CN109933570A - 一种元数据管理方法、系统及介质 - Google Patents

Abstract

本发明公开了一种元数据管理方法、系统及介质，本发明将文件系统中所有的目录和文件采用树形结构进行组织，且针对单个目录下的所有目录和子文件作为一个整体、按照创建的顺序依次保存在底层存储设备的连续地址空间上；元数据更新时，采用日志形式对一个目录下的所有子目录/子文件的更新操作按顺序追加在该目录的尾部，使得每次元数据操作仅引发一个IO请求；进行元数据检索时，在一个父目录下解析一个子目录首先要读取该父目录对应的连续地址空间上的所有数据，然后采用多种加速方法搜索匹配。本发明能够有效解决大目录问题，目录路径解析具有更低的延迟，能够减少元数据访问过程中的IO请求数，能够对文件系统的元数据访问实施加速。

Description

一种元数据管理方法、系统及介质

技术领域

本发明涉及大规模数据存储的文件系统的元数据管理领域，具体涉及一种元数据管理方法、系统及介质，用于对文件系统的元数据访问实施加速，提升文件系统数据访问整体性能。

背景技术

在大规模存储的文件系统中，元数据访问一直是制约IO性能的一大重要因素。元数据访问处于IO流程的关键路径上，其性能决定了整个文件系统数据访问性能的上限；在存储设备接收到的IO请求中，有一半以上由元数据访问产生，优化元数据访问将带来巨大的收益；应用程序往往对文件系统元数据发出大量不规则的小请求，这一IO特性为元数据优化带来巨大的挑战。主流的文件系统都针对元数据做了大量的精细优化，相关的技术可概括为以下几个方面。在宏观组织架构上，一些文件系统采用分布式元数据管理方式提升元数据访问性能。鉴于文件系统中一半以上的IO请求来自于元数据访问，将元数据分布到多个服务器上从而为应用程序提供并发访问能力是一种直观的优化手段。常用的并行文件系统如Lustre、CephFS、BeeGFS均采用这种优化措施，GlusterFS甚至采用无中心架构，将元数据分布到文件系统集群的所有服务器上。针对分布式元数据管理，研究人员提出了子树划分、动态负载均衡等技术手段实现多个服务器上元数据的合理布局。实践证明，这种集群方式能够显著提升文件系统元数据访问的总体性能。

在元数据存储结构上，传统的文件系统一般将元数据以普通文件的形式保存在存储设备上，当一个目录下包含大量的子目录或文件时，采用树形结构对这些子目录或文件进行索引。这种存储结构能够支撑单个目录下保存大量的子目录或文件，但随着子目录或文件数目的不断增多，访问性能会显著下降，主要是因为在树形索引结构下访问一个子目录可能需要从树根搜索到叶子节点，此过程中会产生大量的IO请求和计算操作。相应地，一些新型文件系统如TableFS、IndexFS采用NoSQL数据库、Key-Value系统保存元数据，这些数据结构具备良好的可扩展性和随机访问性能，能够在一定程度上改善元数据访问性能。

以上多项技术的结合使文件系统的访问性能有了很大的改观，但针对一些特定的问题还没有很好的解决方案，其中一个极具挑战性的就是在很多场景下普遍存在的大目录问题。例如，在高性能计算系统中，一个进行多轮迭代计算的作业派生出大量的进程，每个进程在一个迭代步完成后输出一个文件，每个迭代步产生的所有文件保存在一个目录中。当前的大规模高性能计算作业往往派生出十万量级以上的进程，导致每个迭代步对应的目录内包含大量的文件，而针对这些文件的元数据操作成为高性能计算作业的主要IO瓶颈。一些文件系统试图通过分布式元数据管理缓解这一瓶颈，例如，Lustre将整个文件系统名字空间以静态子树划分的形式分布到多个元数据服务器上，但这并不能解决单个目录包含大量文件的问题；CephFS可根据负载情况将同一目录下的大量文件分散到多个元数据服务器上，这种优化方法能够实现同一目录下大量文件的并发访问，但却破坏了文件元数据的局部性。总之，针对大目录问题目前仍然没有很好的解决方案。

导致文件系统元数据性能低下的另一个重要原因是元数据访问带来的读写放大问题。所谓读写放大，是指上层应用发出的每个元数据访问需要由多个IO请求完成。以TableFS为例，其元数据保存在LevelDB（Google工程师Jeff Dean和Sanjay Ghemawat开源的KV存储引擎）中，当创建一个文件时，需要将文件对应的元数据插入到LevelDB的排序的字符串表（Sorted String Table，简称SSTable）中，由此可能引发SStable的分裂操作，从而产生多个写请求；反之，从LevelDB中查找一个文件时，可能需要自顶向下的依次搜寻LevelDB的多个层次，从而产生多个读请求。一次文件系统元数据访问产生的多个IO请求一般是相互依赖的，很难并发处理，从根本上导致元数据访问性能难以提升。

近年来，计算机系统中计算、IO部件的性能取得了显著的进步。CPU的主频和核数均有不同程度的增长，GPU、KNL（Knight Landing）等各种加速器不断推出，以固态盘为代表的新型存储设备逐步普及使用，计算、IO部件的性能提升在系统软件领域催生出新的设计理念。以文件系统元数据为例，传统的文件系统倾向于针对有限的计算、IO性能做精细优化，如EXT4采用HTree树形结构索引同一目录下的所有子目录和文件，所有子目录和文件的具体信息保存在HTree的叶节点上，在目录搜索过程中从HTree根节点开始搜索，处理每一级的分支节点只需从存储设备上获取少量的数据并做少量的计算。以上优化措施所假定的前提条件是处理器和存储设备的性能都相对较弱，从而需要通过逐级索引减少数据的读写和处理。而在当前条件下，以GPU为代表的加速器能够提供千核量级的并发计算能力，以固态盘为代表的新型存储设备能够提供GB/s量级的带宽和十万IOPS量级的吞吐率，强大的计算、IO能力为文件系统的创新设计提供了契机。具体地，本发明重新设计文件系统元数据的存储结构，摒弃树形索引方法，保证任一元数据操作仅引发一次IO请求，从而减少数据IO导致的延迟，并借助CPU的多线程技术、向量处理技术、GPU的众核加速技术对数据实施并发处理，最终提升文件系统元数据的总体访问性能。

发明内容

本发明要解决的技术问题：针对现有技术的上述问题，提供一种元数据管理方法、系统及介质，本发明能够有效解决大目录问题，目录路径解析具有更低的延迟，能够减少元数据访问过程中的IO请求数，能够对文件系统的元数据访问实施加速，提升文件系统数据访问整体性能。

为了解决上述技术问题，本发明采用的技术方案为：

一种元数据管理方法，进行元数据更新的实施步骤包括：

1）将文件系统中所有的目录和文件采用树形结构进行组织，且针对单个目录下的所有目录和子文件作为一个整体、按照创建的顺序依次保存在底层存储设备的连续地址空间上；

2）进行文件系统元数据更新时，采用日志形式对一个目录下的所有子目录/子文件实施更新操作，所有的元数据更新按照发生的顺序追加在该目录对应的连续地址空间的尾部，使得每次元数据操作仅引发一个IO请求。

可选地，步骤2）的详细步骤包括：

2.1）文件系统接收到应用程序发出的元数据更新操作；

2.2）判定元数据更新操作的类型，若为创建新的目录或文件则跳转步骤2.3）；若为更新已有的目录或文件则跳转步骤2.4）；若为删除已有的目录或文件则跳转步骤2.5）；

2.3）生成文件/目录创建日志，跳转步骤2.6）；

2.4）生成目录/文件更新日志，跳转步骤2.6）；

2.5）生成目录/文件删除日志，跳转步骤2.6）；

2.6）将生成的日志追加到连续地址空间的尾部，跳转步骤2.7）；

2.7）将连续地址空间尾部持久化到存储设备上。

可选地，进行元数据检索的实施步骤包括：

S1）将文件系统中所有的目录和文件采用树形结构进行组织，且针对单个目录下的所有目录和子文件作为一个整体、按照创建的顺序依次保存在底层存储设备的连续地址空间上；

S2）进行文件系统元数据检索时，从目录路径的第一个分量依次逐层解析到最后一个分量，最终得到欲访问的目录或文件；且在一个父目录下解析一个子目录时，首先要读取该父目录对应的连续地址空间上的所有数据，然后在读取的数据上搜索目标子目录或子文件，直到匹配成功。

可选地，所述在读取的数据上搜索目标子目录或子文件时，具体是从连续地址空间的尾部向头部逆向处理，一旦检索到待查找的子目录/子文件，即可终止检索过程立即返回相应的元数据。

可选地，所述在一个父目录下解析一个子目录的详细步骤包括：

S2.1）收到应用程序发出的元数据检索请求，所述元数据检索请求为需要从一个父目录中检索目标目录或文件是否存在；

S2.2）通过一次读操作将父目录下所有子目录/子文件的相关信息获取到内存中，跳转步骤S2.3）；

S2.3）判定待解析的父目录大小，若父目录内子目录/子文件总数小于预设的第一阈值TH₁，跳转步骤S2.4）；若父目录内子目录/子文件总数在预设的第一阈值TH₁与预设的第二阈值TH₂之间，则跳转步骤S2.5）；若父目录内子目录/子文件总数大于预设的第二阈值TH₂时，跳转步骤S2.6）；

S2.4）采用多线程技术在父目录中检索目标子目录或子文件，跳转步骤S2.7）；

S2.5）采用向量指令在父目录中检索目标子目录或子文件，跳转步骤S2.7）；

S2.6）采用众核加速技术在父目录中检索目标子目录或子文件，跳转步骤S2.7）；

S2.7）若在父目录中查找到目标子目录或子文件则检索成功；否则检索失败，向上层应用返回检索结果。

可选地，步骤S2.4）、步骤S2.5）、步骤S2.6）三者中至少一个步骤中在父目录中检索目标子目录或子文件时采取从连续地址空间的尾部向头部逆向处理的方式实施搜索。

本发明还提供一种元数据管理方法，进行元数据检索的实施步骤包括：

S1）将文件系统中所有的目录和文件采用树形结构进行组织，且针对单个目录下的所有目录和子文件作为一个整体、按照创建的顺序依次保存在底层存储设备的连续地址空间上；

S2）进行文件系统元数据检索时，从目录路径的第一个分量依次逐层解析到最后一个分量，最终得到欲访问的目录或文件；且在一个父目录下解析一个子目录时，首先要读取该连续地址空间上的所有数据，然后在读取的数据上搜索目标子目录或子文件，直到匹配成功。

可选地，所述在一个父目录下解析一个子目录的详细步骤包括：

S2.1）收到应用程序发出的元数据检索请求，所述元数据检索请求为需要从一个父目录中检索目标目录或文件是否存在；

S2.2）通过一次读操作将父目录下所有子目录/子文件的相关信息获取到内存中，跳转步骤S2.3）；

S2.3）判定待解析的父目录大小，若父目录内子目录/子文件总数小于预设的第一阈值TH₁，跳转步骤S2.4）；若父目录内子目录/子文件总数在预设的第一阈值TH₁与预设的第二阈值TH₂之间，则跳转步骤S2.5）；若父目录内子目录/子文件总数大于预设的第二阈值TH₂时，跳转步骤S2.6）；

S2.4）采用多线程技术在父目录中检索目标子目录或子文件，跳转步骤S2.7）；

S2.5）采用向量指令在父目录中检索目标子目录或子文件，跳转步骤S2.7）；

S2.6）采用众核加速技术在父目录中检索目标子目录或子文件，跳转步骤S2.7）；

S2.7）若在父目录中查找到目标子目录或子文件则检索成功；否则检索失败，向上层应用返回检索结果。

本发明还提供一种元数据管理系统，包括计算机系统，该计算机系统被编程以执行本发明前述元数据管理方法的步骤，或者该计算机系统的存储介质上存储有被编程以执行本发明前述所述元数据管理方法的计算机程序。

本发明还提供一种计算机可读存储介质，该计算机可读存储介质上存储有被编程以执行本发明前述元数据管理方法的计算机程序。

和现有技术相比，本发明能够有效解决大目录问题，目录路径解析具有更低的延迟，能够减少元数据访问过程中的IO请求数，能够对文件系统的元数据访问实施加速，提升文件系统数据访问整体性能。，具体原因体现在以下几个方面：

（1）在本发明采用的技术方案下，从一个父目录内检索一个子目录或子文件仅需一次IO操作。本发明将一个父目录下所有子目录/子文件的元数据聚合后保存在存储设备的连续地址空间上，保证这些子目录/子文件的元数据可以通过一次读操作从存储设备上获取，因此在一个父目录下解析一个子目录时，仅需等待一次IO的延迟。相比之下，EXT4将一个父目录下的所有子目录/子文件索引在两层的HTree中，解析一个目录时需要在HTree中逐层搜索，至少需要两次IO操作，且第二层搜索对应的IO操作必须等待第一层搜索处理完毕才能发出，两次IO操作无法并发，导致目录解析必须容忍更大的延迟。TableFS等其他文件系统为同一父目录下的所有子目录/子文件建立复杂的索引，也存在类似的目录解析延迟过高的问题。本发明通过一次IO将一个父目录下的所有子目录/子文件同时取出，这会导致发出的IO操作较大，但因为当前的新型存储设备如固态盘能够提供很高的带宽，一次大的IO操作并不会导致IO延迟的显著提升。

（2）本发明能够减少元数据更新导致的IO操作，从而提升元数据更新性能。本发明以日志形式记录元数据的所有更新，当一个父目录下出现子目录/子文件创建、更新、删除等操作时，新的信息均以日志形式追加在连续地址空间的尾部。将更新的信息持久化到存储设备上时，只需针对连续地址空间的尾部发起写操作，不会引发写放大效应。相比之下，EXT4在更新元数据时可能引起索引结构的更新，TableFS更新元数据时可能引起LevelDB中SSTable的分裂，以上两种情况均会引起额外的写操作。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本实施例的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本发明实施例一进行元数据更新的基本流程图。

图2为本发明实施例一中采用的文件系统元数据存储结构。

图3为本发明实施例一中的文件系统元数据更新流程。

图4为本发明实施例一中的文件系统元数据检索流程。

具体实施方式

实施例一：

元数据管理方法的关键在于元数据更新以及元数据及按需哦，本实施例实施方式的关键在于如何将目录/文件的元数据保存在存储设备上，以及如何快速地从父目录中检索到特定的子目录/子文件。

如图1所示，本实施例元数据管理方法进行元数据更新的实施步骤包括：

1）将文件系统中所有的目录和文件采用树形结构进行组织，且针对单个目录下的所有目录和子文件作为一个整体、按照创建的顺序依次保存在底层存储设备的连续地址空间上；

2）进行文件系统元数据更新时，采用日志形式对一个目录下的所有子目录/子文件实施更新操作，所有的元数据更新按照发生的顺序追加在该目录对应的连续地址空间的尾部，使得每次元数据操作仅引发一个IO请求。

文件系统元数据的存储结构包含两个方面的内容，首先是文件系统中的所有目录和文件的逻辑组织方式，即文件系统的名字空间，目前大多数文件系统采用树形结构的名字空间；其次是单个目录下大量子目录/子文件的存储结构。以上两个方面对文件系统元数据的访问性能至关重要。对于第一方面，由于树形结构的名字空间最符合用户的使用习惯，本实施例保持这一组织方式不变。对于第二方面，存在多种不同的优化方案，如TableFS将一个目录下所有子目录/子文件整合在一起存储在NoSQL数据库中、ETX4采用HTree将一个目录下所有子目录/子文件索引到一个两级的树形结构中。以上方法存在的共性问题是：每次元数据操作会引发多个IO请求，且这些IO请求之间具有一定的依赖关系，难以并发处理，从根本上决定了文件系统元数据访问性能低下。本实施例的一个重要理念是：尽可能保证每次元数据操作仅引发一个IO请求。为此，本实施例将一个目录下的所有子目录/子文件作为一个整体保存在底层存储设备的连续地址空间上，保证一次读请求即可获取所有子目录/子文件的相关信息（同理，一次写请求即可将所有子目录/子文件的相关信息保存到存储设备上）。另外，不同于EXT4采用HTree将一个目录下所有子目录/子文件索引到一个两级的树形结构中，本实施例不针对一个目录下的所有子目录/子文件建立任何索引，也不进行排序，仅仅将所有子目录/子文件按照创建的顺序依次保存在连续地址空间上。因为一个目录内部没有任何索引，针对该目录下的所有子目录/子文件访问不会引入由索引导致的IO请求，从而进一步确保了“每次元数据操作仅引发一个IO请求”的理念。图2展示了本实施例采用的元数据存储结构。如图1右侧部分所示，文件系统的名字空间被组织成树形结构，其中，目录e包含i、j、n、p四个子目录/子文件。如图2左侧树形结构所示，文件系统为目录e分配了一段连续地址空间，其中i、j、n、p按照创建/更新的顺序保存在这段连续地址空间中。

如图3所示，步骤2）的详细步骤包括：

2.1）文件系统接收到应用程序发出的元数据更新操作；

2.2）判定元数据更新操作的类型，若为创建新的目录或文件则跳转步骤2.3）；若为更新已有的目录或文件则跳转步骤2.4）；若为删除已有的目录或文件则跳转步骤2.5）；

2.3）生成文件/目录创建日志，跳转步骤2.6）；本实施例中，生成文件/目录创建日志具体是指将新文件/目录的名字、标识号等信息封装到日志中；

2.4）生成目录/文件更新日志，跳转步骤2.6）；本实施例中，生成目录/文件更新日志具体是指此操作与文件/目录创建一样，完全生成一个新的目录或文件，原始目录或文件仍然保留在存储系统中，由于在元数据检索时采用逆向检索的方式，一个目录或文件的旧版本信息不会被检索到；

2.5）生成目录/文件删除日志，跳转步骤2.6）；本实施例中，生成目录/文件删除日志具体是指复制该目录/文件的原有信息，但在特殊的标志位上标记为“已删除”；

2.6）将生成的日志追加到连续地址空间的尾部，跳转步骤2.7）；

2.7）将连续地址空间尾部持久化到存储设备上。

元数据更新包括新目录/文件的创建、原有目录/文件的更改、原有目录/文件的删除。本实施例将一个父目录下的所有子目录/子文件聚合后保存在一篇连续地址空间上，针对这些子目录/子文件可能出现如下三种更新操作：（1）新目录/文件创建：当需要创建新的目录或文件时，直接在连续地址空间的尾部追加相关的元数据信息。（2）已有目录/文件更新：上层应用发起文件重命名请求时，会引起针对已有目录/文件的更新操作，本实施例采用日志更新的方式，不在原有目录/文件上直接更新，而是将新的元数据信息直接追加到连续地址空间的尾部。（3）已有目录/文件删除：上层应用发起删除操作时，本实施例采用日志更新方式，不直接删除原有的目录/文件，而是生成一条删除日志，直接追加到连续地址空间的尾部。总之，本实施例采用日志形式对一个目录下的所有子目录/子文件实施更新操作，所有的元数据更新按照发生的顺序追加在该目录对应的连续地址空间的尾部。

如图4所示，进行元数据检索的实施步骤包括：

S1）将文件系统中所有的目录和文件采用树形结构进行组织，且针对单个目录下的所有目录和子文件作为一个整体、按照创建的顺序依次保存在底层存储设备的连续地址空间上；

S2）进行文件系统元数据检索时，从目录路径的第一个分量依次逐层解析到最后一个分量，最终得到欲访问的目录或文件；且在一个父目录下解析一个子目录时，首先要读取该父目录对应的连续地址空间上的所有数据，然后在读取的数据上搜索目标子目录或子文件，直到匹配成功。

本实施例中，所述在读取的数据上搜索目标子目录或子文件时，具体是从连续地址空间的尾部向头部逆向处理，一旦检索到待查找的子目录/子文件，即可终止检索过程立即返回相应的元数据。本实施例通过从连续地址空间的尾部向头部逆向处理，针对活跃文件/目录的检索实施了专门的加速，具体原因如下：一般说来，最近创建或更新的文件属于热点文件，更容易被再次访问。本实施例将一个父目录下的所有子目录/子文件按照创建/更新的顺序依次保存在一篇连续地址空间上，目录解析时从连续地址空间的尾部开始向头部逆向处理，由于最近创建或更新的文件更接近尾部，这一逆向处理过程导致他们能够更快的被检索到。本优化方法能够显著降低热点目录/文件的检索延迟。

由于本实施例仍然采用树形目录结构，因此其目录路径解析的总体流程与传统的文件系统相同：从目录路径的第一个分量依次逐层解析到最后一个分量，最终得到欲访问的目录或文件。本实施例与传统文件系统的不同之处在于：解析一个特定分量时，如何从该分量的父目录中获取该分量对应的元数据信息，即单个目录的解析方法。这一问题很大程度上取决于一个目录下所有子目录/子文件所采用的存储结构。EXT4采用HTree索引一个父目录下的所有子目录/子文件，在一个父目录下解析一个子目录的过程即是HTree搜索。TableFS采用LevelDB保存一个父目录下的所有子目录/子文件，在一个父目录下解析一个子目录的过程即是LevelDB中针对一个Key读取相应的Value。本实施例将一个父目录下所有子目录/子文件的元数据作为一个整体保存在连续地址空间上，在一个父目录下解析一个子目录首先要读取该连续地址空间上的所有数据，然后在读取的数据上搜索目标子目录或子文件。由于本实施例没有为同一父目录下的所有子目录/子文件建立任何索引，这些子目录/子文件对应的元数据在连续地址空间上也没有排序，因此搜索过程实际上是一个线性查找操作，需要检查所有的子目录/子文件，直到匹配成功。

本实施例中，所述在一个父目录下解析一个子目录的详细步骤包括：

S2.1）收到应用程序发出的元数据检索请求，所述元数据检索请求为需要从一个父目录中检索目标目录或文件是否存在；

S2.2）通过一次读操作将父目录下所有子目录/子文件的相关信息获取到内存中，跳转步骤S2.3）；

S2.3）判定待解析的父目录大小，若父目录内子目录/子文件总数小于预设的第一阈值TH₁，跳转步骤S2.4）；若父目录内子目录/子文件总数在预设的第一阈值TH₁与预设的第二阈值TH₂之间，则跳转步骤S2.5）；若父目录内子目录/子文件总数大于预设的第二阈值TH₂时，跳转步骤S2.6）；

S2.4）采用多线程技术在父目录中检索目标子目录或子文件，跳转步骤S2.7）；由于目标子目录或子文件作为一个整体、按照创建的顺序依次保存在底层存储设备的连续地址空间上，因此可以分配各个线程分别处理连续地址空间的不同地址段来实现加速。

S2.5）采用向量指令在父目录中检索目标子目录或子文件，跳转步骤S2.7）；

由于目标子目录或子文件作为一个整体、按照创建的顺序依次保存在底层存储设备的连续地址空间上，因此可以将连续地址空间采用for循环的方式遍历来进行处理，采用向量指令加速即为通过使用向量来指令减少for循环的迭代次数，从而达到加速的效果。

S2.6）采用众核加速技术在父目录中检索目标子目录或子文件，跳转步骤S2.7）；

由于目标子目录或子文件作为一个整体、按照创建的顺序依次保存在底层存储设备的连续地址空间上，因此可以分配各个处理器核分别处理连续地址空间的不同地址段来实现加速。

S2.7）若在父目录中查找到目标子目录或子文件则检索成功；否则检索失败，向上层应用返回检索结果。

参见步骤S2.4）～S2.7），本实施例联合使用多线程、向量处理、众核加速等技术对目录解析过程实施加速。由于本实施例没有为同一个父目录下的所有子目录/子文件建立任何索引，在一个父目录下检索一个文件时需要与该父目录下的所有子目录/子文件匹配，此线性查找过程计算开销较大。本实施例根据父目录大小灵活选择多线程、向量处理、众核加速三种技术对匹配过程实施加速，能够显著缩短计算时间。本质上，本实施例采用以计算换IO的手段降低目录解析的延时，此方法能够取得良好效果的关键原因在于：目录解析过程中的IO操作很难并发，而计算过程可以借助当前的并行计算技术实施显著加速。

一般认为，线性查找的计算开销很大，然而当前的处理器普遍融入了多核多线程技术和向量运算部件，以GPU为代表的众核处理器则能派生出数千个线程，这些新型运算部件固有的并行性能够显著提升线性查找的性能。在此背景下，本实施例提出一种融合方案，分别采用多线程、向量运算、众核加速三种技术对不同大小的目录实施并行解析。具体地，本实施例设定两个阈值TH₁和TH₂，两者均为整数且TH₁<TH₂。假设需要从父目录a中检索子目录/子文件b，当目录a下的子目录/子文件数小于TH₁时，说明b下的子目录/子文件数较少，可采用CPU的线程实施目录解析；当目录a下的子目录/子文件数在TH₁与之间TH₂时，说明b下的子目录/子文件数相对较多，可采用CPU的向量指令实施并行解析；当目录a下的子目录/子文件数大于TH₂时，说明b下的子目录/子文件数很多，可采用以GPU为代表的众核协处理器实施并行解析。总之，本实施例采用不同的加速方法解析不同大小的目录，保证目录解析时计算过程不会引入很高的延时。

正如前文所述，本实施例采用日志追加的方式记录所有的元数据更新操作，这一措施使得一个父目录下的所有子目录/子文件在存储上符合以下两点特征：（I）最近创建的子目录/子文件保存在该父目录对应的连续地址空间上更靠近尾部的位置（II）最新更新的子目录/子文件保存在该父目录对应的连续地址空间上更靠近尾部的位置。

针对以上两点特征，本实施例提出一种加速优化方案：在目录检索时从连续地址空间的尾部向头部逆向处理，一旦检索到待查找的子目录/子文件，即可终止检索过程立即返回相应的元数据。步骤S2.4）、步骤S2.5）、步骤S2.6）三者在父目录中检索目标子目录或子文件时采取从连续地址空间的尾部向头部逆向处理的方式实施搜索，此外也可以根据需要在步骤S2.4）、步骤S2.5）、步骤S2.6）三者中至少一个步骤中采用上述加速优化方法。

本优化措施针对以上两种场景具有类似的加速效果：1、根据局部性原理，最近创建的文件更容易被上层应用再次访问，而本实施例将最近创建的文件保存在连续地址空间的尾部，从尾部向头部的逆向处理能够更快地检索到最近创建的文件。2、根据日志更新的原则，一个目录或文件的最近更新总是保存在更靠近日志尾部的位置，从尾部向头部的逆向处理能够保证最先检索到的元数据版本是最新的更新信息。总之，本实施例提出的从尾部向头部逆向检索的优化措施能够加速活跃文件的元数据访问。

此外，本实施例还提供一种元数据管理系统，包括计算机系统，该计算机系统被编程以执行本实施例前述元数据管理方法的步骤，或者该计算机系统的存储介质上存储有被编程以执行本实施例前述元数据管理方法的计算机程序。本实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有被编程以执行本实施例前述元数据管理方法的计算机程序。

实施例二：

本实施例与实施例一基本相同，其主要区别点为：本实施例为实施例一的子集，本实施例仅仅包含实施例一中进行元数据更新的相关内容，并提供了对应的元数据管理系统及计算机可读介质。

实施例三：

本实施例与实施例一基本相同，其主要区别点为：本实施例为实施例一的子集，本实施例仅仅包含实施例一中进行元数据检索的相关内容，并提供了对应的元数据管理系统及计算机可读介质。

以上所述仅是本发明的优选实施方式，本发明的保护范围并不仅局限于上述实施例，凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理前提下的若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种元数据管理方法，其特征在于，进行元数据更新的实施步骤包括：

1）将文件系统中所有的目录和文件采用树形结构进行组织，且针对单个目录下的所有目录和子文件作为一个整体、按照创建的顺序依次保存在底层存储设备的连续地址空间上；

2）进行文件系统元数据更新时，采用日志形式对一个目录下的所有子目录/子文件实施更新操作，所有的元数据更新按照发生的顺序追加在该目录对应的连续地址空间的尾部，使得每次元数据操作仅引发一个IO请求。

2.根据权利要求1所述的元数据管理方法，其特征在于，步骤2）的详细步骤包括：

2.1）文件系统接收到应用程序发出的元数据更新操作；

2.2）判定元数据更新操作的类型，若为创建新的目录或文件则跳转步骤2.3）；若为更新已有的目录或文件则跳转步骤2.4）；若为删除已有的目录或文件则跳转步骤2.5）；

2.3）生成文件/目录创建日志，跳转步骤2.6）；

2.4）生成目录/文件更新日志，跳转步骤2.6）；

2.5）生成目录/文件删除日志，跳转步骤2.6）；

2.6）将生成的日志追加到连续地址空间的尾部，跳转步骤2.7）；

2.7）将连续地址空间尾部持久化到存储设备上。

3.根据权利要求1或2所述的元数据管理方法，其特征在于，进行元数据检索的实施步骤包括：

S1）将文件系统中所有的目录和文件采用树形结构进行组织，且针对单个目录下的所有目录和子文件作为一个整体、按照创建的顺序依次保存在底层存储设备的连续地址空间上；

S2）进行文件系统元数据检索时，从目录路径的第一个分量依次逐层解析到最后一个分量，最终得到欲访问的目录或文件；且在一个父目录下解析一个子目录时，首先要读取该父目录对应的连续地址空间上的所有数据，然后在读取的数据上搜索目标子目录或子文件，直到匹配成功。

4.根据权利要求3所述的元数据管理方法，其特征在于，所述在读取的数据上搜索目标子目录或子文件时，具体是从连续地址空间的尾部向头部逆向处理，一旦检索到待查找的子目录/子文件，即可终止检索过程立即返回相应的元数据。

5.根据权利要求3所述的元数据管理方法，其特征在于，所述在一个父目录下解析一个子目录的详细步骤包括：

S2.1）收到应用程序发出的元数据检索请求，所述元数据检索请求为需要从一个父目录中检索目标目录或文件是否存在；

S2.2）通过一次读操作将父目录下所有子目录/子文件的相关信息获取到内存中，跳转步骤S2.3）；

S2.3）判定待解析的父目录大小，若父目录内子目录/子文件总数小于预设的第一阈值TH₁，跳转步骤S2.4）；若父目录内子目录/子文件总数在预设的第一阈值TH₁与预设的第二阈值TH₂之间，则跳转步骤S2.5）；若父目录内子目录/子文件总数大于预设的第二阈值TH₂时，跳转步骤S2.6）；

S2.4）采用多线程技术在父目录中检索目标子目录或子文件，跳转步骤S2.7）；

S2.5）采用向量指令在父目录中检索目标子目录或子文件，跳转步骤S2.7）；

S2.6）采用众核加速技术在父目录中检索目标子目录或子文件，跳转步骤S2.7）；

S2.7）若在父目录中查找到目标子目录或子文件则检索成功；否则检索失败，向上层应用返回检索结果。

6.根据权利要求5所述的元数据管理方法，其特征在于，步骤S2.4）、步骤S2.5）、步骤S2.6）三者中至少一个步骤中在父目录中检索目标子目录或子文件时采取从连续地址空间的尾部向头部逆向处理的方式实施搜索。

7.一种元数据管理方法，其特征在于，进行元数据检索的实施步骤包括：

S1）将文件系统中所有的目录和文件采用树形结构进行组织，且针对单个目录下的所有目录和子文件作为一个整体、按照创建的顺序依次保存在底层存储设备的连续地址空间上；

S2）进行文件系统元数据检索时，从目录路径的第一个分量依次逐层解析到最后一个分量，最终得到欲访问的目录或文件；且在一个父目录下解析一个子目录时，首先要读取该父目录对应的连续地址空间上的所有数据，然后在读取的数据上搜索目标子目录或子文件，直到匹配成功。

8.根据权利要求7所述的元数据管理方法，其特征在于，所述在一个父目录下解析一个子目录的详细步骤包括：

S2.1）收到应用程序发出的元数据检索请求，所述元数据检索请求为需要从一个父目录中检索目标目录或文件是否存在；

S2.2）通过一次读操作将父目录下所有子目录/子文件的相关信息获取到内存中，跳转步骤S2.3）；

S2.3）判定待解析的父目录大小，若父目录内子目录/子文件总数小于预设的第一阈值TH₁，跳转步骤S2.4）；若父目录内子目录/子文件总数在预设的第一阈值TH₁与预设的第二阈值TH₂之间，则跳转步骤S2.5）；若父目录内子目录/子文件总数大于预设的第二阈值TH₂时，跳转步骤S2.6）；

S2.4）采用多线程技术在父目录中检索目标子目录或子文件，跳转步骤S2.7）；

S2.5）采用向量指令在父目录中检索目标子目录或子文件，跳转步骤S2.7）；

S2.6）采用众核加速技术在父目录中检索目标子目录或子文件，跳转步骤S2.7）；

S2.7）若在父目录中查找到目标子目录或子文件则检索成功；否则检索失败，向上层应用返回检索结果。

9.一种元数据管理系统，包括计算机系统，其特征在于，该计算机系统被编程以执行权利要求1～8中任意一项所述元数据管理方法的步骤，或者该计算机系统的存储介质上存储有被编程以执行权利要求1～8中任意一项所述元数据管理方法的计算机程序。

10.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有被编程以执行权利要求1～8中任意一项所述元数据管理方法的计算机程序。