On Thu, Sep 01, 2005 at 05:37:52PM +0300, Mike M. Volokhov wrote:
> On Tue, 23 Aug 2005 18:38:45 +0200
> Manuel Bouyer <bouyer@antioche.eu.org> wrote:
> 
> > On Tue, Aug 23, 2005 at 05:03:19PM +0300, Mike M. Volokhov wrote:
> > > > > 
> > > > > Or it has been already fixed?
> > > > 
> > > > Some of these PRs may be fixed. 
> > > 
> > > Fixed or closed? Any chances to get nfsrcvlk hangs off?
> > 
> > Not closed as far as I can see, but I've no NFS problems on my systems ...
> 
> What is options you are using for NFS mounts? Simply
> 
> 	mount_nfs remotehost:/exported/tree /mnt/point

Yes, this and also the default options for amd.

> 
> ... will cause mentioned problems for me.
> 
> After rereading once more all that PRs I've set read/write data sizes
> to 1024 (less than Ethernet MTU I believe) and this now works for me
> very well. Using 8192 for these parametres will produce much less
> errors (no errors at fact after testing for six days or so), but file
> operations with big data works much slower than as with 1024 -r/-w.

You mean, with 8192 it's much slower than with 1024 ? Then it looks
like an ethernet problem, where something reliably drop packets when
too much full ethernet frames are sent in a row. This is something that
can be reproduced with adapter with a too small receive buffer, for example.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--