On Mon, 16 Apr 2012 08:54:02 -0400
Peter Staubach <pstaubach@xxxxxxxxxxx> wrote:
> There seems to be a lot of, perhaps, misinformation here.
>
> The looping occurs when the file system on the server returns a valid file handle during a pathname traversal and then returns ESTALE on a subsequent operation.
>
> The client should retry the pathname traversal, which should either return a valid file handle or ENOENT. If a subsequent operation returns ESTALE, then start over again at the original pathname traversal.
>
> The client should not loop when 1) there is a signal pending which would cause the system call to terminate with EINTR or when it can't recover from the ESTALE return. For example, if lookup("./foo") returns ESTALE, then clearly the current directory has become stale and there is no way for the client to recover.
I think it's reasonable to make the syscall "wrapper" break out of the
loop if there's a _fatal_ signal pending. At that point, we don't
necessarily care what the return was since the program is going to be
dying soon anyway.
Some filesystems (e.g. NFS) would already return a different error code
in that situation, but dealing with it here seems like a reasonable way
to mitigate problems from filesystems that do not deal with signals
themselves.
>One could make the argument that the client can recover by relooking up the current directory, which is fine, but eventually if the file handle for the root of the mounted file system is also stale, then there is no further recovery possible, at least for NFSv[23] and perhaps even for NFSv4 depending upon how the file system was mounted.
If it gets an ESTALE on the initial lookup, then the VFS will already
attempt to retry the lookup again with LOOKUP_REVAL set. IIUC, that
makes it revalidate all the way back up to the root. It currently does
this regardless of whether LOOKUP_REVAL was set on the initial lookup
attempt.
It sounds here like you're suggesting that we should just go ahead and
give up and return ESTALE to userspace if the root of the mount went
stale. So, if someone mistakenly unexports the fs on the server, these
operations would still fail with ESTALE.
If so, I'm OK with that since I'm not necessarily interested in making
that situation more recoverable. It would be a nice to have, but it's
not as essential as fixing these other situations where the ESTALE is
more easily recovered.
--
Jeff Layton <jlayton@xxxxxxxxxx>
--
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
