Am 12.04.2018 um 13:30 hat Paolo Bonzini geschrieben:
> On 12/04/2018 13:11, Kevin Wolf wrote:
> >> Well, there is one gotcha: bdrv_ref protects against disappearance, but
> >> bdrv_ref/bdrv_unref are not thread-safe. Am I missing something else?
> > Apart from the above, if we do an extra bdrv_ref/unref we'd also have
> > to keep track of all the nodes that we've referenced so that we unref
> > the same nodes again, even if the graph has changes.
> > So essentially you'd be introducing a new list of BDSes that we have to
> > manage and then check for every reachable node whether it's already in
> > that list or not, and for every node in the list whether it's still
> > reachable.
> That would be a hash table (a set), not a list, so easy to check. But
> the thread-safety is a bigger issue.
> The problem I have is that there is a direction through which I/O flows
> (parent-to-child), so why can't draining follow that natural direction.
> Having to check for the parents' I/O, while draining the child, seems
> wrong. Perhaps we can't help it, but I cannot understand the reason.
I'm not sure what's there that could be not understood. You already
confirmed that we need to drain the parents, too, when we drain a node.
Drain really must propagate in the opposite direction of I/O, because
part of its job is to quiesce the origin of any I/O to the node that
should be drained. Opposite of I/O _is_ the natural direction for drain.
We also have subtree drains, but that's not because that's the natural
direction for drain, but just as a convenience function because some
operations (e.g. reopen) affect a whole subtree, so they need everything
in that subtree drained rather than just a single node.