Skip to content

docs(hardware): freeze v3.4 disk sizes as static values - #22583

Closed
bloxster wants to merge 1 commit into
release/3.5from
docs/restore-disk-sizes-jun2026
Closed

docs(hardware): freeze v3.4 disk sizes as static values#22583
bloxster wants to merge 1 commit into
release/3.5from
docs/restore-disk-sizes-jun2026

Conversation

@bloxster

@bloxster bloxster commented Jul 19, 2026

Copy link
Copy Markdown
Collaborator

What

Freezes the v3.4 versioned hardware-requirements page to static, 3.4-era measured disk sizes, and removes its disk-sizes.json import.

Why

The v3.4 versioned page imported the shared, live @site/src/data/disk-sizes.json. Since the site deploys from release/3.5, that file holds the current (Sep 2025) values — so /v3.4/get-started/hardware-requirements rendered those instead of the values measured for the 3.4 release. Versioned docs are frozen snapshots, so their disk sizes should be static (the Polygon rows on this page are already hardcoded for the same reason).

Values frozen (measured by syncing a node per prune mode)

mainnet gnosis
archive 2.03 TB 605 GB
full (default) 1.2 TB 645 GB
minimal 360 GB 186 GB

Scope / follow-ups

  • Only touches versioned_docs/version-v3.4/.... The shared disk-sizes.json is untouched.
  • The current (v3.5) page keeps reading the live JSON and will be updated with freshly-measured 3.5 values in a separate PR (mainnet re-measured: archive 2.03 TB, full ~421 GB, minimal ~380 GB; gnosis pending its sync).
  • A durable fix so this doesn't recur at the next version cut (v3.6) is under discussion.

Note: v3.5 full (~421 GB) is genuinely smaller than v3.4 full (1.2 TB) — a real version-over-version reduction, which is why each version keeps its own measured numbers.

Verification

  • python3 docs/site/scripts/generate-llms.py --check — OK (4 llms files, 74 pages).
  • npm run build — production build succeeds.

🤖 Generated with Claude Code

The v3.4 versioned hardware-requirements page imported the shared,
live src/data/disk-sizes.json, so it rendered whatever the deploy
branch (release/3.5) currently holds (the Sep 2025 values) instead
of the values measured for the 3.4 release.

Freeze the v3.4 "Current Disk Usage" column to the 3.4-era measured
values (each obtained by syncing a node per prune mode) and drop the
now-unused JSON import, matching how Polygon is already frozen on this
page. Versioned docs are frozen snapshots, so static values are the
correct representation.

  mainnet: archive 2.03 TB, full 1.2 TB, minimal 360 GB
  gnosis:  archive 605 GB, full 645 GB, minimal 186 GB

The current (v3.5) page keeps reading the live JSON and will be
updated with freshly measured 3.5 values separately.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@bloxster
bloxster force-pushed the docs/restore-disk-sizes-jun2026 branch from eda7c98 to 009b709 Compare July 19, 2026 16:15
@bloxster bloxster changed the title docs(hardware): restore Jun 2026 disk-size values on release/3.5 docs(hardware): freeze v3.4 disk sizes as static values Jul 19, 2026
@bloxster

Copy link
Copy Markdown
Collaborator Author

Superseded by #22596. That PR makes disk sizes static site-wide (Option C from the adversarial review) and folds in this v3.4 freeze as part of a self-consistent change (static current page + static versioned pages + fail-closed CI guard).

@bloxster bloxster closed this Jul 20, 2026
@bloxster
bloxster deleted the docs/restore-disk-sizes-jun2026 branch July 20, 2026 09:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant