From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:44441)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mreitz@redhat.com>) id 1YPzri-0008Co-Fh
	for qemu-devel@nongnu.org; Mon, 23 Feb 2015 15:44:31 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mreitz@redhat.com>) id 1YPzrf-0003yJ-9h
	for qemu-devel@nongnu.org; Mon, 23 Feb 2015 15:44:30 -0500
Received: from mx1.redhat.com ([209.132.183.28]:54524)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mreitz@redhat.com>) id 1YPzrf-0003yD-27
	for qemu-devel@nongnu.org; Mon, 23 Feb 2015 15:44:27 -0500
Message-ID: <54EB910F.5060000@redhat.com>
Date: Mon, 23 Feb 2015 15:43:59 -0500
From: Max Reitz <mreitz@redhat.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>
In-Reply-To: <1423710438-14377-4-git-send-email-wency@cn.fujitsu.com>
Content-Type: text/plain; charset=iso-8859-15; format=flowed
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: Wen Congyang <wency@cn.fujitsu.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 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.

Max