On Mon, Apr 23, 2012 at 08:00:12AM -0400, Jeff Layton wrote: > On Sun, 22 Apr 2012 07:40:57 +0200 > Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > On Fri, Apr 20, 2012 at 11:13 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > On Fri, 20 Apr 2012 15:37:26 -0500 > > > Malahal Naineni <malahal@xxxxxxxxxx> wrote: > > > > > >> Steve Dickson [SteveD@xxxxxxxxxx] wrote: > > >> > > 2) if we assume that it is fairly representative of one, how can we > > >> > > achieve retrying indefinitely with NFS, or at least some large finite > > >> > > amount? > > >> > The amount of looping would be peer speculation. If the problem can > > >> > not be handled by one simple retry I would say we simply pass the > > >> > error up to the app... Its an application issue... > > >> > > >> As someone said, ESTALE is an incorrect errno for a path based call. > > >> How about turning ESTALE into ENOENT after a retry or few retries? > > >> > > > > > > It's not really the same thing. One could envision an application > > > that's repeatedly renaming a new file on top of another one. The file > > > is never missing from the namespace of the server, but you could still > > > end up getting an ESTALE. > > > > > > That would break other atomicity guarantees in an even worse way, IMO... > > > > For directory operations ESTALE *is* equivalent to ENOENT if already > > retrying with LOOKUP_REVAL. Think about it. Atomic replacement by > > another directory with rename(2) is not an excuse here actually. > > Local filesystems too can end up with IS_DEAD directory after lookup > > in that case. > > > > Doesn't that violate POSIX? rename(2) is supposed to be atomic, and I > can't see where there's any exception for that for directories. Hm, but that only allows atomic replacement of the last component of a path. Suppose you're looking up a path, you've so far reached intermediate directory "D", and the next step of the lookup (of some entry in D) returns ESTALE. Then either: - D has since been unlinked, and ENOENT is obviously right. - D was unlinked and then replaced by something else, in which case there was still a moment when ENOENT was correct. - D was replaced atomically by a rename. But for the rename to work it must have been replacing an empty directory, so there was still a moment when ENOENT would have been correct. (Exception: if D was actually a regular file or some other non-directory object, then ENOTDIR would be the right error: but if you're able to get at least object type atomically with a lookup, then you should have noticed this already on lookup of D.) I think that's what Miklos meant? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
