Re: Clarification regarding new qemu-img convert --target-is-zero flag

[David Edmondson <dme@dme.org>]

On Wednesday, 2020-06-10 at 11:21:27 -05, Eric Blake wrote:

> On 6/10/20 10:57 AM, David Edmondson wrote:
>> On Wednesday, 2020-06-10 at 10:48:52 -05, Eric Blake wrote:
>> 
>>> On 6/10/20 10:42 AM, David Edmondson wrote:
>>>> On Wednesday, 2020-06-10 at 18:29:33 +03, Sam Eiderman wrote:
>>>>
>>>>> Excuse me,
>>>>>
>>>>> Vladimir already pointed out in the first comment that it will skip
>>>>> writing real zeroes later.
>>>>
>>>> Right. That's why you want something like "--no-need-to-zero-initialise"
>>>> (the name keeps getting longer!), which would still write zeroes to the
>>>> blocks that should contain zeroes, as opposed to writing zeroes to
>>>> prepare the device.
>>>
>>> Or maybe something like:
>>>
>>> qemu-img convert --skip-unallocated
>> 
>> This seems fine.
>> 
>>> which says that a pre-zeroing pass may be attempted, but it if fails,
>> 
>> This bit puzzles me. In what circumstances might we attempt but fail?
>> Does it really mean "if it can be done instantly, it will be done, but
>> not if it costs something"?
>
> A fast pre-zeroing pass is faster than writing explicit zeroes.  If such 
> a fast pass works, then you can avoid further I/O for all subsequent 
> zero sections; the unallocated sections will now happen to read as zero, 
> but that is not a problem since the content of unallocated portions is 
> not guaranteed.
>
> But if pre-zeroing is not fast, then you have to spend the extra I/O to 
> explicitly zero the portions that are allocated but read as zero, while 
> still skipping the unallocated portions.

The lack of deterministic behaviour would worry me. If the caller can't
be sure whether the unallocated portions of the device will be zeroed or
not, it feels as though the number of potential use cases is reduced.

The optimisation is focused on images where there are a significant
number of allocated zero blocks. Is that a common case? (It obviously
exists, because many images generated before "--target-is-zero" will be
like that, but perhaps they would be better cleaned by an unallocator.)

>> I'd be more inclined to go for "unallocated blocks will not be written",
>> without any attempts to pre-zero.
>
> But that can be slower, when pre-zeroing is fast.  "Unallocated blocks 
> need not be written" allows for optimizations, "unallocated blocks must 
> not be touched" does not.

"unallocated blocks may not be written" would be fine.

dme.
-- 
There is love in you.