-
Notifications
You must be signed in to change notification settings - Fork 6.3k
osd/scrub: partial implementation of scrub reserver #55131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
1c1d095 to
1b3875c
Compare
athanatos
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
src/osd/scrubber/scrub_machine.h
Outdated
| * - 'cancel' from the primary. We clear our reservation state, and transition | ||
| * back to ReplicaUnreserved. | ||
| * - a chunk request: best response is debateable. For now - we treat that | ||
| * as a cancellation followed by the chunk request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should handle the chunk response without affecting the reservation machinery at all. It should be impossible, but it's not a problematic state for the replica so I don't think it's worth adding special code for. It might be worth logging so that teuthology can fail the test, though.
src/osd/scrubber/scrub_resources.h
Outdated
| * | ||
| * - a new reservation request for the same PG: which means we had missed the | ||
| * previous cancellation request. Possible reactions: asserting, or simply | ||
| * removing the previous request from the queue; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should cancel the previous one and start the new one. It should also log so that teuthology can fail the test since this should be impossible.
1b3875c to
95f8323
Compare
778d173 to
e93f680
Compare
This comment was marked as resolved.
This comment was marked as resolved.
e93f680 to
e5410e9
Compare
This comment was marked as resolved.
This comment was marked as resolved.
e5410e9 to
ee4fef3
Compare
2b663d8 to
8311289
Compare
To be used when handling replica reservation requests from "old" primaries, that expect an immediate grant/deny reply. Signed-off-by: Ronen Friedman <rfriedma@redhat.com>
Up-to-date primaries will set this flag when sending a reservation request. The replica OSD, if too busy to handle the request immediately, will queue it until such time that the number of concurrent reservations is below the configured limit. The queued requests are honored in FIFO order. Old primaries will not set this flag, and will receive the expected grant or deny reply immediately. Signed-off-by: Ronen Friedman <rfriedma@redhat.com>
The scrub async reserver is not yet used. All requests are treated as 'legacy' requests, i.e. requests that expect an immediate grant/deny reply. Signed-off-by: Ronen Friedman <rfriedma@redhat.com>
8311289 to
5970ff6
Compare
|
jenkins retest this please |
|
jenkins test api |
|
jenkins test make check |
|
Merging based on multiple Teuthology runs |
This is a partial implementation of a change in the way scrub resource reservation
requests (sent by a primary to its replicas) are handled. In the complete implementation,
scrub reservation requests are no longer granted or refused immediately, but rather are queued in an
asynch reserver (similar to the way backfill reservations are handled).
In this partial implementation - all requests are treated as 'legacy', i.e. - the reserver
is never actually used. But the scrubber state-machine is already modified to handle
asynch requests.