From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:52426)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1aFzZQ-00014d-PC
	for qemu-devel@nongnu.org; Mon, 04 Jan 2016 02:28:49 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1aFzZP-0005GA-SZ
	for qemu-devel@nongnu.org; Mon, 04 Jan 2016 02:28:48 -0500
Date: Mon, 4 Jan 2016 15:28:36 +0800
From: Fam Zheng <famz@redhat.com>
Message-ID: <20160104072836.GA28942@ad.usersys.redhat.com>
References: <87vb7vc2yt.fsf@blackfin.pond.sub.org>
	<20151223101520.GL14423@ad.usersys.redhat.com>
	<20160104051634.GA26505@stefanha-x1.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160104051634.GA26505@stefanha-x1.localdomain>
Subject: Re: [Qemu-devel] 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@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Alberto Garcia <berto@igalia.com>, qemu-block@nongnu.org, qemu-devel@nongnu.org, Jeff Cody <jcody@redhat.com>, Markus Armbruster <armbru@redhat.com>, Max Reitz <mreitz@redhat.com>, John Snow <jsnow@redhat.com>

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.

> 
> If nothing is writing to/reading from BB[d1], then I don't understand
> the purpose of the pull filter.
> 
> Stefan