比特币节点的磁盘保卫战：Disk space is too low 停机之后怎么办

“磁盘空间不足”在节点里不是警告，是停机条件

Bitcoin Core 对磁盘的态度比多数软件激进：在写入区块与状态数据前，节点会主动检查目标目录剩余空间，不够就直接触发致命错误并退出，日志里那行英文是 Disk space is too low!。这不是”可能变慢”的提示，而是一条防止半写状态的保险——区块文件写到一半断掉，比根本不出错更难修。理解这一点，整个排障思路就清楚了一半：节点在”还能正常退出”的时刻选择了退出，是在帮你保住数据目录。

检查点分布在两条主路径上。写新区块与撤销数据到 blocks 目录前有一道；把 UTXO 集合的脏页刷回 chainstate 数据库前还有第二道，而且按脏数据量乘上安全系数留余量。此外初始区块下载阶段的解压、coin 快照落盘也各有空间门槛。不同版本的具体阈值会调整，行为模式不变：宁可停机，不可半写。

三种典型崩盘路径的现场特征

第一种：新节点同步到一半深夜停掉，GUI 弹窗或 debug.log 里 Disk space is too low。常见原因是预留太乐观——区块原始数据之外，chainstate 目录的 UTXO 状态数据库还要单独占用可观空间，再叠上调试日志，容量紧凑的家用盘往往跑到某个百分比就撞上。Bitcoin Core 官方对最低可用磁盘的建议会随链增长变化，请以你安装版本对应的发布说明与官网全节点页面为准，但”给未来留一块增速缓冲”的原则长期有效。

第二种：运行多年的节点突然拒写。blocks 目录看起来没多大，空间却快见底——多半是 debug.log 失控。默认日志滚动配置对体积有每小时上限，但把 loglevel 调细或关掉滚动跑上几个月，单个日志就能吃掉几十 GiB。删日志前先 bitcoin-cli stop，别在运行中 rm：文件句柄还开着，空间不会释放，这是新手最容易误判”删了没用”的场景。

第三种：Windows 或 macOS 上迁移数据目录后旧盘被遗忘。两个盘各躺着一份链数据，新盘写满即停，很多人先怀疑新盘坏了，实际问题在两边都被忽略。

处理动作按这个顺序做

第一步确认是不是真满了：df -h 找到数据目录所在挂载点，对照节点报告的目录。注意文件系统”满”可能不是 100% 整数——ext4 默认给 root 留了约 5% 的保留块，普通用户进程在显示还有余量时也可能写失败，这类情况 resize 或调 reserved 由管理员决定。

第二步安全回收。可以删的：滚动留下的旧 .log 文件（停机删）、已确认无用的一键钱包备份。可以移的：把整个数据目录迁到大盘的标准动作是——先正常 stop，再整目录搬走，启动时加 -datadir=<新路径>。搬完先只读校验再删旧盘副本，观察一次完整重启。prune 模式是另一个思路：保留近期区块、丢弃远古原始数据，能长期压低占用，但已经占用的空间要等 prune 周期逐步释放，不适合当急救手段。

第三步永远不要做的：在节点运行时清理 blocks 或 chainstate 里的单个文件；用 truncate 或清空回收站之外的”智能清理软件”腾空间；空间不够时强行重启期望它”跳过”——它会再次在同一条检查线停机。如果已经出现停机循环且 datadir 疑似半写，恢复路径是整目录换新副本后 reindex，或用另一台机器的快照同步，让程序自己重建，而不是手动删除校验失败的单个文件。

风险提示：本文为节点运维科普，不构成投资建议。数据目录操作前请先完整备份钱包文件并做恢复演练。