背景
最近一直收到产品环境其中一台server的磁盘占用超过90%的警告，之前为了解决这个问题编写了一个压缩和删除历史log的脚本，正常情况来说应该不会再报这个警告，因为脚本是每天都在跑，所以每天增长的log的大小应该不至于占用很多的磁盘空间，但是实际情况却是每隔两三天就会收到一次警告，然后不得不手动的清理一些还没有被脚本压缩以及删除的log，从而释放一些空间，但是这不是长久之计，所以就详细的去查了这个问题。
解决
再次受到这个警告之后，我通过SSH连到了这台机器，然后通过df -h的命令查看了一下各个挂载磁盘的使用率如下图：
df -h
从图中可以看到可以看到 /dev/xvdb1这个磁盘被挂载在/alidata1/这个目录下，并且已经使用了34G(90%).
然后就要查看/alidata1下到底是哪个文件或者文件夹占用了这么多的磁盘空间，我们通过du -h --max-depth=1来查看，如下图：
du -h --max-depth=1
我们可以看到 /alidata1下的所有文件及文件夹占用的空间是22G，和我们通过df -h查看出来的磁盘占用34G相差12G，这是为什么？这12G的空间到底是被谁占用了？
于是去网上查了一些资料，原来是因为在Linux上删除一个进程正在写入的文件的时候，虽然已经被我们删除了，但是只要进程还在，那个文件就不会真正被删除，只是被临时存放到系统的某个地方，有点类似于Windows的回收站。通过lsof可以查看没有被真正删除的文件。如下图
lsof | grep deleted
从图中我们可以看出有四个占用空间比较大的没有被真正删除的文件，这四个文件分别是809和808的java进程console的输出log。之前被手动删除，但是由于没有重启进程导致文件一直还在，占用了大量空间。在通过重启808和809的java进程之后，磁盘的警告恢复了，通过df和du查看的结果如下：
df -h
df -h
du -sh /alidata1/
du -sh /alidata1/
从新的结果中可以看到df查看的磁盘占用空间和du查看的文件中下文件的占用空间一致了。
总结
所以如果以后碰到一些不合理的一些磁盘占用情况，我们可以通过df和du来查看磁盘占用空间和实际的文件占用空间是否有差异，如果有差异通过lsof命令查看有哪些没有被真正删除的文件，确认是被哪个进程占用，通过重启进程的方式来释放这些空间。
网友评论