Re: 3.0+ NFS issues

[Michael Tokarev]

On 31.05.2012 16:59, Myklebust, Trond wrote:
[]
> That is tcpdump trying to interpret your NFSv4 trace as NFSv2/v3.

Oh.

> Can you either please use wireshark to provide a full text dump (using
> something like 'tshark -V -O nfs,rpc'), or just send us the binary
> tcpdump output using 'tcpdump -w /tmp/foo -s 90000'?

I started tcpdump:

 tcpdump -npvi br0 -s 0 host 192.168.88.4 and \( proto ICMP or port 2049 \) -w nfsdump

on the client (192.168.88.2).  Next I mounted a directory on the client,
and started reading (tar'ing) a directory into /dev/null.  It captured a
few stalls.  Tcpdump shows number of packets it got, the stalls are at
packet counts 58090, 97069 and 97071.  I cancelled the capture after that.

The resulting file is available at http://www.corpit.ru/mjt/tmp/nfsdump.xz ,
it is 220Mb uncompressed and 1.3Mb compressed.  The source files are
10 files of 1Gb each, all made by using `truncate' utility, so does not
take place on disk at all.  This also makes it obvious that the issue
does not depend on the speed of disk on the server (since in this case,
the server disk isn't even in use).

What I noticed is: with default 8 NFSD threads, it takes quite a bit
longer to hit this issue, but it still happens.  The capture was
done using 2 threads.

>>>> Can at least the client be made interruptible?  Mounting with
>>>> -o intr,soft makes no visible difference...
>>
>> please? :)
> 
> It already is interruptible: try 'kill -9' or any other fatal signal.

Oh.  Indeed, I can kill it from another terminal using -9.  That is
great already!

Thank you!

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