Very Secure

Notes on how to speed up the trb resync process after data corruption

I was syncing my local trb node and I saw this error in my debug.log file:

NSt8ios_base7failureE

My most recent .dat file had been corrupted, from a cause unknown but most likely from my computer powering off during a write operation. I took some notes on how to avoid having to redownload all my hard earned blocks. The commands I've pasted below are specific to my case, but you can use them as an example.

I) Get asciilifeform's blkcut tool.

II) Remove your most recent blk000n.dat file, since it should be the file that is corrupted. Then cut up the remaining blk000*.dat files and organize the individual block files into a directory. How you do that second step is up to you. I moved all the blocks to ~/.bitcoin/cutblocks.

rm ~/.bitcoin/blk0003.dat # corrupted file.
cutblock ~/.bitcoin/blk0001.dat
cutblock ~/.bitcoin/blk0002.dat

mkdir ~/.bitcoin/cutblocks

for i in {0..9}
do
mv blk0001.dat.$i* ~/.bitcoin/cutblocks; mv blk0002.dat.$i* ~/.bitcoin/cutblocks;
done

III) Remove your old .dat files. I put them in a backup folder.

mkdir ~/bitcoin-data-backup
mv ~/.bitcoin/*.dat ~/bitcoin-data-backup

IV) Start bitcoind with the -caneat flag.

LC_ALL=C nohup ./bitcoind -caneat -myip=234.3.12.222 -addnode=108.31.170.3 -addnode=205.134.172.27 -verifyallll 2>&1 &

V) Now we need to run a script to eatblock on all our blocks. First find out how many blocks each old blkdata file had.

cutblock -c ~/bitcoin-data-backup/blk0001.dat

Then we load those blocks with a script to iterate through the eatblock commands. Run the following command replacing 188528 with the number you received from cutblock -c minus one1. If you have more than 1-3 blk000*.dat files, you'll want to create a more sophisticated script.

for i in {0..188528}; do echo "eating block $i"; ~/v/trb054/bitcoin/build/bitcoind eatblock ~/.bitcoin/cutblocks/blk0001.dat.$i.blk; done
  1. The first blk is blk0001.dat.0.blk []

2 Responses to “Notes on how to speed up the trb resync process after data corruption”

  1. Jacob Welsh says:

    > Remove your most recent blk000n.dat file, since it should be the file that is corrupted.

    That's unfortunate - if you'd kept it, we could test the hypothesis since a corrupt block would be gracefully rejected by eatblock.

  2. whaack says:

    Hm you're right, should have kept it. I won't be surprised if I have an opportunity to do this again in the future.

Leave a Reply