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: Tue, 5 Feb 2019 13:16:24 +0000

05.02.2019 13:00, Kevin Wolf wrote:
> Am 04.02.2019 um 16:36 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 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)
> 
> Good point, but then this description isn't correct either:
> 
>      @in-use: The bitmap was not saved correctly and may be inconsistent.
> 
> Maybe what needs to change is the description, not the name?
> 
> Kevin
> 

How about the following:

@in-use: This flag is set while bitmap is in use by software and it's data in
qcow2 image may be out of date when actual bitmap data is managed by software.
Presence of this flag in offline image means that bitmap was not saved correctly
after last usage and it's data may be inconsistent.


-- 
Best regards,
Vladimir

reply via email to

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