Weird NFS problems

Jon Dama jd at ugcs.caltech.edu
Fri May 27 01:52:12 PDT 2005


Try switching to TCP NFS.

a 100MBit interface cannot keep up with a 1GBit interface in a bridge
configuration.  Therefore, in the long run, at full-bore you'd expect to
drop 9 out of every 10 ethernet frames.

MTU is 1500 therefore 1K works (it fits in one frame), 2K doesn't (your
NFS transactions are split across frames, one of which will almost
certainly be dropped, it's UDP so the loss of one frame invalidates the
whole transaction).

This is the same reason you can't use UDP with a block size greater than
MTU to use NFS over your DSL or some such arrangement.

Incidentially, this has nothing to do with FreeBSD.  So if using TCP
mounts solves your problem, don't expect Solaris NFS to magically make the
UDP case work...

-Jon

On Fri, 27 May 2005, Don Lewis wrote:

> On 26 May, Skylar Thompson wrote:
> > I'm having some problems with NFS serving on a FreeBSD 5.4-RELEASE
> > machine. The FreeBSD machine is the NFS/NIS server for a group of four
> > Linux clusters. The network archictecture looks like this:
> >
> > 234/24                                                   234/24
> > Cluster 1 ---                    |--------------- Cluster 3
> >                    | ---------------
> >             em0|  File server | fxp0
> >                    |  --------------
> > Cluster 2 ---                    |--------------- Cluster 4
> > 234/24                                                    230/24
> >
> >
> > em0 and fxp0 are bridged, and em0 has a 234/24 IP address while fxp0 is
> > just in promiscuous mode. 234/24 is an 802.1q VLAN on the fxp0 side of
> > the server, so packets are untagged at the switch just before fxp0, and
> > are forwarded to em0 through the bridge.
> >
> > The problem manifests itself in large UDP NFS requests from Clusters 3
> > and 4. The export can be mounted fine from both those clusters, and
> > small transfers such as with ls work fine, but the moment any serious
> > data transfer starts, the entire mount just hangs. Running ethereal on
> > the file server shows a a lot of fragmented packets, and RPC
> > retransmissions on just a single request. Reducing the read and write
> > NFS buffers on the Linux clients to 1kB from the default of 4kB solves
> > the issue, but kills the transfer rate. The moment I go to 2kB, the
> > problem reappearss. Clusters 1 and 2 use the default of 4kB buffers, and
> > have no problems communicating to em0.
> >
> > Poking through the list archives, I ran across this message
> > (http://lists.freebsd.org/pipermail/freebsd-stable/2003-May/001007.html)
> > that reveals a bug in the fxp(4) driver in 4-RELEASE that incorrectly
> > detects the capabilities of the NIC. Is this still an issue in
> > 5-RELEASE, or am I looking at a different problem? Any ideas on how I
> > can get the NFS buffers up to a reasonable level?
>
> That problem was fixed quite some time ago.
>
> Which transfer direction fails?
> 	Client writing to server
> 	Client reading from server
> 	Both?
>
> Do you see all the fragments in the retransmitted request?
>
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>


More information about the freebsd-questions mailing list