今天通过监控，监控到某台服务器上的/home目录满了；通过df -Th ,如下图显示：
上图中显示：/home，Used%率达到100%；
随后用du -sh ,发现/home总共才73G；
而且在/home目录下并没有找到大文件；看起来好诡异。
“df”命令报告使用了多少个磁盘块，同时“du”遍历文件系统，并报告所使用的区块的实际数量（按目录下的目录），包括与进程使用的文件相关的任何内容。
在大多数情况下，从“df”和“du”返回的空间利用率将是一致的。但是，对于一个正在运行的进程来说，删除一个大文件的潜力是存在的。在这个例子中，根据“du”，大文件不再存在，因此与删除文件相关联的区块不会被报告。随着进程仍在运行，并且仍然保留着对已删除文件的开放文件描述符，“df”继续跟踪和报告所使用的所有磁盘块，包括与已删除（幻影）文件相关联的磁盘块。在这种情况下，与被删除的文件相关联的磁盘空间只会在进程完全释放被删除的文件描述符或进程终止时（被杀死）时被释放回系统。
解决方案
解决方案是识别并停止（或杀死）继续为已删除文件打开文件描述符的过程。要做到这一点，请运行lsof命令（/usr/sbin/lsof ）作为根来识别扣留过程，例如：
#lsof /home/ 找出持有/home目录下文件的进程
#lsof | grep deleted 数量太多的话，直接过滤出来，kill掉
下图中，发现都是faclcon-ag进程运行时，删除的一些日志文件；文件被删除了，但是进行还在运行着。杀掉这些进程，空间就可以得到释放。
之所以df和du命令看到的空间使用会有差别，原因在于du不统计已经删除的文件，df会统计已经删除的文件，但该文件依然被进程持有，只有等进程释放了该文件，df才不进行统计。通过lsof | grep deleted命令可以找出被删除的文件依然被进程持有的情况。
总结：对于此类问题，我们首先要明白为什么df和du在空间计算上有所差别，其次要熟悉lsof和fuser两个命令，找出继续持有文件的进程号，通过该进程号可以在/proc目录下恢复文件，查看进程的环境信息，甚至杀掉进程来释放空间。
本文来自投稿，不代表Linux运维部落立场，如若转载，请注明出处：http://www.178linux.com/98763
