新公司的测试机磁盘空间空余很小，日志很多，也很大，做个日志压缩脚本，在夜里4：30自动运行，第二天后发现磁盘空间又满了，只好删除没用的日志，清空空间，可诡异的是怎么删除没用的文件，空间还是占用很大。如图
用du 根目录下，发现这些文件加一块也达不到占用的空间大小。如图
我也有遇见过此类问题，一般都是重启完事，因为磁盘坏道损坏有可能导致此问题。
或 DF -i 查看inode使用率，inode不够用也会导致此问题。可看了inode也够用。
如图
这次我度娘了一下，”磁盘空间没释放“，按一篇文章干，解决了此问题。
记录如下：
昨天协助同事搞定了一起磁盘空间被”无形”占用的疑难杂症,简要记录以备忘.
1、用df 检查发现/根目录可用空间为0
[root@/]#df -h
2、用du检查发现各目录占用的空间都很少,有约3G的空间莫名其妙地丢了.
[root@/]# du -m –max-depth=1 |sort -gr
3、用lsof检查后才发现原因是,有文件被删除,而进程还活着,因而造成还占用空间的现象
[root@/]# lsof |grep delete
根据lsof列出的进程号,kill这些进程后,空间就释放出来了.
本文出自 “想飞却飞不高的猪” 博客，请务必保留此出处http://2483526.blog.51cto.com/2473526/798379
linux里的文件被删除后，空间没有被释放是因为在Linux系统中，通过rm或者文件管理器删除文件将会从文件系统的目录结构上解除链接(unlink).然而如果文件是被打开的(有一个进程正在使用)，那么进程将仍然可以读取该文件，磁盘空间也一直被占用。
态为deleted为标记被删除，其实该文件并没有从磁盘中删除，类似windows下的回收站状态。
据称当有其他进程打开某文件时文件被删除，就会将该文件标记为deleted，并删除其目录节点。使用du查看时，因为没有该删除状态文件的节点信息，所以就不做统计，从而导致与df的结果不一致。
若要将deleted状态文件删除，则根据pid直接kill调相应进程即可。
找回被删除文件：
使用lsof处理文件恢复、句柄以及空间释放问题 - yexiaoxiaobai - SegmentFault
https://segmentfault.com/a/1190000000461077