正文
意外的是，系统还有充足的空间，系统盘只使用了15%，数据盘只使用了25%。奇怪吧，错误提示信息和真正情况并不能统一。
调试bug时遇到挫折常见的，我没有别的办法，怀疑找错了方向，但现有的线索也只有这些，怎么办呢，我觉得还是应该在网上搜索，也行会有新的发现。
果然，在一篇文章里看到有人说Errcode: 28所指示的No space并不一定是指空间不足，也可能是磁盘上的文件数过多，这位网友这样说：
I had same problem but disk space was okay (only 40% full). Problem were inodes, I had too many small files and my inodes were full.
You can check inode status with df -i
他说的这个问题我是遇到过的，linux文件系统里对文件数是有限制的，当文件数达到最大数量是，你将无法新增文件。错误信息里提到了无法读写tmp目录下的临时文件，也行正是因为无法创建新的文件。
那么使用df -i会是什么结果呢？让我吓一跳，在/dev/vda1盘上的文件数竟然快到200多万。看来文件就出自这里了。
下面的任务是找到哪个目录里藏了这么多文件。我使用了笨办法，手工从根目录一个一个的搜：
find DIR_NAME -type f | wc -l
上面的命令可以统计出指定目录下一共有多少个文件。这是个体力活儿，但体力活儿是最容易出结果的，没用多久，我就发现了一个可疑目录：
/var/spool/postfix/maildrop
这个目录下竟然有180万个文件。
看来凶手就是它了。只要将maildrop下的文件全部删掉，磁盘文件数会全部释放，问题也就解决了。可是，为什么会有这么多文件，为什么会在postfix目录下，这个问题如果不搞清楚，相同的服务器异常不久后还会出现。
那么，postfix;是个东西，而maildrop又是个什么东西。
原来postfix是一个邮件服务器软件：
What is Postfix? It is Wietse Venema’s mail server that started life at IBM research as an alternative to the widely-used Sendmail program. Now at Google, Wietse continues to support Postfix.
而maildrop是邮件队列，里面存放的都是一个个邮件。
可问题又来了，哪里来的这么多邮件，谁发给谁的？
