[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-nfsv4
Subject:    Re: [PATCH 0/2] : mount.nfs: Try v4 mounts first (Release 3)
From:       Steve Dickson <SteveD () redhat ! com>
Date:       2009-09-28 20:05:10
Message-ID: 4AC116F6.6090607 () RedHat ! com
[Download RAW message or body]



On 09/28/2009 03:39 PM, Chuck Lever wrote:
> On Sep 28, 2009, at 2:43 PM, Steve Dickson wrote:
>> On 09/28/2009 12:55 PM, Chuck Lever wrote:
>>> On Sep 28, 2009, at 5:51 AM, Steve Dickson wrote:
>>>> On 09/28/2009 12:01 AM, Chuck Lever wrote:
>>>>>
>>>>> On Sep 26, 2009, at 12:40 PM, Steve Dickson wrote:
>>>>>> On 09/25/2009 08:56 PM, Steve Dickson wro
>>>>>>>
>>>>>>>> If NFSv4 negotiation is allowed, then each time through the fg/bg
>>>>>>>> retry loop, mount.nfs should try NFSv4, then NFSv2/v3.  It will
>>>>>>>> make
>>>>>>>> mount.nfs do the right thing in more cases than your current
>>>>>>>> proposal.
>>>>>>> Even when the server says both V4 and v3 are not supported? Again I
>>>>>>> ask which current NFS implementation works this way?
>>>>>>>
>>>>>>>>
>>>>>>>> The cleanest, safest way to do this is to have each NFSv4 and
>>>>>>>> NFSv2/v3
>>>>>>>> mount attempt operate on a copy of the user-specified options list.
>>>>>>>> That way each iteration of fg/bg, and each version-specific mount
>>>>>>>> attempt, will get the user-specified options and nothing more or
>>>>>>>> less.
>>>>>>>> I can almost guarantee that this will be simpler than your current
>>>>>>>> proposal.
>>>>>>> Please prove it.. lets see the patch...
>>>>>>>
>>>>>> On second thought... don't bother... Unless there are any other
>>>>>> objections
>>>>>> to this design or major holes in it, I think I'm just going to go
>>>>>> with it...
>>>>>
>>>>> How about this: your patch re-exposes the bug fixed in commit
>>>>> 23c1a452.
>>>>> I think it will cause the negotiated v2/v3 pmap mount options to be
>>>>> dumped into /etc/mtab, which breaks umount in some cases.
>>>>>
>>>> How???? When the *only* time /etc/mtab would be updated is when a
>>>> *successful*
>>>> mount happens... Please...
>>>
>>> Exactly.  When a successful v2/v3 mount occurs, some version negotiation
>>> almost always takes place.  mount.nfs rewrites the mount options.
>>>
>>> I applied your first proposed patch from release 3 to the latest version
>>> of nfs-utils from your git repo, and built a local version of
>>> mount.nfs.  Then, I tried the most basic vers=3 mount request:
>>>
>>> [cel@matisse main]$ sudo utils/mount/mount.nfs klimt:/export/test /mnt
>>> -o vers=3
>>> [cel@matisse main]$ cat /etc/mtab
>>>
>>>  [ ... snipped ... ]
>>>
>>> klimt:/export/test /mnt nfs
>>> rw,addr=192.168.0.55,vers=3,proto=tcp,mountvers=3,mountproto=udp,mountport=32840
>>>
>>> 0 0
>> So what part of this is corrupting the /etc/mtab entry? Those are the
>> exact same
>> options that were given to the kernel... Its actually a more accurate
>> entry now.
>> Plus it give umount more information (mountproto and mountport) on how to
>> do the umount... I see this as a plus...
> 
> There's no guarantee that the server will be configured the same way
> when you are ready to unmount this file system.
> 
> If the server has rebooted since the file system was mounted, it's
> almost guaranteed that the mountport setting will be different, for
> example.  There's nothing that requires the remote mountd to have the
> same transports available after a server reboot, either.  An admin can
> change these settings at any time on most servers without a reboot.
Very true.. By no means am I a saying the renegotiation code should
be removed... but the majority of the the time, the server has not 
been reboot, that information is valued... why not try it first and 
then renegotiate?

> 
> What we want is to give umount.nfs the same mount options that were
> provided by the user at mount time, and then let it negotiate the MNT
> pmap parameters again, based on how the server is configured at that
> time.  That's the way the legacy code has worked for years.
We still do store the same mount options there is just more and
they have never been the exact same options since the mount command
always seem to default values (i.e. 'rw' )

> 
> This is why we still have /etc/mtab (as hard as Miklos has tried to get
> rid of it).  It's why umount.nfs doesn't use /proc/mounts to extract the
> full set of mount options for the file system.  Umount.nfs has to have
> the same mount options that the user provided at mount time to make this
> work.
I can't agree with Miklos more... Writing to /etc directory just wrong 
IMHO especially since we have all the same information (plus more) in
/proc/mounts... I wait for the day /etc/mtab goes as way!! 


> 
> This is also why the legacy code does full version negotiation every
> time the fg/bg loop retries the mount.  If the server happens to reboot
> between retries, and we don't clear out the old negotiation options, the
> mount options list will contain this same kind of stale information, and
> the mount attempt will fail outright instead of negotiating based on the
> latest server settings (true at least for v2/v3, anyway; but I don't
> think there's any guarantee that the server will always export the same
> NFS versions after a reboot, either).
I agree with you... See that third patch I just posted...

steved.
_______________________________________________
NFSv4 mailing list
NFSv4@linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
[prev in list] [next in list] [prev in thread] [next in thread]