Linux磁盘满了怎么办：容量、inode与占用排查

保存文件、备份或数据库写入时提示 No space left on device，先确认失败路径所在的文件系统，再查容量、inode 和文件占用。不要看到“磁盘满了”就清空日志或重启服务器。

以下命令在服务器的 SSH 会话中执行，适用于使用 GNU df、du 的 Ubuntu、Debian 和 RHEL 系常见系统。使用有 sudo 权限的账号；已用 root 登录时可省略 sudo。本文的检查命令不会删除文件或重启服务。

1. 先确定哪一个挂载点出了问题

先查看整体容量和 inode 用量：

df -hT
df -i

然后检查报错文件所在的已有目录。下面以 /var 为例；如果备份写入 /data/backup，就把两行中的路径都换成 /data/backup。

df -hT /var
df -i /var

记下 Mounted on（挂载点）。返回 / 就查根文件系统；返回 /data 就查数据盘。另一块盘有空闲，不代表当前写入路径还有空间。

检查结果	应往哪里查
Avail（可用）接近 0，Use% 接近 100%	先按第 2 步找大目录和大文件。
容量尚有余量，但 IFree 为 0 或 IUse% 达到 100%	按第 3 步查大量小文件占用的 inode。
两项都有余量，应用仍报空间不足	核对应用实际写入路径、容器内挂载和账号配额，不要根据根盘剩余量直接下结论。

2. 从异常挂载点逐层找大目录

下面示范异常挂载点为 /，再逐层查到 /var/log 的过程。每次根据上一条输出选最大的子目录；实际结果不同时，要换成你自己的路径。

sudo du -xhd1 /
sudo du -xhd1 /var
sudo du -xahd1 /var/log

-x 不跨到其他文件系统，-d1 只显示当前目录和下一层的汇总，-a 同时列出这一层的文件。目录自身那一行是合计，不要再与子目录相加。

如果 /var 是独立挂载点，查根盘时会跳过它，应单独查询。Permission denied 等报错表示统计可能不完整，不能把未读到的目录当成零占用。文件多时扫描需要时间；不要同时反复跑全盘扫描，按 Ctrl+C 中止后的输出也不是完整结果。

3. 容量没满，为什么仍无法创建文件

inode 是文件、目录使用的索引资源。大量缓存、会话或临时小文件可能先耗尽 inode。对第 1 步查出的挂载点执行下列命令；这里仍以 / 为例：

sudo du --inodes -x -d1 /

左侧是 inode 计数，不是字节。进入计数最大的子目录，重复同一命令，直到找到具体应用目录。若提示不支持 --inodes，记录 du --version，按当前版本的工具能力继续核查，不能拿目录容量代替 inode 数量。

找到目录后，确认是哪套程序在持续生成文件，再使用该程序的过期清理或保留规则处理。只删少量旧文件、却没有处理持续增长的来源，问题容易再次出现。

4. 文件删了，空间却没回来

df 显示文件系统的空间状态，du 统计当前能遍历到的文件。文件被删除后，如果进程仍持有它，目录里看不到它，空间仍可能被占用。检查这类文件：

sudo lsof -nP -s +L1

+L1 筛选链接数为 0、仍被打开的文件；-s 让大小列显示为 SIZE。若只检查根文件系统，可改用下面的命令；其他挂载点替换最后的 /。

sudo lsof -nP -s +aL1 /

重点看 PID、NAME 和 SIZE。同一文件可能出现在多行，文件大小也不等于可回收的物理空间，不能直接把这一列相加。命令无输出、缺少权限或出现警告时，都不能仅凭这一项判定磁盘正常。

将下面的 1234 换成查到的 PID，确认进程用途；使用 systemd 的系统还可查询它所属的单元：

ps -p 1234 -o pid,user,comm,args
sudo systemctl status 1234 --no-pager

如果显示的是会话或容器范围，而非明确的业务服务，应先查清应用由谁管理。确认是日志占用后，优先按应用支持的方法重新打开日志；确需重启时，安排业务维护后正常重启对应服务，再复查空间。不要仅凭 PID 强杀进程。

lsof: command not found 表示未安装工具，不代表没有此类文件。磁盘已满时，先保存前面检查的结果，不要反复尝试安装软件。

5. 按找到的原因处理，再核对结果

已定位的占用	下一步
已确认不再需要的旧备份	先复制到其他存储、核对校验值并确认可恢复，再按保留规则处理原文件；移到同一文件系统的另一个目录不会释放空间。
日志或缓存持续增长	查明异常增长原因，设置对应应用的轮转、过期和保留上限。
数据库或正常业务数据增长	从应用内部安排归档、清理或扩容，不要手动删除数据库数据文件。扩容先核对分区与文件系统；ext4 数据盘扩容教程仅适用于对应布局。

处理后，对同一实际写入目录重新运行 df -hT 和 df -i，并重试之前失败的一次正常业务操作。确认可用容量或 inode 恢复、业务不再报错，再观察占用是否继续异常增长。

仍无法定位时，提交报错时间、失败路径、对应挂载点、两项 df 输出、占用最大的目录和相关 PID。命令行及路径可能含账号、连接串或业务名称，按日志脱敏指南处理后再提交工单。

技术依据：GNU Coreutils 的 df、du 手册，lsof 官方手册及 systemd 的 systemctl 手册。核对日期：2026 年 11 月 4 日。