Re: [PATCH v6 RESEND 0/2] vfs: have syncfs() return error when there are writeback errors

From: Jeff Layton
Date: Wed Apr 29 2020 - 08:23:41 EST


On Tue, 2020-04-28 at 16:48 -0700, Andrew Morton wrote:
> On Tue, 28 Apr 2020 09:51:53 -0400 Jeff Layton <jlayton@xxxxxxxxxx> wrote:
>
> > Just a resend since this hasn't been picked up yet. No real changes
> > from the last set (other than adding Jan's Reviewed-bys). Latest
> > cover letter follows:
>
> I see no cover letter here.
>
> > --------------------------8<----------------------------
> >
> > v6:
> > - use READ_ONCE to ensure that compiler doesn't optimize away local var
> >
> > The only difference from v5 is the change to use READ_ONCE to fetch the
> > bd_super pointer, to ensure that the compiler doesn't refetch it
> > afterward. Many thanks to Jan K. for the explanation!
> >
> > Jeff Layton (2):
> > vfs: track per-sb writeback errors and report them to syncfs
> > buffer: record blockdev write errors in super_block that it backs
>
> http://lkml.kernel.org/r/20200207170423.377931-1-jlayton@xxxxxxxxxx
>
> has suitable-looking words, but is it up to date?
>

Thanks for picking this up, Andrew.

No, it's not. Since I wrote that, I dropped the ioctl and changed it
over to use a dedicated field in struct file instead of trying to
multiplex it for O_PATH descriptors. How about something like this?

---------------------------8<---------------------------

Currently, syncfs does not return errors when one of the inodes fails to
be written back. It will return errors based on the legacy AS_EIO and
AS_ENOSPC flags when syncing out the block device fails, but that's not
particularly helpful for filesystems that aren't backed by a blockdev.
It's also possible for a stray sync to lose those errors.

The basic idea in this set is to track writeback errors at the
superblock level, so that we can quickly and easily check whether
something bad happened without having to fsync each file individually.
syncfs is then changed to reliably report writeback errors after they
occur, much in the same fashion as fsync does now.

--
Jeff Layton <jlayton@xxxxxxxxxx>