On Thu, Jul 11, 2019 at 08:50:56AM -0500, Eric Blake wrote: > 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).
On the topic of scrubbing, it would actually be nice to have a "secure delete" for QEMU block driver formats that can do some level of scrubbing in software and/or calling out to hardware support. Similarly to prealloc a choice of 'metadata' or 'full'. Wwith LUKS you can do well by just scrubbing the image header (which kills the master decryption key rendering payload useless). Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|