[Gluster-users] Passing noforget option to glusterfs native client mounts
chalcogen_eg_oxygen at yahoo.com
Wed Dec 18 19:46:15 UTC 2013
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.
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.
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
Additionally, should you think that something else might be behind our
problems, please do let me know.
Here's my configuration:
Linux kernel version: 126.96.36.199
GlusterFS versionn: 3.4.0
nfs.disable option for volumes: OFF on all volumes
Thanks a lot for your time!
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-users