rbd: avoid GetTrashList in ensureImageCleanup by using ImageID - #6468
Closed
nixpanic wants to merge 1 commit into
Closed
rbd: avoid GetTrashList in ensureImageCleanup by using ImageID#6468nixpanic wants to merge 1 commit into
nixpanic wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR optimizes RBD image trash cleanup by avoiding librbd.GetTrashList() in the common path and instead removing trashed images directly by ImageID, which is typically available from the journal. It also adds a targeted fallback for the DeleteTempImage() retry scenario where ImageID might be missing because the image can no longer be opened by name.
Changes:
- Updated
ensureImageCleanup()to remove images from trash byImageIDand treat ENOENT as success for idempotency. - Added
findImageIDInTrash()to resolve anImageIDby name from the trash list for exceptional recovery paths. - Updated
DeleteTempImage()to use the fallback only whenDelete()fails withErrImageNotFoundandImageIDis absent.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
nixpanic
force-pushed
the
rbd/ImageID-vs-GetTrashList
branch
from
August 13, 2026 14:46
dc74388 to
5614e94
Compare
ensureImageCleanup() previously called librbd.GetTrashList() and matched the image by name to obtain its ID. Since ImageID is already populated from the journal at all call sites, use it directly and call trashRemoveImage() without the expensive list operation. ENOENT is treated as success for idempotency (image already cleaned up). The one path where ImageID may be absent is DeleteTempImage(): when Delete() fails with ErrImageNotFound because the temp-clone is already in trash (opened by name fails), ImageID is not set. A new helper findImageIDInTrash() performs the GetTrashList fallback only in that exceptional retry scenario and populates ImageID before calling ensureImageCleanup(). Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Niels de Vos <ndevos@ibm.com>
nixpanic
force-pushed
the
rbd/ImageID-vs-GetTrashList
branch
from
August 13, 2026 16:21
5614e94 to
e39ea3a
Compare
nixpanic
marked this pull request as draft
August 13, 2026 16:21
Member
Author
|
closed in favor of #6472 |
This file contains hidden or 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
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.
ensureImageCleanup() previously called librbd.GetTrashList() and
matched the image by name to obtain its ID. Since ImageID is already
populated from the journal at all call sites, use it directly and call
trashRemoveImage() without the expensive list operation. ENOENT is
treated as success for idempotency (image already cleaned up).
The one path where ImageID may be absent is DeleteTempImage(): when
Delete() fails with ErrImageNotFound because the temp-clone is already
in trash (opened by name fails), ImageID is not set. A new helper
findImageIDInTrash() performs the GetTrashList fallback only in that
exceptional retry scenario and populates ImageID before calling
ensureImageCleanup().