From owner-freebsd-fs@FreeBSD.ORG Fri Nov 30 06:03:43 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 BE76D16A46E for ; Fri, 30 Nov 2007 06:03:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 4230E13C458 for ; Fri, 30 Nov 2007 06:03:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IxyQe-00020z-8i for freebsd-fs@freebsd.org; Fri, 30 Nov 2007 07:28:44 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id lAU5SfLU057523; Fri, 30 Nov 2007 07:28:41 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lAU5Sfug057522; Fri, 30 Nov 2007 07:28:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 30 Nov 2007 07:28:41 +0200 From: Kostik Belousov To: Bruce Evans Message-ID: <20071130052840.GH83121@deviant.kiev.zoral.com.ua> References: <474F4E46.8030109@nokia.com> <20071130112043.H7217@besplex.bde.org> <474F69A7.9090404@nokia.com> <20071130151606.F12094@delplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbfcI4OLZ4XW0yH2" Content-Disposition: inline In-Reply-To: <20071130151606.F12094@delplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 81fdb9d644701462f7849401ec726e21 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1835 [Nov 29 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release 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 06:03:43 -0000 --VbfcI4OLZ4XW0yH2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 30, 2007 at 03:58:55PM +1100, Bruce Evans wrote: > On Fri, 30 Nov 2007, David Cecil wrote: >=20 > >Thanks Bruce. > > > >Actually, I had found the same problem, and I came up with the first lin= e=20 > >of your patch (adding IN_MODIFIED) myself, but I still saw the problem. = I >=20 > Yes, it's not that. Testing reminded me that there is normally a > VOP_INACTIVE() after unlink so the IN_CHANGE mark doesn't live very long > for unlink (it can only live long for open files). >=20 > Testing shows that the problem is easy to reproduce and often partially > detected before it becomes fatal. I saw something like the following: >=20 > after touch a; ln a b; rm a; unmount -- no problem with 1 link remain= ing > after touch a; rm a; unmount -- no problem with unmount > after touch a; ln a b; rm a; mount -u o ro -- no problem with 1 link.= .. > after touch a; ; rm a; mount -u o ro -- worked once without soft > updates but seemed to be responsible for a soft update panic later > after touch a; ; rm a; mount -u o ro -- usually fails with soft > updates; the error is detected in various ways: > under ~5.2, mount -u prints "/f: update error: blocks 0 files 1" > but succeeds > under -current, mount -u fails and a subroutine prints > "softdep_waitidle: Failed to flush worklist for 0xc3e1a29c" > However, mount -u apparently cannot afford to fail at this > poing since it has committed to succeeding -- further > mount -u's and unmounts fail and it takes a reboot to reach > an fsck that can fix the problem. >=20 > mount -u seems to do some things right: at least under -current: > - it calls ffs_sync() and thus ffs_update() with waitfor !=3D 0. > - IN_MODIFIED is usually already set in ffs_update(). > - softdep_update_inode_inodeblock() in ffs_update() seems to > make null changes. That doesn't seem right -- shouldn't it > update the link count and finish removing the file?... I > just noticed that ufs_inactive() handles some of this. > - it calls softdep_flushfiles() after doing the sync. This > doesn't seem to touch the inode. > - apparently, softdep_flushfiles() fails in -current, while in > ~5.2 it bogusly succeeds and then code just after it is called > detects a problem but doesn't handle it. >=20 > >didn't pick up on the need for the second line (else if (DOINGASYNC(dvp)= )=20 > >{) though. It's a default mount, so I don't understand how that will=20 > >help, i.e. it won't be an async mount, right? >=20 > Ignore that. It is for async mounts, to make them unconditionally async. >=20 > >One more point to address Julian's question, the partition is not mounte= d=20 > >with soft updates. >=20 > 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. >=20 > [Context lost to top posting] >=20 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() ? --VbfcI4OLZ4XW0yH2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHT5+IC3+MBN1Mb4gRAswwAKC91VxP7p5kWAd55ar832Zqe+YULQCfc/5T Y3Pyj1zTUnBdjJrFx4U6gZM= =YcGm -----END PGP SIGNATURE----- --VbfcI4OLZ4XW0yH2--