linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Sargun Dhillon <sargun@sargun.me>,
	Amir Goldstein <amir73il@gmail.com>,
	Miklos Szeredi <miklos@szeredi.hu>
Cc: Vivek Goyal <vgoyal@redhat.com>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v2 0/3] Check errors on sync for volatile overlayfs mounts
Date: Sat, 12 Dec 2020 06:21:37 -0500	[thread overview]
Message-ID: <7779e2ed97080009d894f3442bfad31972494542.camel@kernel.org> (raw)
In-Reply-To: <20201211235002.4195-1-sargun@sargun.me>

On Fri, 2020-12-11 at 15:49 -0800, Sargun Dhillon wrote:
> The semantics of errseq and syncfs are such that it is impossible to track
> if any errors have occurred between the time the first error occurred, and
> the user checks for the error (calls syncfs, and subsequently
> errseq_check_and_advance.
> 
> Overlayfs has a volatile feature which short-circuits syncfs. This, in turn
> makes it so that the user can have silent data corruption and not know
> about it. The third patch in the series introduces behaviour that makes it
> so that we can track errors, and bubble up whether the user has put
> themselves in bad situation.
> 
> This required some gymanstics in errseq, and adding a wrapper around it
> called "errseq_counter" (errseq + counter). The data structure uses an
> atomic to track overflow errors. This approach, rather than moving to an
> atomic64 / u64 is so we can avoid bloating every person that subscribes to
> an errseq, and only add the subscriber behaviour to those who care (at the
> expense of space.
> 
> The datastructure is write-optimized, and rightfully so, as the users
> of the counter feature are just overlayfs, and it's called in fsync
> checking, which is a rather seldom operation, and not really on
> any hotpaths.
> 
> [1]: https://lore.kernel.org/linux-fsdevel/20201202092720.41522-1-sargun@sargun.me/
> 
> Sargun Dhillon (3):
>   errseq: Add errseq_counter to allow for all errors to be observed
>   errseq: Add mechanism to snapshot errseq_counter and check snapshot
>   overlay: Implement volatile-specific fsync error behaviour
> 
>  Documentation/filesystems/overlayfs.rst |   8 ++
>  fs/buffer.c                             |   2 +-
>  fs/overlayfs/file.c                     |   5 +-
>  fs/overlayfs/overlayfs.h                |   1 +
>  fs/overlayfs/ovl_entry.h                |   3 +
>  fs/overlayfs/readdir.c                  |   5 +-
>  fs/overlayfs/super.c                    |  26 +++--
>  fs/overlayfs/util.c                     |  28 +++++
>  fs/super.c                              |   1 +
>  fs/sync.c                               |   3 +-
>  include/linux/errseq.h                  |  18 ++++
>  include/linux/fs.h                      |   6 +-
>  include/linux/pagemap.h                 |   2 +-
>  lib/errseq.c                            | 129 ++++++++++++++++++++----
>  14 files changed, 202 insertions(+), 35 deletions(-)
> 

It would hel if you could more clearly lay out the semantics you're
looking for. If I understand correctly:

You basically want to be able to sample the sb->s_wb_err of the upper
layer at mount time and then always return an error if any new errors
were recorded since that point.

If that's correct, then I'm not sure I get need for all of this extra
counter machinery. Why not just sample it at mount time without
recording it as 0 if the seen flag isn't set. Then just do an
errseq_check against the upper superblock (without advancing) in the
overlayfs ->sync_fs routine and just errseq_set that error into the
overlayfs superblock? The syncfs syscall wrapper should then always
report the latest error.

Or (even better) rework all of the sync_fs/syncfs mess to be more sane,
so that overlayfs has more control over what errors get returned to
userland. ISTM that the main problem you have is that the
errseq_check_and_advance is done in the syscall wrapper, and that's
probably not appropriate for your use-case.

-- 
Jeff Layton <jlayton@kernel.org>


  parent reply	other threads:[~2020-12-12 11:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-11 23:49 [PATCH v2 0/3] Check errors on sync for volatile overlayfs mounts Sargun Dhillon
2020-12-11 23:50 ` [PATCH v2 1/3] errseq: Add errseq_counter to allow for all errors to be observed Sargun Dhillon
2020-12-11 23:50 ` [PATCH v2 2/3] errseq: Add mechanism to snapshot errseq_counter and check snapshot Sargun Dhillon
2020-12-12  9:57   ` Amir Goldstein
2020-12-13 19:41     ` Sargun Dhillon
2020-12-11 23:50 ` [PATCH v2 3/3] overlay: Implement volatile-specific fsync error behaviour Sargun Dhillon
2020-12-12 11:21 ` Jeff Layton [this message]
2020-12-12 11:48   ` [PATCH v2 0/3] Check errors on sync for volatile overlayfs mounts Jeff Layton
2020-12-13 20:06   ` Sargun Dhillon

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=7779e2ed97080009d894f3442bfad31972494542.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=amir73il@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=sargun@sargun.me \
    --cc=vgoyal@redhat.com \
    --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).