The path mentioned in the below logs says: <gfid:fed32419-4222-4bb2-a8b7-e036df090dfd>/linux-3.2.11 Should be fixed to print the path. [2012-04-20 03:39:25.299323] W [client3_1-fops.c:2610:client3_1_lookup_cbk] 0-nfs-test-big-client-3: remote operation failed: Stale NFS file handle. Path: <gfid:fed32419-4222-4bb2-a8b7-e036df090dfd>/linux-3.2.11 [2012-04-20 03:39:25.299617] W [client3_1-fops.c:2610:client3_1_lookup_cbk] 0-nfs-test-big-client-2: remote operation failed: Stale NFS file handle. Path: <gfid:fed32419-4222-4bb2-a8b7-e036df090dfd>/linux-3.2.11 [2012-04-20 03:39:25.299659] W [client3_1-fops.c:2610:client3_1_lookup_cbk] 0-nfs-test-big-client-1: remote operation failed: Stale NFS file handle. Path: <gfid:fed32419-4222-4bb2-a8b7-e036df090dfd>/linux-3.2.11 [2012-04-20 03:39:25.299732] W [client3_1-fops.c:2610:client3_1_lookup_cbk] 0-nfs-test-big-client-0: remote operation failed: Stale NFS file handle. Path: <gfid:fed32419-4222-4bb2-a8b7-e036df090dfd>/linux-3.2.11 [2012-04-20 03:39:25.299745] W [nfs3.c:1198:nfs3svc_lookup_cbk] 0-nfs: 2ef49f73: <gfid:fed32419-4222-4bb2-a8b7-e036df090dfd>/linux-3.2.11 => -1 (Stale NFS file handle) Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
CHANGE: http://review.gluster.com/3274 (protocol/{client,server} : Log improvements) merged in master by Vijay Bellur (vijay)
The above change doesn't actually solve this. Had put in the wrong bug-id for review. The change solves https://bugzilla.redhat.com/show_bug.cgi?id=812199 and https://bugzilla.redhat.com/show_bug.cgi?id=809713.
Sac, The path printed in the log, is actually directly accessible in the backend, and also, with the current design it is very hard to print the exact path itself (as there will be no path passed in the fops). Hence not planing to work on this bug. This will be properly documented to help GSS and users to understand which file is the one in backend. for "<gfid:fed32419-4222-4bb2-a8b7-e036df090dfd>/linux-3.2.11" backend path will be "$export-path/.glusterfs/fd/d3/fed32419-4222-4bb2-a8b7-e036df090dfd/linux-3.2.11" So taking it off the 3.3.0beta blocker state.
(In reply to comment #3) > Sac, > > The path printed in the log, is actually directly accessible in the backend, > and also, with the current design it is very hard to print the exact path > itself (as there will be no path passed in the fops). > > Hence not planing to work on this bug. This will be properly documented to > help GSS and users to understand which file is the one in backend. > > > for "<gfid:fed32419-4222-4bb2-a8b7-e036df090dfd>/linux-3.2.11" backend path > will be > "$export-path/.glusterfs/fd/d3/fed32419-4222-4bb2-a8b7-e036df090dfd/linux-3. > 2.11" > > So taking it off the 3.3.0beta blocker state. Yes, makes sense.
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.5.0, please reopen this bug report. glusterfs-3.5.0 has been announced on the Gluster Developers mailinglist [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/6137 [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user