Linux磁盘有空间却写不进？inode排查

网站上传文件失败，程序无法创建缓存，终端提示：

No space left on device

但执行 df -h 后，却发现磁盘还有不少可用空间。

这种情况除了需要确认实际写入位置，还应检查文件系统的 inode 是否已经耗尽。大量体积很小的缓存、会话或临时文件，可能在磁盘容量用完之前，先耗尽可用 inode。

本文介绍如何判断 inode 问题、定位文件数量异常的目录，并在处理后验证业务是否恢复。

1. inode是什么？为什么磁盘没满也会报错？

在 ext4 等常见 Linux 文件系统中，inode 用于记录文件的类型、权限、时间戳和数据位置等元信息。文件内容占用的空间，与 inode 资源需要分别考虑。

可以先区分两个问题：

一个体积很大的普通文件，可能占用大量数据空间；大量小文件则可能占用很多 inode。

因此，磁盘还有剩余容量，并不代表一定可以继续创建新文件。

inode 耗尽只是写入失败的原因之一，不能看到 No space left on device 就直接认定是这个问题。

2. 排查前先确定实际目录

本文命令适用于 Debian、Ubuntu 等使用 GNU 工具的 Linux 系统，在服务器终端中执行。

示例使用以下路径：

/var/www

请将其替换为发生写入错误的实际目录，例如网站上传目录、应用缓存目录或日志目录。

如果报错文件尚未创建，应检查它所在的、已经存在的父目录。

涉及目录遍历时使用具有 sudo 权限的账户；已经使用 root 登录的，可以省略命令前面的 sudo。

在莱卡云 Linux 云服务器上遇到同类问题，也可以按本文顺序检查。

查看官网购买链接： https://www.lcayun.com

9折优惠码：bloglcayun

3. 同时检查容量、inode和挂载位置

首先执行：

df -h /var/www
df -i /var/www
findmnt -T /var/www -o TARGET,SOURCE,FSTYPE

三条命令分别用于：

1. 查看该目录所在文件系统的容量。
2. 查看该文件系统的 inode 使用情况。
3. 确认目录对应的挂载点、来源和文件系统类型。

findmnt -T 可以根据文件或目录路径查找其所属文件系统，适合避免检查到错误的数据盘。

3.1 查看磁盘容量

在 df -h 输出中，重点关注：

• Avail：可用容量。
• Use%：容量使用率。
• Mounted on：挂载点。

例如，网站实际位于独立的 /data 文件系统上，就应检查 /data，不能只看根文件系统 /。

3.2 查看inode使用情况

在 df -i 输出中，重点关注：

df -i 显示的是 inode 信息，而不是磁盘数据块容量。

如果同一个文件系统同时出现：

• df -h 仍有可用容量；
• df -i 的 IFree 为 0；
• 新文件创建失败；

就应重点排查 inode 耗尽。

判断时同时看剩余数量，不要只看整数百分比。 百分比存在取整，显示 100% 时也需要核对 IFree。

不同文件系统的 inode 分配和统计方式存在差异；如果相关字段不提供有效数值，需要结合实际文件系统继续判断。

4. 找出哪些目录占用了大量inode

查找大文件时经常使用：

du -sh /var/www

但这主要关注空间占用。排查大量小文件时，可以改用：

sudo du --inodes -x -d 1 /var/www | sort -n

参数含义：

GNU du 的 --inodes 选项就是用于查找文件较多、inode占用较高的目录。

输出左侧的数字是 inode 统计值，不是文件大小。目录本身也会参与统计；硬链接等情况会影响它与文件名数量的对应关系。

父目录这一行包含子目录汇总，不要将父目录和所有子目录的数值再次相加。

4.1 逐层进入占用较高的目录

如果发现 /var/www/site 占用较高，继续执行：

sudo du --inodes -x -d 1 /var/www/site | sort -n

如果进一步定位到 cache：

sudo du --inodes -x -d 1 /var/www/site/cache | sort -n

按照这个方式逐层检查，比直接列出整个服务器的所有文件更容易判断来源。

这里的路径只是示例，应根据上一条命令的实际结果继续排查。

-d 1 只限制显示层级，统计仍会遍历子目录中的内容。 文件数量很大时，执行可能较慢，建议避开业务高峰，并留意权限错误。

4.2 业务目录没有异常怎么办？

inode 是整个文件系统共享的资源。报错的网站目录本身文件不多，也可能受到同一文件系统中其他目录的影响。

如果第三节确认目标文件系统挂载在 /，可以扩大检查范围：

sudo du --inodes -x -d 1 / | sort -n

如果实际挂载点是 /data，则使用：

sudo du --inodes -x -d 1 /data | sort -n

根据实际挂载点选择其中一条，再逐层定位占用来源。

5. 找到大量小文件后怎么处理？

先确认这些文件属于哪个程序，以及为什么持续产生。

常见来源包括：

可以先抽查一个普通文件的路径：

sudo find /var/www/site/cache \
  -xdev -maxdepth 1 -type f -print -quit

再检查这个文件的属性。下面的文件名需要替换成实际结果：

sudo stat /var/www/site/cache/example.cache

结合文件名、所有者、修改时间和应用配置，判断这些文件是否确实属于可清理内容。单凭“文件很旧”或“数量很多”，不能确定它们没有用途。

5.1 优先使用应用自己的清理功能

确认属于过期缓存后，优先使用应用提供的后台清理功能或维护命令，并保留缓存目录需要的权限。

会话文件清理可能影响用户登录；任务队列文件可能仍有待处理业务。数据库目录、用户上传文件和队列数据，应按对应软件的维护方式处理。

如果清理任务依赖 Cron，但长期没有运行，可以参考本站的 Linux定时任务不执行怎么办？Cron常见问题排查。

5.2 同时处理文件持续增长的原因

清理只能释放当前占用。如果程序仍在异常生成文件，inode 很快可能再次耗尽。

应继续检查：

• 清理功能是否被关闭。
• 文件保留时间是否过长。
• 程序是否陷入失败重试。
• 是否每次请求都会创建新文件。
• 队列处理程序是否正常工作。

5.3 删除后统计没有改善怎么办？

先确认清理的是报错文件系统上的文件，再检查文件是否仍被进程打开，或者是否存在其他硬链接。

可以继续参考本站的 Linux删除文件后磁盘空间不释放怎么办？，核对进程引用和统计范围。

6. 处理后如何确认恢复？

重新检查相同路径：

df -h /var/www
df -i /var/www

重点确认：

• IFree 是否已经恢复到有余量的状态。
• 可用容量是否也足够。
• inode使用数量是否仍在快速增长。

如果刚才定位到了具体缓存目录，还可以再次统计：

sudo du --inodes -x -d 1 /var/www/site/cache | sort -n

随后进行一次实际业务验证，例如：

• 上传一个小文件。
• 打开原来报错的页面。
• 执行一次正常的缓存写入。
• 检查应用日志是否还有同类错误。

业务验证应使用应用实际的运行身份。root能够创建文件，并不能单独证明网站进程也具有正确的写入权限。

确认恢复后，再观察一段时间的 inode 增长情况。

7. 常见问题

7.1 删除一个大文件，能解决inode不足吗？

删除大文件通常更有利于释放容量。对于普通单文件，它不会因为体积大，就释放成千上万个 inode。

inode不足时，应优先找到数量异常的文件来源，再按业务规则处理。

7.2 直接扩容磁盘就可以解决吗？

不能只看云平台显示的磁盘容量。

是否增加可用 inode，与文件系统类型、布局及文件系统扩容是否完成有关。扩容后仍需重新执行 df -h 和 df -i，确认实际变化。

如果根因是应用无限生成小文件，还需要修复生成和清理机制。

7.3 容量和inode都正常，为什么仍然写入失败？

先确认程序实际写入的目录，包括临时目录，再根据完整错误判断：

例如，网站目录空间充足，但程序先将上传内容写入 /tmp，仍需检查 /tmp：

df -h /tmp
df -i /tmp
findmnt -T /tmp -o TARGET,SOURCE,FSTYPE

如果错误发生在 Docker 容器中，还需要确认容器内路径对应的是可写层还是挂载目录，再检查相应存储位置。

8. 写在最后

Linux磁盘有空间却无法创建新文件时，应同时检查容量和 inode，并确认检查的是程序真正写入的文件系统。

发现 inode 不足后，使用 du --inodes 逐层定位文件数量异常的目录，确认文件用途，再通过对应应用的清理方式释放资源。

日常维护时，将可用容量、剩余 inode 和文件增长速度一起纳入监控，并检查缓存、会话和临时文件的清理机制，能够更早发现这类问题。