Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration

[Kevin Wolf <kwolf@redhat.com>]

Am 07.09.2010 17:11, schrieb Anthony Liguori:
> On 09/07/2010 10:02 AM, Kevin Wolf wrote:
>> Am 07.09.2010 16:49, schrieb Anthony Liguori:
>>    
>>>> Shouldn't it be a runtime option? You can use the very same image with
>>>> copy-on-read or copy-on-write and it will behave the same (execpt for
>>>> performance), so it's not an inherent feature of the image file.
>>>>
>>>>        
>>> The way it's implemented in QED is that it's a compatible feature.  This
>>> means that implementations are allowed to ignore it if they want to.
>>> It's really a suggestion.
>>>      
>> Well, the point is that I see no reason why an image should contain this
>> suggestion. There's really nothing about an image that could reasonably
>> indicate "use this better with copy-on-read than with copy-on-write".
>>
>> It's a decision you make when using the image.
>>    
> 
> Copy-on-read is, in many cases, a property of the backing file because 
> it suggests that the backing file is either very slow or potentially 
> volatile.

The simple copy-on-read without actively streaming the rest of the image
is not enough anyway for volatile backing files.

> IOW, let's say I'm an image distributor and I want to provide my images 
> in a QED format that actually streams the image from an http server.  I 
> could provide a QED file without a copy-on-read bit set but I'd really 
> like to convey this information as part of the image.
> 
> You can argue that I should provide a config file too that contained the 
> copy-on-read flag set but you could make the same argument about backing 
> files too.

No. The image is perfectly readable when using COW instead of COR. On
the other hand, it's completely meaningless without its backing file.

>>> So yes, you could have a run time switch that overrides the feature bit
>>> on disk and either forces copy-on-read on or off.
>>>
>>> Do we have a way to pass block drivers run time options?
>>>      
>> We'll get them with -blockdev. Today we're using colons for format
>> specific and separate -drive options for generic things.
>>    
> 
> That's right.  I think I'd rather wait for -blockdev.

Well, then I consider -blockdev a dependency of QED (the copy-on-read
part at least) and we can't merge it before we have -blockdev.

>>> You need to understand the cluster boundaries in order to optimize the
>>> metadata updates.  Sure, you can expose interfaces to the block layer to
>>> give all of this info but that's solving the same problem for doing
>>> block level copy-on-write.
>>>
>>> The other challenge is that for copy-on-read to be efficiently, you
>>> really need a format that can distinguish between unallocated sectors
>>> and zero sectors and do zero detection during the copy-on-read
>>> operation.  Otherwise, if you have a 10G virtual disk with a backing
>>> file that's 1GB is size, copy-on-read will result in the leaf being 10G
>>> instead of ~1GB.
>>>      
>> That's a good point. But it's not a reason to make the interface
>> specific to QED just because other formats would probably not implement
>> it as efficiently.
> 
> You really can't do as good of a job in the block layer because you have 
> very little info about the characteristics of the disk image.

I'm not saying that the generic block layer should implement
copy-on-read. I just think that it should pass a run-time option to the
driver - maybe just a BDRV_O_COPY_ON_READ flag - instead of having the
information in the image file. From a user perspective it should look
the same for qed, qcow2 and whatever else (like copy-on-write today)

Kevin