Re: bitmap migration bug with -drive while block mirror runs

[Vladimir Sementsov-Ogievskiy]

01.10.2019 17:10, John Snow wrote:
> 
> 
> On 10/1/19 10:00 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> Otherwise: I have a lot of cloudy ideas on how to solve this, but
>>> ultimately what we want is to be able to find the "addressable" name for
>>> the node the bitmap is attached to, which would be the name of the first
>>> ancestor node that isn't a filter. (OR, the name of the block-backend
>>> above that node.)
>> Not the name of ancestor node, it will break mapping: it must be name of the
>> node itself or name of parent (may be through several filters) block-backend
>>
> 
> Ah, you are right of course -- because block-backends are the only
> "nodes" for which we actually descend the graph and add the bitmap to
> its child.
> 
> So the real back-resolution mechanism is:
> 
> - Find the first non-filter ancestor, A
> - if A is not a block-backend, we must use our node-local name.
> - if A's name is empty, we must use our node-local name.
> - If the name we have chosen is not id_wellformed, we have no
> migration-stable addressable name for this bitmap and the migration must
> fail!
> 
> 
> For resolving bitmap addresses via QMP (node, name) pairs; the
> resolution method would be this:
> 
> - if the node-name N is a block-backend, descend the tree until we find
> the first non-filter node V.
> - if the node-name N is a BlockDriverState, use this node directly.
> 

Looks good for me.

I also think if on destination we have both block-backend with name N and
block-node with name N and the latter is not (filtered) child of the former,
we should fail migration of at least that bitmap. (Hope, nobody reuse
block-backend names as node-names in practice.. (should we restrict it
explicitly ?))

> 
> (I don't have the time to investigate the code snippet right now; my
> attention is being pulled to a different project. sorry!)
> 

So, you are not working on this? Then I'll make patches.

-- 
Best regards,
Vladimir