On Thu, 1 Sep 2005 16:53:11 +0200
Manuel Bouyer <bouyer@antioche.eu.org> wrote:

> 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.

Seems you're right. On NFS server we have installed extremely cheap
Realtek 8139 based NICs :-/

With 8192 sized data I see periodically burst speedups, and the rest
time my NFS client is locked. With 1024 I haven't obscure this kind of
problems.

But with default settings (32k?) my clients just infinitively locked
for hours (no CPU load, no network traffic). Is this a normal behaviour,
even with such bad NICs as 8139?

--
Mishka.