Neil Brown wrote:
>>> By the by, when testing what the current code does, I discovered that
>>> if
>>>
>>>       mount server:/path /dir
>>>
>>> falls back to v2 because the default (v3) doesn't work, then
>>>      umount /dir
>>>
>>> fails with
>>>
>>>      umount.nfs: Server failed to unmount 'server:/path'
>>>
>>> which is a worry.
>> OK, it's not supposed to do that either, and I never saw that  
>> behavior during testing.  (Well, actually we did see it, but it was  
>> only with NFSv4, and is supposed to be fixed by one of the patches in  
>> the last set I sent you).
>>
>>> I think there are two problem here:
>>>   1/ we should fall back to v2 umount if v3 fails (well, the MOUNT
>>>      versions  are different, but you know what I mean).
>>>   2/ If the call to the server fails, we should still unmount the
>>>      filesystem (call del_mtab .... not a good choice for the name
>>>      of the function that does the actual unmount...)
>>> Thoughts?
>> First I would like to understand precisely why umount is failing.  In  
>> this case, mount.nfs should rewrite the mount options, then post them  
>> in /etc/mtab so that umount can use the same service endpoint when  
>> doing the unmount.  The umount should then use the post-fallback  
>> options, and succeed.  Does "umount -v" provide any helpful
>> information?
> 
> (remembering this is with the binary mount interface, not the new
> ASCII one) the updated mount options are *not* written to /etc/mtab.
> It just has 
> 
>  eli:/var/tmp/samba /mnt nfs rw,addr=192.168.1.3 0 0
> 
> nfsvers=2 has not been added.
> umount -v says:
> umount.nfs: trying 192.168.1.3 prog 100005 vers 3 prot UDP port 723
> umount.nfs: Server failed to unmount 'eli:/var/tmp/samba'

OK... the new information is that this is failing with the legacy mount. 
  That makes a little more sense.

>> Certainly it would be good to rename del_mtab() !
>>
>> I also agree that it would be an overall improvement if the RPC  
>> umount request did not determine whether or not umount also tries to  
>> detach the local file system.  I don't see any good reason to link  
>> the two.
> 
> I've broken the link, so the unmount now succeeds.  It would be good
> to get it to send the right request to the server though, either by
> recording the protocol in mtab, or using probe_mntport or similar.

Yeah, that's odd.  It is supposed to be probing the server's mountd in 
nfs_call_umount.  The problem may be that it's only trying a single 
mount RPC (for vers=3), and not doing any kind of version fallback.