作者 | 一得的跋涉责编 | 伍杏玲出品 | CSDN博客对于 Linux 磁盘满的问题，我们通常的处理思路是用 du 查找可清理的大文件，然后临时删掉让磁盘使用率先降下来，从而尽快保证磁盘能继续写入。但是，有一些情况的处理效果不太一样，du/df 呈现的结果可能还会让人迷惑不解。下面，我就分享下几个工作中遇到过的较离奇的磁盘满问题。被忽略的隐藏文件1、认识 swapfileLinux 的交换文件 swapfile 的产生场景较普遍，而且也是以隐藏文件的形式存在的，因此这里主要聊聊 swapfile 这一类的隐藏文件。当用 vim 打开一个文件时，都会产生一个 .swp 的临时隐藏交换文件，用来备份缓冲区中的内容。当文件非正常关闭(比如直接关闭终端或者电脑断电等)时，.swp文件不会被删除，这样就可以用此文件来恢复文件。(注意当正常关闭时，此文件会被删除；且如果只是读取文件，不会产生 .swp 文件)而且，如果 vim 意外退出后，又重新打开文件二次编辑，那么旧的 .swp 文件会继续保留，并产生新的 .swo 临时隐藏文件。如果二次编辑的时候，vim 又异常退出了，那么还会继续产生新的临时隐藏文件.swn、.swm、 .swl ……2、处理建议有些隐藏文件的磁盘占用也挺大：

:/tmp # ll -rth | grep Gtotal 17.7G-rw------- 1 xxxx users 17.6G 2020-02-12 18:27 .sqlkfJTFl.swp

所以有时候碰到大隐藏文件导致磁盘满的情况，如果没能发现这些隐藏文件，就会觉得离奇和疑惑。所以在排查磁盘满问题的时候，可以通过执行 vim -r 来查看和检查下所有临时交换文件的大小；或者通过 ls -lha 把所有隐藏文件都列出来看看大小。如果不想留 swapfile 这个特性，可以考虑关掉 swapfile ：

vim /etc/vimrc   # 添加如下配置set noswapfile  # 禁止在编辑时候产生此文件；

但是注意这仅限于对文件损失可以容忍的情况下；如果不能容忍文件损失，那还是建议还是打开 swapfile：

vim /etc/vimrc   # 添加如下配置set swapfile  # 则是在编辑时候产生此文件；

未释放的已删除文件1、du 和 df 不一致如果隐藏文件因素排除了，还是发现 du 出来的大小诡异，比如 du 发现磁盘并没有用满，但是 df 看到磁盘使用率却是 100% 。这又会是什么原因呢？这时候，通常就得怀疑有一些已删除的文件，还被一些进程 hold 住句柄没释放，导致这些文件虽然已经删除，也的确看不到了，但是却还占着磁盘空间；从而导致 du 和 df 出来的磁盘使用结果不一致的情况。2、处理建议通过执行 lsof | grep deleted 可以找到那些没有释放磁盘空间的文件和进程，然后通过重启对应进程，就可以达到释放已删除文件占用的空间的目的。这个帖子 《 清空热文件的常见错误操作 》 阐述了 “已删除文件还占用磁盘” 的产生场景和处理方式。另外，对于这种情况，还有个错误的处理方法，这里特别提醒下：有些同学在找到未释放已删除文件的 pid 之后，可能会直接通过 kill pid 来达到释放已删除文件的目的。这种做法确实能够释放已删除文件，从而释放磁盘空间，但是这种做法是有副作用的，危害可大可小。如果在离线环境这么操作，影响一般不大；但是如果在生产环境这么操作的话，那就可能搞出故障来了。我们假设这么一种场景：生产环境的某程序由于某种Bug，一直不会释放日志文件，而分时写入的日志文件又是有过期删除机制的，这样一直持续下去，就会发现服务器上有大量的已过期删除日志文件还占用着磁盘空间，直到产生磁盘满风险。那么这个时候如果直接通过 kill pid 来处理的话，就直接把生产环境的在线程序直接干掉了；这个后果就可想而知了：在这个程序被守护进程拉起来之前，这个服务都是不可用的。挂载引发的悬案1、消失的空间如果执行 ls -lha 并没有发现大隐藏文件，执行 lsof | grep deleted 也没有发现未释放的已删除文件；但是 df 看到根目录确实达到 100% 了 ，而 du 出来的根目录实际使用空间却并没有用满 。这又会是什么原因呢？出现这种情况的时候，请回忆下最近这台磁盘异常的机器，是否检修 或者 换过磁盘？根目录出现这种离奇现象，通常就是在检修/更换磁盘的时候(这里假设是更换/data1 ),新磁盘还没挂载就开始往 /data1 写数据了，这时候由于还没挂载新盘，所以写入数据占用的是根目录的空间。然后换好/data1 盘并重新挂载上去后，原本放在 /data1 的数据，也不会出现在挂载盘上，还是继续占用根目录的空间。所以这时候就会出现这样的现象：挂载后 du /data1 并不大 ，但是挂载前 /data1目录写入的数据实际却占用了根目录空间；而且这个数据在挂载后是看不到的，因此很难发现。于是就会发现根目录有一些空间似乎凭空消失了，相当诡异。2、处理建议2.1 解决方法怎么确认是新的挂载盘掩盖了一些数据呢？把新的挂载盘 /data1 umount掉，然后再看看 /data1 占用的空间就知道了。如果 umount提示 busy，可以通过执行以下命令来解决：

fuser -kmvi /data1 && umount /data1

卸载后，就会发现 /data1 目录下确实有大量文件，删除后，再 mount -a 重新挂载，然后根目录消失的磁盘空间，一般就能找回来了。2.2 测试验证如果还不放心的话，清理完数据再次挂载后，可以简单测试下：

dd if=/dev/zero of=/data1 bs=1M count=20000

往 /data1 大概写个 20G 数据，再观察下根目录的空间是否受影响，如果不受影响就说明问题解决！2.3 给个建议针对根目录这类离奇问题：建议在每次更换磁盘重新做挂载动作之前，检查一下根目录的空间使用情况；如果存在错误写入数据的情况，需要及时清理，然后再进行新盘挂载，切记。原文链接：https://blog.csdn.net/weixin_44648216/article/details/104505890

声明：本文系CSDN博主原创文章，版权归作者所有。

【End】《原力计划【第二季】- 学习力挑战》正式开始！
即日起至 3月21日，千万流量支持原创作者，更有专属【勋章】等你来挑战推荐阅读 ☞删库跑路事件发生，SaaS 云服务如何守护数据安全？☞技术大佬：我去，你写的 switch 语句也太老土了吧！☞BZip2Codec压缩、Map端压缩控制、Reduce端压缩控制……都在这份Hadoop整合压缩知识点里了！☞闪电网络的 5 个优点和4 个缺点、本质、来源与工作原理……一文带你读懂闪电网络！☞乔布斯遗孀裸捐 250 亿美元财产：没兴趣累积财富☞赔偿谷歌1.8亿美元！前Uber自动驾驶主管被告到破产你点的每一个在看，我认真当成了喜欢