-
Notifications
You must be signed in to change notification settings - Fork 38.7k
Always flush block and undo when switching to new file #6948
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
Conversation
|
@jonasschnelli @laanwj You may want to test this. |
Previously, the undo weren't being flushed during a reindex because fKnown was set to true in FindBlockPos. That is the correct behaviour for block files as they aren't being touched, but undo files are touched. This changes the behaviour to always flush when switching to a new file (even for block files, though that isn't really necessary).
|
I expect that this fixes the issue. #6923 seemed to be a case of a truncated undo file (there was a strangely-sized old undo file and a very small new one). Although I don't fully remember if it happened during Will test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So on a reindex this means undo files still won't be truncated I suppose?
|
utACK Would an alternative option be to at the end of the reindex loop, go through and flush all the undo files. It seems if you crash during a reindex, you don't care about the state of the undo files, its only if you were to crash after reindex before they were flushed that you would have a problem? Such alternative option would potentially have problems in the event of new blocks being written during reindex, but thats already a problem, see #6691. |
|
tested ACK |
|
Tested ACK. |
I don't understand your reasoning here. The point of this PR is to avoid corruption in the undo files when there is a crash during reindex. It can then pick up where it left off next time the application is launched. |
22e7807 Always flush block and undo when switching to new file (Pieter Wuille)
|
This change brought a new compiler warning: |
Previously, the undo weren't being flushed during a reindex because fKnown was set to true in FindBlockPos. That is the correct behaviour for block files as they aren't being touched, but undo files are touched. This changes the behaviour to always flush when switching to a new file (even for block files, though that isn't really necessary). Rebased-From: 22e7807 Github-Pull: #6948
Previously, the undo weren't being flushed during a reindex because fKnown was set to true in FindBlockPos. That is the correct behaviour for block files as they aren't being touched, but undo files are touched. This changes the behaviour to always flush when switching to a new file (even for block files, though that isn't really necessary). Rebased-From: 22e7807 Github-Pull: bitcoin#6948
ab4f184 Fixed integer comparison warning. (Eric Lombrozo) 189d8b7 Always flush block and undo when switching to new file (Pieter Wuille) Pull request description: Fixing a possible blocks db corruption cause. > Previously, the undo weren't being flushed during a reindex because fKnown was set to true in FindBlockPos. That is the correct behaviour for block files as they aren't being touched, but undo files are touched. > This changes the behavior to always flush when switching to a new file (even for block files, though that isn't really necessary). Coming from dashpay#6948. ACKs for top commit: random-zebra: utACK ab4f184 Fuzzbawls: ACK ab4f184 Tree-SHA512: c544861e74015afab3cb7162fd49f478e455f7a7b0bfa19c9e3c74ccccd343130dab770fe5a2ad88e017889fe075da999caa89bb06dc669d41d7ba573295cbea
Previously, the undo files weren't being flushed during a reindex because fKnown was set to true in FindBlockPos. That is the correct behaviour for block files as they aren't being touched, but undo files are
touched.
This changes the behaviour to always flush when switching to a new file (even for block files, though that isn't really necessary).
Intended to fix #6923.