From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akwCv-0006TX-4r for qemu-devel@nongnu.org; Tue, 29 Mar 2016 12:09:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akwCr-0000d9-0U for qemu-devel@nongnu.org; Tue, 29 Mar 2016 12:09:29 -0400 References: <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> <56FAA4BB.3080300@redhat.com> <20160329155426.GI2240@work-vm> <56FAA65C.3080107@redhat.com> <20160329160309.GJ2240@work-vm> From: Max Reitz Message-ID: <56FAA8A3.6010604@redhat.com> Date: Tue, 29 Mar 2016 18:09:07 +0200 MIME-Version: 1.0 In-Reply-To: <20160329160309.GJ2240@work-vm> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="icQClBgimix9mi4CjaQiHvtAdD1p4vnD4" 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" 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) --icQClBgimix9mi4CjaQiHvtAdD1p4vnD4 Content-Type: multipart/mixed; boundary="NG8TJmE2xw4E07w3eo7XiVqOviSTdPVV9" From: Max Reitz To: "Dr. David Alan Gilbert" Cc: Eric Blake , Wen Congyang , Alberto Garcia , Changlong Xie , qemu devel , Kevin Wolf , Stefan Hajnoczi , Markus Armbruster , Dong Eddie , Jiang Yunhong , qemu block , zhanghailiang , Gonglei Message-ID: <56FAA8A3.6010604@redhat.com> Subject: Re: [PATCH v12 2/3] quorum: implement bdrv_add_child() and bdrv_del_child() References: <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> <56FAA4BB.3080300@redhat.com> <20160329155426.GI2240@work-vm> <56FAA65C.3080107@redhat.com> <20160329160309.GJ2240@work-vm> In-Reply-To: <20160329160309.GJ2240@work-vm> --NG8TJmE2xw4E07w3eo7XiVqOviSTdPVV9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 29.03.2016 18:03, Dr. David Alan Gilbert wrote: > * Max Reitz (mreitz@redhat.com) wrote: >> On 29.03.2016 17:54, Dr. David Alan Gilbert wrote: >>> * Max Reitz (mreitz@redhat.com) wrote: >>>> 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 Ber= to >>>>>>>>> describes; I hit this a couple of months ago and it really does= n't >>>>>>>>> make sense. >>>>>>>> >>>>>>>> Do you mean: read from children.1 first, and then read from chil= dren.0 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= would >>>>>>> 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= =2E >>>>>>> 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 matter= s, and >>>>>> so we need a way for the hot-add operation to explicitly specify w= here >>>>>> in the list a child is inserted (whether it is being inserted as t= he new >>>>>> primary image, or explicitly as the last resort, or somewhere in t= he >>>>>> middle). An optional parameter, that defaults to appending, may b= e ok, >>>>>> but we definitely need to consider how the order of children is af= fected >>>>>> by hot-add. >>>>> >>>>> 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 f= unctional >>>>> namingd - children.0/children.1 doesn't suggest the fact they behav= e >>>>> 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. >>> >>> I don't understand why it's called 'FIFO'. >> >> Because in that mode quorum successively reads from all of its childre= n >> and returns the first successful result. So the First successful Input= >> is the one that becomes quorum's Output (there isn't much of a >> successive output, so it doesn't make much sense to call that the Firs= t >> Output, though...). >> >> I didn't name it, though. *waves hands defensively* :-) >=20 > But that description doesn't make sense for what COLO uses it for. >=20 > They have, on the primary host: > 0) Local disk > 1) an NBD connection to the secondary >=20 > So in theory a read should always happen from (0) and writes should > go to both. Well that's the way it works, isn't it? I didn't mention what happens with writes, but those are indeed distributed to all of quorum's children. And as long as the local disk doesn't fail, data is always read from it alone. All you need to do is make sure that the local disk is the first node in whatever order FIFO is supposed to use. Max --NG8TJmE2xw4E07w3eo7XiVqOviSTdPVV9-- --icQClBgimix9mi4CjaQiHvtAdD1p4vnD4 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+qijAAoJEDuxQgLoOKyt9awH/j40Ava7B5EJoTLF2tKh2MDT 5LpxE43fKf7r/83CToEcA78MGldhXJyg99qOCdYB8MpNDS4dQ1+UzGFDZ/YDZtzf ECpzwL2QIKMoNuyOeqUplbJmY1gmmFzcyqF6W79YuMLe0J2NI2DN1Lk+SvVSdezu xqnPhvQiOxvdhORq8TLe9D2J9k2rYGYpVetGsecEOJ3PDtEROgerQRdxFxlw6mcq LGPTXW4Mts1PBArJf/bK1i8EYgrSD0DfP3heUnJJM2nRDviMyFoeg4bUdXupWUVf VH4phRj7JA6p8XOpNzjaoFgZjUbZ/Utg6/Lbj15SFezbiLD8q/SbbGjZ1GDzfDk= =zaiR -----END PGP SIGNATURE----- --icQClBgimix9mi4CjaQiHvtAdD1p4vnD4--