F64116045 commented on code in PR #11199:
URL: https://github.com/apache/ozone/pull/11199#discussion_r3953346953
##########
hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/fsck/ReconReplicationManager.java:
##########
@@ -313,8 +279,11 @@ public synchronized void processAll() {
// readOnly=true ensures no commands are generated
processContainer(container, replicas, pendingOps, nullQueue, report,
true);
- // ADDITIONAL CHECK: Detect REPLICA_MISMATCH (Recon-specific, not in
SCM)
- if (hasDataChecksumMismatch(replicas)) {
+ // Persist checksum mismatches in Recon's REPLICA_MISMATCH state.
+ if (container.getState() == CLOSED &&
+ container.getReplicationType() == RATIS &&
+ hasMismatch(replicas, ContainerReplica::getSequenceId,
Review Comment:
Thanks @devmadhuu for the review.
Recon currently checks container health using its own replica data; it does
not receive the mismatch state confirmed by SCM. So there are two ways to make
the behavior consistent:
- Run the same two-scan check in Recon. This is the smaller change, but SCM
and Recon may confirm at different times, and Recon must preserve the result
across restarts.
- Send SCM’s confirmed result to Recon. The current RPC handles one
container at a time, so this would likely require a batch RPC or persisted
state.
With the first option, different scan timing could still make SCM and Recon
temporarily disagree, so I’m not sure it fully addresses the consistency
concern.
The scope of the second option would be much larger because we would need a
batch API to pass confirmed mismatches and their removals from SCM to Recon. We
would also need to handle incomplete transfers so Recon does not mistake a
partial result for the complete state.
My preference is the first option. Recon already evaluates container health
independently, and its scan does not necessarily run at the same time as SCM’s,
so a short delay between their results is expected.
But I wonder which direction do you think is more appropriate here?
--
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]
