On 03/02/12 10:05 AM, John R Pierce wrote: > is anyone familiar with this inode64 stuff and NFS in EL6.2 ? still having show stopping issues with XFS, inode64, and NFS. the fsid=uuid option suggested by some googling doesn't seem to work at all for Solaris clients... http://xfs.org/index.php/XFS_FAQ#Q:_Why_doesn.27t_NFS-exporting_subdirectories_of_inode64-mounted_filesystem_work.3F On nfs server... [root at server data]# mount /dev/sda1 on /data type xfs (rw,inode64) [root at server data]# blkid /dev/sda1: UUID="d1bff6f7-9887-44bb-be57-d8628831cf40" TYPE="xfs" [root at server data]# cat /etc/exports /data/oni64 *(rw,async,fsid=d1bff6f7-9887-44bb-be57-d8628831cf40,no_subtree_check) [root at server data]# uname -a Linux server 2.6.32-220.4.2.el6.x86_64 #1 SMP Tue Feb 14 04:00:16 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux With the option fsid=uuid we could not mount nfs on client. root at client1 # mount -F nfs server:/data/oni64 /backups nfs mount: tkddo-clf08:/data/oni64: No such file or directory root at client1 # mount -F nfs -o vers=4 server:/data/oni64 /backups nfs mount: tkddo-clf08:/data/oni64: No such file or directory root at client1 # mount -F nfs -o vers=3 server:/data/oni64 /backups nfs mount: mount: /backups: Stale NFS file handle root at client1 # uname -a SunOS client1 5.10 Generic_138889-08 i86pc i386 i86pc (this last is the same error we got without the fsid=, when using inode64). It *does* seem to work if the export uses fsid=# where # is an arbitrary integer, unique for each export, but thats something of a messy workaround. -- john r pierce N 37, W 122 santa cruz ca mid-left coast