On Fri, Jun 17, 2011 at 10:36:21AM +0200, Kevin Wolf wrote: > Am 16.06.2011 16:52, schrieb Marcelo Tosatti: > > On Thu, Jun 16, 2011 at 03:08:30PM +0200, Kevin Wolf wrote: > >> Am 16.06.2011 14:49, schrieb Avi Kivity: > >>> On 06/16/2011 03:35 PM, Kevin Wolf wrote: > >>>> * Image streaming is a normal image file plus copy-on-read plus a > >>>> background task that copies data from the source image > >>> > >>> Or a block-mirror started in degraded mode. > >> > >> At least not in the same configuration as with live block copy: You > >> don't want to write to the source, you only want to read from it when > >> the destination doesn't have the data yet. > >> > >>>> * Live block copy is a block-mirror of two normal image files plus a > >>>> background task that copies data from the source image > >>> > >>> = block-mirror started in degraded mode > >> > >>>> 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) > >>> > >>> Or in a block-mirror block format driver - generic code need not be > >>> involved. > >> > >> Might be an option. In this case generic code is only involved with the > >> stacking of BlockDriverStates, which is already implemented (but > >> requires -blockdev for a sane way to configure things). > >> > >> Kevin > > > > What are the disadvantages of such an approach for image streaming, > > versus the current QED approach? > > > > blkstream block driver: > > > > - Maintain in memory whether given block is allocated in local image, > > if not, read from remote, write to local. Set block as local. > > Local and remote simply two block drivers from image streaming driver > > POV. > > Why maintain it in memory? We already have mechanisms to track this in > COW image formats, so that you can even continue after a crash. > > We can still add a raw-cow driver that maintains the COW data in memory > for allowing raw copies, if this is needed.
Well, then image streaming is not for generic-format anymore. OK, the uptodate information can live in disk if supported by the lower level format. > > - Once all blocks are local, notify mgmt so it can switch to local > > copy. > > - Writes are mirrored to source and destination, minding guest writes > > over copy writes. > > Image streaming shouldn't write to the source. But adding a flag for > this isn't a major problem. OK, block copy does write to the source. > > Over this scheme, you'd have: > > > > 1) Block copy. > > Reopen image to be copied with > > blkstream:/path/to/current-image:/path/to/destination-image, > > background read sectors 0...N. > > > > 2) Image stream: > > blkstream:remote-image:/path/to/local-image, > > background read sectors 0...N. > > > > Where remote-image is remote accessible image such as NBD. > > I think that should work. > > By the way, we'll get problems with the colon syntax. Without -blockdev > we'll have to invent a new syntax, maybe with brackets: > > blkstream:[nbd:localhost]:out.qcow2 > > Kevin
