On Thu, Sep 05, 2013 at 11:34:49PM +0200, Emmanuel Florac wrote: > Le Thu, 5 Sep 2013 16:45:36 -0400 vous écriviez: > > > Well, it sounds like you have a reproducer that shouldn't be *too* > > huge (the test where it freezes after stat'ing 25 files). > > > > What do you see on the network in that case? > > I didn't look yet what's actually happening, out of the drop in network > throughput. > > > Are you literally using just tcpdump? Wireshark will give more > > (and easier to read) information. > > I didn't install tcpdump yet, but isn't wireshark with a GUI? I can't > run anything with a GUI, this is a remote site behind several ssh > portals. So I should run tshark, then get my hands on the results to > analyze them with wireshark on my PC. Will try that. Right, I just do "tcpdump -s0 -wtmp.pcap -i<interface>" and then run wireshark on tmp.pcap. > > Does the server stop responding at some point, or reply with an error? > > No response. I don't know if the server actually stops responding or if > something's wrong on the client side. Unfortunately I don't have > access to any other NFS client on this network, out of this VM and the > server itself. When rebooting the VM reconnects to the server all by > itself, so the server most probably is OK at all times. > > > Or does the getattr reply on the problem file look odd in any way? > > Not odd at all; it just stops after a particular file, though this file > and the following files can be accessed OK before I run the failing > test. I was asking about the on-the-wire errors and getattr replies here, not the application system calls. --b. -- 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
