本文要點
- 同時盯 區塊用量 與 inode；小檔案風暴常見於
node_modules、索引與日誌分片。 - 把清理分成「可丟快取 → 可重建產物 → 需審批資料」三層，避免腳本誤刪金鑰或製品庫快取。
- 容器側與宿主側分開計量：
docker system df與 APFS 空閒要一起看，細節對齊 Apple Silicon 雲 Mac 上跑生產級 Docker 排障手冊。 - Webhook／自託管 Runner 的磁碟尖峰常與並發任務相關，可與 OpenClaw 回呼與雲 Mac Runner 串聯文 中的隔離與冪等策略一起複核。
df、df -i、統一日誌與 CI 產物保留策略為準。1. 雙頂：區塊裝置與 inode
APFS 上「還剩數十 GB」卻報 No space left on device，多半是 inode 或中繼資料壓力 而非大塊連續檔案。Runner 上高頻元兇：每個 job 一份的 Xcode DerivedData、未輪替的統一日誌、npm／pip／Maven 本機倉庫，以及把版本庫 bind 進容器時複製出的海量小檔。告警建議拆兩條：disk>85% 與 inode>85%（或檔案計數代理），並在 Grafana／企業 IM 裡用不同顏色區分，避免值班只看容量條。跨區遠控時網路路由亦會影響日誌上傳與輪替節奏，必要時與 WireGuard 跨境遠控排障文 一併檢視。
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 與容器快取不再拖垮佇列。