[原]模拟说明du与df 结果不一致的问题

    常用Linux 等类Unix 平台的用户都可能会发现，du与df 的经过经常会不一致。其中，最常见的情况是，df 显示的已使用磁盘占用率比du 统计出来的结果要大很多。原因，主要是由于两者计算结果的方式不同。为了更清楚的说明问题，我下面做了一个简单的模拟实验。

一、实验情况
1、创建并删除文件
创建文件前的磁盘容量情况：

创建文件：

现在的磁盘情况：

模拟某个进程正在使用该文件：

2、删除该文件
打开另一个终端，登陆到系统中。
查看是否有进程正在使用上面创建的文件：

把该文件删掉，并确认：

查看是否还有进程在使用（注意结尾的标记）：

查看磁盘使用情况：

可见，虽然从ls 已经无法找到该文件，但因为tail 进程仍在使用该文件，故实际上内核并没有把这文件所占用的空间释放出来（df 的结果）。

3、停止相关进程
回到第一终端，用Ctrl+C 终止tail 进程，查看结果：

至此，文件所占用的空间已完全释放。

二、说明
从上面的实验，可得出一些情况：

三、解决问题
通常的解决方法有两个：
1、把占用文件的相关进程关闭
这可通过下面的命令得到这些已被删除，但未释放空间的文件和进程信息：

找到这些进程后，在安全的情况下把其关闭，空间自会马上释放。

2、以清空的方式替代删除
归根到底，产生问题的原因是，访问该文件的文件指针（句柄），在rm 动作后，因为进程仍在访问，因此，仍处在文件里面（中间或结尾处）。所以，如果用清空的方式，把文件指针重置，该文件所占用的空间也会马上释放出来。

所以，对于常发生类似问题的文件，如：日志记录文件等。以改名、清空、删除的顺序操作可避免问题。

四、补充
除rm外，有些不明显的操作，也会产生类似的问题。
例如 gzip 命令，其对某个文件xxx.log进行压缩时，会产生一个新的xxx.log.gz文件，完成后，会把原来的xxx.log删除。
这时，若仍有进程在使用xxx.log文件，那么，实际上，该文件还是只会标记为deleted，其空间也不会释放，问题与上面提到的情况是相同的。所以，在编写脚本时，可先判断是否仍有进程正在使用该文件，然后再进行gzip 操作。