From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akvwh-0007d0-ME for qemu-devel@nongnu.org; Tue, 29 Mar 2016 11:52:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akvwb-0003d1-LT for qemu-devel@nongnu.org; Tue, 29 Mar 2016 11:52:43 -0400 References: <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> <20160329155024.GH2240@work-vm> From: Max Reitz Message-ID: <56FAA4BB.3080300@redhat.com> Date: Tue, 29 Mar 2016 17:52:27 +0200 MIME-Version: 1.0 In-Reply-To: <20160329155024.GH2240@work-vm> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VkAibWjbTj1ueWANlG3ogUIQARJFR0eQo" 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: "Dr. David Alan Gilbert" , Eric Blake Cc: Kevin Wolf , Changlong Xie , Alberto Garcia , qemu block , Jiang Yunhong , Dong Eddie , qemu devel , Markus Armbruster , Gonglei , Stefan Hajnoczi , zhanghailiang This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VkAibWjbTj1ueWANlG3ogUIQARJFR0eQo Content-Type: multipart/mixed; boundary="Ip5mMFEFPctcfiNF46jFFhju7IsbfVdLa" From: Max Reitz To: "Dr. David Alan Gilbert" , Eric Blake Cc: Wen Congyang , Alberto Garcia , Changlong Xie , qemu devel , Kevin Wolf , Stefan Hajnoczi , Markus Armbruster , Dong Eddie , Jiang Yunhong , qemu block , zhanghailiang , Gonglei Message-ID: <56FAA4BB.3080300@redhat.com> Subject: Re: [PATCH v12 2/3] quorum: implement bdrv_add_child() and bdrv_del_child() References: <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> <20160329155024.GH2240@work-vm> In-Reply-To: <20160329155024.GH2240@work-vm> --Ip5mMFEFPctcfiNF46jFFhju7IsbfVdLa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 29.03.2016 17:50, Dr. David Alan Gilbert wrote: > * Eric Blake (eblake@redhat.com) wrote: >> On 03/29/2016 09:38 AM, Max Reitz wrote: >>> On 17.03.2016 10:56, Wen Congyang wrote: >>>> On 03/17/2016 05:48 PM, Dr. David Alan Gilbert wrote: >>> >>> [...] >>> >>>>> The children.0 notation is really confusing in the way that Berto >>>>> describes; I hit this a couple of months ago and it really doesn't >>>>> make sense. >>>> >>>> Do you mean: read from children.1 first, and then read from children= =2E0 in >>>> fifo mode? Yes, the behavior is very strange. >>> >>> So is this intended or is it not? In >>> http://lists.nongnu.org/archive/html/qemu-block/2016-03/msg00526.html= >>> you said that it is. >>> >>> I myself would indeed say it is very strange. If I were a user, I wou= ld >>> not expect this behavior. And as I developer, I think that how a BDS'= s >>> child is used by its parent should solely depend on its role (e.g. >>> whether it is "children.0" or "children.1"). >> >> 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, a= nd >> so we need a way for the hot-add operation to explicitly specify where= >> in the list a child is inserted (whether it is being inserted as the n= ew >> primary image, or explicitly as the last resort, or somewhere in the >> middle). An optional parameter, that defaults to appending, may be ok= , >> but we definitely need to consider how the order of children is affect= ed >> by hot-add. >=20 > Certainly in the COLO case the two children are not identical; and IMHO= we need > to get away from thinking about ordering and start thinking about funct= ional > namingd - children.0/children.1 doesn't suggest the fact they behave > differently. To me it does. If quorum is operating in a mode call "FIFO" I would expect some order on the child nodes, and if the child nodes are actually numbered in an ascending order, that is an obvious order. Max --Ip5mMFEFPctcfiNF46jFFhju7IsbfVdLa-- --VkAibWjbTj1ueWANlG3ogUIQARJFR0eQo 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+qS7AAoJEDuxQgLoOKytRGwH/RD7dSHqC/7feU8sGcgRCc/y 27eQD4pszuQAP9pIMlPO1tZna12rubJS58Ac731C3Zr9CMdT/vuN+Ea91MT8GhQ4 0+YUk8Vc7WqFeXbeQXYOAsRgb+nUfQzA4U5OrkxInlUrrloiyB/BubZK8MeB5TlH /j9WinsX/KYDGEFRIJtAc2D40wtrXJlGUPxAdRABgIuhglay9U706VVZEty9Jjkl rWKNi5XQ8kz/PYayS33laWzO/G52pba2YPd3Ypcn0QnqtpRfltcHQ0f2GTtW5Vw2 sAcfGsLa9CwF7oN/kXqrzWI324tlCuCOfV+ZLLpRTZWQqviIPcJemkIYDdidxiU= =+bbB -----END PGP SIGNATURE----- --VkAibWjbTj1ueWANlG3ogUIQARJFR0eQo--