Jason Pan

从磁盘满聊技术问题如何问、去哪问

潘忠显 / 2023-11-20


我有一个开发环境的 CVM,近期系统盘满。本篇小文从这个 VM 系统盘满的问题开始,通过介绍解决过程,少聊技术,多聊聊如何提问、去哪问、如何提高生产力,以及少少感触

一、逃避问题还是解决问题

我申请的 CVM 的规格是16核/32G内存/100G系统盘/500G数据盘。其实最近半年,这个 CVM 都会经常比较满,具体的就是 df -h 会看到磁盘利用率超过 90% 甚至达到 100%。

我的解决方法就是 du -sh 看看什么文件比较大,然后清理一下。因为我用 CVM 主要是用于构建,所以构建相关的文件会比较多:

但是,清理 Cache 的动作甚至都不能算个 WorkAround,再次拉取或者构建总会再填回来,治标不治本。

问题大到一定程度,逃避问题不是办法,解决掉它才能解放自己。

我就直接 du -sh * 一下看看具体哪个文件大,虽然有大文件,但自己算了算加起来也没有 df 显示的 100G 呀(实际使用只有不到 50G)。

df-no-space-but-du-has

术业有专攻,去找运维同学咨询一下会有什么可能造成这种情况。

运维同学提供的思路是,可能有 deleted 文件没有被释放:之前我也碰到过这种,删掉了大日志文件,但是有进程打开了这个文件但没有关闭,就不会释放空间。为了简单处理,直接重启了系统,现象依旧。

于是决定去外部再问问,走,Stack Overflow

二、被关闭的“坏问题”

整理一下已经做过的排查步骤和结果,在 Stack Overflow 进行提问,主要是列上:

贴在 Stack Overflow 上,没有多久就有反应了。只不过是 Down Vote,伴随着 Close 的投票。又一个,又一个。

Stack Overflow 有两个规则这里提一下:

问题被强制关闭了,而我还在觉着这个问题比较明确、详实。不能一删了之,因为那样既得不到问题的答案,最终也没搞清楚Stack Overflow的规则。

因此,我仔细看了一下被大家投票关闭的原因:大概的意思是说,这个问题不是关于编程或软件开发的(与特定的编程问题、软件算法或程序员主要使用的软件工具无关)。同时,他也提示可以去 on-topic 或者去其他 Stack Exchange 网站试试。

stackoverflow-close-tip

Closed. This question is not about programming or software development. It is not currently accepting answers.


This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. You can edit the question so it’s on-topic or see if it can be answered on another Stack Exchange site, but be sure to read the on-topic page for a site before posting there.

通过这些提示,在回忆一下之前在 Stack Overflow 上回答的问题确实都是关于特定编程语言的问题,以及搜索 Linux 问题确实大都被引导到 unix.stackexchange.com 上了。

stackoverflow-my-answers

三、Stack Exchange是什么

上边的提示中,说让去"another Stack Exchange site"问问。这句话有两个含义:

直接看看 stackexchange.com/sites 的面板,可以看到我们常用的一些网站,比如 Server Fault、Super User、Ask Ubuntu、Unix&Linux、Mathematics,都属于 Stack Exchange:

stack-exchange-sites

WikiPedia上介绍:Stack Exchange是一个由问答 (Q&A) 网站组成的网络,涉及不同领域的主题,每个网站都涵盖一个特定主题,其中问题、答案和用户都受到声誉奖励流程的约束。

Stack Exchange 自己的 About上介绍:Stack Overflow 和 Stack Exchange 网络可帮助人们在需要时找到所需的答案。 由包括 Stack Overflow 在内的 173 个问答社区组成,每月有超过 1 亿人访问提问、学习和分享技术知识。

四、问题得放对位置,人也一样

经过 Stack Overflow 的打击和提示,我弄懂了它和 Stack Exchange 的关系,不是所有的问题都可以放在 Stack Overflow 的——怎样,果然是个“老白码农在奋斗”吧?

于是,我将问题直接复制了一下,贴在了 Unix&Linux 上。反应一样很快,很快有了 Comment,甚至还有两个 Up Vote:

stack-exchage-comments

经过几个人的提示,我使用了 fsck 去检查了文件系统是否有问题。具体地使用 fsck -nf /dev/vda1 > fsck.log 将检查结果放到文件中,然后分析发现确实有很多文件系统问题:

然后尝试使用 fsck -a 来尝试修复,但是因为是被 mount 了,所以不能被修复。使用 fsck 修复文件系统的正常操作应该是先 umount 设备,然后再修复,最后再 mount 上。这种 CVM 不像我们手头的机器,可以用 live CD 登录,然后操作修复。所以这里只能找提供 CVM 的云产品的同学去处理。

这里让我有第1点感触:同样的一个问题,贴错了地方,被人 Down Vote 2下并关闭,贴对了地方被 Up Vote 两次,并基本顺利地排查到了根本问题。

打工人又何尝不是这样?把自己放错了地方,再怎么努力也可能背星;放对了地方,游刃有余又容易有产出。不管是主动还是被动地换位置,换对位置才能有好结果。

五、细思极恐的上帝视角

在 Stack Exchange 搞清楚原因之后,直接联系了云的同学,他们也是提示让 lsof、重启看看是否有变化。

我这边重点提示了**“是不是应该从VM的Host上去修复”**之后, 云同学说关机修复一下,过了段时间让我登入一下试试,果然问题解决了。

disk-space-after-fsck

我确认了一下云同学的操作,他们说**“就是fsck修了下而已”**。

god-eye-view

这里让我有第2点感触:在一些层次遇到无论如何都无法克服的 Bug,从更高的视角来看,也仅仅是个“小问题而已”。

生活亦是如此,如果遇到什么过不去的坎,付出那么多的努力都没用。请不要气馁和放弃,可能就是上帝视角不小心弄错了一个什么小问题,等他轻轻修复一下,可能一切都会顺畅无比。

六、先问 ChatGPT

其实最近已经养成习惯,遇到的问题去问 ChatGPT,但是这次觉着这个问题可能是常见运维问题,所以直接请教专家。

而当我解决完问题,再回头尝试问问 Chat GPT 的时候,发现可能不用请教运维同学,也不用上 Stack Exchange 就能直接找出原因。

chatgpts-answer-to-du-df-no-disk

不要排斥新技术,积极地去接受和利用新技术,才能更高效的工作,才更有可能早一天成为 wlbcoder。

这包括但不限于使用 ChatGPT 和 Copilot。一位使用 Copilot 的同事说,“没有 Copilot 的就像原始人”。积极地去尝试,尽早感受到跨越式的生产力提高。