Date: Fri, 30 Nov 2007 07:28:41 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-fs@freebsd.org Subject: Re: File remove problem Message-ID: <20071130052840.GH83121@deviant.kiev.zoral.com.ua> In-Reply-To: <20071130151606.F12094@delplex.bde.org> References: <474F4E46.8030109@nokia.com> <20071130112043.H7217@besplex.bde.org> <474F69A7.9090404@nokia.com> <20071130151606.F12094@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071130052840.GH83121>