From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <famz@redhat.com>,
qemu block <qemu-block@nongnu.org>,
Jiang Yunhong <yunhong.jiang@intel.com>,
Dong Eddie <eddie.dong@intel.com>,
qemu devel <qemu-devel@nongnu.org>,
"Michael R. Hines" <mrhines@linux.vnet.ibm.com>,
Max Reitz <mreitz@redhat.com>, Gonglei <arei.gonglei@huawei.com>,
Paolo Bonzini <pbonzini@redhat.com>,
zhanghailiang <zhang.zhanghailiang@huawei.com>
Subject: Re: [Qemu-devel] [Patch v12 resend 05/10] docs: block replication's description
Date: Mon, 4 Jan 2016 15:51:26 +0000 [thread overview]
Message-ID: <20160104155126.GH2529@work-vm> (raw)
In-Reply-To: <20151223092603.GA11394@stefanha-x1.localdomain>
* Stefan Hajnoczi (stefanha@redhat.com) wrote:
> On Wed, Dec 02, 2015 at 01:31:46PM +0800, Wen Congyang wrote:
> > +== Failure Handling ==
> > +There are 6 internal errors when block replication is running:
> > +1. I/O error on primary disk
> > +2. Forwarding primary write requests failed
> > +3. Backup failed
> > +4. I/O error on secondary disk
> > +5. I/O error on active disk
> > +6. Making active disk or hidden disk empty failed
> > +In case 1 and 5, we just report the error to the disk layer. In case 2, 3,
> > +4 and 6, we just report block replication's error to FT/HA manager (which
> > +decides when to do a new checkpoint, when to do failover).
> > +There is no internal error when doing failover.
>
> Not sure this is true.
>
> Below it says the following for failover: "We will flush the Disk buffer
> into Secondary Disk and stop block replication". Flushing the disk
> buffer can result in I/O errors. This means that failover operations
> are not guaranteed to succeed.
>
> In practice I think this is similar to a successful failover followed by
> immediately getting I/O errors on the new Primary Disk. It means that
> right after failover there is another failure and the system may not be
> able to continue.
Yes, I think that's true.
> So this really only matters in the case where there is a new Secondary
> ready after failover. In that case the user might expect failover to
> continue to the new Secondary (Host 3):
>
> [X] [X]
> Host 1 <-> Host 2 <-> Host 3
Since COLO is just doing a 1+1 redundency, I think it's not expecting to
cope with a double host failure; it's going to take some time (seconds?) to
sync Host 3 back in when you add it after a failover and the aim would
be not to have distrubed the application for that long, so it should
already be running on Host 2 during that resync.
Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2016-01-04 15:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-02 5:31 [Qemu-devel] [Patch v12 resend 00/10] Block replication for continuous checkpoints Wen Congyang
2015-12-02 5:31 ` [Qemu-devel] [Patch v12 resend 01/10] unblock backup operations in backing file Wen Congyang
2015-12-02 5:31 ` [Qemu-devel] [Patch v12 resend 02/10] Store parent BDS in BdrvChild Wen Congyang
2015-12-02 5:31 ` [Qemu-devel] [Patch v12 resend 03/10] Backup: clear all bitmap when doing block checkpoint Wen Congyang
2015-12-02 5:31 ` [Qemu-devel] [Patch v12 resend 04/10] Allow creating backup jobs when opening BDS Wen Congyang
2015-12-02 5:31 ` [Qemu-devel] [Patch v12 resend 05/10] docs: block replication's description Wen Congyang
2015-12-23 9:26 ` Stefan Hajnoczi
2016-01-04 6:03 ` Wen Congyang
2016-01-26 13:57 ` Stefan Hajnoczi
2016-01-04 15:51 ` Dr. David Alan Gilbert [this message]
2015-12-02 5:31 ` [Qemu-devel] [Patch v12 resend 06/10] Add new block driver interfaces to control block replication Wen Congyang
2015-12-02 5:31 ` [Qemu-devel] [Patch v12 resend 07/10] quorum: implement block driver interfaces for " Wen Congyang
2015-12-02 5:37 ` [Qemu-devel] [Patch v12 resend 08/10] Implement new driver " Wen Congyang
2015-12-23 9:47 ` Stefan Hajnoczi
2016-01-04 5:50 ` Wen Congyang
2016-01-26 14:27 ` Stefan Hajnoczi
2015-12-02 5:37 ` [Qemu-devel] [Patch v12 resend 09/10] support replication driver in blockdev-add Wen Congyang
2015-12-02 5:38 ` [Qemu-devel] [Patch v12 resend 10/10] Add a new API to start/stop replication, do checkpoint to all BDSes Wen Congyang
2015-12-17 6:22 ` [Qemu-devel] [Patch v12 resend 00/10] Block replication for continuous checkpoints Wen Congyang
2015-12-23 10:04 ` Stefan Hajnoczi
2016-01-04 5:27 ` Wen Congyang
2016-01-04 16:03 ` Dr. David Alan Gilbert
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=20160104155126.GH2529@work-vm \
--to=dgilbert@redhat.com \
--cc=arei.gonglei@huawei.com \
--cc=eddie.dong@intel.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=mrhines@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=yunhong.jiang@intel.com \
--cc=zhang.zhanghailiang@huawei.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).