On Mon, Aug 12, 2013 at 01:29:15AM -0700, Christian Kujau wrote: > Sorry for the noise, here's another oddity, same setup (client & server > running 3.11-rc5): > > $ find /mnt/nfs/usr/share/ -name getopt.awk -ls > 25072 4 -rw-r--r-- 1 root root 2237 Mar 16 04:46 > /mnt/nfs/usr/share/awk/getopt.awk > 25072 4 -rw-r--r-- 1 root root 2237 Mar 16 04:46 > /mnt/nfs/usr/share/awk/getopt.awk > 25072 4 -rw-r--r-- 1 root root 2237 Mar 16 04:46 > /mnt/nfs/usr/share/awk/getopt.awk > 25072 4 -rw-r--r-- 1 root root 2237 Mar 16 04:46 > /mnt/nfs/usr/share/awk/getopt.awk > 25072 4 -rw-r--r-- 1 root root 2237 Mar 16 04:46 > /mnt/nfs/usr/share/awk/getopt.awk > 25072 4 -rw-r--r-- 1 root root 2237 Mar 16 04:46 > /mnt/nfs/usr/share/awk/getopt.awk > 25072 4 -rw-r--r-- 1 root root 2237 Mar 16 04:46 > /mnt/nfs/usr/share/awk/getopt.awk > 25072 4 -rw-r--r-- 1 root root 2237 Mar 16 04:46 > /mnt/nfs/usr/share/awk/getopt.awk > 25072 4 -rw-r--r-- 1 root root 2237 Mar 16 04:46 > /mnt/nfs/usr/share/awk/getopt.awk > 25072 4 -rw-r--r-- 1 root root 2237 Mar 16 04:46 > /mnt/nfs/usr/share/awk/getopt.awk > > It's the same file, but gets reported 10 times! Hence the error when > trying to tar(1) the directory: > > $ tar -cf - /mnt/nfs/usr/share/awk/ > /dev/null > tar: Removing leading `/' from member names > tar: /mnt/nfs/usr/share/awk/: Cannot savedir: Too many levels of symbolic > links > tar: Exiting with failure status due to previous errors > > On the server: > > $ find /mnt/disk/usr/share/ -name getopt.awk -ls > 25072 4 -rw-r--r-- 1 root root 2237 Mar 16 04:46 > /mnt/disk/usr/share/awk/getopt.awk > > So, is "JFS && NFS" really br0ken and nobody noticed?
It does sound like a jfs bug, and I don't know if anyone tests nfs exports of jfs regularly. 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. The server shouldn't return the same one twice on one read through the directory. And when the client uses a cookie it should get the next entries, not already-returned entries.) 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. --b. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130812162924.gb2...@fieldses.org