Re: [PATCH RFC v3] vfs: make fstatat retry once on ESTALE errors from getattr call

["J. Bruce Fields" <bfields@fieldses.org>]

On Mon, Apr 23, 2012 at 09:50:21AM -0400, Jeff Layton wrote:
> On Mon, 23 Apr 2012 09:34:12 -0400
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
> 
> > On Mon, Apr 23, 2012 at 09:12:55AM -0400, Jeff Layton wrote:
> > > Here's an example -- suppose we have two directories: /foo
> > > and /bar. /bar is empty. We call:
> > > 
> > >     rename("/foo","/bar");
> > > 
> > > ...and at the same time, someone is calling:
> > > 
> > >     stat("/bar");
> > > 
> > > ...the calls race and in this condition the stat() gets ESTALE back
> > > -- /bar got replaced after we did the lookup.
> > > 
> > > According to POSIX, the name "/bar" should never be absent from the
> > > namespace in this situation, so I'm not sure I understand why returning
> > > ENOENT here would be acceptable.
> > 
> > Yes, agreed, my assertion was just that an ESTALE on a lookup of a
> > non-final component is probably equivalent to ENOENT.
> > 
> > I'm not sure if that's what Miklos meant.
> > 
> 
> Ahh ok, sorry I misunderstood. Yeah in that case I suppose it would
> be ok to replace ESTALE with ENOENT. Ok, so to illustrate...
> 
> Suppose we're trying to stat("/bar/baz") instead in the above example.
> Then we could just return ENOENT instead on an ESTALE return for the
> reasons that Bruce outlined. If the dir was stale, then there was a
> at least one point in time where we *know* that "baz" didn't exist.
> 
> That doesn't seem like it'll work as a general solution though since it
> wouldn't apply to an ESTALE on the last component. For that we'd need
> to do something different -- retry the operation in some form, but it
> might be potential optimization in the path walking code to avoid
> retrying in some cases.

I also wonder whether it would be making too many assumptions about the
server or filesystem: just because ordinary posix interfaces don't allow
atomic replacement of a whole directory tree doesn't mean the server
might not have some way to do it.

--b.