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@xxxxxxxxxxxx> 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.
--
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
