This commit was generated by cvs2svn to track changes on a CVS vendor

[unix-history] / contrib / FAQ / OTHER-FAQS / NFS

FreeBSD and NFS [for a FAQ]

Certain Ethernet adapters for ISA PC systems have limitations which
can lead to serious network problems, particularly with NFS.  This
difficulty is not specific to FreeBSD, but FreeBSD systems are affected
by it.

The problem nearly always occurs when (FreeBSD) PC systems are networked
with high-performance workstations, such as those made by Silicon Graphics,
Inc., and Sun Microsystems, Inc.  The NFS mount will work fine, and some
operations may succeed, but suddenly the server will seem to become
unresponsive to the client, even though requests to and from other systems
continue to be processed.  This happens to the client system, whether the
client is the FreeBSD system or the workstation.  On many systems, there is
no way to shut down the client gracefully once this problem has manifested
itself.  The only solution is often to reset the client, because the NFS
situation cannot be resolved.

Though the "correct" solution is to get a higher performance and capacity
Ethernet adapter for the FreeBSD system, there is a simple workaround that
will allow satisfactory operation.  If the FreeBSD system is the SERVER,
include the option "wsize=1024" on the mount from the client.  If the
FreeBSD system is the CLIENT, then mount the NFS file system with the
option "rsize=1024".  These options may be specified using the fourth
field of the fstab entry on the client for automatic mounts, or by using
the "-o" parameter of the mount command for manual mounts.

In the following examples, "fastws" is the host (interface) name of a
high-performance workstation, and "freebox" is the host (interface) name of
a FreeBSD system with a lower-performance Ethernet adapter.  Also,
"/sharedfs" will be the exported NFS filesystem (see "man exports"), and
"/project" will be the mount point on the client for the exported file
system.  In all cases, note that additional options, such as "hard" or
"soft" and "bg" may be desireable in your application.

Examples for the FreeBSD system ("freebox") as the client:
    in /etc/fstab on freebox:
fastws:/sharedfs /project nfs rw,rsize=1024 0 0
    as a manual mount command on freebox:
mount -t nfs -o rsize=1024 fastws:/sharedfs /project

Examples for the FreeBSD system as the server:
    in /etc/fstab on fastws:
freebox:/sharedfs /project nfs rw,wsize=1024 0 0
    as a manual mount command on fastws:
mount -t nfs -o wsize=1024 freebox:/sharedfs /project

Nearly any 16-bit Ethernet adapter will allow operation without the above
restrictions on the read or write size.

For anyone who cares, here is what happens when the failure occurs, which
also explains why it is unrecoverable.  NFS typically works with a "block"
size of 8k (though it may do fragments of smaller sizes).  Since the maximum
Ethernet packet is around 1500 bytes, the NFS "block" gets split into
multiple Ethernet packets, even though it is still a single unit to the
upper-level code, and must be received, assembled, and ACKNOWLEDGED as a
unit.  The high-performance workstations can pump out the packets which
comprise the NFS unit one right after the other, just as close together as
the standard allows.  On the smaller, lower capacity cards, the later
packets overrun the earlier packets of the same unit before they can be
transferred to the host and the unit as a whole cannot be reconstructed or
acknowledged.  As a result, the workstation will time out and try again,
but it will try again with the entire 8K unit, and the process will be
repeated, ad infinitum.

By keeping the unit size below the Ethernet packet size limitation, we
ensure that any complete Ethernet packet received can be acknowledged
individually, avoiding the deadlock situation.

Overruns may still occur when a high-performance workstations is slamming
data out to a PC system, but with the better cards, such overruns are
not guarranteed on NFS "units".  When an overrun occurs, the units affected
will be retransmitted, and there will be a fair chance that they will be
received, assembled, and acknowledged.
-- 
		   John Lind, Starfire Consulting Services
E-mail: john@starfire.MN.ORG		USnail: PO Box 17247, Mpls MN  55417