On Mar 6, 2012, at 4:36 PM, John R Pierce pierce@hogranch.com wrote:
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_subdirectori...
On nfs server...
[root@server data]# mount /dev/sda1 on /data type xfs (rw,inode64)
[root@server data]# blkid /dev/sda1: UUID="d1bff6f7-9887-44bb-be57-d8628831cf40" TYPE="xfs"
[root@server data]# cat /etc/exports /data/oni64 *(rw,async,fsid=d1bff6f7-9887-44bb-be57-d8628831cf40,no_subtree_check)
[root@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@client1 # mount -F nfs server:/data/oni64 /backups nfs mount: tkddo-clf08:/data/oni64: No such file or directory
root@client1 # mount -F nfs -o vers=4 server:/data/oni64 /backups nfs mount: tkddo-clf08:/data/oni64: No such file or directory
root@client1 # mount -F nfs -o vers=3 server:/data/oni64 /backups nfs mount: mount: /backups: Stale NFS file handle
root@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.
From what I read as well NFS and XFS inode64 do not play well at all. NFS still has a lot of 32-bit logic hard coded in it, both in the server and client.
Is there a need for inode64? Is it too late to back-out of it, or have you pickled the file system already.
If so then the only option is to set fsid manually.
-Ross