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

[Eric Blake <eblake@redhat.com>]

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.

> 
> 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.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org