fsync: giving up on dirty

[Johannes Totz]

On 02/03/2012 11:57, Ivan Voras wrote:
> On 29 February 2012 20:19, Kirk McKusick <mckusick at mckusick.com> wrote:
>>> To: freebsd-fs at freebsd.org
>>> From: Ivan Voras <ivoras at freebsd.org>
>>> Date: Wed, 29 Feb 2012 12:08:51 +0100
>>> Subject: fsync: giving up on dirty
>>>
>>> Hi,
>>>
>>> One of the machines I take care of started recently started recording
>>> messages such as these in the logs:
>>>
>>> Feb 28 04:02:09 skynet kernel: fsync: giving up on dirty
> ...
>> I believe that the problem is because the soft updates worklist needs
>> to be flushed before some of the dirty blocks can be successfully written.
>> If you are running a 9-stable system on this machine, are using journaled
>> soft updates on the filesystem in question, and are willing to try out
>> my first attempt at a fix, let me know and I'll send you the diffs for it.
> 
> The thing is - I'm not. This is a 9-stable, but it was upgraded from 8
> and I don't have SUJ enabled.
> 
> I keep getting such messages daily.
> 
> Mar  1 04:02:09 skynet kernel: fsync: giving up on dirty
> Mar  1 04:02:09 skynet kernel: 0xfffffe000fef2780: tag devfs, type VCHR
> Mar  1 04:02:09 skynet kernel: usecount 1, writecount 0, refcount 2515
> mountedhere 0xfffffe000fd25200
> Mar  1 04:02:09 skynet kernel: flags ()
> Mar  1 04:02:09 skynet kernel: v_object 0xfffffe000fe96d98 ref 0 pages 10182
> Mar  1 04:02:09 skynet kernel: lock type devfs: EXCL by thread
> 0xfffffe003dc8d000 (pid 79344)
> Mar  1 04:02:09 skynet kernel: dev multipath/hpdisk4-web

A while back I got similar messages (should be in the archives somewhere).
Eventually it led to filesystem corruption with a kernel panic. It
seemed to be related to snapsot creation (soft-updates, no journal).
fsck and manually deleting all snapshots solved the problem temporarily.
But when I stopped doing UFS snapshots alltogether the messages stopped
too...