Re: nfs client: Now you see it, now you don't (aka spurious ESTALE errors)

[Jeff Layton <jlayton@redhat.com>]

On Thu, 25 Jul 2013 14:24:30 +0000
"Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote:

> On Thu, 2013-07-25 at 10:11 -0400, Jeff Layton wrote:
> 
> > What might be helpful is to do some network captures when the problem
> > occurs. What we want to know is whether the ESTALE errors are coming
> > from the server, or if the client is generating them. That'll narrow
> > down where we need to look for problems.
> 
> Hmm... Shouldn't ESTALE always be repackaged as ENOENT by the VFS, now
> that your patchset has gone upstream, Jeff?
> 

I don't think so...

On something path-based then that might make sense (or maybe we should
declare a new ERACE error like Al once suggested and return that). If
you're doing a write() on a fd that you previously opened but the inode
has disappeared on the server, then -ESTALE clearly seems valid.

There are other problematic cases too...

Suppose I do stat(".", ...); ? Does an -ENOENT error make sense at that point?

Also, since we only retry once on an ESTALE error, returning that is a
pretty clear indicator that you raced with some other metadata
operations. ENOENT is not as informative...

-- 
Jeff Layton <jlayton@redhat.com>