From: Kevin Wolf <kwolf@redhat.com>
To: Sam Eiderman <sameid@google.com>
Cc: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-block@nongnu.org, David Edmondson <dme@dme.org>,
qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>,
Tony Zhang <tzz@google.com>
Subject: Re: Clarification regarding new qemu-img convert --target-is-zero flag
Date: Wed, 10 Jun 2020 16:06:20 +0200 [thread overview]
Message-ID: <20200610140620.GE6947@linux.fritz.box> (raw)
In-Reply-To: <CAFr6bUk5LrEL8BPXYkNOqj_jsbxHBfbj_NYryUjszMtG89L+2w@mail.gmail.com>
Am 10.06.2020 um 14:19 hat Sam Eiderman geschrieben:
> Thanks David,
>
> Yes, I imaging the following use case:
>
> disk.vmdk is a 50 GB disk that contains 12 MB binary of zeroes in its beginning.
> /dev/sda is a raw disk containing garbage
>
> I invoke:
> qemu-img convert disk.vmdk -O raw /dev/sda
>
> Required output:
> The first 12 MB of /dev/sda contain zeros, the rest garbage, qemu-img
> finishes fast.
>
> Kevin, from what I understood from you, this is the default behavior.
Sorry, I misunderstood what you want. qemu-img will write zeros to all
unallocated parts, too. If it didn't do that, the resulting image on
/dev/sda wouldn't be a copy of disk.vmdk.
As the metadata (which blocks are allocated) cannot be preserved in raw
images, you wouldn't be able to tell which part of the image contains
valid data and which part needs to be interpreted as zeros even though
it contains random garbage.
What is your use case for this result where the actual virtual disk
content is mixed with garbage?
Kevin
next prev parent reply other threads:[~2020-06-10 14:07 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 [this message]
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
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=20200610140620.GE6947@linux.fritz.box \
--to=kwolf@redhat.com \
--cc=dme@dme.org \
--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).