From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55583) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akvuj-0004vq-1n for qemu-devel@nongnu.org; Tue, 29 Mar 2016 11:50:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akvuh-0003G9-Qh for qemu-devel@nongnu.org; Tue, 29 Mar 2016 11:50:40 -0400 Date: Tue, 29 Mar 2016 16:50:25 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20160329155024.GH2240@work-vm> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56FAA2C4.3000002@redhat.com> 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: Eric Blake Cc: Kevin Wolf , Changlong Xie , Alberto Garcia , qemu block , Markus Armbruster , Jiang Yunhong , Dong Eddie , qemu devel , Max Reitz , Gonglei , Stefan Hajnoczi , zhanghailiang * 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.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. > > 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, and > 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 new > 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 affected > 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 functional namingd - children.0/children.1 doesn't suggest the fact they behave differently. Dave > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK