Re: [Qemu-devel] Minutes from the "Stuttgart block Gipfele"

[Fam Zheng <famz@redhat.com>]

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