场景概述
根分区或数据盘使用率冲到 95% 以上时，失败会级联：日志写不进去、数据库无法提交、容器建不了临时文件，报错文本通常是 No space left on device。此时需要先分清三类占用——真实的大文件、被删除但仍被进程持有的句柄、以及持续增长的日志与数据文件。三者的定位手段与处置方式完全不同，先量化再动手，避免删掉一堆文件却发现空间没释放。
场景信息
| 触发条件 | df 显示某挂载点 Use% 达到 90% 以上，或应用报 No space left on device |
|---|---|
| 排查目标 | 定位真实占用者，用最小代价释放空间并保留证据 |
| 工具链 | df（定挂载点）→ du（定目录）→ find（定文件）→ lsof（定句柄）→ 处置与验证 |
| 两个方向 | 块空间（df -h）与 inode（df -i）会分别耗尽，报错相同但处置不同 |
常见成因
- 应用日志没有轮转，或轮转后没有清理历史文件，单个日志涨到几十 GB
- 文件被删除但进程仍持有句柄：目录项消失了，inode 与数据块要等句柄关闭才释放
- 数据库与中间件的数据文件增长，例如 binlog 未设过期、WAL 堆积、备份文件留在数据盘
- 临时目录被批处理写满：/tmp、/var/tmp 上的导入导出中间文件没有清理策略
- 容器运行时残留：旧镜像层、已退出的容器日志、overlay2 目录持续膨胀
- 小文件数量爆炸导致 inode 耗尽，此时 df -h 仍有空间但无法新建文件
五步排查命令
五步排查命令
# 第 1 步：确认哪个挂载点满（块与 inode 都要看）
df -hT; df -i
# 第 2 步：逐层定位大目录（-x 不跨文件系统）
du -x -h --max-depth=1 / | sort -rh | head -n 12
# 第 3 步：找大文件，不跨文件系统
find / -xdev -type f -size +1G -printf '%s %p\n' 2>/dev/null | sort -rn | head -n 20
# 第 4 步：检查已删除但仍被持有的文件
lsof +L1 2>/dev/null | awk '$7>1000000000 {print}' | head
# 第 5 步：处置——日志类用截断，句柄类让进程重开文件
: > /var/log/huge.log
systemctl restart app.service
# journal 日志单独限量
journalctl --disk-usage; journalctl --vacuum-size=500M信号判读与处置
| 现象 | 说明 | 下一步 |
|---|---|---|
| df -h 某挂载点 Use% 高 | 块空间不足 | 进该挂载点用 du 逐层下钻 |
| df -i 使用率 100% | inode 耗尽，块空间可能还有余量 | 找小文件密集目录，而非找大文件 |
| df 已用远大于 du 合计 | 存在 deleted 句柄或容器 overlay 层 | 用 lsof +L1 定位持有进程 |
| lsof +L1 列出大文件 | 文件已删但句柄未关，空间未释放 | 重载或重启持有进程，或让它重开日志 |
| find 列出散落大文件 | 真实存在的占用 | 确认业务归属后再删除或迁移 |
用 : > file 截断日志会立即释放空间，且 inode 与文件句柄保持有效。以 O_APPEND 方式打开的日志会继续从新末尾追加；其他打开方式会保留原偏移，新内容写在原位置，文件出现空洞（du 明显小于 ls -l 显示的大小）。最稳妥的处置是让服务重新打开日志文件：reload、发信号或重启。
不要在未确认归属前删除数据库文件、备份文件或运行中的日志。删除正在写的日志目录项时，空间不会释放，应用还会继续向已删文件写入；先截断，再让服务重开文件。
容器与日志类占用的定量方法：docker system df 分别列出镜像、容器、卷与构建缓存的大小，docker system prune 回收未使用的镜像层与已停止容器。容器标准输出会落到 /var/lib/docker/containers/ 下的 json 日志文件，单个文件涨到几十 GB 很常见，配置 log-opts 的 max-size 与 max-file 可以根治。systemd 日志占用则用 journalctl --disk-usage 查看、--vacuum-size 回收。