Linux磁盘空间存满的处理⽅法
对于 Linux 磁盘满的问题，
我们通常的处理思路是⽤du查可清理的⼤⽂件，
然后临时删掉让磁盘使⽤率先降下来，从⽽尽快保证磁盘能继续写⼊。
但是，有⼀些情况的处理效果不太⼀样，
du/df 呈现的结果可能还会让⼈迷惑不解。
下⾯，我就分享下⼏个⼯作中遇到过的较离奇的磁盘满问题。
⼀、被忽略的隐藏⽂件
1、认识 swapfile
Linux 的交换⽂件 swapfile 的产⽣场景较普遍，⽽且也是以隐藏⽂件的形式存在的，
因此这⾥主要聊聊 swapfile 这⼀类的隐藏⽂件。
当⽤ vim 打开⼀个⽂件时，都会产⽣⼀个 .swp 的临时隐藏交换⽂件，⽤来备份缓冲区中的内容。
当⽂件⾮正常关闭（⽐如直接关闭终端或者电脑断电等）时，.swp⽂件不会被删除，这样就可以⽤此⽂件来恢复⽂件。（注意当正常关闭时，此⽂件会被删除；且如果只是读取⽂件，不会产⽣ .swp ⽂件）
⽽且，如果 vim 意外退出后，⼜重新打开⽂件⼆次编辑，
那么旧的 .swp ⽂件会继续保留，并产⽣新的 .swo 临时隐藏⽂件。
如果⼆次编辑的时候，vim ⼜异常退出了，
那么还会继续产⽣新的临时隐藏⽂件.swn、.swm、 .swl …
2、处理建议
有些隐藏⽂件的磁盘占⽤也挺⼤：
ll -rth | grep G
total 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少儿平安福
1
解决。
卸载后，就会发现 /data1 ⽬录下确实有⼤量⽂件，
删除后，再 mount -a 重新挂载，
然后根⽬录消失的磁盘空间，⼀般就能回来了。
2.2 测试验证
如果还不放⼼的话，清理完数据再次挂载后，可以简单测试下：
通过
dd if=/dev/zero of=/data1 bs=1M count=20000
往 /data1 ⼤概写个 20G 数据，
佟丽娅离婚了吗
再观察下根⽬录的空间是否受影响，
如果不受影响就说明问题解决！
2.3 给个建议
针对根⽬录这类离奇问题：
建议在每次更换磁盘重新做挂载动作之前，检查⼀下根⽬录的空间使⽤情况；如果存在错误写⼊数据的情况，需要及时清理，然后再进⾏新盘挂载，切记。