Thanks for the comments. Pls see inline below..
On 09/15/2016 01:38 PM, Chris Murphy wrote:
On Tue, Sep 13, 2016 at 7:39 AM, Anand Jain <anand.j...@oracle.com> wrote:
This patchset adds btrfs encryption support.
The main objective of this series is to have bugs fixed and stability.
I have verified with fstests to confirm that there is no regression.
A design write-up is coming next, however here below is the quick example
on the cli usage. Please try out, let me know if I have missed something.
What's the behavior with nested subvolumes having different keys?
subvolume A (encrypted with key A)
|
- subvolume B (encrypted with key B)
Without encryption I can discover either A or B whether top-level, A,
or B are mounted.
With encryption, must A be opened [1] for B to be discovered? Must A
be opened before B can be opened? Or is the subvolume metadata always
non-encrypted, and it's just file extents that are encrypted? Are
filenames in those subvolumes discoverable (e.g. btrfs-debug-tree,
btrfs-image) if the subvolume is not opened? And reflink handling
between subvolumes behaves how?
nested encrypting subvolume isn't supported, its just that it wasn't
in my mind or the use case analysis review which I did, didn't tell
me that. However I did a bit of code changes, its not that tough to
get that in the current setup though. Yes only extent encrypted.
Thanks, Anand
[1] open in the cryptsetup open/luksOpen sense
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
