> On Nov 15, 2017, at 3:14 AM, Anders Ossowicki <and@xxxxxx> wrote: > > On 14 November 2017 at 19:11, Anders Ossowicki <and@xxxxxx> wrote: >> On 14 November 2017 at 18:12, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >>> But since you already have such inodes, NFS clients will >>> have to convert the numbers on the fly. You can use a boot >>> parameter on your clients: >>> >>> nfs.enable_ino64=0 >>> >>> According to comments in fs/nfs/inode.c . >> >> Thanks for the suggestion. >> >> I looked at nfs.enable_ino64 while tracking down this issue, but it >> looked like a client-side option to me, and the error happens in the >> nfsd code. I'll give a shot tomorrow. > > No dice, unfortunately: > > aowi@otto ~ $ dmesg|grep 'Kernel command line' > [ 0.000000] Kernel command line: > BOOT_IMAGE=/boot/vmlinuz-3.19.0-77-generic > root=UUID=601cb526-8e11-4565-a5ed-0be619db7a5e ro quiet splash > nfs.enable_ino64=0 vt.handoff=7 > aowi@otto ~ $ sudo mount -t nfs svin:/z/svin/aowitest/foo /mnt > aowi@otto ~ $ ls /mnt > ls: cannot open directory /mnt: Stale file handle Does this happen with a recent kernel on the client? And, it would help if you can capture and post a raw tcpdump of this interaction so we can see all the details of the conversation. Start the tcpdump before "sudo mount", and save the raw bytes with "-w /tmp/sniffer.pcap". gzip and post it here. What happens if you mount svin:/ and walk down the server's namespace into /z/svin/aowitest/foo ? -- Chuck Lever -- 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
