qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] Minutes from the "Stuttgart block Gipfele"


From: Fam Zheng
Subject: Re: [Qemu-block] [Qemu-devel] Minutes from the "Stuttgart block Gipfele"
Date: Thu, 7 Jan 2016 17:32:56 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, 01/07 13:23, Stefan Hajnoczi wrote:
> 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.
> 

OK, it's more of the mental model. My point is letting the dynamic filter
reconfiguration interface manage the block job in units of filters, the
internal mechanism should be the same between "pull" filter and "mirror" job
coroutine.

Fam




reply via email to

[Prev in Thread] Current Thread [Next in Thread]