What happened to NFS on fedora 11?

[Craig White]

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.