From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:43465)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <xiecl.fnst@cn.fujitsu.com>) id 1aVYk9-0004HY-8R
	for qemu-devel@nongnu.org; Tue, 16 Feb 2016 01:04:14 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <xiecl.fnst@cn.fujitsu.com>) id 1aVYk8-0001WD-Bt
	for qemu-devel@nongnu.org; Tue, 16 Feb 2016 01:04:13 -0500
Message-ID: <56C2BC13.7020906@cn.fujitsu.com>
Date: Tue, 16 Feb 2016 14:05:07 +0800
From: Changlong Xie <xiecl.fnst@cn.fujitsu.com>
MIME-Version: 1.0
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>
	<20160122200209.GA18933@work-vm>
	<w5137t39lnb.fsf@maestria.local.igalia.com>
In-Reply-To: <w5137t39lnb.fsf@maestria.local.igalia.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
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>, "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Kevin Wolf <kwolf@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>, Markus Armbruster <armbru@redhat.com>, Gonglei <arei.gonglei@huawei.com>, Stefan Hajnoczi <stefanha@redhat.com>, zhanghailiang <zhang.zhanghailiang@huawei.com>

On 02/09/2016 01:06 AM, Alberto Garcia wrote:
> On Fri 22 Jan 2016 09:02:10 PM CET, "Dr. David Alan Gilbert" <dgilbert@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.
>
> Yes but this is a general API that can be used independently from
> COLO. I'd say if we want to allow that we should at least place a big
> warning in the documentation.
>

Ok, that's fair enough. Will add in next version.

Thanks
	-Xie
> Berto
>
>
> .
>