From the other thread:
So you mean that backing_hd is modified as its parent is changed, do
I understand correctly?
Yes
As we started to discuss in a thread started with my "[PATCH] block:
bdrv_set_backing_hd(): use drained section", I think draining the whole
subtree when we modify some parent-child relation is too much. In-flight
requests in subtree don't touch these relations, so why to wait/stop
them? Imagine two disks A and B with same backing file C. If we want to
detach A from C, what is the reason to drain in-fligth read request of B
in C?
If I am not mistaken, bdrv_set_backing_hd adds a new node (yes removes
the old backing_hd, but let's not think about this for a moment).
So we have disk B with backing file C, and new disk A that wants to have
backing file C.
I think I understand what you mean, so in theory the operation would be
- create new child
- add child to A->children list
- add child to C->parents list
So in theory we need to
* drain A (without subtree), because it can't happen that child nodes of
A have in-flight requests that look at A status (children list),
right?
In other words, if A has another node X, can a request in X inspect
A->children
It should not happen. In my understanding, IO request never access
parents of the node.
* drain C, as parents can inspect C status (like B). Same assumption
here, C->children[x]->bs cannot have requests inspecting C->parents
list?
No, I think we should not drain C. IO requests don't inspect parents
list. And if some _other_ operations do inspect it, drain will not help,
as drain is only about IO requests.