From 9b84caf3a5f55cc2a14b50291118b9fab668b8c2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A9ter=20Szil=C3=A1gyi?= Date: Wed, 22 Mar 2017 02:37:24 +0200 Subject: core, eth, les: support resuming fast sync on heavy rollback (#3743) --- eth/sync.go | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'eth/sync.go') diff --git a/eth/sync.go b/eth/sync.go index 6e2c7c432..f2cae6c19 100644 --- a/eth/sync.go +++ b/eth/sync.go @@ -175,6 +175,14 @@ func (pm *ProtocolManager) synchronise(peer *peer) { // Otherwise try to sync with the downloader mode := downloader.FullSync if atomic.LoadUint32(&pm.fastSync) == 1 { + // Fast sync was explicitly requested, and explicitly granted + mode = downloader.FastSync + } else if currentBlock.NumberU64() == 0 && pm.blockchain.CurrentFastBlock().NumberU64() > 0 { + // The database seems empty as the current block is the genesis. Yet the fast + // block is ahead, so fast sync was enabled for this node at a certain point. + // The only scenario where this can happen is if the user manually (or via a + // bad block) rolled back a fast sync node below the sync point. In this case + // however it's safe to reenable fast sync. mode = downloader.FastSync } if err := pm.downloader.Synchronise(peer.id, pHead, pTd, mode); err != nil { -- cgit v1.2.3