Subject: Re: NFS problems
To: <>
From: David Laight <david@l8s.co.uk>
List: tech-kern
Date: 07/23/2002 17:36:03
On Tue, Jul 23, 2002 at 11:53:15AM -0400, rick@snowhite.cis.uoguelph.ca wrote:
> Well, I'm not directly involved in the NetBSD code, but here are a few
> random comments that might be useful:
> 
> - If you have too large a blocksize when using NFS over UDP, you'll
>   see "IP Fragments dropped due to timeout" when you do "netstat -s".
>   (These indicate that fragments of the large UPD datagram aren't
>    making it through the network interconnect and cause serious
>    performance degredation. The "fix" is to either reduce the read/write
>    data size or switch to TCP. See "man mount_nfs" to find out how to
>    do either of these.)

Except that it is likely that the same number of packets will get lost
using TCP - just the recovery code works slightly faster.....
> 
> - The NFS code is much more sensitive to buffer cache race conditions
>   than local file systems. Among other reasons is the fact that local
>   file systems almost never take several seconds to do an I/O operation.

Except on compact flash - that can really confuse anything trying to
do round trip time measurements.  Writes are fast until you have
to do a sector erase - then it takes about a second.

>   (Mounting a really slow NFS server, like one with debugging printfs
>    turned on is the best way to "find" these. Been there, have the T-shirt.

I remember looking at a LAN trace of NFS traffic where the server was
a rather slow PC (66MHz 486?) with IDE disks (probably pio).  The
client was probably an sbus sparc box.  In any case writeing to a
large file on the server caused the client to clear several 8k data
blocks from its buffer cache at the same time.   The burst of traffic
overwhelmed the poor little server!  Requests were being retransmited
before the response to the previous request was transmitted, I suspect
that the 'staircase' disk write algorithm caused some of the NFS
server tasks to get delayed even further (remember the server shouldn't
return until the data is ON the disk).
Decoding that LAN trace was hell!

	David

-- 
David Laight: david@l8s.co.uk