Date: Fri, 5 Apr 2002 23:19:39 -0800 (PST) From: Kip Macy <kmacy@netapp.com> To: Aditya <aditya@grot.org> Cc: freebsd-stable@freebsd.org Subject: Re: NFS hang with fxp and Network Appliance fileserver Message-ID: <Pine.GSO.4.10.10204052259090.20180-100000@orbit> In-Reply-To: <20020406055443.GA82908@mighty.grot.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. I'm speculating that the difference in behaviours is an artifact of the hardware and not the driver. The 82559 may be able to feed ip_input fragments faster than the 21x4x. There was a thread on -hackers this week about problems caused by UDP fragmentation (only in that case it was a panic). If you're interested the subject was "Fatal trap 12: page fault while in kernel mode". > 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). > I'm glad that that fixed the problem. If this is not already documented on this end, I will try to get it updated to reflect this. I think TCP should be the default. I agree with Kirk that the designers of NFSv2 took statelessness a little too seriously when they used UDP. The fact of the matter is you still have state, but you move it from the network stack into the client and the server. The end effect being that you reproduce parts of TCP badly. -Kip 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?Pine.GSO.4.10.10204052259090.20180-100000>