From: Vivek Goyal <vgoyal@redhat.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: Linux fsdevel mailing list <linux-fsdevel@vger.kernel.org>,
linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org,
viro@zeniv.linux.org.uk, miklos@szeredi.hu, amir73il@gmail.com,
willy@infradead.org, jack@suse.cz, sargun@sargun.me
Subject: Re: [PATCH] vfs, syncfs: Do not ignore return code from ->sync_fs()
Date: Wed, 16 Dec 2020 10:14:09 -0500 [thread overview]
Message-ID: <20201216151409.GA3177@redhat.com> (raw)
In-Reply-To: <132c8c1e1ab82f5a640ff1ede6bb844885d46e68.camel@kernel.org>
On Wed, Dec 16, 2020 at 09:57:49AM -0500, Jeff Layton wrote:
> On Wed, 2020-12-16 at 09:38 -0500, Vivek Goyal wrote:
> > I see that current implementation of __sync_filesystem() ignores the
> > return code from ->sync_fs(). I am not sure why that's the case.
> >
> > Ignoring ->sync_fs() return code is problematic for overlayfs where
> > it can return error if sync_filesystem() on upper super block failed.
> > That error will simply be lost and sycnfs(overlay_fd), will get
> > success (despite the fact it failed).
> >
> > I am assuming that we want to continue to call __sync_blockdev()
> > despite the fact that there have been errors reported from
> > ->sync_fs(). So I wrote this simple patch which captures the
> > error from ->sync_fs() but continues to call __sync_blockdev()
> > and returns error from sync_fs() if there is one.
> >
> > There might be some very good reasons to not capture ->sync_fs()
> > return code, I don't know. Hence thought of proposing this patch.
> > Atleast I will get to know the reason. I still need to figure
> > a way out how to propagate overlay sync_fs() errors to user
> > space.
> >
> > Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
> > ---
> > fs/sync.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > Index: redhat-linux/fs/sync.c
> > ===================================================================
> > --- redhat-linux.orig/fs/sync.c 2020-12-16 09:15:49.831565653 -0500
> > +++ redhat-linux/fs/sync.c 2020-12-16 09:23:42.499853207 -0500
> > @@ -30,14 +30,18 @@
> > */
> > static int __sync_filesystem(struct super_block *sb, int wait)
> > {
> > + int ret, ret2;
> > +
> > if (wait)
> > sync_inodes_sb(sb);
> > else
> > writeback_inodes_sb(sb, WB_REASON_SYNC);
> >
> >
> > if (sb->s_op->sync_fs)
> > - sb->s_op->sync_fs(sb, wait);
> > - return __sync_blockdev(sb->s_bdev, wait);
> > + ret = sb->s_op->sync_fs(sb, wait);
> > + ret2 = __sync_blockdev(sb->s_bdev, wait);
> > +
> > + return ret ? ret : ret2;
> > }
> >
> >
> > /*
> >
>
> I posted a patchset that took a similar approach a couple of years ago,
> and we decided not to go with it [1].
>
> While it's not ideal to ignore the error here, I think this is likely to
> break stuff.
So one side affect I see is that syncfs() might start returning errors
in some cases which were not reported at all. I am wondering will that
count as breakage.
> What may be better is to just make sync_fs void return, so
> people don't think that returned errors there mean anything.
May be.
But then question remains that how do we return error to user space
in syncfs(fd) for overlayfs. I will not be surprised if other
filesystems want to return errors as well.
Shall I create new helpers and call these in case of syncfs(). But
that too will start returning new errors on syncfs(). So it does
not solve that problem (if it is a problem).
Or we can define a new super block op say ->sync_fs2() and call that
first and in that case capture return code. That way it will not
impact existing cases and overlayfs can possibly make use of
->sync_fs2() and return error. IOW, impact will be limited to
only file systems which chose to implement ->sync_fs2().
Thanks
Vivek
>
> [1]: https://lore.kernel.org/linux-fsdevel/20180518123415.28181-1-jlayton@kernel.org/
> --
> Jeff Layton <jlayton@kernel.org>
>
next prev parent reply other threads:[~2020-12-16 15:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-16 14:38 [PATCH] vfs, syncfs: Do not ignore return code from ->sync_fs() Vivek Goyal
2020-12-16 14:57 ` Jeff Layton
2020-12-16 15:14 ` Vivek Goyal [this message]
2020-12-16 15:44 ` Jeff Layton
2020-12-16 15:53 ` Jeff Layton
2020-12-16 17:16 ` Vivek Goyal
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=20201216151409.GA3177@redhat.com \
--to=vgoyal@redhat.com \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=sargun@sargun.me \
--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 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.