inode耗尽导致“no space left on device”：用df -i查iuse%≥95%的挂载点，再用find递归统计各目录文件数，重点排查/var/spool/postfix/maildrop等高危路径，确认并清理定时任务产生的冗余小文件。
df -i 看哪里 inode 快爆了
系统报 No space left on device，但 df -h 显示磁盘还有大量空间？十有八九是 inode 耗尽了。这时候必须用 df -i，它专看索引节点——不是看容量，是看“还能建多少个文件”。
-
IUse%列是关键，≥95% 就得立刻查；100% 时连touch都会失败 - 注意挂载点（
Mounted on），比如/home或/var单独分区时，inode 耗尽只影响该分区，和根目录无关 -
tmpfs、devtmpfs这类内存文件系统也有 inode，df -i一样能列出来，别漏掉
find + wc 定位“产蛋大户”目录
知道哪个分区爆了还不够，得找到谁在疯狂创建小文件。不能靠肉眼翻，要用命令组合快速扫描。
- 从高风险路径入手：
find /var -type d -exec sh -c "echo {}; ls -a '{}' | wc -l" \;，重点盯/var/spool/postfix/maildrop、/var/log/journal、/var/cache - 如果怕卡死，加
-maxdepth 2限制深度；加-xdev避免跨文件系统误扫 - 注意：直接
ls /var | wc -l只统计一级子项，真正藏污纳垢的往往是深层嵌套的小目录，必须递归
删文件前先确认是不是 cron 邮件积压
很多 inode 满的案例，根子都在定时任务没配好输出重定向，导致每跑一次就往 /var/spool/postfix/maildrop 塞一个临时邮件文件。
- 检查
crontab -l，看有没有脚本没加> /dev/null 2>&1 - 进
/var/spool/postfix/maildrop用ls -U | head -n 5看文件名时间戳是否密集（如全是同秒生成） - 别直接
rm -rf *：先ls -U | head -n 1000 | xargs rm -f分批删，避免参数过长报错Argument list too long
临时缓解比硬格式化更实用
inode 数量在格式化时就定死了，重装系统或 mkfs.ext4 -i 8192 调比例是下策——线上环境根本不敢动。
- 软链接迁移是最快方案：
mkdir /opt/newcache && ln -sfn /opt/newcache /var/cache，把压力转到 inode 充裕的分区 - 日志轮转要配
logrotate的maxsize和rotate，光靠daily不顶用 - 容器环境记得
docker system prune -af，悬空镜像层、构建缓存、停止容器都会悄悄吃 inode
真正麻烦的不是删文件，而是找出那个每分钟新建一个空文件却没人管的定时任务——它往往藏在 root 的 crontab 里，名字还起得特别朴素，比如 sync-time.sh。
