服务器突然报“No space left on device”但用df -h看磁盘还有不少剩余这种矛盾现象在 Linux 上通常是 inode 耗尽了。换句话说磁盘块没用完但文件系统用来记录文件元数据的索引节点已经满了。下面按我平时排查的顺序把思路和操作步骤整理出来。先用 df -i 确认是不是 inode 满遇到无法写入文件时不要急着清理磁盘先同时看两个命令的输出。当服务器提示“No space left on device”但用df -h查看磁盘空间还有剩余时首先要怀疑 inode 已经耗尽。可以通过df -i命令查看文件系统 inode 的使用情况如果 IUse% 接近 100%说明 inode 满了。此时即使磁盘还有空间也无法创建新文件、目录或软链接因为每个文件都需要占用一个 inode。这一步要重点看挂载点对应的文件系统比如根分区/或数据盘/data。如果df -i显示某个挂载点已用 100%而其他分区还有余量那问题就局限在这个分区上。接下来要做的不是清空磁盘而是找出哪里堆积了大量小文件。按目录统计文件数量缩小排查范围inode 被占满本质上就是文件数量太多。要快速定位是哪个目录占用了大量 inode可以使用 for 循环配合 find 命令统计每个子目录的文件数量。例如先进入根目录然后执行for dir in */; do echo -n $dir: ; find $dir -xdev | wc -l; done按输出排序找出文件数最多的目录。注意使用-xdev避免跨文件系统统计防止把其他挂载点也算进来。这个循环会列出根目录下每个一级子目录的文件总数输出结果可能很多建议重定向到文件再排序比如把命令输出到/tmp/count.txt然后执行sort -t: -k2 -n /tmp/count.txt | tail只看文件数最多的几个目录。对于数据盘同样进入该挂载点执行类似命令。这一步往往能快速暴露出问题目录比如/var/spool、/tmp或者某个应用的数据目录。注意find会统计目录本身所以目录数会包含所有子目录和文件但这不影响排序比较。如果某个目录下文件数量异常比如有几百万个基本就能确定 inode 消耗的大头。检查小文件堆积的常见位置找到目录后先别急着删观察一下里面是什么类型的文件。常见的堆积场景包括邮件队列、PHP 会话文件、Nginx 的 proxy_temp、Squid 缓存以及未配置轮转的日志。可以用find /可疑目录 -type f | wc -l统计文件个数再用ls -l --time-stylelong-iso /可疑目录 | head查看最近文件的时间。如果文件时间集中在最近几小时说明有进程在持续写入如果时间很旧可能是历史遗留问题。有些目录看起来不大但文件数量惊人比如每个文件只有几 KB。这种场景下磁盘空间可能只用了百分之几但 inode 已经顶满。我遇到过/tmp下堆了上百万个 PHP 会话文件的情况也遇到过应用日志因为没配置 logrotate同一个日志目录里生成了几百万个滚动文件。重点检查/var/spool/mqueue、/var/tmp、/tmp以及 Nginx、PHP-fpm、Java 应用的临时目录和日志目录。需要结合你的业务和进程列表判断不能只看目录名就断定是垃圾。删除文件时的操作边界与验证方式确认占用目录后删除文件时要小心。直接rm -rf 目录可能导致服务中断或误删有用数据。建议先确认目录用途如果有进程正在写文件先停掉相关服务再清理。对于大量小文件可以分批删除比如find 目录 -type f -mtime 7 -delete避免一次性删除造成负载过高。删除后要确认 inode 使用率是否下降同时检查是否有进程持续产生新文件否则很快又会占满。在执行删除前先看目录属于哪个服务。比如/var/spool/postfix/maildrop是 Postfix 的邮件队列如果直接用rm -rf删掉整个目录可能破坏 Postfix 的目录结构导致服务启动失败。正确做法是先停掉相关服务保留目录本身只删除目录内的文件。对于大量小文件我习惯用find加-mtime或-size条件分批删比如先删三天前的旧文件观察系统负载正常后再删更近的。删除时注意看find命令是否卡住如果文件数量极大可能耗时较长。删除完成后立刻执行df -i确认 inode 使用率是否回落。如果使用率没有变化很可能有进程仍持有已删除文件的文件描述符需要重启该进程或服务。此时用lsof | grep deleted能找出还在占用已删除文件句柄的进程确认后重启对应服务inode 才会真正释放。如果 inode 只是略微下降说明还有另外的目录在持续产生文件需要回到上一步继续排查。几个容易被忽略的坑排查时要注意有些文件系统无法用 find 统计比如某些挂载点或只读文件系统。另外删除文件后 inode 不会立即释放如果文件仍被进程占用需要重启相关进程或服务。备份也不容忽视如果只用 tar 打包大量小文件tar 本身也需要创建文件可能因 inode 不足而失败。建议先清理足够空间或用流式压缩等方式绕过 inode 限制。这里补充两个实际场景。一是临时目录挂载了 tmpfs这种内存文件系统默认 inode 数量受内存限制但df -i会显示使用率如果内存足够一般不会满。二是 NFS 或网络存储上的文件系统inode 管理由服务端决定客户端df -i可能看不到真实情况需要登录存储侧确认。在清理空间不足的情况下tar 备份确实会遇到麻烦。如果来不及清理可以先用find 目录 -type f -delete把最旧的一批文件删掉留出 inode 余量后再做备份。但要注意如果业务还在写入删文件可能造成数据缺失所以备份前最好先暂停写入或者明确这些文件是临时文件。后续预防思路要避免 inode 再次耗尽可以从预留 inode 和监控入手。在文件系统创建时通过-i参数指定较高比例的 inode但已经格式化的分区无法直接调整只能重新格式化。日常运维中建议用监控工具跟踪 inode 使用率当超过 80% 时发出告警。对于日志和临时文件配置定期清理任务比如 logrotate 或 cron 定时删除超过 N 天的文件减少小文件堆积的可能。如果你用的是 ext4可以在 mkfs 时指定-i 16384每 16384 字节分配一个 inode来增加 inode 数量xfs 则可以通过mkfs.xfs -i maxpct50调整。但重新格式化意味着数据清空这个操作必须离线做不能在生产分区上直接尝试。更稳妥的做法是先清理现有文件再观察增长趋势。监控方面除了通用的 Zabbix、Prometheus也可以写一个简单的 shell 脚本每天执行df -i并判断使用率超过阈值就发送通知。最后再强调一个容易被忽略的点删除大量小文件时CPU 和磁盘 IO 都会上升尤其是在机械硬盘上可能短暂影响业务。建议把删除操作安排到业务低峰期并且用nice或ionice降低优先级。如果你遇到删除后 inode 使用率仍然不下降的情况优先检查是否有进程持有已删除文件的句柄而不是反复执行删除命令。