From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:32843)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1YQ5HT-0003O3-0A
	for qemu-devel@nongnu.org; Mon, 23 Feb 2015 21:31:27 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1YQ5HP-0003Oa-M2
	for qemu-devel@nongnu.org; Mon, 23 Feb 2015 21:31:26 -0500
Received: from [59.151.112.132] (port=19700 helo=heian.cn.fujitsu.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wency@cn.fujitsu.com>) id 1YQ5HM-00032r-7K
	for qemu-devel@nongnu.org; Mon, 23 Feb 2015 21:31:23 -0500
Message-ID: <54EBE2F8.1040709@cn.fujitsu.com>
Date: Tue, 24 Feb 2015 10:33:28 +0800
From: Wen Congyang <wency@cn.fujitsu.com>
MIME-Version: 1.0
References: <1423710438-14377-1-git-send-email-wency@cn.fujitsu.com>
	<1423710438-14377-4-git-send-email-wency@cn.fujitsu.com>
	<54EB910F.5060000@redhat.com>
In-Reply-To: <54EB910F.5060000@redhat.com>
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC PATCH 03/14] quorum: ignore 0-length 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: Max Reitz <mreitz@redhat.com>, qemu devel <qemu-devel@nongnu.org>, Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>, Jiang Yunhong <yunhong.jiang@intel.com>, Dong Eddie <eddie.dong@intel.com>, "Dr. David
	Alan Gilbert" <dgilbert@redhat.com>, Gonglei <arei.gonglei@huawei.com>, Yang Hongyang <yanghy@cn.fujitsu.com>, zhanghailiang <zhang.zhanghailiang@huawei.com>

On 02/24/2015 04:43 AM, Max Reitz wrote:
> On 2015-02-11 at 22:07, Wen Congyang wrote:
>> We connect to NBD server when starting block replication, so
>> the length is 0 before starting block replication.
>>
>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
>> Signed-off-by: Gonglei <arei.gonglei@huawei.com>
>> ---
>>   block/quorum.c | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/block/quorum.c b/block/quorum.c
>> index 5ed1ff8..e6aff5f 100644
>> --- a/block/quorum.c
>> +++ b/block/quorum.c
>> @@ -734,6 +734,11 @@ static int64_t quorum_getlength(BlockDriverState *bs)
>>           if (value < 0) {
>>               return value;
>>           }
>> +
>> +        if (!value) {
>> +            continue;
>> +        }
>> +
>>           if (value != result) {
>>               return -EIO;
>>           }
> 
> Hm, what do you think about some specific error value returned by your delayed NBD implementation? Like -ENOTCONN or something like that? Then we'd be able to discern a real 0-length block device from a not-yet-connected NBD server.
> 
> Also, while you did write that one shouldn't be using the NBD client as the first quorum child, I think we should try to support that case anyway. For this patch, that means accepting that bdrv_getlength(s->bs[0]) may be off.

Good idea. I will try it.

Thanks
Wen Congyang

> 
> Max
> .
>