From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47370) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aH32m-0004JO-KZ for qemu-devel@nongnu.org; Thu, 07 Jan 2016 00:23:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aH32l-0008RO-QC for qemu-devel@nongnu.org; Thu, 07 Jan 2016 00:23:28 -0500 Date: Thu, 7 Jan 2016 13:23:18 +0800 From: Stefan Hajnoczi Message-ID: <20160107052318.GE12971@stefanha-x1.localdomain> References: <87vb7vc2yt.fsf@blackfin.pond.sub.org> <20151223101520.GL14423@ad.usersys.redhat.com> <20160104051634.GA26505@stefanha-x1.localdomain> <20160104072836.GA28942@ad.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="brEuL7wsLY8+TuWz" Content-Disposition: inline In-Reply-To: <20160104072836.GA28942@ad.usersys.redhat.com> Subject: Re: [Qemu-devel] [Qemu-block] Minutes from the "Stuttgart block Gipfele" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Kevin Wolf , qemu-block@nongnu.org, qemu-devel@nongnu.org, Markus Armbruster , Max Reitz , Stefan Hajnoczi --brEuL7wsLY8+TuWz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 = =66rom 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 the > > > case of mirror, it is trivially the same as now. > >=20 > > I don't understand the pull filter. Is there also a mirror block job > > coroutine? > >=20 > > Does anything perform I/O to BB[d1]? >=20 > 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 ha= ve > their own BBs" design. Are any of the pull filter's callbacks (.bdrv_co_readv(), =2Ebdrv_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 --brEuL7wsLY8+TuWz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWjfZGAAoJEJykq7OBq3PIFeYH/3Tl3gxO4jXeNA9oHgRvvN9D IT1aha8k+Ie8UU24qj9+O1CfIlljUFqS9qiDMOlKwwy3SCTyR7b0T5qRXPFl3gRF 56ScM1imlA90IgHrer02FMd8Qbys7DSBtRKZYFzXMUP/Reh/DOFI0gvVkVpQ74SI lZolDeyvj6MIGKEJcqv5URKUVrTDzU6v4VPt+UTJzH74u74YNLHJVc5FuQ/VfwTU wUPmYdd/aaxhyfCblp5wePLx8bAXwMDeBwd68Z5q1Jbjp83Bz6SafyXBHniUUZVh DG4R5l/mGUnF764xLWkZNsGJGehsyPiwo7RGtEFKkIa0vhADoyBWAfkfkBgaOt4= =Ssjo -----END PGP SIGNATURE----- --brEuL7wsLY8+TuWz--