文件自動清理的需求

　　系統管理員的手中，管理著企業最有價值的資產——數據；而占據企業級服務器操作系統市場半壁江山的 Linux，更是讓 Linux系統管理員成為最重要的資產管理員。管理員的職責，就是讓有限的 IT 資源，存儲最有價值的數據。1991 年 IBM 推出 3.5 英寸 1GB 硬盤的時候，管理員洞悉硬盤上的每個文件，人工就可以實現文件管理；而今天 PB 級的存儲設備，則給文件管理帶來了前所未有的挑戰。

　　文件刪除操作，用過 Linux的人都應該可以完成。那么以下這些文件刪除操作，你能完成哪些？

1. 刪除整個文件系統中以特定后綴結尾的文件
2. 在一個有 1 百萬的文件系統中刪除某個指定文件
3. 從一個千萬級的文件系統里，刪除指定日期創建的 10 萬個文件
4. 在億級文件系統里，每天執行文件系統清理，刪除 1 年前產生的上百萬文件

　　下面要討論就是如何實現以上文件刪除操作的策略和方法，如果以上操作對你來說輕而易舉，可以忽略本文。對于清理文件系統而言，我們可以簡單的把清理任務分成兩大類，清理過期文件和清理垃圾文件。

　　過期文件

　　任何數據都有自己的生命周期，數據的生命周期曲線告訴我們，數據在產生和產生之后的一段時間內的價值最大，然后數據價值隨著時間衰減。當數據生命周期結束時，就應該刪除這些過期文件，將存儲空間釋放出來留給有價值的數據。

　　垃圾文件

　　系統運行過程中，會產生各種各樣的臨時文件，些應用程序運行時的臨時文件，系統錯誤產生的 Trace 文件，Core Dump 等等，在這些文件被處理后，就失去了保留價值，這些文件可以統稱為垃圾文件。及時清理垃圾文件，有助于系統維護和管理，保證系統穩定有效的運行。

　　文件自動清理的概述

　　文件自動清理的特點與方法

　　在指定絕對路徑下刪除一個文件，rm 就可以實現；如果只知道文件名，不知道路徑，我們可以通過 `find` 找到它，然后刪除。推而廣之，如果我們可以根據預設的條件找到指定文件，我們就可以實施刪除操作。這也就是文件自動清理的基本思路，根據預設條件生成待刪除文件列表，然后執行定期清除任務實施刪除操作。

　　對于過期文件而言，他們共同標志是時間戳，根據不同的文件系統，可能是文件創建時間，訪問時間，過期時間等不同的時間屬性。由于過期文件大多存在于歸檔系統上，這類文件的特點是數量巨大，對于大型系統而言，每天的過期文件數量都可能達到數十萬甚至百萬的數量級。對于如此規模的文件數量，掃描文件系統，生成文件列表就需要大量的時間，所以文件清理性能是此類人物不得不考慮的問題。

　　對于垃圾文件而言，有可能會是存放在特定目錄下的文件，也有可能是是以特殊后綴名結尾的文件，還有可能是因為系統錯誤產生的 0 尺寸或者超大尺寸的文件，對于這些文件而言，文件數量一般不大，但是種類比較繁多，情況比較復雜，需要根據系統管理員的經驗，制定比較細致的文件查詢條件，定期掃描，生成文件列表，然后進行進一步處理。

　　相關 Linux命令簡介

　　常用的文件系統管理命令包括 `ls`，`rm`，`find` 等等。鑒于這些命令都是常見的系統管理命令，在此不做贅述，詳細用法請參見命令幫助或者 Linux使用手冊。由于大規模文件系統一般都存儲在專用的文件系統上，這些文件系統都提供了獨有的命令進行文件系統管理。本文實踐章節以 IBM 的 GPFS 文件系統舉例，以下簡要介紹 GPFS 的若干文件系統管理命令。

　　mmlsattr

　　此命令主要用于查看 GPFS 文件系統中文件的擴展屬性，如存儲池信息，過期時間等屬性。

　　mmapplypolicy

　　GPFS 采用策略對文件進行管理，此命令可以根據用戶定義的策略文件，對 GPFS 文件系統執行各種操作，具有非常高的效率。
　　大批量文件自動清理的難點

　　Linux文件刪除機制

　　Linux是通過 link 的數量來控制文件刪除，只有當一個文件不存在任何 link 的時候，這個文件才會被刪除。每個文件都有 2 個 link 計數器—— i_count 和 i_nlink。i_count 的意義是當前使用者的數量，i_nlink 的意義是介質連接的數量；或者可以理解為 i_count 是內存引用計數器，i_nlink 是硬盤引用計數器。再換句話說，當文件被某個進程引用時，i_count 就會增加；當創建文件的軟連接或者硬連接的時候，i_nlink 就會增加。

　　對于 rm 而言，就是減少 i_nlink。這里就出現一個問題，如果一個文件正在被某個進程調用，而用戶卻執行 rm 操作把文件刪除了，會出現什么結果呢？當用戶執行 rm 操作后，ls 或者其他文件管理命令不再能夠找到這個文件，但是進程卻依然在繼續正常執行，依然能夠從文件中正確的讀取內容。這是因為，`rm` 操作只是將 i_nlink 置為 0 了；由于文件被進程飲用的緣故，i_count 不為 0，所以系統沒有真正刪除這個文件。i_nlink 是文件刪除的充分條件，而 i_count 才是文件刪除的必要條件。

　　對于單個文件刪除而言，我們可能完全不需要關心這個機制，但是對于大批量文件刪除，這卻是一個非常重要的因素，請允許我在隨后章節中詳細闡述，此處請先記下 Linux的文件刪除機制。

　　生成待刪除列表
當一個文件夾下面有 10 個文件的時候，`ls` 可以一目了然，甚至可以用 `ls – alt` 查看所有文件的詳細屬性；當文件變成 100 個的時候，`ls` 可能只能看一看文件名了；文件數量上漲到 1000，多翻幾頁可能還能接受；如果是 10，000 呢？ `ls` 可能需要等上半天才能有結果；再擴展成 100，000 的時候，絕大多數系統可能都沒有反應，或者“Argument list too long”了。不止是 `ls` 會遇到這樣的問題，其它的常用 Linux系統管理命令都會遇到類似的問題，Shell 有參數來限制命令的長度。就算我們可以通過修改 Shell 參數來擴展命令長度，但這并不能提高命令的執行效率。對一個超大規模的文件系統而言，等待 `ls` 和 `find` 等常用文件管理命令的返回的時間是不可接受的．
那么我們如何能夠在更大數量級的文件系統上生成刪除文件列表呢？一個高性能的文件系統索引是一個好方法，不過高性能的文件索引是少數人的專利（這也解釋了為什么 google 和 baidu 能這么賺錢）。好在如此規模的文件系統一般都只存在于高性能文件系統里面，這些文件系統都提供了非常強大的文件管理功能。譬如前面提到的 IBM 通用并行文件系統（GPFS）的 mmapplypolicy，通過直接掃描 inode 來快速掃描整個文件系統，并能夠根據指定條件返回文件列表。下面演示如何根據時間戳和文件類型來獲取文件列表

　　死鎖對文件刪除性能的影響

　　對于一個每天定時執行文件刪除任務系統，首先生成待刪除文件，然后把該列表作為輸入執行刪除操作；如果某天待刪除列表特別大，導致第一天的刪除任務還沒有完成，第二天的刪除任務就啟動了，會有什么結果呢？
第一天還沒有來得及被刪除的文件會出現在第二天的刪除文件列表中，然后第二天的文件刪除進程會把它做為輸出執行刪除操作。此時，第一天的刪除進程和第二天的刪除都會嘗試去刪除相同的文件，系統拋出大量的 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 個文件夾。

　　定義查找規則如下，保存為 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 個文件的子列表：

　　執行以下命令進行刪除操作：

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

　　手動執行刪除任務，待刪除文件掃描結果如下：

[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 小時）：

　　當然，對于 GPFS 文件系統而言，文件系統本身還提供了其他的文件清理方法，譬如可以通過 mmapplypolicy來執行文件刪除操作，通過這種方法，有可能實現更加高效的文件清理任務。本文的目的在于討論一種通用的大規模文件清理方法，在此就不對基于文件系統所提供功能的文件清理操作做進一步討論了，感興趣的讀者可以嘗試一下。