On Mon, 12 Aug 2013 at 12:29, J. Bruce Fields wrote: > It might be interesting to get a network trace (something like tcpdump > -s0 -wtmp.pcap; then "wireshark tmp.pcap" and look at the "cookie" > fields in the readdir calls and replies.
I've created #60737[0] to track this issue upstream and attached a pcap to the bug, obtained while running "find <dir> -ls" on the client. But I fail to look at the right details in tcpdump/wireshare, I don't see any cookie information... > You could also just run "strace -egetdents64 -v ls" on the server on > the exported filesystem, in a problem directory, and see if the offsets > are unique. strace returned nothing for "getdents64", only "getdents". My test filesystems are 256 MB in size, maybe this is too small for getdents64 to be used? All the calls to "getdents" however return unique offsets, if I did this right: $ strace -egetdents -v ls /mnt/disk_jfs/usr/share/terminfo/q 2>&1 | egrep -o "d_off=[0-9]*" | sort When running "ls" (even w/o "-l") on the client on that NFS share, this "readdir loop" message is printed. HTH, Christian. [0] https://bugzilla.kernel.org/show_bug.cgi?id=60737 ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Jfs-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jfs-discussion
