smengcl commented on PR #4680: URL: https://github.com/apache/ozone/pull/4680#issuecomment-1553530240
> They do call locks internally. Do you think that is insufficient? Ah that is good enough. Thanks. They count as `rocksDbCheckpointDiffer` in the `Lock` I presume: https://github.com/apache/ozone/blob/08cb5208b95abbccfada0d16bbe65a0451d8a88b/hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/OMDBCheckpointServlet.java#L304-L309 > I don't think the new sst files are a serious problem. The question is are the new compaction log entries a problem. That is what I need help determining. If they are not a problem, then we don't need to pause compactions. I agree with sufficient handling in DAG traversal (e.g. when used in SnapDiff) this should not be a big problem. cc @hemantk-12 I think alternative approach to `pauseBackgroundWork()` that could also keep compaction log consistent could be that we ask bootstrapping followers to ignore any newer compaction log entries than the **checkpointed** active DB's [sequence number](https://github.com/apache/ozone/blob/08cb5208b95abbccfada0d16bbe65a0451d8a88b/hadoop-hdds/rocksdb-checkpoint-differ/src/main/java/org/apache/ozone/rocksdiff/RocksDBCheckpointDiffer.java#L594-L595), because any compactions happened after that sequence number, even persisted to compaction log right during tarball creation, would be irrelevant to the active DB checkpoint. What do you think? -- 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]
