Date: Wed, 29 Feb 2012 11:19:41 -0800 From: Kirk McKusick <mckusick@mckusick.com> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: fsync: giving up on dirty Message-ID: <201202291919.q1TJJfCP082878@chez.mckusick.com> In-Reply-To: <jil10d$52d$1@dough.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> To: freebsd-fs@freebsd.org > From: Ivan Voras <ivoras@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 > Feb 28 04:02:09 skynet kernel: 0xfffffe000fef2780: tag devfs, type VCHR > Feb 28 04:02:09 skynet kernel: usecount 1, writecount 0, refcount 2400 > mountedhere 0xfffffe000fd25200 > Feb 28 04:02:09 skynet kernel: flags () > Feb 28 04:02:09 skynet kernel: v_object 0xfffffe000fe96d98 ref 0 pages 23990 > Feb 28 04:02:09 skynet kernel: lock type devfs: EXCL by thread > 0xfffffe000feb5000 (pid 44968) > Feb 28 04:02:09 skynet kernel: dev multipath/hpdisk4-web > > I'm leaning towards suspecting bad hardware - the device behind > "multipath/hpdisk4-web" is an old HP MSA FC storage (which I wouldn't > recommend to anyone), but though verbose, the message lacks device-level > specifics. I would expect messages to be logged by the isp driver, or > the CAM layer, or even GEOM, but there is nothing there - only this > "fsync" message. > > From the code, it looks like an transient condition (printed in the case > of EAGAIN), but the hardware here is behaving a bit suspect so I'd like > to make sure - should I ignore this message? I have seen this message during some of Peter Holm's stress tests when running with journaled soft updates. Note that soft updates without journaling do not show this issue. The "giving up" message comes when trying to flush the filesystem metadata blocks associated with the mount device (hence the VCHR type of the vnode). The problem has become more evident with my recent changes to the way that sync'ing is done. 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. Kirk McKusick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201202291919.q1TJJfCP082878>