Date: Thu, 28 Aug 2003 09:01:49 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-current@freebsd.org Subject: Re: nfs tranfers hang in state getblck or nfsread Message-ID: <Pine.NEB.3.96L.1030828085851.34202D-100000@fledge.watson.org> In-Reply-To: <3F4DC1AC.B551316C@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 28 Aug 2003, Terry Lambert wrote: > Pawel Worach wrote: > [ ... subject ... ] > > > This only seem to happen for nfs over tcp. > > That's strange; most of the problems I've ever seen are from using UDP, > large read/write sizes, and then droping one packet out of a bunch of > frags caused by the MTU being much smaller than the read/write size > (misguided attempt to emulate a fixed window size and get more packets > in flight, without using TCP to do it). I'm wondering if large block sizes are causing the TCP socket buffer to fill, resulting in some bad behavior on the client or server. Most probably the server, given that the scenarios in question seem to involve reading. Another intereseting test case might be to use dd with various block sizes to read from a file on the server and see whether a particular size triggers the problem, or if it's less deterministic (and more likely a race condition of some sort). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030828085851.34202D-100000>