Thread (19 messages) 19 messages, 4 authors, 2021-06-07

Re: [PATCH RERESEND v9 0/9] fs: interface for directly reading/writing compressed data

From: Omar Sandoval <osandov@osandov.com>
Date: 2021-06-07 19:27:13
Also in: linux-api, linux-fsdevel

On Mon, May 17, 2021 at 02:32:47PM -0700, Linus Torvalds wrote:
On Mon, May 17, 2021 at 11:35 AM Omar Sandoval [off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help