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@xxxxxxxxxx> 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! steved. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
