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

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

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

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

• Docker 拉取的镜像，可以使用 docker system prune -a 清理掉
• Bazel/Go/Sbt 等的 Cache 目录
• /var/log/messages-* 里边的日志

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

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

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

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

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

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

二、被关闭的“坏问题”

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

• df -h 的结果
• du -sh / --exclude=/data --exclude=/proc 的结果
• lsof | grep delete 结果为空
• ls .[^.]* 没有隐藏文件
• free -h 没有设置 swap 空间

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

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

• Close 投票达到了3，问题会被关闭，别人就不能回答了
• 1个Down Vote会减 2 Reputation
• 删掉问题或回答，减的 Reputation 会恢复，但是问题就不可见了

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

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

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 上了。

三、Stack Exchange是什么

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

• Stack Overflow 属于 Stack Exchange site
• Stack Exchange 还有其他类似于 Stack Overflow 的网站

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

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：

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

• 10 个 Deleted inode N has zero dtime
• 7 个 Free blocks count wrong for group
• 1 个 Free blocks count wrong
• 17 个 Directories count wrong for group
• 1 个 Free inodes count wrong

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

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

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

五、细思极恐的上帝视角

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

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

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

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

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

六、先问 ChatGPT

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

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

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

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