inode耗尽是“No space left on device”的常见原因，可用df -i确认，再用du --inodes -S定位高占用目录，针对性清理journald日志、邮件队列、临时文件或Docker残留，并通过logrotate、合理inode分配和监控预防复发。
Linux 报 “No space left on device” 却发现 df -h 显示磁盘使用率很低，这大概率是 inode 耗尽，而非磁盘空间不足。inode 是文件系统的元数据结构，每个文件（含目录、软链接、设备文件等）都占用一个 inode。即使文件体积极小（比如空日志、临时小文件），也会消耗 inode。一旦用完，系统就无法创建新文件——哪怕磁盘还有几十 GB 空闲。
确认是否为 inode 耗尽
运行以下命令查看各挂载点的 inode 使用情况：
df -i
重点关注 IUse% 列。若某分区显示 100% 或接近 100%，而 df -h 对应空间使用率很低，即可确认是 inode 耗尽。
定位高 inode 占用目录
进入疑似满载的挂载点（如 /var、/home），逐级统计子目录的 inode 数量：
find . -xdev -type d | while read dir; do echo "$(find "$dir" -maxdepth 1 -type f | wc -l) $dir"; done | sort -nr | head -20
更简洁常用的方式（推荐）：
du --inodes -S /var | sort -nr | head -10
该命令会列出 /var 下 inode 占用最多的前 10 个目录。常见高 inode 目录包括：
-
/var/log/journal：systemd-journald 日志，默认不轮转时可能生成海量小文件 -
/var/spool/postfix/maildrop或/var/spool/clientmqueue：邮件队列堆积 -
/tmp或/var/tmp：残留的临时文件、未清理的 session、容器卷挂载残留 -
/var/lib/docker/overlay2（Docker 环境）：已删除但未清理的镜像层或悬空容器产生的未引用文件
快速释放 inode 的常用操作
确认问题目录后，针对性清理：
- 清空 journald 日志（保留最近 2 天）：
journalctl --vacuum-time=2d；或限制日志大小：sudo systemctl edit systemd-journald，添加[Journal] SystemMaxUse=500M - 清理旧邮件队列：
postsuper -d ALL（Postfix）或检查sendmail队列路径并手动rm -f - 清理
/tmp下过期临时文件：sudo find /tmp -type f -mtime +7 -delete（注意避免误删正在使用的文件） - Docker 用户可执行：
docker system prune -a --volumes（谨慎，会删所有未使用资源）；或先docker ps -a和docker images -f "dangling=true"定位再清理
预防 inode 再次耗尽
长期运维需从机制上规避：
- 对日志服务启用轮转策略（logrotate），限制单个日志文件数量和总大小
- 在
/etc/fstab挂载选项中为高频小文件场景（如/var）预留更多 inode：格式化时用mke2fs -i 4096（每 4KB 分配一个 inode），默认是 16KB；已有文件系统不可直接修改，需备份重建 - 定期巡检：
df -i加入监控告警（如 Prometheus + Node Exporter），阈值建议设为 85% - 避免程序反复创建/删除极小文件（如某些监控 agent、脚本循环 touch）；改用追加写入或批量处理
