1

My understanding of Geth's trie pruning is based off this geth v1.8 release blog post: https://blog.ethereum.org/2018/02/14/geth-1-8-iceberg%C2%B9/

Trie pruning is enabled on all --syncmode variations (including --syncmode=full). If you are running an archive node where you would like to retain all historical data, you should disable pruning via --gcmode=archive

But how many trie nodes persisted to disk, are the trie nodes on disk also garbage-collected? This next quote doesn't make it any clearer

Geth v1.8.0 takes an initial stab at the problem by introducing an in-memory cache in which to store the recent trie nodes. As long as the nodes are in memory, they are cheap to reference count and garbage collect. Instead of writing each trie node to disk, we keep it around as long as possible, hoping that a future block will make it obsolete and save us a database write.

I started 2 Geth v1.8.17 nodes to try and understand:

--syncmode=full finished with ~113GB and a couple days later is ~134GB

--syncmode=fast also finished with ~113GB and a couple days later is also ~134GB

  • But how many trie nodes will it keep on disk? If it finished syncing around ~113GB and is now ~134GB just ~1.5 days later, then does that mean it's currently storing 134-113=21GB worth of trie nodes on disk?
  • If the state is ~7GB, then is the total state storage equal to the number of trie nodes * 7GB? (i.e. if we store 1500 trie nodes than do we have 10TB of disk? I know this isn't true, so what am I missing)?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.