peterxcli commented on code in PR #11140:
URL: https://github.com/apache/ozone/pull/11140#discussion_r3879638991
##########
hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/request/key/OMKeyPurgeRequest.java:
##########
@@ -160,13 +171,49 @@ public OMClientResponse
validateAndUpdateCache(OzoneManager ozoneManager, Execut
AUDIT.logWriteSuccess(ozoneManager.buildAuditMessageForSuccess(OMSystemAction.KEY_DELETION,
auditParams));
}
return new OMKeyPurgeResponse(omResponse.build(), keysToBePurgedList,
renamedKeysToBePurged, fromSnapshotInfo,
- keysToUpdateList, bucketInfoList);
+ keysToUpdateList, bucketInfoList, updatedSharerCounts);
} catch (IOException e) {
AUDIT.logWriteFailure(ozoneManager.buildAuditMessageForFailure(OMSystemAction.KEY_DELETION,
null, e));
return new OMKeyPurgeResponse(createErrorOMResponse(omResponse, e));
}
}
+ /**
+ * Drops the sharer count of each block group whose sharers were reclaimed in
+ * this batch, and returns the new counts for the response to persist. A
count
+ * that falls to one is removed instead: the single key left owns the blocks
+ * again, so its own deletion releases them through the ordinary path.
+ *
+ * @return new count per block group id, where a value of one or less means
+ * the row should be deleted.
+ */
+ private Map<Long, Long> applySharedBlockGroupDecrements(
+ List<SharedBlockGroupDecrement> decrements, OMMetadataManager
omMetadataManager, long trxnLogIndex)
+ throws IOException {
+ if (decrements.isEmpty()) {
+ return Collections.emptyMap();
+ }
+ Map<Long, Long> updatedCounts = new HashMap<>();
+ for (SharedBlockGroupDecrement decrement : decrements) {
+ long groupId = decrement.getSharedBlockGroupId();
+ Long currentCount =
omMetadataManager.getSharedBlockGroupTable().get(groupId);
+ if (currentCount == null) {
+ // Already removed by an earlier batch; nothing left to count down.
+ continue;
+ }
+ long newCount = currentCount - decrement.getSharerCount();
+ updatedCounts.put(groupId, newCount);
+ if (newCount > 1) {
+ omMetadataManager.getSharedBlockGroupTable().addCacheEntry(
+ new CacheKey<>(groupId), CacheValue.get(trxnLogIndex, newCount));
+ } else {
+ omMetadataManager.getSharedBlockGroupTable().addCacheEntry(
+ new CacheKey<>(groupId), CacheValue.get(trxnLogIndex));
+ }
Review Comment:
Good catch, fixed in b2cc9a40c0.
This was a real hole in the invariant the rest of the design is built on. A
negative `newCount` fell into the `<= 1` branch and deleted the row, which
drops the protection for a group that may still have live sharers, so the next
deletion would release blocks another key is using. That is data loss, and it
is precisely the direction this design is supposed to make impossible.
The guard now skips the decrement and logs an error when `newCount` would go
below zero, keeping the row. A stale row costs a leak that an audit can
reclaim, which is the failure direction we want.
One clarification on the boundary: `newCount == 0` is legitimate and still
deletes the row. When every sharer of a group is reclaimed in the same batch,
`planSharedBlockGroups` withholds all but one member and emits a decrement
equal to the number of members, so the count lands exactly on zero while that
one member releases the blocks to SCM. Only a strictly negative result means
the count and the tagged keys disagree.
##########
hadoop-hdds/docs/content/design/ratis-backed-streaming-readblock.md:
##########
@@ -0,0 +1,894 @@
+---
+title: Ratis-Backed Streaming ReadBlock
+summary: Design for group-aware and closed-replica ReadBlock over Ratis
DataStream
+date: 2026-07-11
+status: draft
+author: Lixucheng
+---
Review Comment:
You are right, and both files are removed in b2cc9a40c0.
They were unrelated work in progress that lived untracked in the working
tree and got swept into the first commit by an overly broad `git add`. Nothing
in this PR referenced them. The only design doc the change set adds now is
`server-side-copy-key.md`, which documents this feature.
--
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]
