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

[Changlong Xie]

On 03/30/2016 11:07 PM, Max Reitz wrote:
> On 30.03.2016 13:39, Alberto Garcia wrote:
> > On Tue 29 Mar 2016 05:51:22 PM CEST, Max Reitz wrote:
> > > > 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.
> > >
> > > However, the order should be queriable after the fact, and there are
> > > three ways I see to accomplish this:
> > >
> > > (1) Make this information queriable as driver-specific BDS information.
> > >      I personally don't like it very much, but it would be fine.
> > > (2) Implement query-block-node-tree, make the order of child nodes
> > >      significant and thus represent the FIFO order there. I don't like
> > >      this because it would mean returning two orders through that child
> > >      node list: One is the numeric order (children.0, children.1, ...)
> > >      and another is the FIFO order, which are not necessarily equal.
> > > (3) Fix FIFO order to the child name (its role). I'm very much in favor
> > >      of this.
> > >
> > > While I don't have good arguments against (1), I think I have good
> > > arguments for (3) instead: It just doesn't make sense to have a numeric
> > > order of children if this order doesn't mean anything; especially if you
> > > suddenly do need the list of child nodes to be ordered. To me, it
> > > doesn't make any sense to introduce a new hidden order which takes
> > > precedence over this obvious user-visible order.
> >
> > I'm not sure if I understand correctly what you mean in (3). The
> > user-visible FIFO order is the one specified when the Quorum is created:
> >
> > children.0.file.filename=hd0.qcow2,
> > children.1.file.filename=hd1.qcow2,
> > ...
> >
> > Would you then call those BDS children.0, children.1, etc
>
> They are already called that way; it's not their node name but their
> "child role" name.
>
> >                                                            and make those
> > names be the ones that actually define how they are ordered internally?
>
> Yes, that's what I meant.
Hi Max

I think you just mean what i draw in below chart:

1) Insert 4 children.
0           1          2          3
+----------------------------------------------------
|children.0|children.1|children.2|children.3|
+----------------------------------------------------

2) Remove the 2th child (s->children[1])

{ "execute": "x-blockdev-change", 


  "arguments": { "parent": "xxx", 


                 "child": "children.1" } }

0           1          2          3
+----------------------------------------------------
|children.0|children.1|children.2|children.3|
+------------------------+------------+--------------
                         |            |         
                  +------+   +--------+
0           1     |    2     |
+----------------v----------v------------------------
|children.0|children.1|children.2|
+----------------------------------------------------

Remove children.1 and shorten the array, then rename children.{2,3} to 
children.{1.2}

3) Insert a new child

0           1          2         3
+----------------------------------------------------
|children.0|children.1|children.2|children.3|
+----------------------------------------------------

But as Wen said: 
http://lists.nongnu.org/archive/html/qemu-devel/2016-04/msg00898.html

Everytime we try to remove a children.i (i < n-1, so it's not the last 
element of the array[n]), we have to rename children.{i+1, n-1} to 
children.{i, n-2}.

Thanks
        -Xie

> > I also have another (not directly related) question: why not simply use
> > the node name when removing children? I understood that the idea was
> > that it's possible to have the same node attached twice to the same
> > Quorum, but can you actually do that? And what's the use case?
>
> What I like about using the child role name is that it automatically
> prevents you from specifying a node that is not a child of the given parent.
>
> Which makes me notice that it might be a good idea to require the user
> to specify the child's role when adding a new child. In this version of
> this series (where only quorum is supported), the children are just
> inserted in numerical order (first free slot is taken first), but maybe
> the user wants to insert them in a different order.
>
> For quorum, this is basically irrelevant if the order doesn't mean
> anything (which I don't like), but it may be relevant for other block
> drivers.
>
> And the "filling up quorum's children" topic then makes me notice that
> (x-)blockdev-change should probably be transaction-able (so you can
> restructure the whole BDS graph in a single transaction), but that's
> something we can care about later on.
>
> Max