Fork me on github

对集群上 df 和 du 命令显示结果不一致的排查记录

目录

对集群上 df 和 du 命令显示结果不一致的排查记录

背景

在集群上跑作业,然后把磁盘空间吃掉了。把占用空间很大的文件删掉后,du /home 命令的结果显示磁盘占用已经回到了正常水平,但是 df -h 显示,/home 所在分区的磁盘占用率还是 100%,也不能新建和修改文件。

猜想

不会是把文件系统弄坏了吧!

仔细想了想好像不可能,因为平时都是用普通用户的身份工作的……不太可能搞出影响文件系统的操作。

有些人的小文件太多,把 inode 给用光了!

看起来有可能,但是回想下很久很久以前自己做赛博仓鼠的时候遇到的问题,就会发现两个问题表现完全不一样。

很久很久以前,赛博鼠鼠 jyi 试图往自己的鼠鼠洞里塞图片,发现没有磁盘空间了!他 df 了下,发现硬盘空间还有很多,但是新建文件就是会出错。他又试了试往已有的文件后面追加写入一些东西,好像可以成功。他觉得非常奇怪,“凭什么磁盘有空间,但是就是不让我放东西呢?”

用一种比较笨蛋的方法来看 ext{2,3,4} 文件系统,就知道文件系统中,一个文件需要 1 个 inode 和许多许多 block。其中,inode 用来存放文件的元数据,block 用来存放文件本身。由于 block 数量一般多于 inode 的数量(block 的数量少于 inode 的数量有啥用啊……),所以可能会出现 inode 耗尽,而 block 有剩余的情况。在这种情况下,无法新建文件,却可以修改文件。

因为赛博鼠鼠 jyi 非常菜,所以他与电脑搏斗了一番后才想起关于 inode 的知识。他 df -i 了一下,发现自己要存放图片的文件系统的 inode 已经用光了。最后他把一些图片打包成 sfs,再挂载到世界树目录树上,从而在原本的文件系统里回收了一些 inode,终于解决了这个问题。

回到集群上来,为什么这个表现和集群上遇到的状况完全不一样呢?因为经过检查发现,集群上显示 df -i 不是 100%,df -h 显示的使用率是 100%;而很久很久以前和自己的电脑搏斗时,df -i 显示的使用率是 100%,df -h 则是比 100 小不少的数字。

这说明集群上很可能不是很多小文件把 inode 用光的问题,更可能是巨大文件很简单地把 block 用光的问题。

有一些邪恶文件藏在了黑暗角落里!

Linux 下面是可以往非空目录上挂载文件系统的,挂载后原目录里有的文件将会被遮盖掉。这些文件显然会被 df 统计,但是不会被 du 统计。

显然,最简单的方法就是把根目录之外的所有目录卸载,然后跑一下 dfdu。然而,现在要操作的是运行中的系统(也许还有同学在上面跑神秘程序,那种中断了会遭遇线下真人快打的),不能这么粗暴地处理……

最后我找了个 tmpfs /run/mnt(因为根目录下没法新建文件夹做挂载点了),然后 mount --bind / /run/mnt。接着进 /run/mnt 一看,发现 dfdu 的结果仍然不同!仍然是 du 很少一点,df 巨大无比的结果。

破案

正在自闭时,突然想起来,好像学文件系统时在懵懵懂懂的时候学到了 Linux 下 inode 结构体里,有关 i_counti_nlink 的知识。其中,i_count 代表当前有多少个文件描述符引用了这个文件,i_nlink 代表这个文件在文件系统里有多少个硬链接。当且仅当 i_counti_nlink 都为零时,这个 inode 和她所持有的 block 才被会释放。有没有这种可能,一个神秘邪恶,吃光了磁盘的巨大文件,它的 i_nlink 是 0 同时 i_count 非零,这样它不会被递归查看文件名的 du 找到,但是能被统计 block 的 df 给检查到呢?

于是使用 lsof | grep deleted 一查,果然有一堆坏比 Perl 程序,打开了巨大文件没关。文件的所有者是我,大小有 780G。考虑到集群上好像只有我写 Perl,所以主谋是谁应该不言自明了……

结局

使用天火圣裁发动了一次牛逼的攻击……其实是 ps -u jyi,把自己所有的进程,不管好比还是坏比都干掉了。然后 df 了几次,看着可用空间逐渐上涨。

问题最终解决了,可喜可贺可喜可贺。另外给好朋友说这个事时,还听说在 “进程打开了文件,但是文件不小心删掉了” 这种情况下,在进程关闭之前,可以去 /proc/X/fd/Y 下面把文件找回来。其中 X 是进程 pid,Y 是软链接,名字就是文件描述符,目标是被打开的文件,用 cat 命令就可以把文件给找回来。利用的也是 inode 释放的机制。

总之,Linux 真神奇啊 :3

posted @ 2022-11-19 00:36  jyi2ya  阅读(133)  评论(0编辑  收藏  举报
回到顶部