Geth Fast Sync imports blocks that have already been synced

Question

I keep having this problem where geth fast syncs normally importing headers and receipts (not blocks) up until a certain point at which it starts importing blocks that I had already synced a long time ago.

An example of the output is as follows (the most recent time this happened):

I0524 14:22:07.798880 core/headerchain.go:294] imported 192 header(s) (0 ignored) in 2.469281116s. #660378 [2073f529… / 3a505033…]
I0524 14:22:08.209943 core/blockchain.go:751] imported 6 receipt(s) (0 ignored) in 21.040595ms. #660192 [2073f529… / 454b2b4f…]
I0524 14:22:16.408611 eth/downloader/downloader.go:1130] Rolled back 2048 headers (LH: 660378->658330, FB: 660192->658330, LB: 0->0)
I0524 14:22:17.484047 core/blockchain.go:751] imported 103 receipt(s) (0 ignored) in 512.848247ms. #660295 [07662877… / 02d566a8…]
I0524 14:22:17.922178 core/blockchain.go:751] imported 83 receipt(s) (0 ignored) in 372.939255ms. #660378 [779d2a58… / 3a505033…]
I0524 14:22:34.658717 core/headerchain.go:294] imported 0 header(s) (192 ignored) in 68.916111ms. #192 [88e96d45… / 723899e8…]
I0524 14:23:09.703319 core/blockchain.go:959] imported 2 block(s) (0 queued 0 ignored) including 0 txs in 34.853133777s. #2 [88e96d45 / b495a1d7]
I0524 14:23:09.793493 core/headerchain.go:294] imported 0 header(s) (192 ignored) in 84.786686ms. #384 [967642fd… / d3d5d5c1…]
I0524 14:23:14.549250 core/blockchain.go:959] imported 190 block(s) (0 queued 0 ignored) including 0 txs in 4.74805811s. #192 [3d612266 / 723899e8]
I0524 14:23:14.599539 core/headerchain.go:294] imported 0 header(s) (192 ignored) in 44.800954ms. #576 [bbb506ab… / 41a7466b…]
I0524 14:23:19.567974 core/blockchain.go:959] imported 192 block(s) (0 queued 0 ignored) including 0 txs in 4.949800668s. #384 [967642fd / d3d5d5c1]
I0524 14:23:19.665313 core/headerchain.go:294] imported 0 header(s) (192 ignored) in 78.182567ms. #768 [c4cee3bf… / 5cfe57c2…]

It goes on (somewhat later) to sync only the blocks.

This has been really frustrating in trying to catch up (in this latest instance it went from block #660378 to #192; other times have been comparable to this and sometimes it has happened when I was even further along), and I could really use any help on how to go about fixing this.

Feel free to ask me any questions that might help you diagnose and hopefully fix this issue.

Answer 1

I've seen this "looping" behavior in the past and I would suggest deleting the chaindata and then running geth --fast --cache=1024.

The default datadir is:

Mac: ~/Library/Ethereum
Linux: ~/.ethereum
Windows: %APPDATA%/Ethereum

Delete the chaindata subdirectory that you find.

Answer 2

This is not an answer to your question, but I would like to encourage client diversity and you could try out the parity client in fast pruning mode which is considered very stable:

$ parity --pruning fast

http://parity.io - Maybe this could be an alternative for you to consider.