Linux 生产环境“No space left on device”故障排查指南(Inode 耗尽专项)

一、 故障背景与原因分析

在生产环境中，当系统提示 No space left on device（设备上没有空间）时，通常由以下两种独立的原因引起：

1.磁盘数据块（Block）耗尽：实际存储文件内容的空间已满。2.索引节点（Inode）耗尽：文件数量达到文件系统上限，即使磁盘空间充足也无法创建新文件。

1.1 快速区分故障类型

•

检查 Block 使用率：使用 df -h 或 df -m 查看磁盘容量使用百分比（Use%）。

df -i

df -ih

二、 深入理解 Linux Inode 机制

2.1 什么是 Inode？

文件储存在硬盘上，硬盘的最小物理存储单位是“扇区（Sector）”（通常为 512 字节）。为提高读写效率，操作系统将连续的扇区组合成“块（Block）”（通常为 4KB），Block 是系统读写数据的最小单位。

然而，文件的元数据（如权限、大小、时间戳等）并不存储在 Block 中，而是存储在另一个独立的存储单元——Inode（索引节点） 中。

2.2 Inode 的分配与大小

•

固定分配：Inode 的数量和大小在文件系统格式化（如 mkfs.ext4）时就已经固定，后续无法动态增加。

2.3 查看 Inode 信息

•全局使用情况：df -ih•单个文件 Inode 号：stat <filename> 或 ls -li <filename>

三、 Inode 耗尽的排查与定位

当确认 Inode 使用率达到 100% 时，切勿使用 du -ah 命令。du 命令统计的是文件占用的 Block 大小，而不是文件数量。应使用以下方法定位“产 Inode 大户”：

3.1 快速定位高占用目录

在疑似挂载点（如 /var 或 /）下执行以下命令，按子目录消耗的文件数量倒序排列：

find /path/to/dir -type d -exec sh -c 'echo "$(find "$1" -maxdepth 1 -type f | wc -l) $1"' _ {} \; | sort -rn | head -10

常见高危目录包括：/tmp、/var/spool、/var/log/journal、/var/lib/docker/overlay2。

3.2 确认具体目录的文件数量

进入疑似重灾区后，统计文件总数：

find /var/log/journal -type f | wc -l

四、 解决方案与清理策略

4.1 常规小文件清理

清理临时文件：rm -rf /tmp/*

journalctl --vacuum-size=100M      # 限制 systemd 日志大小journalctl --vacuum-time=7d        # 清理 7 天前的日志

rm

find

xargs

find /path/to/directory -type f -print0 | xargs -0 rm -f

4.2 处理“已删未释”的僵尸 Inode

如果文件已被 rm 删除，但 df -i 显示使用率仍为 100%，说明文件仍被进程占用（如日志服务正在写入）。

•查找占用进程：lsof +L1 或 lsof | grep deleted•释放 Inode：重启对应服务（如 systemctl restart rsyslog），或在极端情况下 kill -9 <PID> 强制结束进程。

五、 长期预防与架构优化

Inode 耗尽通常是“治标不治本”的，需从源头控制小文件爆炸：

1.配置日志轮转：为 /var/log 配置 logrotate，启用 maxage 和压缩选项，防止历史日志堆积。2.挂载 tmpfs：为 /tmp 挂载 tmpfs 并设置大小上限，重启后自动清空。3.优化定时任务：检查 crontab，禁用高频无意义任务，或将标准输出重定向至 /dev/null。4.合理规划文件系统：新建存放海量小文件的分区时，可使用 mkfs.ext4 -T small 或切换至支持动态 Inode 分配的文件系统（如 XFS、Btrfs）。5.设置监控告警：将 df -i 纳入监控体系，当 Inode 使用率 > 80% 时触发告警，防患于未然。