From: Lukas Straub <lukasstraub2@web.de>
To: Max Reitz <mreitz@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-block <qemu-block@nongnu.org>,
Wen Congyang <wencongyang2@huawei.com>,
Jason Wang <jasowang@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
Zhang Chen <chen.zhang@intel.com>,
Xie Changlong <xiechanglong.d@gmail.com>
Subject: Re: [PATCH v6 1/4] block/replication.c: Ignore requests after failover
Date: Wed, 23 Oct 2019 20:07:37 +0200 [thread overview]
Message-ID: <20191023200737.6adf4834@luklap> (raw)
In-Reply-To: <26551274-6bb9-734f-0131-a146742d22f3@redhat.com>
On Wed, 23 Oct 2019 14:49:29 +0200
Max Reitz <mreitz@redhat.com> wrote:
> On 05.10.19 15:05, Lukas Straub wrote:
> > After failover the Secondary side of replication shouldn't change state, because
> > it now functions as our primary disk.
> >
> > In replication_start, replication_do_checkpoint, replication_stop, ignore
> > the request if current state is BLOCK_REPLICATION_DONE (sucessful failover) or
> > BLOCK_REPLICATION_FAILOVER (failover in progres i.e. currently merging active
> > and hidden images into the base image).
> >
> > Signed-off-by: Lukas Straub <lukasstraub2@web.de>
> > Reviewed-by: Zhang Chen <chen.zhang@intel.com>
> > ---
> > block/replication.c | 38 +++++++++++++++++++++++++++++++++++---
> > 1 file changed, 35 insertions(+), 3 deletions(-)
>
> Disclaimer: I don’t know anything about the replication block driver.
>
> > diff --git a/block/replication.c b/block/replication.c
> > index 3d4dedddfc..97cc65c0cf 100644
> > --- a/block/replication.c
> > +++ b/block/replication.c
>
> [...]
>
> > @@ -529,8 +540,7 @@ static void replication_start(ReplicationState *rs, ReplicationMode mode,
> > "Block device is in use by internal backup job");
> >
> > top_bs = bdrv_lookup_bs(s->top_id, s->top_id, NULL);
> > - if (!top_bs || !bdrv_is_root_node(top_bs) ||
> > - !check_top_bs(top_bs, bs)) {
> > + if (!top_bs || !check_top_bs(top_bs, bs)) {
>
> It appears to me that top_bs is only used to install op blockers. It
> seems reasonable to require a root node to be able to do so (because op
> blockers are really only checked on a root node).
> (And the commit message doesn’t tell why we’d want to drop the
> is_root_node check here.)
>
> Now OTOH I don’t know whether the replication driver needs an op blocker
> at all or whether the permission system suffices...
Hi,
Now that I look at again, it actually works without this change, by passing
a correct top-id= parameter to the driver (I somehow overlooked that parameter).
So I will revert this change in the next version.
>
> I suppose the rest of this patch is not really about the block layer, so
> I can’t really comment on it. (It looks OK to me from a generic and
> naïve standpoint, though.)
>
> > error_setg(errp, "No top_bs or it is invalid");
> > reopen_backing_file(bs, false, NULL);
> > aio_context_release(aio_context);
>
> [...]
>
> > @@ -593,7 +614,7 @@ static void replication_get_error(ReplicationState *rs, Error **errp)
> > aio_context_acquire(aio_context);
> > s = bs->opaque;
> >
> > - if (s->stage != BLOCK_REPLICATION_RUNNING) {
> > + if (s->stage == BLOCK_REPLICATION_NONE) {
>
> Just one question out of curiosity, though: Is this a bug fix?
No, It only applies to continuous replication, because colo will
check all replication nodes for errors before checkpointing. So
a secondary continuing replication would error out here, because
it is either in state BLOCK_REPLICATION_DONE or
BLOCK_REPLICATION_FAILOVER.
> Max
>
> > error_setg(errp, "Block replication is not running");
> > aio_context_release(aio_context);
> > return;
>
next prev parent reply other threads:[~2019-10-23 18:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-05 13:05 [PATCH v6 0/4] colo: Add support for continuous replication Lukas Straub
2019-10-05 13:05 ` [PATCH v6 1/4] block/replication.c: Ignore requests after failover Lukas Straub
2019-10-18 18:46 ` Lukas Straub
2019-10-23 8:13 ` Zhang, Chen
2019-10-23 12:49 ` Max Reitz
2019-10-23 18:07 ` Lukas Straub [this message]
2019-10-05 13:05 ` [PATCH v6 2/4] tests/test-replication.c: Add test for for secondary node continuing replication Lukas Straub
2019-10-09 6:03 ` Zhang, Chen
2019-10-09 15:19 ` Lukas Straub
2019-10-05 13:05 ` [PATCH v6 3/4] net/filter.c: Add Options to insert filters anywhere in the filter list Lukas Straub
2019-10-05 13:05 ` [PATCH v6 4/4] colo: Update Documentation for continuous replication Lukas Straub
2019-10-09 8:36 ` Zhang, Chen
2019-10-09 15:16 ` Lukas Straub
2019-10-10 10:34 ` Zhang, Chen
2019-10-11 16:00 ` Lukas Straub
2019-10-11 17:39 ` Zhang, Chen
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=20191023200737.6adf4834@luklap \
--to=lukasstraub2@web.de \
--cc=chen.zhang@intel.com \
--cc=jasowang@redhat.com \
--cc=kwolf@redhat.com \
--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 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.