From: Jeff Layton <jlayton@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
viro@ZenIV.linux.org.uk, andres@anarazel.de
Subject: Re: [RFC PATCH 07/11] ext4: have sync_fs op report writeback errors when passed a since pointer
Date: Fri, 18 May 2018 12:50:31 -0400 [thread overview]
Message-ID: <822b5af73146dd7cc9c18f0cbbe3ae7121af493d.camel@kernel.org> (raw)
In-Reply-To: <20180518152250.GC6361@bombadil.infradead.org>
On Fri, 2018-05-18 at 08:22 -0700, Matthew Wilcox wrote:
> On Fri, May 18, 2018 at 08:34:11AM -0400, Jeff Layton wrote:
> > From: Jeff Layton <jlayton@redhat.com>
> >
> > When ext4_sync_fs gets a non-NULL since pointer, use it to report
> > errors vs. the errseq_t in the super_block. This allows us to
> > properly report an error to sync_fs when any inode has failed writeback
> > since we last checked for it.
> >
> > Signed-off-by: Jeff Layton <jlayton@redhat.com>
> > ---
> > fs/ext4/super.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> > index 896ddf8c3421..a5f41d31611f 100644
> > --- a/fs/ext4/super.c
> > +++ b/fs/ext4/super.c
> > @@ -4898,6 +4898,8 @@ static int ext4_sync_fs(struct super_block *sb, int wait, errseq_t *since)
> > }
> > out:
> > ret2 = __sync_blockdev(sb->s_bdev, wait);
> > + if (since)
> > + ret2 = errseq_check_and_advance(&sb->s_wb_err, since);
> > return ret ? ret : ret2;
> > }
>
> This is inconsistent with the ext2 and xfs implementations ...
>
> I'm worried this is too much complexity to push down to the filesystems.
> When should errors get reported through the return value; when should they
> be reported through the errseq_t?
>
> Can we hide all of this? Maybe ext4 could do:
>
> errseq_set(&sb->s_wb_err, __sync_blockdev(sb->s_bdev, wait));
> return ret;
>
I'm not sure I understand what you intend here. If __sync_blockdev
fails, then the error should have already been marked in sb->s_wb_err
(via patch #6). We wouldn't want to record that again at syncfs time.
Note that __sync_blockdev will return errors based on the legacy
AS_EIO/AS_ENOSPC flags.
We really do need to record it in the superblock as soon as possible
after an error occurs. If we want to allow userland to eventually be
able to scrape this value out of the kernel (as we discussed at LSF/MM)
then we can't assume that it'll be doing any sort of syncfs call
beforehand.
The main reason to push this down into the filesystems is to allow them
control over whether to report errors at syncfs time via the superblock
errseq_t or not. If we don't really care about allowing this to be an
opt-in thing, then we could just take the patch that I sent on April
17th:
[PATCH] fs: track per-sb writeback errors and report them to syncfs
We'd also want patch #6 from this series, I think, but that's more or
less enough to implement this over all filesystems, assuming they use
mapping_set_error to record writeback errors. I'm fine with either
approach.
> (we'd need to make calling errseq_set(x, 0) be a no-op instead of an error)
>
> and then the caller is the one who takes care of calling
> errseq_check_and_advance() so we don't have to pass 'since' into each
> filesystem.
next prev parent reply other threads:[~2018-05-18 16:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-18 12:34 [RFC PATCH 00/11] vfs: have syncfs return an error when inode writeback fails Jeff Layton
2018-05-18 12:34 ` [RFC PATCH 01/11] vfs: push __sync_blockdev calls down into sync_fs routines Jeff Layton
2018-05-18 15:56 ` Christoph Hellwig
2018-05-18 17:56 ` Jeff Layton
2018-05-18 12:34 ` [RFC PATCH 02/11] vfs: add a new errseq_t pointer to sync_fs prototype Jeff Layton
2018-05-18 12:34 ` [RFC PATCH 03/11] vfs: add an errseq_t pointer to sync_filesystem Jeff Layton
2018-05-18 12:34 ` [RFC PATCH 04/11] vfs: add errseq_t pointer to __sync_filesystem Jeff Layton
2018-05-18 12:34 ` [RFC PATCH 05/11] fs: track per-sb writeback errors and report them to syncfs Jeff Layton
2018-05-18 12:34 ` [RFC PATCH 06/11] buffer: record blockdev write errors in super_block that backs them Jeff Layton
2018-05-18 12:34 ` [RFC PATCH 07/11] ext4: have sync_fs op report writeback errors when passed a since pointer Jeff Layton
2018-05-18 15:22 ` Matthew Wilcox
2018-05-18 16:50 ` Jeff Layton [this message]
2018-05-18 12:34 ` [RFC PATCH 08/11] xfs: " Jeff Layton
2018-05-21 23:01 ` Dave Chinner
2018-05-21 23:23 ` Jeff Layton
2018-05-18 12:34 ` [RFC PATCH 09/11] btrfs: " Jeff Layton
2018-05-18 12:34 ` [RFC PATCH 10/11] ext2: " Jeff Layton
2018-05-18 12:34 ` [RFC PATCH 11/11] vfs: have call_sync_fs " Jeff Layton
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=822b5af73146dd7cc9c18f0cbbe3ae7121af493d.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=andres@anarazel.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
--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
Powered by JetHome