From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aq14a-0001u7-DG for qemu-devel@nongnu.org; Tue, 12 Apr 2016 12:21:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aq14Z-0008NW-3E for qemu-devel@nongnu.org; Tue, 12 Apr 2016 12:21:52 -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> <56FBEBA3.9070305@redhat.com> <570B33AA.7000902@cn.fujitsu.com> From: Max Reitz Message-ID: <570D208E.7070402@redhat.com> Date: Tue, 12 Apr 2016 18:21:34 +0200 MIME-Version: 1.0 In-Reply-To: <570B33AA.7000902@cn.fujitsu.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4p794KjmmtfdLRL0OfCOKfOtdKCtH5Wn2" 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: Changlong Xie , Alberto Garcia , Eric Blake , Wen Congyang , "Dr. David Alan Gilbert" Cc: qemu devel , Kevin Wolf , Stefan Hajnoczi , Markus Armbruster , Dong Eddie , Jiang Yunhong , qemu block , zhanghailiang , Gonglei This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4p794KjmmtfdLRL0OfCOKfOtdKCtH5Wn2 Content-Type: multipart/mixed; boundary="8BR9RxoAFLWPCJmliUp3cFBKTcD129pWW" From: Max Reitz To: Changlong Xie , Alberto Garcia , Eric Blake , Wen Congyang , "Dr. David Alan Gilbert" Cc: qemu devel , Kevin Wolf , Stefan Hajnoczi , Markus Armbruster , Dong Eddie , Jiang Yunhong , qemu block , zhanghailiang , Gonglei Message-ID: <570D208E.7070402@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> <56FBEBA3.9070305@redhat.com> <570B33AA.7000902@cn.fujitsu.com> In-Reply-To: <570B33AA.7000902@cn.fujitsu.com> --8BR9RxoAFLWPCJmliUp3cFBKTcD129pWW Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On 11.04.2016 07:18, Changlong Xie wrote: > On 03/30/2016 11:07 PM, Max Reitz wrote: >> 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 wh= ere >>>>> 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 th= e >>>>> middle). An optional parameter, that defaults to appending, may be= >>>>> ok, >>>>> but we definitely need to consider how the order of children is >>>>> affected >>>>> 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 informati= on. >>>> 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 li= ke >>>> this because it would mean returning two orders through that ch= ild >>>> node list: One is the numeric order (children.0, children.1, ..= =2E) >>>> 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 fa= vor >>>> 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 nume= ric >>>> order of children if this order doesn't mean anything; especially if= >>>> you >>>> 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. >>> >>> 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 creat= ed: >>> >>> children.0.file.filename=3Dhd0.qcow2, >>> children.1.file.filename=3Dhd1.qcow2, >>> ... >>> >>> 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 >>> those >>> names be the ones that actually define how they are ordered internall= y? >> >> Yes, that's what I meant. >> > Hi Max >=20 > I think you just mean what i draw in below chart: >=20 > 1) Insert 4 children. > 0 1 2 3 > +---------------------------------------------------- > |children.0|children.1|children.2|children.3| > +---------------------------------------------------- >=20 > 2) Remove the 2th child (s->children[1]) >=20 > { "execute": "x-blockdev-change", >=20 > "arguments": { "parent": "xxx", >=20 > "child": "children.1" } } >=20 > 0 1 2 3 > +---------------------------------------------------- > |children.0|children.1|children.2|children.3| > +------------------------+------------+-------------- > | | =20 > +------+ +--------+ > 0 1 | 2 | > +----------------v----------v------------------------ > |children.0|children.1|children.2| > +---------------------------------------------------- No, what I meant, is: 0 1 2 3 +----------+----------+----------+----------+ |children.0|children.1|children.2|children.3| +----------+----------+----------+----------+ | v 0 1 2 3 +----------+----------+----------+----------+ |children.0| |children.2|children.3| +----------+----------+----------+----------+ I.e., children.1 simply ceases to exist. Max > Remove children.1 and shorten the array, then rename children.{2,3} to > children.{1.2} >=20 > 3) Insert a new child >=20 > 0 1 2 3 > +---------------------------------------------------- > |children.0|children.1|children.2|children.3| > +---------------------------------------------------- >=20 > But as Wen said: > http://lists.nongnu.org/archive/html/qemu-devel/2016-04/msg00898.html >=20 > Everytime we try to remove a children.i (i < n-1, so it's not the last > element of the array[n]), we have to rename children.{i+1, n-1} to > children.{i, n-2}. >=20 > Thanks > -Xie --8BR9RxoAFLWPCJmliUp3cFBKTcD129pWW-- --4p794KjmmtfdLRL0OfCOKfOtdKCtH5Wn2 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 iQEcBAEBCAAGBQJXDSCPAAoJEDuxQgLoOKyt35AH/2bG9Q6Y6oShCTnI7GzINNlj ZembJTzJR2yjOrZIVgGd4V9fhk63lceBHlGhq5FvA1ejNLpb2TZx6f8znwK0uI9C sA10GgvILviiBboINelZv4CZo19vNgwgNNIm5sumfKGVWocqCR0MqJpSwr68GN/f CyPOz2HJ8NYdnrzK2zaXA9RDiJPSnhEQ+FfXyaCj0WZ+/ZWpereW6y2+Gk7s8kQT X/YaPQxnnAw4i52I6PNtBzoetgYWkUaOKkZgnGUGVSyXFN1K4d0APeM1YwZscr0b 41KOH3ss2u9nPNz2XsFWqUTFBf31LdMOQL1Uw9Mr3xcX6flELvxsOPGokr6xkso= =IPmG -----END PGP SIGNATURE----- --4p794KjmmtfdLRL0OfCOKfOtdKCtH5Wn2--