On Thu, Jun 30, 2011 at 04:52:00PM +0200, Kevin Wolf wrote: > Am 30.06.2011 16:36, schrieb Marcelo Tosatti: > >> 4. Live block copy API and high-level control - the main code that > >> adds the live block copy feature. Existing patches by Marcelo, can be > >> restructured to use common core by Marcelo. > > > > Can use your proposed block_stream interface, with a "block_switch" > > command on top, so: > > > > 1) management creates copy.img with backing file current.img, allows > > access > > 2) management issues "block_switch dev copy.img" > > 3) management issues "block_stream dev base" > > Isn't this block_switch command the same as the existing snapshot_blkdev? Yep. > > Thought of implementing "block_stream" command by reopening device with > > > > blkstream:imagename.img > > > > Then: > > > > AIO_READ: > > - for each cluster in request: > > - if allocated-or-in-final-base, read. > > - check write queue, if present wait on it, if not, add "copy" > > entry to write queue. > > - issue cluster sized read from source. > > - on completion: > > - copy data to original read buffer, complete it. > > - if not cancelled, write cluster to destination. > > > > AIO_WRITE > > for each cluster in request: > > - check write queue, cancel/wait for "copy" entry. > > - add "guest" entry to write queue. > > - issue write to destination. > > - on completion: > > - remove write queue entry. > > > > > > With the 0...END background read, once it completes write final base > > file for image. > > > > So block_stream/block_stream_cancel/block_stream_status commands, the > > background read and the rebase -u update can be separate from the block > > driver. > > The way how it works looks good to me, I'm just not entirely sure about > the right place to implement it. I think request queueing and copy on > read could be useful outside blkstream, too. They could be lifted later, when there are other users. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
