repo/stat如何判断IPFS空间压力？

IPFS节点磁盘告警经常出现两种相反问题：RepoSize接近StorageMax，但主机仍有很多空间；或者RepoSize看起来不高，底层容器卷却快满了。原因是Kubo仓库上限和操作系统真实容量属于不同层。

repo/stat先给出仓库内部快照

Kubo /api/v0/repo/stat返回NumObjects、RepoPath、SizeStat.RepoSize、SizeStat.StorageMax和Version，并支持size-only与human参数。

RepoPath帮助确认你观察的是哪个仓库，Version说明仓库格式，RepoSize与StorageMax组成Kubo视角的容量关系，NumObjects描述对象数量。容器、测试网与生产网可能各自有不同IPFS_PATH，采集脚本不保存RepoPath就容易监控错实例。

human参数适合人工查看，机器采集应优先保留原始字节值，避免不同语言或单位格式造成解析误差。size-only可以减少输出，但做版本审计时仍要定期保存完整stat。

RepoSize是Kubo仓库使用量，StorageMax是配置上限；它们不等于底层卷或主机的实时可用字节。

RepoSize除以StorageMax可作为仓库压力指标，但不能替代df、卷监控和inode检查。StorageMax大于底层卷容量尤其危险：Kubo尚未触及自身上限，文件系统已经可能写满。反过来，StorageMax较小可能是有意预留给系统日志和其他服务。

NumObjects可观察对象数量变化，但对象大小不一，不能用对象数直接推断磁盘增长。

NumObjects快速增长而RepoSize缓慢上升，可能是大量小对象；对象数平稳但RepoSize快速上升，可能是少量大块或临时数据。它有助于分类，却不能用“平均对象大小”简单预测，因为datastore开销、块大小与回收状态并不均匀。

诊断时把NumObjects增量、RepoSize增量、pin数量、入站内容任务和GC时间放在同一窗口。单独看某一次对象数无法知道增长来自用户pin、缓存、导入CAR还是异常任务。

每隔固定周期采集RepoSize与文件系统available，计算短期和长期斜率。预计耗尽时间可以用剩余可用容量除以平滑后的增长速率，但当增长接近零或任务批量导入时要显示区间，不给虚假精确日期。

告警可分为三档：仓库接近StorageMax、底层卷接近安全水位、增长加速导致预计耗尽时间短于扩容准备期。三档各自有负责人和动作，不要用一个90%阈值覆盖所有场景。

检查高价值CID是否pin、pin策略是否与业务一致、CAR或其他备份能否实际恢复、最近GC是否成功，以及数据是否可从其他节点重新获取。Pinning保障本节点保留意图，不等于外部永久存储；备份存在也不等于已验证。

若需要扩容，先确认RepoPath所在卷并按基础设施流程操作。若调整StorageMax或GC配置，记录变更前后值与回滚方式。不要直接删除仓库目录中的块文件，手工删除会破坏索引与数据一致性。

/api/v0/repo/verify的drop与heal可能改变仓库，容量监控不应在未备份、未停机和未理解后果时调用。

verify相关的drop、heal等选项可能改变仓库，适合经过备份、维护窗口和明确操作手册的修复，不适合“磁盘超过阈值就自动执行”。容量不足和仓库损坏是两类问题，用修复工具清容量可能扩大事故。

只读监控账号不应拥有执行破坏性RPC的权限。Kubo管理API也不应对公网开放，采集器通过localhost或受控管理网络访问，并对日志中的路径与环境信息脱敏。

日报列出RepoSize、StorageMax占用率、文件系统剩余、inode、24小时与7日增长、预计耗尽时间、NumObjects变化、最近GC、关键pin与备份状态。结论写明是扩容、优化任务、审查pin还是继续观察，并保留原始采样以复核趋势。

先确认哪些内容必须保留、备份是否可恢复、GC策略是否正确，再决定扩容或清理。监控的职责是提供提前量，而不是在空间紧张时擅自删除证据。

本页事实底稿来自Kubo RPC API v0.43.0、Kubo CLI Reference、Kubo v0.43.0 Release，关键结论均可回到对应原文复查。

当前不能越过的事实边界是：RepoSize与文件系统实际占用可因datastore、文件系统、稀疏文件和容器层不同，需结合操作系统指标。

相关背景可继续查看Pinning保留边界、CAR恢复核验、网络流量基线。数据、接口与规则会随时间更新，本文不构成投资、交易或收益建议。