erigontech / erigontech/erigon
docs: hardware-requirements table inconsistencies (minimal > full disk, stale rows under a fresh footnote date, RAM Required/Recommended anomalies)
- Dominant language
- Go
- Stars
- 3.6k
- Forks
- 1.5k
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 455
Description
Found while cross-checking `docs/site/docs/get-started/hardware-requirements.mdx` against an internal field report of a mainnet validator running `--prune.mode=minimal` on a 32 GB RAM server (Ubuntu 24.04, Erigon + Caplin, datadir measured at ~477 GB on 2026-07-18).
Source file: `docs/site/docs/get-started/hardware-requirements.mdx`
Data file: `docs/site/src/data/disk-sizes.json`
Last refresh: 125dbf4fad787402f7d8ad74288f3441b1d619fd — "docs: August 2026 w35 — refresh disk sizes from 2026-08-23 sync"
---
### 1. Minimal now reports more disk than Full, on two networks
Current values in the source:
| Network | Archive | Full (Default) | Minimal |
|---|---|---|---|
| Ethereum mainnet | 2.03 TB | 419.04 GB | **478.40 GB** |
| Gnosis Chain | 673.59 GB | 220.10 GB | **304.67 GB** |
Minimal retains the least history, so it exceeding Full is counter-intuitive and the table offers no explanation. A reader choosing a pruning mode by disk budget gets the wrong answer.
Worth noting the internal field report independently measured **~477 GB** for mainnet minimal, which closely matches 478.40 GB. That suggests the minimal figure is real and **`full` is the number to re-verify** — see point 2.
Also relevant as prior art: #18166 ("Abnormal disk space growth with `--prune.mode=minimal`", 355 GB after sync → 1.1 TB after 2 months), closed as completed against milestone 3.4.0. Someone should confirm the current minimal figure is normal growth and not a recurrence of that.
### 2. The w35 refresh only updated the Minimal rows, but re-dated the whole table
Diff of 125dbf4fad on this file changed exactly four lines: the mainnet minimal value, the gnosis minimal value, and the two footnote dates.
- mainnet minimal: 378.97 GB → 478.40 GB
- gnosis minimal: 204.45 GB → 304.67 GB
- `ds-date:mainnet`: 2026-07-19 → 2026-08-24
- `ds-date:gnosis`: 2026-07-21 → 2026-08-24
Archive and Full were carried over untouched from the July measurement, yet the footnote now reads *"Current Disk Usage measured as of 2026-08-24"* for the entire table. Two of three rows per network are five weeks stale under a date that claims otherwise.
Suggested fix: either re-measure all rows per refresh, or make the date per-row rather than per-table.
### 3. RAM columns: Minimal recommends more than Full
| Pruning Mode | RAM (Required) | RAM (Recommended) |
|---|---|---|
| Archive | 32 GB | 64 GB |
| Full (Default) | 16 GB | 32 GB |
| Minimal | 16 GB | **64 GB** |
Minimal recommends double what Full does while retaining less history. If that is intentional, it needs a sentence explaining why; if not, it is a typo.
### 4. `RAM (Required): 16 GB` may assume swap that the page never mentions
The internal field report states that a **32 GB** mainnet minimal node was periodically OOM-killed and that initial sync could fail outright without a compressed-swap (ZRAM) device configured. If a 32 GB box needs swap to survive initial sync, `Required: 16 GB` with no swap caveat is optimistic — the page currently implies a bare 16 GB machine is sufficient.
Suggested fix: state whether the Required column assumes configured swap, and add a short note (or link) on swap/ZRAM for memory-constrained hosts.
### 5. "Kernel version > v4" understates the real constraint
The Overview table lists *"Kernel version > v4"* under Linux. The field report found the **default Ubuntu 24.04 GA kernel** — far newer than v4 — crashing under OOM pressure, and required the HWE kernel (`linux-generic-hwe-24.04`) for stability. The stated bar passes for a configuration that reportedly does not work.
### 6. Memory-tuning topics absent from the page
Not contradictions, but gaps a memory-constrained operator currently has to discover elsewhere:
- `GOMEMLIMIT` / `GOGC` — the primary lever for capping Erigon's footprint, unmentioned.
- `vm.max_map_count` — directly relevant to MDBX mmap; the page covers only filesystem choice and `noatime`.
- Peer counts (`--maxpeers`, `--caplin.max-peer-count`) as a memory/bandwidth trade-off — the Bandwidth section does not mention that peer count also costs RAM.
---
### Suggested scope
1. Re-measure Archive and Full; resolve or explain minimal > full.
2. Make the measurement date per-row, or refresh all rows together.
3. Confirm or correct the Minimal RAM (Recommended) = 64 GB figure.
4. Clarify whether RAM (Required) assumes swap; link swap/ZRAM guidance.
5. Tighten the kernel-version guidance beyond "> v4".
Contributor guide
Assessment
This issue has not been assessed yet.