linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: Chris Mason <clm@fb.com>, Christoph Hellwig <hch@infradead.org>,
	Tomasz Torcz <tomek@pipebreaker.pl>,
	linux-btrfs@vger.kernel.org
Subject: Re: [RFC] Experimental btrfs encryption
Date: Wed, 2 Mar 2016 12:48:07 +0800	[thread overview]
Message-ID: <56D67087.7040702@oracle.com> (raw)
In-Reply-To: <20160301182312.fdl264cxemz2fy5m@floor.thefacebook.com>




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

for your kind review.


Thanks! Anand


  reply	other threads:[~2016-03-02  4:48 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-01 16:08 [RFC] Experimental btrfs encryption Anand Jain
2016-03-01 16:08 ` [RFC PATCH 1/1] btrfs: Encryption: Add btrfs encryption support Anand Jain
2016-03-10  2:19   ` Liu Bo
2016-05-06  9:21     ` Anand Jain
2016-03-01 16:08 ` [RFC PATCH 1/2] btrfs-progs: subvolume functions reorg Anand Jain
2016-03-01 16:08 ` [RFC PATCH 2/2] btrfs-progs: Encryption: add encrypt sub cli Anand Jain
2016-03-01 16:29 ` [RFC] Experimental btrfs encryption Tomasz Torcz
2016-03-01 16:46   ` Chris Mason
2016-03-01 17:56     ` Austin S. Hemmelgarn
2016-03-01 17:59     ` Christoph Hellwig
2016-03-01 18:23       ` Chris Mason
2016-03-02  4:48         ` Anand Jain [this message]
2016-03-04 12:30           ` Austin S. Hemmelgarn
2016-03-01 16:41 ` Austin S. Hemmelgarn
2016-03-02  1:44   ` Qu Wenruo
2016-03-02  8:50     ` Anand Jain
2016-03-03  1:12       ` Qu Wenruo
2016-03-02  7:07   ` Anand Jain
2016-03-02  1:06 ` Qu Wenruo
2016-03-02  9:09   ` Anand Jain
2016-03-03  1:26     ` Qu Wenruo
2016-03-03 10:17   ` Alex Elsayed
2016-03-04  2:52     ` Anand Jain
2016-03-20 11:56   ` Martin Steigerwald
2016-03-03  1:58 ` Anand Jain
2016-03-22 14:25   ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56D67087.7040702@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=clm@fb.com \
    --cc=hch@infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=tomek@pipebreaker.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).