Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Feb 2005 10:44:56 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Daniel Eriksson <daniel_k_eriksson@telia.com>
Cc:        'Kris Kennaway' <kris@obsecurity.org>
Subject:   RE: Processes stuck in nfsreq
Message-ID:  <Pine.NEB.3.96L.1050204104002.6650R-100000@fledge.watson.org>
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAAYRXr%2B9Ojcky9rvrwFRzIlQEAAAAA@telia.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Fri, 4 Feb 2005, Daniel Eriksson wrote:

> I wrote:
> 
> > I only switched off net.isr yesterday, so I still don't
> > know for sure if it has cured the problem, but I've moved 
> > well over 1000 files since then without any corruption
> > issues.
> 
> During the night a number of files being moved from the client to the
> server have ended up corrupted (shorter than original, with a size
> evenly dividable by 8192), so turning net.isr off wasn't the solution. 

Was the corruption of the same sort in both cases?  While I wouldn't
preclude a bug relating to increased parallelism in the socket/network
stack code, page-aligned and neatly rounded sizes, etc, are suggestive of
an NFS-side problem.  BTW, have you tried watching the protocol stats with
netstat -s to see if you're seeing corrupted packets at the lower layers
in processing?  It looks like the NFS client may not keep stats for all of
its packet parsing problem spots, unfortunately, so that makes it a bit
harder to figure out if/where problems are occuring in NFS packet
handling.

Robert N M Watson



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050204104002.6650R-100000>