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

[Kevin Wolf <kwolf@redhat.com>]

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.

>>> 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