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-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
