From: David Edmondson <dme@dme.org>
To: Eric Blake <eblake@redhat.com>, Sam Eiderman <sameid@google.com>,
Kevin Wolf <kwolf@redhat.com>
Cc: Tony Zhang <tzz@google.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
Max Reitz <mreitz@redhat.com>
Subject: Re: Clarification regarding new qemu-img convert --target-is-zero flag
Date: Wed, 10 Jun 2020 16:57:45 +0100 [thread overview]
Message-ID: <m28sgu9ame.fsf@dme.org> (raw)
In-Reply-To: <999a1a74-d082-bcdb-e3f9-6c44b2526433@redhat.com>
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.
next prev parent reply other threads:[~2020-06-10 15:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-10 5:28 Clarification regarding new qemu-img convert --target-is-zero flag Sam Eiderman
2020-06-10 6:16 ` Vladimir Sementsov-Ogievskiy
2020-06-10 6:28 ` Sam Eiderman
2020-06-10 11:37 ` Kevin Wolf
2020-06-10 11:52 ` Sam Eiderman
2020-06-10 11:56 ` David Edmondson
2020-06-10 12:19 ` Sam Eiderman
2020-06-10 13:36 ` Vladimir Sementsov-Ogievskiy
2020-06-10 14:06 ` Kevin Wolf
2020-06-10 15:26 ` Sam Eiderman
2020-06-10 15:29 ` Sam Eiderman
2020-06-10 15:42 ` David Edmondson
2020-06-10 15:47 ` Sam Eiderman
2020-06-10 15:48 ` Eric Blake
2020-06-10 15:57 ` David Edmondson [this message]
2020-06-10 16:21 ` Eric Blake
2020-06-11 10:58 ` David Edmondson
2020-06-10 16:31 ` Kevin Wolf
2020-06-11 13:41 ` Sam Eiderman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m28sgu9ame.fsf@dme.org \
--to=dme@dme.org \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sameid@google.com \
--cc=tzz@google.com \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).