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






_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Reply via email to