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 <we...@cn.fujitsu.com>
Signed-off-by: zhanghailiang <zhang.zhanghaili...@huawei.com>
Signed-off-by: Gonglei <arei.gong...@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

Reply via email to