qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: John Snow <jsnow@redhat.com>
Cc: Peter Krempa <pkrempa@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Qemu-block <qemu-block@nongnu.org>, Max Reitz <mreitz@redhat.com>
Subject: Re: bitmap migration bug with -drive while block mirror runs
Date: Tue, 1 Oct 2019 14:00:08 +0000	[thread overview]
Message-ID: <d897c755-40e7-6392-23e3-c06b1a371f28@virtuozzo.com> (raw)
In-Reply-To: <315cff78-dcdb-a3ce-2742-da3cc9f0ca97@redhat.com>

01.10.2019 3:09, John Snow wrote:
> Hi folks, I identified a problem with the migration code that Red Hat QE
> found and thought you'd like to see it:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1652424#c20
> 
> Very, very briefly: drive-mirror inserts a filter node that changes what
> bdrv_get_device_or_node_name() returns, which causes a migration problem.
> 
> 
> Ignorant question #1: Can we multi-parent the filter node and
> source-node? It looks like at the moment both consider their only parent
> to be the block-job and don't have a link back to their parents otherwise.
> 
> 
> Otherwise: I have a lot of cloudy ideas on how to solve this, but
> ultimately what we want is to be able to find the "addressable" name for
> the node the bitmap is attached to, which would be the name of the first
> ancestor node that isn't a filter. (OR, the name of the block-backend
> above that node.)

Not the name of ancestor node, it will break mapping: it must be name of the
node itself or name of parent (may be through several filters) block-backend

> 
> A simple way to do this might be a "child_unfiltered" BdrvChild role
> that simply bypasses the filter that was inserted and serves no real
> purpose other than to allow the child to have a parent link and find who
> it's """real""" parent is.
> 
> Because of flushing, reopen, sync, drain &c &c &c I'm not sure how
> feasible this quick idea might be, though.
> 
> 
> - Corollary fix #1: call error_setg if the bitmap node name that's about
> to go over the wire is an autogenerated node: this is never correct!
> 
> (Why not? because the target is incapable of matching the node-name
> because they are randomly generated AND you cannot specify node-names
> with # prefixes as they are especially reserved!
> 
> (This raises a related problem: if you explicitly add bitmaps to nodes
> with autogenerated names, you will be unable to migrate them.))
> 
> --js
> 

What about the following:

diff --git a/block.c b/block.c
index 5944124845..6739c19be9 100644
--- a/block.c
+++ b/block.c
@@ -1009,8 +1009,20 @@ static void bdrv_inherited_options(int *child_flags, QDict *child_options,
      *child_flags = flags;
  }

+static const char *bdrv_child_get_name(BdrvChild *child)
+{
+    BlockDriverState *parent = child->opaque;
+
+    if (parent->drv && parent->drv->is_filter) {
+        return bdrv_get_parent_name(parent);
+    }
+
+    return NULL;
+}
+
  const BdrvChildRole child_file = {
      .parent_is_bds   = true,
+    .get_name        = bdrv_child_get_name,
      .get_parent_desc = bdrv_child_get_parent_desc,
      .inherit_options = bdrv_inherited_options,
      .drained_begin   = bdrv_child_cb_drained_begin,
@@ -1163,6 +1175,7 @@ static int bdrv_backing_update_filename(BdrvChild *c, BlockDriverState *base,

  const BdrvChildRole child_backing = {
      .parent_is_bds   = true,
+    .get_name        = bdrv_child_get_name,
      .get_parent_desc = bdrv_child_get_parent_desc,
      .attach          = bdrv_backing_attach,
      .detach          = bdrv_backing_detach,


-- 
Best regards,
Vladimir

  parent reply	other threads:[~2019-10-01 14:02 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-01  0:09 bitmap migration bug with -drive while block mirror runs John Snow
2019-10-01  4:28 ` Peter Krempa
2019-10-01  9:07   ` Vladimir Sementsov-Ogievskiy
2019-10-01  8:57 ` Vladimir Sementsov-Ogievskiy
2019-10-01  9:54   ` Kevin Wolf
2019-10-01 10:05     ` Vladimir Sementsov-Ogievskiy
2019-10-01 13:24     ` Peter Krempa
2019-10-01 15:09     ` John Snow
2019-10-01 15:58       ` Kevin Wolf
2019-10-01 16:12         ` Vladimir Sementsov-Ogievskiy
2019-10-01 16:24           ` Kevin Wolf
2019-10-01 16:23         ` John Snow
2019-10-01 11:45   ` Peter Krempa
2019-10-01  9:17 ` Vladimir Sementsov-Ogievskiy
2019-10-01 14:00 ` Vladimir Sementsov-Ogievskiy [this message]
2019-10-01 14:10   ` John Snow
2019-10-01 15:57     ` Vladimir Sementsov-Ogievskiy
2019-10-01 16:07       ` John Snow
2019-10-02  8:12         ` Kevin Wolf
2019-10-02 10:46         ` Peter Krempa
2019-10-02 11:11           ` Kevin Wolf
2019-10-02 12:22             ` Vladimir Sementsov-Ogievskiy
2019-10-02 13:48               ` Peter Krempa
2019-10-02 13:43             ` Peter Krempa
2019-10-02 14:03               ` Vladimir Sementsov-Ogievskiy
2019-10-02 21:35           ` John Snow
2019-10-03 10:14             ` Vladimir Sementsov-Ogievskiy
2019-10-03 23:34               ` John Snow
2019-10-04  8:33                 ` Peter Krempa
2019-10-04  9:21                   ` Vladimir Sementsov-Ogievskiy
2019-10-06  3:15                   ` John Snow
2019-10-04  9:24                 ` Vladimir Sementsov-Ogievskiy
2019-10-04 13:07                   ` Eric Blake
2019-10-06  3:19                     ` John Snow
2019-10-01 16:16       ` Kevin Wolf
2019-10-01 16:17         ` Vladimir Sementsov-Ogievskiy
2019-10-01 14:13   ` Max Reitz
2019-10-01 14:27     ` Vladimir Sementsov-Ogievskiy
2019-10-01 14:34       ` Max Reitz
2019-10-01 14:53         ` Vladimir Sementsov-Ogievskiy
2019-10-01 15:26           ` Max Reitz
2019-10-02  7:34             ` Peter Krempa
2019-10-01 15:09         ` Kevin Wolf
2019-10-01 15:27           ` Max Reitz
2019-10-01 16:12             ` Kevin Wolf
2019-10-01 16:17               ` Max Reitz
2019-10-01 16:22                 ` Vladimir Sementsov-Ogievskiy

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=d897c755-40e7-6392-23e3-c06b1a371f28@virtuozzo.com \
    --to=vsementsov@virtuozzo.com \
    --cc=jsnow@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pkrempa@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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).