On 04.02.20 18:51, Eric Blake wrote: > On 2/4/20 11:42 AM, Max Reitz wrote: > >>> >>> I understand that this is preexisting logic, but could I ask: why? >>> What's wrong >>> if driver can guarantee that created file is all-zero, but is not sure >>> about >>> file resizing? I agree that it's normal for these flags to have the same >>> value, >>> but what is the reason for this restriction?.. >> >> If areas added by truncation (or growth, rather) are always zero, then >> the file can always be created with size 0 and grown from there. Thus, >> images where truncation adds zeroed areas will generally always be zero >> after creation. >> >>> So, the only possible combination of flags, when they differs, is >>> create=0 and >>> truncate=1.. How is it possible? >> >> For preallocated qcow2 images, it depends on the storage whether they >> are actually 0 after creation. Hence qcow2_has_zero_init() then defers >> to bdrv_has_zero_init() of s->data_file->bs. >> >> But when you truncate them (with PREALLOC_MODE_OFF, as >> BlockDriver.bdrv_has_zero_init_truncate()’s comment explains), the new >> area is always going to be 0, regardless of initial preallocation. >> >> >> I just noticed a bug there, though: Encrypted qcow2 images will not see >> areas added through growth as 0. Hence, qcow2’s >> bdrv_has_zero_init_truncate() implementation should not return true >> unconditionally, but only for unencrypted images. > > Hence patch 5 earlier in the series :)
Ah, good. :-) Max
signature.asc
Description: OpenPGP digital signature
