GeorgeJahad opened a new pull request, #4680: URL: https://github.com/apache/ozone/pull/4680
## What changes were proposed in this pull request? ### The BootstrapStateHandler This PR creates a new interface, BootstrapStateHandler. Each process that manages state that needs to be copied into the bootstrap tarball must implement this interface. The interface has a single method, getBoostrapStateLock(). The processes managing bootstrap state implement this method, which returns the lock used to protect state that must be changed atomically with respect to the tarball creation process. The tarball creation process takes each of these locks before generating the tarball. That prevents any of the processes from changing the state while the tarball is being created. Then the tarball creator waits for the double buffer to flush so that any remaining operations that may effect the bootstrap state have completed before the tarball is created. ### The state to protect/synchronize Outside of the active rocksdb itself, the omSnapshot subsystem uses many types of persistent state data. I've listed the types below along with an indication of whether they are guarded by a BootstrapStateHandler.Lock. If there is any type I've forgotten please let me know, so that we can account for it. #### delete/rename key entries The sdt, and eventually the kdt, move delete/rename key entries between snapshots. These are guarded by a BootstrapStateHandler.Lock, (and by waiting for the double buffer flush.) #### deleted sst files The rocksdb differ and sst filtering service delete sst files when no longer needed. These are guarded with by the BootstrapStateHandler.Lock. The reason for these need to be guarded is that the tarball creation process does a calculation of hard links prior to tarball creation. That calculation requires a stable set of sst files. If some get deleted during the process, the hard links calculated may be invalid. #### compaction logs These get created by the active rocksdb as sst files are compacted. These are not currently guarded by a BootstrapStateHandler.Lock. My reasoning for this is that it would require turning off compactions on the active rocksdb for the duration of the tarball creation. Before the tarball is created, the BootstrapStateHandler's are locked and a checkpoint of the active fs is taken. Any compactions that happen after that checkpoint is taken, but before the tarball is finished, will have compaction log entries add to the tarball, that don't correspond to the checkpoint. This may be a problem. If so, we'll have to pause compactions on the active fs long enough to make a copy of the compaction logs. So please include your thoughts when reviewing. #### intermediate rocksdb snapdiff files These are just used during the calculation of the snapdiff. They will not be a part of the tarball. They are not guarded by a BootstrapStateHandler.Lock. #### SST filter service history file This file keeps track of all the snapshots that have been filtered. It is guarded by a BootstrapStateHandler.Lock. ### Other changes in this PR #### Flush Snapshot WAL's after moving deleted keys When deleted keys are moved from one snapshot to another, the double buffer opens and writes to both the corresponding rocksdb images, in addition to the rocksdb for the active fs. I've modified that operation to flush the wal for the snapshot rocksdb images. (The active rocksdb doesn't need to be flushed because the tarball creator takes a rocksdb checkpoint of that image after the doublebuffer is flushed.) ### Moved some methods to the AbstractKeyDeletingService class The AbstractKeyDeletingService class is the parent class of both the SnapshotDeletingService and the KeyDeletingService. I moved the submitSnapshotMoveDeletedKeys() and submitRequest() methods from the SnapshotDeletingService class to the AbstractKeyDeletingService class. This is because thesnapshot delete design includes an optimization that has the KeyDeletingService also moving deleted keys. Since that operation needs to be protected by a BootstrapStateHandler.Lock, I moved that code in anticipation of when the optimization is implemented. ## What is the link to the Apache JIRA https://issues.apache.org/jira/browse/HDDS-8209 ## How was this patch tested? added unit tests I will add a test for the SnapshotDeletingService once this is merged: https://github.com/apache/ozone/pull/4571 ## TODO As mentioned above, we need to decide if the compaction logs need to be synchronized with the actvie fs checkpoint. -- 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]
