On Wednesday 20 July 2011 03:29 PM, Emmanuel Dreyfus wrote:
On Tue, Jul 19, 2011 at 08:05:07PM +0200, Emmanuel Dreyfus wrote:
Another bug: first find complains of a stale NFS filehandle
find: /gfs/usr/src/tools/binutils/../../gnu/dist/binutils/cpu/sh.opc: Stale
NFS file handle
Increasing the log level helps: ESTALE happens here in client3_1_lookup_cbk()
if ((!uuid_is_null (inode->gfid))
&& (uuid_compare (stbuf.ia_gfid, inode->gfid) != 0)) {
gf_log (frame->this->name, GF_LOG_DEBUG,
"gfid changed for %s", local->loc.path);
rsp.op_ret = -1;
op_errno = ESTALE;
goto out;
}
But what does that mean, and how to fix it?
This is from my limited understanding. Here are the details -
When lookup is sent, the details of the ondisk file (particularly gfid)
is fetched. In the lookup callback, a comparison with this gfid is made
with one in the local inode cache. If this inode is found in the local
cache and the local gfid differs from the one obtained from the disk,
ESTALE is returned to FUSE. FUSE will consider this to be a revalidate
case, and should send a revalidate lookup to update it's cache, and
should *not* pass this error back to VFS. If the error is passed back to
VFS, the application can report "Stale NFS file handle".
There is already a bug raised on this. Refer to bug 3041.
Pavan
