[Gluster-devel] Re: NFS reexport status

[Brent A Nelson]

Replying to myself...

On Mon, 25 Feb 2008, Brent A Nelson wrote:

> I thought I'd present my findings with regards to NFS reexport from a recent 
> TLA of GlusterFS (patch 663), in case they are of use:
>
> 1) Stale NFS file handles coupled with the loss of the CWD (current working 
> directory) can occur on idle client shells.  This seems to occur with AFR 
> filesystems, presumably due to the possibility that the inode number of the 
> directory could change, but not with unify (even with AFR underneath and even 
> with the namespace AFRed, I've not encountered the problem, although I am now 
> using the read-subvolume option, which may be avoiding the issue).
>

I was wrong, this does still occur, even with unified AFRs, at least when 
the namespace is also an AFR (I suspect it would work fine if namespace 
was not an AFR, but I could be wrong).  If anyone has any idea of how to 
correct this (without losing AFR redundancy), please let me know.

> 2) Aside from 1), NFS-kernel server seems to provide 100% correct NFS 
> reexport, no glitches or weird errors.  However, it's extremely slow, on the 
> order of 200-300KBps writes.  Does anyone have any ideas on how to speed this 
> up? Nevertheless, for someone who just needs NFS reexport for compatibility 
> with systems that can't run GlusterFS, and performance doesn't matter, this 
> will apparently do the job.

I found that the Solaris NFS mount option "forcedirectio" gives a massive 
speed boost.  It's still not as fast as Unfs3 (4MBps writes compared to 
10.2MBps on fast ethernet), but it's not all that bad, either (and Unfs3 
"glitches" with GlusterFS)...

Thanks,

Brent