On 11.07.19 14:23, Max Reitz wrote: > On 11.07.19 11:20, Daniel P. Berrangé wrote: >> On Wed, Jul 10, 2019 at 11:24:46PM +0200, Max Reitz wrote:
[...] >>> Hm. I would expect a preallocated image to read 0. But if you just >>> pass this through to the protocol layer, it won’t read 0. >> >> Yes, it will be zeros at the physical layer, but unintelligble >> garbage from POV of the virtual disk. >> >> I don't think this is really a problem though - this is what you >> get already if you create a LUKS volume on top of a block device >> today. > > Which is why we have BlockDriver.bdrv_has_zero_init(), which the LUKS > driver does not implement, hence it being treated as false. > > But if you are preallocating, you have a choice of what you write, and > why not make that zeroes? > >> AFAIK, we've not documented that preallocation guarantees future >> reads will return zeros. Preallocation simply ensures that all >> required space is allocated upfront. We do mention that it might >> be achieved by writing zeros to the underlying storage but never >> said you'll get zeros back. > > But we have, as I wrote in my second reply. PreallocMode's > documentation says that at least “full” is writing zeroes, and to say > those zeroes can be anywhere in the stack is cheating, from my POV. I should add that I don’t mind changing the current documentation too much: >> IOW I think its at most a docs problem to more clearly explain >> that preallocation != guaranteed zeros for reads. If there is a good reason to do that, sure. But it needs to be done explicitly, with an accompanying justification. I don’t like just ignoring the documentation we have. (And yes, if something says “this writes zeroes”, I personally will always interpret that as “it will read as zeroes”.) Max
signature.asc
Description: OpenPGP digital signature