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 12:06:36 +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 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.

>>> Can someone verify these assumptions for me please?
>>> - I can bdrv_open() a file that has a chain of backing files, and the
>>> following is true :
>>>         - bdrv_read() returns the most recently allocated sector contents 
>>> (or
>>> 0)
>> Correct.
>>
>>>         - bdrv_is_allocated() will return false only if that sector is not
>>> allocated in _any_ of the files in the chain
>> Incorrect.  It returns true if the sector is allocated in the top-most
>> file, false otherwise.  In other words bdrv_is_allocated() is flat, it
>> does not traverse a chain of backing files.
> 
> Right.
> 
> I guess the correct way to do this is to open and traverse all the input and 
> output backing files, 
> but I don't see why that should be necessary as the output file is created 
> O_RDWR.
> 
> Now as the output file is created with the backing_file option, can I simply 
> bdrv_read() both input 
> and output files, and only write to the output file if the sector differs or 
> != 0? Seems like that 
> would be the logical way to do everything right while leveraging the 
> complexity of the block 
> drivers. It would also allow for maximum "compression" of the output file if 
> the filesystem has all 
> unused space wiped (which is my desired usage case).

qemu-img convert -B is supposed to work only with unchanged backing
files! I'm not aware of any major use cases besides renaming the backing
file (for which rebase -u exists today), so it's only there for
compatibility reasons.  What you describe looks much more like qemu-img
rebase.

Kevin



reply via email to

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