答案是inode耗尽而非磁盘空间不足，需用df -i确认iuse%是否≥95%，重点检查/var、/boot等分区，再用find定位小文件源头，lsof +l1排查已删未释放文件，最后修正定时任务防止复发。
磁盘报“No space left on device”，但 df -h 显示还有大量空间？八成是 inode 耗尽了，不是磁盘块（block）真满了。
用 df -i 确认是不是 inode 真爆了
这是第一且唯一必须做的动作。df -i 不看容量，只看每个挂载点还能建多少文件——这才是“能否创建新文件”的决定性指标。
-
IUse%≥ 95% 就得立刻处理；100% 时touch、echo > file全都会失败 - 注意
Mounted on列：/var、/home、/boot 这些单独分区最容易满，和根目录无关 -
tmpfs和devtmpfs也会计 inode，df -i会一并列出，别漏掉内存文件系统 - 某些小分区（比如 512MB 的
/boot）默认只有几万个 inode，IUse%很容易冲到 100%
用 find + wc 找出谁在狂产小文件
知道哪个分区 inode 满了，下一步是定位源头目录。不能靠 ls /var | wc -l 这种一级统计——真正吃 inode 的是深层嵌套的临时目录或日志子目录。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 从高危路径入手：
find /var -xdev -type d -exec sh -c "echo {}; ls -a '{}' | wc -l" \; | sort -nr | head -10 - 重点盯：
/var/spool/postfix/maildrop（cron 邮件积压）、/var/log/journal（systemd 日志）、/var/cache（包管理缓存） - 加
-maxdepth 2防卡死；加-xdev避免跨文件系统误扫（比如 /var 下挂了 /var/lib/docker） - 输出里数值异常大的路径，进它里面再跑一次
ls -a | wc -l确认，别光信 find 的递归统计
用 lsof +L1 或 lsof | grep deleted 排查“已删未释放”
inode 满 ≠ 一定有大量可见文件。还有一种情况：文件被 rm 了，但进程还在写它，inode 和 block 都没真正回收。
-
lsof | grep deleted列出所有标记为 deleted 但仍在被打开的文件 - 更精准的写法：
lsof +L1（+L1 表示 link count = 0，即硬链接数为 0 的已删文件） - 重点关注
COMMAND列里的服务名，比如rsyslogd、nginx、java—— 对应进程重启后空间立即释放 - 别直接
kill -9，优先systemctl reload rsyslog或nginx -s reload，避免业务中断
清理前务必确认文件是否可删
很多 inode 满的根子不在文件本身，而在定时任务配置错误。删了今天，明天又长出来。
- 进
/var/spool/postfix/maildrop后，用ls -U | head -n 5看文件名时间戳是否密集（如全是同秒生成），大概率是 cron 脚本没重定向输出 - 检查
crontab -l和/etc/cron.d/下脚本，确认每行末尾都有> /dev/null 2>&1 - 删大量小文件时，别用
rm -rf *：参数过长会报Argument list too long，改用find . -type f -print0 | xargs -0 rm -f - 容器环境别忘了
docker system prune -af，悬空镜像层、构建缓存、停止容器都悄悄占 inode
最麻烦的永远不是怎么删，而是那个名字叫 sync.sh、每分钟新建一个空文件、藏在 root crontab 里的定时任务——它不会出现在 find 统计里，因为文件刚建就删了，但 inode 分配又回收不及时，长期下来就把分区拖垮。
