"Denis V. Lunev" <[email protected]> writes: > On 8/25/26 11:10, Markus Armbruster wrote: >> "Denis V. Lunev" <[email protected]> writes: >> >>> From: Denis V. Lunev <[email protected]> >>> >>> 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 <[email protected]> >>> Cc: Eric Blake <[email protected]> >>> Cc: Markus Armbruster <[email protected]> >>> Signed-off-by: Denis V. Lunev <[email protected]> >> [...] >> >>> 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'] } } [...]
