Buyer Beware: A Major Change in NFS is about to happen

[Andrew Haley]

Steve Dickson wrote:
> 
> On 09/30/2009 06:18 AM, Andrew Haley wrote:
>> Steve Dickson wrote:
>>> On 09/30/2009 04:53 AM, Andrew Haley wrote:
>>>> Steve Dickson wrote:
>>>>> On 09/29/2009 10:10 PM, Jeremy Katz wrote:
>>>>>> On Tue, Sep 29, 2009 at 8:15 PM, Steve Dickson <SteveD at redhat.com> wrote:
>>>>>>>> My main concern is with installer, installing from NFS shares from older
>>>>>>>> servers, say RHEL5.  How will anaconda handle mounting?  Will there be
>>>>>>>> odd errors that are difficult to figure out?  Has this been tested in
>>>>>>>> the anaconda environment at all?
>>>>>>> This issue is this... when the the F12 does a mount to a linux server
>>>>>>> and that linux server is *not* configured with a  "/ *(ro,fsid=0)"
>>>>>>> export, the mount will fail with ENOENT (or No such file or directory).
>>>>>>> If the server does have that export, things will work as expected...
>>>>>>> So my advice is to added that one line to your rhel5 server and every
>>>>>>> thing should as expected... or may even better... ;-) Another workaround
>>>>>>> is to added the '-o v3' mount options... would that be hard?
>>>>>> Why not just see the error and fall back and try v3 programatically
>>>>>> rather than forcing that upon unsuspecting users?  If someone
>>>>>> explicitly specifies v4, then sure, if that fails, it should fail.
>>>>>> But if they don't, we should be forgiving in what we do rather than
>>>>>> giving cryptic error messages.

>>>>> I looked into this... Having the kernel give a "different" kind of 
>>>>> error when the "V4 beginning mount routine failed" did not look 
>>>>> feasible  so figure it would be impossible to get through upstream
>>>> I don't really understand this reason.  When you get a mount fail, why
>>>> not try v3?  It doesn't matter whether the kernel gives a different
>>>> kind of error or not.

>>> The error that is returned is ENOENT which is fatal error because 
>>> it means the remote directory does not exist... and I'm not sure it
>>> would be good to continue flood the network with mounts requests
>>> (I'm thinking about autofs mount storms) for directories that may
>>> or may not be there...

>> I can't see how it would cause a mount storm: all you'd be doing is
>> issuing a mount request twice, once in each protocol.  
> Times 1000 very 5 seconds...

So 2000 every 5 seconds as opposed to 1000 every 5 seconds.  This is
surely better than returning an incorrect "directory does not exist"
response to almost every NFS user who upgrades.  And it will be almost
everyone: maintaining servers on older versions of RHEL and upgrading
clients to recent Fedora is normal.

> I really don't think the server people would appreciate all those
> extra cycles and network traffic... Doing something like this would
> be hack... a hack that I could not push upstream...  There are other
> workagrounds (defined in original mail) that I would rather
> explore...

But they are all pretty unpleasant.  The user gets an obscure error
message that indicates nothing to them except "NFS is broken".
They then have to either export root from the server or edit their
fstab.

>> Consider the alternative, which is breaking NFS access for enormous
>> numbers (hundreds of thousands?)  of people.  And, in the process,
>> severely damaging the reputation of Fedora.

> I am not "breaking NFS access", I'm changing NFS access for the
> better, IMHO.
> Unfortunately its just a bit painful....

Yep.

> I don't see how pushing, incorporating and utilizing the latest
> technology available can "severely damaging the reputation of
> Fedora".

Really?  Why not?  What you are proposing to is indistinguishable to a
user from breaking NFS.  I can easily see it.

> To be quite frank, my goal is just the opposite... I want Fedora
> have a reputation of being on the breaking edge of technology... I
> think that is a good thing!

Me too.  So, let's see how we can do that without making Fedora more
fragile.

Andrew.