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
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.
That's right, if can be done in one iteration, that's best.
Maybe I'm ignorant about encryption, but it seems the design goal of
current block encryption is safety (confusion and diffusion), and
normally same plaintext and ciphertext size.
So it may be a little difficult to find such encryption/compression
algorithm.
And even found, we may need to implement it in kernel, if we're the only
user, Linus may not be happy with that though.
Another concern is, if using that method, encryption and compression
must be bond together, make things a little unflex, especially for
subvolume level encryption.
But that's all my assumption.
Maybe current encryption and compression conflicts method is the best,
as it's so easy for user to compression a file in user space.
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.
OK, I'll just forgot this corner and focus on current implement.
Good job on bringing encryption to the view of most developers.
Thanks,
Qu
Thanks, Anand
--
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
