Re: [Qemu-devel] [RFC for-2.7 1/1] block/qapi: Add query-block-node-tree

[Max Reitz <mreitz@redhat.com>]

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

On 28.03.2016 17:25, Eric Blake wrote:
> On 03/26/2016 10:33 AM, Max Reitz wrote:
> 
>>> We insert the new child to the head, not the tail...
>>
>> Well, the idea is that the order of children doesn't really matter; The
>> only thing that describes the behavior of a child is its role. For
>> instance, for qcow2 it doesn't matter whether the "file" or the
>> "backing" BDS is the first child.
>>
>> However, for quorum, the order might matter (e.g. in FIFO mode). But
>> then again, the order is clearly specified by the role again: The first
>> child is the one with the "children.0" role.
>>
>> So I don't think this is real problem as long as I add a note to the
>> documentation that the order of objects in the @children array is
>> undefined and does not have any significance.
> 
> What happens when we hot-add/-delete children from a FIFO mode quorum?

Good question. I'd have hoped it'd be children.1 (because that is then
the first child).

But it appears to be more or less a random child. It just always
iterates through the s->children array (from start to finish), but when
children.0 is deleted, that array is compacted so the first entry is
then indeed children.1; but when children.0 is added again, it will be
appended to the end of the array (and so you can bring that array into a
random order, basically).

However, I don't think that we should expose this array's order to the
outside because of this, but that it is a bug that should be addressed
in a new version of the hot-add/-delete series.

> Obviously, we can select which child to delete, so if we delete the
> child.0 node, do we have guaranteed semantics on which node takes over
> the role as the primary child?  Conversely, when adding a node, do we
> have a way to specify whether the new node must be at the front (assume
> the child.0 role) or back (must not affect the current FIFO roles)?

No, we don't. I'm not sure whether we need this, but in any case it's
something the hot-add/-delete series needs to address.

> I think order is important enough for FIFO mode that we ought to try and
> represent it explicitly in the command, rather than getting it backwards
> or stating it is undefined.

In my opinion, the way the order is explicitly represented is through
every child's role. For quorum, "children.${i}" comes before
"children.${i+1}".

The general block layer does not care about these generic children, it
only cares about "file" and "backing". Therefore, it cannot know the
order of the children (if there is any) and it in fact does not care. If
there is an order, we would thus need to get the block driver to define
it and I don't think that's trivial (the easiest way to do so probably
is to define a driver-supplied iterator function).

Note that any order of children would be driver-specific still, just as
generic children's role names are driver-specific. Therefore, if a user
knows how to interpret the order of children, they'd know how to derive
the order from the role name, too.

Also noteworthy is that it's completely fine to leave the order
undefined for now and implement functionality to sort the array at some
later point in time.

Max


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