Quote from: achow101 on Today at 05:36:43 PM

Quote from: telcomsoft on Today at 05:34:57 AM

...and it's downloading the whole blockchain again Huh

Time-travel back to 2014.

Are you monitoring network traffic and sure that it is actually downloading the blockchain?

During a reindex, it will appear to be downloading the blockchain because it looks like it's syncing from genesis. But it isn't actually downloading anything, just loading blocks from disk and updating the chainstate.

reindex process finished, I am pretty sure, I found a specific note in the log file.
I am not really sure either it downloading blocks or just checking it, but definetly it move forward too slow, fraction of percents per day.

so, at the end of the day I decided to start from the very beginning

Quote from: achow101 on Today at 05:36:43 PM

Quote from: srgmnr on Today at 01:44:38 PM

it was a Raspberry pie. OS was on microSD card and blockchain data on the attached USB external HDD.

Are you sure that it is using the correct datadir? Also, external hard drives are known to occasionally have issues with Bitcoin Core. Usually something gets corrupted.

well, I am pretty sure with datadir, because debug.log created exactly in those dir, and I were observing debug.log....

external drive, well, in the article about building full node with raspberry nothing was told about potential problems. in the fact, this is only way to have a pretty big storage.

Quote from: achow101 on Today at 05:36:43 PM

Quote from: srgmnr on Today at 04:08:35 PM

it is wired
I thought that blk000XX.dat files are similar in each node, but it is not!

this is old one

$ ll blocks/blk00000.dat
-rw------- 1 srg srg 134214783 Apr 2 05:45 blocks/blk00000.dat
$ sha256sum blocks/blk00000.dat
a49e3196378bcd5fa59f53a7b568684fcdd4c626445deda127e5933122008765 blocks/blk00000.dat

and I restarted process from the scratch

$ ll blocks/blk00000.dat
-rw------- 1 srg srg 134215966 Apr 5 16:03 blocks/blk00000.dat
$ sha256sum blocks/blk00000.dat
2b41358fac62f7bf20a29dfa5761bbd39fa4f5e4ca8874cd15982abf1b7d0f42 blocks/blk00000.dat
any ideas why?

---
Sergey

That's expected. Blocks are downloaded out of order, but stored in the order downloaded. Different nodes will typically end up downloading blocks in different orders depending on their peers and internet connection.

oh, didn't know this fact, so thank you.

---
Sergey