本文要点
- 同时盯 块用量 与 inode；小文件风暴常见于
node_modules、索引与日志分片。 - 把清理分成「可丢缓存 → 可重建产物 → 需审批数据」三层，避免脚本误删密钥或制品库缓存。
- 容器侧与宿主侧分开计量：
docker system df与 APFS 空闲要一起看，详见 Docker 生产排障手册。 - Webhook / 自托管 Runner 的磁盘尖峰常与并发任务相关，可与 OpenClaw 回调与 Runner 串联文 中的隔离与幂等策略一起评审。
df、df -i、统一日志与 CI 产物保留策略为准。1. 双顶：块设备与 inode
APFS 上「还剩几十 GB」却报 No space left on device，多半是 inode 或元数据压力 而非大块连续文件。Runner 上高频 culprits：每 job 一份的 Xcode DerivedData、未轮转的统一日志、npm/pip/Maven 本地仓库、以及把仓库 bind 进容器时复制出的海量小文件。告警建议拆两条：disk>85% 与 inode>85%（或文件计数代理），并在 Grafana / 企业微信里用不同颜色区分，避免值班只看容量条。
2. 分层清理：顺序即政策
第一层只动可再下载或可再构建的路径：语言包缓存、临时 /tmp job 目录、过期的 .xcresult 压缩包。第二层动可重建但耗时的：DerivedData、Docker BuildKit 缓存与悬空镜像——具体命令与边界可与上文 Docker 手册对齐。第三层才碰需变更单的持久卷与审计日志；与入站执行链相关的保留周期，可参考 OpenClaw Runner 文中的审计字段设计，避免「为腾盘删掉合规证据」。
| 层级 | 典型路径 / 对象 | 风险与动作 |
|---|---|---|
| L1 可丢 | 包管理器 cache、job workspace/tmp |
低；建议每 job finally 清理或独立临时卷 |
| L2 可重建 | DerivedData、Docker 层、模拟器运行时缓存 |
中；清前打标签或镜像版本号，避免正在跑的索引任务 |
| L3 需审批 | 制品缓存、审计日志、用户上传目录 | 高；走保留策略与法务周期，禁止夜间脚本一刀切 |
3. 容器层、统一日志与套餐边界
Docker 镜像层在 SSD 上呈叠加写入，多并行 build 会把 IOPS 与空闲块同时打穿；统一日志若未限制体积，几个月后单台 Runner 也能吃掉数 GB。把套餐内的 256 GB / 512 GB 当成「系统 + 工具链 + 滚动两周产物 + 15% 缓冲」来建模：缓冲耗尽时，不仅 CI 失败，Spotlight 与钥匙串维护也会变慢。将 log config、max-size 与宿主 newsyslog/aslmanager 策略写进镜像基线，比事后 rm -rf 便宜。
若同一台机既跑 Xcode 又跑容器化步骤，建议每周固定窗口跑一次「只读体检」：df -h、df -ih、按目录排序的 du -sh * 前几名，以及 docker system df；把结果 append 到只读对象存储或工单系统，便于对比「上周谁长大」，而不是磁盘红了才全员 grep。
4. 结语
好的 Runner 治理，是配额可观测 + 清理可重复 + 边界可解释：同一套数字既能给 SRE 告警，也能给采购看「为何下一档要升盘」。把本文分层表贴进 onboarding，新同事第一次值班就不会在 inode 上踩雷。
在云端 Mac mini 上，容量与性能更可预期
Apple Silicon 统一内存让 Xcode、模拟器与并行构建同时开跑时更不易因 swap 抖动而「假死」；macOS 上 APFS、统一日志与原生工具链语义一致，排障不必在 Linux 宿主与 macOS 客体之间来回翻译。独占云 Mac 能把磁盘 I/O 与 inode 压力从多租户邻居中隔离；M 系列能效高、体积小，7×24 长期跑 Runner 的总拥有成本常优于自购笔记本当构建机；Gatekeeper 与 SIP 也降低供应链被篡改面。
若你正在为 CI / 自托管 Runner 规划可观测的磁盘配额与清理 Runbook，kvmboot 云端 Mac mini M4 是目前性价比很高的起点——立即了解套餐方案，让 Derived Data 与容器缓存不再拖垮队列。