Re: [RFC] Experimental btrfs encryption

[Anand Jain <anand.jain@oracle.com>]

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.
> (We are already testing the patch to allow dedup to cooperate with
> compression)
>
> So no need to find a encryption with can compress.
> (Never mix 2 different work together)

  I am not too sure about this. But logically if one encoding engine
  can do both that seems to be better than using two separate encoding
  engines.

> 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 hope we can encrypt the subvolume tree blocks too, if using
> per-subvolume policy.
> To provide a feature near block-level encryption.

  No you didn't miss about filename, its not there yet. Will add more
  depth, as I obtain feedback/confirmed on the approach concerns if any.

Thanks, Anand