qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-devel] [PATCH v11 2/3] qemu-img info lists bitmap directory entries
Date: Mon, 4 Feb 2019 15:36:03 +0000

04.02.2019 16:45, Markus Armbruster wrote:
> Kevin Wolf <address@hidden> writes:
> 
>> Am 01.02.2019 um 19:39 hat Markus Armbruster geschrieben:
>>> Andrey Shinkevich <address@hidden> writes:
>>>
>>>> In the 'Format specific information' section of the 'qemu-img info'
>>>> command output, the supplemental information about existing QCOW2
>>>> bitmaps will be shown, such as a bitmap name, flags and granularity:
>>>>
>>>> image: /vz/vmprivate/VM1/harddisk.hdd
>>>> file format: qcow2
>>>> virtual size: 64G (68719476736 bytes)
>>>> disk size: 3.0M
>>>> cluster_size: 1048576
>>>> Format specific information:
>>>>      compat: 1.1
>>>>      lazy refcounts: true
>>>>      bitmaps:
>>>>          [0]:
>>>>              flags:
>>>>                  [0]: in-use
>>>>                  [1]: auto
>>>>              name: back-up1
>>>>              unknown flags: 4
>>>>              granularity: 65536
>>>>          [1]:
>>>>              flags:
>>>>                  [0]: in-use
>>>>                  [1]: auto
>>>>              name: back-up2
>>>>              unknown flags: 8
>>>>              granularity: 65536
>>>>      refcount bits: 16
>>>>      corrupt: false
>>>>
>>>> Signed-off-by: Andrey Shinkevich <address@hidden>
>>>> ---
>>> [...]
>>>> diff --git a/qapi/block-core.json b/qapi/block-core.json
>>>> index 91685be..271e0df 100644
>>>> --- a/qapi/block-core.json
>>>> +++ b/qapi/block-core.json
>>>> @@ -69,6 +69,8 @@
>>>>   # @encrypt: details about encryption parameters; only set if image
>>>>   #           is encrypted (since 2.10)
>>>>   #
>>>> +# @bitmaps: A list of qcow2 bitmap details (since 4.0)
>>>> +#
>>>>   # Since: 1.7
>>>>   ##
>>>>   { 'struct': 'ImageInfoSpecificQCow2',
>>>> @@ -77,7 +79,8 @@
>>>>         '*lazy-refcounts': 'bool',
>>>>         '*corrupt': 'bool',
>>>>         'refcount-bits': 'int',
>>>> -      '*encrypt': 'ImageInfoSpecificQCow2Encryption'
>>>> +      '*encrypt': 'ImageInfoSpecificQCow2Encryption',
>>>> +      '*bitmaps': ['Qcow2BitmapInfo']
>>>>     } }
>>>>   
>>>>   ##
>>>> @@ -454,6 +457,41 @@
>>>>              'status': 'DirtyBitmapStatus'} }
>>>>   
>>>>   ##
>>>> +# @Qcow2BitmapInfoFlags:
>>>> +#
>>>> +# An enumeration of flags that a bitmap can report to the user.
>>>> +#
>>>> +# @in-use: The bitmap was not saved correctly and may be inconsistent.
>>>
>>> I doubt the casual reader could guess the meaning from the name.  What
>>> about @dirty?
>>
>> Feels like overloading the word "dirty" in the context of "dirty
>> bitmaps". This might easily lead to misinterpretation as "this bitmap
>> marks some clusters as dirty" rather than "this bitmap might be
>> inconsistent".
> 
> Call it @possibly-inconsistent then?
> 

If you run qmp query-block while vm is running, all bitmaps in image will
be in use. And in this context, in-use seems more appropriate than
possibly-inconsistent. And in-use has less interference with the fact that
actual bitmaps now are in-RAM BdrvDirtyBitmap structures which are actually
consistent (and also shown by query-block)

-- 
Best regards,
Vladimir

reply via email to

[Prev in Thread] Current Thread [Next in Thread]