On 2016-03-01 23:48, Anand Jain wrote:
On 03/02/2016 02:23 AM, Chris Mason wrote:
On Tue, Mar 01, 2016 at 09:59:27AM -0800, Christoph Hellwig wrote:
On Tue, Mar 01, 2016 at 11:46:16AM -0500, Chris Mason wrote:
We'll definitely move in line with the common API over time. Thanks
Anand for starting this!
I'd prefer that we keep it per-subvolume for now, just because
subvolumes are so cheap and because it seems like a better collection
point for general use. But as the other filesystems add features we'll
make sure and keep parity with what users expect.
We already have per-file encryption in f2fs and ext4, and both have
a compatible userspace API and ABI. It would be a pitty to deviate
from that intead of reusing it, and if needed extending it.
I wasn't very clear here sorry. per-subvolume is my favorite way, but
we'll go with the existing ABIs as well. There's no reason to be
different.
Thanks for commenting.
btrfs encryption creates attributes per file its named
btrfs.encrypt
But when we have a standard attribute for file encryption
this should be updated.
I wrote a design approaches/principles on which btrfs encryption
is based on.. and it here
https://docs.google.com/document/d/1fq9snDM_4ikn44UDNErjHqKXgZHukiJWS4Il3qVhm3M/edit?usp=sharing
FWIW, a new version of the patch series pushing the ext4/F2FS API up to
the VFS layer got posted on LKML just the other day. Based on the level
of review, it looks like it may end up in 4.6.
--
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
