Topic: Bitcoin core : Rolling Forward very slow (Read 188 times)

Facing this issue of "Rolling forward.." since a restart of my system. NOT ON WINDOWS!!
Very painful. I just calculated and at the current speed,  it is going to take me 80+ hours just to catch up provided no new blocks are found on the network I have been kicked back to 14th May 2024, not sure how because I had restarted my system many times after that. What sucks is that this time I did run 'bitcoin-cli stop' and forgot about that terminal expecting it to complete the process, but it didn't.

It is really sad that BTCD has still not fixed this issue.

I had my own issues recently, but it's not unexpected since I had my data on an external HDD.
I ended up re-downloading everything and, with an old trick it went fast and painlessly (although on Windows, heh) :
I've moved to my (rather small) SSD 3 folders (block\index, chainstate, indexes\txindex) and creaded symbolic links to them.

Let me guess... is the OP using Windows? I gave up on running node on Windows, it causes problems, it's preferable to run Bitcoin Core on a Linux distro (I use Ubuntu), OP can create a partition to use as a dualboot with Windows, without having to delete Windows.

On Windows, especially if you have a desktop and the power shut down suddenly while the node is running, it's rare that there are no problems and you have to reindex or re-download all the blocks.

This happens when restarting when  the database flush was interrupted by an unexpected shutdown. It has to start with what was in the database, and re-apply all of the state changes represented by the blocks on disk. This is a very disk I/O intensive process, so if your disk is slow, it will take a while. It looks like you are using an external disk, so there may be a slowdown caused by USB and/or the physical connection itself.

Considering that it is doing a subset of the things done during block download, it seems likely that if you tried to redownload the blockchain, it would take just as long to download it. It's also not possible to download from a specific block height unless you delete some of the block files, but that would also trigger a reindex.

Hello, I was synchronizing a node with bitcoin core but bitcoin core has "core dumped" (between block 750,000 and 800,000 so I really don't want to have to download everything) and when restarting bitcoin- qt shows me "replaying blocks: 0%" and in debug.logs I have:

2024-04-27T00:30:15Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=58, size=100189578, heights=803877...804359, time=2023-08-19...2023-08-22)
2024-04-27T00:30:15Z Checking all blk files are present...
2024-04-27T00:30:15Z Initializing chainstate Chainstate [ibd] @ height -1 (null)
2024-04-27T00:30:15Z Opening LevelDB in /media/myname/DD Externe/chainstate
2024-04-27T00:30:17Z Opened LevelDB successfully
2024-04-27T00:30:17Z Using obfuscation key for /media/myname/DD Externe/chainstate: 5f4cbf4f04be336c
2024-04-27T00:30:17Z Replaying blocks
2024-04-27T00:30:17Z Rolling forward 00000000000000000003448732b35cd9bb92eff0328bfc3e1800cd95d23721b8 (788897)
2024-04-27T00:31:59Z Rolling forward 000000000000000000001bff2639e28de97f48ec1497fda22bcfcf44ce196bede (788898)
2024-04-27T00:33:02Z Rolling forward 0000000000000000000560890080e8dc8c30196783035ff4adb1ab5dd979f8ee (788899)
2024-04-27T00:33:41Z Rolling forward 00000000000000000001e2993abf7288aed1671a3c5f6e3ecd09347aacd16595 (788900)
2024-04-27T00:37:03Z Rolling forward 00000000000000000002731186762fba5cde45adc550f0308c9790f9d768dcad (788901)
2024-04-27T00:39:35Z Rolling forward 00000000000000000001e9818fd9be9145fd07bd60f44dc8d13fd466cb27c103 (788902)
2024-04-27T00:41:25Z Rolling forward 000000000000000000026ea74cd2b8fadebf4d5d4ee65186902490455d7bf706 (788903)
2024-04-27T00:42:23Z Rolling forward 0000000000000000000207548eddccce21d03c9787ade227c8a448d61136e195 (788904)
2024-04-27T00:44:15Z Rolling forward 00000000000000000003e92043d36b45494d987aa6fb385e8c8dbb0e8230f177 (788905)
2024-04-27T00:45:24Z Rolling forward 0000000000000000000023f3a017220f051a884fea43464a1cb18d5bda687c2e1 (788906)
2024-04-27T00:46:25Z Rolling forward 00000000000000000003f69bd245bc16fefd07fd50258963da39bcb19b885cae (788907)
2024-04-27T00:47:47Z Rolling forward 00000000000000000003ee8da7e286f4e7d28164b4d6e86620b64dcba186cc68 (788908)
2024-04-27T00:48:55Z Rolling forward 00000000000000000003be44f3fd8a38e93fe75a9809b1e7d198ac4532642e9f (788909)
2024-04-27T00:49:37Z Rolling forward 0000000000000000000418be070a760599d0bd4622409aa9f3c90d6351edab9f (788910)
2024-04-27T00:50:02Z Rolling forward 0000000000000000000005e50b30f6f8cca43caefd662070bda4c04ac39c5a794 (788911)
2024-04-27T00:50:14Z Rolling forward 00000000000000000005a6c463bbd5731479466691ff59bed40442f5142a8037 (788912)
2024-04-27T00:50:50Z Rolling forward 00000000000000000005ba649f99cf5d3c92f6853c091e667810fc1137eaf2e4 (788913)
2024-04-27T00:51:11Z Rolling forward 000000000000000000016a58e2418c5f64530636a223d4ad49fdea005783af8b (788914)
2024-04-27T00:51:49Z Rolling forward 0000000000000000000322eed119fddb71c66bdf379d3a75182769afd3a8ca01 (788915)
2024-04-27T00:52:24Z Rolling forward 0000000000000000000445f79006668cdc199dee1baf61224c5b2d85f2b88ceb (788916)
2024-04-27T00:52:53Z Rolling forward 00000000000000000002db386cd6493e47781c4c3bd61095b43e720e79610037 (788917)

As you see bitcoin core seems to check for corrupted blocks (or something like that), but one thing worries me: it's this line 2024-04-27T00:30:15Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks =58, size=100189578, heights=803877...804359, time=2023-08-19...2023-08-22)

from what I see if bitcoin core wants to "roll forward" to block 804359, with a speed of 2 blocks per minute it would take me 6 days, it is much faster to redownload the blockchain from block 788897, this is is it possible?

NB : I run on bitcoin core 27