On Wed, 2009-10-07 at 11:33 -0600, Frank Cox wrote: > On Wed, 07 Oct 2009 10:24:04 -0700 > Craig White wrote: > > > is there some particular advantage to using udp instead of tcp protocol? > > I only use nfs on a LAN and have always used the tcp. > > Whatever it defaulted to has always worked for me up until yesterday's update > to nfs-utils. Whether it was using udp or tcp has never really been a concern > to me. > > Again, it still seems to work fine when mounting a Centos 5 fileserver. It > failed with my dedicated Intel fileserver until I added the "-o proto=udp" to > the mount line. (I guess I'll have to start looking into how to get that > parameter into my /etc/fstab to prevent that from happening again the next > time this computer gets rebooted.) > > Here is my note regarding how to make nfs work. I have followed these > instructions on many Fedora and Centos machines and haven't seen it fail before: ---- I understand the firewall setup and that is sort of non-responsive to the question I am asking. The default protocol for NFS is tcp. You are overriding the default by specifying udp protocol and I am wondering if that offers a particular advantage. >From 'man nfs' TRANSPORT METHODS NFS clients send requests to NFS servers via Remote Procedure Calls, or RPCs. The RPC client discovers remote service endpoints automatically, handles per-request authentication, adjusts request parameters for different byte endianness on client and server, and retransmits requests that may have been lost by the network or server. RPC requests and replies flow over a network transport. In most cases, the mount(8) command, NFS client, and NFS server can automatically negotiate proper transport and data transfer size settings for a mount point. In some cases, however, it pays to specify these settings explicitly using mount options. Traditionally, NFS clients used the UDP transport exclusively for transmitting requests to servers. Though its implementation is simple, NFS over UDP has many limitations that prevent smooth operation and good performance in some common deployment environments. Even an insignificant packet loss rate results in the loss of whole NFS requests; as such, retransmit timeouts are usually in the subsecond range to allow clients to recover quickly from dropped requests, but this can result in extraneous network traffic and server load. However, UDP can be quite effective in specialized settings where the network’s MTU is large relative to NFS’s data transfer size (such as network environments that enable jumbo Ethernet frames). In such environments, trimming the rsize and wsize settings so that each NFS read or write request fits in just a few network frames (or even in a single frame) is advised. This reduces the probability that the loss of a single MTU-sized network frame results in the loss of an entire large read or write request. TCP is the default transport protocol used for all modern NFS implementations. It performs well in almost every conceivable network environment and provides excellent guarantees against data corruption caused by network unreliability. TCP is often a requirement for mounting a server through a network firewall. Under normal circumstances, networks drop packets much more frequently than NFS servers drop requests. As such, an aggressive retransmit timeout setting for NFS over TCP is unnecessary. Typical timeout settings for NFS over TCP are between one and ten minutes. After the client exhausts its retransmits (the value of the retrans mount option), it assumes a network partition has occurred, and attempts to reconnect to the server on a fresh socket. Since TCP itself makes network data transfer reliable, rsize and wsize can safely be allowed to default to the largest values supported by both client and server, independent of the network’s MTU size. Craig -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
