A fun little firedrill this morning with Tejun hilighted that we still do reads under the parent lock during search. Thinking about this I'm not entirely sure we need it. We definitely need it for reada_for_search() because we look at the node, but when we do the actual blocking read for the extent buffer we already have all the info we need, we probably are fine just dropping the locks there and doing the read.
Potential problems are
What happens if the transaction commits in between? I think this doesn't matter, because this could happen currently, just because we have a lock on the EB doesn't mean it can't be reclaimed. I think it matters if the read takes long enough to span multiple transactions, but even then we wouldn't have COW'ed it without reading it, so I think this isn't an issue.
Stale generation information. Again this block shouldn't have changed, and we did actually lock the parent to get the blocknr and generation, so I think this is fine?
We'd have to test it a bunch, but I think it would be ok. But it'd require very thorough investigation.
A fun little firedrill this morning with Tejun hilighted that we still do reads under the parent lock during search. Thinking about this I'm not entirely sure we need it. We definitely need it for reada_for_search() because we look at the node, but when we do the actual blocking read for the extent buffer we already have all the info we need, we probably are fine just dropping the locks there and doing the read.
Potential problems are
We'd have to test it a bunch, but I think it would be ok. But it'd require very thorough investigation.