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

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4623 bytes --]

On 11.04.2016 07:18, Changlong Xie wrote:
> 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|
> +----------------------------------------------------

No, what I meant, is:

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

|
v

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

I.e., children.1 simply ceases to exist.

Max

> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]