對于一個每天定時執(zhí)行文件刪除任務(wù)系統(tǒng)，首先生成待刪除文件，然后把該列表作為輸入執(zhí)行刪除操作;如果某天待刪除列表特別大，導(dǎo)致第一天的刪除任務(wù)還沒有完成，第二天的刪除任務(wù)就啟動了，會有什么結(jié)果呢?

　　第一天還沒有來得及被刪除的文件會出現(xiàn)在第二天的刪除文件列表中，然后第二天的文件刪除進程會把它做為輸出執(zhí)行刪除操作。此時，第一天的刪除 進程和第二天的刪除都會嘗試去刪除相同的文件，系統(tǒng)拋出大量的 unlink 失敗的錯誤，刪除性能會受到很大的影響。刪除性能的下降，會導(dǎo)致第二天的文件依然沒有被刪除，第三天的刪除進程會加劇刪除文件的死鎖，進入刪除性能下降的 惡性循環(huán)。

　　如果簡單的刪除第一天生成的待刪除列表，能夠解決上述問題嗎?不能。如前文所述的 Linux 文件刪除機制，刪除第一天的文件列表文件只能把該文件的 i_nlink 清零，當(dāng)?shù)谝惶斓奈募⻊h除進程沒有結(jié)束的時候，該文件的 i_count 就不為零，因而該文件不會被刪除。直到該進程處理完列表中的所有文件，進程退出，第一天的待刪除列表文件才真正被刪除了。

　　我們至少需要在新的文件刪除進程啟動以前，把系統(tǒng)中其它的文件刪除進程終止，才能保證不會發(fā)生刪除死鎖的情況。但是這樣做，依然存在一些弊 端。考慮到極端情況下，如果連續(xù)一段時間刪除進程都無法在一個周期內(nèi)完成刪除任務(wù)，那么待刪除列表就會不斷增長，文件掃描時間會延長，進而擠占文件刪除進 程的工作時間，陷入另外一個惡性循環(huán)。

　　而且實戰(zhàn)經(jīng)驗告訴我們，當(dāng)刪除列表特別巨大時，刪除進程的工作性能也有所下降。而一個適當(dāng)大小的參數(shù)輸入文件，能夠保證進程有效執(zhí)行。所以， 按照固定尺寸將待刪除列表文件分割成一系列文件，能夠讓刪除操作穩(wěn)定高效的執(zhí)行。而且，在存儲和主機性能允許的前提下，分割為多個文件還可以允許我們并發(fā) 執(zhí)行多個刪除進程。

　　大批量文件自動清理的最佳實踐

　　GPFS 文件系統(tǒng)下大規(guī)模額外年間自動清理的最佳實踐

　　以下是在一個千萬級的 GPFS 文件系統(tǒng)上進行的文件自動清理實踐：硬件環(huán)境為兩臺 IBMx3650 服務(wù)器和存儲容量為 50TB 的 DS4200 磁盤陣列，安裝了 Linux 操作系統(tǒng)和 GPFS v3.2。目標是每天 2：00AM 執(zhí)行文件清理操作，刪除 30 天以前的文件和所有以 tmp 為結(jié)尾的文件。

　　mmapplypolicy 掃描結(jié)果顯示該系統(tǒng)上有 323,784,950 個文件，158,696 個文件夾。

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

　　定義查找規(guī)則如下，保存為 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'

　　執(zhí)行 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_

　　執(zhí)行以下命令進行刪除操作：

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

　　將上述操作保存為 trash_clear.sh，然后定義 crontab 任務(wù)如下：

　　0 2 * * * 　 /path/trash_clear.sh

　　手動執(zhí)行刪除任務(wù)，待刪除文件掃描結(jié)果如下：

　　[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;

　　在文件刪除過程中，我們可以采用以下命令計算每分鐘文件刪除數(shù)量。從下面的輸出可以得出，文件刪除速度為 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` 命令對文件刪除操作進行計時，從輸出結(jié)果可以看出，本次文件刪除操作一共耗時 1168 分鐘(19.5 小時)：

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

　　當(dāng)然，對于 GPFS 文件系統(tǒng)而言，文件系統(tǒng)本