[Gluster-devel] Re: NFS re-export works for me

[Brent A Nelson]

Further testing indicates that NFS will break GlusterFS.  An rsync from an 
NFS reexported GlusterFS to itself works for a while, but then the 
glusterfs and glusterfsd on the reexporting node fails.

The nfsd fails with errors:
"nfsd: non-standard errno: -107" (the first time it also mentioned -103)

The nfs client has:
[43183798.232000] nfs: server jupiter not responding, still trying
[43183798.870000] nfs: server jupiter OK
[43183798.870000] nfs: server jupiter OK
[43183798.870000] nfs: server jupiter OK
[43184182.556000] nfs_statfs: statfs error = 5
[43184189.720000] nfs_statfs: statfs error = 5
[43184197.393000] nfs_update_inode: inode number mismatch
[43184197.393000] expected (0:1a/0x1), got (0:1a/0xf8ccb3c0)
[43184211.224000] nfs warning: mount version older than kernel
[43184211.225000] init_special_inode: bogus i_mode (1520)
[43184211.230000] nfs warning: mount version older than kernel
[43184229.733000] nfs warning: mount version older than kernel
[43184229.734000] init_special_inode: bogus i_mode (1520)
[43184229.740000] nfs warning: mount version older than kernel
[43184247.305000] nfs warning: mount version older than kernel
[43184432.614000] nfs_update_inode: inode number mismatch
[43184432.614000] expected (0:1a/0xc), got (0:1a/0xf8ccb3c0)

Although, that includes multiple attempts, including where I hadn't 
restarted nfsd on the server, and it was complaining about superblock 
access until I restarted it and it could access the remounted GlusterFS.

I wonder if this could be related to the way GlusterFS fakes inodes...

Thanks,

Brent

On Wed, 18 Apr 2007, Brent A Nelson wrote:

> I tried a quick NFS re-export to another Linux box (with the fsid= option and 
> fuse 2.6.3 on the NFS server, of course).  I didn't test it much, but copies 
> to and from the NFS filesystem worked just fine.  I think writes were very 
> slow, but they didn't give me any trouble.
>
> No special mount options (such as NFS version or transport) were needed.
>
> Thanks,
>
> Brent