LevelDB read failure: Corruption: block checksum mismatch #10897

issue safocl openend this issue on July 21, 2017
  1. safocl commented at 5:57 pm on July 21, 2017: none

    bitcoin core 0.14.2 is official binary files

    start is: bitcoind -daemon -server -dbcache=3000 or bitcoind -daemon -server or bitcoin-qt

    Machine specs:

    • OS:archlinux
    • CPU:intel I3 2100
    • RAM:8GB
    • Disk size:2TB
    • Disk Type (HD/SDD):HD

    when trying to sync the blockchain every time appears the same error. https://ptpb.pw/5l4Y

    02017-07-21 17:11:20 UpdateTip: new best=00000000000000000f2224b90fba180dfdd3cb7f39c8f197af468e4803a590ba height=365179 version=0x00000003 log2_work=83.070267 tx=76119675 date='2015-07-13 20:05:19' progress=0.317846 cache=778.1MiB(542173tx)
    12017-07-21 17:11:20 LevelDB read failure: Corruption: block checksum mismatch
    22017-07-21 17:11:20 Corruption: block checksum mismatch
    32017-07-21 17:11:20 Error: Error reading from database, shutting down.
    42017-07-21 17:11:20 Error reading from database: Database corrupted
    

    this problem the computer began in 2016, up to this point normally synchronized

    on a laptop with the same configuration except hdd size 500GB processor i3 2350M, synchronization of the blockchain is successful. OS on laptop is the same archlinux with the same version of the packages.

  2. jonasschnelli commented at 8:37 am on July 24, 2017: contributor
    Do you really use a physical connected HDD (or a NAS or NFS/SMB device)? If you use an attached HDD and encounter this over and over, then I recommend to check your RAM and disk for corruptions. Bitcoin-Core is a great tool to identify hardware failures.
  3. jonasschnelli added the label Data corruption on Jul 24, 2017
  4. safocl commented at 9:57 pm on July 24, 2017: none
    S. M. A. R. T shows excellent results. FS is also not damaged. forgot to mention that the problem detected and Windows on this computer, which is installed on another hard disk partition. Tests of RAM previously, when this issue did not reveal any problems with her.
  5. TheBlueMatt commented at 6:50 pm on July 25, 2017: member
    You say “every time”, I assume that means you’ve hit the same issues multiple times? Have you tried a reindex as well? Have you tried using a different disk?
  6. safocl commented at 9:46 pm on July 25, 2017: none

    You say “every time”, I assume that means you’ve hit the same issues multiple times? Have you tried a reindex as well? Have you tried using a different disk?

    Yes, this error has plagued me in January 2016, the unit on which the error occurs is always the same. Re-indexing was done not once, but the results are the same. Hard drive change is not possible in the absence of the other.

  7. TheBlueMatt commented at 10:31 pm on July 25, 2017: member

    Does it always happen at the same/similar height?

    If not, I hate to say it, but I’m gonna bet this is silent disk corruption. You may wish to try again with a filesystem which does checksumming (btrfs, zfs, etc, though note performance drawbacks there).

  8. safocl commented at 2:35 am on July 26, 2017: none
    ran the hard drive tests and RAM, no errors found. At the expense of other file systems-so the problem is not only on ext4 on linux, but on windows on this computer, where the file system is ntfs.
  9. TheBlueMatt commented at 3:09 pm on July 26, 2017: member
    That sounds very much like silent drive corruption (or other hardware issues) to me - SMART tests are only capable of detecting certain types of issues.
  10. safocl commented at 11:57 pm on July 26, 2017: none
    but I ran the tests the file system for errors in it was not.
  11. laanwj commented at 11:42 am on July 27, 2017: member
    “block checksum mismatch” is a db level error, which happens if the CRC written with a block of data doesn’t match the data, on read. So either it didn’t get written properly, or it was randomly overwritten later. Many things can cause this on your system, including buggy drivers, overheating CPU/GPUs, and so on, not just a flaky HDD. It’s impossible to say with this information.
  12. safocl commented at 8:03 pm on July 27, 2017: none

    overheating of the processor and graphics card didn’t happen. monitored the process in real time.

    LTC is synchronized without problems.

    also excluded buggy drivers, as the laptop uses the same OS in which the same driver.

  13. gmaxwell commented at 1:00 am on August 1, 2017: contributor
    The failed checksum is more or less definitive, it seems that you are very dismissive of the possibility of hardware failure– but there are tens of thousands of other nodes that run without issue (including test nodes with very abusive operating conditions). The fact that LTC is synced isn’t much of an indicator, as LTC has thousands of times less load than Bitcoin.
  14. safocl commented at 7:20 am on August 1, 2017: none
    so the fact that if I downloaded the full someone’s blockchain, everything will work fine and continue to synchronize.
  15. safocl commented at 6:59 am on August 7, 2017: none

    put the other hard drive (the laptop on which everything runs fine), the effect is the same

    02017-08-07 01:47:33 UpdateTip: new best=000000000000000010a0711043ae24c0abf68370ae85909a5c23aaad758b28e5 height=342866 version=0x00000002 log2_work=82.203924 tx=59214793 date='2015-02-10 13:17:39' progress=0.242675 cache=286.6MiB(145886tx)
    12017-08-07 01:47:33 LevelDB read failure: Corruption: block checksum mismatch
    22017-08-07 01:47:33 Corruption: block checksum mismatch
    32017-08-07 01:47:34 Error: Error reading from database, shutting down.
    42017-08-07 01:47:34 Error reading from database: Database corrupted
    

    I do not understand what trubble maybe even, why is this a checksum error? DDR3 tested – passed all tests on hurrah, without errors. The processor can’t understand what’s can be?

    that’s the unit number is of course different, but still it is 2015, and it all started at the beginning of 2016. and constantly error in the blocks in 2015.

  16. gmaxwell commented at 9:05 am on August 20, 2017: contributor
    set assumevalid=0 and I bet it’ll fail somewhat earlier. I think it’s failing after it’s done enough signature validation to heat things up in your computer.
  17. fanquake closed this on Oct 7, 2017

  18. DrahtBot locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-09-29 01:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me