From owner-freebsd-fs@FreeBSD.ORG Sat Dec 1 22:14:54 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 5F78C16A417 for ; Sat, 1 Dec 2007 22:14:54 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (adsl-75-1-14-242.dsl.scrm01.sbcglobal.net [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 35AF613C4CE for ; Sat, 1 Dec 2007 22:14:54 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id lB1MEl2Q015881; Sat, 1 Dec 2007 14:14:50 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200712012214.lB1MEl2Q015881@gw.catspoiler.org> Date: Sat, 1 Dec 2007 14:14:47 -0800 (PST) From: Don Lewis To: brde@optusnet.com.au In-Reply-To: <20071202020213.I2849@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii 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 22:14:54 -0000 On 2 Dec, Bruce Evans wrote: > Here is a non-hackish patch which explains why ignoring MNT_RDONLY in > the above or in ffs_mount() helps. It just fixes the confusion between > IN_MODIFIED and IN_CHANGE in critical places. > > % Index: ffs_softdep.c > % =================================================================== > % RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_softdep.c,v > % retrieving revision 1.214 > % diff -u -2 -r1.214 ffs_softdep.c > % --- ffs_softdep.c 9 Nov 2007 11:04:36 -0000 1.214 > % +++ ffs_softdep.c 1 Dec 2007 14:25:49 -0000 > % @@ -2776,5 +2776,5 @@ > % DIP_SET(ip, i_blocks, DIP(ip, i_blocks) + \ > % freeblks->fb_chkcnt - blocksreleased); > % - ip->i_flag |= IN_CHANGE; > % + ip->i_flag |= IN_MODIFIED; > % vput(vp); > % } > % @@ -3575,5 +3575,5 @@ > % ip->i_nlink--; > % DIP_SET(ip, i_nlink, ip->i_nlink); > % - ip->i_flag |= IN_CHANGE; > % + ip->i_flag |= IN_MODIFIED; > % if (ip->i_nlink < ip->i_effnlink) > % panic("handle_workitem_remove: bad file delta"); > % @@ -3594,5 +3594,5 @@ > % ip->i_nlink -= 2; > % DIP_SET(ip, i_nlink, ip->i_nlink); > % - ip->i_flag |= IN_CHANGE; > % + ip->i_flag |= IN_MODIFIED; > % if (ip->i_nlink < ip->i_effnlink) > % panic("handle_workitem_remove: bad dir delta"); > % @@ -3635,5 +3635,5 @@ > % WORKLIST_INSERT(&inodedep->id_inowait, &dirrem->dm_list); > % FREE_LOCK(&lk); > % - ip->i_flag |= IN_CHANGE; > % + ip->i_flag |= IN_MODIFIED; > % ffs_update(vp, 0); > % vput(vp); > > Without this change, soft updates depends on IN_CHANGE being converted > to IN_MODIFIED by ufs_itimes(), but this conversion doesn't happen > when MNT_RDONLY is set. With soft updates, changes are often delayed > until sync time, and when the sync is for mount-update it is done after > setting MNT_RDONLY so the above doesn't work. ufs_itimes() should probably also be looking at fs_ronly instead of MNT_RDONLY, *but* all the paths leading from userland to ufs_itimes() would need to be checked to verify that they check MNT_RDONLY to prevent new file system write operations from happening while the remount is in progress.