Date: Fri, 27 May 2005 15:47:08 -0700 (PDT) From: Jon Dama <jd@ugcs.caltech.edu> To: Don Lewis <truckman@freebsd.org> Cc: freebsd-stable@freebsd.org, skylar@cs.earlham.edu, freebsd-questions@freebsd.org Subject: Re: Weird NFS problems Message-ID: <Pine.LNX.4.53.0505271542200.30808@heave.ugcs.caltech.edu> In-Reply-To: <200505270711.j4R7BTMf078204@gw.catspoiler.org> References: <200505270711.j4R7BTMf078204@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Oh, something else to try: I checked through my notes and discovered that I had gotten UDP to work in a similar configuration before. What I did was bind the IP address to fxp0 instead of em0. By doing this, the kernel seems to send the data at a pace suitable for the slow interface. -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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.53.0505271542200.30808>