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

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

 



[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 


steved.

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux