From: Omar Sandoval <firstname.lastname@example.org>
To: Linus Torvalds <email@example.com>
Cc: Matthew Wilcox <firstname.lastname@example.org>,
"Martin K. Petersen" <email@example.com>,
Al Viro <firstname.lastname@example.org>,
Dave Chinner <email@example.com>,
Linux API <firstname.lastname@example.org>,
Kernel Team <email@example.com>,
Dave Chinner <firstname.lastname@example.org>
Subject: Re: [PATCH RESEND x3 v9 1/9] iov_iter: add copy_struct_from_iter()
Date: Wed, 7 Jul 2021 10:59:53 -0700 [thread overview]
Message-ID: <YOXrmbi81Fr14fUV@relinquished.localdomain> (raw)
On Fri, Jun 25, 2021 at 02:07:59PM -0700, Omar Sandoval wrote:
> On Fri, Jun 25, 2021 at 09:16:15AM -0700, Linus Torvalds wrote:
> > On Thu, Jun 24, 2021 at 8:38 PM Matthew Wilcox <email@example.com> wrote:
> > >
> > > Does it make any kind of sense to talk about doing this for buffered I/O,
> > > given that we can't generate them for (eg) mmaped files?
> > Sure we can.
> > Or rather, some people might very well like to do it even for mutable
> > data. In fact, _especially_ for mutable data.
> > You might want to do things like "write out the state I verified just
> > a moment ago", and if it has changed since then, you *want* the result
> > to be invalid because the checksums no longer match - in case somebody
> > else changed the data you used for the state calculation and
> > verification in the meantime. It's very much why you'd want a separate
> > checksum in the first place.
> > Yeah, yeah, you can - and people do - just do things like this with a
> > separate checksum. But if you know that the filesystem has internal
> > checksumming support _anyway_, you might want to use it, and basically
> > say "use this checksum, if the data doesn't match when I read it back
> > I want to get an IO error".
> > (The "data doesn't match" _could_ be just due to DRAM corruption etc,
> > of course. Some people care about things like that. You want
> > "verified" filesystem contents - it might not be about security, it
> > might simply be about "I have validated this data and if it's not the
> > same data any more it's useless and I need to re-generate it").
> > Am I a big believer in this model? No. Portability concerns (across
> > OS'es, across filesystems, even just across backups on the same exact
> > system) means that even if we did this, very few people would use it.
> > People who want this end up using an external checksum instead and do
> > it outside of and separately from the actual IO, because then they can
> > do it on existing systems.
> > So my argument is not "we want this". My argument is purely that some
> > buffered filesystem IO case isn't actually any different from the
> > traditional "I want access to the low-level sector hardware checksum
> > data". The use cases are basically exactly the same.
> > Of course, basically nobody does that hw sector checksum either, for
> > all the same reasons, even if it's been around for decades.
> > So my "checksum metadata interface" is not something I'm a big
> > believer in, but I really don't think it's really all _that_ different
> > from the whole "compressed format interface" that this whole patch
> > series is about. They are pretty much the same thing in many ways.
> I see the similarity in the sense that we basically want to pass some
> extra metadata down with the read or write. So then do we want to add
> preadv3/pwritev3 for encoded I/O now so that checksums can use it in the
> future? The encoding metadata could go in this "struct io_how", either
> directly or in a separate structure with a pointer in "struct io_how".
> It could get messy with compat syscalls.
Ping. What's the path forward here? At this point, it seems like an
ioctl is the path of least resistance.
next prev parent reply other threads:[~2021-07-07 17:59 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-17 23:51 [PATCH RESEND x3 v9 0/9] fs: interface for directly reading/writing compressed data Omar Sandoval
2021-06-17 23:51 ` [PATCH RESEND x3 v9 1/9] iov_iter: add copy_struct_from_iter() Omar Sandoval
2021-06-18 18:50 ` Linus Torvalds
2021-06-18 19:42 ` Al Viro
2021-06-18 19:49 ` Al Viro
2021-06-18 20:33 ` Omar Sandoval
2021-06-18 20:32 ` Omar Sandoval
2021-06-18 20:58 ` Al Viro
2021-06-18 21:10 ` Linus Torvalds
2021-06-18 21:32 ` Al Viro
2021-06-18 21:40 ` Linus Torvalds
2021-06-18 22:10 ` Omar Sandoval
2021-06-18 22:32 ` Al Viro
2021-06-19 0:43 ` Omar Sandoval
2021-06-21 18:46 ` Omar Sandoval
2021-06-21 19:33 ` Linus Torvalds
2021-06-21 20:46 ` Omar Sandoval
2021-06-21 20:53 ` Omar Sandoval
2021-06-21 20:55 ` Omar Sandoval
2021-06-22 22:06 ` Dave Chinner
2021-06-23 17:49 ` Omar Sandoval
2021-06-23 18:28 ` Linus Torvalds
2021-06-23 19:33 ` Omar Sandoval
2021-06-23 19:45 ` Al Viro
2021-06-23 20:46 ` Omar Sandoval
2021-06-23 21:39 ` Al Viro
2021-06-23 21:58 ` Omar Sandoval
2021-06-23 22:26 ` Al Viro
2021-06-24 2:00 ` Matthew Wilcox
2021-06-24 6:14 ` Omar Sandoval
2021-06-24 17:52 ` Linus Torvalds
2021-06-24 18:28 ` Omar Sandoval
2021-06-24 21:07 ` Linus Torvalds
2021-06-24 22:41 ` Martin K. Petersen
2021-06-25 3:38 ` Matthew Wilcox
2021-06-25 16:16 ` Linus Torvalds
2021-06-25 21:07 ` Omar Sandoval
2021-07-07 17:59 ` Omar Sandoval [this message]
2021-07-19 15:44 ` Josef Bacik
2021-06-24 6:41 ` Christoph Hellwig
2021-06-24 7:50 ` Omar Sandoval
2021-06-18 22:14 ` Al Viro
2021-06-17 23:51 ` [PATCH RESEND x3 v9 2/9] fs: add O_ALLOW_ENCODED open flag Omar Sandoval
2021-06-17 23:51 ` [PATCH RESEND x3 v9 3/9] fs: add RWF_ENCODED for reading/writing compressed data Omar Sandoval
2021-06-17 23:51 ` [PATCH RESEND x3 v9 4/9] btrfs: don't advance offset for compressed bios in btrfs_csum_one_bio() Omar Sandoval
2021-06-17 23:51 ` [PATCH RESEND x3 v9 5/9] btrfs: add ram_bytes and offset to btrfs_ordered_extent Omar Sandoval
2021-06-17 23:51 ` [PATCH RESEND x3 v9 6/9] btrfs: support different disk extent size for delalloc Omar Sandoval
2021-06-17 23:51 ` [PATCH RESEND x3 v9 7/9] btrfs: optionally extend i_size in cow_file_range_inline() Omar Sandoval
2021-06-17 23:51 ` [PATCH RESEND x3 v9 8/9] btrfs: implement RWF_ENCODED reads Omar Sandoval
2021-06-17 23:51 ` [PATCH RESEND x3 v9 9/9] btrfs: implement RWF_ENCODED writes Omar Sandoval
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).