关于linux:删除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 文件夹，不确定是否可行，然而是做法上最简略的一种，能解决以后问题就行，看问题紧急、重要水平和影响。