Re: [RFC 1/4] drive-mirror: add support for sync=bitmap mode=never

[Fiona Ebner]

Am 21.02.24 um 07:55 schrieb Markus Armbruster:
>> diff --git a/qapi/block-core.json b/qapi/block-core.json
>> index ab5a93a966..ac05483958 100644
>> --- a/qapi/block-core.json
>> +++ b/qapi/block-core.json
>> @@ -2181,6 +2181,15 @@
>>  #     destination (all the disk, only the sectors allocated in the
>>  #     topmost image, or only new I/O).
>>  #
>> +# @bitmap: The name of a bitmap to use for sync=bitmap mode.  This
>> +#     argument must be present for bitmap mode and absent otherwise.
>> +#     The bitmap's granularity is used instead of @granularity.
>> +#     (Since 9.0).
> 
> What happens when the user specifies @granularity anyway?  Error or
> silently ignored?
> 

It's an error:

>> +    if (bitmap) {
>> +        if (granularity) {
>> +            error_setg(errp, "granularity (%d)"
>> +                       "cannot be specified when a bitmap is provided",
>> +                       granularity);
>> +            return NULL;
>> +        }

>> +#
>> +# @bitmap-mode: Specifies the type of data the bitmap should contain
>> +#     after the operation concludes.  Must be present if sync is
>> +#     "bitmap".  Must NOT be present otherwise.  (Since 9.0)
> 
> Members that must be present when and only when some enum member has a
> certain value should perhaps be in a union branch.  Perhaps the block
> maintainers have an opinion here.
> 

Sounds sensible to me. Considering also the next patches, in the end it
could be a union discriminated by the @sync which contains @bitmap and
@bitmap-mode when it's the 'bitmap' sync mode, @bitmap when it's the
'incremental' sync mode (@bitmap-sync mode needs to be 'on-success'
then, so there is no choice for the user) and which contains
@granularity for the other sync modes.

Best Regards,
Fiona