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 following method to support dedup and
compression while still using most of CPU cores like compression:
Old compression only implement:
inode needs compress will go into async_cow_start()
async_cow_start()
|- compress_file_range()
Compression with dedup implement:
inode needs compress *OR* dedup will go into async_cow_start()
async_cow_start()
|
|- if (!inode_need_dedup())
| |- compress_file_range() <<Just as normal one
| |- btrfs_compress_pages()
| |- add_async_extent()
|
|- else
|- hash_file_range() <<Calculate file hashes
|- normal dedup hash
|- if (inode_need_compress())
| |- btrfs_compress_pages()
|- add_async_extent()
Although not the most elegant method, but it shows that we can
co-operate compress and encrypt.
However the most elegant method, is to rework current cow_file_range()
and its variant, to an unified btrfs internal API.
Thanks for this. Right. Currently there is no elegant way of doing it.
Tried a bit of juggles. Unless rework.
But I am confused. Are you suggesting we should cascade compress engine
and then an encryption engine ?
Just a suggestion.
As personally, I'd like to separate compression and encryption work.
Although most of encryption is just like compression, it's still a
little differnet, especially for the need of encryption/decryption key
unlike compression.
And in fact, compression then encrypt is quite common in this days, a
lot of gzipped data is transmitted by TLS, so the need may exist though.
Although it's also acceptable not to support compression with
encryption, just for simple implementation in kernel.
Austin said against such an approach.
And I have included it under limitation section just to mention, and
what's the idea if at all someone seeks such a configurations, which
is to use engine which provides both instead.
Another reason I mention this idea, is we're considering rework the
current run_delalloc_range(), to provide a unified, re-entry friendly,
and independent framework for the growing need of different data
processing method.
Including normal cow,no data cow, inline, compress, dedup, and hopefully
encryption.
But current one is good enough for the RFC usage.
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
