From: Jeff Layton <jlayton@kernel.org>
To: trond.myklebust@hammerspace.com, chuck.lever@oracle.com
Cc: willy@infradead.org, linux-nfs@vger.kernel.org
Subject: [PATCH 0/3] nfsd: write verifier fixes and optimization
Date: Mon, 13 Feb 2023 16:13:42 -0500 [thread overview]
Message-ID: <20230213211345.385005-1-jlayton@kernel.org> (raw)
While looking at the recent problems with the fsync during nfsd_file
cleanup, it occured to me that we could greatly simplify and improve
the server's write verifier handling. I also noticed an existing bug
which is fixed in patch #1.
Instead of trying to check for errors via fsync and resetting the write
verifier when we get one, we can just fold the current value of the
inode's errseq_t into the hashed verifier that is generated at startup
time.
Testing this new scheme has been a real challenge. Once a writeback
error is recorded on all local filesystems, further attempts to write to
the inode return -EIO (and some filesystems even flip to r/o) and you
never see the new verifier.
Trond, you originally added the code to make it reset the verifier on a
writeback error. Do you have a good way to test that? Did you guys use
NFSv3 reexport for testing this somehow?
Jeff Layton (3):
nfsd: copy the whole verifier in nfsd_copy_write_verifier
errseq: add a new errseq_fetch helper
nfsd: simplify write verifier handling
fs/nfsd/filecache.c | 22 +------------------
fs/nfsd/netns.h | 4 ----
fs/nfsd/nfs4proc.c | 17 ++++++---------
fs/nfsd/nfsctl.c | 1 -
fs/nfsd/nfssvc.c | 48 +++++++++++++-----------------------------
fs/nfsd/trace.h | 28 ------------------------
fs/nfsd/vfs.c | 28 +++++-------------------
fs/nfsd/vfs.h | 1 +
include/linux/errseq.h | 1 +
lib/errseq.c | 33 ++++++++++++++++++++++++++++-
10 files changed, 62 insertions(+), 121 deletions(-)
--
2.39.1
next reply other threads:[~2023-02-13 21:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 21:13 Jeff Layton [this message]
2023-02-13 21:13 ` [PATCH 1/3] nfsd: copy the whole verifier in nfsd_copy_write_verifier Jeff Layton
2023-02-13 21:13 ` [PATCH 2/3] errseq: add a new errseq_fetch helper Jeff Layton
2023-02-13 21:13 ` [PATCH 3/3] nfsd: simplify write verifier handling Jeff Layton
2023-02-14 0:49 ` Rick Macklem
2023-02-14 3:28 ` Trond Myklebust
2023-02-14 13:53 ` Jeff Layton
2023-02-14 14:58 ` Chuck Lever III
2023-02-14 15:01 ` Jeff Layton
2023-02-14 22:57 ` Rick Macklem
2023-02-14 23:16 ` Jeff Layton
2023-02-14 23:34 ` Trond Myklebust
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230213211345.385005-1-jlayton@kernel.org \
--to=jlayton@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@hammerspace.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox