On 7/11/19 7:24 AM, Max Reitz wrote: >>> So it isn’t just me who expects these to pre-initialize the image to 0. >>> Hm, although... I suppose @falloc technically does not specify whether >>> the data reads as zeroes. I kind of find it to be implied, but, well... >> >> I personally don't really think that zeros are important, but rather the >> level of allocation. >> posix_fallocate probably won't write the data blocks but rather only the >> inode metadata / used block bitmap/etc. >> >> On the other hand writing zeros (or anything else) will force the block >> layer to actually write to the underlying >> storage which could trigger lower layer allocation if the underlying storage >> is thin-provisioned. >> >> In fact IMHO, instead of writing zeros, it would be better to write random >> garbage instead (or have that as an even 'fuller' >> preallocation mode), since underlying storage might 'compress' the zeros. > > Which is actually an argument why you should just write zeroes on the > LUKS layer, because this will then turn into quasi-random data on the > protocol layer.
We want preallocation to be fast (insofar as possible). Writing zeroes in LUKS is not fast, because it forces random data on the protocol layer; while writing zeroes on the protocol layer can be fast, even if it reads back as random on the LUKS layer. If you WANT to guarantee reading zeroes, that's image scrubbing, not preallocation. I think this patch is taking the right approach, of letting the underlying layer allocate data efficiently (but the burden is then on the underlying layer to actually allocate data, and not optimize by compressing zeroes into non-allocated storage). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
