On Fri, 30 Nov 2007, David Cecil wrote:

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).

Testing shows that the problem is easy to reproduce and often partially detected before it becomes fatal. I saw something like the following:

after touch a; ln a b; rm a; unmount -- no problem with 1 link remaining 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.

mount -u seems to do some things right: at least under -current: - it calls ffs_sync() and thus ffs_update() with waitfor != 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.

Ignore that. It is for async mounts, to make them unconditionally async.

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.

[Context lost to top posting]