Re: [Qemu-devel] Image streaming and live block copy

[Kevin Wolf <kwolf@redhat.com>]

Am 16.06.2011 15:10, schrieb Anthony Liguori:
> On 06/16/2011 07:35 AM, Kevin Wolf wrote:
>> To summarise what both things are about:
>>
>> * Image streaming is a normal image file plus copy-on-read plus a
>> background task that copies data from the source image
>> * Live block copy is a block-mirror of two normal image files plus a
>> background task that copies data from the source image
> 
> Is this correct in practice?
> 
> Image streaming has the following semantics for A -> B where B is the 
> backing file of A.

That B is a backing file of A is an implementation detail and not a
requirement.

> 1) All writes go to A.
> 2) If a read can be satisified by A, read from A, else read from B, copy 
> to A, then return
> 
> Block copy has the following semantics where A is the source and B is 
> the destination.
> 
> 1) All reads and writes go to A
> 2) Copy data from B to A in the background
> 3) When B matches the content of A, switch over to B

3) is optional, it would be like adding an item for image streaming that
it drops the backing file as soon as everything has been copied.

> Other than at a hand wave, they both do copies, I'm not sure I see the 
> overlap in implementations.

One thing is handling concurrent requests. If there's a concurrent guest
write request, it must always have precedence over the background copy/COR.

And even if we couldn't use a common implementation for live block copy
and image streaming, I think it's something that shouldn't be duplicated
for copy on read in each image format driver. I think it's possible to
have a generic COR implementation that would not only work for QED, but
also for qcow2, VMDK and any other format implementing backing files
without adding code to each driver.

Kevin