GUFI: Fast, Secure File System Metadata Search for Both Privileged and Unprivileged Users——论文阅读

SC 2022 Paper 元数据论文阅读汇总

“High-Performance Computing (HPC)” 高性能计算

背景

Oak Ridge 领导计算设施和劳伦斯利物浦国家实验室计算设施描述他们的命名空间包含十亿个文件，并且预计在不久的将来这些命名空间将服务数百亿个文件[5, 6]。其他大型科学计算站点也在各种文件系统上生成和存储以达到数十亿文件的 PB 级数据[17-19]。处理极大数量的文件不仅仅是科学计算用户的问题，娱乐行业也存储和处理数十亿个文件[20]。庞大的文件数量以及与用于匹配高性能计算平台性能的文件系统相关联的 PB 级快速存储，导致管理员广泛依赖限额和自动清理旧数据，以保持随着时间推移的存储性能[21]。因此，一个快速的元数据查询系统是必要的，以便设施用户可以定位和管理数据，推动他们的科学工作流，并作为共享存储资源的负责任用户，确保最有价值的数据得到适当的归档，并且庞大的临时数据集不会膨胀到超过限额的大小（导致批处理作业失败），也不会违反设施的容量和清理政策。

HPC 数据中心中严格的策略执行机制的积极方面是，已经形成了成熟的批处理工具生态系统，用于执行完整的文件系统扫描。系统管理员每晚运行作业，遍历数十亿个文件以计算使用统计信息，并定位将要删除的陈旧文件系统数据。此外，许多本地和分布式文件系统提供仅供管理员使用的工具，支持快速的命名空间扫描以支持这些作业。例如，IBM 的信息生命周期管理库为 Spectrum Scale 提供了快速的 inode 扫描[22]，其他分布式存储系统也存在类似的功能[23-25]。构建这些快速、仅供管理员使用的扫描技术输出的模式和索引，并创建用户可访问的查询工具，是实现科学数据敏捷、符合政策的数据管理系统的关键组成部分。

高性能计算（HPC）数据中心提供各种数据服务，以满足多样化的工作负载需求[1, 2]。定制特定的存储系统来提供特定服务的空间，例如用户特定的文件（/home）、协作空间（/project）、大容量数据存储服务（/scratch）和归档存储服务（/archive），因此每个服务在单独的挂载点上都具有单独的命名空间。为工作负载定制的存储系统能够提供比通用系统更高的性能[3]。为了将数据引导到正确的系统，工作流程为在每个数据处理步骤期间，协调不同数据服务之间的数据移动[4]。虽然 HPC 存储的专业性使用户能够高效执行各种科学工作流，但也对系统用户和集群管理员产生了负担，需要有效地定位和管理分布在各种可用存储系统中的大量文件。

当总文件数量较小时，可以通过标准的数据管理工具如 du 和 find 来有效地完成集群范围的数据管理任务。这是因为大多数数据存储系统提供了支持传统 POSIX 文件系统接口的分层命名空间，使得大量常见的数据管理查询可以直接分解为，对底层存储系统元数据管理器的单独目录扫描和文件属性检索请求。随着时间的推移，无论集群大小如何，每个数据服务创建的文件数量都会增长到庞大的数字和容量[5]。现代 HPC 数据中心通常存储庞大的数据集，包括数百万个目录和数十亿个文件[6]。即使今天最快的分布式文件系统元数据服务器能够每秒执行数十万次，甚至是数百万次元数据操作[7-10]，但大量小型元数据查询请求必须发送到单个存储系统，使得高级数据管理查询变得越来越昂贵，导致查询响应时间不可接受。特别是当查询需要扫描未能在存储系统服务器内存中缓存的文件或目录时。

一个关键的问题是：为什么用户不能直接使用分布式文件系统提供的可扩展元数据平面执行查询？分布式元数据服务通常被调整为，同时从数千或数百万个进程中创建或打开最新文件时提供最高性能，快速的并行文件系统旨在提供横向扩展的性能。虽然当科学应用程序同时从100万个核心中创建和打开文件时，可扩展性是一项资产，但当用户试图从交互式 shell 中搜索数百万个文件的子树中的单个名称时，它没有实际用途。使用数千个计算核心进行搜索现有文件的并行搜索工具[26, 27]由于计算资源的低效使用而不切实际。首先，这些工具消耗宝贵的计算平台时间执行基本的文件系统操作，而不是利用现代处理器的能力推进科学模拟和基于 AI 的发现。其次，这些并行作业必须通过面向批处理的资源管理器（例如 Slurm Workload Manager）进行调度，并且可能需要在作业执行之前在队列中等待数小时。现代的并行和分布式文件系统并不是为了支持科学数据管理所需的高效、交互式查询而设计的，因此需要额外的工具来为 HPC 数据中心和设施提供强大的元数据查询能力。

构建可查询的元数据资源的明显解决方案是利用数据库技术。然而，数据库和文件系统之间的一个重要区别是访问控制的细粒度。文件系统支持对权限的精细控制，使用户能够创建文件和目录，并控制其他用户和用户组能够访问或禁止访问这些文件和目录。这种类型的访问控制在数据库技术中很难实现，并需要在企业级关系数据库管理系统中提供的行级安全性。最先进的行级安全性机制导致查询性能损失约30%，数据库更新性能损失约20%[28]。理想的文件系统元数据查询工具不应对用户级查询产生与安全相关的减速，而应通过仅在用户能够访问的文件系统内容上进行搜索而不是对所有文件系统条目进行扫描，从而提高性能。

现有方法的问题和挑战

图1显示了常见元数据查询在大型 HPC 集群中通常可用的文件系统、本地文件系统以及本文的 GUFI 服务的性能。每个查询遍历 Linux 5.8.9 内核源树中的74,000个文件，显示对每个系统的元数据层执行递归目录列表（find -ls）和磁盘使用情况（du -s）所需的时间。这些程序使用 readdir 和 stat 系统调用，这些系统调用是所有文件系统元数据查询的构建块。尽管所有文件系统都使用了快速的 SSD 进行元数据存储，并具有服务器端的元数据缓存，并行文件系统 Lustre [11] 和 GPFS [12] 无法提供快速的元数据查询性能。

现有的元数据搜索解决方案为数据中心提供了低延迟、可搜索的索引[13-15]，依赖于数据库技术以实现高水平的查询性能，但无法配置以执行传统文件系统使用的分层权限。因此，这些系统在不牺牲POSIX权限下不能直接向用户公开。

现有的文件系统和文件系统索引[14, 16]，通常缺乏允许在文件系统元数据和文件扩展属性之间进行快速、复杂查询的丰富模式。由于文件系统命名空间的分层性质，许多常见查询需要总结文件系统子树的内容，或查找每个用户的最大文件（在兄弟目录之间进行的一组查询）。现代元数据系统可能加速配额强制系统，但提供的物化视图和索引很少加速用户查询。

本文工作

我们提出了 Grand Unified File Index（GUFI），是一个用于在多个文件系统中搜索元数据和属性的单一统一索引。该索引通过扫描数据中心内的文件系统，创建集群嵌入式 SQL 数据库来构建，这些数据库被分片以强制执行文件系统权限。由于 GUFI 严格执行 POSIX 权限，因此可以直接被用户和管理员访问。GUFI 构建的索引，加速了整个数据中心范围内的交互式命令行查询和基于 Web 的元数据搜索生成的查询。由于底层索引存储在一组嵌入式数据库中，并通过 SQL 访问，GUFI 支持使用传统元数据查询工具性能较差的复杂查询。由于分片是基于 SQL 的，通过添加表、连接和其他机制来扩展 GUFI 是简单易行的。由文件系统访问权限分片的统一索引还使 GUFI 能够轻松地在所有可用的分片上并行处理查询，以实现在快速 SSD 上的高水平查询性能。

与当前文件系统元数据的索引技术相比，GUFI 在真实生产文件系统命名空间上由管理员执行的查询中能够提供1.5倍至230倍的加速。用户执行的查询通常无法依赖于集群范围的索引，使用 GUFI 甚至能够实现更大的加速。

GUFI 元数据索引相对于现有的可扩展文件系统和元数据索引还提供了其他优势。首先，GUFI 系统被设计为一个能够对数据中心内所有文件系统的内容进行索引和查询的服务。其次，GUFI 索引既可以组合又可以分解，因此索引中的任何目录或目录子树都可以由管理员根据需要轻松添加、更新或删除。第三，GUFI 索引提供索引构建工具，利用常见存储系统的自定义功能，以支持更快的索引创建和更新。最后，GUFI 在其实现中利用了开源文件系统和嵌入式数据库，以减少部署复杂性。

GUFI 的设计与实现

文件系统元数据索引为数据中心提供了两个好处。首先，一个快速、可搜索的索引使得定位数据并在文件系统之间协调数据移动变得更容易。其次，它将元数据密集型查询从高度优化的文件系统关键任务中移开，将这些查询定向到专用的交互式元数据资源，这可以显著减少大规模并行作业的性能损失[29]。GUFI 索引目标是超越这些基本好处，具体表现在：a) 专门设计将权限信息编码到文件系统元数据和扩展文件属性索引中，以便用户可以直接、高效地查询结果索引。b) 提供一个丰富的模式，支持对文件系统子树中常见查询的快速数据检索。c) 使用一组算法，既减少每个查询访问的数据量，又有效地实现与今天快速SSD速度相匹配的高性能水平。

GUFI 架构

如图2所示，GUFI 索引系统包括一个服务器、交互式查询客户端和一组通用或定制的文件系统扫描器（或树遍历器）。服务器存储所有索引，这些索引是存储在一个或多个本地 SSD 上的文件系统目录层次结构中的一组嵌入式数据库文件。这些嵌入式数据库定期由 GUFI 索引构建器重新构建，该构建器使用通用或定制的文件系统扫描器从给定的一组源文件系统中提取元数据。在大多数情况下，扫描器作为特权进程在给定源文件系统的元数据服务器上运行。客户端搜索通过将查询发送到 GUFI 服务器上进行。为了充分利用可用的存储带宽，每个查询被划分为大量子查询，并同时在服务器上存储的数据库层次结构上执行。通过将数据库存储在与原始源文件系统相同的层次结构中，GUFI 能够强制执行与这些文件系统使用的相同的分层权限方案，并通过使用支持标准 SQL 查询的数据库，GUFI 可以提供强大的文件系统元数据查询功能。

GUFI 索引

【索引的各种基础功能：结构、创建、更新、访问】

系统定义元数据的安全索引

【根据原始目录结构，构建新的基于嵌入式数据库的索引】

POSIX 兼容的文件系统以目录、子目录和非目录条目的形式提供了文件系统存储的信息的分层视图。POSIX 文件权限经常被误解的一个方面是，如何控制对元数据条目的访问。对文件或目录进行 stat（或列出其扩展属性名称）的权限仅要求该条目的每个父目录对用户可搜索。没有要求该条目本身必须可读（尽管访问扩展属性值确实要求设置条目的读取位）。在用户空间中实现对搜索位检查的层次结构是难以高效实现的，需要通过特权进程仔细复制内核强制的文件访问控制。

如图3所示，GUFI 重用操作系统的文件系统权限强制，并在索引中重新创建源文件系统的目录结构。文件、目录和符号链接的元数据，如 UID、大小和访问权限，都存储在索引中每个目录中的单个嵌入式数据库文件中。嵌入式数据库功能由开源的 SQLite库[30]提供。整个 GUFI 索引只是一组数据库文件和目录，可以像一组文件和目录一样进行管理。支持快照、归档、文件传输工具甚至版本控制的系统工具都可以无缝地与 GUFI 索引配合使用。由于 GUFI 仅是元数据的索引，数十亿文件的存储系统产生的索引大约为数百 GB。

用户定义元数据的安全索引

【根据权限信息划分多个数据库，确保元数据访问的安全性】

扩展属性（XAttrs）是 POSIX 的一个特性，它允许将名称-值对添加到文件和目录中。随着数据中心开始支持对 AI 工作负载进行更多的数据标记，扩展属性在 HPC 中的重要性日益增加。尽管 XAttr 名称受到与系统定义的元数据相同的保护，但 XAttr 值必须像文件数据一样受到保护。在索引中安全存储 XAttr 数据是复杂的，并依赖于以下规则：

• 一个目录的 XAttr 值存储在该目录内的主嵌入式数据库中。

• 任何具有与其父目录相同权限的文件都将其 XAttr 值存储在主嵌入式数据库中。

• 对于所有权与父目录不匹配的文件，将为每个用户创建一个嵌入式数据库（由相应的 UID 拥有，GID 设置为 none），用于存储该用户可访问的所有 XAttr 值。

• 对于组（组包含有权限的多个用户）与父目录不匹配的文件，将创建两个每个组的嵌入式数据库（UID 为 none，GID 设置为相应组）。一个数据库用于存储组可读的 XAttr 值，另一个用于存储组没有读取权限的 XAttr 值。

通过在每个用户和每个组的嵌入式数据库上设置所有权和组，用户只能读取他们有权访问的 XAttr 值。我们允许用户访问存储在他们自己的 UID 下的所有 XAttr，包括那些他们当前没有启用读权限的 XAttr。文件所有者可以轻松地更改其在源文件系统上的文件权限，因此阻止对这些 XAttrs 的访问不会增加真正的安全性。我们创建了两个每组的数据库，以区分根据组读取权限可访问和不可访问的 XAttr 值。

索引创建工具

【利用一些管理员专用工具进行快速索引创建，也可以根据用户需要立即更新单个目录索引】

为了构建 GUFI 的输入数据，需要对包含在索引中的每个源文件系统执行元数据扫描。此扫描是以特权用户身份执行的，以确保权限不会阻止对源文件系统的任何部分的访问。

在最坏的情况下，为索引创建输入数据集的时间需要对源文件系统进行完整的树遍历，这在源文件系统的元数据服务器内执行，以最小化访问延迟。简单的扫描工具可能需要数小时才能扫描数十亿个文件和目录。幸运的是，许多本地和分布式文件系统提供仅供管理员使用的工具，提供更快的命名空间扫描。GUFI 工具集利用这些接口的扫描工具（如果可用）。例如，GUFI 利用 IBM 的信息生命周期管理库为 Spectrum Scale 提供快速的索引扫描[22]，其他存储系统也存在类似的功能[23-25]。对于提供快照功能的网络文件系统，例如 WAFL [31] 和 ZFS [32]，GUFI 扫描工具利用一致的快照来生成元数据状态的准确索引。然而，即使可以在几分钟内完成扫描，如果执行源文件系统的扫描，则 GUFI 索引只能使用几分钟前的数据，在源文件系统扫描过程中正在进行的大数据移动将无法很好地被描述。

为了更新陈旧的索引数据，GUFI 包括一个工具，允许用户请求立即更新单个目录的索引和目录权限。这个工具是为在文件系统间迁移数据的文件传输程序而设计的，它后来被用于用户意识到他们在元数据中暴露了敏感信息，并且必须立即强制更新可见性或元数据内容的情况。在这种情况下，该工具用于触发立即的索引更新，并保留用户强制执行的元数据可见性的安全性。

在线索引更新

【4小时更新一次索引，索引中有旧数据也可以接受】

GUFI 索引的更新基于一个拉取过程，该过程以可配置的间隔检索最新的源文件系统扫描。根据表I中显示的扫描时间，我们的设施使用4小时的索引更新间隔。此更新频率是基于最慢源文件系统可以扫描的实际速率而确定的，而无需大量客户节点执行扫描。参与扫描的大量节点有可能导致影响数据中心内运行的批处理作业的大量元数据负载。

一些源元数据系统，例如大型磁带存档，基于 SQL 的扫描技术无法并行化，可能无法在间隔窗口内生成完整的跟踪。在这种情况下，GUFI 会拉取并应用最新完成的扫描数据到索引中。在许多情况下，索引的创建可以有效地与扫描重叠，因此拉取过程能够检索一个完全创建的 GUFI 索引。即使在将索引作为 GUFI 服务器的后处理步骤构建的情况下，由于我们依赖本地文件系统的性能来创建和存储索引，创建时间是廉价的。正如表I的最后一列所示，我们的通用服务器使用内核文件系统（例如XFS [34]）能够在大约18秒内创建1M个带有数据库的目录，并在不到120秒内插入100M个索引行。

更新过程是对指向新索引的符号链接的重命名，以覆盖指向陈旧索引的符号链接，从而允许现有查询和新查询同时更新。尽管批量扫描的缺点是显著的，但拥有两个相隔几个小时的完整命名空间快照，也可以对数据在文件系统内部和之间的移动进行被动测量。此外，在许多云和 HPC 数据中心中，命名空间和数据变化的最大驱动因素是，由调度程序以非交互方式执行的并行批处理作业，并且用户知道即使在实时文件系统上进行命名空间查询也包含过时数据。

索引访问控制

【为了避免用户修改索引， 用户使用时只能通过固定方法以只读权限访问索引】

由于 GUFI 实现了整个数据中心的单一共享索引，包括用于管理的索引，因此要确保索引不被用户损坏。因此，尽管索引目录权限包括读取和写入权限设置（保留原始目录权限），但对于用户来说，对索引的访问是只读的。为了提供对索引的只读访问，一种解决方案是在客户端系统上直接执行对索引的只读挂载，但在部署过程中，只读挂载导致用户混淆，因为源目录包含文件的目录树和包含嵌入式数据库的相同的索引目录都可用。我们为 GUFI 开发了一个 FUSE 接口，但未能实现较好的查询性能。

图4显示了索引如何在数据中心内部署，以实现远程只读访问，同时支持通过并行工具集进行访问。每个具有索引访问权限的客户节点都会创建一个空目录（通常命名为/search），可用作 GUFI 命令行工具的输入。当用户在 /search 目录下指定 gufi_find 或 gufi_ls 时，通过从客户节点向索引的服务器发送远程调用来查询索引。这种访问通过受限制的 shell 进行安全控制，该 shell 只允许在服务器上调用 GUFI 工具。Web 访问的交互方式类似，用户身份验证后，通过 Web 请求搜索或使用预生成的查询，查询结果描述了各种元数据特性，例如用户的最大文件及其最近访问的文件。每个查询都需要通过身份验证服务（例如LDAP）进行完全授权，以便新注册用户访问权限的更改，并且所有查询都遵循最新的系统访问权限。

为了防止普通用户执行修改 GUFI 模式的查询，所有用户界面的查询工具只能以只读标志（O_RDONLY）打开嵌入式数据库文件。尽管修改数据库模式的能力是一种强大的功能，我们只允许管理员查询工具以启用该功能所需的写标志打开数据库文件。

索引架构

【为了实现数据库的高效查询，根据命名空间的信息建立了多个便于查询的表：entries、summary、tsummary、pentries、XAttr。空间换时间的策略】

数据库模式被构建为高效地回答许多类型的查询，并提供了三种类型的 SQL 记录保持表：

• entries：一个表，用于存储每个目录条目（文件和链接）的元数据。

• summary：一个表，描述当前目录以及当前目录条目特性。

• t[ree]summary：一个表，总结整个树的特性，从当前目录开始。

entries 表是与目录条目索引常见的相关的元数据属性的复制。summary 表描述了有关当前目录的信息，包括最小文件大小、最大文件大小、文件数量、总目录大小、目录自身的元数据。 summary 表提供的附加数据显著降低了常见查询的成本，这些查询旨在确定子树使用了多少空间或定位子树内最小/最大的文件。 tsummary 表不会在构建索引时默认创建，需要管理员触发构建的过程，生成的表总结了表下方的每个文件和目录的大小、用户计数、组计数以及其他信息。summary 和 tsummary 表都具有整体、每用户和每组记录，因此使得每用户或每组摘要查询非常高效。

GUFI 还提供了具有修改模式的表的持久视图，以简化查询。其中一个视图是 pentries，如图5所示，它是带有父索引列的 entries 表。

由于索引存储在嵌入式 SQL 数据库中，可以添加到索引的字段几乎没有实际限制。查询索引的工具可用于添加表和视图或修改模式。虽然我们不希望管理员利用这个能力，但可以简单地将索引复制到一个临时位置，递归地修改模式以支持自定义查询，并将该更改包含在类似于 tsummary 构建的过程中。

扩展属性架构

XAttr 名称存储在 entries 表的一个列中。XAttr 表是一个包含2列的表：与 XAttr 相关联的条目的索引和 XAttr 值。不直接查询具有此模式的表，而是在当前目录中对目录数据库的 XAttr 表执行并集，来创建一个唯一可访问 XAttr 视图，其中当前目录的每个用户和每个组的 XAttr 数据库文件都已经打开。用户无法打开的每个用户和每个组的 XAttr 数据库不可访问，不包括在动态构建的数据库视图中。由于不同的用户将生成不同的视图，我们不提供 XAttr 的持久视图。为方便起见，我们自动生成将 entries  pentries、summary 与 XAttrs 视图结合的临时视图。

为了优化，XAttr 索引期间在目录的数据库中创建了一个额外的表，用于跟踪生成的每个用户和每个组的 XAttr 数据库文件。这样就无需遍历目录以寻找要附加的 XAttr 数据库文件。

并行索引算法

GUFI 提供了工具的并行版本，这些工具复制了常见文件系统程序的行为，还提供了一个带有搜索栏的 Web 界面以及一套用于构建和管理索引的工具。所有这些工具都构建在并行树的基础上，该代码旨在快速打开目录和文件，同时在请求处理过程中的多个点执行数据聚合。这个代码以广度优先顺序下降的文件系统树为基础，每个目录由单个线程处理，子目录添加到队列中以供线程池后续处理。

源文件系统扫描

源树扫描按照广度优先的顺序处理源树的目录，以并行创建所有数据库的列表。每次将目录添加到工作队列时，都会分配一个单独的线程来处理每个目录的内容。为了将这些处理过的跟踪文件转换为目录和数据库，GUFI 提供了一个并行摄取工具，该工具根据需要创建目录，同时将条目插入嵌入式数据库中。GUFI 还提供了一个并行摄取工具，跳过列表构建阶段，并在遇到源目录时生成数据库。

并行索引查询

gufi_query 可执行文件直接访问 GUFI 索引，用于构建 gufi_find 和 gufi_ls 的工具。由于目录的权限被保留在索引结构中，查询工具仅搜索（按广度优先顺序）用户可以访问的数据库。因此，用户查询性能与用户可访问的元数据量成正比，而不是存储在整个索引中的数据量。由于索引模式包括摘要信息，因此许多查询不需要访问超过预先计算的摘要表。

查询处理始于用户提供的目录，提供的目录的子目录被发现并推送到线程池进行处理，在发现的目录数据库上执行提供给 gufi_query 的 SQL 查询。支持复杂的 SQL 查询需要高级操作，如聚合、唯一性检查和缩减操作。gufi_query 中还可以进一步在查询之间汇总结果，而不是在发现它们时从每个目录的数据库中打印结果。每个目录的结果被写入每个线程的内存数据库，以避免多个线程插入单个数据库时的争用。在索引遍历完成后，执行用户提供的 SQL 查询将每个线程的结果合并为一组结果，在合并的结果上运行用户提供的SQL查询，以打印最终的结果。

基于权限的共享

默认情况下，GUFI 索引复制源树目录的形状、所有权和权限。虽然这种方案使元数据访问控制变得简单，但每个目录一个数据库的方案通常导致了数百万个小型数据库，查询效率低下。为了提高性能，GUFI 识别整个子目录树具有兼容访问权限的机会，并将子目录的数据合并到父目录的数据库中。当子目录的访问权限与子目录顶部的数据库的访问权限兼容时，子目录条目可以合并到顶级数据库中，然后对更多的元数据进行汇总。与读取许多较小的数据库相比，这种优化既减少了查询期间访问的数据库数量，又增加了查询请求的大小。我们将这个合并操作称为 GUFI 索引卷积。

为了使目标目录卷积有效，必须满足两个条件。

• 目标目录下的所有子目录都必须卷积。

• 所有目标目录和子目录对的权限都必须满足以下任一条件：

  • 全局可读和可执行（即设置o+rx）

  • 匹配权限（用户、组和其他），相同的用户和组

  • 匹配用户和组权限，相同用户和组的可读和可执行（ug+rx），并且不是全局可读和可执行（即设置了o-rx）

  • 匹配用户权限，相同用户的可读和可执行（u+rx），并且不是组或全局可读和可执行（go-rx）

如果一个目录不满足上述条件，则其 summary 表被标记为未卷积。如果一个目录可以卷积，那么目录的数据库会修改，pentries 视图删除，并用与原始视图相同列和内容的 pentries 表替换，然后将每个子目录的 pentries 表复制进去。这允许将子目录的行插入到 pentries 中，而不会破坏位于 entries 表中的原始数据。每个子目录的 summary 表被复制到目录的 summary 表中，目录的名称前缀为子目录的名称，并标记为不是表中的原始行，然后将目录标记为已卷积。这一系列操作会递归地向上执行，使用用于卷积 XAttr 数据库的相同权限检查，以相似的方式执行每个用户和每个组的 XAttr 数据库的卷积。

被卷积的数据库和目录并没有删除。这有两个有用的效果：第一，因为所有的原始目录都存在并包含卷积数据，查询可以从任何目录开始，并利用该子树中存在的卷积。第二，如果需要撤销卷积（例如，为了执行用户请求的目录更新），那么撤销的过程比重新创建整个子树更轻量级。除了不重新创建子树的每个目录外，由于不依赖于任何其他目录的卷积数据，可以独立地撤销每个目录的卷积。删除目录卷积的步骤如下：删除 pentries 表，恢复 pentries 视图，并删除摘要表中最初不存在的行。

实验

表II显示了用于评估实验的硬件配置、系统软件版本和数据集特性。数据集1是在 NFS 文件系统上运行 GUFI 扫描并匿名输出生成的。数据集2是在 HPC 数据中心内的 Lustre 文件系统上进行 GUFI 扫描生成的，包括其所有真实元数据。对于每次实验，GUFI 索引都存储在本地 XFS 文件系统[34]中。修改后的 SQLite[30]3.27.2（实现优化的只读访问）用于实现 GUFI 的嵌入式数据库。

底层磁盘利用率

GUFI 将高级数据管理查询转换为并行的低级磁盘读取，利用并行性充分发挥磁盘性能，如图7(a)。随着磁盘增多主机成为性能瓶颈，如图7(b)。

基于权限的数据库汇总

通过数据库汇总可以显著降低数据库数量，汇总有时间开销，减少查询时的字节数，减少运行时间。

扩展属性查询性能

增加扩展属性可以有效提升查询性能。【但没统计增加扩展属性所需的时间】

宏观基准测试结果

比较四种查询，GUFI 性能好：

1. 列出用户可访问的所有文件名。

2. 打印用户可访问的每个目录的大小和名称。

3. 打印用户主目录（根目录的顶层）使用的空间。GUFI 通过访问多个数据库并对每个目录的摘要大小求和来执行。

4. 打印用户主目录（根目录的顶层）使用的空间。GUFI 依靠 tsummary 表来执行。

【实验不公平，GUFI 有大量的表的整理，没统计预处理的时间，只比较了查询时间】

总结

针对元数据查询的优化，通过构建外部元数据索引来加速元数据查询的性能。作者提出以下优化点：将各个底层文件系统的所有元数据汇总，构建统一的基于嵌入式数据库的新索引；在索引中添加多个表便于快速的数据库查询；在索引中增加目录汇总机制，减少数据库数量；将权限信息放入数据库中，实现并发索引查询。

局限性：实现只测试了查询效果好，但没有测试构建索引的时间开销和空间开销，整体来看是空间换时间的思路