[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

On Mon, 2009-10-26 at 10:34 -0400, 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 

Haven't gone through the full thread yet, but is it worth adding a
note/admonition to our NFS installation instructions that changing the
nfs server configuration may be necessary?



Attachment: signature.asc
Description: This is a digitally signed message part

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