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?
[1] open in the cryptsetup open/luksOpen sense
--
Chris Murphy
--
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
