With the size of full nodes rapidly growing, I'm looking for a way to split my chaindata across multiple hard drives. I have one internal 1TB SSD capable of syncing the chain, and then an internal HDD and an external SSD, each 1TB. My internal drive is rapidly filling up, so I'm interested in porting some of chaindata onto one of the other drives.

I'm using Geth (on Linux), though I would prefer this to be a client-agnostic question in case someone else has the same question while using a different client.


3 Answers 3


Geth has a freezer as of v1.9 https://blog.ethereum.org/2019/07/10/geth-v1-9-0/


Wouldn’t it be amazing if we didn’t have to waste so much precious space on our expensive and sensitive SSDs to run an Ethereum node, and could rather move at least some of the data onto a cheap and durable HDD?

With the v1.9.0 release, Geth separated its database into two parts (done by Péter Szilágyi, Martin Holst Swende and Gary Rong):

Recent blocks, all state and accelerations structures are kept in a fast key-value store (LevelDB) as until now. This is meant to be run on top of an SSD as both disk IO performance is crucial.

Blocks and receipts that are older than a cutoff threshold (3 epochs) are moved out of LevelDB into a custom freezer database, that is backed by a handful of append-only flat files. Since the node rarely needs to read these data, and only ever appends to them, an HDD should be more than suitable to cover it. A fresh fast sync at block 7.77M placed 79GB of data into the freezer and 60GB of data into LevelDB.

Freezer basics

By default Geth will place your freezer inside your chaindata folder, into the ancient subfolder. The reason for using a sub-folder was to avoid breaking any automated tooling that might be moving the database around or across instances. You can explicitly place the freezer in a different location via the --datadir.ancient CLI flag.

When you update to v1.9.0 from an older version, Geth will automatically being migrating blocks and receipts from the LevelDB database into the freezer. If you haven’t specified --datadir.ancient at that time, but would like to move it later, you will need to copy the existing ancient folder manually and then start Geth with --datadir.ancient set to the correct path.

Freezer tricks

Since the freezer (cold data) is stored separately from the state (hot data), an interesting question is what happens if one of the two databases goes missing?

If the freezer is deleted (or a wrong path specified), you essentially pull the rug from underneath Geth. The node would become unusable, so it explicitly forbids doing this on startup. If, however, the state database is the one delete, Geth will reconstruct all its indices based on the frozen data; and then do a fast sync on top to back-fill the missing state. Essentially, the freezer can be used as a guerrilla state pruner to periodically get rid of accumulated junk. By removing the state database, but not the freezer, the node will do a fast sync to fetch the latest state, but will reuse all the existing block and receipt data already downloaded previously.

You can trigger this via geth removedb (plus the --datadir and --datadir.ancient flags if you used custom ones); asking it to only remove the state database, but not the ancient database.

Be advised, that reindexing all the transactions from the ancient database can take over an hour, and fast sync will only commence afterwards. This will probably be changed into a background process in the near future.

  • 3
    For anyone else thinking "I'll be clever and use the default location for the 'ancient' database and just symlink it to a different disk": It doesn't work.
    – jlh
    Commented Feb 28, 2021 at 16:46
  • You can move the ancient database into separate disk volumes, which can be HDD. It shrinks the blockchain data directory approximately twice times lower. Use --datadir.ancient option.

  • You may delete sometimes your whole database and resync again. The new size after resync will be much lower - it is about 230 GB at the time of September 2020. Parity does this kind of pruning automatically. You may see the difference here: https://etherscan.io/chartsync/chaindefault


If you are trying to build an archive node you can follow some tricks outlined here: https://github.com/allada/bsc-archive-snapshot

This is for the binance chain, but it should also apply to ethereum or any other chain that uses geth.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.