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