felhom.eu/documentation/audits/storage-identity-buildB-2026-10-15/SPACE-CHECK.md

Storage identity build B, Part 1 — the D3 space check (2026-10-15)

Design: architecture/16-storage-physical-identity.md §5, §7 (D3 ruled „as recommended, check the space"). Question: how big must the guest's data volume (mp0) and the thin-pool reserve be, so that the one-disk internal data place („Belső tárhely") gets as much as is safe? Status: PROPOSAL — waits for the operator's „ok" or other numbers. Method: read-only measurement on every box we can read (space/*.txt), the registry manifests of every catalog image (space/catalog-images.txt), the hub's latest host reports (space/hub-fleet-storage.txt, database copied with its WAL), and one whole-box copy on Tester 1 with the thin pool sampled every 2 s (space/tester1-pool-during-wholebox-copy.txt).

1. What the boxes really use

Box	Disk	Thin pool	mp0 size	mp0 used	of which images	volumes	Tier-1 in mp0	Apps
demo-hp	128 GB SATA	54 GiB	70 GiB	18.2 GB	14.8 GB (4.2 GB old, reclaimable)	1.4 GB	1.1 GB	21
Tester 1 (VM)	200 GB virtual	113 GiB	70 GiB	7.9 GB	7.0 GB	0.6 GB	0.2 GB	17
9202 scratch	file on NVMe	—	70 GiB	10.6 GB	9.1 GB	1.3 GB	0.1 GB	10
N100	512 GB SATA	349 GiB	250 GiB	2.4 GB	2.3 GB	0.07 GB	0	9
Tester 2 (hub)	512 GB	349 GiB	250 GiB	pool 7.2 GiB used	—	—	—	—
Tester4 OMV VM (hub)	VM disk	113 GiB	—	pool 6.1 GiB used	—	—	—	—

The guest root (rootfs, 32 GiB) uses 1.1–1.3 GB on every box.

Full catalog: 63 installable apps (plant-it and wger are not offered), 84 images. Distinct layers, compressed: 22.6 GB. On disk an image takes 2.43× its compressed size (17 installed images: 3.1 GB → 7.5 GB; range 1.6–3.4×). So the whole catalog's images ≈ 55 GB on disk. Largest: gramps-web 2.6 GB compressed, cal.com 1.8, OnlyOffice 1.3, Immich 1.2. Running all 63 apps at once needs ≈ 22 GB of memory (audits/sizing-2026-10-13/SIZING.md), so only a 32 GB box can — a 256 GB box (8 GB memory) runs roughly 10–15 apps.

mp0 for the whole catalog: images 55 + volumes ≈ 5 + Tier-1 of apps with no drive ≈ 3 + an update (old and new image of the largest app side by side) ≈ 6 + old images not yet cleaned ≈ 5 → ≈ 74 GB. For a heavy real household (demo-hp, 21 apps): 18 GB.

2. What the reserve is for (measured)

• A whole-box copy's snapshot: Tester 1, apps running, 8.7 GiB copied in 2 min → the pool went 12.05 % → 12.06 % (≈ 12 MB). The snapshot costs almost nothing.
• An update's image pull lands inside mp0 — mp0's size covers it, not the reserve.
• The restore test restores a whole guest into the pool: it needs free ≈ the guest's used size (3.5–19.5 GB measured; ≈ 75 GB for a full-catalog box). It sizes itself and refuses what does not fit (A19) — a too-small reserve costs a skipped proof, never a full pool.
• Why the reserve must exist at all: thin volumes are promised more than the pool holds (demo-hp today: 102 GiB promised on a 54 GiB pool). That is safe only while use stays low. The internal place will hold films and will be filled, so the sizes below never promise more than pool − reserve. A pool at 100 % stops every volume on the box.

3. The host root (Proxmox local)

The Proxmox installer sets it (the public ISO has no answer file); measured 39.5 GiB on a 128 GB disk, 59.8 on 200 GB, 96 on 512 GB. Proxmox itself uses ≈ 13 GB (/usr 7, logs 4). The local whole-box copies are 0.3–0.4 × the guest's used size (5.4 GB for demo-hp's 18 GB; 3.1 GB for Tester 1's 8 GB), three kept plus one while a new one is written. They do not grow with the internal place (a host mount, outside the copy — to be shown live in Part 2). Can the root be smaller on a one-disk box? No change proposed: the Felhom installer runs after Proxmox and cannot shrink an ext4 root; a realistic household needs ≈ 13 + 4 × 7 ≈ 41 GB, which fits all three measured sizes; a heavy box already meets R-548 (the copy is skipped by name, R-685). Shrinking it would only bring R-548 to more boxes.

4. The proposal

Rules: rootfs 32 GiB (the golden's; unchanged). mp0: 50 GiB (pool < 300), 100 GiB (300–800), 130 GiB (≥ 800). Reserve: max(16 GiB, 10 % of the pool), at most 48 GiB. Internal place = pool − 32 − mp0 − reserve, made only when ≥ 20 GiB. Nothing promised beyond pool − reserve.

Disk	Thin pool (GiB)	mp0 today / design / proposed	Reserve design / proposed	Internal place design / proposed
256 GB	≈ 140 (estimate from 128 GB and 200 GB measured)	70 / 70 / 50	16 / 16	22 / ≈ 42
512 GB	349 (N100, Tester 2 measured)	250 / 130 / 100	35 / 35	152 / ≈ 182
1 TB	≈ 800 (estimate)	250 / 250 / 130	80 / 48	438 / ≈ 590
2 TB	≈ 1,720 (estimate)	250 / 250 / 130	172 / 48	1,266 / ≈ 1,510

Why each number:

• mp0 50 on a 256 GB box: 2.7× the heaviest measured household (18 GB); the whole catalog (74 GB) does not fit, but an 8 GB box cannot run it either. 100 on 512 GB: the whole catalog with ≈ 35 % spare. 130 from 1 TB: the same plus room for the catalog to grow. The design's 250 is 3× the whole catalog — space a household never reaches.
• mp0 is the number to be careful with: a full mp0 refuses app backups and stops Docker (C15), and growing it later means shrinking the internal place, which ext4 cannot do online. So mp0 errs high; the reserve does not need to.
• Reserve cap 48 GiB: it covers a restore test of every measured box twice over; beyond it the reserve only withholds the household's space (172 GiB on 2 TB for a 12 MB snapshot).

Not decided here: the guest root's 32 GiB (uses ≈ 1.3) is the golden's; shrinking it is a golden change, not this task.

5. Also found (filed)

• R-1087 — the N100's host root still holds three whole-box copies from 2026-07-28 (≈ 16.8 GB); its copies go to the USB disk since then, and nothing prunes the old target.
• R-1088 — CC's credentials file was overwritten during this session (by another session's credential-reader call), and this session printed the hub token once while checking the file's shape.