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
