lkml.org 
[lkml]   [2012]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v4 00/17] vfs: add the ability to retry on ESTALE to several syscalls
    From
    Hi Jeff.

    Which testcase(or test method) do I use to know improved point from
    ESTALE error ?
    I want to know before & after using testcase with this patch-set.

    Thanks.

    2012/7/26, Jeff Layton <jlayton@redhat.com>:
    > This patchset is a respin of the one I sent on June 29th. The main
    > reason for the resend is to deal with some minor merge conflicts that
    > have cropped up due to recent changes.
    >
    > This series depends on the "audit" series that I sent earlier today.
    > It's also available via the "estale" branch of my git tree:
    >
    > git://git.samba.org/jlayton/linux.git estale
    >
    > The original cover letter text follows:
    >
    > ESTALE errors are a source of pain for many users, primarily those who
    > are doing work on NFS. When userspace provides a path to a syscall, then
    > there's really little excuse for returning ESTALE. If userspace gave us
    > a path that we had to lookup in order to do the call, then it's not
    > particularly helpful to return ESTALE just because that path went stale
    > before we could do the actual operation.
    >
    > We can and should do better here. The kernel should instead catch that
    > error and retry the lookup and call, while forcing a revalidation of all
    > dentries involved.
    >
    > Unfortunately fixing this requires touching the syscalls themselves, or
    > at least their immediate helper functions. Not all syscalls can be
    > retried -- only those that take a pathname as an argument.
    >
    > With this patchset, I've decided to take the relatively less
    > controversial approach of just having the kernel retry once when it gets
    > an ESTALE error. I still think that it's not as strong as it should be,
    > but it should improve the situation in many common cases.
    >
    > I've also tried to engineer this in such a way that if we do decide that
    > we need to retry more than once, then it should be easy to change that
    > later. This should cover all of the syscalls in fs/stat.c and
    > fs/namei.c.
    >
    > Once these are merged, I'll look at adding similar handling to other
    > path-based syscalls in a later set. A quick look shows that we have
    > about 50-odd path-based syscalls that will need similar handling, so
    > this is just a start.
    >
    > Jeff Layton (17):
    > vfs: add a retry_estale helper function to handle retries on ESTALE
    > vfs: add a kern_path_at function
    > vfs: make fstatat retry on ESTALE errors from getattr call
    > vfs: fix readlinkat to retry on ESTALE
    > vfs: remove user_path_at_empty
    > vfs: turn "empty" arg in getname_flags into a bool
    > vfs: add new "reval" argument to kern_path_create
    > vfs: fix mknodat to retry on ESTALE errors
    > vfs: fix mkdir to retry on ESTALE errors
    > vfs: fix symlinkat to retry on ESTALE errors
    > vfs: fix linkat to retry on ESTALE errors
    > vfs: make rmdir retry on ESTALE errors
    > vfs: make do_unlinkat retry on ESTALE errors
    > vfs: fix renameat to retry on ESTALE errors
    > vfs: remove user_path_parent
    > vfs: have do_sys_truncate retry once on an ESTALE error
    > vfs: have faccessat retry once on an ESTALE error
    >
    > drivers/base/devtmpfs.c | 7 +-
    > fs/namei.c | 407
    > +++++++++++++++++++++++++++++-------------------
    > fs/open.c | 162 ++++++++++---------
    > fs/stat.c | 44 ++++--
    > include/linux/fs.h | 22 +++
    > include/linux/namei.h | 4 +-
    > net/unix/af_unix.c | 3 +-
    > 7 files changed, 400 insertions(+), 249 deletions(-)
    >
    > --
    > 1.7.11.2
    >
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    >


    \
     
     \ /
      Last update: 2012-07-27 05:01    [W:0.204 / U:1.132 seconds]
    ©2003-2014 Jasper Spaans. Advertise on this site