“no space left on device”报错但df -h显示磁盘充足，极大概率是inode耗尽；必须运行df -i检查各挂载点iuse%列，若任一达到100%即确认为inode满，尤其需单独检查/var、/home、/var/log等独立inode池目录。
“No space left on device” 报错但 df -h 显示磁盘空间充足？十有八九是 inode 耗尽，不是磁盘满——必须立刻查 df -i，否则所有排查方向都会错。
怎么确认真的是 inode 耗尽？
只运行 df -h 不够，它只看块（block）使用率；真正要盯的是 df -i 输出里的 Use% 列：
- 哪怕
Capacity%才 12%，只要任意挂载点的Use%是 100%，就是 inode 耗尽 - 特别注意独立挂载点：/var、/home、/var/log、/var/spool 等，它们各自有独立 inode 池，
df -i要逐个看，不能只扫根分区 - 常见误判：看到
/的 Use% 是 82%，就排除 inode 问题——但其实/var可能已 100%，而应用日志或邮件队列正卡死在那儿
哪个目录塞满了小文件？快速定位高 inode 占用路径
别用 find / -type f | wc -l 全盘扫，既慢又可能跨文件系统误统计。优先用带 -xdev 和限定深度的方式：
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
-
du --inodes -s /var/* 2>/dev/null | sort -nr | head -5—— 准确、快，适合初步圈定范围 -
find /var -xdev -type d | while read d; do echo "$(find "$d" -maxdepth 1 -type f 2>/dev/null | wc -l) $d"; done | sort -nr | head -10—— 定位到具体子目录，-maxdepth 1避免递归拖慢速度 - 重点盯这些目录：
/var/spool/postfix/maildrop、/var/spool/clientmqueue、/tmp、/var/log/journal，它们是小文件黑洞高频区
删不掉：“Argument list too long” 怎么安全清空海量小文件？
直接 rm -rf * 在几十万文件目录下必然失败，shell 展开参数超限。必须绕过 shell 参数传递：
- 先进入目标目录：
cd /var/spool/postfix/maildrop，再操作，避免路径错误 - 用
find . -type f -delete最简洁，但部分老系统不支持-delete，可退化为：find . -type f -print0 | xargs -0 rm -f - 慎用
ls | xargs rm -f：如果文件名含空格或换行符会出错；find ... -print0 | xargs -0才是安全组合 - 删完立刻
df -i验证——XFS 文件系统可能延迟释放 inode，需等几秒或触发一次sync
删了还是 100%？注意已删除但被进程占用的 inode
执行 rm 只是解除硬链接，如果还有进程打开着这个文件，inode 就不会真正回收。这类文件在 lsof +L1 或 lsof | grep deleted 里能看到，状态标为 DEL：
-
lsof +L1直接列出所有已删但未释放的文件（需要 root 权限） - 常见持有者：logrotate 中转的日志、长期运行的 daemon（如 nginx、rsyslog）、cron 脚本重定向输出到已删文件（如
cat file > /tmp/log后file被删） - 解决方式不是硬杀进程，优先尝试
systemctl reload xxx或kill -HUP $(pgrep xxx)让其重新打开文件句柄 - 实在无法 reload 的服务，才考虑
systemctl restart，否则 inode 一直卡住
最易被忽略的一点：inode 耗尽往往不是单点故障，而是某个服务持续产文件 + 缺乏清理机制的组合结果。定位到目录后，一定要顺藤摸瓜查 cron、mail 配置、应用日志轮转策略——否则几天后又满。临时清理只是止血，补上自动清理或限制逻辑才是根治。
