On Thu, 25 Jul 2013 14:24:30 +0000
"Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> 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@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
