Re: [PATCH v6 19/25] parallels: report the stored dirty bitmaps in qemu-img info

[Markus Armbruster <armbru@redhat.com>]

"Denis V. Lunev" <den@virtuozzo.com> writes:

> On 8/25/26 11:10, Markus Armbruster wrote:
>> "Denis V. Lunev" <den@openvz.org> writes:
>>
>>> From: Denis V. Lunev <den@openvz.org>
>>>
>>> Nothing tells which persistent bitmaps an image carries. qemu-img info
>>> says nothing about them, and the only other way to see one is to export
>>> the image over NBD and ask for a bitmap by name, which needs the name
>>> beforehand.
>>>
>>> Add ImageInfoSpecificParallels with the bitmaps and their granularity,
>>> as qcow2 reports the contents of its bitmap directory:
>>>
>>>     Format specific information:
>>>         bitmaps:
>>>             [0]:
>>>                 name: b2c9e1a4-5d3f-4e8b-9a7c-6f0d1e2b3a45
>>>                 granularity: 65536
>>>
>>> The list is built from the bitmaps loaded at open time rather than from
>>> a second pass over the Format Extension, as every bitmap the extension
>>> carries is loaded and marked persistent there. On a node which is open
>>> that also covers a bitmap which was created but not stored yet, which is
>>> what the field says: qemu-img info opens the image on its own, so there
>>> the two are the same thing.
>>
>> The last sentence confuses me.
>>
>>> An image with no bitmaps leaves the structure empty, and
>>> bdrv_image_info_specific_dump() prints nothing for an empty one, so the
>>> output for such an image does not change.
>>
>> Output of what?  I guess it's "info block" and "qemu-img info", because
>> these call bdrv_image_info_specific_dump().
> For the image (BDS) without dirty bitmaps the output
> of 'qemu-img info' would be the same as with and
> without a patch.

Suggest to clarify 'the output' to something like 'the output of
"qemu-img info" and "info block"'.

>>> Cc: Stefan Hajnoczi <stefanha@redhat.com>
>>> Cc: Eric Blake <eblake@redhat.com>
>>> Cc: Markus Armbruster <armbru@redhat.com>
>>> Signed-off-by: Denis V. Lunev <den@openvz.org>
>> [...]
>>
>>> diff --git a/qapi/block-core.json b/qapi/block-core.json
>>> index 1f87b07850..4bc8b45efe 100644
>>> --- a/qapi/block-core.json
>>> +++ b/qapi/block-core.json
>>> @@ -200,7 +200,7 @@
>>>  # Since: 1.7
>>>  ##
>>>  { 'enum': 'ImageInfoSpecificKind',
>>> -  'data': [ 'qcow2', 'vmdk', 'luks', 'rbd', 'file' ] }
>>> +  'data': [ 'qcow2', 'vmdk', 'luks', 'rbd', 'file', 'parallels' ] }
>>>  
>>>  ##
>>>  # @ImageInfoSpecificQCow2Wrapper:
>>> @@ -255,6 +255,41 @@
>>>  { 'struct': 'ImageInfoSpecificFileWrapper',
>>>    'data': { 'data': 'ImageInfoSpecificFile' } }
>>>  
>>> +##
>>> +# @ParallelsBitmapInfo:
>>> +#
>>> +# Parallels dirty bitmap information.
>>> +#
>>> +# @name: the name of the bitmap
>>> +#
>>> +# @granularity: granularity of the bitmap in bytes
>>> +#
>>> +# Since: 11.2
>>> +##
>>> +{ 'struct': 'ParallelsBitmapInfo',
>>> +  'data': { 'name': 'str', 'granularity': 'uint32' } }
>>> +
>>> +##
>>> +# @ImageInfoSpecificParallels:
>>> +#
>>> +# @bitmaps: A list of the persistent dirty bitmaps of the image,
>>> +#     including the ones which are not written out yet
>>
>> Pardon my ignorance...  Is "not written out yet" relevant to a user /
>> management application?
> This means that the image on disk could contains
> bitmaps A and B while backup software has added
> bitmap C to BDS. The query will return A, B, C.
> This is same as for QCOW2.

Will bitmap C be written to the image, and when?

>> ImageInfoSpecificQCow2 also has a @bitmaps member.  Its documentation is
>>
>>    # @bitmaps: A list of qcow2 bitmap details (since 4.0)
>>
>> Are these "persistent dirty bitmaps" as well, or something else?
> same, as above

If they're basically the same, then their documentation should be
basically the same.

>>> +#
>>> +# Since: 11.2
>>> +##
>>> +{ 'struct': 'ImageInfoSpecificParallels',
>>> +  'data': { '*bitmaps': ['ParallelsBitmapInfo'] } }

[...]