OP-Geth Disk Usage Keeps Growing Uncontrollably: Path Scheme Not Auto-Pruning, Hash Scheme Manual Pruning Not Supported

[DanchuoZhong]

Are you running the most up to date node software?

• Yes

Did you check the documentation?

• Yes

Did you check for duplicate questions?

• Yes

Issue Description

I'm experiencing severe disk usage growth issues when running an Optimism Full Node. Neither State Scheme can effectively control disk usage.

Problem 1: Path Scheme Not Auto-Pruning

I initially ran the node with --state.scheme=path configuration. According to the documentation, Path Scheme should automatically prune state in the background, keeping disk usage within a reasonable range (approximately 300-400GB).

However, the actual situation is:

• After running for several weeks, disk usage continued to grow
• No signs of automatic reclamation or pruning were observed

Actual monitoring data (Path Scheme):

===== 2026-01-17 17:42:35 =====
451M    /optest/store/op-geth/geth/chaindata/ancient/state
590G    /optest/store/op-geth/geth/chaindata/ancient/chain
590G    /optest/store/op-geth/geth/chaindata/ancient
989G    /optest/store/op-geth/geth/chaindata/

===== 2026-02-24 17:00:01 =====
4.5G    /optest/store/op-geth/geth/chaindata/ancient/state
619G    /optest/store/op-geth/geth/chaindata/ancient/chain
623G    /optest/store/op-geth/geth/chaindata/ancient
1.1T    /optest/store/op-geth/geth/chaindata/

Questions:
Why does disk usage keep growing instead of stabilizing at a certain value?Is Path Scheme's automatic pruning mechanism actually working?Is there specific configuration required to trigger automatic reclamation?

---

Problem 2: Hash Scheme Does Not Support Manual Pruning

When I found that Path Scheme couldn't control disk growth, I tried switching back to Hash Scheme and planned to perform manual pruning periodically. However, when I attempted to execute offline pruning, I encountered an unexpected error.

Error message received:

CRIT [02-26|10:17:27.505] Offline pruning is not required for path scheme

This is weird because i start op-geth in hash
Actual monitoring data (Hash Scheme):

{"timestamp":"2026-02-25 15:59:31","total_human":"1.10TB","ancient_human":"611.10GB","recent_human":"519.48GB"}
{"timestamp":"2026-02-25 16:00:01","total_human":"1.10TB","ancient_human":"611.63GB","recent_human":"519.48GB"}
{"timestamp":"2026-02-25 17:00:01","total_human":"1.11TB","ancient_human":"619.19GB","recent_human":"521.16GB"}
{"timestamp":"2026-02-25 18:00:01","total_human":"1.11TB","ancient_human":"619.23GB","recent_human":"521.12GB"}
{"timestamp":"2026-02-25 19:00:01","total_human":"1.11TB","ancient_human":"619.26GB","recent_human":"521.29GB"}
{"timestamp":"2026-02-25 20:00:01","total_human":"1.11TB","ancient_human":"619.28GB","recent_human":"521.48GB"}
{"timestamp":"2026-02-25 21:00:01","total_human":"1.11TB","ancient_human":"619.31GB","recent_human":"521.57GB"}
{"timestamp":"2026-02-25 22:00:01","total_human":"1.11TB","ancient_human":"619.34GB","recent_human":"521.76GB"}
{"timestamp":"2026-02-25 23:00:01","total_human":"1.11TB","ancient_human":"619.37GB","recent_human":"521.96GB"}
{"timestamp":"2026-02-26 00:00:01","total_human":"1.11TB","ancient_human":"619.41GB","recent_human":"522.14GB"}
{"timestamp":"2026-02-26 01:00:01","total_human":"1.11TB","ancient_human":"619.44GB","recent_human":"522.42GB"}
{"timestamp":"2026-02-26 02:00:01","total_human":"1.11TB","ancient_human":"619.47GB","recent_human":"522.65GB"}
{"timestamp":"2026-02-26 03:00:01","total_human":"1.11TB","ancient_human":"619.50GB","recent_human":"523.00GB"}
{"timestamp":"2026-02-26 04:00:01","total_human":"1.11TB","ancient_human":"619.53GB","recent_human":"522.86GB"}
{"timestamp":"2026-02-26 05:00:01","total_human":"1.11TB","ancient_human":"619.56GB","recent_human":"523.12GB"}
{"timestamp":"2026-02-26 06:00:01","total_human":"1.11TB","ancient_human":"619.59GB","recent_human":"523.41GB"}
{"timestamp":"2026-02-26 07:00:02","total_human":"1.11TB","ancient_human":"619.62GB","recent_human":"523.75GB"}
{"timestamp":"2026-02-26 08:00:02","total_human":"1.11TB","ancient_human":"619.66GB","recent_human":"524.07GB"}
{"timestamp":"2026-02-26 09:00:02","total_human":"1.11TB","ancient_human":"619.69GB","recent_human":"524.38GB"}
{"timestamp":"2026-02-26 10:00:02","total_human":"1.11TB","ancient_human":"619.71GB","recent_human":"524.67GB"}

This means:

• ❌ Hash Scheme: Official statement says offline pruning is "not supported for path scheme"
• ❌ Path Scheme: Official statement says offline pruning is "not required" (due to automatic reclamation)

Steps to Reproduce

I follow the instruction in https://docs.optimism.io/node-operators/tutorials/node-from-docker, and modify the start-op-geth.sh in /script:

# Start op-geth.
exec geth \
  --datadir="$BEDROCK_DATADIR" \
  --http \
  --http.corsdomain="*" \
  --http.vhosts="*" \
  --http.addr=0.0.0.0 \
  --http.port=8545 \
  --http.api=web3,debug,eth,txpool,net,engine \
  --ws \
  --ws.addr=0.0.0.0 \
  --ws.port=8546 \
  --ws.origins="*" \
  --ws.api=debug,eth,txpool,net,engine,web3 \
  --syncmode="$OP_GETH__SYNCMODE" \
  --gcmode="$NODE_TYPE" \
  --authrpc.vhosts="*" \
  --authrpc.addr=0.0.0.0 \
  --authrpc.port=8551 \
  --authrpc.jwtsecret=/shared/jwt.txt \
  --rollup.sequencerhttp="$BEDROCK_SEQUENCER_HTTP" \
  --rollup.disabletxpoolgossip=true \
  --port="${PORT__OP_GETH_P2P:-39393}" \
  --discovery.port="${PORT__OP_GETH_P2P:-39393}" \
  --db.engine=pebble \
  --state.scheme=hash \    # or path
  --history.state=5000 \
  --history.transactions=30000 \
  $EXTENDED_ARG $@

This is how i try to prune in hash scheme：

docker run --rm -v /optest/store/op-geth:/geth us-docker.pkg.dev/oplabs-tools-artifacts/images/op-geth:v1.101603.5 snapshot prune-state --datadir=/geth
INFO [02-26|10:17:10.795] Maximum peer count ETH=50 total=50
INFO [02-26|10:17:10.797] Smartcard socket not found, disabling err="stat /run/pcscd/pcscd.comm: no such file or directory"
INFO [02-26|10:17:10.799] Set global gas cap cap=50,000,000
INFO [02-26|10:17:10.800] Initializing the KZG library backend=gokzg
INFO [02-26|10:17:10.829] Using pebble as the backing database
INFO [02-26|10:17:10.829] Allocated cache and file handles database=/geth/geth/chaindata cache=512.00MiB handles=524,288
INFO [02-26|10:17:27.502] Opened ancient database database=/geth/geth/chaindata/ancient/chain readonly=false
INFO [02-26|10:17:27.502] Opened Era store datadir=/geth/geth/chaindata/ancient/chain/era
CRIT [02-26|10:17:27.505] Offline pruning is not required for path scheme

Which component is affected?

• op-geth
• op-node
• Other

Expected vs. Actual Behavior

Expecte the disk usage of op-geth will be stable , but usage keep going up and the pruning seems not work in data both hash/path scheme.

Environment Details

Ubuntu 22.04
Model name: Intel(R) Xeon(R) Platinum 8575C
CPU(s): 4
Memory:
free -h
total used free shared buff/cache available
Mem: 30Gi 8.2Gi 312Mi 145Mi 22Gi 23Gi
Swap: 0B 0B 0B

Protocol Information

CONTAINER REPOSITORY TAG IMAGE ID SIZE
simple-optimism-node-bedrock-init-1 simple-optimism-node-bedrock-init latest cb8655ecf7ba 1.44GB
simple-optimism-node-healthcheck-1 ethereumoptimism/replica-healthcheck latest b0a2d1a00d50 3.91GB
simple-optimism-node-op-geth-1 us-docker.pkg.dev/oplabs-tools-artifacts/images/op-geth v1.101603.5 98a8cd504f1b 69.8MB
simple-optimism-node-op-node-1 us-docker.pkg.dev/oplabs-tools-artifacts/images/op-node v1.16.2 1917c778cdab 81.3MB

Node Logs

No response

Troubleshooting Attempts

No response

Additional Information

No response

Feedback

No response

[sueun-dev]

I think two different things are getting mixed together here.

From the du numbers you posted, the part that is really growing is ancient/chain.

• ancient/chain: 590G -> 619G
• ancient/state: 451M -> 4.5G

That looks more like normal chain history growth than failed path-state pruning.

state.scheme=path prunes state history. It does not keep the whole datadir flat. Block history, receipts, ancients, and indexes can still grow.

In current op-geth, the flag text for --history.state says it is only relevant for state.scheme=path, with a default of 90,000 recent blocks retained. So path mode does have a pruning knob, but it is about state history, not all disk usage.

The second issue is the offline prune error.

In current op-geth (cmd/geth/snapshot.go on dbb4aa0), snapshot prune-state does this:

if rawdb.ReadStateScheme(chaindb) != rawdb.HashScheme {
    log.Crit("Offline pruning is not required for path scheme")
}

So that command is checking the scheme already stored on disk, not the flag you passed for this run.

Also, core/rawdb/accessors_trie.go reuses the stored scheme and rejects incompatible switches. So if this datadir was created as path, starting with --state.scheme=hash later does not convert it into a hash DB.

So my read is:

1. Path mode is probably working.
2. The growth you are seeing is mostly chain history growth, not state trie growth.
3. The hash prune attempt is still pointed at a path-scheme database, so --state.scheme=hash by itself is not enough.

If you want to confirm that, keep comparing these separately over time:

• geth/chaindata/ancient/chain
• geth/chaindata/ancient/state
• geth/chaindata

If ancient/chain is the one rising, the issue is storage planning / history retention, not missing path pruning.

If you want to test true hash-mode offline pruning, do it with a fresh datadir that was synced with --state.scheme=hash from the start. For the path setup, the more relevant flag is --history.state, not snapshot prune-state.

[DanchuoZhong]

Thank you for the clarification. However, I still have several unresolved concerns:

1. Regarding Hash mode offline pruning:

• I did start with a fresh datadir synced from scratch using --state.scheme=hash
• After sync completed, I stopped the node and ran geth snapshot prune-state --datadir /geth
• The pruning command still returned: Fatal: Offline pruning is not supported for hash-based scheme
• This suggests that even with a fresh hash-mode database, offline pruning doesn't work in current op-geth

2. Regarding --history.state flag:

• I've tested with --history.state=90000 (default) in both path and hash modes
• I also tried smaller values like --history.state=10000
• In both cases, I didn't observe any effective control over disk growth
• The total disk usage continued to grow regardless of this setting

3. Regarding ancient/chain growth - This is my main concern:

• Initial sync completed at ~350GB (January 17)
• After 38 days, total size reached 1.1TB (February 24)
• Now (March 2026), it has grown to 1.3TB and continues growing
• The ancient/chain component specifically grew from 590GB to 619GB in 38 days, and is still growing

My core questions are:

• How can I control ancient/chain growth? Is there a flag or configuration to limit block history retention?
• Is periodic re-syncing the only solution? How are other Full Node operators handling this?