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

Andrew Haley aph at redhat.com
Tue Oct 27 11:03:38 UTC 2009


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 at 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...
(chuck[dot]lever[at]oracle[dot]com)

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

Further,

 > 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.
(chuck[dot]lever[at]oracle[dot]com)

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

Andrew.




More information about the fedora-devel-list mailing list