On 29.03.2016 17:50, Dr. David Alan Gilbert wrote: > * Eric Blake (ebl...@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.
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
signature.asc
Description: OpenPGP digital signature
