-
Notifications
You must be signed in to change notification settings - Fork 286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
blockstore - separate write and prune batches. #688
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Pull Request Test Coverage Report for Build 1813298077
💛 - Coveralls |
Pull Request Test Coverage Report for Build 1812837669
💛 - Coveralls |
pinheadmz
reviewed
Feb 8, 2022
5e45750
to
9cded82
Compare
ChainDB and BlockStore are separate and committing to them is not really atomic, so we need to make sure the order operations can handle failure at any step. Previously blockstore writes and prunes would happen after the chaindb was written, but that could lead to the situation where the blockstore did not actually have a block but chaindb had the information. This PR separates write and prune batches for the blockstore, so we can try writing to blockstore first. In case writing to blockstore fails whole operation will get aborted. Nothing gets written into the chaindb, so the information is consistent. In case blockstore writes a block and then chaindb write fails, we just get extra data in the blockstore. But most of the time, the same block write will happen again (either main or alt chains). Pruning always happens after the chaindb was updated to avoid situation, where chaindb thinks the data is stored, but blockstore has removed it. If blockstore fails to prune after chaindb removed the information, worst case scenario (prune mode) we get a maxFileLength(128 MB by default) space wasted.
pinheadmz
reviewed
Feb 8, 2022
86df238
to
6e62968
Compare
Thanks for the fast work on this, LGTM now after a few nits. Makes sense to split up write/prune and execute them before/after the levelDB index as you've done. I wonder if this is the kind of thing we should add to a patch version and release, maybe Bob Wallet should do the same. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
blockstore
part of the codebase
bug
general - Something isn't working
intermediate
review difficulty - intermediate
patch
Release version
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ChainDB and BlockStore are separate and committing to them is not really atomic,
so we need to make sure the order operations can handle failure at any step.
Previously blockstore writes and prunes would happen after the chaindb was
written, but that could lead to the situation where the blockstore did not
actually have a block but chaindb had the information.
This PR separates write and prune batches for the blockstore, so we can try
writing to blockstore first. In case writing to blockstore fails whole operation
will get aborted. Nothing gets written into the chaindb, so the information is
consistent. In case blockstore writes a block and then chaindb write fails,
we just get extra data in the blockstore. But most of the time, the same block
write will happen again (either main or alt chains).
Pruning always happens after the chaindb was updated to avoid situation, where
chaindb thinks the data is stored, but blockstore has removed it. If blockstore
fails to prune after chaindb removed the information, worst case scenario
(prune mode) we get a maxFileLength(128 MB by default) space wasted.
Issue found here: kyokan/bob-wallet#453