Re: whither NFS umount?

[Steve Dickson <SteveD@redhat.com>]

On 10/13/2010 02:18 PM, Trond Myklebust wrote:
> On Wed, 2010-10-13 at 13:40 -0400, Steve Dickson wrote:
>> Sorry for joining late... 
>>
>> On 10/12/2010 03:44 PM, Trond Myklebust wrote:
>>> On Tue, 2010-10-12 at 15:18 -0400, Jeff Layton wrote:
>>>
>>>> I think the part that causes problems is having userspace do this. In
>>>> theory, if the kernel were in charge of sending the UMNT, then it's not
>>>> really a problem since it knows when to do it. If we have code that
>>>> sends a UMNT already, why not do a best-effort UMNT call from the
>>>> kernel when we tear down the sb?
>>>
>>> Purely for the pleasure of allowing the server to maintain inaccurate
>>> statistics about who is currently mounting what? I think not...
>>>
>>> You can get far more accurate results by replacing the MNT/UMNT state
>>> counter with a purely server-based scheme to track who accessed one or
>>> more files on each exported partition in the past 5 minutes or so. That
>>> would even work with NFSv4...
>>>
>>>> Either way, eliminating umount.nfs would be nice...
>>>
>>> Agreed.
>> I having a hard time understanding this logic... 
>>
>> Why do we think we (the Linux community) can simply 
>> throw way an established part of the protocol just because 
>> we deem it advisory... Now maybe in our implementation UMNT its
>> advisory and it might even be advisory in the spec, but how do we 
>> know with  other NFS implementation is not advisory, its actually needed.
>> We don't known and we can't known....
> 
> Yes we do know!
> 
> Anything that relies on a _stateful_ protocol that doesn't have a way to
> deal with the fact that clients may go away and never return is
> inherently broken. That lesson is exactly why we moved to making state
> subject to a lease in NFSv4.
> 
> Furthermore, it is not as if we have more than a semi-working
> implementation of this now: we don't implement UMNTALL on client reboot
> (I doubt that even Solaris bothers doing that) and we don't get UMNT
> right if the same filesystem is mounted twice on the same client.
> 
> IOW: if there are servers that really do require UMNT to work, then they
> will already be learning the errors of their assumptions with today's
> client.
You reasoning is very solid... I agree, if servers, for some reason,
are depended on this state they are broken. But *not* staying 
compatible with broken server is not an option, at least from 
where I view the world.. ;-)
  
> 
>> Now when our implementation becomes an NFSv4 only implementation, 
>> I say fine; Eliminate all the protocols that go along
>> with both v2 and v3. But until then lets just have leave
>> the legacy protocols along and move forward in more meaningful 
>> efforts... 
> 
> For the reasons state above, I see no need to put UMNT support in the
> kernel, nor do I want yet another upcall mechanism in order to make
> UMNTALL work.
Fine... 

> For the same reasons, I don't care if people keep it or throw it out
> from the userland utilities.
Unfortunately I do! 8-) 

steved.