删除maildrop 目录下大量文件以及避免后续再次发生

这两天遇到一个问题：
1、问题现象
一个linux主机上报存储过大的告警，/var/spool/postfix/maildrop 目录下的文件多大400万个，占用存储30G，ls、rm等命令执行就卡主，抽查一两个文件，文件名是类似095285C63AF6这样的12位16进制的数字顺序组合，文件大小都是几K，文件内容没有实质性的意义。

2、问题原因：网上查了下，具体如下
该主机上有一些crontab，执行频率比较高，每次执行都会默认将output和warning信息邮件发送给crontab的属主，linux没有配置邮件功能，会导致有你发送不出去，从而以文件的形式堆积在/var/spool/postfix/maildrop目录下。

3、问题解决方案
3.1、临时方案：这些文件没有实际作用，手动删除。
手动删除400多万个小文件，rm -f 删除执行不动，不知道执行效率，如果一直放在那里执行，也不确定会不会因客户端会话过期导致执行失败。而且rm -f 如果文件过多，也会报错说传递的参数过大，导致无法删除。
自动化脚本：通过 ls -f1 /var/spool/postfix/maildrop/* > ~/tmp.txt ，将文件名清单写入到临时文件中，然后通过shell脚本，读取文件清单，一个个文件删除，加上语句，也可以知道当前删除的是哪个文件，脚本内容如下。

#!/bin/bash
cd /var/spool/postfix/maildrop/
ls -f1 /var/spool/postfix/maildrop/* > /root/tmp.txt
for i in `cat /root/tmp.txt`
do
echo $i
rm -f $i
done
echo "complete!"

3.2、彻底解决方案：禁用crontab的邮件发送
在每个用户的crontab下增加邮件配置的语句，如下示例：

 MAILTO=""
 */5 * * * *  /bin/bash
 */2 * * * * /bin/sh

4、总结
耗时最长的是手动删除400多个文件，毕竟积累了好几年的东西， shell脚本不一定是最快、最优的方式，比如是否可以直接删除maildrop文件夹，删除完后再创建一个maildrop文件夹，不确定是否可行，但是是做法上最简单的一种，能解决当前问题就行，看问题紧急、重要程度和影响。