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
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