2026 年遠端 Mac 磁碟满导致 SFTP/rsync 上傳失败：APFS 水位线、製品 LRU 与 CI Job 閘門决策矩陣
遠端 Mac 出现 No space left on device 时，SFTP/rsync 往往在中途断开，而 ssh 登录仍可能正常。本文把 APFS 真满盘、inode、配额与中间设备 reset 分层归因，并给出 20%/12%/10% 水位线、製品 LRU 与上傳前 df 探测，并联原子發佈、link-dest、SHA256 閘門与並發 SFTP 專文。
当租賃或自建遠端 Mac 同时承载 Xcode 编译、製品上傳与 link-dest 快照时，空间压力很少来自单一目錄。更常见的是 APFS 容器、purgeable 字节与多路 SFTP 並發叠加。建议阅读顺序对齐 原子發佈、link-dest、SHA256 閘門、並發 SFTP、DerivedData 專文。
2026 生产里为何「磁碟满」会让 SFTP/rsync 上傳像网络故障
痛點一：把 df 的 Available 当成「还能传」。APFS 的 purgeable 与本地快照会让可用空间在压力下骤降；上傳前应同时看容器空闲百分比与 tmutil listlocalsnapshots，而不是只看 Finder 圆饼图。
痛點二：满盘时仍 in-place rsync 覆盖 release。半写入的 bundle 会破坏 原子發佈 假设；应先停新 Job、清可再生目錄，再对 staging 做 dry-run。
痛點三：link-dest 保留 N 过大。硬連結快照省空间但代数叠加仍可能吃满 NVMe；满盘治理应先降 N，再动 DerivedData，避免删除当前 staging 指向的一代。
痛點四：並發 SFTP 与编译抢同一卷。多路大文件上傳会放大元数据 IO；应联读 並發 SFTP 与 DerivedData 的降载规则。
痛點五：把 ENOSPC 与 Operation not permitted 混为一谈。后者可能是 TCC/SIP 或只读挂载；用 errno 与 unified log 对照，避免误删业务树。
痛點六：无 SHA256 閘門就强行重试上傳。磁碟满后的部分文件可能已损坏；恢复顺序应为：释放空间 → dry-run → 完整性校验 → 再切可见性。
磁碟满盘治理决策矩陣：水位线、LRU 与 CI 閘門
矩陣原则：先判层（真满盘 / inode / 配额），再按空闲百分比选动作；禁止在 <12% 时启动全量 mirror 或多路大文件並發。
| 水位线 | CI / 上傳动作 | 风险 | 下一跳 |
|---|---|---|---|
| ≥20% 空闲 | 正常上傳/编译 | 无 | 常规 rsync + SHA256 |
| 12–20% | 仅增量、禁全量 mirror | 中 | 降並發 SFTP |
| <12% | 停新 Job（exit 75） | 高 | LRU + 扩卷/外迁 |
| inode>90% | 停 --delete | 高 | 清小文件集群 |
How-to：七步完成 APFS 水位探测、製品 LRU 与上傳恢复
在扩卷/外迁前，先完成 SHA256 清单 快照与 原子發佈 工单字段，避免满盘清理删掉仍被 rollback 指针引用的目錄。
# APFS disk watermark — pre-upload probe (remote Mac)
df -H / /System/Volumes/Data 2>/dev/null
diskutil info / | rg -i 'Volume Free Space|Container Free Space|APFS'
tmutil listlocalsnapshots / 2>/dev/null | head
du -sh ~/Library/Developer/Xcode/DerivedData/* 2>/dev/null | sort -hr | head -5
FREE_PCT=$(df -g / | awk 'NR==2{print int($4*100/($3+$4))}')
[ "$FREE_PCT" -lt 12 ] && echo "DEFER_CI_UPLOAD" && exit 75
rsync -a --info=stats2 --dry-run ./artifact/ user@remote:/var/staging/incoming/ || true- 冻结变更：记录 df、容器 UUID、当前 link-dest 代数与正在跑的 CI Job 清单。
- 判层：区分真满盘、inode 耗尽、配额与中间设备 reset。
- 执行水位线：空闲 ≥20% 正常；12–20% 只允许增量；<12% 停新上傳（exit 75）。
- LRU 清理：DerivedData → 旧 releases → 降 link-dest N → 本地快照（可再生的优先）。
- 上傳前探测：df + rsync dry-run；並發度按水位自动下调。
- 恢复传输：先 staging，再 SHA256，最后原子 swap。
- 验收：写入工单「释放空间 GB、删除类别、是否影响回滚」并设定下周 Top10 报表。
可引用数据：APFS 空闲比例与清理边界
下表为规划用中位数，请在自家遠端 Mac 实测后写入 SLO。
| 指标 | 常见观测 | 建议动作 | 專文 |
|---|---|---|---|
| DerivedData 单机 | 80–220 GB | 周期 LRU | 專文 |
| link-dest 保留 5 代 | 1.2–3.5× 单次全量 | 满盘先降 N | 專文 |
| 並發 SFTP 4 路 | 元数据 IO +40% | <12% 改 2 路 | 專文 |
| 本地 TM 快照 | 10–80 GB | tmutil thin | 与 release 分账 |
站内互链：与原子發佈、link-dest 的执行顺序
建议阅读顺序：link-dest 缩面 → 本文水位/LRU → SHA256 → 原子發佈 swap → 並發 SFTP 降载。
FAQ
问：上傳中途断开一定是磁碟满吗？答：不一定。需先区分 ENOSPC、配额、inode 与中间设备 reset；磁碟满时 ssh 往往仍可登录但写入失败。
问：满盘时能否继续 in-place rsync？答：不建议。应先停新 Job、清可再生製品或扩卷，再按 原子發佈 与 SHA256 閘門 顺序恢复。
问：link-dest 快照占多少空间？答：取决于保留代数与增量比例；满盘时应先降 N、再清 DerivedData，避免删当前 staging。
總結与 SFTPMAC 遠端 Mac 收束
本文价值在于把「磁碟满」从模糊的 rsync 失败，拆成 APFS 水位、製品 LRU 与 CI 閘門三层可执行规则，并与站内原子發佈、完整性、並發專文串成同一套交付顺序。
自建遠端 Mac 的局限是：快照代数、清理窗口与监控仍由团队自管；多 Job 同机时，一次满盘会同时打断编译、上傳与回滚能力，SLA 代价高于单次 rm。
若要把磁碟水位与製品 LRU 写进长期基线，租賃 SFTPMAC 遠端 Mac可预设分离构建卷与製品卷、內建水位告警与上傳閘門，减少 No space left 导致的發佈事故。见 套餐與首頁。