From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akZ2d-00046Z-NP for qemu-devel@nongnu.org; Mon, 28 Mar 2016 11:25:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akZ2X-0007Hl-Su for qemu-devel@nongnu.org; Mon, 28 Mar 2016 11:25:19 -0400 References: <1458846438-28573-1-git-send-email-mreitz@redhat.com> <1458846438-28573-2-git-send-email-mreitz@redhat.com> <56F4E0C0.6080609@cn.fujitsu.com> <56F6B9DA.1090601@redhat.com> From: Eric Blake Message-ID: <56F94CD3.5010608@redhat.com> Date: Mon, 28 Mar 2016 09:25:07 -0600 MIME-Version: 1.0 In-Reply-To: <56F6B9DA.1090601@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Xir02RuDSOkLvvN9iX0XfieiD052Ihmpc" Subject: Re: [Qemu-devel] [RFC for-2.7 1/1] block/qapi: Add query-block-node-tree List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , Wen Congyang , qemu-block@nongnu.org Cc: Kevin Wolf , qemu-devel@nongnu.org, Markus Armbruster This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Xir02RuDSOkLvvN9iX0XfieiD052Ihmpc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/26/2016 10:33 AM, Max Reitz wrote: >> We insert the new child to the head, not the tail... >=20 > Well, the idea is that the order of children doesn't really matter; The= > only thing that describes the behavior of a child is its role. For > instance, for qcow2 it doesn't matter whether the "file" or the > "backing" BDS is the first child. >=20 > However, for quorum, the order might matter (e.g. in FIFO mode). But > then again, the order is clearly specified by the role again: The first= > child is the one with the "children.0" role. >=20 > So I don't think this is real problem as long as I add a note to the > documentation that the order of objects in the @children array is > undefined and does not have any significance. What happens when we hot-add/-delete children from a FIFO mode quorum? Obviously, we can select which child to delete, so if we delete the child.0 node, do we have guaranteed semantics on which node takes over the role as the primary child? Conversely, when adding a node, do we have a way to specify whether the new node must be at the front (assume the child.0 role) or back (must not affect the current FIFO roles)? I think order is important enough for FIFO mode that we ought to try and represent it explicitly in the command, rather than getting it backwards or stating it is undefined. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --Xir02RuDSOkLvvN9iX0XfieiD052Ihmpc 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJW+UzTAAoJEKeha0olJ0NqYFEH/i5vH5korJAMlJ6bH/aGHAyW c85rLjWMSL3u+Hnzcs+YudBMPvGklB4Y8PgUFmA2nvhLH3u+lf8i9ZSVDCO6JXJo K9li7FCWdO1h1TOm+WHoPAYlQ0gOYbn07xzZkjTARhj+WmtvlMIONHgiVpADndIJ du+/3gTOPur0w/Pq79Pl61CLdSgM3N2qLRRm1wL2ABXX4gJ1Jk6yeuIqKIg5lhAm m8hr4Z05iOE3t4DwVTCp4nQbCR5LlUYXRB9QaielnzkGAmchOc4UdYtxfRRAr8do Ba8rbvscjL1/qf/wM++OaKl1cuywNJ2afbFXSj8L2uquAs/AOPjBvZbsR8p5tKs= =IuKR -----END PGP SIGNATURE----- --Xir02RuDSOkLvvN9iX0XfieiD052Ihmpc--