Re: [Qemu-devel] [Qemu-block] [PATCH v2 01/17] docs: incremental backup documentation

[John Snow <jsnow@redhat.com>]

On 03/11/2015 10:43 AM, Eric Blake wrote:
> On 03/11/2015 08:19 AM, John Snow wrote:
>>
>>
>> On 03/11/2015 09:43 AM, Stefan Hajnoczi wrote:
>>> On Mon, Mar 02, 2015 at 06:19:47PM -0500, John Snow wrote:
>>>> +## Bitmap Modes
>>>> +
>>>> +* A Bitmap can be "enabled" (tracking writes, the default) or
>>>> "disabled"
>>>> +(read-only, I/O is ignored.) This state is currently only changed
>>>> internally
>>>> +for the purposes of migration, and otherwise remains enabled.
>>>
>>>   From a QMP API perspective this information is not relevant.  The
>>> documentation is clearer without the concept of enabled/disabled.
>>>
>>
>> Hm ... I suppose; If you want all mention of this gone from user view, I
>> should actually remove this status field from the query, too. It is
>> entirely possible to have a state where the bitmap is not frozen, but it
>> is disabled (migration, perhaps others in the future?) so I left the
>> status visible to the user for now.
>>
>> libvirt et al could likely rely on the migration status to know not to
>> manipulate bitmaps, but having that status information directly in the
>> bitmap didn't bother me.
>
> With a back-compat perspective, it's easier to hide the field now and
> add it later if we discover that it would have been useful to expose,
> than it is to expose it now and then have to support it forever even
> though no one uses it.  I'm not yet sure if libvirt can make use of
> knowing whether a bitmap is frozen/disabled.
>

Makes sense. I suspect I will leave the frozen status there, though, 
because applying an operation to a frozen bitmap WILL result in an 
error, and it would be nice to be able to avoid that scenario instead of 
it being a hidden status that sometimes fails your commands.

Granted, it is only currently in this status while it is being USED for 
a job, so it may not be mechanically useful...