From: Kevin Wolf <kwolf@redhat.com>
To: qemu-block@nongnu.org
Cc: wencongyang2@huawei.com, xiechanglong.d@gmail.com,
lukasstraub2@web.de, qemu-devel@nongnu.org, mreitz@redhat.com
Subject: Re: [PATCH] replication: Avoid blk_make_empty() on read-only child
Date: Fri, 15 May 2020 14:12:17 +0200 [thread overview]
Message-ID: <20200515121217.GH93011@linux.fritz.box> (raw)
In-Reply-To: <20200515120318.188831-1-kwolf@redhat.com>
Am 15.05.2020 um 14:03 hat Kevin Wolf geschrieben:
> This is just a bandaid to keep tests/test-replication working after
> bdrv_make_empty() starts to assert that we're not trying to call it on a
> read-only child.
>
> For the real solution in the future, replication should not steal the
> BdrvChild from its backing file (this is never correct to do!), but
> instead have its own child node references, with the appropriate
> permissions.
>
> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
I'll commit this patch for now so the brokenness of the replication
driver won't stop my pull request, but this is really not how things
should work.
Can someone who is interested in replication have a look at the real
solution, please? It's not trivial enough for me to fix it without
learning a lot about using replication first.
Essentially, the problem is that you can't just copy the BdrvChild from
bs->backing like replication_start() does, but you need to use
bdrv_attach_child() to attach the respective node directly to bs, too.
This gives you the opportunity to request the write permissions you need
for bdrv_make_empty().
However, it seems that during replication_start(), the backing file
isn't writable yet (which is not surprising, backing files are supposed
to be read-only), so my attempt to request write permissions right there
failed. So it seems we need to figure out where the backing file becomes
writable and then take write permissions after this point. Or make it
writable earlier. I don't understand enough about the whole setup to
figure out where this should happen, which is why I'm asking you.
Kevin
prev parent reply other threads:[~2020-05-15 12:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-15 12:03 [PATCH] replication: Avoid blk_make_empty() on read-only child Kevin Wolf
2020-05-15 12:12 ` Kevin Wolf [this message]
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=20200515121217.GH93011@linux.fritz.box \
--to=kwolf@redhat.com \
--cc=lukasstraub2@web.de \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=wencongyang2@huawei.com \
--cc=xiechanglong.d@gmail.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).