CentOS - Mar 2012 - xfs, inode64, and NFS

we recently deployed some large XFS file systems with centos 6.2 used as 
NFS servers...

I've had some reports of a problem similar to the one reported here...
http://www.linuxquestions.org/questions/red-hat-31/xfs-inode64-nfs-export-no_subtree_check-and-stale-nfs-file-handle-message-855844/

these reports are somewhat vague (third indirectly reported via internal 
corporate channels from sites in the far east).

is anyone familiar with this inode64 stuff and NFS in EL6.2 ?


-- 
john r pierce                            N 37, W 122
santa cruz ca                         mid-left coast

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