no space left on device大概率是inode耗尽而非磁盘空间不足，需用df -i检查iuse%是否≥95%，再定位/var/log、/tmp、/var/lib/docker等高危目录清理小文件，并按文件系统类型采取ext4重格式化或xfs动态扩容等预防措施。
磁盘空间明明还有余量，却提示“No space left on device”或无法新建文件？这大概率不是空间问题，而是 inode 耗尽——文件系统里“登记档案的本子”写满了，再没空行记新文件。
用 df -i 快速确认是不是 inode 问题
执行 df -i，重点看输出中的 IUse% 列：
- 若某挂载点（如
/、/var或/data）的 IUse% ≥ 95%，而对应的空间使用率（Use%）仍很低（比如才 30%），基本就是 inode 耗尽 - 加
-T可同时查看文件系统类型：df -i -T，因为 ext4 和 XFS 对 inode 的管理逻辑不同 - 只查
df -h容易误判，尤其在日志服务、Docker、缓存目录等高频生成小文件的场景下
定位哪个目录吃掉了最多 inode
确认 inode 紧张后，要快速找出“高产小文件”的路径：
- 检查常见高危区域：
find /var/log -type f | wc -l、find /tmp -type f | wc -l、find /var/lib/docker -type f | wc -l - 统计各二级目录下的文件总数：
find / -xdev -type d | cut -d/ -f2 | sort | uniq -c | sort -nr - 进到可疑目录后，用
ls -ia查看所有文件（含隐藏的.tmp、.log），再配合ls -a | wc -l统计数量
清理 + 监控 + 预防三步走
临时释放靠清理，长期稳定靠机制：
- 清理无用小文件：停掉 journal 日志服务后清
/run/log/journal、轮转未启用的/var/log/*/*.log、删过期 session、清 Docker dangling volume - 加入基础监控：写个脚本定期跑
df -i | awk '$5 ~ /%/ {sub(/%/,"",$5); if($5 > 85) print $1 " inode high"}'，接入 Zabbix 或 Prometheus 做阈值告警 - 新建分区时预留足够 inode：ext4 用
mkfs.ext4 -i 4096 /dev/sdb1（每 4KB 一个 inode，比默认多 4 倍）；XFS 用mkfs.xfs -i maxpct=30 /dev/sdb1
不同文件系统的扩展能力差异
ext4 和 XFS 处理 inode 枯竭的方式完全不同：
- ext4 的 inode 总数在格式化时就固定，后期无法增加。只能备份数据 → 重新格式化（带
-i或-T small）→ 恢复 - XFS 更灵活：
xfs_growfs -i maxpct=30 /mountpoint可动态扩大 inode 区占比（前提是预留了空间），无需停机 - 新部署 XFS 分区时，默认
maxpct=25，建议按需设为 30 或更高，尤其用于日志、对象存储等小文件密集型场景
