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/block-core.json | |
| parent | 920305661473842980b65fca439af2bb69fcec76 (diff) | |
| download | focaccia-qemu-00a463b1dc73d1665ce6720df4de052aff95acf8.tar.gz focaccia-qemu-00a463b1dc73d1665ce6720df4de052aff95acf8.zip | |
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/block-core.json')
| -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 |