priyeshkaratha commented on PR #11307: URL: https://github.com/apache/ozone/pull/11307#issuecomment-6265007358
Thanks @smengcl. Agreed that another snapshot alone doesn't close the race. The check depends on ordering: 1. On the datanode, export and delete recording take the same container lock. A copy is therefore either exported after the deletion was recorded, so it carries the record and deletes the blocks itself, or exported before. A source ACKs only after it has recorded the deletion. 2. A copy exported before the deletion was scheduled before the ACK. So when commitTransactions runs, its ADD is either still pending, which defers the purge, or already completed. ContainerStateManager adds the replica and clears the pending ADD under the same container lock. Because we check the pending ADD before reading replicas, a completed ADD's replica is in the set we read. 3. An ADD scheduled after the check is safe, because its source has already recorded the deletion.The one case not covered is an ADD that expires while the copy is still importing. The datanode checks the deadline only before it starts, so SCM-side locking can't close this. Fixing it needs SCM to reconcile a late replica using the deleteTransactionId it reports. That touches the report handler and ReplicationManager, so I'd like to do it in [HDDS-17152](https://issues.apache.org/jira/browse/HDDS-17152). I've noted this case in the Javadoc. -- 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]
