From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:49310)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dgilbert@redhat.com>) id 1aMhua-0000v2-81
	for qemu-devel@nongnu.org; Fri, 22 Jan 2016 15:02:25 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <dgilbert@redhat.com>) id 1aMhuZ-0008Qi-Ex
	for qemu-devel@nongnu.org; Fri, 22 Jan 2016 15:02:24 -0500
Date: Fri, 22 Jan 2016 20:02:10 +0000
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Message-ID: <20160122200209.GA18933@work-vm>
References: <1451035376-7252-1-git-send-email-xiecl.fnst@cn.fujitsu.com>
	<1451035376-7252-3-git-send-email-xiecl.fnst@cn.fujitsu.com>
	<w51r3hcmf2m.fsf@maestria.local.igalia.com>
	<56A03A42.7060802@cn.fujitsu.com>
	<w51lh7j5bho.fsf@maestria.local.igalia.com>
	<56A10E42.5040500@redhat.com>
	<w51d1sulzlt.fsf@maestria.local.igalia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <w51d1sulzlt.fsf@maestria.local.igalia.com>
Subject: Re: [Qemu-devel] [PATCH v9 2/3] quorum: implement bdrv_add_child()
 and bdrv_del_child()
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alberto Garcia <berto@igalia.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Changlong Xie <xiecl.fnst@cn.fujitsu.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>, Markus Armbruster <armbru@redhat.com>, Gonglei <arei.gonglei@huawei.com>, Stefan Hajnoczi <stefanha@redhat.com>, zhanghailiang <zhang.zhanghailiang@huawei.com>

* Alberto Garcia (berto@igalia.com) wrote:
> On Thu 21 Jan 2016 05:58:42 PM CET, Eric Blake <eblake@redhat.com> wrote:
> >>>> In general, what do you do to make sure that the data in a new Quorum
> >>>> child is consistent with that of the rest of the array?
> >>>
> >>> Quorum can have more than one child when it starts. But we don't do
> >>> the similar check. So I don't think we should do such check here.
> >> 
> >> Yes, but when you start a VM you can verify in advance that all
> >> members of the Quorum have the same data. If you do that on a running
> >> VM how can you know if the new disk is consistent with the others?
> >
> > User error if it is not.  Just the same as it is user error if you
> > request a shallow drive-mirror but the destination is not the same
> > contents as the backing file.  I don't think qemu has to protect us
> > from user error in this case.
> 
> But the backing file is read-only so the user can guarantee that the
> destination has the same data before the shallow mirror. How do you do
> that in this case?

I think in the colo case they're relying on doing a block migrate
to synchronise the remote disk prior to switching into colo mode.

Dave

> Berto
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK