Date: Sat, 1 Dec 2007 13:23:34 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: David Cecil <david.cecil@nokia.com> Cc: freebsd-fs@freebsd.org Subject: Re: File remove problem Message-ID: <20071201130225.E15170@delplex.bde.org> In-Reply-To: <4750AE03.9010603@nokia.com> References: <474F4E46.8030109@nokia.com> <20071130112043.H7217@besplex.bde.org> <474F69A7.9090404@nokia.com> <20071130151606.F12094@delplex.bde.org> <20071130052840.GH83121@deviant.kiev.zoral.com.ua> <20071201030305.G1170@besplex.bde.org> <4750AE03.9010603@nokia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 1 Dec 2007, David Cecil wrote: > I tried the change and it doesn't fix the non-sofdep problem. Urk. Apparently, the extra ffs_update() activity only helps as a side effect. > Looking at that code got me thinking though. I thought that a workable > solution for us short term might be to call UFS_UPDATE with waitfor == 1 if > the filesystem is mounted synchronous. It is strange that ithat and some other things are fully async even if the fs is mounted (not-quite-)fully sync (or the file is open with O_SYNC). I;ve thought a bit about this and decided that it is mostly a good optimization -- some things can be reconstructed by fsck and it is a good optimization to not write then synchronously. Note that waitfor == 1 in UFS_UPDATE() forces an i/o unconditionally. In some kernels I use a patch (posted to this list a month ago) to avoid i/o if the inode hasn't changed and the buffer containing the inode isn't dirty. This doesn't seem to affect the bug, but it might make the bug larger for soft updates, since soft updates might be depending on the i/o to trigger a callback. > So, the scenario is: > mount -u -w -o sync / > remove file > mount -u -o ro / > > I observed that the second call to ffs_update with the offending vnode caused > bwrite to be called, though the first call was still bdwrite. Anyhow, the > problem still occurred. I tried clearing the B_ASYNC flag in ffs_update if > bwrite is called, but still the problem occurs. Obviously I'm missing > something. When is the second update? Soft updates seems to trigger delayed updates as part of syncing, but I don't see how there could be more than one non-null ffs_update that does a bwrite for the non-soft updates sync mounted case, and for the soft updates sync mounted case the sync shouldn't be delayed. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071201130225.E15170>