[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

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

I don't see how pushing, incorporating and utilizing the latest technology 
available can "severely damaging the reputation of Fedora". 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!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]