Re: [PATCH 06/12] text-based mount.nfs:

[Chuck Lever <chuck.lever@oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 2554 bytes --]

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.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 315 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
email;internet:chuck dot lever at nospam oracle dot com
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs