Re: [PATCH v3 1/6] block: add bitmap-populate job

[Vladimir Sementsov-Ogievskiy]

19.06.2020 22:56, Eric Blake wrote:
> From: John Snow <jsnow@redhat.com>
>
> This job copies the allocation map into a bitmap. It's a job because
> there's no guarantee that allocation interrogation will be quick (or
> won't hang), so it cannot be retrofitted into block-dirty-bitmap-merge.
>
> It was designed with different possible population patterns in mind,
> but only top layer allocation was implemented for now.
>
> Signed-off-by: John Snow <jsnow@redhat.com>
> Signed-off-by: Eric Blake <eblake@redhat.com>
> ---
>   qapi/block-core.json      |  48 +++++++++
>   qapi/job.json             |   6 +-
>   include/block/block_int.h |  21 ++++
>   block/bitmap-populate.c   | 207 ++++++++++++++++++++++++++++++++++++++
>   blockjob.c                |   3 +-
>   MAINTAINERS               |   1 +
>   block/Makefile.objs       |   1 +
>   7 files changed, 285 insertions(+), 2 deletions(-)
>   create mode 100644 block/bitmap-populate.c
>
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 0e1c6a59f228..a1bcdba04423 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -2211,6 +2211,54 @@
>         { 'command': 'block-dirty-bitmap-merge',
>           'data': 'BlockDirtyBitmapMerge' }
>
> +##
> +# @BitmapPattern:
> +#
> +# An enumeration of possible patterns that can be written into a bitmap.
> +#
> +# @allocation-top: The allocation status of the top layer
> +#                  of the attached storage node.
> +#
> +# Since: 5.1
> +##
> +{ 'enum': 'BitmapPattern',
> +  'data': ['allocation-top'] }
> +
> +##
> +# @BlockDirtyBitmapPopulate:
> +#
> +# @job-id: identifier for the newly-created block job.
> +#
> +# @pattern: What pattern should be written into the bitmap?
> +#
> +# @on-error: the action to take if an error is encountered on a bitmap's
> +#            attached node, default 'report'.
> +#            'stop' and 'enospc' can only be used if the block device supports
> +#            io-status (see BlockInfo).
> +#
> +# @auto-finalize: When false, this job will wait in a PENDING state after it 
> has
> +#                 finished its work, waiting for @block-job-finalize before
> +#                 making any block graph changes.
> +#                 When true, this job will automatically
> +#                 perform its abort or commit actions.
> +#                 Defaults to true.
> +#
> +# @auto-dismiss: When false, this job will wait in a CONCLUDED state after it
> +#                has completely ceased all work, and awaits @block-job-dismiss.
> +#                When true, this job will automatically disappear from the 
> query
> +#                list without user intervention.
> +#                Defaults to true.
> +#
> +# Since: 5.1
> +##
> +{ 'struct': 'BlockDirtyBitmapPopulate',
> +  'base': 'BlockDirtyBitmap',
> +  'data': { 'job-id': 'str',
> +            'pattern': 'BitmapPattern',
> +            '*on-error': 'BlockdevOnError',
> +            '*auto-finalize': 'bool',
> +            '*auto-dismiss': 'bool' } }
> +

Peter said about a possibility of populating several target bitmaps 
simultaneously.

What about such a generalized semantics:

Merge all sources to each target

@targets: list of bitmaps to be populated by the job
{ 'struct': 'BlockDirtyBitmapPopulate',
  'data': { <common job fields>,
            'targets': ['BlockDirtyBitmap'],
            'sources': ['BitmapPopulateSource'] } }


@bitmap: specify dirty bitmap to be merged to target bitamp(s)
@node: specify a node name, which allocation-map is to be merged to target 
bitmap(s)
{ 'alternate': 'BitmapPopulateSource',
  'data': { 'bitmap': 'BlockDirtyBitmap',
            'node': 'str' } }


- so, we can merge several bitmaps together with several allocation maps into 
several target bitmaps.
(I remember, we also said about a possibility of starting several populating 
jobs, populating into
 same bitmap, I think it may be substituted by one job with several sources. 
Still, it's not hard to
 allow to use target bitmaps in a several jobs simultaneously and this is not 
about the QAPI interface)

Will this simplify things in libvirt?

--
Best regards,
Vladimir