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

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

Ewan Mac Mahon wrote:
> On Mon, Oct 26, 2009 at 02:06:45PM -0400, Steve Dickson wrote:
>> On 10/26/2009 01:34 PM, Frank Ch. Eigler wrote:
>>> Steve Dickson <SteveD redhat com> writes:
>>>> On 10/26/2009 12:06 PM, Frank Ch. Eigler wrote:
>>> Unfortunately, this sounds like "only".  Is it out of the question to
>>> make the client look for this case (an upgraded client in an existing
>>> unupgraded, unchanged network) and handle it?
>> We talked about it... See http://linux-nfs.org/pipermail/nfsv4/2009-October/011471.html
>> But in the end, I decided not to do this since its not clear how the change
>> would interact with other NFS servers...
> It's not clear to me how falling back to NFSv3 if v4 fails (and the
> version wasn't explicitly set to v4) could ever cause a problem - it
> might not help, but under what circumstances could it possibly be
> harmful? I had a look at the linked thread from linux-nfs and no-one
> there seemed to come up with anything concrete.

The strongest objection I found was

> Older versions of ONTAP (like 6.0 through 6.2?), for example, have the
> same problem as the Linux NFSv4 server does currently, iirc.
> It's also worth noting that modern Solaris clients do not have this
> ENOENT workaround.  So, if automounter maps are shared with Linux
> clients _with_ the workaround, mounting a Linux NFSv4 server, there
> may be some issues.
> In the long term, I think we are much better off living with a few
> months of complaints about the new version negotiation behavior,
> rather than having this mount.nfs workaround.  I'm not going to object
> to it outright, though...

"I'm not going to object outright" sounds to me like we can fall back
to V3.  I think this is the best plan for us: we should not break things
for users of Fedora clients with RHEL servers or Fedora clients with
Fedora servers.


> On Oct 22, 2009, at 10:04 AM, Steve Dickson wrote:
> > On 10/22/2009 12:21 PM, Chuck Lever wrote:
> >> This would be mitigated instantly by leaving the version negotiation
> >> default set to v3/v2.  Then no workaround would be needed.
> > Right... Or defining the negotiation in the configuration file
> > would also cause the workaround not to be needed...
> That's what I meant: set defaultvers: 3 in the config file, and allow
> early adopters to change it.  After a while, we can bump the default
> setting.  I think this is roughly what Sun did during their transition.

Leaving the default at Version 3 for the next year or two would mostly
solve the problem.


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