qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kevin Wolf
Subject: Re: [Qemu-devel] Image streaming and live block copy
Date: Thu, 16 Jun 2011 15:50:38 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]