Re: [nfs-utils PATCH] retry on EPERM from NFSv4 mount attempt

[Steve Dickson <SteveD@redhat.com>]

On 11/30/2009 11:43 AM, Chuck Lever wrote:
> On Nov 30, 2009, at 8:11 AM, Steve Dickson wrote:
>> Sorry for the delayed response, I took some time off...
>>
>> On 11/24/2009 09:29 AM, Steve Dickson wrote:
>>>
>>>
>>> On 11/23/2009 06:32 PM, Neil Brown wrote:
>>>>
>>>> Hi,
>>>> I recently packaged nfs-utils 1.2.1 for openSUSE and fairly quickly
>>>> got a bug report - "-o nfsvers=3" was needed to mount NFSv3
>>>> filesystems.
>>>>
>>>> mount.nfs in 1.2.1 will first try a v4 mount but will fall-back to v3
>>>> if it gets ENOENT.  This works fine.
>>>> However for kernel prior to 2.6.25, you don't get ENOENT, you get
>>>> EPERM.
>>>> In that case the fall-back to v3 doesn't happen and you get a failure
>>>> to mount.
>>>>
>>>> So I think we need to fall back on EPERM as well.  See below.
>>> I already posted this patch on the v4 mailing list
>>> http://linux-nfs.org/pipermail/nfsv4/2009-November/011595.html
>>> but it got shot down...  at least that's how I interpreted the
>>> responses...
>>>
>>> But I do thing we need this, since there are so many server
>>> that will simple break if we don't... Agreed?
>>
>> There appears to be a consensus that we need to do something
>> but no agreement on what....
>>
>> I believe the options are:
>>   1) Start servers with '-N 4' when there is no root configured.
>>      * The problem I see with this is, in the event v4 support is wanted
>>        its yet another configuration knob that has to be turned,
>> basically
>>        making it more difficult for people use v4.
>>
>>   2) Change the kernel to return NFS4ERR_SERVERFAULT when there is no
>>      root configured.
>>      * I see this is yet another errno the mounting code has to deal
>> with..
>>        We are up to two errnos, do we really want to add a third?
>>
>> Neither one of these solutions deal with legacy servers or move
>> the "v4 technology" forward... IMHO...
> 
> To quote Yoda, "No.  There is another."
> 
> Distributions can choose to revert the recently added behavior which
> makes mount.nfs try vers=4 by default.  That's what the mount config
> file is for, yes?  That seems like a responsible choice, given the
> number of legacy servers still in the field.
Yes... That was the main reason for the configuration file.

> 
> At some later point (say, when your pseudoroot work is more widely
> deployed), distributions can make vers=4 the default as shipped simply
> by flipping a switch in the mount config file.  For now, the default
> behavior stays the same, with an option for individual sites to try
> something new.  In my opinion, default behavior out of the shrinkwrap
> should always be the behavior most likely to work in any environment --
> principle of least surprise, and all that sort of thing.
Not matter how or when we flip the switch, we'll have to deal 
with the legacy servers...

> 
> This seems like the way we normally deploy new features like this, and
> would give the many very recent changes in mount.nfs more soak time with
> early adopters before we force them on everyone.
Take a look at the Fedora 12... Its set up exactly as you just described
with only difference vers=3 is set in the configuration file...

So in my opinion, we are at the point of no return.... ;-)

steved.