From: Jeff Layton <jlayton@redhat.com>
To: NeilBrown <neilb@suse.com>, Jeff Layton <jlayton@kernel.org>,
trond.myklebust@primarydata.com, anna.schumaker@netapp.com
Cc: linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] nfs: track writeback errors with errseq_t
Date: Mon, 28 Aug 2017 07:47:35 -0400 [thread overview]
Message-ID: <1503920855.4563.12.camel@redhat.com> (raw)
In-Reply-To: <87h8wsiog4.fsf@notabene.neil.brown.name>
On Mon, 2017-08-28 at 09:24 +1000, NeilBrown wrote:
> On Fri, Aug 25 2017, Jeff Layton wrote:
>
> > On Thu, 2017-07-20 at 15:42 -0400, Jeff Layton wrote:
> > > From: Jeff Layton <jlayton@redhat.com>
> > >
> > > There is some ambiguity in nfs about how writeback errors are
> > > tracked.
> > >
> > > For instance, nfs_pageio_add_request calls mapping_set_error when
> > > the
> > > add fails, but we track errors that occur after adding the
> > > request
> > > with a dedicated int error in the open context.
> > >
> > > Now that we have better infrastructure for the vfs layer, this
> > > latter int is now unnecessary. Just have
> > > nfs_context_set_write_error set
> > > the error in the mapping when one occurs.
> > >
> > > Have NFS use file_write_and_wait_range to initiate and wait on
> > > writeback
> > > of the data, and then check again after issuing the commit(s).
> > >
> > > With this, we also don't need to pay attention to the ERROR_WRITE
> > > flag for reporting, and just clear it to indicate to subsequent
> > > writers that they should try to go asynchronous again.
> > >
> > > In nfs_page_async_flush, sample the error before locking and
> > > joining
> > > the requests, and check for errors since that point.
> > >
> > > Signed-off-by: Jeff Layton <jlayton@redhat.com>
> > > ---
> > > fs/nfs/file.c | 24 +++++++++++-------------
> > > fs/nfs/inode.c | 3 +--
> > > fs/nfs/write.c | 8 ++++++--
> > > include/linux/nfs_fs.h | 1 -
> > > 4 files changed, 18 insertions(+), 18 deletions(-)
> > >
> > > I have a baling wire and duct tape solution for testing this with
> > > xfstests (using iptables REJECT targets and soft mounts). This
> > > seems to
> > > make nfs do the right thing.
> > >
> > > diff --git a/fs/nfs/file.c b/fs/nfs/file.c
> > > index 5713eb32a45e..15d3c6faafd3 100644
> > > --- a/fs/nfs/file.c
> > > +++ b/fs/nfs/file.c
> > > @@ -212,25 +212,23 @@ nfs_file_fsync_commit(struct file *file,
> > > loff_t start, loff_t end, int datasync)
> > > {
> > > struct nfs_open_context *ctx =
> > > nfs_file_open_context(file);
> > > struct inode *inode = file_inode(file);
> > > - int have_error, do_resend, status;
> > > - int ret = 0;
> > > + int do_resend, status;
> > > + int ret;
> > >
> > > dprintk("NFS: fsync file(%pD2) datasync %d\n", file,
> > > datasync);
> > >
> > > nfs_inc_stats(inode, NFSIOS_VFSFSYNC);
> > > do_resend =
> > > test_and_clear_bit(NFS_CONTEXT_RESEND_WRITES, &ctx->flags);
> > > - have_error = test_and_clear_bit(NFS_CONTEXT_ERROR_WRITE,
> > > &ctx->flags);
> > > - status = nfs_commit_inode(inode, FLUSH_SYNC);
> > > - have_error |= test_bit(NFS_CONTEXT_ERROR_WRITE, &ctx-
> > > >flags);
> > > - if (have_error) {
> > > - ret = xchg(&ctx->error, 0);
> > > - if (ret)
> > > - goto out;
> > > - }
> > > - if (status < 0) {
> > > + clear_bit(NFS_CONTEXT_ERROR_WRITE, &ctx->flags);
> > > + ret = nfs_commit_inode(inode, FLUSH_SYNC);
> > > +
> > > + /* Recheck and advance after the commit */
> > > + status = file_check_and_advance_wb_err(file);
>
> This change makes the code inconsistent with the comment above the
> function, which still references ctx->error. The intent of the
> comment
> is still correct, but the details have changed.
>
Good catch. I'll fix that up in a respin.
> Also, there is a call to mapping_set_error() in
> nfs_pageio_add_request().
> I wonder if that should be changed to
> nfs_context_set_write_error(req->wb_context, desc->pg_error)
> ??
>
Trickier question...
I'm not quite sure what semantics we're looking for with
NFS_CONTEXT_ERROR_WRITE. I know that it forces writes to be
synchronous, but I'm not quite sure why it gets cleared the way it
does. It's set on any error but cleared before issuing a commit.
I added a similar flag to Ceph inodes recently, but only clear it when
a write succeeds. Wouldn't that make more sense here as well?
--
Jeff Layton <jlayton@redhat.com>
next prev parent reply other threads:[~2017-08-28 11:47 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-20 19:42 [PATCH] nfs: track writeback errors with errseq_t Jeff Layton
2017-08-25 17:59 ` Jeff Layton
2017-08-27 23:24 ` NeilBrown
2017-08-28 11:47 ` Jeff Layton [this message]
2017-08-29 1:23 ` NeilBrown
2017-08-29 10:54 ` Jeff Layton
2017-09-07 3:37 ` NeilBrown
2017-09-07 11:35 ` Jeff Layton
2017-09-07 14:54 ` Trond Myklebust
2017-09-07 14:54 ` Trond Myklebust
2017-09-11 3:24 ` NeilBrown
2017-09-11 10:46 ` Jeff Layton
2017-09-11 21:52 ` NeilBrown
2017-09-12 15:20 ` Jeff Layton
2017-09-12 21:47 ` NeilBrown
2017-09-13 12:23 ` Jeff Layton
2017-09-13 23:50 ` [RFC PATCH manpages] write.2, fsync.2, close.2: update description of error codes NeilBrown
2017-09-13 23:50 ` NeilBrown
[not found] ` <87ingm9n04.fsf-wvvUuzkyo1HefUI2i7LXDhCRmIWqnp/j@public.gmane.org>
2017-09-14 7:59 ` walter harms
[not found] ` <59BA36C5.9000506-fPG8STNUNVg@public.gmane.org>
2017-09-14 22:36 ` NeilBrown
2017-09-14 10:48 ` Jeff Layton
2017-09-14 10:48 ` Jeff Layton
2017-09-15 7:50 ` Michael Kerrisk (man-pages)
[not found] ` <28da8888-e8f9-31d5-a3dd-d3c2a5e9037a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-09-15 8:25 ` NeilBrown
2017-09-15 8:25 ` NeilBrown
[not found] ` <1505386139.4870.10.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-09-28 3:01 ` NeilBrown
2017-09-28 3:01 ` NeilBrown
[not found] ` <87fub75xxr.fsf-wvvUuzkyo1HefUI2i7LXDhCRmIWqnp/j@public.gmane.org>
2017-09-28 12:20 ` Jeff Layton
2017-09-28 12:20 ` Jeff Layton
2017-09-28 16:19 ` Michael Kerrisk (man-opages)
2017-09-12 2:24 ` [PATCH] nfs: track writeback errors with errseq_t Trond Myklebust
2017-09-12 2:24 ` Trond Myklebust
2017-09-12 5:29 ` NeilBrown
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=1503920855.4563.12.camel@redhat.com \
--to=jlayton@redhat.com \
--cc=anna.schumaker@netapp.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.com \
--cc=trond.myklebust@primarydata.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.