On Thu, Mar 03, 2016 at 09:58:53AM +0800, Anand Jain wrote:
> . (I received couple of private emails on this, so looks like
> I confused you and I'm writing again to clear the air on this).
>
> > - Uses btrfs compression framework, so compression and then
> >encryption is not possible.
On Mittwoch, 2. März 2016 09:06:57 CET Qu Wenruo wrote:
> And maybe I just missed something, but the filename seems not touched,
> meaning it will leak a lot of information.
> Just like default eCryptfs behavior.
>
> I understand that's an easy design and it's not a high priority thing,
> but I
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
The way btrfs encryption interacts with the keyring APIs is important, and
"reconsidering later" will potentially represent an API/ABI break. Please
keep it in mind.
Yep. We would take considerable time to get the API frozen and
integrated, as once its in, its there forever. So there are
Qu Wenruo cn.fujitsu.com> writes:
> > - As of now uses "user" keytype, I am still considering/
> >evaluating other key type such as logon.
>
> UI things can always be reconsidered later.
> Never a big problem.
This is not only a UI concern, but an API/ABI concern.
To use eCryptFS as an
. (I received couple of private emails on this, so looks like
I confused you and I'm writing again to clear the air on this).
- Uses btrfs compression framework, so compression and then
encryption is not possible. However yet evaluate if there
are encryption algorithm which can
Anand Jain wrote on 2016/03/02 17:09 +0800:
Hi Qu,
Not only move, but also reflink/inband dedup.
oh yes thanks. I shall add those.
Yes, but in fact, you can use another method, just like in-band de-dup,
by adding new hook into async_cow_start() and async_cow_end(), allowing
Anand Jain wrote on 2016/03/02 16:50 +0800:
Thanks! for commenting Qu.
As you are working near these codes appreciate any
code review comments.
+1 here, but in fact, it's easy to deal with.
As long as not implement encryption as a compression method.
Just like inband dedup, we use the
Hi Qu,
Not only move, but also reflink/inband dedup.
oh yes thanks. I shall add those.
Yes, but in fact, you can use another method, just like in-band de-dup,
by adding new hook into async_cow_start() and async_cow_end(), allowing
compression and encryption can be done at the same time.
Thanks! for commenting Qu.
As you are working near these codes appreciate any
code review comments.
+1 here, but in fact, it's easy to deal with.
As long as not implement encryption as a compression method.
Just like inband dedup, we use the following method to support dedup and
Thanks Austin for commenting.
Yes to most of it. And probably I should have titled known-issues
to known-bugs, which I meant to fix before final integration.
In general:
Its good to explore options of both compression+encryption OR an
algorithm engine which can automatically do both
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
Austin S. Hemmelgarn wrote on 2016/03/01 11:41 -0500:
On 2016-03-01 11:08, Anand Jain wrote:
This patchset adds btrfs encryption support.
While I think this is a great feature to have, I personally think we're
better off waiting for the ext4/F2FS encryption API's to get pushed up
to the VFS
Anand Jain wrote on 2016/03/02 00:08 +0800:
This patchset adds btrfs encryption support.
Warning:
The code is in prototype/experimental stage and is not suitable
for the production data yet.
Example usage:
Create an encrypted subvolume:
btrfs subvol create -e /btrfs/sv1
Paraphrase: <-
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
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
On 2016-03-01 11:46, Chris Mason wrote:
On Tue, Mar 01, 2016 at 05:29:52PM +0100, Tomasz Torcz wrote:
On Wed, Mar 02, 2016 at 12:08:09AM +0800, Anand Jain wrote:
This patchset adds btrfs encryption support.
Warning:
The code is in prototype/experimental stage and is not suitable
for the
On Tue, Mar 01, 2016 at 05:29:52PM +0100, Tomasz Torcz wrote:
> On Wed, Mar 02, 2016 at 12:08:09AM +0800, Anand Jain wrote:
> > This patchset adds btrfs encryption support.
> >
> > Warning:
> > The code is in prototype/experimental stage and is not suitable
> > for the production data yet.
>
>
On Wed, Mar 02, 2016 at 12:08:09AM +0800, Anand Jain wrote:
> This patchset adds btrfs encryption support.
>
> Warning:
> The code is in prototype/experimental stage and is not suitable
> for the production data yet.
Can you share some design documents? Will it be compatible
with existing
This patchset adds btrfs encryption support.
Warning:
The code is in prototype/experimental stage and is not suitable
for the production data yet.
Example usage:
Create an encrypted subvolume:
btrfs subvol create -e /btrfs/sv1
Paraphrase: <-
Review encryption status
btrfs subvol show
20 matches
Mail list logo
