fsync: giving up on dirty

Kirk McKusick mckusick at mckusick.com
Fri Mar 2 21:36:33 UTC 2012


> From: Ivan Voras <ivoras at freebsd.org>
> Date: Fri, 2 Mar 2012 12:57:00 +0100
> Subject: Re: fsync: giving up on dirty
> To: Kirk McKusick <mckusick at mckusick.com>
> Cc: freebsd-fs at freebsd.org
> 
> On 29 February 2012 20:19, Kirk McKusick <mckusick at mckusick.com> wrote:
> 
> > 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

Thanks for the report. It is useful to know that this can occur even
with non SUJ systems. I am working with Peter Holm to identify the
cause and will keep you (and the list) posted with what we figure out.

	Kirk McKusick


More information about the freebsd-fs mailing list