qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: Markus Armbruster <armbru@redhat.com>,
	"fam@euphon.net" <fam@euphon.net>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"mreitz@redhat.com" <mreitz@redhat.com>,
	Denis Lunev <den@virtuozzo.com>,
	Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>,
	"jsnow@redhat.com" <jsnow@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v11 2/3] qemu-img info lists bitmap directory entries
Date: Tue, 5 Feb 2019 15:28:55 +0100	[thread overview]
Message-ID: <20190205142855.GD5273@linux.fritz.box> (raw)
In-Reply-To: <8bdd3e6e-f83f-e73a-6dad-870d05698334@virtuozzo.com>

Am 05.02.2019 um 14:16 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 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 <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
> > 
> 
> 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.

Yes, I think this has the information it needs to have.

It needs some spelling and grammar fixes, but before I make them, I'll
wait if Eric would phrase it in a different way that sounds more natural
to him as a native speaker.

Kevin

  reply	other threads:[~2019-02-05 14:29 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-31 13:46 [Qemu-devel] [PATCH v11 0/3] qemu-img info lists bitmap directory entries Andrey Shinkevich
2019-01-31 13:46 ` [Qemu-devel] [PATCH v11 1/3] bdrv_query_image_info Error parameter added Andrey Shinkevich
2019-02-01 14:42   ` Vladimir Sementsov-Ogievskiy
2019-02-01 14:46     ` Daniel P. Berrangé
2019-02-01 17:13   ` Kevin Wolf
2019-01-31 13:46 ` [Qemu-devel] [PATCH v11 2/3] qemu-img info lists bitmap directory entries Andrey Shinkevich
2019-02-01 15:19   ` Vladimir Sementsov-Ogievskiy
2019-02-01 17:08   ` Eric Blake
2019-02-01 17:19   ` Kevin Wolf
2019-02-01 18:39   ` Markus Armbruster
2019-02-01 19:04     ` Eric Blake
2019-02-01 19:23       ` Markus Armbruster
2019-02-01 19:28         ` Eric Blake
2019-02-04 13:05           ` Markus Armbruster
2019-02-04 16:03             ` Vladimir Sementsov-Ogievskiy
2019-02-04 16:24               ` Eric Blake
2019-02-04 16:35                 ` Vladimir Sementsov-Ogievskiy
2019-02-04 16:46                   ` Vladimir Sementsov-Ogievskiy
2019-02-04 17:33                     ` Eric Blake
2019-02-04 17:37                       ` Eric Blake
2019-02-04  7:49     ` Vladimir Sementsov-Ogievskiy
2019-02-04 15:23       ` Eric Blake
2019-02-04  9:46     ` Kevin Wolf
2019-02-04 13:45       ` Markus Armbruster
2019-02-04 15:36         ` Vladimir Sementsov-Ogievskiy
2019-02-05 10:00           ` Kevin Wolf
2019-02-05 13:16             ` Vladimir Sementsov-Ogievskiy
2019-02-05 14:28               ` Kevin Wolf [this message]
2019-02-05 14:38                 ` Eric Blake
2019-01-31 13:46 ` [Qemu-devel] [PATCH v11 3/3] qemu-img info: bitmaps extension new test 239 Andrey Shinkevich
2019-02-01 15:57   ` Vladimir Sementsov-Ogievskiy
2019-02-01 17:14   ` Kevin Wolf
2019-02-04  7:53     ` Vladimir Sementsov-Ogievskiy
2019-02-04  9:36       ` Kevin Wolf
2019-02-01 17:23   ` Eric Blake
2019-02-01 17:34     ` Kevin Wolf
2019-02-03 15:28 ` [Qemu-devel] [PATCH v11 0/3] qemu-img info lists bitmap directory entries no-reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190205142855.GD5273@linux.fritz.box \
    --to=kwolf@redhat.com \
    --cc=andrey.shinkevich@virtuozzo.com \
    --cc=armbru@redhat.com \
    --cc=den@virtuozzo.com \
    --cc=fam@euphon.net \
    --cc=jsnow@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).