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 导致的发布事故。见 套餐与首页。