From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51770) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ynpte-0004hC-Ut for qemu-devel@nongnu.org; Thu, 30 Apr 2015 10:57:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ynpte-0005qD-6J for qemu-devel@nongnu.org; Thu, 30 Apr 2015 10:57:02 -0400 Date: Thu, 30 Apr 2015 15:56:44 +0100 From: Stefan Hajnoczi Message-ID: <20150430145644.GA26173@stefanha-thinkpad.redhat.com> References: <5539A78D.1020206@cn.fujitsu.com> <5539F4F6.10507@redhat.com> <5539F702.7040708@cn.fujitsu.com> <20150424085841.GC2139@work-vm> <553A070E.8030909@redhat.com> <553A0F18.4010501@cn.fujitsu.com> <553A0EA3.9080400@redhat.com> <20150427093741.GA15658@stefanha-thinkpad.redhat.com> <55409678.5000002@redhat.com> <5540985D.9080406@huawei.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: <5540985D.9080406@huawei.com> Subject: Re: [Qemu-devel] [PATCH COLO v3 01/14] docs: block replication's description List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gonglei Cc: Kevin Wolf , Yang Hongyang , Fam Zheng , Lai Jiangshan , armbru@redhat.com, jcody@redhat.com, Jiang Yunhong , Dong Eddie , "Dr. David Alan Gilbert" , qemu devel , Max Reitz , Paolo Bonzini , qemu block , zhanghailiang --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 29, 2015 at 04:37:49PM +0800, Gonglei wrote: > On 2015/4/29 16:29, Paolo Bonzini wrote: > >=20 > >=20 > > On 27/04/2015 11:37, Stefan Hajnoczi wrote: > >>>> But it's only for the failover case. Quorum (or a new=20 > >>>> block/colo.c driver or filter) is fine for normal colo=20 > >>>> operation. > >> Perhaps this patch series should mirror the Secondary's disk to a=20 > >> Backup Secondary so that the system can be protected very quickly=20 > >> after failover. > >> > >> I think anyone serious about fault tolerance would deploy a Backup > >> Secondary, otherwise the system cannot survive two failures > >> unless a human administrator is lucky/fast enough to set up a new=20 > >> Secondary. > >=20 > > Let's do one thing at a time. Otherwise nothing of this is going to > > be ever completed... > >=20 > Yes, and the continuous backup feature is on our TODO list. We hope > this series (including basic functions and COLO framework) can be > upstream first. That's fine, I just wanted to make sure you have the issue in mind. Stefan --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVQkKsAAoJEJykq7OBq3PIAmgH/jbYTNUAFZESZoBLwEuEvJqe ORUXXXxUpfZ/6n5JT8/5TPehyRGyVQaj5zNnUFktQfnXq5Oj4MdQvtlOGfEXK93d wKTUEstmaoxBqQbc2+K/qQ1w9BdgmVpdVxekdJMV5cL4nzZgoQA6pHlZnu29/O8v hluUD9TuW+XHeSfCTQoHhS7/T/mwEc/6Ql6KBfVmDkNmDgPcWUXRKKIU6wEPF0Oy UNjvqge/FzJ6qP5SZzR3xd0X6nIZKNkPE8pEMQ9AQ76uWj2jLJg/1Fs5L03eO7FX q5YBOhouDBbNDrfK8dose6WDEd8bubEGiVJZQ7bCAN3l/N4cJTwX6SVdLr3HTzA= =6M9h -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh--