答案是inode耗尽。当df -h显示空间充足但提示“no space left on device”时，应运行df -i检查iuse%是否达100%；再用du --inodes定位高inode占用目录如/var/log/journal；最后清理无用小文件或调整日志、缓存策略预防复发。

看到“No space left on device”但 df -h 显示磁盘还有大量空间，大概率是 inode 耗尽了。这不是磁盘真满了，而是文件系统“登记簿”写满了——每个文件都要占一个 inode 条目，条目用光了，再空的硬盘也写不了新文件。

第一步：确认是不是 inode 问题

别猜，直接验证：

• 运行 df -i，重点看 IUse% 列。如果某个挂载点（比如 /、/var 或 /data）显示 100%，基本就是它了
• 对比 df -h 和 df -i 输出，若容量使用率很低（如 30%），而 inode 使用率已满（100%），可立即锁定为 inode 耗尽
• 小提示：XFS、Btrfs 文件系统动态分配 inode，极少出现耗尽；ext4 最常见，尤其在小分区或大量小文件场景下

第二步：定位哪个目录占用了最多 inode

找到“罪魁目录”，才能精准清理：

linux-sysadmin

Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...

下载

• 快速扫描根下一级子目录： du --inodes -s /* 2>/dev/null | sort -n -r | head -10
• 深入高嫌疑目录（如 /var/log、/tmp、/var/cache）逐层排查： du --inodes -s /var/log/* 2>/dev/null | sort -n -r | head -5
• 典型高危路径包括：/var/log/journal（journald 日志）、/var/spool/postfix（邮件队列）、/tmp/systemd-private-*（临时 systemd 目录）、Web 应用的 session 或缓存目录

第三步：清理或缓解 inode 占用

清理要谨慎，优先删明确无用的小文件：

• 清空过期日志：journalctl --vacuum-time=7d（清理 7 天前的 journal 日志）
• 删除 /tmp 下陈旧临时文件：find /tmp -type f -mtime +7 -delete
• 检查并清理重复或残留的缓存目录，例如 Docker 构建中间层、Python pip 缓存（~/.cache/pip）
• 若无法立即删文件，可临时迁移目录到 inode 充足的分区，并用软链接替代：mv /data/cache /opt/cache_new && ln -s /opt/cache_new /data/cache

第四步：预防再次发生

治标更要治本：

• 对日志服务（rsyslog、journald）配置轮转和大小限制，避免无限堆积
• 应用层控制缓存生命周期，避免生成海量 1KB 级小文件
• 新建 ext4 分区时，如预知会存大量小文件，可用 mke2fs -i 4096（每 4KB 分配一个 inode）代替默认的 16KB，提高 inode 总量
• 定期监控：df -i | awk '$5 > 90 {print "ALERT: "$1" inode usage "$5}' 可加入巡检脚本