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

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

On Nov 30, 2009, at 12:41 PM, Steve Dickson wrote:
> 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...

Well, the point of waiting would be so that the proportion of legacy  
servers would become relatively insignificant.  And, a number of  
reasonable longer term solutions which have been proposed here could  
be deployed in the meantime.

>> 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...

Perhaps that should be the upstream default as well, for now, so other  
distributors aren't taken by surprise when they update to 1.2.1.  Just  
a thought.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com