qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Edmondson
Subject: Re: Clarification regarding new qemu-img convert --target-is-zero flag
Date: Wed, 10 Jun 2020 16:57:45 +0100

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"?

I'd be more inclined to go for "unallocated blocks will not be written",
without any attempts to pre-zero.

> only the explicit zeroes need to be written rather than zeroes for all
> unallocated areas in the source (so the resulting image will NOT be an
> identical copy if there were any unallocated areas, but that the user
> is okay with that).

dme.
-- 
Too much information, running through my brain.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]