Find the answer to your Linux question:
Results 1 to 7 of 7
I have determined that some part of the changes between Linux kernel 2.6.32 and 2.6.33 effected mounting NFS shares. It is definitely a kernel issue as my testing has been ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jun 2012
    Posts
    5

    Linux Kernel change 2.6.33 / 2.6.32 NFS mount


    I have determined that some part of the changes between Linux kernel 2.6.32 and 2.6.33 effected mounting NFS shares. It is definitely a kernel issue as my testing has been included a dozen different distributions.

    With any disto using a .32 kernel the command
    "mount ip:/NFS/server/share /mnt/localdir"
    works automatically, without fuss. The same command used in a distro with any kernel from .33 afterward returns the error
    "mount:nfs timed out, giving up"

    When you modify the command, like this
    "mount -o proto=tcp ip:/NFS/server/share /mnt/localdir"
    then the command works correctly.

    I would like to know:
    *What is the specific change between .32 and .33 that causes this change in the behavior of the mount command, so that UDP is now the automatic protocol instead of TCP?
    *Why was it changed?
    *Where/How do I make a change in the settings of Ubuntu or other systems so that they permanently revert back to a default of TCP?
    *Where/How do I make a change in the settings of an NFS server, I am using NAS4Free/FreeNAS/BSD, to make the shares either UDP or TCP?

    I have been working on this for quite awhile and your help is greatly appreciated.

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,574
    Did you reinstall the nfs-utils package? You may need to update that as well as the kernel in this case.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined!
    Join Date
    Jun 2012
    Posts
    5
    Quote Originally Posted by Rubberman View Post
    Did you reinstall the nfs-utils package? You may need to update that as well as the kernel in this case.
    I did not reinstall the nfs-utils, because What I did do was use clean LiveCD versions of various distros.

    Your question poses the additional question: Is the change actually in kernel 2.6.33 or is it in nfs-common or nfs-utils? It would make sense that the problem would be in the nfs utilities. So, either ALL of the distros use the same nfs-utils for the 2.6.32 (ver.A) AND the same nfs-utils for 2.6.33 (ver.B) or the problem is in the kernel. Any help on being able to locate the information on the version change log for nfs-common and nfs-utils would be very helpful. Thank you.

    Extra thank you for being the only person to respond to my inquiries into this matter in many many months.

  4. #4
    Just Joined!
    Join Date
    Jun 2012
    Posts
    5
    Here is a link to the thread where I have been tracking my efforts on this issue.
    >> I am not yet allowed to post a link.
    So, if you run a search on ( nfs mount timed out giving up FreeNAS ) you should find my thread.

  5. #5
    Just Joined!
    Join Date
    Jun 2012
    Posts
    5
    I have added a link to this thread in that thread, so it should be an easy find. Thanks again.

  6. #6
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,574
    From the Red Hat NFS documentation:
    Code:
    12.1. How It Works
    
    Currently, there are three versions of NFS. NFS version 2 (NFSv2) is older and is widely supported. NFS version 3 (NFSv3) supports safe asynchronous writes and a more robust error handling than NFSv2; it also supports 64-bit file sizes and offsets, allowing clients to access more than 2Gb of file data.
    
    NFS version 4 (NFSv4) works through firewalls and on the Internet, no longer requires an rpcbind service, supports ACLs, and utilizes stateful operations. Red Hat Enterprise Linux 6 supports NFSv2, NFSv3, and NFSv4 clients. When mounting a file system via NFS, Red Hat Enterprise Linux uses NFSv4 by default, if the server supports it.
    
    All versions of NFS can use Transmission Control Protocol (TCP) running over an IP network, with NFSv4 requiring it. NFSv2 and NFSv3 can use the User Datagram Protocol (UDP) running over an IP network to provide a stateless network connection between the client and server.
    
    When using NFSv2 or NFSv3 with UDP, the stateless UDP connection (under normal conditions) has less protocol overhead than TCP. This can translate into better performance on very clean, non-congested networks. However, because UDP is stateless, if the server goes down unexpectedly, UDP clients continue to saturate the network with requests for the server. In addition, when a frame is lost with UDP, the entire RPC request must be retransmitted; with TCP, only the lost frame needs to be resent. For these reasons, TCP is the preferred protocol when connecting to an NFS server.
    
    The mounting and locking protocols have been incorporated into the NFSv4 protocol. The server also listens on the well-known TCP port 2049. As such, NFSv4 does not need to interact with rpcbind[2], lockd, and rpc.statd daemons. The rpc.mountd daemon is still required on the NFS server to set up the exports, but is not involved in any over-the-wire operations.
    So, if you are mounting from server running NFSv4 to a client that uses NFSv3 or earlier, you will need the options you show in order to force it to use the TCP instead of UDP protocol.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  7. #7
    Just Joined!
    Join Date
    Jun 2012
    Posts
    5
    Thank you for the info I will test it out ASAP and post an update.

    Quote Originally Posted by Rubberman View Post
    From the Red Hat NFS documentation:
    Code:
    12.1. How It Works
    
    Currently, there are three versions of NFS. NFS version 2 (NFSv2) is older and is widely supported. NFS version 3 (NFSv3) supports safe asynchronous writes and a more robust error handling than NFSv2; it also supports 64-bit file sizes and offsets, allowing clients to access more than 2Gb of file data.
    
    NFS version 4 (NFSv4) works through firewalls and on the Internet, no longer requires an rpcbind service, supports ACLs, and utilizes stateful operations. Red Hat Enterprise Linux 6 supports NFSv2, NFSv3, and NFSv4 clients. When mounting a file system via NFS, Red Hat Enterprise Linux uses NFSv4 by default, if the server supports it.
    
    All versions of NFS can use Transmission Control Protocol (TCP) running over an IP network, with NFSv4 requiring it. NFSv2 and NFSv3 can use the User Datagram Protocol (UDP) running over an IP network to provide a stateless network connection between the client and server.
    
    When using NFSv2 or NFSv3 with UDP, the stateless UDP connection (under normal conditions) has less protocol overhead than TCP. This can translate into better performance on very clean, non-congested networks. However, because UDP is stateless, if the server goes down unexpectedly, UDP clients continue to saturate the network with requests for the server. In addition, when a frame is lost with UDP, the entire RPC request must be retransmitted; with TCP, only the lost frame needs to be resent. For these reasons, TCP is the preferred protocol when connecting to an NFS server.
    
    The mounting and locking protocols have been incorporated into the NFSv4 protocol. The server also listens on the well-known TCP port 2049. As such, NFSv4 does not need to interact with rpcbind[2], lockd, and rpc.statd daemons. The rpc.mountd daemon is still required on the NFS server to set up the exports, but is not involved in any over-the-wire operations.
    So, if you are mounting from server running NFSv4 to a client that uses NFSv3 or earlier, you will need the options you show in order to force it to use the TCP instead of UDP protocol.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •