[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v10 2/3] qemu-img info lists bitmap directory en
From: |
Vladimir Sementsov-Ogievskiy |
Subject: |
Re: [Qemu-devel] [PATCH v10 2/3] qemu-img info lists bitmap directory entries |
Date: |
Thu, 31 Jan 2019 09:46:33 +0000 |
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