inode耗尽是“no space left on device”错误的常见原因，需用df -i检查iuse%是否≥95%，再通过du --inodes逐级定位高inode占用目录（如/var/spool/postfix/maildrop），最后用find安全清理小文件。
inode 是文件系统的“元数据身份证”，不存文件名和内容，只管权限、所有者、时间戳、数据块位置等信息。每个文件、目录、软链接都独占一个 inode。磁盘空间够但报 No space left on device，十有八九是 inode 耗尽了。
怎么看是不是 inode 用完了
运行 df -i，重点看 IUse% 这一列：
- 超过 95% 就得警觉，接近或达到 100% 基本确认是瓶颈
- 对比 df -h：如果磁盘使用率才 60%，而 IUse% 是 100%，就是典型的 inode 耗尽
- 注意挂载点，/、/var、/home 等不同分区的 inode 是独立统计的
怎么找到哪个目录在疯狂吃 inode
用 du --inodes 逐层统计文件数量：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 从根下一级开始：du --inodes -s /* 2>/dev/null | sort -nr | head -10
- 发现 /var 占最多，就深入：du --inodes -s /var/* 2>/dev/null | sort -nr | head -10
- 一层层往下查，直到定位到具体子目录，比如 /var/spool/postfix/maildrop 或 /var/cache/fontconfig
哪些地方最容易堆满 inode
这几个路径是高频“产 inode 大户”：
- 邮件队列：/var/spool/postfix/maildrop 或 /var/spool/clientmqueue，cron 脚本输出未发送成功时会堆积成千上万个零散文件
- 临时与缓存目录：/tmp、/var/lib/php/sessions、/var/cache/fontconfig（Ubuntu 上可能生成几百万个小文件）
- 日志碎片：/var/log 下未轮转的 *.log.*、*.gz，还有 journal 日志没清理，journalctl --vacuum-time=3d 可收缩
- 应用残留：Nginx、Tomcat、Java 应用未关闭日志句柄就删了文件，lsof +L1 能揪出这类“已删未释放”的文件
清理时要注意什么
别直接 rm -rf *，尤其文件超多时容易报 “Argument list too long”：
- 用 find ... -delete 最稳妥，例如：find /var/spool/postfix/maildrop -type f -delete
- 清 session 或缓存时加 -mtime +7 避免误删活跃文件
- 字体缓存这种千万级目录，建议分批执行，或先用 find ... | head -1000 | xargs rm -f 测试节奏
- 清完立刻 df -i 验证，IUse% 下降才算生效
