From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:37337)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@redhat.com>) id 1aFxVg-00059h-NF
	for qemu-devel@nongnu.org; Mon, 04 Jan 2016 00:16:49 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@redhat.com>) id 1aFxVf-0001Jf-Rz
	for qemu-devel@nongnu.org; Mon, 04 Jan 2016 00:16:48 -0500
Date: Mon, 4 Jan 2016 13:16:34 +0800
From: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20160104051634.GA26505@stefanha-x1.localdomain>
References: <87vb7vc2yt.fsf@blackfin.pond.sub.org>
	<20151223101520.GL14423@ad.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk"
Content-Disposition: inline
In-Reply-To: <20151223101520.GL14423@ad.usersys.redhat.com>
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: Fam Zheng <famz@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>


--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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,
>=20
> mirror (device=3Dd0 target=3Dd1) becomes a pull fileter:
>=20
>         BB[d0]            BB[d1]
>            |                 |
>         throttle        [pull,src=3Dd0]
>            |                 |
>        detect-zero       detect-zero
>            |                 |
>       copy-on-read      copy-on-read
>            |                 |
>           BDS               BDS
>=20
> 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 t=
he
> 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]?

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

Stefan

--qDbXVdCdHGoSgWSk
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJWigAyAAoJEJykq7OBq3PITJoIAKo5SFFeAeOTvTZ4bUinbkeS
hTXuTHZp0QVFKvzbpdo6krvdidSmtmZtf7KtXRYIALy/+tbSt5RVZDTjvw+Xprm2
t6Dh+nKwVUSxVQJp7LgF9RMl1sjTDhyRsMw7yVNSCiHBf4m9ul73R1LGFSPH34x+
5e9AFW+Ws8mnFWe8tdQQa65Sot0FoETL37v0EieoM7YK9P2Qnp6FZgVrORTjN9vL
6cO2fkcJ29jppOkxDeGJaK2sX2GVflckdZYAePpt7AknJc8d6vIPLoXBSAUvYUlk
5Ca8fQ2T9liu1gOAi1uqTHZ4Z/QiwybSX1RQ+LnKDn9HCXpyKSMFEfwg+AKS6gw=
=8q2V
-----END PGP SIGNATURE-----

--qDbXVdCdHGoSgWSk--