smengcl opened a new pull request, #11779: URL: https://github.com/apache/ozone/pull/11779
Generated-by: Claude Code (Opus 5.5) ## What changes were proposed in this pull request? In a bucket that has a snapshot, `snapshotRenamedTable` maps `/volume/bucket/objectID` to the name the object has in the latest snapshot, and only the first rename after the snapshot may write it. `OMKeyRenameResponse`, `OMKeysRenameResponse` and `OMKeyRenameResponseWithFSO` decide that on the double buffer flush thread: each reads the entry with `snapshotRenamedTable.get` and puts its source name only if the read returns null. Nothing adds cache entries to `snapshotRenamedTable`, so the read does not see a put that an earlier response added to the same batch. When two renames of one object are flushed in the same batch, the second also reads null and replaces the entry with the intermediate name, which the object never had in the snapshot. `KeyDeletingService` then looks the deleted key up in the snapshot under that name, finds nothing, and reclaims blocks the snapshot still holds. This change keeps the decision on the flush thread and adds one condition to all three responses: the committed DB must still hold the same object (same object ID) at the rename's source key. The check reads with `getSkipCache` from the key table, the file table or, for an FSO directory rename, the directory table (helper `OMKeyRenameResponse.isCommittedAt`). If an earlier rename of the object is in the same batch, the committed table does not hold it at the source, and the later rename leaves the entry that the first one wrote. The decision is not moved to apply time: snapshot create clears the bucket's `snapshotRenamedTable` range only when its own batch is flushed, so a rename applied between a snapshot create and that flush would read the stale entry and leave the object without one. There is no request, response or proto change. The cost is one extra point read per rename, only in a bucket that has a snapshot and only while the object has no entry. Entries already stored with a wrong name are not repaired. HDDS-17467 is a separate defect in the same table with an independent fix. ## What is the link to the Apache JIRA https://issues.apache.org/jira/browse/HDDS-17468 ## How was this patch tested? - New `TestOMKeyRenameResponse.testSecondRenameKeepsSnapshotName` (also run through `TestOMKeyRenameResponseWithFSO`): two rename responses for one key in a snapshotted bucket, in one batch and, as a control, with a commit between them. Without the change the one batch case fails. - New `TestOMKeysRenameResponse.testSecondRenameInSameBatchKeepsSnapshotName` and `TestOMKeyRenameResponseWithFSO.testSecondDirectoryRenameInSameBatchKeepsSnapshotName`: the same for `OMKeysRenameResponse` and for a directory rename. Both fail without the change. - New `TestOMKeyRenameResponse.testRenameOfObjectNotCommittedAtSourceRecordsNothing` (also run through `TestOMKeyRenameResponseWithFSO`): when the committed source name holds a different object, no entry is written. Without the change an entry is written. - `TestOMKeyRenameResponse`, `TestOMKeyRenameResponseWithFSO`, `TestOMKeysRenameResponse`, the rename request suites and the `TestReclaimable*Filter` suites (523 tests) pass locally on master; checkstyle is clean. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
