diff options
| author | John Snow <jsnow@redhat.com> | 2019-07-29 16:35:52 -0400 |
|---|---|---|
| committer | John Snow <jsnow@redhat.com> | 2019-08-16 16:28:02 -0400 |
| commit | 00a463b1dc73d1665ce6720df4de052aff95acf8 (patch) | |
| tree | 8018f0c1fe05c5a1984c102802b03cf58ba5161b /qapi | |
| parent | 920305661473842980b65fca439af2bb69fcec76 (diff) | |
qapi: add BitmapSyncMode enum
Depending on what a user is trying to accomplish, there might be a few
bitmap cleanup actions that occur when an operation is finished that
could be useful.
I am proposing three:
- NEVER: The bitmap is never synchronized against what was copied.
- ALWAYS: The bitmap is always synchronized, even on failures.
- ON-SUCCESS: The bitmap is synchronized only on success.
The existing incremental backup modes use 'on-success' semantics,
so add just that one for right now.
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-id: 20190709232550.10724-5-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
Diffstat (limited to 'qapi')
| -rw-r--r-- | qapi/block-core.json | 14 |
1 files changed, 14 insertions, 0 deletions
diff --git a/qapi/block-core.json b/qapi/block-core.json index 8ca12004ae..06eb3bb3d7 100644 --- a/qapi/block-core.json +++ b/qapi/block-core.json @@ -1135,6 +1135,20 @@ 'data': ['top', 'full', 'none', 'incremental'] } ## +# @BitmapSyncMode: +# +# An enumeration of possible behaviors for the synchronization of a bitmap +# when used for data copy operations. +# +# @on-success: The bitmap is only synced when the operation is successful. +# This is the behavior always used for 'INCREMENTAL' backups. +# +# Since: 4.2 +## +{ 'enum': 'BitmapSyncMode', + 'data': ['on-success'] } + +## # @MirrorCopyMode: # # An enumeration whose values tell the mirror block job when to |