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
