rgw: during GC defer, prevent new GC enqueue #38228
Merged
Conversation
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
With the new queue-based GC code, when a GC defer operation is performed, it adds an "urgent" record to prevent GC from removing objects that are still being read. It does not check whether the objects are on the GC queue or not and that's OK for the urgent record. The code *also* adds a new GC entry to the queue to cause GC to occur at a later time. This would be incorrect if there was no GC entry to begin with, however. In such a case this would cause GC to delete tail objects when no user-initiated remove has happend. In other words a READ could cause a DELETE of tail objects and therefore data loss. This fix prevents such a new GC entry from being enqueued, thus preventing the data loss in this rare case. There is a new risk that tail object orphans to be created, but as an immediate fix to prevent data loss, this is appropriate and it is a rare event. A follow-on PR that will handle these cases is likely. This PR adds a level 0 log entry as a way to potentially confirm this case is being triggered in real-world cases. In time, this log entry should be deleted. Signed-off-by: J. Eric Ivancich <ivancich@redhat.com>
ivancich
added
needs-qa
needs-test
wip-eric-testing-1
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With the new queue-based GC code, when a GC defer operation is
performed, it adds an "urgent" record to prevent GC from removing
objects that are still being read. It does not check whether the
objects are on the GC queue or not and that's OK for the urgent
record.
The code also adds a new GC entry to the queue to cause GC to occur
at a later time. This would be incorrect if there was no GC entry to
begin with, however. In such a case this would cause GC to delete tail
objects when no user-initiated remove has happend. In other words a
READ could cause a DELETE of tail objects and therefore data loss.
This fix prevents such a new GC entry from being enqueued, thus
preventing the data loss in this rare case. There is a new risk that
tail object orphans to be created, but as an immediate fix to prevent
data loss, this is appropriate and it is a rare event. A follow-on PR
that will handle these cases is likely.
This PR adds a level 0 log entry as a way to potentially confirm this
case is being triggered in real-world cases. In time, this log entry
should be deleted.
Signed-off-by: J. Eric Ivancich ivancich@redhat.com
Fixes: https://tracker.ceph.com/issues/47866