Add unverified checkpoint marker #583
Conversation
| pub(crate) enum CheckpointForResettingTip { | ||
| Verified(CheckpointLayout<ReadOnly>), | ||
| Verifying(CheckpointLayout<InVerification>), | ||
| } | ||
|
|
There was a problem hiding this comment.
After discussing with @schneiderstefan , we think we introduce too much work in distinguishing verified and unverified checkpoints by the type systems while not gaining comparable benefit.
Although the LoadingPolicy trait and the generic type in load_checkpoint handle loading neatly. Here is a example that we have to handle it in a complicated way.
When reseting tip to checkpoint, the checkpoint is verified with LSMT and unverified without LSMT due to the different workflows. There is no simple work round for the type check and we have to define an enum for both cases although LSMT is already fully rolled out.
The main benefit distinguishing verified and unverified checkpoints is that we don't accidentally use checkpoint with markers in the scenario where verified checkpoints are required. This can be achieved by having two different methods, checkpoint_verified and checkpoint_in_verification for getting CheckpointLayout. checkpoint_verified checks if the marker file is removed and returns an error if not.
In addition, the functionality of adding the marker is limited to readonly CheckpointLayout. Trying to remove the marker from a verified checkpoint is a no-op.
The functionality of adding the marker is limited to CheckpointLayout with WritePolicy. This prevents polluting the verified ones.
I suggest we hold the InVerification type for CheckpointLayout and merge the two methods first (see the new PR #657). After we cleanup the non-LSMT code and have more async checkpointing code, we can revisit if the InVerification type.
No description provided.