大文件定位：磁盘空间都去哪了
青梅煮雪
4 min read
df -h 告诉你磁盘快满了，但没说满在哪儿。真正要定位"是谁吃了空间"，靠的是从根目录往下逐层看占用，而不是凭感觉去翻目录。思路就一句：从大到小、逐层下钻。看到是哪一个挂载点满，再进那个分区里按目录排占用，一层层逼近元凶，比直接全局扫一遍快得多，也更能避开权限和挂载带来的干扰。
第一步：确认哪个挂载点满了
df -h
输出里 Use% 接近 100% 的那一行就是问题挂载点。先确定是 /、/home 还是某个数据盘，别在错误的分区里白找。一个常见错觉是盯着 / 发愁，其实满的是 /var 或某个独立挂载的数据盘，从根目录搜半天一无所获。先 df 定锚，后面所有 du 都限定在这个挂载点内。
第二步：按目录看占用排前三
du -h --max-depth=1 /var 2>/dev/null | sort -rh | head -5
du 统计目录实际占用，--max-depth=1 只看一层，sort -rh 倒序排人类可读大小，head 取前几名。哪一行最大，就 cd 进去对它的子目录再跑一遍同样的命令。这种"看一层、进一层"的下钻，比一次性 du -sh /* 更稳，也不会因为权限不足的目录报错中断。误区是贪快用 du -sh /* 一把梭，遇到 /proc、/sys 这类虚拟文件系统会扫出无意义数据甚至卡住，还可能在无权限目录上满屏 Permission denied 噪声。
第三步：找单个大文件
find /var -type f -size +100M -exec du -h {} + 2>/dev/null | sort -rh | head
这条在 /var 下找大于 100M 的普通文件并排大小。+100M 是阈值，可按量级调整：先查 +1G 快速定位巨头，再降档查 +100M 找中等块头。经验上，吃空间的常客是日志（/var/log）、包缓存、容器镜像分层、还有被删但仍被进程占用的文件。日志类尤其喜欢"无声膨胀"——某个服务把 debug 开了一周，日志就能吃掉几十 G，而它往往藏在子目录深处。
一个隐形陷阱：已删但被占用的文件
lsof +L1 2>/dev/null | awk '$5=="REG"' | sort -k7 -rh | head
有时 du 看着不大、df 却显示满，原因是文件被 rm 了但打开它的进程没退出，磁盘块没真正释放。上面这条列出"链接数为 0 但仍被打开"的已删文件。找到对应 PID，重启或杀掉那个进程，空间才回来。这是只删文件却腾不出空间的典型原因，常见于日志轮转配置失效、或进程持有着已被删除的临时文件句柄。光 rm 不够，必须让持有者释放。
几个边界
du 统计的是文件实际占用的块，和 ls -l 显示的"逻辑大小"可能不同，稀疏文件差异尤其大，别拿 ls 的大小当占用。网络挂载目录（NFS 等）跑 du 会很慢甚至卡死，应限定在本地文件系统。容器环境下，宿主机看到的大目录可能是镜像层共享，删容器前先确认是不是可写层在涨，误删只读镜像层既腾不出空间又可能破坏其他容器。还有 inode 耗尽：df 显示空间还有，但写文件报"设备上没有空间"，那是 inode 用光了，用 df -i 单独看 inode 使用率。
定位空间问题的核心不是某个神奇命令，而是"挂载点 → 目录下钻 → 单文件 → 已删占用 → inode"这条有顺序的排查链。
1 view
0 likes
0 comments