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

[Kevin Wolf <kwolf@redhat.com>]

Am 07.09.2010 17:30, schrieb Anthony Liguori:
> On 09/07/2010 10:20 AM, Kevin Wolf wrote:
>> Am 07.09.2010 17:11, schrieb Anthony Liguori:
>>> 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.
>>    
> 
> But as a web site owner, it's extremely useful for me to associate 
> copy-on-read with an image because it significantly reduces my bandwidth.
> 
> I have a hard time believing this isn't a valuable use-case and not one 
> that's actually pretty common.

As a web site user, I don't necessarily want you to control the
behaviour of my qemu. :-)

But I do see your point there.

>>> 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)
>>    
> 
> Okay, the only place I'm disagreeing slightly is that I think an image 
> format should be able to request copy_on_read such that the default 
> behavior if an explicit flag isn't specified is to do what the image 
> suggests we do.

Maybe we can agree on that. I'm not completely decided yet if allowing
the image to contain such a hint is a good or a bad thing.

Kevin