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