Re: 2.6 must-fix list, v2

Dave Jones (davej@codemonkey.org.uk)
Tue, 13 May 2003 17:09:48 +0100


On Tue, May 13, 2003 at 06:02:31PM +0200, Trond Myklebust wrote:
> >>>>> " " == Dave Jones <davej@codemonkey.org.uk> writes:
>
> > I had thought that the 2.4 server survived this. I just did a
> > test with a 2.4.21pre7 kernel and found the same behaviour, so
> > this isn't a regression, just something thats not very nice.
>
> Then I'm confused as to what you are saying. Are we talking about a
> full NFS server crash or just a temporary 'server not responding'
> situation?

ok, I've now established that kernel version is irrelevant.
the server keeps on ticking, no problems.
the client (which runs fsx on an nfs mount) fails.

Two failure modes.
1, fsx dies with bus error. This is infrequent (seen it once)
The most common failure mode is..
2, fsx fails. Different failure each time. Usually takes a minute
to trigger.

(16:30:08:root@tetrachloride:mesh)# ~/fsx voon
truncating to largest ever: 0x13e76
truncating to largest ever: 0x2e52c
truncating to largest ever: 0x3c2c2
truncating to largest ever: 0x3f15f
truncating to largest ever: 0x3fcb9
truncating to largest ever: 0x3fe96
truncating to largest ever: 0x3ff9d
Size error: expected 0x2126e stat 0x21546 seek 0x21546
LOG DUMP (7665 total operations):
7666(242 mod 256): READ 0x1b20b thru 0x215b7 (0x63ad bytes)
7667(243 mod 256): MAPWRITE 0x247ef thru 0x26e9f (0x26b1 bytes)
7668(244 mod 256): WRITE 0x26fc thru 0x11d2f (0xf634 bytes)
7669(245 mod 256): TRUNCATE DOWN from 0x3b18c to 0x1cbfc
7670(246 mod 256): MAPREAD 0x7f92 thru 0xd860 (0x58cf byte
....
etc...

> Does NFS over TCP fix it, for instance?

Untested, I can give that a try.

Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/