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? > 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. Kevin -- 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
