在 Linux 系统中，出现 no space left on device 错误并不一定代表磁盘容量已满。很多时候，使用 df 命令查看空间时仍然显示充足，但实际已经无法继续创建文件，这种情况通常与 inode 耗尽有关。本文将从 inode 与磁盘空间的关系出发，说明如何确认、定位并处理 inode 耗尽问题。
理解 inode 与磁盘空间的差异
在 Linux 文件系统中，存储资源不仅包含用于保存文件内容的数据区块，还包含用于记录文件元数据的 inode 节点。每个文件或目录在创建时都必须分配一个 inode，用来保存文件大小、权限、属主、时间戳以及指向数据区块的指针等信息。因此，即使数据区块仍然空闲，只要 inode 已经被分配完毕，文件系统同样会拒绝新的文件创建请求。
这也解释了为什么 df 显示空间充足但写入仍然失败。默认情况下，df 命令展示的是数据区块的使用率，而 inode 的使用情况需要通过 df -i 才能看到。很多场景中会存在海量小文件，例如日志碎片、缓存文件、临时会话文件或邮件队列，这些文件占用的字节数可能很小，但每个文件都会消耗一个 inode。当文件数量达到文件系统允许的 inode 上限时，就会出现“磁盘未满但无法写入”的现象。
理解这一区别是排查问题的前提。遇到 no space left on device 错误时，不应只关注容量剩余空间，还应同时关注文件数量与 inode 使用率。只有区分清楚数据区块耗尽与 inode 耗尽，才能采取正确的处理措施。
确认 inode 耗尽的方法与特征
当怀疑存在 inode 耗尽时，最直接的确认方式是执行 df -i 命令。该命令会列出每个挂载点的 inode 总数、已用数量、剩余数量和使用率。如果某个挂载点的 IUse% 接近或达到 100%，而普通 df 输出的空间使用率并不高，就可以基本确认问题来自 inode 耗尽。
下面是一个使用 df -i 查看根目录 inode 使用情况的示例。示例中根分区的 inode 使用率已经达到 100%，但此时磁盘数据区块仍可能留有余量。
# 查看各挂载点的 inode 使用情况 df -i # 示例输出 # Filesystem Inodes IUsed IFree IUse% Mounted on # /dev/sda1 655360 655350 10 100% /
除了直接查看 inode 使用率，还可以观察系统中是否存在大量小文件、目录项异常增多或某些目录文件数量快速上升等情况。例如，某个目录下出现数百万个几字节大小的文件，虽然总容量不大，但已经消耗了海量 inode。此时需要进一步定位这些文件集中的位置。
定位消耗 inode 的目录
确认是 inode 耗尽后，下一步要找出哪些目录保存了最多的文件。由于 inode 消耗与文件数量直接相关，可以从指定目录开始逐层统计各子目录中的文件数，并通过排序快速找到消耗 inode 最多的位置。
下面的脚本会从目标目录开始，统计每个一级子目录下包含的文件总数，并按数量从高到低输出前 20 个目录。脚本中的目标目录可以通过第一个参数传入，默认从根目录开始扫描。
#!/bin/bash
# 用法: ./inode_scan.sh /path/to/scan
# 统计各一级子目录下的文件总数，并输出前20个文件最多的目录
target_dir=${1:-/}
echo "正在统计 $target_dir 下各子目录的文件数量..."
find "$target_dir" -maxdepth 1 -type d | while read -r dir; do
# 统计该目录及其嵌套目录中的文件数量
count=$(find "$dir" -type f | wc -l)
echo "$count $dir"
done | sort -rn | head -n 20
echo "排查完成，请重点关注文件数量最多的目录"
在实际使用中，如果直接扫描根目录，耗时会比较长。可以先从常见的高风险目录入手，例如 /var、/tmp、/var/spool、/var/log 以及应用自身的数据目录。这样可以更快缩小范围。对于已经明确发生问题的挂载点，也可以把该挂载点作为扫描起点，避免无关目录干扰。
定位到文件数量最多的目录后，还需要进一步确认这些文件的具体类型、创建时间和是否仍在使用。可以使用 ls -l、find 配合时间条件或文件大小条件过滤，找出哪些文件已经过期、不再需要，从而判断哪些可以安全清理。
清理与预防措施
找到问题目录后，不要直接执行批量删除。应当先确认文件是否为垃圾文件、临时文件或已经轮转的旧日志。对于不再需要的文件，可以使用 find 配合 -type f 和 -mtime 等条件筛选后再删除。例如只删除超过一定天数未修改的临时文件，避免误删仍然活跃的会话或队列数据。
清理时要特别注意，某些服务在文件被删除后仍然占用文件句柄，此时磁盘数据不会立即释放，但 inode 会随着目录项删除而释放。对于日志类文件，如果进程仍持有句柄，删除后可能仍然占用磁盘空间。一般建议在删除后重启相关服务，或使用 truncate 方式清空文件，以确保空间真正释放。
针对长期预防，可以从以下几个方面入手：
- 为日志文件配置轮转策略，限制日志保留数量，并对旧日志进行压缩或清理；
- 对临时目录设置定时清理任务，删除过期会话文件、缓存文件和临时脚本；
- 监控 inode 使用率，设置告警阈值，在耗尽之前提前介入；
- 对于需要存储海量小文件的业务，评估是否适合调整文件系统类型或重新规划存储方案。
注意：删除文件前务必确认其无用，避免误删导致服务异常。
下面是一个简单的 inode 使用率监控示例。当根目录的 inode 使用率超过 90% 时，输出警告信息。该逻辑可以集成到定时任务或监控系统中。
# 当根目录 inode 使用率大于90%时输出警告
use=$(df -i / | awk 'NR==2 {print $5}' | sed 's/%//')
if [ "$use" -gt 90 ]; then
echo "警告: inode 使用率已达 ${use}%"
fi
监控脚本不应只执行一次，而应纳入周期性任务。通过持续观察 inode 使用率的变化趋势，可以在问题爆发前发现异常增长。例如，如果某个目录的文件数量在短时间内快速上升，即使当前没有耗尽，也应提前排查是否存在未轮转的日志、未清理的队列或程序异常写入。
总结与要点回顾
no space left on device 错误并不总是磁盘容量满导致的。在 Linux 中，inode 同样是一种有限的文件系统资源。当 df 显示空间充足但无法创建文件时，应优先使用 df -i 检查 inode 使用率。若 IUse% 接近 100%，就可以确认是 inode 耗尽。
排查过程可以分为三步：第一步确认 inode 使用情况，第二步统计目录文件数量定位热点目录，第三步确认并清理无用文件。清理后还应结合日志轮转、临时目录清理和 inode 使用率监控等措施，防止同样问题再次发生。
总体而言，处理这类问题的关键是不能只看磁盘容量，而要同时关注文件系统的 inode 资源。只有建立对文件数量增长趋势的长期监控，才能从根本上减少 inode 耗尽导致的写入故障。
inodedfno_space_left_on_deviceLinux排查脚本修改时间：2026-07-24 18:09:26