qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Qemu-block <qemu-block@nongnu.org>, Max Reitz <mreitz@redhat.com>
Subject: [Qemu-devel] "Internal" bdrv-dirty-bitmaps
Date: Mon, 8 Jul 2019 17:53:11 -0400	[thread overview]
Message-ID: <27efde48-e5c2-714d-87c6-6b044de9c163@redhat.com> (raw)

Hi Markus;

recently it's come up a few times that it might be nice to hide bitmaps
that have no names from the query results, because these are "internal"
bitmaps used by QEMU that the user cannot manipulate.

Actually, all of the bitmap-finding functions will refuse to touch
bitmaps with no name.

We added names to bitmaps with 0db6e54a8a2, but bitmaps existed prior to
this and already had a "query" mechanism -- meaning that the "internal"
use bitmaps created by mirror have always been user-visible.

commit 21b56835 added the bdrv_query_dirty_bitmaps function, replacing
and older one-per-node bitmap querying utility, which... leads me to
believe that we've always explicitly exposed these bitmaps...

Further back in time (2012), we see b9a9b3a4626, which explicitly
exposed this information -- intentionally showing the bitmap dirty count
for... either migration or mirror, it could have been both.

I guess it's back from
https://lists.gnu.org/archive/html/qemu-devel/2012-09/msg04545.html --
and just assumed we'd want to see this count during operations that used it.

I guess at this point I definitely can't sweep the last 7 years under a
mat. The problem I have with it is that without a name, these bitmaps
are meaningless to an outside viewer. There could be many no-name
bitmaps at once, each correlating to different operations that could
finish and delete them at any time.

Are these useful to still have? If not, is there a reasonable way to
announce their farewell party by the deprecation policy?

--js


                 reply	other threads:[~2019-07-08 21:54 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=27efde48-e5c2-714d-87c6-6b044de9c163@redhat.com \
    --to=jsnow@redhat.com \
    --cc=armbru@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).