-
Notifications
You must be signed in to change notification settings - Fork 37.7k
Add reindex=auto flag to automatically reindex corrupt data #26674
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
This allows the reindex flag to be set to auto, which automatically starts a reindex if the chain state or block index are corrupt. This can be especially useful for Raspberry Pi based full nodes, which often experience power outages or similar issues which can corrupt data. It allows full node operators to make Bitcoin Core reindex automatically, without having to worry about removing the reindex flag again. (Which isn't much effort, but can be annoying to forget) In case this error message is printed, pretty much nothing else except a reindex can be done, so adding this feature would make user experience slightly better.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
Not an argument against this PR, but I feel that if you're running on a system where the chainstate is continuously corrupted, you should investigate what's causing that and/or switch to non-broken hardware. |
This was also mentioned in the original PR, but in my opinion, it helps especially for the Raspberry Pi users, who often don't have protections against power outages (Using software like runcitadel or Umbrel). So while checking the hardware should be necessary, this could help improve the user experience for users on such projects or users who are fine with the risk. |
Concept ~0
I agree.
Sounds like an option that might just be (ab)used by node in a box producers, (i.e on by default) to stop people complaining to them about hardware issues.
Users who are fine with these risks can also introduce their own solutions to this problem (i.e some system service/watchdog that doesn't need to be a part of Bitcoin Core). There are also non-software solutions to freuqent/sudden power outages, i.e a UPS. I don't think allowing users to blindly ignore known/recurring problems and continue on, is something we should be supporting. |
Yes, but implementing something like this would probably be a lot more complicated than just having this feature in Bitcoin Core (It would probably work by reading log messages, but if these change, the script would need to be changed, also, such a script would also need to check if the database still needs a reindex when Core restarts).
For some, it may be a one-time issue. And in my opinion, it could benefit node-in-a-box providers a lot. I wouldn't call that "abusing a feature". It definitely won't help with users having HW issues. As a former member of the Umbrel team, I know that on such software, HW issues caused a lot of other problems. A reindex was in almost every case only needed because of a power outage, which happens sometimes, but not often for most users. |
I think it would be more useful to refuse a reindex on two subsequent starts, see #22072 (comment) . It is common for users to set the flag, then start, wait for the reindex to finish and then forget about the flag. On the next restart they will see that their whole sync progress is thrown away without warning, forcing them to wait hours/days/weeks (depending on their hardware) for no reason. |
Where would you store such data? In a separate lock file? |
It might be sufficient to just shut down right after the reindex has started |
Do you mean after it finished? I was talking about how Core should know it reindexed on the previous start. I don't understand how a shutdown could help? |
It just seems better UX if the user can do both edits (adding and removing the flag) in the shortest time possible. Previous workflow:
Proposed workflow:
|
The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues. Closing due to lack of interest. Pull requests with improvements are always welcome. |
This allows the reindex flag to be set to auto, which automatically starts a reindex if the chain state or block index are corrupt. This can be especially useful for Raspberry Pi based full nodes, which often experience power outages or similar issues which can corrupt data.
It allows full node operators to make Bitcoin Core reindex automatically, without having to worry about removing the reindex flag again. (Which isn't much effort, but can be annoying to forget).
In case this error message is printed, pretty much nothing else except a reindex can be done, so adding this feature would make user experience slightly better.
Rebased version of #22072.