* Max Reitz (mre...@redhat.com) wrote: > On 29.03.2016 17:54, Dr. David Alan Gilbert wrote: > > * Max Reitz (mre...@redhat.com) wrote: > >> 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. > > > > I don't understand why it's called 'FIFO'. > > Because in that mode quorum successively reads from all of its children > 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 First > Output, though...). > > I didn't name it, though. *waves hands defensively* :-)
But that description doesn't make sense for what COLO uses it for. They have, on the primary host: 0) Local disk 1) an NBD connection to the secondary So in theory a read should always happen from (0) and writes should go to both. Dave > Max > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK