repo/gc会删除哪些IPFS区块？ 图 1
repo/gc会删除哪些IPFS区块？ · 图 1

IPFS节点磁盘接近上限时，repo gc看起来像一个直接答案：删除不再需要的对象并释放空间。问题是“未被本地pin保护”不等于“业务不再需要”。GC前必须把业务保留清单翻译成可验证的本地pin与备份证据。

GC真正清理的是本地未保护块

repo gc扫描本地对象并删除没有被pin保护的块，以回收磁盘空间。

pin保护的是从特定根可达的块集合，直接pin、递归pin和业务外部记录要区分。一个CID曾经被读取、出现在网关缓存或由远程pin服务保存，都不能自动保护当前仓库的本地副本。

用业务清单列出必须保留的根CID，再导出本地pin状态并抽样遍历子块。对共享DAG，避免因为另一个根仍可达就误以为原业务引用关系已经正确；保留集合要能回到业务所有者。

add默认pin不等于所有导入路径都安全

Kubo add默认会pin新增内容，但GC前仍需核对目标CID是否处于本地pin保护集合。

标准add流程可以默认pin，但程序可能显式关闭pin、只导入原始块、使用外部工具写仓库，或把远程pin误认为本地pin。GC前按实际命令与API审计，不从“通常会pin”推断所有内容都受到保护。

开工前证据合格条件不合格处理
关键根清单有业务所有者与保留期暂停GC补清单
本地pin导出根与模式可核对补pin并等待稳定
备份或远端副本已实际读取并校验先制作可恢复副本
空间基线repo stat与磁盘一致查挂载与其他占用

执行时保留完整错误流

命令支持stream-errors、quiet与silent输出选项，自动化应保存完整错误而不是只记录退出。

stream-errors适合长任务把错误随扫描输出。自动化保存标准输出、错误、开始结束时间和退出状态；quiet或silent只用于已经有其他完整审计通道的场景。只记录“删除N个块”会丢掉无法处理的对象和部分失败。

运行期间暂停大规模add、pin变更和其他GC任务，降低保留集合在扫描中变化的机会。若服务必须持续写入，先验证Kubo版本和部署模式对并发的支持，并在变更记录说明仍存在的竞态边界。

空间前后对比要固定口径

RPC是管理员接口；GC前后应在同一仓库读取repo stat并验证关键CID，而不是只看释放字节。

同一节点、同一仓库在GC前后采集RepoSize、NumObjects与底层文件系统占用。文件系统延迟回收、日志、索引和其他进程也会占空间，因此两组数字不一定完全相等。差异要解释，不能为了对齐篡改统计。

如果GC几乎没有释放空间，先查高占用是否来自已pin内容、日志、索引或仓库之外的目录；不要立刻重复GC。频繁全盘扫描会增加I/O，却不会改变业务保留策略。

回读关键CID比查看成功提示更重要

GC后从本节点读取每个关键根和抽样子块，重新计算CID或内容哈希；再用独立节点验证提供和取回。某根能打开但深层子块缺失时，报告部分损坏并停止对外宣称完整。

对被预期删除的样本也做一次检查，确认它确实不再受pin保护且本地已回收。保留样本与删除样本都符合预期，才能证明策略执行正确。

自动GC需要水位、冷却和停止条件

自动任务根据仓库配置与磁盘水位触发，并设置最短间隔、运行时资源上限和关键服务延迟阈值。发生pin导出失败、备份不可用、仓库verify异常或磁盘错误时，自动GC必须停止而不是继续腾空间。

GC涉及数据删除。变更前由第二人复核关键集合与恢复路径，操作后保存删除清单和回读结果。本文用于节点存储运维，不构成数据永不丢失的保证。

GC的成功标准不是释放了多少空间

合格验收同时证明关键CID仍可读、pin策略仍匹配业务、错误得到解释且空间确实回落。任何关键数据只有一个副本时，先完成备份再运行GC。

资料台账与适用边界

  1. Kubo CLI repo gc：删除边界与选项。
  2. Kubo RPC add and pin：新增内容默认pin语境。
  3. Kubo RPC repo stat：空间前后对照。
  4. Kubo RPC security：管理员接口边界。

资料访问时间为2026-08-08。仍需按实际环境复核：具体GC触发阈值与周期来自节点配置；共享仓库或并发写入环境需按部署方案另行验证。

相关站内主题：repo stat空间压力、dag stat共享大小、CAR完整性校验。本文用于技术教育与防御性运维，不构成投资、收益、交易或资产安全承诺。