Enable paranoid corruption checks in LevelDB >= 1.16 #4177

1. 
   sipa commented at 10:51 am on May 12, 2014: member

   It should be tested how well this responds to various types of corruption, but I’m submitting it as a pull request to give exposure.
2. Enable paranoid corruption checks in LevelDB >= 1.16 cd01a5e185
3. laanwj added the label UTXO Db and Indexes on May 13, 2014
4. laanwj added the label Improvement on May 13, 2014
5. 
   laanwj commented at 1:06 pm on May 19, 2014: member

   Paranoid is good.

   Maybe add it as an option first for now before we enable it in general? What is the biggest risk here, to have false positives with regard to corruption?

6. 
   sipa commented at 9:24 pm on May 21, 2014: member

   Basically, yes. The fix in 1.16 is a case of something that LevelDB would consider corruption in paranoid mode, but is both hard to avoid (machines do crash…) and harmless (logfiles are append-only anyway). Perhaps there are other cases like these.

   On the other hand, I prefer detecting corruption as early as possible…

7. 
   BitcoinPullTester commented at 8:01 am on June 23, 2014: none

   Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p4177_cd01a5e18507c09eb6bbf159418e29c28fd3cadb/ for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
8. 
   laanwj commented at 1:42 pm on July 11, 2014: member

   I’ve tested this for almost a month on some nodes. No spurious corruption errors. ACK.
9. 
   sipa commented at 1:46 pm on July 11, 2014: member

   On a non-broken system I don’t expect this to ever trigger.

   It’s more in cases with crashing nodes/hardware, …

10. 
    laanwj commented at 2:00 pm on July 11, 2014: member

    Yes, but if there is actual corruption it should trigger. So making it more sensitive here can only be better, or not?
11. 
    sipa commented at 2:05 pm on July 11, 2014: member

    Fair enough. I guess we’ll see if it actually causes problems for anyone.
12. 
    gmaxwell commented at 5:38 pm on July 12, 2014: contributor

    ACK. We can back this out before the next release if we decide we don’t like it… having it in master will help us find other issues.
13. sipa merged this on Jul 12, 2014
14. sipa closed this on Jul 12, 2014

    ---

15. sipa referenced this in commit 0f2f2b38d0 on Jul 12, 2014
16. sipa deleted the branch on Jul 12, 2014
17. DrahtBot locked this on Sep 8, 2021

Contributors
sipa laanwj BitcoinPullTester gmaxwell

Labels
Refactoring UTXO Db and Indexes