qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).