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
signature.asc
Description: OpenPGP digital signature