Re: patch for ext2fs unmount problem at shutdown

On  6 Sep, Poul-Henning Kamp wrote:
> In message <200509060841.j868fj1I032057_at_gw.catspoiler.org>, Don Lewis writes:
> 
>>I suspect both that is one possible reason, and another reason would be
>>to avoid marking the file system clean if any writes timed out.
> 
> In that case the unmount should fail, otherwise the filesystem is
> buggy.
> 
>>> I think we should do away with the nbusy check, including the 35
>>> lines of softupdate magic and call vfs_unmountall() in all circumstances
>>> (but retain the check for !cold, RB_NOSYNC and panic).
>>> 
>>> Instead we should add a flag to VFS_UNMOUNT that means "don't hang
>>> forever" and use that in vfs_unmountall().
>>
>>That makes sense longer term, but for quite some time we've had a number
>>of users who have been rather unhappy to find out that every time they
>>reboot with a mounted ext2fs file system that *all* of their file
>>systems are marked dirty and require attention from fsck.
> 
> I am really not keen on adding more magic features to the buffer cache
> if we can get the same effect by taking away code.

I'm not especially thrilled about it either since the buffer cache code
is one of the parts of the kernel that I understand the least.  This
patch is pretty non-intrusive, though, because it essentially just
borrows an unused flag bit.

> Considering that our kernel presently tend to explode violently on
> disk errors I would say that the nbusy check should just be commented
> out for now and vfs_unmountall() always tried.

This might be reasonable to try in HEAD, but I'm not comfortable doing
it in RELENG_6 and RELENG_5.  We've always skipped vfs_unmountall() if
nbusy != 0, so we don't know what strange and wonderful new failure
modes we might find if we do it unconditionally.  Just auditing the code
would be a lot of work given the number of file system types we support.