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

[Kevin Wolf <kwolf@redhat.com>]

Am 16.06.2011 16:38, schrieb Marcelo Tosatti:
> On Thu, Jun 16, 2011 at 02:35:37PM +0200, Kevin Wolf wrote:
>> Am 14.06.2011 20:18, schrieb Stefan Hajnoczi:
>>> Overview
>>> --------
>>>
>>> This patch series adds image streaming support for QED image files.  Other
>>> image formats can also be supported in the future.
>>>
>>> Image streaming populates the file in the background while the guest is
>>> running.  This makes it possible to start the guest before its image file has
>>> been fully provisioned.
>>>
>>> Example use cases include:
>>>  * Providing small virtual appliances for download that can be launched
>>>    immediately but provision themselves in the background.
>>>  * Reducing guest provisioning time by creating local image files but backing
>>>    them with shared master images which will be streamed.
>>>
>>> When image streaming is enabled, the unallocated regions of the image file are
>>> populated with the data from the backing file.  This occurs in the background
>>> and the guest can perform regular I/O in the meantime.  Once the entire backing
>>> file has been streamed, the image no longer requires a backing file and will
>>> drop its reference
>>
>> Long CC list and Kevin wearing his upstream hat - this might be an
>> unpleasant email. :-)
>>
>> So yesterday I had separate discussions with Stefan about image
>> streaming and Marcelo, Avi and some other folks about live block copy.
>> The conclusion was in both cases that, yes, both things are pretty
>> similar and, yes, the current implementation don't reflect that but
>> duplicate everything.
>>
>> 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
>>
>> The right solution is probably to implement COR and the background task
>> in generic block layer code (no reason to restrict it to QED) and use it
>> for both image streaming and live block copy. (This is a bit more
>> complicated than it may sound here because guest writes must always take
>> precedence over a copy - but doing complicated things is an even better
>> reason to do it in a common place instead of duplicating)
>>
>> People seem to agree on this, and the reason that I've heard why we
>> should merge the existing code instead is downstream time pressure. That
>> may be a valid reason for downstreams to add such code, but is taking
>> such code really the best option for upstream (and therefore long-term
>> for downstreams)?
>>
>> If we take these patches as they are, I doubt that we'll ever get a
>> rewrite to implement the code as it should have been done in the first
>> place.
> 
> That (a newer, unified mechanism) is just a matter of allocating
> resources to the implementation.
> 
> At least in block copy's case the interface can be reused, so it can be
> seen as an incremental approach (read: advocating in favour of merging
> live block copy patchset).

Right. However, my point was that I'm afraid that this resource
allocation and therefore the incremental improvement won't happen
because for most people (who don't care about the code) the result will
be "good enough" and the problem will only be visible for block layer
people who must work with the code.

Kevin