From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFevw-0006rj-9V for qemu-devel@nongnu.org; Fri, 08 Aug 2014 03:49:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XFevq-0006hC-AS for qemu-devel@nongnu.org; Fri, 08 Aug 2014 03:49:52 -0400 Received: from mail-pa0-x236.google.com ([2607:f8b0:400e:c03::236]:57389) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFevq-0006h8-3M for qemu-devel@nongnu.org; Fri, 08 Aug 2014 03:49:46 -0400 Received: by mail-pa0-f54.google.com with SMTP id fa1so6924339pad.27 for ; Fri, 08 Aug 2014 00:49:44 -0700 (PDT) Date: Fri, 8 Aug 2014 15:49:37 +0800 From: Liu Yuan Message-ID: <20140808074937.GI12057@ubuntu-trusty> References: <1407396520-2720-1-git-send-email-mitake.hitoshi@lab.ntt.co.jp> <1407396520-2720-2-git-send-email-mitake.hitoshi@lab.ntt.co.jp> <20140808052038.GD12057@ubuntu-trusty> <87vbq3zf0e.wl%mitake.hitoshi@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vbq3zf0e.wl%mitake.hitoshi@lab.ntt.co.jp> Subject: Re: [Qemu-devel] [PATCH 1/2] sheepdog: adopting protocol update for VDI locking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hitoshi Mitake Cc: Kevin Wolf , sheepdog@lists.wpkg.org, mitake.hitoshi@gmail.com, MORITA Kazutaka , qemu-devel@nongnu.org, Stefan Hajnoczi On Fri, Aug 08, 2014 at 03:12:17PM +0900, Hitoshi Mitake wrote: > At Fri, 8 Aug 2014 13:20:39 +0800, > Liu Yuan wrote: > > > > On Thu, Aug 07, 2014 at 04:28:39PM +0900, Hitoshi Mitake wrote: > > > The update is required for supporting iSCSI multipath. It doesn't > > > affect behavior of QEMU driver but adding a new field to vdi request > > > struct is required. > > > > > > Cc: Kevin Wolf > > > Cc: Stefan Hajnoczi > > > Cc: Liu Yuan > > > Cc: MORITA Kazutaka > > > Signed-off-by: Hitoshi Mitake > > > --- > > > block/sheepdog.c | 8 +++++++- > > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > > > diff --git a/block/sheepdog.c b/block/sheepdog.c > > > index 8d9350c..36f76f0 100644 > > > --- a/block/sheepdog.c > > > +++ b/block/sheepdog.c > > > @@ -103,6 +103,9 @@ > > > #define SD_INODE_SIZE (sizeof(SheepdogInode)) > > > #define CURRENT_VDI_ID 0 > > > > > > +#define LOCK_TYPE_NORMAL 1 > > > +#define LOCK_TYPE_SHARED 2 /* for iSCSI multipath */ > > > > How about > > > > #define LOCK_TYPE_NORMAL 0 > > #define LOCK_TYPE_SHARED 1 > > > > Then we don't need this patch. Since qemu won't make use of multipath for the > > near future, we should avoid adding stuff related to multipath to qemu driver. > > (Cc-ing current Kazutaka-san's address) > > I think this isn't a good idea. Because it means that sheep has an > assumption about padding field of the request data struct. This sort > of workaround can cause hard to find problems in the future. > The point is, how to keep backward compatibilty? E.g, old QEMU with present sheep daemon with lock features. Then QEMU will send 0 instead of 1 to the sheep daemon and based on how you handle the invalid value, these might cause problems. Suppose we have 1 old QEMU and 1 present QEMU who try to start the same image A. Old QEMU will send invalid 0 to sheep daemon. We shouldn't deny it because it can run with old sheep and should run on new sheep too. Then this image A isn't locked due to invalid 0 value. Then present QEMU send correct LOCK signal and will wrongly set up the image. Start with 0 instead of 1, in my option, is reasonable to keep backward compatibility. Thanks Yuan