My unified nix flake for all configuration management.
- Nix 72.2%
- Rust 13.6%
- Shell 7.3%
- Python 3.2%
- TypeScript 1.8%
- Other 1.9%
b729310fe4
The free-space reclaim floor was a flat 20%, which is warnCapacity's 80% restated as free space. A pruner that succeeded exactly as designed therefore parked rpool ON the warn line, and zpool-capacity-alert paged every 15 minutes about the pruner's own target. Observed 2026-08-31: rpool at 80% with the guest healthy, exactly the three configured pre-deploy points kept, the daily trim reporting 100% trimmed, and prune-cutover-snapshots green every night since Aug 25 -- every mechanism correct, and a page anyway. That is the shape of alert an operator learns to wave through, which is the outcome the guard exists to prevent (see the 2026-08-16 and 2026-08-28 pool-full outages). Derive the floor from warnCapacity plus a margin rather than writing the two numbers side by side, so moving the warn line moves the floor with it and they cannot drift back into agreeing. Two assertions carry the invariants: a completed reclaim leaves the pool below warn, and the floor still stays clear of the critical line. Alternative not taken: raising warnCapacity to 85. That keeps the two numbers independent, so the same collision returns the next time either is tuned, and it gives up the 80% signal for the reason it was chosen -- ZFS's allocator falls back to best-fit there and write latency climbs. Tested with nix eval of nixosConfigurations.battleship, which evaluates the assertions. |
||
|---|---|---|
| .forgejo/workflows | ||
| .helix | ||
| dotfiles | ||
| issues | ||
| lib | ||
| packages | ||
| prototypes/beefcake-impermanence | ||
| secrets | ||
| .envrc | ||
| .gitignore | ||
| .sops.yaml | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| flake.lock | ||
| flake.nix | ||
| readme.md | ||
| run-claude-sandbox.sh | ||
