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. Stefan
signature.asc
Description: PGP signature
