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

[Vladimir Sementsov-Ogievskiy]

01.10.2019 19:16, Kevin Wolf wrote:
> Am 01.10.2019 um 17:57 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 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 ?))
> 
> You can't have a node and a BlockBackend of the same name, they share a
> single namespace. If you try to do so, you get an error.
> 


Oh, thanks, that's cool.


-- 
Best regards,
Vladimir