admin
3eca98f135
gates / gates (push) Successful in 6m41s
Measured four boxes, the hub's five host reports, every catalog image's registry size and one whole-box copy's thin-pool use. Proposal: mp0 50/100/130 GiB, reserve max(16 GiB, 10 %) capped at 48 GiB -> the internal place about 42/182/590/1,510 GB for 256 GB/512 GB/1 TB/2 TB. STATUS D10 asks for the operator's ok. Claude-Session: https://claude.ai/code/session_012qRErfCoiTkvDK9N5XHbzb
85 lines
6.3 KiB
Markdown
85 lines
6.3 KiB
Markdown
# 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.
|