> On Nov 14, 2017, at 11:49 AM, Anders Ossowicki <and@xxxxxx> wrote: > > If I export a directory that has an inode number > 2^32, the > client-side mount succeeds, but any subsequent action gives a stale > error. > > $ sudo mount -t nfs svin:/z/svin/aowitest/foo /mnt > $ ls /mnt > ls: cannot access /mnt: Stale file handle > > The underlying filesystem is XFS. The exported directory is not the > root of that filesystem (hence the large inode number). > > Server-side debug captures this: > > nfsd_dispatch: vers 4 proc 1 > nfsv4 compound op #1/3: 22 (OP_PUTFH) > svc: server ffff897ecc64e000, pool 0, transport ffff897eca7fd000, inuse=3 > nfsd: fh_verify(28: 00070001 400000c0 00000001 0f52f60a 63438e31 ab541493) > nfsv4 compound op ffff897ecb6e9080 opcnt 3 #1: 22: status 70 > nfsv4 compound returned 70 > > I have worked around this by rmdir/mkdir'ing until I got an inode < 2^32. > > This is only an issue with the inode of the / of the NFS exported path. > > Have I overlooked a flag somewhere? Is this just impossible to fix > without breaking the world? A fresh XFS file system can be mounted with the "inode32" mount option (on the server) to prevent the creation of inodes with numbers that cannot be represented in 32 bits. 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 . -- 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
