对于一个每天定时执行文件删除任务系统，首先生成待删除文件，然后把该列表作为输入执行删除操作;如果某天待删除列表特别大，导致第一天的删除任务还没有完成，第二天的删除任务就启动了，会有什么结果呢?

　　第一天还没有来得及被删除的文件会出现在第二天的删除文件列表中，然后第二天的文件删除进程会把它做为输出执行删除操作。此时，第一天的删除 进程和第二天的删除都会尝试去删除相同的文件，系统抛出大量的 unlink 失败的错误，删除性能会受到很大的影响。删除性能的下降，会导致第二天的文件依然没有被删除，第三天的删除进程会加剧删除文件的死锁，进入删除性能下降的 恶性循环。

　　如果简单的删除第一天生成的待删除列表，能够解决上述问题吗?不能。如前文所述的 Linux 文件删除机制，删除第一天的文件列表文件只能把该文件的 i_nlink 清零，当第一天的文件删除进程没有结束的时候，该文件的 i_count 就不为零，因而该文件不会被删除。直到该进程处理完列表中的所有文件，进程退出，第一天的待删除列表文件才真正被删除了。

　　我们至少需要在新的文件删除进程启动以前，把系统中其它的文件删除进程终止，才能保证不会发生删除死锁的情况。但是这样做，依然存在一些弊 端。考虑到极端情况下，如果连续一段时间删除进程都无法在一个周期内完成删除任务，那么待删除列表就会不断增长，文件扫描时间会延长，进而挤占文件删除进 程的工作时间，陷入另外一个恶性循环。

　　而且实战经验告诉我们，当删除列表特别巨大时，删除进程的工作性能也有所下降。而一个适当大小的参数输入文件，能够保证进程有效执行。所以， 按照固定尺寸将待删除列表文件分割成一系列文件，能够让删除操作稳定高效的执行。而且，在存储和主机性能允许的前提下，分割为多个文件还可以允许我们并发 执行多个删除进程。

　　大批量文件自动清理的最佳实践

　　GPFS 文件系统下大规模额外年间自动清理的最佳实践

　　以下是在一个千万级的 GPFS 文件系统上进行的文件自动清理实践：硬件环境为两台 IBMx3650 服务器和存储容量为 50TB 的 DS4200 磁盘阵列，安装了 Linux 操作系统和 GPFS v3.2。目标是每天 2：00AM 执行文件清理操作，删除 30 天以前的文件和所有以 tmp 为结尾的文件。

　　mmapplypolicy 扫描结果显示该系统上有 323,784,950 个文件，158,696 个文件夹。

　　............. [I] Directories scan: 323784950 files, 158696 directories, 0 other objects, 0 'skipped' files and/or errors. .............

　　定义查找规则如下，保存为 trash_rule.txt

　　RULE EXTERNAL LIST 'trash_list' EXEC '' RULE 'exp_scan_rule' LIST 'trash_list' FOR FILESET('data') WHERE DAYS(CURRENT_TIMESTAMP) – DAYS(ACCESS_TIME) > 30 RULE 'tmp_scan_rule' LIST 'trash_list' FOR FILESET('data') WHERE NAME LIKE '%.tmp'

　　执行 mmapplypolicy 并配合 grep 和 awk 命令生成待删除文件完整列表，再用 split 命令将完整列表分割为每个列表包含 10,000 个文件的子列表：

　　mmapplypolicy /data – P trash_rule.txt – L 3 | grep “/data” |awk ‘ {pint $1} ’ > trash.lst split – a 4 – C 10000 – d trash.lst trash_split_

　　执行以下命令进行删除操作：

　　for a in `ls trash_splict_*` do rm `cat $a` done

　　将上述操作保存为 trash_clear.sh，然后定义 crontab 任务如下：

　　0 2 * * * 　 /path/trash_clear.sh

　　手动执行删除任务，待删除文件扫描结果如下：

　　[I] GPFS Policy Decisions and File Choice Totals: Chose to migrate 0KB: 0 of 0 candidates; Chose to premigrate 0KB: 0 candidates; Already co-managed 0KB: 0 candidates; Chose to delete 0KB: 0 of 0 candidates; Chose to list 1543192KB: 1752274 of 1752274 candidates; 0KB of chosen data is illplaced or illreplicated;

　　在文件删除过程中，我们可以采用以下命令计算每分钟文件删除数量。从下面的输出可以得出，文件删除速度为 1546 文件每分钟：

　　df – i /data;sleep 60;df – i 　 /data Filesystem Inodes IUsed IFree IUse% Mounted on /dev/data 2147483584 322465937 1825017647 16% /data Filesystem Inodes IUsed IFree IUse% Mounted on /dev/data 2147483584 322467483 1825016101 16% /data

　　通过 `time` 命令对文件删除操作进行计时，从输出结果可以看出，本次文件删除操作一共耗时 1168 分钟(19.5 小时)：

　　time trash_clear.sh real 1168m0.158s user 57m0.168s sys 2m0.056s

　　当然，对于 GPFS 文件系统而言，文件系统本