Re: [Gluster-devel] Stale NFS file handle, then EINVAL

[Pavan T C]

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

>