All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Alberto Garcia <berto@igalia.com>,
	qemu-block@nongnu.org, Jeff Cody <jcody@redhat.com>,
	qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	John Snow <jsnow@redhat.com>
Subject: Re: [Qemu-devel] Minutes from the "Stuttgart block Gipfele"
Date: Wed, 23 Dec 2015 18:15:20 +0800	[thread overview]
Message-ID: <20151223101520.GL14423@ad.usersys.redhat.com> (raw)
In-Reply-To: <87vb7vc2yt.fsf@blackfin.pond.sub.org>

On Fri, 12/18 14:15, Markus Armbruster wrote:
> First, let's examine how such a chain could look like.  If we read the
> current code correctly, it behaves as if we had a chain
> 
>         BB
>          |
>       throttle
>          |
>      detect-zero
>          |
>     copy-on-read
>          |
>         BDS
> 
> Except for the backup job, which behaves as if we had
> 
>                backup job
>               /
>       notifier
>          |
>      detect-zero
>          |
>         BDS

Just to brainstorm block jobs in the dynamic reconfigured node graph: (not sure
if this is useful)

Nothing stops us from viewing backup as a self-contained filter,

        [backup]
           |
       detect-zero
           |
          BDS

where its .bdrv_co_writev copies out the old data, and at instantiation time
it also creates a long running coroutine (backup_run).

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.

stream (device=d0 base=base0) becomes a pull filter:

          BB[d0]
           |
     [pull,src=base0]
           |
       detect-zero
           |
      copy-on-read
           |
          BDS
           |
          BDS[base0]

Note: s->dirty_bitmap will be initialized with the blocks which should be copied
by block-stream.

Similarly, active commit (device=d0 base=base0) becomes a pull filter:

          BB[d0]
           |
       detect-zero
           |
      copy-on-read
           |
          BDS
           |
      [pull,src=d0]
           |
          BDS[base0]

and commit (device=d0 top=base1 base=base0) becomes a pull filter:

          BB[d0]
           |
       detect-zero
           |
      copy-on-read
           |
          BDS
           |
          BDS[base1]
           |
      [pull,src=base1]
           |
          BDS[base0]


If this could work, I'm looking forward to a pretty looking diffstat if we can
unify the coroutine code of all four jobs. :)

Fam

  parent reply	other threads:[~2015-12-23 10:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-18 13:15 [Qemu-devel] Minutes from the "Stuttgart block Gipfele" Markus Armbruster
2015-12-23  8:33 ` Stefan Hajnoczi
2016-01-11 15:10   ` Kevin Wolf
2016-01-14 11:25     ` Stefan Hajnoczi
2015-12-23 10:15 ` Fam Zheng [this message]
2016-01-04  5:16   ` Stefan Hajnoczi
2016-01-04  7:28     ` Fam Zheng
2016-01-07  5:23       ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2016-01-07  9:32         ` Fam Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151223101520.GL14423@ad.usersys.redhat.com \
    --to=famz@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berto@igalia.com \
    --cc=jcody@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.