On 2020/12/18 19:53, Satya Tangirala wrote:
On Fri, Dec 18, 2020 at 05:02:23PM +0800, Chao Yu wrote:
On 2020/12/17 23:44, Satya Tangirala wrote:
On Sat, Oct 10, 2020 at 05:53:06PM +0800, Chao Yu wrote:
Why not using nid as DUN, then GC could migrate encrypted node block directly
via
meta inode's address space like we do for encrypted data block, rather than
decrypting node block to node page and then encrypting node page with DUN of new
blkaddr it migrates to.
The issue is, the bi_crypt_context in a bio holds a single DUN value,
which is the DUN for the first data unit in the bio. blk-crypto assumes
that the DUN of each subsequent data unit can be computed by simply
incrementing the DUN. So physically contiguous data units can only be put
into the same bio if they also have contiguous DUNs. I don't know much
about nids, but if the nid is invariant w.r.t the physical block location,
then there might be more fragmentation of bios in regular read/writes
Correct, considering performance of in batch node flush, it will be better to
use pba as IV value.
But, what's the plan about supporting software encryption for metadata? Current
f2fs write flow will handle all operations which may encounter failure before
allocating block address for node, if we do allocation first, and then use pba
as IV to encrypt node block, it will be a little complicated to revert
allocation
if we fail to encrypt node block.
Software encryption for metadata is supported through the blk-crypto
blk-crypto will encrypt all data in filesystem, if FBE is enabled, data may
be encrypted twice?
And why not supporting hardware encryption for metadata in blk-crypto? then
both f2fs and ext4 can use inline-encryption based blk-crypto?
Thanks,
framework - so encryption will happen in the block layer, not the
filesystem layer. So there's nothing extra/special we need to do if
there's an encryption failure - an encryption failure is no different
from a read/write failure in a lower layer from f2fs' perspective.
.
