From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55601) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alHib-0005Zz-El for qemu-devel@nongnu.org; Wed, 30 Mar 2016 11:07:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1alHiW-0007kU-DE for qemu-devel@nongnu.org; Wed, 30 Mar 2016 11:07:37 -0400 References: <1457578181-27111-1-git-send-email-xiecl.fnst@cn.fujitsu.com> <1457578181-27111-3-git-send-email-xiecl.fnst@cn.fujitsu.com> <56E653E0.9030808@cn.fujitsu.com> <56EA06E0.7000409@cn.fujitsu.com> <56EA7C62.3090000@cn.fujitsu.com> <20160317094831.GA2504@work-vm> <56EA7F39.9060504@cn.fujitsu.com> <56FAA168.9090304@redhat.com> <56FAA2C4.3000002@redhat.com> <56FAA47A.2020801@redhat.com> From: Max Reitz Message-ID: <56FBEBA3.9070305@redhat.com> Date: Wed, 30 Mar 2016 17:07:15 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5NIdtJSfAgt7BCA5wb6XQrm2LBSxVAP59" Subject: Re: [Qemu-devel] [PATCH v12 2/3] quorum: implement bdrv_add_child() and bdrv_del_child() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia , Eric Blake , Wen Congyang , "Dr. David Alan Gilbert" Cc: Kevin Wolf , Changlong Xie , zhanghailiang , qemu block , Jiang Yunhong , Dong Eddie , qemu devel , Markus Armbruster , Gonglei , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5NIdtJSfAgt7BCA5wb6XQrm2LBSxVAP59 Content-Type: multipart/mixed; boundary="wBcra2H1CsAmJifFUjtWBemjTi5wCfTbH" From: Max Reitz To: Alberto Garcia , Eric Blake , Wen Congyang , "Dr. David Alan Gilbert" Cc: Changlong Xie , qemu devel , Kevin Wolf , Stefan Hajnoczi , Markus Armbruster , Dong Eddie , Jiang Yunhong , qemu block , zhanghailiang , Gonglei Message-ID: <56FBEBA3.9070305@redhat.com> Subject: Re: [PATCH v12 2/3] quorum: implement bdrv_add_child() and bdrv_del_child() References: <1457578181-27111-1-git-send-email-xiecl.fnst@cn.fujitsu.com> <1457578181-27111-3-git-send-email-xiecl.fnst@cn.fujitsu.com> <56E653E0.9030808@cn.fujitsu.com> <56EA06E0.7000409@cn.fujitsu.com> <56EA7C62.3090000@cn.fujitsu.com> <20160317094831.GA2504@work-vm> <56EA7F39.9060504@cn.fujitsu.com> <56FAA168.9090304@redhat.com> <56FAA2C4.3000002@redhat.com> <56FAA47A.2020801@redhat.com> In-Reply-To: --wBcra2H1CsAmJifFUjtWBemjTi5wCfTbH Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On 30.03.2016 13:39, Alberto Garcia wrote: > On Tue 29 Mar 2016 05:51:22 PM CEST, Max Reitz wrote: >>> It sounds like the argument here, and in Max's thread on >>> query-block-node-tree, is that we DO have cases where order matters, = and >>> so we need a way for the hot-add operation to explicitly specify wher= e >>> in the list a child is inserted (whether it is being inserted as the = new >>> primary image, or explicitly as the last resort, or somewhere in the >>> middle). An optional parameter, that defaults to appending, may be o= k, >>> but we definitely need to consider how the order of children is affec= ted >>> by hot-add. >> >> However, the order should be queriable after the fact, and there are >> three ways I see to accomplish this: >> >> (1) Make this information queriable as driver-specific BDS information= =2E >> I personally don't like it very much, but it would be fine. >> (2) Implement query-block-node-tree, make the order of child nodes >> significant and thus represent the FIFO order there. I don't like >> this because it would mean returning two orders through that child= >> node list: One is the numeric order (children.0, children.1, ...) >> and another is the FIFO order, which are not necessarily equal. >> (3) Fix FIFO order to the child name (its role). I'm very much in favo= r >> of this. >> >> While I don't have good arguments against (1), I think I have good >> arguments for (3) instead: It just doesn't make sense to have a numeri= c >> order of children if this order doesn't mean anything; especially if y= ou >> suddenly do need the list of child nodes to be ordered. To me, it >> doesn't make any sense to introduce a new hidden order which takes >> precedence over this obvious user-visible order. >=20 > I'm not sure if I understand correctly what you mean in (3). The > user-visible FIFO order is the one specified when the Quorum is created= : >=20 > children.0.file.filename=3Dhd0.qcow2, > children.1.file.filename=3Dhd1.qcow2, > ... >=20 > Would you then call those BDS children.0, children.1, etc They are already called that way; it's not their node name but their "child role" name. > and make thos= e > names be the ones that actually define how they are ordered internally?= Yes, that's what I meant. > I also have another (not directly related) question: why not simply use= > the node name when removing children? I understood that the idea was > that it's possible to have the same node attached twice to the same > Quorum, but can you actually do that? And what's the use case? What I like about using the child role name is that it automatically prevents you from specifying a node that is not a child of the given pare= nt. Which makes me notice that it might be a good idea to require the user to specify the child's role when adding a new child. In this version of this series (where only quorum is supported), the children are just inserted in numerical order (first free slot is taken first), but maybe the user wants to insert them in a different order. For quorum, this is basically irrelevant if the order doesn't mean anything (which I don't like), but it may be relevant for other block drivers. And the "filling up quorum's children" topic then makes me notice that (x-)blockdev-change should probably be transaction-able (so you can restructure the whole BDS graph in a single transaction), but that's something we can care about later on. Max --wBcra2H1CsAmJifFUjtWBemjTi5wCfTbH-- --5NIdtJSfAgt7BCA5wb6XQrm2LBSxVAP59 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW++ujAAoJEDuxQgLoOKytGXwH/RHo4RiVLrnfoYiu7GqmNOty sAu+7zTIBpa8egowuyWIFL3BQQroHuEEflQexKN/oQaX9j198j+faVYbuauHDx00 kIcECVefaSvQxhkgovZA7mPA2z9gzoWmGVTGC4M16hS7z1+0gZyRmfhFNZIMBbI6 klZg19f+mdJrowbPfX8ZY0bhWUHQa003YEa5caMvWKoCSIk0M5U/jJnl/UYYIh8w 2k+s0sS8NLEFMXnIwuVZ9Dp30jXpaVMIfAnRviX+Lc/566evzUoqFmzO3W440NlB 1RFfhNw+V1amaIGY2agoqxgL/VJPUkP/fojbLRCMvhSUeT95UOgCLHFntzJ+Acs= =nubL -----END PGP SIGNATURE----- --5NIdtJSfAgt7BCA5wb6XQrm2LBSxVAP59--