Re: umount -f implementation

2009/6/30 Rick Macklem <rmacklem_at_uoguelph.ca>:
>
>
> 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().)

Sorry for not answering and I still didn't read this thread at all, I
just wanted to let you know that this msleep is skipped for the force
unmount, it should just happen in a normal unmount case.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein