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(a)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.