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. Kevin