Re: [Qemu-devel] [PATCH v12 2/3] quorum: implement bdrv_add_child() and bdrv_del_child()

[Dr. David Alan Gilbert]

* Max Reitz (address@hidden) wrote:
> On 29.03.2016 17:54, Dr. David Alan Gilbert wrote:
> > * Max Reitz (address@hidden) wrote:
> >> On 29.03.2016 17:50, Dr. David Alan Gilbert wrote:
> >>> * Eric Blake (address@hidden) 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 / address@hidden / Manchester, UK