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

[Eric Blake]

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