--- name: test-profile-pool-outgrows-the-disk-floor description: "A cold nextest leg on hfenduleam wrote ~55 GiB past the 32 GiB floor read and filled the disk mid-suite — a 109 GB test-profile pool; treat the floor as a refusal line, not headroom, and reap before the nextest leg" metadata: node_type: memory type: project originSessionId: 0f1cd318-0505-4e70-8849-c30b62254099 modified: 2026-09-07T01:56:50.241Z --- Measured 2026-09-07 (W1 #249, tip 8d980fdf, hfenduleam): the driver's floor read before the nextest leg said `free_gib=55` (floor 32) and PASSED; the test-profile build then grew the pool `.worktrees/ws272-w1/target` to **109 GB** and the disk hit 0.5 GB free at test 1127/3026. The suite died inside tests with `No space left on device` (git worktree add, temp homes), no Summary line, and the driver could not even write `nextest.exit` — a VOID leg with 5 reds that were all disk. `ws272-w0/target` (my finished W0 lane) sat beside it at 83.6 GB. **Why:** `xtask disk-floor` is the same 32 GiB floor at every leg; it guards the CURRENT read, not the leg's own footprint. A cold `nextest` of the four-package population costs ~60–70 GB on top of the dev-profile prebuild, so a PASS at 55 GiB is a fill in waiting. **How to apply:** before the nextest leg, want ~80 GB free, not 32: reap the previous lane's pool first (classify: outbound kind, inbound reparse sweep, live procs by exe path, measure before/after), or refuse the leg. Two lanes' pools on one box (~190 GB) is the shape that fills a 250 GB drive. Infra fix belongs in INFRA-REGISTER (a per-leg floor; the nextest leg's own). Related: [[kitsubito-remote-launch-traps]] (the Linux side has 400+ GB and never sees this). 2026-09-08 face (hertz) — THE FLOOR CHECK IS MEASURING THE WRONG INSTANT, and today gave the supporting datum. I measured 104 GB free at 10:57Z; an hour later todlando measured 39.3 GB before reaping — the box fell ~65 GB while a cold workspace build, a clippy, and a CI run overlapped. So 39.3 GB was not "getting low" in the abstract: it was BELOW the level that has already voided a leg here (2026-09-07, floor PASS at 55 GiB, then the nextest leg grew the pool past it and filled the disk mid-suite — VOID leg, 5 disk reds, no exit file). The shape: **a floor checked at battery START answers a question about a pool that has not grown yet.** The nextest leg is the growth, so the check must be re-run IMMEDIATELY BEFORE that leg and against a floor that includes the leg's own expected growth, not merely today's free space. The 09-07 incident is the proof rather than the worry — that floor check PASSED and the run still died, which is exactly what a start-of-run check will always do when the consumer runs later. Two practical riders: on a shared box the number moves under you for reasons that are nobody's lane (a CI runner job here is invisible to every agent's own accounting), so a floor is a measurement with a short shelf life, not a property of the morning. And reaping a FINISHED lane's target is the cheap lever — classify with `Get-Item -Force` (reparse vs real), sweep INBOUND for links aimed at it, reap the target SUBTREE only, and print free-before/after so the reclaim is a number: 6.9 + 6.2 GB of landed-lane pools gave back 11.6 GB in under a minute today, with every raw and exit file beside them untouched. todlando's two numbers, same day, and they say WHERE the margin goes: a cold workspace pool for this tree reached **75 GB** (39.3 GB free at its peak), and the growth is concentrated in the **all-targets / test profile**, not the initial dependency build. So the dangerous instant is not "after deps compile" — it is immediately before the nextest leg, which is exactly the instant a start-of-battery floor check cannot see. doyle pinned the remedy for the next driver: floor 80 GB before the first nextest, re-read before each, refusing LOUDLY with the number rather than logging `free_gb` after the fact. --- **2026-09-09 face (hertz; slug prompted by deployah) — A NARROW FILTER IS NOT A CHEAP RUN, and this is the shape that fills the disk while you believe you are running five tests.** I ran `cargo nextest run --test-threads=1 --no-fail-fast -E "test(a) + test(b) + test(c) + test(d) + test(e)"` — five tests — in two worktrees. `-E` narrows the RUN. It does not narrow the BUILD: nextest reported `Starting 5 tests across 221 binaries (3418 tests skipped)`, and the pools reached **82.88 GiB** and **64.44 GiB** under the `test` profile. Two of them, plus 40.93 GiB of `C:\actions-runner\_work` and 9.8 GiB of `%TEMP%`, took hfenduleam from ~195 GiB free to **0.018 GiB of 1862.02 (0.00%)**. Riders that cost real time today: - **`cargo build --tests` warms NOTHING for this.** It builds the dev profile; the nextest leg builds the `test` profile and pays the whole cost again inside the leg — 13m30s of build inside my rep 1. Budget the build as part of the LEG, not as a prior step you already paid. - **The failure this filled disk produced was not a build error.** It was a product-level refusal assertion inside a test ([[disk-full-reds-as-lnk1318-pdb-error]] third face), which routes to a code owner instead of to the box. - **Do not derive a rate from two free-space readings** (deployah, banked same day). Consumption ACCRUES across the whole build phase; endpoints 20 minutes apart bound nothing. A '>150 MB/s' derived that way sent a hunt after runaway logs, VSS and torrent preallocation while the measured live box-wide write rate was ~1.5 MB/s. His independent leg — top writer 0.57 MB/s over a ~15 s sample — established "no mystery writer" before my attribution arrived, and two of his instruments lied on the way: cumulative `WriteTransferCount` named a 5-day-old browser at 188.7 GB (a cumulative counter cannot answer an interval question, and the magnitude coincidence with the missing ~195 GiB is what sells it), and `Get-Process WriteTransferCount` came back BLANK in his shell, which would have cleared every process on the box. CIM carries the real numbers. - **Reclaim, as measured:** 81.87 and 63.32 GiB actual against 82.88 / 64.44 Length-sums — 1.2% and 1.8% over, the hardlink gap, instances 3 and 4. `pool-release` first with a PREBUILT xtask, never `cargo run` ([[pool-release-rebuilds-xtask-into-the-pool-you-just-reaped]]). So the floor question this file already asks — 80 GB before the first nextest — has a second term: **per LANE, and a lane's filter does not reduce it.** Two lanes of a 5-test filter is a ~150 GiB commitment.