df -h第一步:列出每个挂载点的容量和使用率,找到满的那个。
约 1386 字大约 5 分钟
2026-05-14
“磁盘满了”是运维最常见的告警之一。排查它有一条固定路线:先用 df 定位是哪个分区满了,再用 du 一层层下钻找到膨胀的目录。但中间还藏着两个坑——inode 也会满、文件删了空间却不释放。这篇把整条路线讲清楚。
掌握 df 定位分区、du 下钻目录的排查路线,理解 inode 耗尽和“删了文件空间不释放”这两个反直觉情况。
df -h第一步:列出每个挂载点的容量和使用率,找到满的那个。
df -ih空间没满却写不进,可能是 inode 耗尽,用这个查。
du -h --max-depth=1 /var看某个目录下每个子目录占多少,顺着最大的往下追。
lsof +L1df 满 du 却找不到时,是文件被删但进程还占着。
df -h 列出所有挂载点的使用情况。先看清是哪个分区满了——是根 /、是 /var、还是单独挂的数据盘?
df -h
# Filesystem Size Used Avail Use% Mounted on
# /dev/sda1 50G 48G 0.5G 99% /注意:df 的每一行是一个挂载点,不是一块物理盘(见 挂载与 fstab)。/var 单独挂载时,它满了不影响 /。定位到具体分区,才知道下一步该 du 哪里。
知道哪个分区满了,用 du 在那个分区里一层一层往下找膨胀点:
du -h --max-depth=1 / # 看根下每个目录多大
# 发现 /var 最大 →
du -h --max-depth=1 /var # 再下钻一层
# 发现 /var/log 最大 →
du -h --max-depth=1 /var/log # 继续,直到找到具体的大文件 / 目录关键是别一上来就 du -h / 全盘扫——慢,输出还多。用 --max-depth=1 一层层缩,顺着最大的那个往下追,几步就能定位到元凶。常见元凶:失控的日志文件、没清理的缓存、忘了删的临时文件。
有时 df -h 显示还有空间,但创建文件却报 No space left on device。这是 inode 耗尽——每个文件都要占一个 inode,海量小文件会把 inode 用光,哪怕字节空间还有富余。用 df -ih 查:
df -ih
# IUse% 到了 100% → inode 满了元凶通常是某个目录里堆了几百万个小文件(如 session 文件、邮件队列、缓存碎片)。
df 显示磁盘满着,但 du 怎么找都找不到大文件——这是因为某个文件被删除了,但还有进程开着它。在最后一个进程关闭它之前,空间不会释放(原理见 inode、硬链接与软链接)。
lsof +L1 # 列出链接数为 0(已删)但仍被占用的文件
lsof | grep deleted找到那个进程后,重启或重载它(让它松开文件句柄),空间才真正回来。最常见的场景:服务还在往一个已经被 rm 掉的日志文件里写。
清理磁盘前先确认数据可不可再生
磁盘满了让人手忙脚乱,但 rm 之前务必停一秒确认:这个文件 / 目录删了能不能恢复?日志、缓存、临时文件多半可再生,可以清;数据库文件、用户数据、还在被服务写的文件,删了就是事故。安全顺序:① 先 du 定位、ls -lh 看清是什么、lsof 看有没有进程在用;② 优先用 logrotate、journalctl --vacuum-time 等正规手段清日志,而不是手动 rm;③ 正在被进程写的文件不要直接 rm(会触发“空间不释放”),应该先停 / 重载那个服务。
| 误区 | 更稳妥的做法 |
|---|---|
一上来 du -h / 全盘扫 | 先 df 定位分区,再 du --max-depth=1 逐层下钻 |
| 空间没满写不进就以为是别的问题 | df -ih 查 inode 是不是满了 |
df 满但 du 找不到大文件就放弃 | 用 lsof +L1 找已删但被进程占用的文件 |
磁盘一满就慌着 rm | 先确认数据可不可再生,正在被写的文件先停服务再清 |
版权归属:Shuo Liu