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

[Kevin Wolf]

Am 01.10.2019 um 18:07 hat John Snow geschrieben:
> >> So the real back-resolution mechanism is:
> 
> Amendment:
>    - If our local node-name N is well-formed, use this.
>    - Otherwise:
> >> - Find the first non-filter ancestor, A
> >> - if A is not a block-backend, we must use our node-local name.
>      Amendment: If it's not a BB, we have no addressable name
>                 for the bitmap and this is an error.
> >> - if A's name is empty, we must use our node-local name.
>      Amendment: If it's empty, we have no addressable name
>                 for the bitmap and this is an error.
> >> - 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!
>      (Handled by above amendments.)
> 
> The reason for the change is to prefer user-defined node names whenever
> possible; only trying to find a "device" or "backend" name whenever we
> fail to find one.

I think we also need to clarify what "find the first non-filter" means:
"first" means not skipping over non-filters, but there can still be
multiple parents, and we can take the name of any of them.

In legacy setups, we can expect that there is only one BB that has a
defined name (i.e. nodes aren't reused in multiple subtrees) whereas the
other BBs may come from things like block jobs. We must not give up and
error out when the job BB is returned first.

Kevin