Data Domain：Data Domain 檔案系統清理/垃圾收集階段概觀

Data Domain 檔案系統 （DDFS） 與許多常見的檔案系統實現不同，因為當檔案系統刪除檔案時，該檔案所使用的空間無法立即以供重複使用。之所以會這樣做，是因為 Data Domain Restorer （DDR） 不會立即知道已刪除檔案所參考的資料是否也在針對其他檔案進行重複資料刪除，因此也不知道移除該資料是否安全。

清理 （有時稱為垃圾收集或 GC） 是透過 DDR 執行的程序：

• 確定磁碟上的哪些資料是多餘的（即不再被檔或快照等物件引用）
• 以實體方式刪除多餘的資料，使基礎磁碟空間可供重複使用（即引入新資料）

清理/GC 通常排定為定期執行 （預設為每週二早上 6 點開始），可以是：

• 長時間執行
• 運算成本高昂

但請注意，除了執行清理/GC 之外，別無他法可移除資料/在 Data Domain Restorer 上實際釋放空間 （也就是說，沒有捷徑可加速此程序）。

本文更詳細地說明 clean/GC：

• 清潔通常運行的階段
• 各種版本的 DDOS 中使用的不同清理演算法

無

每次執行清理/GC 時，它有兩個主要目的 - 首先它必須在 DDR 上找到多餘的數據 - 簡要概述如何做到這一點如下：

• 清理/GC 會列舉 DDFS 檔案系統的內容，以尋找系統上目前存在的檔案、快照和複寫記錄等物件
• 接著，它會判斷磁碟上由這些物件主動參照的所有實體資料
• 主動引用的數據稱為「活動」，無法從 DDR 中刪除，否則引用此數據的物件將損壞（它們將無法再被讀取，因為它們所依賴的基礎數據將不再存在於磁碟上）
• 未被任何物件主動引用的數據稱為“死”並且是多餘的 - 可以從系統中安全地刪除此數據
• DDR 上的所有資料都封裝在大小為 4.5 MB 的物件中，稱為容器
• 透過列舉清理/GC 可以判斷哪些 4.5 Mb 容器含有失效資料，以及每個容器中的失效資料量
• 根據預設，clean/GC 會選取容納 > 8% 失效資料的 4.5Mb 容器進行「處理」

其次，它必須刪除 DDR 上的失效數據 - 有關如何執行此操作的簡要說明如下：

• 再次檢查選擇進行處理的容器，以確認它們確實包含大量失效資料
• 從這些容器中提取實時數據，並在文件系統結束時寫入新的 4.5 Mb 容器
• 完成此操作后，將從磁碟中刪除選定的容器（包括它們包含的死數據），從而物理釋放磁碟空間

清潔過程分為幾個「階段」，總階段計數取決於：

• DDR 上使用的 DDOS 版本 （因此預設為該版本的 DDOS 所使用的乾淨演算法）
• 系統的組態或內容

然而，一般來說，查找“死”數據和選擇相應容器的過程分幾個階段進行，而刪除死數據則發生在稱為“複製”的單個階段。例如，某些版本的 DDOS 會執行清理階段，如下所示：

1. 預列舉 - 列舉 DDFS 檔案系統的內容
2. 預合併 - 執行 DDFS 索引合併，以確保索引資訊的最新副本已刷新到磁碟
3. 預先篩選 - 判斷 DDFS 檔案系統中是否有重複資料，若有，位於何處
4. 預選 - 確定應通過清理「處理」哪些 4.5 Mb 容器
5. 複製 - 從所選容器中實際提取實時數據，將其寫入新容器，然後刪除所選容器
6. 摘要 - 重新建置摘要向量（在攝取新資料期間用作優化）

在上述範例中，階段 1-4 用於判斷 DDR 上「失效」資料的位置。在本文檔的其餘部分中，這稱為“枚舉階段”。階段 5（複製）用於物理刪除此數據。

在清理/GC 到達複製階段之前，不會實際釋放系統上的空間。因此，在開始清理和開始釋放空間之間可能會有明顯的延遲 （因為列舉程序必須先執行才能完成）。因此，在開始清理/GC 之前，不應讓系統 100% 充滿。

枚舉階段在 CPU 利用率方面往往很昂貴（即它們通常受 CPU 限制），而複製階段在 CPU 和 I/O 方面都很昂貴（即它們通常是 CPU 和 I/O 綁定的）。但是，綜上所述，可以說：

• 列舉階段的總長度取決於複員方案上必須列舉的資料量
• 複製階段的總長度取決於 DDR 上必須移除的失效資料量，以及該資料在磁碟上的「碎片化」程度 （將進一步討論如下）

列舉階段的數量/功能取決於 DDR 上使用的 DDOS 版本。

DDOS 5.4 （及更早版本） - 完整清理演算法：執行 6 或 10 個階段 （如上所示）：

• DDFS 檔案系統的內容是自上而下列舉的 （也就是以檔案為中心）
• DDFS 會探索 DDR 上存在的所有檔案，然後依次掃描每個檔案，以判斷該檔案參照的資料
• 這可讓 clean/GC 判斷磁碟上的哪個資料為「即時」

DDOS 5.5 （及更新版本） - 實體清理演算法 （PGC）：執行 7 或 12 個階段：

• DDFS 的內容是自下而上列舉的 （也就是它不再掃描個別檔案）
• DDFS 會探索參考磁碟上實體資料的檔案系統中繼資料，並掃描該中繼資料以判斷所參考的資料
• 這可讓 clean/GC 判斷磁碟上的哪個資料為「即時」
• 這是通過添加「分析」階段來實現的（因此與完全清潔演演演算法相比相位數增加）
• 通常，實體清理的總持續時間預期會比相同系統的完整清理短 （儘管包含更多個別階段）

DDOS 6.0 （及更新版本） - 完美實體清理演算法 （PPGC）：

• 這隻是對物理清理演演演算法的優化，下面將進一步討論

DDOS 已從完整清理演算法切換至實體清理演算法，以改善列舉程序的擴充能力/效能 - 由於完整清理演算法的自上而下性質，它在 DDR 上的擴充性不佳：

• 許多小檔（因為從一個檔枚舉移動到下一個檔時的上下文切換成本高昂/速度很慢）
• 高重複資料刪除率 （因為多個檔案引用相同的實體資料，因此相同的資料會被多次列舉）

從 DDOS 5.4 （或更早版本） 升級至 5.5 （或更新版本） 時，DDR 會自動從完整演算法切換至實體清理演算法。唯一的例外情況是配置了延長保留的系統，其中必須先檢查 DDFS 檔案系統的內容是否有「跨越」檔案，才能啟用實體清理 - 關於此程序的討論超出了本文件的範圍，但是此檢查會在升級後自動執行，並在檢查完成後啟用實體清理，無需手動動作。

同樣地，從 DDOS 5.x 升級到 6.0 （或更新版本） 時，DDR 會自動從實體清理演算法切換為完善的實體清理演算法。但請注意，完美的物理清理演演演算法要求索引採用“index 2.0”格式才能使用。請注意：

• 「index 2.0」格式是在 DDOS 5.5 中推出的 （因此在 5.5 或更新版本上建立的所有檔案系統都已在使用索引 2.0）
• 在 5.4 或更早版本上創建的檔案系統最初將具有索引 1.0 格式的索引。升級到 DDOS 5.5（或更高版本）後，索引將轉換為索引 2.0 格式 - 每次執行清理時都會進行轉換，但是每次清理期間僅轉換 ~1% 的索引，因此可能需要長達 2 年的時間（假設每周執行一次清理）才能將索引完全轉換為 2.0 格式

對於最初執行 DDOS 5.4 （或更早版本） 但後續升級到 DDOS 5.5 （或更新版本） 的 DDR，可透過一次性的「索引重建」強制將索引轉換為索引 2.0 格式。但請注意，索引重建需要一段時間的停機時間，而索引則是實體重建 - 此操作通常需要 2-8 小時才能完成，具體取決於 DDR 上的數據大小/數量。若要討論執行索引重建，請與合同支援供應商聯繫。

無論使用何種清理演演演演算法，它都可能需要可變數量的相位 - 例如，完全清理演演演算法可能需要 6 或 10 個相位。這樣做的原因是：

• DDFS 啟動時，它會保留固定的內存量以供清理/GC 使用
• 在此記憶體中，清理/GC 建立資料結構來描述枚舉的結果（即描述磁碟上存在即時與死亡數據的位置）
• 當 DDR 包含的資料量相對較少時，DDFS 檔案系統的全部內容都可以在此記憶體區域中描述
• 然而，在許多系統上，這是不可能的，而且在枚舉 DDFS 檔案系統的全部內容之前，這個記憶體區域就會耗盡
• 因此，這些系統執行「採樣」，從而增加了所需的清潔階段數量

當使用清潔採樣時/GC 將：

• 在整個文件系統中執行枚舉的採樣傳遞 - 請注意，此枚舉不是「完整的」（即它不會記錄有關文件系統每個部分的完整資訊，而是近似於文件系統每個部分的資訊）
• 使用此採樣資訊來確定 DDFS 檔案系統的哪個部分從對其運行清理/GC 受益最大（即文件系統的哪個部分在清理後釋放空間方面提供最佳回報）
• 針對檔案系統的選定部分執行第二輪完整列舉，現在可以在為 GC 保留的記憶體中完整描述其內容

如果需要，會在清理/GC 期間自動啟用取樣功能，但會導致：

• GC 需要執行的階段數量增加
• 指導性案例的總持續時間相應增加

在 DDOS 6.0 之前，大部分的 DDR 會在 GC 期間執行取樣 （除非它們擁有相對較小的資料集）。但是，完美的物理清理演演演算法包括各種優化，以減少在文件系統中枚舉數據時 GC 所需的內存量。這意味著許多在 DDOS 5.x 上的 GC 期間執行採樣的系統將不再需要在 DDOS 6.0 上採樣 - 因此這減少了清理執行的階段數，並導致總清理運行時間的相應減少（即清潔性能的提高）。

除了下列情況外，沒有其他資訊可直接判斷系統是否已從實體清理演算法切換為完美實體清理演算法：

• 當系統在 DDOS 5.5 - 5.7 上執行實體清理時，會在清理期間執行 12 個階段
• 系統升級到 DDOS 6.0 （或更新版本） 後，在清理期間僅執行七個階段

如果執行 DDOS 6.0 的系統仍必須執行取樣，此功能會在清理期間自動啟用，並在清理期間回復為執行 12 個階段。

無論使用何種乾淨的演演演算法，複製階段（從系統中物理刪除死數據）在所有版本中都以類似的方式運行。複製階段的性能通常取決於：

• 必須刪除的「失效」資料量
• 此死資料的「碎片化」（即它分佈在磁碟上的方式）

如上所述，複製的工作原理是選擇保存死數據的 4.5 Mb 容器，從這些容器中提取任何實時數據並將該實時數據寫入新容器，然後刪除最初選擇的容器。以下示例描述了為什麼死數據的碎片很重要：

示例 1：

• 選取 10 個容器進行複製 （資料總大小為 45 Mb）
• 如果這些容器不保存實時數據（即它們保存的數據完全未引用），則全部
• 因此，複本必須將這些容器標記為已刪除，以釋放磁碟上的 45 MB 物理空間

範例 2：

• 已選取 100 個容器進行複製 （資料總容量 450 Mb）
• 這些容器中的每一個都可容納 90% 的即時資料/10% 的失效資料
• 若要處理這些容器，複製必須：

執行範例 2 所述複本需要比範例 1 更多的 I/O 和 CPU，因此在此範例中，釋放磁碟中的 45 Mb 實體空間需要較長的時間。

使用者通常無法控制 DDR 上磁碟上死數據的「碎片化」，因為這在很大程度上取決於寫入系統的資料的使用案例/類型。但是，請注意，clean/GC 確實會維護統計資訊，這些統計資訊有助於確定在複製階段遇到的死數據的“碎片”（因此，這允許使用者確定這種碎片是否可以解釋可能長時間運行的複製階段）。在自動支援中收集清理/GC 最新階段的此類統計資料。例如，下面顯示了一個複製階段，其中死數據相當連續（即大多數為副本選擇的容器都保存了大部分死數據）：

複製的實時數據的百分比：              3.6% 4.3%

相反，下面顯示了一個複製階段，其中死數據被碎片化（即為副本選擇的大多數容器主要保存實時數據）：

複製的實時數據的百分比：             70.9% 71.5%

如上所述，在第二種情況下，清理/GC 必須執行相對更多的工作，才能實際釋放 DDR 上的空間，這會導致複製階段的輸送量降低。

拷貝相通量也可能受到以下因素的不利影響：

• 加密的使用：複製期間可能需要解密/重新加密資料，這會大幅增加所需的 CPU 用量
• 使用低頻寬優化：容器可能需要在複製期間生成「草圖」資訊，這也會導致所需的 CPU 量顯著增加

請注意，如果最近啟用了低頻寬優化和/或加密，則所有現有容器（無論是否選擇它們進行複製）都可能需要加密和/或在後續清理期間針對它們生成草圖資訊 - 這可能會導致清理操作（特別是複製階段）花費比正常時間更長的時間。

有關檢查/修改清理計劃和限制的進一步說明，請參閱以下知識庫文章：Data Domain - 在 DDR

上排程清理但請注意：

• 在正常情況下，清理應排定為每週最多執行一次 - 執行清理的頻率高於此頻率可能會導致磁碟上的數據變得過於「碎片化」（即表現出較差的空間局部性），這可能會導致讀取/複製/數據移動性能不佳
• 清理節流不會影響清理所消耗的 CPU 總量和 I/O 頻寬，而是控制清理對系統上其他工作負荷的敏感程度。例如：

• 依預設，清潔節流設定為 50 - 當 DDR 遇到正常工作負載時，使用者有責任使用不同的節流設定測試乾淨執行，以判斷允許：

• 長時間執行的清理不一定是問題，只要符合以下條件：

• 使用延長保留功能的系統應設定為：

• 自動支援和詳細資訊中包含最新清理操作的完整資訊：