From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:37501)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1aH6wN-0003fd-75
	for qemu-devel@nongnu.org; Thu, 07 Jan 2016 04:33:08 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1aH6wM-0007nk-8r
	for qemu-devel@nongnu.org; Thu, 07 Jan 2016 04:33:07 -0500
Date: Thu, 7 Jan 2016 17:32:56 +0800
From: Fam Zheng <famz@redhat.com>
Message-ID: <20160107093256.GA4480@ad.usersys.redhat.com>
References: <87vb7vc2yt.fsf@blackfin.pond.sub.org>
	<20151223101520.GL14423@ad.usersys.redhat.com>
	<20160104051634.GA26505@stefanha-x1.localdomain>
	<20160104072836.GA28942@ad.usersys.redhat.com>
	<20160107052318.GE12971@stefanha-x1.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160107052318.GE12971@stefanha-x1.localdomain>
Subject: Re: [Qemu-devel] [Qemu-block] Minutes from the "Stuttgart block
 Gipfele"
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-block@nongnu.org, qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>, Max Reitz <mreitz@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>

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