From owner-freebsd-fs@FreeBSD.ORG Sat Dec 1 04:28:05 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 8A1EF16A417 for ; Sat, 1 Dec 2007 04:28:05 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by mx1.freebsd.org (Postfix) with ESMTP id 12A8913C45B for ; Sat, 1 Dec 2007 04:28:04 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB14RkHZ007894; Sat, 1 Dec 2007 06:28:02 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 06:27:55 +0200 Received: from syebe101.NOE.Nokia.com ([172.30.128.65]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 06:27:54 +0200 Received: from [172.30.10.196] ([172.30.10.196]) by syebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 15:27:49 +1100 Message-ID: <4750E2C4.9030003@nokia.com> Date: Sat, 01 Dec 2007 14:27:48 +1000 From: David Cecil User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Bruce Evans 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> <20071201130225.E15170@delplex.bde.org> In-Reply-To: <20071201130225.E15170@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2007 04:27:50.0199 (UTC) FILETIME=[883E4470:01C833D2] X-Nokia-AV: Clean 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 04:28:05 -0000 ext Bruce Evans wrote: > 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). Yes, I've noticed that too. > 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. Yes, that's why in the short term I thought I'd tie it to MNT_SYNCHRONOUS. > 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? The first is from ffs_truncate. I don't know where the second call comes from, yet. > 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. Unfortunately, for this weekend at least, I probably won't be able to investigate this too much further. Project deadlines mean I'm going to have to work around this another way, unfortunately. I'll try and get back to it though. Regards, Dave