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 09:17:31 +0000 [thread overview]
Message-ID: <ffd337d8-31f1-0515-ce1a-15a8fcfff75d@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.)
>
> 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.))
>
Related problem:
# cd tests/qemu-iotests; git grep -il migration ??? | xargs git grep -il mirror | xargs git grep -il bitmap | wc -l
0
--
Best regards,
Vladimir
next prev parent reply other threads:[~2019-10-01 9:20 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 [this message]
2019-10-01 14:00 ` Vladimir Sementsov-Ogievskiy
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=ffd337d8-31f1-0515-ce1a-15a8fcfff75d@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.