[lkml]   [2012]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH RFC] vfs: make fstatat retry on ESTALE errors from getattr call
    On Mon, 16 Apr 2012 08:54:02 -0400
    Peter Staubach <> 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

    >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

    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 <>

     \ /
      Last update: 2012-04-16 18:05    [W:0.020 / U:241.368 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site