memory: snapshot — Ada destination pool is smaller than the source

Measured irv-ml1's storetank against the R750xa's as-bought drives while
answering comfy-dev's "does the Ada box have ZFS?" question.

- storetank: 1.81 TiB pool, 1.45 TiB used, 80% CAP already, compression
  off at compressratio 1.00x (safetensors incompressible — no win at
  recv). comfy-dev's ~112 GB batch is landing into it now.
- The R750xa shipped 2x 1.92 TB SATA SSD; mirrored that is ~1.74 TiB,
  smaller than the pool it receives from. Migration would arrive at
  ~90% full with no growth room.
- Buy list: +2x 2 TB SATA SSD (6 bays free, HBA355i has the ports) ->
  two mirror vdevs striped, ~3.49 TiB at ~45%, redundancy intact.
- Retain vs reclaim irv-ml1's /storetank after cutover: RETAIN
  recommended, surfaced to the operator.

Also corrects branch (b)'s recorded rationale. comfy-dev enumerated all
twelve running containers: only comfyui mounts /storetank, so (b) was
unavailable during the transition, not structurally. Right conclusion,
wrong reason — infra-ops reasoned about the box when the question was
about the mount.

Memory-only; no version bump per the SemVer SKIP list.
This commit is contained in:
vh
2026-09-01 17:06:32 -07:00
parent ace839c768
commit 72065b45aa
3 changed files with 101 additions and 16 deletions
@@ -73,6 +73,21 @@ The HBA355i (PCIe 4.0 x8) is nowhere near limiting. **Drives are the constraint.
256 GB restored, ZFS ARC caches most of the working set at RAM speed. The RAM upgrade is
both cheaper and likely faster than four more SATA drives.
⚠ **CAPACITY, not throughput, is the binding constraint — the as-bought drives are SMALLER
than the pool they receive from** (measured 2026-09-01). ComfyUI's `/storetank` on irv-ml1 is
a 2x 2 TB mirror: SIZE **1.81 TiB**, ALLOC **1.45 TiB**, CAP **80%**, and growing as
comfy-dev's ~112 GB batch lands (-> ~1.56 TiB). The R750xa's 2x **1.92 TB** mirrored is only
**~1.74 TiB** — the migration would arrive at **~90% full** with zero growth room, past the
~80% line where ZFS allocation degrades. Compression buys nothing: safetensors measured
`compressratio 1.00x`, `logicalused == used`.
**-> Add 2x 2 TB SATA SSD to the buy list.** Six of eight bays free, HBA355i has the ports;
two mirror vdevs striped = **~3.49 TiB at ~45%**, redundancy intact. Cheapest line on this
buy list and it does not gate the cutover window. The no-spend alternative is striping the
as-bought pair (same ~3.49 TiB, **no redundancy**) — only acceptable if irv-ml1 retains its
copy, which makes retain a requirement rather than a recommendation.
→ [[2026-09-01-ada-migration-branch-a]]
**UNCHECKED, and it may moot the whole bay question:** free PCIe slots. Riser Config 0 is
`330-BBUM : Riser Config 0, 6x16 + 2x8 slots`; two double-wide GPUs will not consume all of
it. An NVMe add-in card (U.2 HBA or bifurcating M.2 carrier) bypasses the SAS/SATA backplane
@@ -98,12 +113,16 @@ circuit this lands on before racking, not after.**
|---|---|---|
| RDIMM 16 GB 3200 2Rx8 | **`M04W6`** | **8** → restores 256 GB, all 16 slots, all 8 channels/socket |
| NVIDIA 12VHPWR adapter | **`930-00030-1546-000`** | **2** |
| 2 TB SATA SSD (any; match/exceed the MX500s) | — | **2** → pool ~3.49 TiB at ~45%; without it the migration lands at ~90% |
**Only if the iDRAC inventory shows them absent:** `12XPY`, `9TR6X`, `4RW1P`, `W4K7M`,
`XC48N`, `6C77X`, `CP67W`, `CXYF8`, `H4D7D`, `N61TK`, `HXJDR`, `W1P56`, `C2JNP`,
`FD00R` ×6.
**Spend order:** RAM → check PCIe slots → only then consider more SATA drives.
**Spend order:** RAM → **2 SATA SSDs (now certain, capacity-driven)** → check PCIe slots →
only then consider filling the remaining bays. (The original order deprioritised drives on a
*throughput* argument, which still holds; the drives are now on the certain list for
**capacity**, which is a different axis.)
⚠ Dell's Installation & Service Manual publishes **no part numbers at all** for GPU kit
hardware — names and quantities only. The factory CSV keyed to the service tag is the only