-
Notifications
You must be signed in to change notification settings - Fork 5.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
osd/PG: make scan recovery op cancellation match up reliably
Previously, there was only one time we would end up in this region of code: when the backfill was rejected by the peer. Previously that was apparently reliably when we had an outstanding SCAN request, because we would unconditionally cancle the MAX recovery op and clear waiting_on_backfill. See 624aaf2 for when this code appeared. Now we have several similar paths, and we don't always have an outstanding scan call (I don't think!). Regardless, move most these three cases into a common helper and make the finish_recovery_op completion conditional on whether there is an outstanding SCAN. This fixes a leak of a recovery op when we defer while a scan is outstanding (this bug was recently introduced by e708410 and then duplicated by 2463c64). Note that there is still one other time we register MAX ops: when we are finishing backfill. There, we start one per target. But we will always get back our reply and process it in the normal way (that old commit did not change the timing for these). Signed-off-by: Sage Weil <sage@redhat.com>
- Loading branch information
Showing
2 changed files
with
18 additions
and
49 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters