1、若有进程在占用某个文件，而其他进程把这文件删掉，只会删除其在磁盘中的标记，而不会释放其占用的磁盘空间；直到所有访问该文件的进程退出为止；
2、df 是从内核中获取磁盘占用情况数据的，而du是统计当前磁盘文件大小的结果，由于磁盘标记已被删掉，因此du 不会计算上述被删除文件的空间，导致df 与 du的结果不一致。
2、df 是从内核中获取磁盘占用情况数据的，而du是统计当前磁盘文件大小的结果，由于磁盘标记已被删掉，因此du 不会计算上述被删除文件的空间，导致df 与 du的结果不一致。
三、解决问题
通常的解决方法有两个：
1、把占用文件的相关进程关闭
这可通过下面的命令得到这些已被删除，但未释放空间的文件和进程信息：
|
# lsof |grep deleted |
找到这些进程后，在安全的情况下把其关闭，空间自会马上释放。
2、以清空的方式替代删除
归根到底，产生问题的原因是，访问该文件的文件指针（句柄），在rm 动作后，因为进程仍在访问，因此，仍处在文件里面（中间或结尾处）。所以，如果用清空的方式，把文件指针重置，该文件所占用的空间也会马上释放出来。
引用
# echo > /tmp/test.iso
# df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 5.7G 5.5G 51% /
tmpfs 506M 0 506M 0% /dev/shm
# tail -f /tmp/test.iso
tail: /tmp/test.iso: file truncated
# df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/sda1 12G 5.7G 5.5G 51% /
tmpfs 506M 0 506M 0% /dev/shm
# tail -f /tmp/test.iso
tail: /tmp/test.iso: file truncated
所以，对于常发生类似问题的文件，如：日志记录文件等。以改名、清空、删除的顺序操作可避免问题。
四、补充
除rm外，有些不明显的操作，也会产生类似的问题。
例如 gzip 命令，其对某个文件xxx.log进行压缩时，会产生一个新的xxx.log.gz文件，完成后，会把原来的xxx.log删除。
这时，若仍有进程在使用xxx.log文件，那么，实际上，该文件还是只会标记为deleted，其空间也不会释放，问题与上面提到的情况是相同的。所以，在编写脚本时，可先判断是否仍有进程正在使用该文件，然后再进行gzip 操作。
五 文件空洞
文件读写时，如果先文件指针偏移很大一段，然后写入1byte；这样这个文件实际占用1byte空间，但是stat查看文件大小，或者读写时，都会发现文件很大；所有没有写内容的都返回0，且不占用空间，这样的文件叫 'sparse file'，即文件空洞
容易发生在一个进程在写一个文件，这是人工进行清空文件操作，就会产生。