Gluster users - Jun 2016 - Stale file handle when accessing shared drive,

Hello,

We use glusterfs version 3.6.9 as a shared storage solution. The linux kernel
version is 4.1.20. Our setup consists of replica 2 volumes, no distribute. We
have seen that occasionally readdir operations return the "Stale file
handle" error. Below are the client logs:

[2016-06-15 09:29:59.717521] W [fuse-bridge.c:1001:fuse_fd_cbk]
0-glusterfs-fuse: 598: OPENDIR() /folder1/folder2/folder3/folder4/folder5 =>
-1 (Stale file handle)
[2016-06-15 09:29:59.717851] W [defaults.c:2177:default_releasedir] (-->
/usr/lib64/glusterfs/libglusterfs.so.0(_gf_log_callingfn+0x218)[0x7f28346e9bdd]
(-->
/usr/lib64/glusterfs/libglusterfs.so.0(default_releasedir+0x44)[0x7f28347035d4]
(--> /usr/lib64/glusterfs/libglusterfs.so.0(+0x5c6a1)[0x7f28347236a1] (-->
/usr/lib64/glusterfs/libglusterfs.so.0(fd_unref+0x9d)[0x7f28347238c3] (-->
/usr/lib64/glusterfs/glusterfs/3.6.9/xlator/protocol/client.so(client_local_wipe+0x56)[0x7f282bdd2549]
))))) 0-fuse: xlator does not implement releasedir_cbk

The issue is temporary. We have created a script that continuously does an ls on
the directory, and the error appeared for 30 seconds in one case. For these 30
seconds, the ls command showed the following output:
ls: cannot open directory '/folder1/folder2/folder3/folder4/folder5 ':
Stale file handle
After 30 seconds, no error appeared and the directory contents were listed
normally.

Do you think this is related to the bugs below:
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1041109
[2]
https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3/html/3.0_Update_4_Release_Notes/chap-Known_Issues.html

Are the bugs above still applicable in the 3.6.9 release? In [2] there is a
suggested workaround, to use "gluster volume set VOLNAME quick-read
off". Do you think it will fix the stale file handle issue? Won't this
cause a decrease in performance?

On a more general level, what can cause the "Stale file handle"? In
this link
[3] http://www.cyberciti.biz/tips/nfs-stale-file-handle-error-and-solution.html
it says that it occurs when one client holds an active handle (open file
descriptor?) to a file/directory that is deleted by another client or directly
on the server. But in our case the issue is temporary so it doesn't look
that the problem is deletion by another client.

Best regards,

Klearchs






-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20160623/093304f1/attachment.html>