<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font color="#000099">Hi everybody,<br>
<br>
A few months back I joined a project where people want to replace
their legacy fuse-based (twin-server) replicated file-system with
GlusterFS. They also have a high-availability NFS server code
tagged with the kernel NFSD that they would wish to retain (the
nfs-kernel-server, I mean). The reason they wish to retain the
kernel NFS and not use the NFS server that comes with GlusterFS is
mainly because there's this bit of code that allows NFS IP's to be
migrated from one host server to the other in the case that one
happens to go down, and tweaks on the export server configuration
allow the file-handles to remain identical on the new host server.<br>
<br>
The solution was to mount gluster volumes using the
mount.glusterfs native client program and then export the
directories over the kernel NFS server. This seems to work most of
the time, but on rare occasions, 'stale file handle' is reported
off certain clients, which really puts a damper over the
'high-availability' thing. After suitably instrumenting the
nfsd/fuse code in the kernel, it seems that decoding of the
file-handle fails on the server because the inode record
corresponding to the nodeid in the handle cannot be looked up.
Combining this with the fact that a second attempt by the client
to execute lookup on the same file passes, one might suspect that
the problem is identical to what many people attempting to export
fuse mounts over the kernel's NFS server are facing; viz, fuse
'forgets' the inode records thereby causing ilookup5() to fail.
Miklos and other fuse developers/hackers would point towards '-o
noforget' while mounting their fuse file-systems. <br>
<br>
I tried passing '-o noforget' to mount.glusterfs, but it does not
seem to recognize it. Could somebody help me out with the correct
syntax to pass noforget to gluster volumes? Or, something we could
pass to glusterfs that would instruct fuse to allocate a bigger
cache for our inodes?<br>
<br>
Additionally, should you think that something else might be behind
our problems, please do let me know.<br>
<br>
Here's my configuration:<br>
<br>
Linux kernel version: 2.6.34.12<br>
GlusterFS versionn: 3.4.0<br>
nfs.disable option for volumes: OFF on all volumes<br>
<br>
Thanks a lot for your time!<br>
Anirban<br>
<br>
P.s. I found quite a few pages on the web that admonish users that
GlusterFS is not compatible with the kernel NFS server, but do not
really give much detail. Is this one of the reasons for saying so?</font><br>
</body>
</html>