2015-07-07 02:54:22 +02:00
// Copyright 2015 The go-ethereum Authors
2015-07-22 18:48:40 +02:00
// This file is part of the go-ethereum library.
2015-07-07 02:54:22 +02:00
//
2015-07-23 18:35:11 +02:00
// The go-ethereum library is free software: you can redistribute it and/or modify
2015-07-07 02:54:22 +02:00
// it under the terms of the GNU Lesser General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
2015-07-22 18:48:40 +02:00
// The go-ethereum library is distributed in the hope that it will be useful,
2015-07-07 02:54:22 +02:00
// but WITHOUT ANY WARRANTY; without even the implied warranty of
2015-07-22 18:48:40 +02:00
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
2015-07-07 02:54:22 +02:00
// GNU Lesser General Public License for more details.
//
// You should have received a copy of the GNU Lesser General Public License
2015-07-22 18:48:40 +02:00
// along with the go-ethereum library. If not, see <http://www.gnu.org/licenses/>.
2015-07-07 02:54:22 +02:00
2015-06-16 11:58:32 +03:00
// Package downloader contains the manual full chain synchronisation.
2015-04-12 12:38:25 +02:00
package downloader
import (
2015-04-18 01:10:32 +02:00
"errors"
2015-10-13 12:04:25 +03:00
"fmt"
2015-07-29 13:20:54 +03:00
"math/big"
2015-04-12 12:38:25 +02:00
"sync"
"sync/atomic"
"time"
2019-05-15 14:33:33 +03:00
"github.com/ethereum/go-ethereum"
2015-04-12 12:38:25 +02:00
"github.com/ethereum/go-ethereum/common"
2018-05-07 14:35:06 +03:00
"github.com/ethereum/go-ethereum/core/rawdb"
2021-04-29 17:33:45 +03:00
"github.com/ethereum/go-ethereum/core/state/snapshot"
2015-04-12 12:38:25 +02:00
"github.com/ethereum/go-ethereum/core/types"
2020-12-14 11:27:15 +02:00
"github.com/ethereum/go-ethereum/eth/protocols/snap"
2015-10-05 19:37:56 +03:00
"github.com/ethereum/go-ethereum/ethdb"
2015-05-15 00:43:00 +02:00
"github.com/ethereum/go-ethereum/event"
2017-02-22 14:10:07 +02:00
"github.com/ethereum/go-ethereum/log"
2016-05-13 12:12:13 +02:00
"github.com/ethereum/go-ethereum/params"
2024-02-13 21:49:53 +08:00
"github.com/ethereum/go-ethereum/triedb"
2015-04-12 12:38:25 +02:00
)
2015-06-08 14:06:36 +03:00
var (
2024-03-15 14:37:47 +05:30
MaxBlockFetch = 128 // Number of blocks to be fetched per retrieval request
MaxHeaderFetch = 192 // Number of block headers to be fetched per retrieval request
MaxReceiptFetch = 256 // Number of transaction receipts to allow fetching per request
2015-09-28 19:27:31 +03:00
2024-04-30 06:46:53 -07:00
maxQueuedHeaders = 32 * 1024 // [eth/62] Maximum number of headers to queue for import (DOS protection)
maxHeadersProcess = 2048 // Number of header download results to import at once into the chain
maxResultsProcess = 2048 // Number of content download results to import at once into the chain
fullMaxForkAncestry uint64 = params . FullImmutabilityThreshold // Maximum chain reorganisation (locally redeclared so tests can reduce it)
2015-09-28 19:27:31 +03:00
2024-04-30 06:46:53 -07:00
reorgProtHeaderDelay = 2 // Number of headers to delay delivering to cover mini reorgs
2018-10-04 16:36:59 +03:00
2023-05-03 12:58:39 +03:00
fsHeaderSafetyNet = 2048 // Number of headers to discard in case a chain violation is detected
fsHeaderContCheck = 3 * time . Second // Time interval to check for header continuations during state download
fsMinFullBlocks = 64 // Number of blocks to retrieve fully even in snap sync
2015-05-15 13:14:46 +03:00
)
2015-04-19 13:30:34 +02:00
2015-05-15 13:14:46 +03:00
var (
2024-04-30 06:46:53 -07:00
errBusy = errors . New ( "busy" )
errBadPeer = errors . New ( "action from bad peer ignored" )
2016-02-25 18:36:42 +02:00
errTimeout = errors . New ( "timeout" )
errInvalidChain = errors . New ( "retrieved hash chain is invalid" )
errInvalidBody = errors . New ( "retrieved block body is invalid" )
errInvalidReceipt = errors . New ( "retrieved receipt is invalid" )
errCancelStateFetch = errors . New ( "state data download canceled (requested)" )
errCancelContentProcessing = errors . New ( "content processing canceled (requested)" )
2019-06-05 20:00:46 +08:00
errCanceled = errors . New ( "syncing canceled (requested)" )
2022-04-04 15:10:16 +08:00
errNoPivotHeader = errors . New ( "pivot header is not found" )
2015-04-18 01:10:32 +02:00
)
2021-11-26 13:26:03 +02:00
// peerDropFn is a callback type for dropping a peer detected as malicious.
type peerDropFn func ( id string )
2022-07-25 16:51:04 +03:00
// badBlockFn is a callback for the async beacon sync to notify the caller that
// the origin header requested to sync to, produced a chain with a bad block.
type badBlockFn func ( invalid * types . Header , origin * types . Header )
2021-12-01 20:18:12 +02:00
// headerTask is a set of downloaded headers to queue along with their precomputed
// hashes to avoid constant rehashing.
type headerTask struct {
headers [ ] * types . Header
hashes [ ] common . Hash
}
2015-04-12 12:38:25 +02:00
type Downloader struct {
2023-04-04 03:48:10 +08:00
mode atomic . Uint32 // Synchronisation mode defining the strategy used (per sync cycle), use d.getMode() to get the SyncMode
2016-06-02 12:37:14 +03:00
mux * event . TypeMux // Event multiplexer to announce sync operation events
2015-05-15 00:43:00 +02:00
2024-04-30 06:46:53 -07:00
queue * queue // Scheduler for selecting the hashes to download
peers * peerSet // Set of active peers from which download can proceed
2019-05-13 15:28:01 +03:00
2021-12-03 12:32:41 +02:00
stateDB ethdb . Database // Database to state sync into (and deduplicate via)
2015-04-12 12:38:25 +02:00
2015-06-10 01:20:35 +03:00
// Statistics
2021-11-26 13:26:03 +02:00
syncStatsChainOrigin uint64 // Origin block number where syncing started at
syncStatsChainHeight uint64 // Highest block number known when syncing started
2015-10-05 19:37:56 +03:00
syncStatsLock sync . RWMutex // Lock protecting the sync stats fields
2015-06-10 01:20:35 +03:00
2017-07-03 15:17:12 +01:00
blockchain BlockChain
2017-06-27 16:15:29 +01:00
2015-04-13 16:38:32 +02:00
// Callbacks
2017-06-27 16:15:29 +01:00
dropPeer peerDropFn // Drops a peer for misbehaving
2022-07-25 16:51:04 +03:00
badBlock badBlockFn // Reports a block as rejected by the chain
2015-04-12 12:38:25 +02:00
2015-04-13 16:38:32 +02:00
// Status
2024-04-30 06:46:53 -07:00
synchronising atomic . Bool
notified atomic . Bool
committed atomic . Bool
ancientLimit uint64 // The maximum block number which can be regarded as ancient data.
2015-04-13 16:38:32 +02:00
// Channels
2021-12-01 20:18:12 +02:00
headerProcCh chan * headerTask // Channel to feed the header processor new tasks
2015-05-13 13:47:21 +03:00
2022-03-11 14:14:45 +02:00
// Skeleton sync
skeleton * skeleton // Header skeleton to backfill the chain with (eth2 mode)
2020-09-08 11:13:16 +03:00
// State sync
pivotHeader * types . Header // Pivot block header to dynamically push the syncing state root
pivotLock sync . RWMutex // Lock protecting pivot header reads from updates
2020-12-14 11:27:15 +02:00
SnapSyncer * snap . Syncer // TODO(karalabe): make private! hack for now
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
stateSyncStart chan * stateSync
2016-07-26 13:07:12 +03:00
// Cancellation and termination
2018-04-16 16:37:48 +08:00
cancelCh chan struct { } // Channel to cancel mid-flight syncs
cancelLock sync . RWMutex // Lock to protect the cancel channel and peer in delivers
cancelWg sync . WaitGroup // Make sure all fetcher goroutines have exited.
2015-08-14 21:25:41 +03:00
2016-06-01 18:07:25 +03:00
quitCh chan struct { } // Quit channel to signal termination
2020-10-13 16:58:41 +08:00
quitLock sync . Mutex // Lock to prevent double closes
2016-06-01 18:07:25 +03:00
2015-08-14 21:25:41 +03:00
// Testing hooks
2015-09-28 19:27:31 +03:00
bodyFetchHook func ( [ ] * types . Header ) // Method to call upon starting a block body fetch
receiptFetchHook func ( [ ] * types . Header ) // Method to call upon starting a receipt fetch
chainInsertHook func ( [ ] * fetchResult ) // Method to call upon inserting a chain of blocks (possibly in multiple invocations)
2023-02-21 12:17:34 +02:00
// Progress reporting metrics
syncStartBlock uint64 // Head snap block when Geth was started
syncStartTime time . Time // Time instance when chain sync started
syncLogTime time . Time // Time instance when status was last reported
2015-05-26 14:00:21 +03:00
}
2024-05-28 10:52:08 -07:00
// BlockChain encapsulates functions required to sync a (full or snap) blockchain.
type BlockChain interface {
2017-06-27 16:15:29 +01:00
// HasHeader verifies a header's presence in the local chain.
2018-02-05 18:40:32 +02:00
HasHeader ( common . Hash , uint64 ) bool
2017-06-27 16:15:29 +01:00
// GetHeaderByHash retrieves a header from the local chain.
GetHeaderByHash ( common . Hash ) * types . Header
// CurrentHeader retrieves the head header from the local chain.
CurrentHeader ( ) * types . Header
2018-01-30 18:39:32 +02:00
// GetTd returns the total difficulty of a local block.
GetTd ( common . Hash , uint64 ) * big . Int
2017-06-27 16:15:29 +01:00
// InsertHeaderChain inserts a batch of headers into the local chain.
2023-05-03 12:58:39 +03:00
InsertHeaderChain ( [ ] * types . Header ) ( int , error )
2017-06-27 16:15:29 +01:00
2020-08-20 13:01:24 +03:00
// SetHead rewinds the local chain to a new head.
SetHead ( uint64 ) error
2017-06-27 16:15:29 +01:00
2018-02-11 14:43:56 +02:00
// HasBlock verifies a block's presence in the local chain.
HasBlock ( common . Hash , uint64 ) bool
2017-06-27 16:15:29 +01:00
2021-11-26 13:26:03 +02:00
// HasFastBlock verifies a snap block's presence in the local chain.
2018-11-16 13:15:05 +02:00
HasFastBlock ( common . Hash , uint64 ) bool
2017-06-27 16:15:29 +01:00
// GetBlockByHash retrieves a block from the local chain.
GetBlockByHash ( common . Hash ) * types . Block
// CurrentBlock retrieves the head block from the local chain.
2023-03-02 08:29:15 +02:00
CurrentBlock ( ) * types . Header
2017-06-27 16:15:29 +01:00
2023-03-02 08:29:15 +02:00
// CurrentSnapBlock retrieves the head snap block from the local chain.
CurrentSnapBlock ( ) * types . Header
2017-06-27 16:15:29 +01:00
2021-11-26 13:26:03 +02:00
// SnapSyncCommitHead directly commits the head block to a certain entity.
SnapSyncCommitHead ( common . Hash ) error
2017-06-27 16:15:29 +01:00
// InsertChain inserts a batch of blocks into the local chain.
InsertChain ( types . Blocks ) ( int , error )
// InsertReceiptChain inserts a batch of receipts into the local chain.
all: integrate the freezer with fast sync
* all: freezer style syncing
core, eth, les, light: clean up freezer relative APIs
core, eth, les, trie, ethdb, light: clean a bit
core, eth, les, light: add unit tests
core, light: rewrite setHead function
core, eth: fix downloader unit tests
core: add receipt chain insertion test
core: use constant instead of hardcoding table name
core: fix rollback
core: fix setHead
core/rawdb: remove canonical block first and then iterate side chain
core/rawdb, ethdb: add hasAncient interface
eth/downloader: calculate ancient limit via cht first
core, eth, ethdb: lots of fixes
* eth/downloader: print ancient disable log only for fast sync
2019-04-25 22:59:48 +08:00
InsertReceiptChain ( types . Blocks , [ ] types . Receipts , uint64 ) ( int , error )
2021-04-29 17:33:45 +03:00
// Snapshots returns the blockchain snapshot tree to paused it during sync.
Snapshots ( ) * snapshot . Tree
2022-11-28 21:31:28 +08:00
// TrieDB retrieves the low level trie database used for interacting
// with trie nodes.
2024-02-13 21:49:53 +08:00
TrieDB ( ) * triedb . Database
2017-06-27 16:15:29 +01:00
}
2015-06-11 15:56:08 +03:00
// New creates a new downloader to fetch hashes and blocks from remote peers.
2024-05-28 10:52:08 -07:00
func New ( stateDb ethdb . Database , mux * event . TypeMux , chain BlockChain , dropPeer peerDropFn , success func ( ) ) * Downloader {
2016-06-01 18:07:25 +03:00
dl := & Downloader {
2017-06-28 13:25:08 +01:00
stateDB : stateDb ,
mux : mux ,
2020-09-02 11:01:46 +02:00
queue : newQueue ( blockCacheMaxItems , blockCacheInitialItems ) ,
2017-06-28 13:25:08 +01:00
peers : newPeerSet ( ) ,
2017-07-03 15:17:12 +01:00
blockchain : chain ,
2017-06-28 13:25:08 +01:00
dropPeer : dropPeer ,
2021-12-01 20:18:12 +02:00
headerProcCh : make ( chan * headerTask , 1 ) ,
2017-06-28 13:25:08 +01:00
quitCh : make ( chan struct { } ) ,
2022-11-28 21:31:28 +08:00
SnapSyncer : snap . NewSyncer ( stateDb , chain . TrieDB ( ) . Scheme ( ) ) ,
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
stateSyncStart : make ( chan * stateSync ) ,
2023-03-02 08:29:15 +02:00
syncStartBlock : chain . CurrentSnapBlock ( ) . Number . Uint64 ( ) ,
2015-04-12 12:38:25 +02:00
}
2023-02-21 12:17:34 +02:00
// Create the post-merge skeleton syncer and start the process
2022-03-11 14:14:45 +02:00
dl . skeleton = newSkeleton ( stateDb , dl . peers , dropPeer , newBeaconBackfiller ( dl , success ) )
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
go dl . stateFetcher ( )
2016-06-01 18:07:25 +03:00
return dl
2015-04-12 12:38:25 +02:00
}
2015-10-13 12:04:25 +03:00
// Progress retrieves the synchronisation boundaries, specifically the origin
// block where synchronisation started at (may have failed/suspended); the block
// or header sync is currently at; and the latest known block which the sync targets.
2016-02-10 11:56:15 +02:00
//
2021-11-26 13:26:03 +02:00
// In addition, during the state download phase of snap synchronisation the number
2016-02-10 11:56:15 +02:00
// of processed and the total number of known states are also returned. Otherwise
// these are zero.
2016-09-06 12:39:14 +03:00
func ( d * Downloader ) Progress ( ) ethereum . SyncProgress {
2016-02-10 11:56:15 +02:00
// Lock the current stats and return the progress
2015-09-09 19:02:54 +03:00
d . syncStatsLock . RLock ( )
defer d . syncStatsLock . RUnlock ( )
2015-06-10 01:20:35 +03:00
2015-10-13 12:04:25 +03:00
current := uint64 ( 0 )
2020-06-30 19:43:29 +02:00
mode := d . getMode ( )
2024-05-28 10:52:08 -07:00
switch mode {
case FullSync :
2023-03-02 08:29:15 +02:00
current = d . blockchain . CurrentBlock ( ) . Number . Uint64 ( )
2024-05-28 10:52:08 -07:00
case SnapSync :
2023-03-02 08:29:15 +02:00
current = d . blockchain . CurrentSnapBlock ( ) . Number . Uint64 ( )
2019-05-13 15:28:01 +03:00
default :
2024-05-28 10:52:08 -07:00
log . Error ( "Unknown downloader mode" , "mode" , mode )
2015-10-13 12:04:25 +03:00
}
2021-11-26 13:26:03 +02:00
progress , pending := d . SnapSyncer . Progress ( )
2016-09-06 12:39:14 +03:00
return ethereum . SyncProgress {
2021-11-26 13:26:03 +02:00
StartingBlock : d . syncStatsChainOrigin ,
CurrentBlock : current ,
HighestBlock : d . syncStatsChainHeight ,
SyncedAccounts : progress . AccountSynced ,
SyncedAccountBytes : uint64 ( progress . AccountBytes ) ,
SyncedBytecodes : progress . BytecodeSynced ,
SyncedBytecodeBytes : uint64 ( progress . BytecodeBytes ) ,
SyncedStorage : progress . StorageSynced ,
SyncedStorageBytes : uint64 ( progress . StorageBytes ) ,
HealedTrienodes : progress . TrienodeHealSynced ,
HealedTrienodeBytes : uint64 ( progress . TrienodeHealBytes ) ,
HealedBytecodes : progress . BytecodeHealSynced ,
HealedBytecodeBytes : uint64 ( progress . BytecodeHealBytes ) ,
HealingTrienodes : pending . TrienodeHeal ,
HealingBytecode : pending . BytecodeHeal ,
2016-09-06 12:39:14 +03:00
}
2015-04-19 21:45:58 +02:00
}
2015-05-11 14:26:20 +03:00
// RegisterPeer injects a new download peer into the set of block source to be
// used for fetching hashes and blocks from.
2020-12-14 11:27:15 +02:00
func ( d * Downloader ) RegisterPeer ( id string , version uint , peer Peer ) error {
var logger log . Logger
if len ( id ) < 16 {
// Tests use short IDs, don't choke on them
logger = log . New ( "peer" , id )
} else {
2021-01-25 07:17:05 +01:00
logger = log . New ( "peer" , id [ : 8 ] )
2020-12-14 11:27:15 +02:00
}
2017-02-24 18:23:03 +02:00
logger . Trace ( "Registering sync peer" )
2017-06-28 13:25:08 +01:00
if err := d . peers . Register ( newPeerConnection ( id , version , peer , logger ) ) ; err != nil {
2017-02-27 13:17:58 +02:00
logger . Error ( "Failed to register sync peer" , "err" , err )
2015-05-11 14:26:20 +03:00
return err
}
2015-04-12 12:38:25 +02:00
return nil
}
2015-05-11 14:26:20 +03:00
// UnregisterPeer remove a peer from the known list, preventing any action from
2015-09-28 19:27:31 +03:00
// the specified peer. An effort is also made to return any pending fetches into
// the queue.
2015-05-11 14:26:20 +03:00
func ( d * Downloader ) UnregisterPeer ( id string ) error {
2016-07-26 13:07:12 +03:00
// Unregister the peer from the active peer set and revoke any fetch tasks
2020-12-14 11:27:15 +02:00
var logger log . Logger
if len ( id ) < 16 {
// Tests use short IDs, don't choke on them
logger = log . New ( "peer" , id )
} else {
2021-01-25 07:17:05 +01:00
logger = log . New ( "peer" , id [ : 8 ] )
2020-12-14 11:27:15 +02:00
}
2017-02-24 18:23:03 +02:00
logger . Trace ( "Unregistering sync peer" )
2015-05-11 14:26:20 +03:00
if err := d . peers . Unregister ( id ) ; err != nil {
2017-02-27 13:17:58 +02:00
logger . Error ( "Failed to unregister sync peer" , "err" , err )
2015-05-11 14:26:20 +03:00
return err
}
2015-09-28 19:27:31 +03:00
d . queue . Revoke ( id )
2016-07-26 13:07:12 +03:00
2015-05-11 14:26:20 +03:00
return nil
2015-04-12 12:38:25 +02:00
}
2015-06-11 15:56:08 +03:00
// synchronise will select the peer and use it for synchronising. If an empty string is given
2017-11-16 13:14:51 +02:00
// it will use the best peer possible and synchronize if its TD is higher than our own. If any of the
2015-04-24 14:40:32 +02:00
// checks fail an error will be returned. This method is synchronous
2024-04-30 06:46:53 -07:00
func ( d * Downloader ) synchronise ( mode SyncMode , beaconPing chan struct { } ) error {
2022-03-11 14:14:45 +02:00
// The beacon header syncer is async. It will start this synchronization and
2022-04-20 23:17:29 +09:00
// will continue doing other tasks. However, if synchronization needs to be
2022-03-11 14:14:45 +02:00
// cancelled, the syncer needs to know if we reached the startup point (and
2022-08-19 01:00:21 -05:00
// inited the cancel channel) or not yet. Make sure that we'll signal even in
2022-03-11 14:14:45 +02:00
// case of a failure.
if beaconPing != nil {
defer func ( ) {
select {
case <- beaconPing : // already notified
default :
close ( beaconPing ) // weird exit condition, notify that it's safe to cancel (the nothing)
}
} ( )
}
2015-05-07 21:07:20 +03:00
// Make sure only one goroutine is ever allowed past this point at once
2023-04-04 03:48:10 +08:00
if ! d . synchronising . CompareAndSwap ( false , true ) {
2015-06-11 15:56:08 +03:00
return errBusy
2015-04-19 13:30:34 +02:00
}
2023-04-04 03:48:10 +08:00
defer d . synchronising . Store ( false )
2015-04-24 14:40:32 +02:00
2015-05-13 16:03:05 +03:00
// Post a user notification of the sync (only once per session)
2023-04-04 03:48:10 +08:00
if d . notified . CompareAndSwap ( false , true ) {
2017-02-24 18:23:03 +02:00
log . Info ( "Block synchronisation started" )
2015-05-13 16:03:05 +03:00
}
2020-12-14 11:27:15 +02:00
if mode == SnapSync {
2023-09-17 22:35:09 +08:00
// Snap sync will directly modify the persistent state, making the entire
// trie database unusable until the state is fully synced. To prevent any
// subsequent state reads, explicitly disable the trie database and state
// syncer is responsible to address and correct any state missing.
if d . blockchain . TrieDB ( ) . Scheme ( ) == rawdb . PathScheme {
core, accounts, eth, trie: handle genesis state missing (#28171)
* core, accounts, eth, trie: handle genesis state missing
* core, eth, trie: polish
* core: manage txpool subscription in mainpool
* eth/backend: fix test
* cmd, eth: fix test
* core/rawdb, trie/triedb/pathdb: address comments
* eth, trie: address comments
* eth: inline the function
* eth: use synced flag
* core/txpool: revert changes in txpool
* core, eth, trie: rename functions
2023-09-28 15:00:53 +08:00
if err := d . blockchain . TrieDB ( ) . Disable ( ) ; err != nil {
return err
}
2023-09-17 22:35:09 +08:00
}
// Snap sync uses the snapshot namespace to store potentially flaky data until
2021-11-26 13:26:03 +02:00
// sync completely heals and finishes. Pause snapshot maintenance in the mean-
// time to prevent access.
if snapshots := d . blockchain . Snapshots ( ) ; snapshots != nil { // Only nil in tests
snapshots . Disable ( )
2020-12-14 11:27:15 +02:00
}
}
2015-09-28 19:27:31 +03:00
// Reset the queue, peer set and wake channels to clean any internal leftover state
2020-09-02 11:01:46 +02:00
d . queue . Reset ( blockCacheMaxItems , blockCacheInitialItems )
2015-05-11 14:26:20 +03:00
d . peers . Reset ( )
2015-05-08 17:21:11 +03:00
2021-11-26 13:26:03 +02:00
for _ , ch := range [ ] chan bool { d . queue . blockWakeCh , d . queue . receiptWakeCh } {
2015-09-28 19:27:31 +03:00
select {
case <- ch :
default :
}
2015-09-23 12:39:17 +03:00
}
2016-02-25 18:36:42 +02:00
for empty := false ; ! empty ; {
select {
case <- d . headerProcCh :
default :
empty = true
}
}
2016-07-26 13:07:12 +03:00
// Create cancel channel for aborting mid-flight and mark the master peer
2015-06-18 00:04:57 +03:00
d . cancelLock . Lock ( )
d . cancelCh = make ( chan struct { } )
d . cancelLock . Unlock ( )
2017-03-22 02:37:24 +02:00
defer d . Cancel ( ) // No matter what, we can't leave the cancel channel open
2016-05-30 12:01:50 +03:00
2020-06-30 19:43:29 +02:00
// Atomically set the requested sync mode
2023-04-04 03:48:10 +08:00
d . mode . Store ( uint32 ( mode ) )
2018-02-05 18:40:32 +02:00
2022-03-11 14:14:45 +02:00
if beaconPing != nil {
close ( beaconPing )
}
2024-04-30 06:46:53 -07:00
return d . syncToHead ( )
2015-05-01 00:23:51 +02:00
}
2020-06-30 19:43:29 +02:00
func ( d * Downloader ) getMode ( ) SyncMode {
2023-04-04 03:48:10 +08:00
return SyncMode ( d . mode . Load ( ) )
2020-06-30 19:43:29 +02:00
}
2024-04-30 06:46:53 -07:00
// syncToHead starts a block synchronization based on the hash chain from
// the specified head hash.
func ( d * Downloader ) syncToHead ( ) ( err error ) {
2015-05-16 12:29:19 +02:00
d . mux . Post ( StartEvent { } )
2015-05-01 00:23:51 +02:00
defer func ( ) {
// reset on error
if err != nil {
2015-05-15 00:43:00 +02:00
d . mux . Post ( FailedEvent { err } )
} else {
2024-05-28 10:52:08 -07:00
latest := d . blockchain . CurrentHeader ( )
cmd,eth: 16400 Add an option to stop geth once in sync. WIP for light mode (#17321)
* cmd, eth: Added in the flag to step geth once sync based on input
* cmd, eth: 16400 Add an option to stop geth once in sync.
* cmd: 16400 Add an option to stop geth once in sync. WIP
* cmd/geth/main, les/fletcher: added in light mode support
* cmd/geth/main, les/fletcher: Cleaned Comments and code for light mode
* cmd: 16400 Fixed formatting issue and cleaned code
* cmd, eth, les: 16400 Fixed formatting issues
* cmd, eth, les: Performed gofmt to update formatting
* cmd, eth, les: Fixed bugs resulting formatting
* cmd/geth, eth/, les: switched to downloader event
* eth: Fixed styling and gen_config
* eth/: Fix nil error in config file
* cmd/geth: Updated countdown log
* les/fetcher.go: Removed depcreated channel
* eth/downloader.go: Removed deprecated select
* cmd/geth, cmd/utils: Fixed minor issues
* eth: Reverted config files to proper format
* eth: Fixed typo in config file
* cmd/geth, eth/down: Updated code to use header time stamp
* eth/downloader: Changed the time threshold to 10 minutes
* cmd/geth, eth/downloader: Updated downloading event to pass latest header
* cmd/geth: Updated main to use right timer object
* cmd/geth: Removed unused failed event
* cmd/geth: added in correct time field with type assertion
* cmd/geth, cmd/utils: Updated flag to use boolean
* cmd/geth, cmd/utils, eth/downloader: Cleaned up code based on recommendations
* cmd/geth: Removed unneeded import
* cmd/geth, eth/downloader: fixed event field and suggested changes
* cmd/geth, cmd/utils: Updated flag and linting issue
2019-01-30 02:40:36 -05:00
d . mux . Post ( DoneEvent { latest } )
2015-05-01 00:23:51 +02:00
}
} ( )
2020-06-30 19:43:29 +02:00
mode := d . getMode ( )
2015-04-24 14:40:32 +02:00
2024-04-30 06:46:53 -07:00
log . Debug ( "Backfilling with the network" , "mode" , mode )
2015-09-30 19:23:31 +03:00
defer func ( start time . Time ) {
2019-05-15 14:33:33 +03:00
log . Debug ( "Synchronisation terminated" , "elapsed" , common . PrettyDuration ( time . Since ( start ) ) )
2015-09-30 19:23:31 +03:00
} ( time . Now ( ) )
2015-08-14 21:25:41 +03:00
2016-07-21 11:36:38 +02:00
// Look up the sync boundaries: the common ancestor and the target block
2023-02-23 13:22:41 +02:00
var latest , pivot , final * types . Header
2024-04-30 06:46:53 -07:00
latest , _ , final , err = d . skeleton . Bounds ( )
if err != nil {
return err
}
if latest . Number . Uint64 ( ) > uint64 ( fsMinFullBlocks ) {
number := latest . Number . Uint64 ( ) - uint64 ( fsMinFullBlocks )
// Retrieve the pivot header from the skeleton chain segment but
// fallback to local chain if it's not found in skeleton space.
if pivot = d . skeleton . Header ( number ) ; pivot == nil {
_ , oldest , _ , _ := d . skeleton . Bounds ( ) // error is already checked
if number < oldest . Number . Uint64 ( ) {
count := int ( oldest . Number . Uint64 ( ) - number ) // it's capped by fsMinFullBlocks
headers := d . readHeaderRange ( oldest , count )
if len ( headers ) == count {
pivot = headers [ len ( headers ) - 1 ]
log . Warn ( "Retrieved pivot header from local" , "number" , pivot . Number , "hash" , pivot . Hash ( ) , "latest" , latest . Number , "oldest" , oldest . Number )
2022-04-14 14:49:23 +08:00
}
2022-04-04 15:10:16 +08:00
}
2024-04-30 06:46:53 -07:00
}
// Print an error log and return directly in case the pivot header
// is still not found. It means the skeleton chain is not linked
// correctly with local chain.
if pivot == nil {
log . Error ( "Pivot header is not found" , "number" , number )
return errNoPivotHeader
2022-03-11 14:14:45 +02:00
}
2016-07-21 11:36:38 +02:00
}
2022-03-11 14:14:45 +02:00
// If no pivot block was returned, the head is below the min full block
// threshold (i.e. new chain). In that case we won't really snap sync
// anyway, but still need a valid pivot block to avoid some code hitting
// nil panics on access.
2021-11-26 13:26:03 +02:00
if mode == SnapSync && pivot == nil {
2023-03-02 08:29:15 +02:00
pivot = d . blockchain . CurrentBlock ( )
2020-09-08 11:13:16 +03:00
}
2016-07-21 11:36:38 +02:00
height := latest . Number . Uint64 ( )
2015-09-09 19:02:54 +03:00
2024-04-30 06:46:53 -07:00
// In beacon mode, use the skeleton chain for the ancestor lookup
origin , err := d . findBeaconAncestor ( )
if err != nil {
return err
2016-07-21 11:36:38 +02:00
}
d . syncStatsLock . Lock ( )
if d . syncStatsChainHeight <= origin || d . syncStatsChainOrigin > origin {
d . syncStatsChainOrigin = origin
}
d . syncStatsChainHeight = height
d . syncStatsLock . Unlock ( )
2016-05-27 14:26:00 +03:00
2021-11-26 13:26:03 +02:00
// Ensure our origin point is below any snap sync pivot point
if mode == SnapSync {
2018-02-05 18:40:32 +02:00
if height <= uint64 ( fsMinFullBlocks ) {
origin = 0
2016-07-21 11:36:38 +02:00
} else {
2020-09-08 11:13:16 +03:00
pivotNumber := pivot . Number . Uint64 ( )
if pivotNumber <= origin {
origin = pivotNumber - 1
2016-07-21 11:36:38 +02:00
}
2020-08-20 13:01:24 +03:00
// Write out the pivot into the database so a rollback beyond it will
2021-11-26 13:26:03 +02:00
// reenable snap sync
2020-09-08 11:13:16 +03:00
rawdb . WriteLastPivotNumber ( d . stateDB , pivotNumber )
2015-09-09 19:02:54 +03:00
}
2016-07-21 11:36:38 +02:00
}
2023-04-04 03:48:10 +08:00
d . committed . Store ( true )
2021-11-26 13:26:03 +02:00
if mode == SnapSync && pivot . Number . Uint64 ( ) != 0 {
2023-04-04 03:48:10 +08:00
d . committed . Store ( false )
2018-02-05 18:40:32 +02:00
}
2021-11-26 13:26:03 +02:00
if mode == SnapSync {
2023-02-23 13:22:41 +02:00
// Set the ancient data limitation. If we are running snap sync, all block
// data older than ancientLimit will be written to the ancient store. More
// recent data will be written to the active database and will wait for the
// freezer to migrate.
all: integrate the freezer with fast sync
* all: freezer style syncing
core, eth, les, light: clean up freezer relative APIs
core, eth, les, trie, ethdb, light: clean a bit
core, eth, les, light: add unit tests
core, light: rewrite setHead function
core, eth: fix downloader unit tests
core: add receipt chain insertion test
core: use constant instead of hardcoding table name
core: fix rollback
core: fix setHead
core/rawdb: remove canonical block first and then iterate side chain
core/rawdb, ethdb: add hasAncient interface
eth/downloader: calculate ancient limit via cht first
core, eth, ethdb: lots of fixes
* eth/downloader: print ancient disable log only for fast sync
2019-04-25 22:59:48 +08:00
//
2023-02-23 13:22:41 +02:00
// If the network is post-merge, use either the last announced finalized
// block as the ancient limit, or if we haven't yet received one, the head-
// a max fork ancestry limit. One quirky case if we've already passed the
// finalized block, in which case the skeleton.Bounds will return nil and
// we'll revert to head - 90K. That's fine, we're finishing sync anyway.
all: integrate the freezer with fast sync
* all: freezer style syncing
core, eth, les, light: clean up freezer relative APIs
core, eth, les, trie, ethdb, light: clean a bit
core, eth, les, light: add unit tests
core, light: rewrite setHead function
core, eth: fix downloader unit tests
core: add receipt chain insertion test
core: use constant instead of hardcoding table name
core: fix rollback
core: fix setHead
core/rawdb: remove canonical block first and then iterate side chain
core/rawdb, ethdb: add hasAncient interface
eth/downloader: calculate ancient limit via cht first
core, eth, ethdb: lots of fixes
* eth/downloader: print ancient disable log only for fast sync
2019-04-25 22:59:48 +08:00
//
2023-02-23 13:22:41 +02:00
// For non-merged networks, if there is a checkpoint available, then calculate
// the ancientLimit through that. Otherwise calculate the ancient limit through
// the advertised height of the remote peer. This most is mostly a fallback for
2023-12-18 16:35:12 +08:00
// legacy networks, but should eventually be dropped. TODO(karalabe).
2024-04-30 06:46:53 -07:00
//
// Beacon sync, use the latest finalized block as the ancient limit
// or a reasonable height if no finalized block is yet announced.
if final != nil {
d . ancientLimit = final . Number . Uint64 ( )
} else if height > fullMaxForkAncestry + 1 {
d . ancientLimit = height - fullMaxForkAncestry - 1
2020-10-09 14:58:30 +08:00
} else {
2024-04-30 06:46:53 -07:00
d . ancientLimit = 0
all: integrate the freezer with fast sync
* all: freezer style syncing
core, eth, les, light: clean up freezer relative APIs
core, eth, les, trie, ethdb, light: clean a bit
core, eth, les, light: add unit tests
core, light: rewrite setHead function
core, eth: fix downloader unit tests
core: add receipt chain insertion test
core: use constant instead of hardcoding table name
core: fix rollback
core: fix setHead
core/rawdb: remove canonical block first and then iterate side chain
core/rawdb, ethdb: add hasAncient interface
eth/downloader: calculate ancient limit via cht first
core, eth, ethdb: lots of fixes
* eth/downloader: print ancient disable log only for fast sync
2019-04-25 22:59:48 +08:00
}
frozen , _ := d . stateDB . Ancients ( ) // Ignore the error here since light client can also hit here.
2020-08-20 13:01:24 +03:00
all: integrate the freezer with fast sync
* all: freezer style syncing
core, eth, les, light: clean up freezer relative APIs
core, eth, les, trie, ethdb, light: clean a bit
core, eth, les, light: add unit tests
core, light: rewrite setHead function
core, eth: fix downloader unit tests
core: add receipt chain insertion test
core: use constant instead of hardcoding table name
core: fix rollback
core: fix setHead
core/rawdb: remove canonical block first and then iterate side chain
core/rawdb, ethdb: add hasAncient interface
eth/downloader: calculate ancient limit via cht first
core, eth, ethdb: lots of fixes
* eth/downloader: print ancient disable log only for fast sync
2019-04-25 22:59:48 +08:00
// If a part of blockchain data has already been written into active store,
// disable the ancient style insertion explicitly.
if origin >= frozen && frozen != 0 {
d . ancientLimit = 0
log . Info ( "Disabling direct-ancient mode" , "origin" , origin , "ancient" , frozen - 1 )
} else if d . ancientLimit > 0 {
log . Debug ( "Enabling direct-ancient mode" , "ancient" , d . ancientLimit )
}
// Rewind the ancient store and blockchain if reorg happens.
if origin + 1 < frozen {
2024-05-28 10:52:08 -07:00
if err := d . blockchain . SetHead ( origin ) ; err != nil {
2020-08-20 13:01:24 +03:00
return err
all: integrate the freezer with fast sync
* all: freezer style syncing
core, eth, les, light: clean up freezer relative APIs
core, eth, les, trie, ethdb, light: clean a bit
core, eth, les, light: add unit tests
core, light: rewrite setHead function
core, eth: fix downloader unit tests
core: add receipt chain insertion test
core: use constant instead of hardcoding table name
core: fix rollback
core: fix setHead
core/rawdb: remove canonical block first and then iterate side chain
core/rawdb, ethdb: add hasAncient interface
eth/downloader: calculate ancient limit via cht first
core, eth, ethdb: lots of fixes
* eth/downloader: print ancient disable log only for fast sync
2019-04-25 22:59:48 +08:00
}
2024-01-31 16:57:33 +08:00
log . Info ( "Truncated excess ancient chain segment" , "oldhead" , frozen - 1 , "newhead" , origin )
all: integrate the freezer with fast sync
* all: freezer style syncing
core, eth, les, light: clean up freezer relative APIs
core, eth, les, trie, ethdb, light: clean a bit
core, eth, les, light: add unit tests
core, light: rewrite setHead function
core, eth: fix downloader unit tests
core: add receipt chain insertion test
core: use constant instead of hardcoding table name
core: fix rollback
core: fix setHead
core/rawdb: remove canonical block first and then iterate side chain
core/rawdb, ethdb: add hasAncient interface
eth/downloader: calculate ancient limit via cht first
core, eth, ethdb: lots of fixes
* eth/downloader: print ancient disable log only for fast sync
2019-04-25 22:59:48 +08:00
}
}
2018-02-05 18:40:32 +02:00
// Initiate the sync using a concurrent header and content retrieval algorithm
2020-06-30 19:43:29 +02:00
d . queue . Prepare ( origin + 1 , mode )
2024-04-30 06:46:53 -07:00
// In beacon mode, headers are served by the skeleton syncer
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
fetchers := [ ] func ( ) error {
2024-04-30 06:46:53 -07:00
func ( ) error { return d . fetchHeaders ( origin + 1 ) } , // Headers are always retrieved
func ( ) error { return d . fetchBodies ( origin + 1 ) } , // Bodies are retrieved during normal and snap sync
func ( ) error { return d . fetchReceipts ( origin + 1 ) } , // Receipts are retrieved during snap sync
func ( ) error { return d . processHeaders ( origin + 1 ) } ,
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
}
2021-11-26 13:26:03 +02:00
if mode == SnapSync {
2020-09-08 11:13:16 +03:00
d . pivotLock . Lock ( )
d . pivotHeader = pivot
d . pivotLock . Unlock ( )
2021-11-26 13:26:03 +02:00
fetchers = append ( fetchers , func ( ) error { return d . processSnapSyncContent ( ) } )
2020-06-30 19:43:29 +02:00
} else if mode == FullSync {
2024-04-30 06:46:53 -07:00
fetchers = append ( fetchers , func ( ) error { return d . processFullSyncContent ( ) } )
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
}
2018-02-05 18:40:32 +02:00
return d . spawnSync ( fetchers )
2015-11-13 16:08:15 +00:00
}
// spawnSync runs d.process and all given fetcher functions to completion in
// separate goroutines, returning the first error that appears.
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
func ( d * Downloader ) spawnSync ( fetchers [ ] func ( ) error ) error {
errc := make ( chan error , len ( fetchers ) )
2018-04-16 16:37:48 +08:00
d . cancelWg . Add ( len ( fetchers ) )
2015-11-13 16:08:15 +00:00
for _ , fn := range fetchers {
fn := fn
2018-04-16 16:37:48 +08:00
go func ( ) { defer d . cancelWg . Done ( ) ; errc <- fn ( ) } ( )
2015-11-13 16:08:15 +00:00
}
// Wait for the first error, then terminate the others.
var err error
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
for i := 0 ; i < len ( fetchers ) ; i ++ {
if i == len ( fetchers ) - 1 {
2015-11-13 16:08:15 +00:00
// Close the queue when all fetchers have exited.
// This will cause the block processor to end when
// it has processed the queue.
d . queue . Close ( )
}
2023-05-05 13:55:32 +08:00
if got := <- errc ; got != nil {
err = got
if got != errCanceled {
break // receive a meaningful error, bubble it up
}
2015-11-13 16:08:15 +00:00
}
}
d . queue . Close ( )
2017-03-22 02:37:24 +02:00
d . Cancel ( )
2015-11-13 16:08:15 +00:00
return err
2015-04-12 12:38:25 +02:00
}
2018-04-23 00:01:21 -07:00
// cancel aborts all of the operations and resets the queue. However, cancel does
// not wait for the running download goroutines to finish. This method should be
// used when cancelling the downloads from inside the downloader.
func ( d * Downloader ) cancel ( ) {
2015-05-13 14:01:08 +03:00
// Close the current cancel channel
2015-05-15 19:43:42 +03:00
d . cancelLock . Lock ( )
2020-04-27 11:22:15 +03:00
defer d . cancelLock . Unlock ( )
2015-06-12 13:35:29 +03:00
if d . cancelCh != nil {
select {
case <- d . cancelCh :
// Channel was already closed
default :
close ( d . cancelCh )
}
2015-05-15 19:43:42 +03:00
}
2018-04-23 00:01:21 -07:00
}
// Cancel aborts all of the operations and waits for all download goroutines to
// finish before returning.
func ( d * Downloader ) Cancel ( ) {
d . cancel ( )
2018-04-16 16:37:48 +08:00
d . cancelWg . Wait ( )
2015-05-10 00:34:07 +02:00
}
2015-06-18 00:04:57 +03:00
// Terminate interrupts the downloader, canceling all pending operations.
2015-11-13 16:08:15 +00:00
// The downloader cannot be reused after calling Terminate.
2015-06-18 00:04:57 +03:00
func ( d * Downloader ) Terminate ( ) {
2016-06-01 18:07:25 +03:00
// Close the termination channel (make sure double close is allowed)
d . quitLock . Lock ( )
select {
case <- d . quitCh :
default :
close ( d . quitCh )
2022-03-11 14:14:45 +02:00
// Terminate the internal beacon syncer
d . skeleton . Terminate ( )
2016-06-01 18:07:25 +03:00
}
d . quitLock . Unlock ( )
// Cancel any pending download requests
2017-03-22 02:37:24 +02:00
d . Cancel ( )
2015-06-18 00:04:57 +03:00
}
2015-08-14 21:25:41 +03:00
// fetchBodies iteratively downloads the scheduled block bodies, taking any
// available peers, reserving a chunk of blocks for each, waiting for delivery
// and also periodically checking for timeouts.
2024-04-30 06:46:53 -07:00
func ( d * Downloader ) fetchBodies ( from uint64 ) error {
2017-02-24 18:23:03 +02:00
log . Debug ( "Downloading block bodies" , "origin" , from )
2024-04-30 06:46:53 -07:00
err := d . concurrentFetch ( ( * bodyQueue ) ( d ) )
2015-09-28 19:27:31 +03:00
2017-02-27 13:17:58 +02:00
log . Debug ( "Block body download terminated" , "err" , err )
2015-09-28 19:27:31 +03:00
return err
}
// fetchReceipts iteratively downloads the scheduled block receipts, taking any
// available peers, reserving a chunk of receipts for each, waiting for delivery
// and also periodically checking for timeouts.
2024-04-30 06:46:53 -07:00
func ( d * Downloader ) fetchReceipts ( from uint64 ) error {
2021-11-26 13:26:03 +02:00
log . Debug ( "Downloading receipts" , "origin" , from )
2024-04-30 06:46:53 -07:00
err := d . concurrentFetch ( ( * receiptQueue ) ( d ) )
2015-09-28 19:27:31 +03:00
2021-11-26 13:26:03 +02:00
log . Debug ( "Receipt download terminated" , "err" , err )
2015-09-28 19:27:31 +03:00
return err
}
2016-02-25 18:36:42 +02:00
// processHeaders takes batches of retrieved headers from an input channel and
// keeps processing and scheduling them into the header chain and downloader's
// queue until the stream ends or a failure occurs.
2024-04-30 06:46:53 -07:00
func ( d * Downloader ) processHeaders ( origin uint64 ) error {
2020-07-24 09:46:26 +02:00
var (
2024-04-30 06:46:53 -07:00
mode = d . getMode ( )
timer = time . NewTimer ( time . Second )
2020-07-24 09:46:26 +02:00
)
2024-04-09 14:51:54 +08:00
defer timer . Stop ( )
2016-02-25 18:36:42 +02:00
for {
select {
case <- d . cancelCh :
2019-06-05 20:00:46 +08:00
return errCanceled
2016-02-25 18:36:42 +02:00
2021-12-01 20:18:12 +02:00
case task := <- d . headerProcCh :
2016-02-25 18:36:42 +02:00
// Terminate header processing if we synced up
2021-12-01 20:18:12 +02:00
if task == nil || len ( task . headers ) == 0 {
2016-02-25 18:36:42 +02:00
// Notify everyone that headers are fully processed
2021-11-26 13:26:03 +02:00
for _ , ch := range [ ] chan bool { d . queue . blockWakeCh , d . queue . receiptWakeCh } {
2016-02-25 18:36:42 +02:00
select {
case ch <- false :
case <- d . cancelCh :
}
}
return nil
}
// Otherwise split the chunk of headers into batches and process them
2021-12-01 20:18:12 +02:00
headers , hashes := task . headers , task . hashes
2016-02-25 18:36:42 +02:00
for len ( headers ) > 0 {
// Terminate if something failed in between processing chunks
select {
case <- d . cancelCh :
2019-06-05 20:00:46 +08:00
return errCanceled
2016-02-25 18:36:42 +02:00
default :
}
// Select the next chunk of headers to import
limit := maxHeadersProcess
if limit > len ( headers ) {
limit = len ( headers )
}
2021-12-01 20:18:12 +02:00
chunkHeaders := headers [ : limit ]
chunkHashes := hashes [ : limit ]
2020-08-20 13:01:24 +03:00
2016-02-25 18:36:42 +02:00
// In case of header only syncing, validate the chunk immediately
2024-05-28 10:52:08 -07:00
if mode == SnapSync {
2022-03-11 14:14:45 +02:00
// Although the received headers might be all valid, a legacy
// PoW/PoA sync must not accept post-merge headers. Make sure
// that any transition is rejected at this point.
2022-03-23 01:58:05 +08:00
if len ( chunkHeaders ) > 0 {
2024-05-28 10:52:08 -07:00
if n , err := d . blockchain . InsertHeaderChain ( chunkHeaders ) ; err != nil {
2022-03-23 01:58:05 +08:00
log . Warn ( "Invalid header encountered" , "number" , chunkHeaders [ n ] . Number , "hash" , chunkHashes [ n ] , "parent" , chunkHeaders [ n ] . ParentHash , "err" , err )
return fmt . Errorf ( "%w: %v" , errInvalidChain , err )
2016-02-25 18:36:42 +02:00
}
}
}
2024-05-28 10:52:08 -07:00
// If we've reached the allowed number of pending headers, stall a bit
for d . queue . PendingBodies ( ) >= maxQueuedHeaders || d . queue . PendingReceipts ( ) >= maxQueuedHeaders {
timer . Reset ( time . Second )
select {
case <- d . cancelCh :
return errCanceled
case <- timer . C :
2016-02-25 18:36:42 +02:00
}
}
2024-05-28 10:52:08 -07:00
// Otherwise insert the headers for content retrieval
inserts := d . queue . Schedule ( chunkHeaders , chunkHashes , origin )
if len ( inserts ) != len ( chunkHeaders ) {
return fmt . Errorf ( "%w: stale headers" , errBadPeer )
}
2016-02-25 18:36:42 +02:00
headers = headers [ limit : ]
2021-12-01 20:18:12 +02:00
hashes = hashes [ limit : ]
2016-02-25 18:36:42 +02:00
origin += uint64 ( limit )
}
2018-03-09 17:51:30 +08:00
// Update the highest block number we know if a higher one is found.
d . syncStatsLock . Lock ( )
if d . syncStatsChainHeight < origin {
d . syncStatsChainHeight = origin - 1
}
d . syncStatsLock . Unlock ( )
2022-08-19 01:00:21 -05:00
// Signal the content downloaders of the availability of new tasks
2021-11-26 13:26:03 +02:00
for _ , ch := range [ ] chan bool { d . queue . blockWakeCh , d . queue . receiptWakeCh } {
2016-02-25 18:36:42 +02:00
select {
case ch <- true :
default :
}
}
}
}
}
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
// processFullSyncContent takes fetch results from the queue and imports them into the chain.
2024-04-30 06:46:53 -07:00
func ( d * Downloader ) processFullSyncContent ( ) error {
2015-06-12 13:35:29 +03:00
for {
2018-02-05 18:40:32 +02:00
results := d . queue . Results ( true )
2015-09-28 19:27:31 +03:00
if len ( results ) == 0 {
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
return nil
2015-06-12 13:35:29 +03:00
}
2015-08-14 21:25:41 +03:00
if d . chainInsertHook != nil {
2015-09-28 19:27:31 +03:00
d . chainInsertHook ( results )
2015-08-14 21:25:41 +03:00
}
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
if err := d . importBlockResults ( results ) ; err != nil {
return err
}
}
}
func ( d * Downloader ) importBlockResults ( results [ ] * fetchResult ) error {
2018-02-05 18:40:32 +02:00
// Check for any early termination requests
if len ( results ) == 0 {
return nil
}
select {
case <- d . quitCh :
return errCancelContentProcessing
default :
}
2022-07-25 16:51:04 +03:00
// Retrieve a batch of results to import
2018-02-05 18:40:32 +02:00
first , last := results [ 0 ] . Header , results [ len ( results ) - 1 ] . Header
log . Debug ( "Inserting downloaded chain" , "items" , len ( results ) ,
"firstnum" , first . Number , "firsthash" , first . Hash ( ) ,
"lastnum" , last . Number , "lasthash" , last . Hash ( ) ,
)
blocks := make ( [ ] * types . Block , len ( results ) )
for i , result := range results {
2024-04-30 06:55:08 -06:00
blocks [ i ] = types . NewBlockWithHeader ( result . Header ) . WithBody ( result . body ( ) )
2018-02-05 18:40:32 +02:00
}
all: core rework for the merge transition (#23761)
* all: work for eth1/2 transtition
* consensus/beacon, eth: change beacon difficulty to 0
* eth: updates
* all: add terminalBlockDifficulty config, fix rebasing issues
* eth: implemented merge interop spec
* internal/ethapi: update to v1.0.0.alpha.2
This commit updates the code to the new spec, moving payloadId into
it's own object. It also fixes an issue with finalizing an empty blockhash.
It also properly sets the basefee
* all: sync polishes, other fixes + refactors
* core, eth: correct semantics for LeavePoW, EnterPoS
* core: fixed rebasing artifacts
* core: light: performance improvements
* core: use keyed field (f)
* core: eth: fix compilation issues + tests
* eth/catalyst: dbetter error codes
* all: move Merger to consensus/, remove reliance on it in bc
* all: renamed EnterPoS and LeavePoW to ReachTDD and FinalizePoS
* core: make mergelogs a function
* core: use InsertChain instead of InsertBlock
* les: drop merger from lightchain object
* consensus: add merger
* core: recoverAncestors in catalyst mode
* core: fix nitpick
* all: removed merger from beacon, use TTD, nitpicks
* consensus: eth: add docstring, removed unnecessary code duplication
* consensus/beacon: better comment
* all: easy to fix nitpicks by karalabe
* consensus/beacon: verify known headers to be sure
* core: comments
* core: eth: don't drop peers who advertise blocks, nitpicks
* core: never add beacon blocks to the future queue
* core: fixed nitpicks
* consensus/beacon: simplify IsTTDReached check
* consensus/beacon: correct IsTTDReached check
Co-authored-by: rjl493456442 <garyrong0905@gmail.com>
Co-authored-by: Péter Szilágyi <peterke@gmail.com>
2021-11-26 12:23:02 +01:00
// Downloaded blocks are always regarded as trusted after the
// transition. Because the downloaded chain is guided by the
// consensus-layer.
2018-02-05 18:40:32 +02:00
if index , err := d . blockchain . InsertChain ( blocks ) ; err != nil {
2018-12-20 10:46:08 +01:00
if index < len ( results ) {
log . Debug ( "Downloaded item processing failed" , "number" , results [ index ] . Header . Number , "hash" , results [ index ] . Header . Hash ( ) , "err" , err )
2022-07-25 16:51:04 +03:00
// In post-merge, notify the engine API of encountered bad chains
if d . badBlock != nil {
2023-02-23 13:22:41 +02:00
head , _ , _ , err := d . skeleton . Bounds ( )
2022-07-25 16:51:04 +03:00
if err != nil {
log . Error ( "Failed to retrieve beacon bounds for bad block reporting" , "err" , err )
} else {
d . badBlock ( blocks [ index ] . Header ( ) , head )
}
}
2018-12-20 10:46:08 +01:00
} else {
// The InsertChain method in blockchain.go will sometimes return an out-of-bounds index,
// when it needs to preprocess blocks to import a sidechain.
// The importer will put together a new list of blocks to import, which is a superset
// of the blocks delivered from the downloader, and the indexing will be off.
log . Debug ( "Downloaded item processing failed on sidechain import" , "index" , index , "err" , err )
}
2020-05-29 11:12:43 +02:00
return fmt . Errorf ( "%w: %v" , errInvalidChain , err )
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
}
return nil
}
2021-11-26 13:26:03 +02:00
// processSnapSyncContent takes fetch results from the queue and writes them to the
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
// database. It also controls the synchronisation of state nodes of the pivot block.
2021-11-26 13:26:03 +02:00
func ( d * Downloader ) processSnapSyncContent ( ) error {
2018-02-05 18:40:32 +02:00
// Start syncing state of the reported head block. This should get us most of
// the state of the pivot block.
2020-09-08 11:13:16 +03:00
d . pivotLock . RLock ( )
sync := d . syncState ( d . pivotHeader . Root )
d . pivotLock . RUnlock ( )
2020-08-26 13:05:06 +03:00
defer func ( ) {
// The `sync` object is replaced every time the pivot moves. We need to
// defer close the very last active one, hence the lazy evaluation vs.
// calling defer sync.Cancel() !!!
sync . Cancel ( )
} ( )
2019-10-25 13:17:32 +02:00
closeOnErr := func ( s * stateSync ) {
2021-02-16 16:11:33 +02:00
if err := s . Wait ( ) ; err != nil && err != errCancelStateFetch && err != errCanceled && err != snap . ErrCancelled {
2018-10-23 06:21:16 -05:00
d . queue . Close ( ) // wake up Results
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
}
2019-10-25 13:17:32 +02:00
}
go closeOnErr ( sync )
2020-08-20 13:01:24 +03:00
2018-02-05 18:40:32 +02:00
// To cater for moving pivot points, track the pivot block and subsequently
2018-04-04 18:25:02 +08:00
// accumulated download results separately.
2023-09-15 15:06:25 +03:00
//
// These will be nil up to the point where we reach the pivot, and will only
// be set temporarily if the synced blocks are piling up, but the pivot is
// still busy downloading. In that case, we need to occasionally check for
// pivot moves, so need to unblock the loop. These fields will accumulate
// the results in the meantime.
//
// Note, there's no issue with memory piling up since after 64 blocks the
// pivot will forcefully move so these accumulators will be dropped.
2018-02-05 18:40:32 +02:00
var (
oldPivot * fetchResult // Locked in pivot block, might change eventually
oldTail [ ] * fetchResult // Downloaded content after the pivot
2024-04-09 14:51:54 +08:00
timer = time . NewTimer ( time . Second )
2018-02-05 18:40:32 +02:00
)
2024-04-09 14:51:54 +08:00
defer timer . Stop ( )
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
for {
2023-09-15 15:06:25 +03:00
// Wait for the next batch of downloaded data to be available. If we have
// not yet reached the pivot point, wait blockingly as there's no need to
// spin-loop check for pivot moves. If we reached the pivot but have not
// yet processed it, check for results async, so we might notice pivot
// moves while state syncing. If the pivot was passed fully, block again
// as there's no more reason to check for pivot moves at all.
results := d . queue . Results ( oldPivot == nil )
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
if len ( results ) == 0 {
2018-02-05 18:40:32 +02:00
// If pivot sync is done, stop
2023-09-15 15:06:25 +03:00
if d . committed . Load ( ) {
2023-02-21 12:17:34 +02:00
d . reportSnapSyncProgress ( true )
2019-10-25 13:17:32 +02:00
return sync . Cancel ( )
2018-02-05 18:40:32 +02:00
}
// If sync failed, stop
select {
case <- d . cancelCh :
2019-10-25 13:17:32 +02:00
sync . Cancel ( )
2019-06-05 20:00:46 +08:00
return errCanceled
2018-02-05 18:40:32 +02:00
default :
}
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
}
if d . chainInsertHook != nil {
d . chainInsertHook ( results )
}
2023-02-21 12:17:34 +02:00
d . reportSnapSyncProgress ( false )
2020-09-08 11:13:16 +03:00
// If we haven't downloaded the pivot block yet, check pivot staleness
// notifications from the header downloader
d . pivotLock . RLock ( )
pivot := d . pivotHeader
d . pivotLock . RUnlock ( )
2023-09-15 15:06:25 +03:00
if oldPivot == nil { // no results piling up, we can move the pivot
if ! d . committed . Load ( ) { // not yet passed the pivot, we can move the pivot
if pivot . Root != sync . root { // pivot position changed, we can move the pivot
sync . Cancel ( )
sync = d . syncState ( pivot . Root )
2020-09-08 11:13:16 +03:00
2023-09-15 15:06:25 +03:00
go closeOnErr ( sync )
}
2020-09-08 11:13:16 +03:00
}
2023-09-15 15:06:25 +03:00
} else { // results already piled up, consume before handling pivot move
2018-02-05 18:40:32 +02:00
results = append ( append ( [ ] * fetchResult { oldPivot } , oldTail ... ) , results ... )
}
2021-11-26 13:26:03 +02:00
// Split around the pivot block and process the two sides via snap/full sync
2023-04-04 03:48:10 +08:00
if ! d . committed . Load ( ) {
2020-09-08 11:13:16 +03:00
latest := results [ len ( results ) - 1 ] . Header
// If the height is above the pivot block by 2 sets, it means the pivot
2023-09-15 15:06:25 +03:00
// become stale in the network, and it was garbage collected, move to a
2020-09-08 11:13:16 +03:00
// new pivot.
//
// Note, we have `reorgProtHeaderDelay` number of blocks withheld, Those
// need to be taken into account, otherwise we're detecting the pivot move
// late and will drop peers due to unavailable state!!!
if height := latest . Number . Uint64 ( ) ; height >= pivot . Number . Uint64 ( ) + 2 * uint64 ( fsMinFullBlocks ) - uint64 ( reorgProtHeaderDelay ) {
log . Warn ( "Pivot became stale, moving" , "old" , pivot . Number . Uint64 ( ) , "new" , height - uint64 ( fsMinFullBlocks ) + uint64 ( reorgProtHeaderDelay ) )
pivot = results [ len ( results ) - 1 - fsMinFullBlocks + reorgProtHeaderDelay ] . Header // must exist as lower old pivot is uncommitted
d . pivotLock . Lock ( )
d . pivotHeader = pivot
d . pivotLock . Unlock ( )
2020-08-20 13:01:24 +03:00
// Write out the pivot into the database so a rollback beyond it will
2021-11-26 13:26:03 +02:00
// reenable snap sync
2020-09-08 11:13:16 +03:00
rawdb . WriteLastPivotNumber ( d . stateDB , pivot . Number . Uint64 ( ) )
2018-02-05 18:40:32 +02:00
}
}
2020-09-08 11:13:16 +03:00
P , beforeP , afterP := splitAroundPivot ( pivot . Number . Uint64 ( ) , results )
2021-11-26 13:26:03 +02:00
if err := d . commitSnapSyncData ( beforeP , sync ) ; err != nil {
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
return err
}
if P != nil {
2018-02-05 18:40:32 +02:00
// If new pivot block found, cancel old state retrieval and restart
if oldPivot != P {
2019-10-25 13:17:32 +02:00
sync . Cancel ( )
sync = d . syncState ( P . Header . Root )
2020-08-26 13:05:06 +03:00
2019-10-25 13:17:32 +02:00
go closeOnErr ( sync )
2018-02-05 18:40:32 +02:00
oldPivot = P
}
// Wait for completion, occasionally checking for pivot staleness
2024-04-09 14:51:54 +08:00
timer . Reset ( time . Second )
2018-02-05 18:40:32 +02:00
select {
2019-10-25 13:17:32 +02:00
case <- sync . done :
if sync . err != nil {
return sync . err
2018-02-05 18:40:32 +02:00
}
if err := d . commitPivotBlock ( P ) ; err != nil {
return err
}
oldPivot = nil
2024-04-09 14:51:54 +08:00
case <- timer . C :
2018-02-05 18:40:32 +02:00
oldTail = afterP
continue
2015-06-12 13:35:29 +03:00
}
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
}
2018-02-05 18:40:32 +02:00
// Fast sync done, pivot commit done, full import
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
if err := d . importBlockResults ( afterP ) ; err != nil {
return err
}
}
}
func splitAroundPivot ( pivot uint64 , results [ ] * fetchResult ) ( p * fetchResult , before , after [ ] * fetchResult ) {
2020-07-24 09:46:26 +02:00
if len ( results ) == 0 {
return nil , nil , nil
}
if lastNum := results [ len ( results ) - 1 ] . Header . Number . Uint64 ( ) ; lastNum < pivot {
// the pivot is somewhere in the future
return nil , results , nil
}
// This can also be optimized, but only happens very seldom
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
for _ , result := range results {
num := result . Header . Number . Uint64 ( )
switch {
case num < pivot :
before = append ( before , result )
case num == pivot :
p = result
default :
after = append ( after , result )
}
}
return p , before , after
}
2021-11-26 13:26:03 +02:00
func ( d * Downloader ) commitSnapSyncData ( results [ ] * fetchResult , stateSync * stateSync ) error {
2018-02-05 18:40:32 +02:00
// Check for any early termination requests
if len ( results ) == 0 {
return nil
}
select {
case <- d . quitCh :
return errCancelContentProcessing
case <- stateSync . done :
if err := stateSync . Wait ( ) ; err != nil {
return err
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
}
2018-02-05 18:40:32 +02:00
default :
}
2023-02-21 12:17:34 +02:00
// Retrieve the batch of results to import
2018-02-05 18:40:32 +02:00
first , last := results [ 0 ] . Header , results [ len ( results ) - 1 ] . Header
2021-11-26 13:26:03 +02:00
log . Debug ( "Inserting snap-sync blocks" , "items" , len ( results ) ,
2018-02-05 18:40:32 +02:00
"firstnum" , first . Number , "firsthash" , first . Hash ( ) ,
"lastnumn" , last . Number , "lasthash" , last . Hash ( ) ,
)
blocks := make ( [ ] * types . Block , len ( results ) )
receipts := make ( [ ] types . Receipts , len ( results ) )
for i , result := range results {
2024-04-30 06:55:08 -06:00
blocks [ i ] = types . NewBlockWithHeader ( result . Header ) . WithBody ( result . body ( ) )
2018-02-05 18:40:32 +02:00
receipts [ i ] = result . Receipts
}
all: integrate the freezer with fast sync
* all: freezer style syncing
core, eth, les, light: clean up freezer relative APIs
core, eth, les, trie, ethdb, light: clean a bit
core, eth, les, light: add unit tests
core, light: rewrite setHead function
core, eth: fix downloader unit tests
core: add receipt chain insertion test
core: use constant instead of hardcoding table name
core: fix rollback
core: fix setHead
core/rawdb: remove canonical block first and then iterate side chain
core/rawdb, ethdb: add hasAncient interface
eth/downloader: calculate ancient limit via cht first
core, eth, ethdb: lots of fixes
* eth/downloader: print ancient disable log only for fast sync
2019-04-25 22:59:48 +08:00
if index , err := d . blockchain . InsertReceiptChain ( blocks , receipts , d . ancientLimit ) ; err != nil {
2018-02-05 18:40:32 +02:00
log . Debug ( "Downloaded item processing failed" , "number" , results [ index ] . Header . Number , "hash" , results [ index ] . Header . Hash ( ) , "err" , err )
2020-05-29 11:12:43 +02:00
return fmt . Errorf ( "%w: %v" , errInvalidChain , err )
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
}
return nil
}
func ( d * Downloader ) commitPivotBlock ( result * fetchResult ) error {
2024-04-30 06:55:08 -06:00
block := types . NewBlockWithHeader ( result . Header ) . WithBody ( result . body ( ) )
2021-11-26 13:26:03 +02:00
log . Debug ( "Committing snap sync pivot as new head" , "number" , block . Number ( ) , "hash" , block . Hash ( ) )
2019-05-13 15:28:01 +03:00
// Commit the pivot block as the new head, will require full sync from here on
all: integrate the freezer with fast sync
* all: freezer style syncing
core, eth, les, light: clean up freezer relative APIs
core, eth, les, trie, ethdb, light: clean a bit
core, eth, les, light: add unit tests
core, light: rewrite setHead function
core, eth: fix downloader unit tests
core: add receipt chain insertion test
core: use constant instead of hardcoding table name
core: fix rollback
core: fix setHead
core/rawdb: remove canonical block first and then iterate side chain
core/rawdb, ethdb: add hasAncient interface
eth/downloader: calculate ancient limit via cht first
core, eth, ethdb: lots of fixes
* eth/downloader: print ancient disable log only for fast sync
2019-04-25 22:59:48 +08:00
if _ , err := d . blockchain . InsertReceiptChain ( [ ] * types . Block { block } , [ ] types . Receipts { result . Receipts } , d . ancientLimit ) ; err != nil {
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
return err
}
2021-11-26 13:26:03 +02:00
if err := d . blockchain . SnapSyncCommitHead ( block . Hash ( ) ) ; err != nil {
eth/downloader: separate state sync from queue (#14460)
* eth/downloader: separate state sync from queue
Scheduling of state node downloads hogged the downloader queue lock when
new requests were scheduled. This caused timeouts for other requests.
With this change, state sync is fully independent of all other downloads
and doesn't involve the queue at all.
State sync is started and checked on in processContent. This is slightly
awkward because processContent doesn't have a select loop. Instead, the
queue is closed by an auxiliary goroutine when state sync fails. We
tried several alternatives to this but settled on the current approach
because it's the least amount of change overall.
Handling of the pivot block has changed slightly: the queue previously
prevented import of pivot block receipts before the state of the pivot
block was available. In this commit, the receipt will be imported before
the state. This causes an annoyance where the pivot block is committed
as fast block head even when state downloads fail. Stay tuned for more
updates in this area ;)
* eth/downloader: remove cancelTimeout channel
* eth/downloader: retry state requests on timeout
* eth/downloader: improve comment
* eth/downloader: mark peers idle when state sync is done
* eth/downloader: move pivot block splitting to processContent
This change also ensures that pivot block receipts aren't imported
before the pivot block itself.
* eth/downloader: limit state node retries
* eth/downloader: improve state node error handling and retry check
* eth/downloader: remove maxStateNodeRetries
It fails the sync too much.
* eth/downloader: remove last use of cancelCh in statesync.go
Fixes TestDeliverHeadersHang*Fast and (hopefully)
the weird cancellation behaviour at the end of fast sync.
* eth/downloader: fix leak in runStateSync
* eth/downloader: don't run processFullSyncContent in LightSync mode
* eth/downloader: improve comments
* eth/downloader: fix vet, megacheck
* eth/downloader: remove unrequested tasks anyway
* eth/downloader, trie: various polishes around duplicate items
This commit explicitly tracks duplicate and unexpected state
delieveries done against a trie Sync structure, also adding
there to import info logs.
The commit moves the db batch used to commit trie changes one
level deeper so its flushed after every node insertion. This
is needed to avoid a lot of duplicate retrievals caused by
inconsistencies between Sync internals and database. A better
approach is to track not-yet-written states in trie.Sync and
flush on commit, but I'm focuing on correctness first now.
The commit fixes a regression around pivot block fail count.
The counter previously was reset to 1 if and only if a sync
cycle progressed (inserted at least 1 entry to the database).
The current code reset it already if a node was delivered,
which is not stong enough, because unless it ends up written
to disk, an attacker can just loop and attack ad infinitum.
The commit also fixes a regression around state deliveries
and timeouts. The old downloader tracked if a delivery is
stale (none of the deliveries were requestedt), in which
case it didn't mark the node idle and did not send further
requests, since it signals a past timeout. The current code
did mark it idle even on stale deliveries, which eventually
caused two requests to be in flight at the same time, making
the deliveries always stale and mass duplicating retrievals
between multiple peers.
* eth/downloader: fix state request leak
This commit fixes the hang seen sometimes while doing the state
sync. The cause of the hang was a rare combination of events:
request state data from peer, peer drops and reconnects almost
immediately. This caused a new download task to be assigned to
the peer, overwriting the old one still waiting for a timeout,
which in turned leaked the requests out, never to be retried.
The fix is to ensure that a task assignment moves any pending
one back into the retry queue.
The commit also fixes a regression with peer dropping due to
stalls. The current code considered a peer stalling if they
timed out delivering 1 item. However, the downloader never
requests only one, the minimum is 2 (attempt to fine tune
estimated latency/bandwidth). The fix is simply to drop if
a timeout is detected at 2 items.
Apart from the above bugfixes, the commit contains some code
polishes I made while debugging the hang.
* core, eth, trie: support batched trie sync db writes
* trie: rename SyncMemCache to syncMemBatch
2017-06-22 14:26:03 +02:00
return err
2015-06-12 13:35:29 +03:00
}
2023-04-04 03:48:10 +08:00
d . committed . Store ( true )
2018-02-05 18:40:32 +02:00
return nil
2015-06-12 13:35:29 +03:00
}
2020-12-14 11:27:15 +02:00
// DeliverSnapPacket is invoked from a peer's message handler when it transmits a
// data packet for the local node to consume.
func ( d * Downloader ) DeliverSnapPacket ( peer * snap . Peer , packet snap . Packet ) error {
switch packet := packet . ( type ) {
case * snap . AccountRangePacket :
hashes , accounts , err := packet . Unpack ( )
if err != nil {
return err
}
return d . SnapSyncer . OnAccounts ( peer , packet . ID , hashes , accounts , packet . Proof )
case * snap . StorageRangesPacket :
hashset , slotset := packet . Unpack ( )
return d . SnapSyncer . OnStorage ( peer , packet . ID , hashset , slotset , packet . Proof )
case * snap . ByteCodesPacket :
return d . SnapSyncer . OnByteCodes ( peer , packet . ID , packet . Codes )
case * snap . TrieNodesPacket :
return d . SnapSyncer . OnTrieNodes ( peer , packet . ID , packet . Nodes )
default :
return fmt . Errorf ( "unexpected snap packet type: %T" , packet )
}
2015-10-05 19:37:56 +03:00
}
2022-04-14 14:49:23 +08:00
// readHeaderRange returns a list of headers, using the given last header as the base,
// and going backwards towards genesis. This method assumes that the caller already has
// placed a reasonable cap on count.
func ( d * Downloader ) readHeaderRange ( last * types . Header , count int ) [ ] * types . Header {
var (
current = last
headers [ ] * types . Header
)
for {
2024-05-28 10:52:08 -07:00
parent := d . blockchain . GetHeaderByHash ( current . ParentHash )
2022-04-14 14:49:23 +08:00
if parent == nil {
break // The chain is not continuous, or the chain is exhausted
}
headers = append ( headers , parent )
if len ( headers ) >= count {
break
}
current = parent
}
return headers
}
2023-02-21 12:17:34 +02:00
// reportSnapSyncProgress calculates various status reports and provides it to the user.
func ( d * Downloader ) reportSnapSyncProgress ( force bool ) {
// Initialize the sync start time if it's the first time we're reporting
if d . syncStartTime . IsZero ( ) {
d . syncStartTime = time . Now ( ) . Add ( - time . Millisecond ) // -1ms offset to avoid division by zero
}
// Don't report all the events, just occasionally
if ! force && time . Since ( d . syncLogTime ) < 8 * time . Second {
return
}
// Don't report anything until we have a meaningful progress
var (
headerBytes , _ = d . stateDB . AncientSize ( rawdb . ChainFreezerHeaderTable )
bodyBytes , _ = d . stateDB . AncientSize ( rawdb . ChainFreezerBodiesTable )
receiptBytes , _ = d . stateDB . AncientSize ( rawdb . ChainFreezerReceiptTable )
)
syncedBytes := common . StorageSize ( headerBytes + bodyBytes + receiptBytes )
if syncedBytes == 0 {
return
}
var (
header = d . blockchain . CurrentHeader ( )
2023-03-02 08:29:15 +02:00
block = d . blockchain . CurrentSnapBlock ( )
2023-02-21 12:17:34 +02:00
)
2023-03-02 08:29:15 +02:00
syncedBlocks := block . Number . Uint64 ( ) - d . syncStartBlock
2023-02-21 12:17:34 +02:00
if syncedBlocks == 0 {
return
}
// Retrieve the current chain head and calculate the ETA
2023-02-23 13:22:41 +02:00
latest , _ , _ , err := d . skeleton . Bounds ( )
2023-02-21 12:17:34 +02:00
if err != nil {
// We're going to cheat for non-merged networks, but that's fine
latest = d . pivotHeader
}
if latest == nil {
// This should really never happen, but add some defensive code for now.
// TODO(karalabe): Remove it eventually if we don't see it blow.
log . Error ( "Nil latest block in sync progress report" )
return
}
var (
2023-03-02 08:29:15 +02:00
left = latest . Number . Uint64 ( ) - block . Number . Uint64 ( )
2023-02-21 12:17:34 +02:00
eta = time . Since ( d . syncStartTime ) / time . Duration ( syncedBlocks ) * time . Duration ( left )
2023-03-02 08:29:15 +02:00
progress = fmt . Sprintf ( "%.2f%%" , float64 ( block . Number . Uint64 ( ) ) * 100 / float64 ( latest . Number . Uint64 ( ) ) )
2023-02-21 12:17:34 +02:00
headers = fmt . Sprintf ( "%v@%v" , log . FormatLogfmtUint64 ( header . Number . Uint64 ( ) ) , common . StorageSize ( headerBytes ) . TerminalString ( ) )
2023-03-02 08:29:15 +02:00
bodies = fmt . Sprintf ( "%v@%v" , log . FormatLogfmtUint64 ( block . Number . Uint64 ( ) ) , common . StorageSize ( bodyBytes ) . TerminalString ( ) )
receipts = fmt . Sprintf ( "%v@%v" , log . FormatLogfmtUint64 ( block . Number . Uint64 ( ) ) , common . StorageSize ( receiptBytes ) . TerminalString ( ) )
2023-02-21 12:17:34 +02:00
)
log . Info ( "Syncing: chain download in progress" , "synced" , progress , "chain" , syncedBytes , "headers" , headers , "bodies" , bodies , "receipts" , receipts , "eta" , common . PrettyDuration ( eta ) )
d . syncLogTime = time . Now ( )
}