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

[Kevin Wolf <kwolf@redhat.com>]

Am 04.02.2019 um 16:36 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 04.02.2019 16:45, Markus Armbruster wrote:
> > Kevin Wolf <kwolf@redhat.com> writes:
> > 
> >> Am 01.02.2019 um 19:39 hat Markus Armbruster geschrieben:
> >>> Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> 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 <andrey.shinkevich@virtuozzo.com>
> >>>> ---
> >>> [...]
> >>>> 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