Skip site navigation (1)Skip section navigation (2)
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>