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

[Kevin Wolf <kwolf@redhat.com>]

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.

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

>> Doing it this way has the additional advantage that you need no image
>> format support for this, so we could implement copy-on-read for other
>> formats, too.
>>    
> 
> To do it efficiently, it really needs to be in the format for the same 
> reason that copy-on-write is part of the format.

Copy-on-write is not part of the format, it's a way of how to use this
format. Backing files are part of the format, and they are used for both
copy-on-write and copy-on-read. Any driver implementing a format that
has support for backing files should be able to implement copy-on-read.

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

Kevin