du跟df查看目录出来的大不小不一致的一次总结

今天晚上收到一封服务器报警邮件的短信提醒，提示楼主所在公司的一台备份服务器的磁盘剩余空间不足20%，作为24小时电话值班的楼主，赶紧打开笔记本，远程登录这台服务器。然后，楼主顿时颤抖：

请看截图（下面一个截图为楼上对服务器的该挂载点上的数据进行了些比较大清理操作）：

淡定的楼主此时没法淡定，赶紧google、度娘：根据网上的大虾们的的指点，原来df跟du的算法不一样：

df命令          通过查看文件系统磁盘块分配图得出总块数与剩余块数。

du -sh命令    通过将指定文件系统中所有的目录、符号链接和文件使用的块数累加得到该文件系统使用的总块数。 文件系统分配其中的一些磁盘块用来记录它自身的一些数据，如i节点，磁盘分布图，间接块，超级块等。这些数据对大多数用户级的程序来说是不可见的，通常称为Meta Data。 du命令是用户级的程序，它不考虑Meta Data，而df命令则查看文件系统的磁盘分配图并考虑Meta Data。 因此正常情况下，df计算的USED空间会比du计算的结果要稍大。

同时，大仙们对上面截图出现的问题的见解是，某个或者某些进程在没有释放掉删除了的文件而导致。顿时楼主感觉茅塞顿开，原谅楼主的草率：

楼主马上进行如下操作：

1.fuser -mv /web   去查看那些进程使用该目录下的文件。

2.将使用该目录下的大的进程做记录，并将这些进程一个个的kill掉，kill掉过程中使用df -h  进行观察:

3.终于ok，如下截图，原来是nginx进程惹的祸：

     总结，处理该问题过于草率，如果为线上服务器这样操作会对线上的服务有多大影响不可估量，而且时间的把控上面也未知。处理完成该问题后，楼主发现有虾米这样处理该问题:查看deleted文件使用的进程，然后将这些kill掉，losf |grep deleted ，然后kill掉这些pid。待楼主以后验证。