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

[Steve Dickson]

On 10/26/2009 10:34 AM, Steve Dickson wrote:
> [With the next nfs-utils rawhide build, I will be flipping the ]
> [switch that will cause all NFS client mounts to try NFS v4 first ]
> [At the bottom of this email has the workarounds if this change does ]
> [indeed cause pain ]
> 
> As part of the https://fedoraproject.org/wiki/Features/NFSv4Default feature
> I am one commit away from changing the default protocol version NFS will 
> be using (or at least trying to use).
> 
> What does this means to you? Hopefully nothing! In theory this should 
> be a very seamless transition but with all new technology there
> will be (and are) some rough spots. 
> 
> Why are make the change? See the NFSv4Default wiki for details,
> but in a nutshell:
>     * Better performance - V4 is now a stateful protocol. Meaning the server keeps 
>       state on all the clients access a particular file or directory. This
>       allows the server to give out delegations (or leases) which in turn
>       allows the client to aggressive cache both data and meta data locally
> 
>     * Firewall Friendly- With v4 only one port is used 2049 for all traffic
>       including mounting and file locking.
> 
>     * Finally it enables us use upcoming minor releases of the the protocol. 
>       NFS version 4.1 and pNFS are two example of upcoming minor releases.
> 
> 
> FYI, V4 was introduced in Fedora Core 2 so it has been around for a while. I 
> personally have been using it for my home directory for a couple years now..
> For more of the nitty gritty details see  
>     http://www.iaps.com/NFSv4-new-features.html 
> 
> That's the good news... Here is the bad....
> 
> Because the mount command will try NFS v4 first, mounts to older Linux servers
> will start failing like:
> 
>  # mount linux-server:/export /mnt
>  mount.nfs: mounting linux-server:/export failed, reason given by server:
>     No such file or directory
> 
> This is due to a defect in the Linux server exporting code, which is fixed 
> in F-12, *but* there are a number of workarounds
> 
> On the server (Which is suggested):
>    * Add the following entry to the /etc/exports file:
>      / *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages.
> 
> On the client, go back to v3 mounts by doing one of the following:
> 
>    * Add -o v3 to command line, similar to:
>         mount linux-server:/export /mnt
> 
>    * Change the default mount version in the new /etc/nfsmount.conf file by 
>      uncommenting the Nfsvers=3 setting in the 'NFSMount_Global_Options' section.
>      See nfsmount.conf(5) man page for details. The diff would look like:
> 
>     --- /etc/nfsmount.conf.orig	2009-10-26 09:30:21.000000000 -0400
>     +++ /etc/nfsmount.conf	2009-10-26 10:31:30.227443686 -0400
>     @@ -31,7 +31,7 @@
>     # Protocol Version [2,3,4]
>     # This defines the default protocol version which will
>     # be used to start the negotiation with the server.
>    -# Defaultvers=4
>    +Defaultvers=3
>     #
>     # Setting this option makes it mandatory the server supports the
>     # given version. The mount will fail if the given version is 

Update... 

With Build http://koji.fedoraproject.org/koji/taskinfo?taskID=1783028 
the mount command will first try to do a v4 mount and then fall back
to v3/v2 mounts if v4 is not support. This fall back will also happen 
if the server returns ENOENT, which will be the case with legacy Linux 
servers  and possible Netapp servers... 

I hope to get the ENOENT-patch into F-12 as soon as it bakes a while
in rawhide and once F-12 stabilizes... 

Thanks for all the input!!!

steved.