On 7/5/19 10:18 AM, Markus Armbruster wrote:
> John Snow <js...@redhat.com> writes:
>
>> 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.
>> - CONDITIONAL: The bitmap is synchronized only on success.
>>
>> The existing incremental backup modes use 'conditional' semantics,
>> so add just that one for right now.
>>
>> Signed-off-by: John Snow <js...@redhat.com>
>> ---
>> qapi/block-core.json | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/qapi/block-core.json b/qapi/block-core.json
>> index 7b23efcf13..87eba5a5d9 100644
>> --- a/qapi/block-core.json
>> +++ b/qapi/block-core.json
>> @@ -1134,6 +1134,20 @@
>> { 'enum': 'MirrorSyncMode',
>> 'data': ['top', 'full', 'none', 'incremental'] }
>>
>> +##
>> +# @BitmapSyncMode:
>> +#
>> +# An enumeration of possible behaviors for the synchronization of a bitmap
>> +# when used for data copy operations.
>> +#
>> +# @conditional: 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': ['conditional'] }
>> +
>> ##
>> # @MirrorCopyMode:
>> #
>
> The name "conditional" makes me go "on what?". What about "on-success"?
>
Good point. I do like that more.
