From: Andres Freund <andres@anarazel.de>
To: Dave Chinner <david@fromorbit.com>
Cc: David Howells <dhowells@redhat.com>,
Jeff Layton <jlayton@kernel.org>,
viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
willy@infradead.org, hch@infradead.org, jack@suse.cz,
akpm@linux-foundation.org
Subject: Re: [PATCH v3 0/3] vfs: have syncfs() return error when there are writeback errors
Date: Mon, 10 Feb 2020 17:31:17 -0800 [thread overview]
Message-ID: <20200211013117.23z3ftgeorx6a3qk@alap3.anarazel.de> (raw)
In-Reply-To: <20200211004830.GB10737@dread.disaster.area>
Hi,
I shortly after this found a thread where Linus was explicitly asking
for potential userspace users of the feature, so I also responded there:
https://lore.kernel.org/linux-fsdevel/20200211005626.7yqjf5rbs3vbwagd@alap3.anarazel.de/
On 2020-02-11 11:48:30 +1100, Dave Chinner wrote:
> On Mon, Feb 10, 2020 at 04:04:05PM -0800, Andres Freund wrote:
> > On 2020-02-11 08:46:57 +1100, Dave Chinner wrote:
> > As far as I can tell the superblock based stuff does *not* actually
> > report any errors yet (contrast to READONLY, EDQUOT). Is the plan here
> > to include writeback errors as well? Or just filesystem metadata/journal
> > IO?
>
> Right, that part hasn't been implemented yet, though it's repeatedly
> mentioned as intended to be supported functionality. It will depend
> on the filesystem to what it is going to report
There really ought to be some clear guidelines what is expected to be
reported though. Otherwise we'll just end up with a hodgepodge of
different semantics, which'd be, ummm, not good.
> but I would expect that it will initially be focussed on reporting
> user data errors (e.g. writeback errors, block device gone bad data
> loss reports, etc). It may not be possible to do anything sane with
> metadata/journal IO errors as they typically cause the filesystem to
> shutdown.
I was mostly referencing the metadata/journal errors because it's what a
number of filesystems seem to treat as errors (cf errors=remount-ro
etc), and I just wanted to be sure that more than just those get
reported up...
I think the patch already had support for getting a separate type of
notification for SBs remounted ro, shouldn't be too hard to change that
so it'd report error shutdowns / remount-ro as a different
category. Without
> Of course, a filesystem shutdown is likely to result in a thundering
> herd of userspace IO error notifications (think hundreds of GB of
> dirty page cache getting EIO errors). Hence individual filesystems
> will have to put some thought into how critical filesystem error
> notifications are handled.
Probably would make sense to stop reporting them individually once the
whole FS is shutdown/remounted due to errors, and a notification about
that fact has been sent.
> That said, we likely want userspace notification of metadata IO
> errors for our own purposes. e.g. so we can trigger the online
> filesystem repair code to start trying to fix whatever went wrong. I
> doubt there's much userspace can do with things like "bad freespace
> btree block" notifications, whilst the filesystem's online repair
> tool can trigger a free space scan and rebuild/repair it without
> userspace applications even being aware that we just detected and
> corrected a critical metadata corruption....
Neat.
> > I don't think that block layer notifications would be sufficient for an
> > individual userspace application's data integrity purposes? For one,
> > it'd need to map devices to relevant filesystems afaictl. And there's
> > also errors above the block layer.
>
> Block device errors separate notifications to the superblock
> notifications. If you want the notification of raw block device
> errors, then that's what you listen for. If you want the filesystem
> to actually tell you what file and offset that EIO was generated
> for, then you'd get that through the superblock notifier, not the
> block device notifier...
Not something we urgently need, but it might come in handy at a later
point.
Thanks,
Andres
next prev parent reply other threads:[~2020-02-11 1:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-07 17:04 [PATCH v3 0/3] vfs: have syncfs() return error when there are writeback errors Jeff Layton
2020-02-07 17:04 ` [PATCH v3 1/3] vfs: track per-sb writeback errors and report them to syncfs Jeff Layton
2020-02-07 17:04 ` [PATCH v3 2/3] buffer: record blockdev write errors in super_block that it backs Jeff Layton
2020-02-07 17:04 ` [PATCH v3 3/3] vfs: add a new ioctl for fetching the superblock's errseq_t Jeff Layton
2020-02-07 20:52 ` [PATCH v3 0/3] vfs: have syncfs() return error when there are writeback errors Dave Chinner
2020-02-07 21:20 ` Andres Freund
2020-02-07 22:05 ` Jeff Layton
2020-02-07 22:21 ` Andres Freund
2020-02-10 21:46 ` Dave Chinner
2020-02-10 23:59 ` Andres Freund, David Howells
2020-02-11 0:04 ` Andres Freund
2020-02-11 0:48 ` Dave Chinner
2020-02-11 1:31 ` Andres Freund [this message]
2020-02-11 12:57 ` Jeff Layton
2020-02-12 12:21 ` 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=20200211013117.23z3ftgeorx6a3qk@alap3.anarazel.de \
--to=andres@anarazel.de \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=dhowells@redhat.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-api@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).