Re: [RFC] Experimental btrfs encryption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux