[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Generic image streaming
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [RFC] Generic image streaming |
Date: |
Tue, 27 Sep 2011 09:37:23 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Tue, Sep 27, 2011 at 11:26:45AM +0800, Zhi Yong Wu wrote:
> On Fri, Sep 23, 2011 at 11:57 PM, Stefan Hajnoczi
> <address@hidden> wrote:
> > Here is my generic image streaming branch, which aims to provide a way
> > to copy the contents of a backing file into an image file of a running
> > guest without requiring specific support in the various block drivers
> > (e.g. qcow2, qed, vmdk):
> >
> > http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/image-streaming-api
> >
> > The tree does not provide full image streaming yet but I'd like to
> > discuss the approach taken in the code. Here are the main points:
> >
> > The image streaming API is available through HMP and QMP commands. When
> > streaming is started on a block device a coroutine is created to do the
> > background I/O work. The coroutine can be cancelled.
> >
> > While the coroutine copies data from the backing file into the image
> > file, the guest may be performing I/O to the image file. Guest reads do
> > not conflict with streaming but guest writes require special handling.
> > If the guest writes to a region of the image file that we are currently
> > copying, then there is the potential to clobber the guest write with old
> > data from the backing file.
> >
> > Previously I solved this in a QED-specific way by taking advantage of
> > the serialization of allocating write requests. In order to do this
> > generically we need to track in-flight requests and have the ability to
> > queue I/O. Guest writes that affect an in-flight streaming copy
> > operation must wait for that operation to complete before being issued.
> > Streaming copy operations must skip overlapping regions of guest writes.
> >
> > One big difference to the QED image streaming implementation is that
> > this generic implementation is not based on copy-on-read operations.
> > Instead we do a sequence of bdrv_is_allocated() to find regions for
> > streaming, followed by bdrv_co_read() and bdrv_co_write() in order to
> Why is the api not bdrv_aio_readv/writev? In your branch, it seems
> that you only modify bdrv_read/write. Does your branch currently only
> support sync read/write mode?
No, it is designed to work with all three: aio, co, and sync.
The streaming loop itself is in a coroutine but it will be able to
interact with any other block I/O requests. The critical part is the
request tracking here, which monitors aio, co, and sync:
http://repo.or.cz/w/qemu/stefanha.git/commitdiff/cf365d4e33ba19fadd4f1f20c64526e890d34239
Stefan
Re: [Qemu-devel] [RFC] Generic image streaming, Marcelo Tosatti, 2011/09/26
Re: [Qemu-devel] [RFC] Generic image streaming, Zhi Yong Wu, 2011/09/26
- Re: [Qemu-devel] [RFC] Generic image streaming,
Stefan Hajnoczi <=
Re: [Qemu-devel] [RFC] Generic image streaming, Zhi Yong Wu, 2011/09/27