From: Kevin Wolf <kwolf@redhat.com>
To: Brad Campbell <lists2009@fnarfbargle.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Qemu-img convert with -B
Date: Wed, 27 Apr 2011 15:56:42 +0200 [thread overview]
Message-ID: <4DB8209A.7070400@redhat.com> (raw)
In-Reply-To: <4DB81E16.5010408@fnarfbargle.com>
Am 27.04.2011 15:45, schrieb Brad Campbell:
> On 27/04/11 18:06, Kevin Wolf wrote:
>> Am 27.04.2011 10:56, schrieb Brad Campbell:
>>> On 27/04/11 16:10, Stefan Hajnoczi wrote:
>>>> On Wed, Apr 27, 2011 at 4:05 AM, Brad Campbell
>>>> <lists2009@fnarfbargle.com> wrote:
>>>>> I see there is a bug raised about the behaviour of qemu-img when used to convert using an output backing file. It allocates every sector whether or not it already exists in the output backing file.
>>>> Please post the link to the bug report.
>>>>
>>> Yeah, sorry about that. Not very clever of me.
>>>
>>> https://bugs.launchpad.net/qemu/+bug/660366
>>
>> I think this bug is fixed by commit a18953fb.
>
> And indeed it is. Thus while the issue I'm facing looks like that bug,
> it's either another one or my misunderstanding about how backing files work.
>
> So what is happening here then?
>
> - create 1.img as a 20G qcow2
> - 1.img is 193k
> - Install windows XP into 1.img
> - 1.img is 1.5G
> - create 2.img as a qcow2 with 1.img as a backing file.
> - 2.img is ~150k
> - Install/uninstall and generally use 2.img
> - 2.img is 7G
> - Mount 2.img with systemrescuecd and use ntfswipe -a which zero's all
> unused data and cluster tails.
> - 2.img is 20G
> - qemu-img convert -O qcow2 -o backing_file 1.img 2.img 3.img
> - 3.img is 20G
>
> If I do the same process without the backing file..
>
> - create 1.img as a 20G qcow2
> - 1.img is 193k
> - Install windows XP into 1.img
> - 1.img is 1.5G
> - Install/Uninstall and generally use 1.img
> - 1.img is 7G
> - Mount 1.img with systemrescuecd and use ntfswipe
> - 1.img is 20G
> - qemu-img convert -O qcow2 1.img 3.img
> - 3.img is 4G
>
> Why does the first example write out all the zeroed sectors into the
> image while the second one doesn't?
When you don't have a backing file, leaving an cluster unallocated means
that it's zero. When you have a backing file, it could be anything. So
if qemu-img convert wanted to save this space, it would have to read
from the backing file and leave the cluster unallocated if it reads as zero.
This is something that qemu-img doesn't do today.
Kevin
next prev parent reply other threads:[~2011-04-27 13:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-27 3:05 [Qemu-devel] Qemu-img convert with -B Brad Campbell
2011-04-27 8:10 ` Stefan Hajnoczi
2011-04-27 8:56 ` Brad Campbell
2011-04-27 10:06 ` Kevin Wolf
2011-04-27 13:45 ` Brad Campbell
2011-04-27 13:56 ` Kevin Wolf [this message]
2011-04-27 14:02 ` Brad Campbell
2011-04-28 2:06 ` Brad Campbell
2011-04-28 6:36 ` Kevin Wolf
2011-04-28 9:38 ` Brad Campbell
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=4DB8209A.7070400@redhat.com \
--to=kwolf@redhat.com \
--cc=lists2009@fnarfbargle.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.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).