答案是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}'可加入巡检脚本
