19.06.2020 22:56, Eric Blake wrote:
From: John Snow <js...@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 <js...@redhat.com>
Signed-off-by: Eric Blake <ebl...@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
