inode 耗尽导致“No space left on device”错误，因 inode 与磁盘块独立管理；小文件过多（如日志、临时文件）易占满 inode；需用 df -i 定位、du –inodes 分析、find 清理，并在格式化时用 -i 参数预留足够 inode。
inode 是 linux 文件系统的元数据容器，不存文件名、不存内容，只存权限、所有者、大小、时间戳、数据块位置等信息。每个文件或目录都必须对应一个 inode，系统靠 inode 号识别文件——你用 ls -i 就能看到它。
df -i 显示 100% 时，为什么 df -h 还说空间充足？
因为 inode 和磁盘块（block）是两套独立资源：
- 磁盘块管“能存多少字节”
-
inode管“最多能建多少个文件/目录”
比如：一个 50GB 分区，格式化时分配了 100 万个 inode；如果程序每秒生成一个 1KB 的日志小文件，3 天就耗尽全部 inode，而实际只占了不到 1GB 空间。此时 touch test 或 mkdir newdir 都会报 No space left on device——不是空间没了，是“编号本”用完了。
哪些场景最容易把 inode 耗尽？
-
/var/log下未轮转的访问日志（nginx/apache）、journal 日志堆积 -
/tmp和/var/tmp中残留的临时文件（尤其是脚本没清理的.tmp或.lock） -
/var/spool/postfix/maildrop或/var/spool/cron：cron 输出未被投递时，会以小文件形式卡在队列里 - docker 容器残留的
overlay2临时层、构建缓存（/var/lib/docker/overlay2） - 应用自己写的缓存目录（如 python 的
pycache、Node.js 的node_modules/.cache），没设清理策略
这些目录共同点：单个文件极小（几十到几百字节），但数量可达几十万甚至上百万。
怎么快速定位并清理高 inode 占用目录？
先确认问题分区：df -i 找出 IUse% 为 100% 的挂载点（比如 / 或 /var）。
再逐层定位：
- 查根下各一级目录的 inode 数：
du --inodes -s /* 2>/dev/NULL | sort -n - 进入可疑目录（如
/var）后细化：du --inodes -s /var/* 2>/dev/null | sort -n - 若发现
/var/log/journal异常高，可限制 journal 大小：sudo systemctl edit systemd-journald，加[Journal] SystemMaxUse=500M - 清理 postfix 队列：
find /var/spool/postfix/maildrop -type f -delete（确认无业务依赖后再执行） - 避免
rm *报 “argument list too long”：改用find /path -type f -print0 | xargs -0 rm
注意：删前用 lsof +L1 检查是否有已删除但仍被进程占用的文件（它们仍占 inode，需重启对应服务才能释放）。
真正麻烦的不是清理，而是预防——inode 总数在 mkfs.ext4 时就固化了，没法在线扩容。所以新建分区时，若预判会存海量小文件（如日志服务器、CI 构建机），务必加 -i 4096（每 4KB 数据块配 1 个 inode），而不是默认的每 8KB 或 16KB 一个。否则等用满再扩容，只能备份→重格式化→还原，停机成本极高。