df -h找到 Use% 接近 100% 的挂载点。
磁盘满了怎么查
约 1267 字大约 4 分钟
2026-05-14
磁盘满了——服务写不进日志、数据库报错、上传失败。这是个有固定套路的问题：df 定位是哪个分区、du 下钻找膨胀目录、清理前确认数据可不可再生。这篇是一份照着走的实战清单，背后的原理见 磁盘空间排查。
阅读导览
磁盘满了怎么查
按 df 定位分区、du 下钻目录、确认数据可再生再清理的固定流程处理磁盘满，并覆盖 inode 耗尽和“删了不释放”两个坑。
- df 定位是哪个分区满了
- du 逐层下钻找膨胀点
- 空间没满也可能 inode 满了
- 清理前确认数据可不可再生
命令速查
磁盘满排查清单
照着走du -h --max-depth=1 /满的路径顺着最大的子目录一层层往下追。
df -ih空间没满却写不进，看 IUse% 是不是 100%。
lsof +L1df 满 du 找不到时，是文件被删但进程还占着。
第一步:df 定位是哪个分区
df -h找到 Use% 接近 100% 的那一行，记住它的挂载点。注意 df 每行是一个挂载点——/var 单独挂载时，它满了和根 / 是两回事。定位错分区，后面全白费。
第二步:du 在那个分区里下钻
对着满的那个挂载点，逐层往下找：
du -h --max-depth=1 /var # 看 /var 下每个子目录多大
# 发现 /var/log 最大 →
du -h --max-depth=1 /var/log # 继续下钻别一上来 du -h / 全盘扫——慢，输出还乱。用 --max-depth=1 一层层缩，顺着最大的往下追。常见元凶：失控的日志、堆积的缓存、忘删的临时文件、数据库的 WAL/binlog。
第三步：空间没满，查 inode
如果 df -h 显示还有空间，但写文件却报 No space left on device，查 inode：
df -ih # 看 IUse%，到 100% 就是 inode 耗尽inode 满，元凶通常是某个目录堆了海量小文件（session、邮件队列、缓存碎片）。这种情况删几个大文件没用，要清的是那堆小文件。
第四步:df 满但 du 找不到
df 说满着，du 怎么找都找不到大文件——是有文件被删了但进程还占着，空间没释放：
lsof +L1 # 列出已删但仍被占用的文件找到那个进程，重启或重载它（让它松开文件句柄），空间才回来。最典型：服务还在往一个被 rm 掉的日志文件里写。
第五步：清理，但要克制
定位到元凶，清理前停一秒问自己：这东西删了能不能再生？
- 可清：旧日志（优先用
logrotate、journalctl --vacuum-time=7d，而不是手动rm）、缓存、临时文件 - 慎清：数据库文件、用户数据、还在被进程写的文件
正在被进程写的文件不要直接 rm——会触发上面第四步的“删了不释放”。应该先停 / 重载那个服务，或用 truncate -s 0 file 就地清空（如果服务支持）。
磁盘满时最容易慌着乱删
磁盘满会引发一连串告警，人一急就容易 rm 错东西。守住几条：① 删之前 ls -lh 看清是什么、lsof 看有没有进程在用；② 优先用 logrotate、--vacuum-time 这类正规手段，别手动 rm 日志；③ 数据库目录、/var/lib 下不认识的东西一律先查清归属再说；④ 临时腾空间可以，但根因(日志没轮转、某服务疯狂写)不解决，过几天还会满。
常见误区
| 误区 | 更稳妥的做法 |
|---|---|
跳过 df 直接 du -h / 全盘扫 | 先 df 定位分区，再 du 在那个分区下钻 |
| 空间没满写不进就以为是别的问题 | df -ih 查 inode 是不是满了 |
| df 满 du 找不到大文件就放弃 | lsof +L1 找已删但被进程占用的文件 |
| 慌着 rm，且不解决根因 | 确认数据可再生再清，并修掉“为什么会满”的根因 |
实践清单
练习清单
- 1对一台机器跑 `df -h`，找出使用率最高的挂载点。
- 2对那个挂载点用 `du -h --max-depth=1` 逐层下钻，定位最大的子目录。
- 3跑 `df -ih`，理解 inode 使用率和空间使用率是两个独立的指标。
- 4了解 `lsof +L1` 的用途，以及为什么正在被写的日志文件不能直接 rm。
重点总结
要点回收
- 固定流程：df 定位分区 → du 逐层下钻 → 找到膨胀点。
- 空间没满写不进查 df -ih（inode）；df 满 du 找不到用 lsof +L1（已删占用）。
- 清理前确认数据可再生，优先用 logrotate 等正规手段，正在被写的文件别直接 rm，并修掉根因。
版权所有
版权归属：Shuo Liu