Re: umount -f implementation

On Mon, 29 Jun 2009, Attilio Rao wrote:

>
> While that should be real in principle (immediate shutdown of the fs
> operation and unmounting of the partition) it is totally impossible to
> have it completely unsleeping, so it can happen that also umount -f
> sleeps / delays for some times (example: vflush).
> Currently, umount -f is one of the most complicated thing to handle in
> our VFS because it puts as requirement that vnodes can be reclaimed in
> any moment, adding complexity and possibility for races.
>
> What's the fix for your problem?
>
>From other responses, it does look like pursuing this is appropriate
and that current behaviour is considered a bug.

I should have noted in the previous email that I suspected that my simple 
patch didn't handle all cases, which I have just determined via testing.

Unfortunately, the thread doing "umount" can also get stuck in an msleep() 
while waiting for the mnt_lockref to go to 0, which happens before the
VFS_UNMOUNT() call. (mnt_lockref gets incremented by various system
calls that call vfs_busy().)

I think I can fix this in the experimental nfsv4 client, since it has
a kernel thread that can check for MNTK_UNMOUNTF being set and then
kill off the RPCs in progress, but that won't help the regular client.

It's starting to look like too much work for FreeBSD8, but sounds like
it is worth pursuing. (Appologies to anyone that thought I would have it
all fixed in a day or two.)

rick