Date: Fri, 5 Apr 2002 21:54:43 -0800 From: Aditya <aditya@grot.org> To: Kip Macy <kmacy@netapp.com> Cc: freebsd-stable@freebsd.org Subject: Re: NFS hang with fxp and Network Appliance fileserver Message-ID: <20020406055443.GA82908@mighty.grot.org> In-Reply-To: <Pine.GSO.4.10.10204052108540.20180-100000@orbit> References: <Pine.GSO.4.10.10204052108540.20180-100000@orbit>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 05, 2002 at 09:15:44PM -0800, Kip Macy wrote: > This sounds like it could be a flow control problem caused by NFS v2's abuse > of fragmentation/reassembly when using large UDP packets. I did see a bunch of fragments from the filer when I briefly turned on tcpdump on that interface whilst it hung. > What are your mount options? Have you tried v3 with tcp? I believe mount_nfs under 4-STABLE defaults to v3, udp and netstat bears out the udp part: udp4 0 0 192.168.1.37.925 192.168.1.2.2049 here are my current options: -r=1024,ro,intr,nodev,nosuid,noauto I've tried it with and without intr and dumbtimer (there was a post in the archive that said that turning off the dynamic retransmit timeout estimator would help for high-performance UDP mounts) but not tcp. As I mentioned, it works fine on a machine with a de-based NIC without -r=1024. > Many of our machines in the labs have 8255x based cards and none of them see > this problem. That is not to say that your problem is not real, just that there > is some key difference in configuration that we need to isolate. Okay, I've forced nfs v3 and tcp like this: -3,tcp,ro,intr,nodev,nosuid,noauto and seems to work fine too...so the problem is with fragments on v2 and v3 UDP mounts (I tested both and they had the same "hanging" behaviour). Adi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020406055443.GA82908>