Re: [Qemu-devel] [PATCH v10 2/3] qemu-img info lists bitmap directory entries

[Vladimir Sementsov-Ogievskiy]

30.01.2019 22:26, Andrey Shinkevich wrote:
> 
> 
> On 30/01/2019 21:24, Eric Blake wrote:
>> On 1/30/19 11:51 AM, Andrey Shinkevich wrote:
>>> In the 'Format specific information' section of the 'qemu-img info'
>>> command output, the supplemental information about existing QCOW2

[...]

>>> +##
>>> +# @Qcow2BitmapInfo:
>>> +#
>>> +# Qcow2 bitmap information.
>>> +#
>>> +# @name: the name of the bitmap
>>> +#
>>> +# @granularity: granularity of the bitmap in bytes
>>> +#
>>> +# @flags: recognized flags of the bitmap
>>> +#
>>> +# @unknown-flags: any remaining flags not recognized by the current qemu 
>>> version
>>> +#
>>> +# Since: 4.0
>>> +##
>>> +{ 'struct': 'Qcow2BitmapInfo',
>>> +  'data': {'name': 'str', 'granularity': 'uint32',
>>> +           'flags': ['Qcow2BitmapInfoFlags'],
>>> +           '*unknown-flags': 'uint32' } }
>>
>> Not for this patch, but how hard would it be to add a field showing the
>> number of set bits in the bitmap?
> 
> I believe that is not too hard and would be happy to implement that with
> another series, please.
> 

In common case, we should load all bitmaps for it, which is bad idea for qmp 
query
when vm is running.

On the other hand, in some meaningful cases (when open read-only, with qemu-img 
info),
we can reuse information obtained during loading bitmaps on open(). However, 
for in-use
bitmaps we'll have to load them to count dirty bits. Which is not a problem for 
qemu-img,
but again, may be not good idea while vm is running (as it may take too much 
time).

Also, exporting dirty-count for in-use bitmaps while vm is running may be 
ambiguous, as
some of the in-use bitmaps (or all) will be bitmaps in-use by exactly this vm 
run, so
actual dirty-count is in BdrvDirtyBitmap info.

And, another idea: we have extra_data field in bitmap list in qcow2,
which may be safely ignored if extra_data_compatible is set for this bitmap. 
So, it may
be a good reason to implement first type of compatible extra data.. But I don't 
sure that
it's worth it.

-- 
Best regards,
Vladimir