qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Qemu-img convert with -B


From: Kevin Wolf
Subject: Re: [Qemu-devel] Qemu-img convert with -B
Date: Wed, 27 Apr 2011 15:56:42 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10

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
>>>> <address@hidden>   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



reply via email to

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