From owner-freebsd-fs@FreeBSD.ORG Sat Dec 1 02:23:38 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1750316A418 for ; Sat, 1 Dec 2007 02:23:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id A5F1813C442 for ; Sat, 1 Dec 2007 02:23:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lB12NZUG020780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Dec 2007 13:23:35 +1100 Date: Sat, 1 Dec 2007 13:23:34 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David Cecil In-Reply-To: <4750AE03.9010603@nokia.com> Message-ID: <20071201130225.E15170@delplex.bde.org> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: File remove problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2007 02:23:38 -0000 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