[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] Minutes from the "Stuttgart block Gipfele"
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [Qemu-block] Minutes from the "Stuttgart block Gipfele" |
Date: |
Thu, 7 Jan 2016 13:23:18 +0800 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Mon, Jan 04, 2016 at 03:28:36PM +0800, Fam Zheng wrote:
> On Mon, 01/04 13:16, Stefan Hajnoczi wrote:
> > On Wed, Dec 23, 2015 at 06:15:20PM +0800, Fam Zheng wrote:
> > > On Fri, 12/18 14:15, Markus Armbruster wrote:
> > > In that theory, all other block job types, mirror/stream/commit, fit into
> > > a
> > > "pull" model, which follows a specified dirty bitmap and copies data from
> > > a
> > > specified src BDS. In this pull model,
> > >
> > > mirror (device=d0 target=d1) becomes a pull fileter:
> > >
> > > BB[d0] BB[d1]
> > > | |
> > > throttle [pull,src=d0]
> > > | |
> > > detect-zero detect-zero
> > > | |
> > > copy-on-read copy-on-read
> > > | |
> > > BDS BDS
> > >
> > > Note: the pull reuses most of the block/mirror.c code except the
> > > s->dirty_bitmap will be initialized depending on the block job type. In
> > > the
> > > case of mirror, it is trivially the same as now.
> >
> > I don't understand the pull filter. Is there also a mirror block job
> > coroutine?
> >
> > Does anything perform I/O to BB[d1]?
>
> Yes, the filter will have a mirror block job coroutine, and it writes to the
> BDS behind BB[d1]. This is conceptually different from the "block jobs have
> their own BBs" design.
Are any of the pull filter's callbacks (.bdrv_co_readv(),
.bdrv_co_writev()) being invoked?
I still don't understand your idea because it seems like the coroutine
is doing all the work and the filter serves no purpose.
Stefan
signature.asc
Description: PGP signature