All of lore.kernel.org
 help / color / mirror / Atom feed
From: Omar Sandoval <osandov@osandov.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Christoph Hellwig <hch@infradead.org>,
	Dave Chinner <david@fromorbit.com>, Jann Horn <jannh@google.com>,
	Amir Goldstein <amir73il@gmail.com>,
	Aleksa Sarai <cyphar@cyphar.com>,
	Linux API <linux-api@vger.kernel.org>,
	Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH RERESEND v9 0/9] fs: interface for directly reading/writing compressed data
Date: Mon, 7 Jun 2021 12:27:07 -0700	[thread overview]
Message-ID: <YL5zCxGx/J1WxSCq@relinquished.localdomain> (raw)
In-Reply-To: <CAHk-=wh74eFxL0f_HSLUEsD1OQfFNH9ccYVgCXNoV1098VCV6Q@mail.gmail.com>

On Mon, May 17, 2021 at 02:32:47PM -0700, Linus Torvalds wrote:
> On Mon, May 17, 2021 at 11:35 AM Omar Sandoval <osandov@osandov.com> wrote:
> >
> > Patches 1-3 add the VFS support, UAPI, and documentation. Patches 4-7
> > are Btrfs prep patches. Patch 8 adds Btrfs encoded read support and
> > patch 9 adds Btrfs encoded write support.
> 
> I don't love the RWF_ENCODED flag, but if that's the way people think
> this should be done, as a model this looks reasonable to me.
> 
> I'm not sure what the deal with the encryption metadata is. I realize
> there is currently only one encryption type ("none") in this series,
> but it's not clear how any other encryption type would actually ever
> be described. It's not like you can pass in the key (well, I guess
> passing in the key would be fine, but passing it back out certainly
> would not be).  A key ID from a keyring?
> 
> So there's presumably some future plan for it, but it would be good to
> verify that that plan makes sense..

To summarize the discussion and answer your original question, using
RWF_ENCODED for encryption will require additional support for getting
encryption metadata, but that support is best suited for a separate
interface, with RWF_ENCODED purely for the encrypted data itself. The
harder part of encrypted backups is restoring filenames, and that would
also be best as a separate interface.

My use case is only for compression, so none of that is a blocker for
RWF_ENCODED.

What else can I do to move this along?

Thanks,
Omar

      parent reply	other threads:[~2021-06-07 19:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17 18:35 [PATCH RERESEND v9 0/9] fs: interface for directly reading/writing compressed data Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 1/9] iov_iter: add copy_struct_from_iter() Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 2/9] fs: add O_ALLOW_ENCODED open flag Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 3/9] fs: add RWF_ENCODED for reading/writing compressed data Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 4/9] btrfs: don't advance offset for compressed bios in btrfs_csum_one_bio() Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 5/9] btrfs: add ram_bytes and offset to btrfs_ordered_extent Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 6/9] btrfs: support different disk extent size for delalloc Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 7/9] btrfs: optionally extend i_size in cow_file_range_inline() Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 8/9] btrfs: implement RWF_ENCODED reads Omar Sandoval
2021-05-17 18:35 ` [PATCH RERESEND v9 9/9] btrfs: implement RWF_ENCODED writes Omar Sandoval
2021-05-17 21:32 ` [PATCH RERESEND v9 0/9] fs: interface for directly reading/writing compressed data Linus Torvalds
2021-05-17 22:27   ` Omar Sandoval
2021-05-17 22:48     ` Eric Biggers
2021-05-17 23:25       ` Omar Sandoval
2021-05-18  0:07         ` Eric Biggers
2021-05-18  2:53         ` Theodore Y. Ts'o
2021-05-18  8:38           ` Omar Sandoval
2021-05-18 16:21             ` Theodore Y. Ts'o
2021-06-07 19:27   ` Omar Sandoval [this message]

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=YL5zCxGx/J1WxSCq@relinquished.localdomain \
    --to=osandov@osandov.com \
    --cc=amir73il@gmail.com \
    --cc=cyphar@cyphar.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=jannh@google.com \
    --cc=kernel-team@fb.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.