情景

有天看到有开发同事A在讨论群里说，一测试环境中某服务打印了大量的日志，把磁盘打满了。这位同事把日志清理了，并请群里的相关人员看下是否需要重启各自的服务。过一会儿，同事B说其中一服务虽然重新启动了，但并未正常启动，因为启动日志中依然显示着... No space left on device ...。

前有同事A说磁盘满并把日志清了，后有同事说磁盘还是没有剩余空间。这前后矛盾的现象，激起了我的兴趣，于是我登录到该测试环境服务器上一探究竟。

分析

BTW:

上述所说服务的路径均在/opt目录下，产生的文件也都在/opt目录的相关子目录下。所以，下面示例中关注/opt路径的磁盘空间即可。

使用df命令查看：

df -lh

Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/cl-root             92G   12G   80G  13% /
devtmpfs                       7.8G     0  7.8G   0% /dev
tmpfs                          7.8G     0  7.8G   0% /dev/shm
tmpfs                          7.8G   75M  7.7G   1% /run
tmpfs                          7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/sda1                     1014M  138M  877M  14% /boot
/dev/mapper/vg_data2-lv_data2  200G  200G   20K 100% /opt

在/opt目录下使用du命令查看：

sudo du -h --max-depth=1

6.4M	./blueset
9.7G	./laxi
16K	./mysqlback
86M	./logs
9.8G	.

由上可知： 

du命令得到/opt目录只占用了9.8G的空间，而df命令则显示200G全部被占满。为什么会这样呢？du和df得到的磁盘占用的数值不应该一致的么？

原理

经过一番搜索，发现了df和du的差别：

1 正常情况下，两者的输出其实也并不完全相同，但只是稍有差异；

du命令得到的是将指定文件系统中所有的目录、符号链接和文件使用的块数累加，即该文件系统使用的总块数；

df命令得到的是文件系统磁盘块分配情况，包括总块数、剩余块数等。

文件系统分配其中的一些磁盘块用来记录它自身的一些数据，如inode，磁盘分布图，间接块，超级块等。这些数据对大多数用户级的程序来说是不可见的，通常称为Meta Data（元数据）。 du命令是用户级的程序，它不考虑Meta Data，而df命令则查看文件系统的磁盘分配图并考虑Meta Data。

因此正常情况下，df计算的USED空间会比du计算的结果要稍大些。

2 特殊情况下，两者输出的结果差异很大；

上述碰到的问题就是这种特殊情况。

du是以文件名、目录名等为依据计算空间使用的，而df是以硬盘块使用情况来计算空间使用的。

当一个应用程序正在写一个大文件的时候，虽然我们可以对这个文件进行删除或挪走，但应用程序依然占有着句柄，并根据句柄所指磁盘位置直接写磁盘，而不检查该文件是否存在。

对应到上面的场景中，服务在向日志文件中写入时，因为磁盘空间不足，所以把日志文件删除了。但由于服务并没有停止，所以它还占用着句柄，因而两者得到的数据也不一样。

解决方案

对于当前存在的df和du结果不一致问题，可选的解决方案有：

1 重新挂载这个分区；

2 将未关闭的服务停掉，释放句柄；

如果在一开始A同事发现磁盘空间不足时，应该怎么做？

应清空日志文件的内容（echo ' ' > server.log），而不是直接删除文件。通过这种方法，磁盘空间可以立即释放，进程可以继续向文件写入日志，而不必重启服务。如果日志文件内容需要保留，可以先复制一份保存起来，再清空原文件。

总结

避免磁盘空间不足有很多种机制。本文讨论的是上述这种特殊情景下所涉及到的知识点和相应的解决方法。

相关链接

http://itindex.net/detail/39369-linux-df-du

http://www.chinaunix.net/old_jh/6/465673.html

该帖中摘要了一篇来自2001年发布的网文片段，对du和df区别的介绍很详细，推荐仔细阅读。