From owner-freebsd-fs@FreeBSD.ORG Fri Nov 30 16:34:09 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 26E9916A4A1 for ; Fri, 30 Nov 2007 16:34:09 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id BD22713C46B for ; Fri, 30 Nov 2007 16:34:07 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lAUGY3Np005117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Dec 2007 03:34:05 +1100 Date: Sat, 1 Dec 2007 03:34:03 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20071130052840.GH83121@deviant.kiev.zoral.com.ua> Message-ID: <20071201030305.G1170@besplex.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> 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: Fri, 30 Nov 2007 16:34:09 -0000 On Fri, 30 Nov 2007, Kostik Belousov wrote: > On Fri, Nov 30, 2007 at 03:58:55PM +1100, Bruce Evans wrote: >> On Fri, 30 Nov 2007, David Cecil wrote: >... >>> One more point to address Julian's question, the partition is not mounted >>> with soft updates. >> >> Interesting. I saw no sign of the problem without soft updates except a >> panic later after enabling soft updates. I was running fsck a lot but >> may have forgotten one since no error was detected. The problem should >> be easier to understand if it affects non-soft-updates. > > As a speculation, it might be that ufs_inactive() should conditionalize on > fs_ronly instead of MNT_RDONLY. Then, VOP_INACTIVE() would set up the > IN_CHANGE|IN_UPDATE and finally call the ffs_update() ? Something like that seems to be right. The folowing hack in ufs_inactive() seems to fix the problem with sift updates, as does unsetting MNT_RDONLY for the whole VOP_SYNC() in ffs_mount(). % Index: ufs_inode.c % =================================================================== % RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_inode.c,v % retrieving revision 1.53 % diff -u -2 -r1.53 ufs_inode.c % --- ufs_inode.c 7 Apr 2004 03:47:20 -0000 1.53 % +++ ufs_inode.c 30 Nov 2007 12:58:39 -0000 % @@ -59,4 +59,6 @@ % #endif % % +#include % + % /* % * Last reference to an inode. If necessary, write or delete it. % @@ -118,6 +120,15 @@ % ip->i_flag &= ~IN_ACCESS; % } else { % + int wasro = 0; % + % (void) vn_write_suspend_wait(vp, NULL, V_WAIT); % + if (vp->v_mount->mnt_flag & MNT_RDONLY && % + ip->i_fs->fs_ronly == 0) { % + vp->v_mount->mnt_flag &= ~MNT_RDONLY; % + wasro = 1; % + } % UFS_UPDATE(vp, 0); % + if (wasro) % + vp->v_mount->mnt_flag |= MNT_RDONLY; % } % } I didn't bother with correct locking here (only tested under UP). With this change, the VOP_SYNC() in ffs_mount() for MNT_UPDATE seems to flush everything in simple cases (with no open files), just like the VOP_SYNC() in unmount() flushes everything before ffs_unmount() is reached. OTOH, without a forced flush, soft updates takes a long time to flush things -- more like 3 syncer periods than 1 for non-waitfor syncs. With soft updates, the above is called from deep in VOP_SYNC(). It's strange that the above non-waitfor UFS_UPDATE() is used inside of waitfor syncs. It apparently works because the waitfor syncs wait for it later, but only if it is non-null. BTW, *_mount() has lots of bogusness related to string options. In particular, ffs_mount() for update from r/w to r/o checks the "ro" string option and sets MNT_RDONLY later, but MNT_RDONLY is already set and other things depend on it being set early. Bruce