Data Domain：Data Domain 文件系统（DDFS）清理/垃圾数据收集（GC）阶段概览

Data Domain 文件系统（DDFS）不同于许多常见文件系统的实施方式，在从文件系统中删除文件时，如果从该文件使用的文件系统空间中删除了文件，则不能立即使用。原因是因为 Data Domain Restorer （DDR）不会立即确定是否已删除的文件引用的数据也会被其他文件重复数据消除，因此是否可以安全地删除该数据。

清理（有时也称为垃圾收集/GC）是 DDR 的过程：

• 确定磁盘上的哪些数据是多余的（即不再由文件或快照等对象引用）
• 以物理方式删除多余的数据，使底层磁盘空间可供重复使用（即接收新数据）

清理/GC 通常计划为按固定间隔运行（默认情况下，它从每个星期二开始6am），可以是：

• 长期运行
• 计算成本高昂

但是，请注意，除了通过运行清理/GC （在 Data Domain Restorer 上以物理方式释放数据）和空间（例如，没有可加快此过程的快捷方式）

的情况下，也是如此。本文介绍了清理/GC 的更多详细信息，其中介绍了以下内容：

• 清理通常运行的阶段
• 各种 DDOS 版本中使用的不同清理算法

无

每次运行 "clean/GC" 时，都有两个主要用途—首先它必须在 DDR 上找到多余的数据，简要概述如何完成此操作，如下所示：

• Clean/GC 可枚举 DDFS 文件系统的内容，查找系统中当前存在的文件、快照和复制日志等对象
• 然后，它将确定这些对象积极引用的磁盘上的所有物理数据
• 主动引用的数据被称为 "live"，不能从 DDR 中删除; 否则，引用此数据的对象将被损坏（这些数据将无法再被读取为其依赖的底层数据将不再存在于磁盘上）
• 任何对象无法主动引用的数据被视为 "失效"，并且是多余的—此数据可以安全地从系统中删除。
• DDR 中的所有数据都打包为大小为 4.5 Mb 的对象（称为容器）
• 通过枚举清理/GC 可以确定哪些 4.5 Mb 容器保存失效数据，以及每个
• 默认情况下，clean/GC 将选择包含 "处理" > 8% 的失效数据的 4.5 Mb 容器

其次，它必须删除 DDR 上的死数据—简要说明如何完成此操作，如下所示：

• 再次检查选择用于处理的容器，以确认其是否拥有大量失效数据
• 实时数据从这些容器中提取并写入到文件系统末尾的新 4.5 Mb 容器中
• 完成后，所选容器（包括其包含的死数据）将从物理上释放磁盘空间的磁盘中删除。

清理过程将拆分为多个阶段，其中的阶段数取决于：

• 在 DDR 上使用的 DDOS 版本（因此，默认情况下，此版本的 DDOS 使用的是清理算法）
• 系统的配置/内容

但是，一般情况下，发现 "失效" 数据并选择相应容器的过程会跨多个阶段进行，而在单个阶段（称为 "拷贝"）中删除死数据会发生。例如，某些版本的 DDOS 将按如下所示运行清理阶段：

1. 预枚举—枚举 DDFS 文件系统的内容
2. 预合并—执行 DDFS 索引合并，以确保将索引信息的最新副本刷新到磁盘
3. 预先筛选器—确定 DDFS 文件系统中是否存在重复数据，如果是，则为
4. 预先选择-确定应通过清理来 "处理" 4.5 Mb 容器
5. Copy —从所选容器进行物理提取，将此数据写入新容器，然后删除选定容器
6. Summary —重建摘要向量（在接收新数据的过程中用作 optimisation）

在上面的示例阶段1-4 用于确定 DDR 上存在 "坏" 数据的位置（在本文档的其余部分称为 "枚举阶段"），而阶段5（拷贝）用于实际删除此数据。

请注意，在清理/GC 到达拷贝阶段之前，不会在系统上物理释放空间。因此，开始清理和开始释放空间之间可能存在显著延迟（因为必须首先运行完成的枚举进程）。因此，在启动清理/GC 之前，不应允许系统填满100%。

枚举阶段的成本通常是 cpu utilisation （即通常绑定 CPU）的成本，而拷贝阶段的成本代价是 CPU 和 i/o （即通常是 CPU 和 i/o 绑定的）。但在摘要中，可以说：

• 枚举阶段的总长度取决于需要枚举的 DDR 数据量
• 拷贝阶段的总长度取决于需要删除的 DDR 上的失效数据量，以及数据在磁盘上的碎片化程度（如下所述）

枚举阶段的数量/功能取决于 DDR 上使用的 DDOS 版本。

DDOS 5.4 （及更低版本）—全清晰算法：运行6或10个阶段（如上图所示）：

• DDFS 文件系统的内容枚举从上到下（即，以文件为中心）
• DDFS 会发现 DDR 上存在的所有文件，然后依次扫描每个文件，以确定该文件引用的数据
• 这允许清理/GC 确定磁盘上的哪些数据是 "live"

DDOS 5.5 （和更高版本）-物理清理算法（PGC）：运行7个或12个阶段：

• DDFS 的内容将向上枚举（即它不再扫描单个文件）
• DDFS 会发现在磁盘上引用物理数据的文件系统元数据，并扫描该元数据以确定引用的数据
• 这允许清理/GC 确定磁盘上的哪些数据是 "live"
• 这是通过添加 "分析" 阶段实现的（因此，在完整清理算法中的相位计数增加）
• 但是，在大多数情况下，物理清理的总持续时间预计比同一系统的完全干净要短（尽管包含多个单独的阶段）

DDOS 6.0 （和更高版本）—完美物理清理算法（PPGC）：

• 这只是一个 optimisation 的物理干净算法，并在下面将进一步讨论

请注意，DDOS 从全清晰算法切换为物理干净算法，以提高枚举过程的可扩展性/性能—由于完整清理算法的自上而下程度，它不能在 Ddr 上很好地扩展，方法是：

• 大量小文件（当从一个文件的枚举移至下一个文件时，上下文切换非常昂贵/缓慢）
• 高重复数据消除率（作为多个文件引用相同的物理数据，以便多次枚举相同的数据）

从 DDOS 5.4 （或更早版本）升级到5.5 （或更高版本）时，Ddr 会自动从完整到物理清理算法进行切换。唯一的例外情况是配置有延长保留空间的系统，其中 DDFS 文件系统的内容需要在可以启用物理清洗之前检查 "扩展" 文件—此过程的讨论超出了本文档的范围，但在完成此检查后，此检查将自动运行，并且无需手动操作。

当从 DDOS 5.x 升级到6.0 （或更高版本）时，同样的 Ddr 会自动从物理到完美的物理清理算法进行切换。但是请注意，理想的物理清理算法要求索引为 "索引 2.0" 格式，然后才能使用。请注意：

• "索引 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 上的数据大小/数量。要讨论执行索引重建，请联系您的签约支持提供商。

如上面所述，无论使用何种清理/GC 算法，clean 都可能需要可变数量的阶段—例如完整的清理算法可能需要6或10个阶段。这样做的原因是：

• DDFS 启动后，它会保留要由清理/GC 使用的固定内存量
• 在此内存清理/GC 中，创建数据结构以描述枚举的结果（即磁盘上存在 live 与死数据的位置）
• 当 DDR 包含相对少量的数据时，DDFS 文件系统的完整内容可以在此内存区域中进行说明
• 但是，在许多系统上，在枚举 DDFS 文件系统的全部内容之前，此内存区域可能会耗尽
• 因此，这些系统会执行 "采样"，这会增加所需的清理阶段数

当使用采样时，clean/GC 将：

• 在整个文件系统中执行枚举的采样传递—请注意，此枚举不是 "complete" （即，它不会记录有关文件系统每个部分的完整信息，而不是近似于文件系统的每个部分的信息）
• 使用此采样信息可以确定 DDFS 文件系统的哪个部分将获得最大的优势，以便对其进行清理/GC （例如，文件系统的哪个部分在被清理的空间方面得到了最佳返回）
• 针对文件系统的所选部分执行第二轮枚举，其内容现在可以在保留用于 GC 的内存内完全描述

如果需要，采样将在清理/GC 期间自动启用，但会导致：

• 需要通过清理/GC 执行的阶段数增加
• 清理/GC 的总持续时间的对应增加

在 DDOS 6.0 之前，大多数 Ddr 在清理/GC 期间执行采样（除非它们拥有相对较小的数据集）。但是，完美的物理清理算法包括各种 optimisations，以减少在文件系统中枚举数据时清理/GC 所需的内存量。这意味着，在 DDOS 5.x 上执行清理/GC 期间进行采样的许多系统不再需要在 DDOS 6.0 上取样，因此这会减少清理所执行的阶段数，并导致总清理运行时间的相应减少（即清理性能的改进）。

没有可用于直接确定系统是否已从物理干净算法切换到完全清晰的物理清理算法的信息：

• 当系统在 DDOS 5.5-5.7 上运行物理清洁时，在清理过程中执行了12个阶段
• 在升级到 DDOS 6.0 （或更高版本）的系统之后，在清理过程中仅执行7阶段

如果运行 DDOS 6.0 的系统仍需要执行采样，将在清理过程中自动启用此功能，并且在清理期间将回滚到运行12阶段。

无论使用何种干净算法，拷贝阶段（在物理上从系统中取出死数据）的功能都在所有版本中以相似的方式工作。拷贝阶段的性能通常取决于：

• 必须删除的 "失效" 数据量
• 此死数据的 "碎片化" （即它在磁盘间的分布方式）

如上所述，copy works 通过选择包含失效数据的 4.5 Mb 容器，从这些容器提取任何实时数据，并将该实时数据写入到新容器，然后删除最初选定的容器。以下示例介绍了失效数据的碎片整理是非常重要的：

示例1：

• 为拷贝选择了10个容器（45Mb 总计数据）
• 所有这些容器均不保存实时数据（即他们保留的数据完全未引用/失效）
• 因此，拷贝只需将这些容器标记为已删除即可释放磁盘上的45Mb 物理空间

示例 2：

• 为拷贝选择了100容器（450Mb 总计数据）
• 其中每个容器均包含90% 的活动数据/10% 的数据失效数据
• 要处理这些容器拷贝，必须执行以下操作：

与示例2中所述的拷贝相比，要显著增加 i/o 和 CPU 的数量非常大，因此，在此示例中，将显著释放45Mb 物理空间。

用户通常无法控制 DDR 上磁盘上的死数据，因为这很多取决于写入系统的数据的使用情形/类型。但是请注意，清理/GC 确实会保留统计信息，以帮助确定在拷贝阶段中遇到的死数据的 "零碎" （因此允许用户确定此碎片是否可以解释可能长时间运行的拷贝阶段）。Autosupports 中收集了来自全新/GC 的最新阶段的此类统计信息。例如，下面显示了死数据相当连续的拷贝阶段（即，大多数为拷贝保存选择的容器数通常会失效数据）：

拷贝的活动数据的百分比：              3.6% 4.3%

相反，下图显示了发生故障的数据被分段的拷贝阶段（即，大多数选择用于拷贝存储的容器大部分活动数据）：

拷贝的活动数据的百分比：             70.9% 71.5%

如上面所述，清理/GC 将必须在第二种情况下执行相对更多的工作，以实现 DDR 上的物理可用空间，这会导致拷贝阶段的吞吐量减少。

拷贝阶段的吞吐量也会受到以下影响：

• 使用加密：可能需要在拷贝期间对数据进行解密/重新加密，这会显著增加所需的 CPU 容量
• 使用低带宽 optimisation：容器可能需要在拷贝期间生成 "草图" 信息，这也会导致所需 CPU 数量显著增加

请注意，如果您最近已启用低带宽 optimisation 和/或加密，则可能需要对所有现有容器进行加密和/或在随后的清理过程中为其生成草图信息，这可能会导致清理操作（特别是拷贝阶段）比正常时间要长得多。

下面的知识库文章中提供了有关检查/修改清理计划和限制的进一步说明： https://support.emc.com/kb/306100

注意：

• 在正常情况下，清理应计划每周运行一次，但这会导致磁盘上的数据变得过多（例如，出现空间较差的空间），这可能会导致读取/复制/数据移动性能不佳
• 清理限制不会影响清理所消耗的 CPU 和 i/o 带宽总量，而是控制对系统上其他工作负载的敏感清理。例如：

• 默认情况下，清理限制设置为50—用户有责任使用不同的限制设置测试运行整洁，同时 DDR 会经历正常工作负载以确定允许的限制设置：

• 请注意，只要执行以下操作，运行时间长不一定就是问题：

• 应配置使用延长保留功能的系统，以便：

• Autosupports 和详细信息中包含最新的清理操作的完整信息：