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

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

Info

Publication number
WO2020186549A1
WO2020186549A1 PCT/CN2019/080279 CN2019080279W WO2020186549A1 WO 2020186549 A1 WO2020186549 A1 WO 2020186549A1 CN 2019080279 W CN2019080279 W CN 2019080279W WO 2020186549 A1 WO2020186549 A1 WO 2020186549A1
Authority
WO
WIPO (PCT)
Prior art keywords
directory
metadata
sub
file
parent directory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2019/080279
Other languages
English (en)
French (fr)
Inventor
卢宇彤
陈志广
肖侬
刘芳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Yat Sen University
Original Assignee
Sun Yat Sen University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Yat Sen University filed Critical Sun Yat Sen University
Priority to US17/279,606 priority Critical patent/US11693830B2/en
Publication of WO2020186549A1 publication Critical patent/WO2020186549A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/13—File access structures, e.g. distributed indices
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/185—Hierarchical storage management [HSM] systems, e.g. file migration or policies thereof

Definitions

  • the invention relates to the field of metadata management of a file system for large-scale data storage, and in particular to a metadata management method, system and medium, which are used to accelerate the metadata access of the file system and improve the overall performance of the file system data access.
  • Metadata access is on the critical path of the IO process, and its performance determines the upper limit of the data access performance of the entire file system; more than half of the IO requests received by the storage device are generated by metadata access.
  • Optimizing metadata access will bring Huge benefits; applications often make a large number of irregular small requests for file system metadata. This IO feature brings huge challenges to metadata optimization.
  • the mainstream file systems have done a lot of fine optimization for metadata, and the related technologies can be summarized as the following aspects. In terms of macro organizational structure, some file systems adopt distributed metadata management methods to improve metadata access performance.
  • Metadata storage structure In terms of metadata storage structure, traditional file systems generally store metadata in the form of ordinary files on storage devices. When a directory contains a large number of subdirectories or files, a tree structure is used to perform operations on these subdirectories or files. index. This storage structure can support a large number of subdirectories or files stored in a single directory, but as the number of subdirectories or files continues to increase, the access performance will decrease significantly, mainly because accessing a subdirectory under a tree index structure may require From the root search to the leaf nodes, a large number of IO requests and calculation operations will be generated in this process. Correspondingly, some new file systems such as TableFS and IndexFS use NoSQL databases and Key-Value systems to store metadata. These data structures have good scalability and random access performance, and can improve metadata access performance to a certain extent.
  • Lustre distributes the entire file system namespace to multiple metadata servers in the form of static subtree division, but this does not solve the problem of a single directory containing a large number of files.
  • CephFS can distribute a large number of files in the same directory to multiple metadata servers according to the load situation. This optimization method can achieve concurrent access to a large number of files in the same directory, but it destroys the locality of file metadata. In short, there is still no good solution for the large catalog problem.
  • the so-called read-write amplification means that each metadata access issued by the upper application needs to be completed by multiple IO requests.
  • TableFS the KV storage engine open sourced by Google engineers Jeff Dean and Sanjay Ghemawat.
  • LevelDB the KV storage engine open sourced by Google engineers Jeff Dean and Sanjay Ghemawat.
  • SSTable Sorted String Table
  • This may cause the split operation of SStable, resulting in multiple write requests; conversely, when searching for a file in LevelDB, you may need to search multiple levels of LevelDB sequentially from top to bottom. This generates multiple read requests.
  • Multiple IO requests generated by a file system metadata access are generally interdependent and difficult to process concurrently, which fundamentally leads to difficulty in improving metadata access performance.
  • EXT4 uses HTree tree structure to index all subdirectories and files in the same directory, and the specifics of all subdirectories and files
  • the information is stored on the leaf nodes of the HTree, and the search starts from the root node of the HTree during the directory search.
  • the branch nodes of each level only need to obtain a small amount of data from the storage device and do a small amount of calculation.
  • the prerequisite assumed by the above optimization measures is that the performance of the processor and the storage device are relatively weak, which requires a step-by-step index to reduce data reading and processing and processing.
  • accelerators represented by GPUs can provide thousands of cores of concurrent computing capabilities, and new storage devices represented by solid state disks can provide bandwidths of the order of GB/s and throughput rates of the order of 100,000 IOPS.
  • Powerful computing and IO capabilities provide an opportunity for the innovative design of the file system. Specifically, the present invention redesigns the storage structure of file system metadata, abandons the tree index method, ensures that any metadata operation only triggers one IO request, thereby reducing the delay caused by data IO, and uses the CPU's multi-threading technology and vector processing Technology, GPU's many-core acceleration technology implements concurrent processing of data, and ultimately improves the overall access performance of file system metadata.
  • the technical problem to be solved by the present invention in view of the above-mentioned problems of the prior art, a metadata management method, system and medium are provided.
  • the present invention can effectively solve the problem of large catalogs.
  • the catalog path resolution has lower delay and can reduce metadata
  • the number of IO requests during the access process can accelerate the metadata access of the file system and improve the overall performance of the file system data access.
  • a metadata management method includes:
  • All directories and files in the file system are organized in a tree structure, and all directories and sub-files in a single directory are stored as a whole in the order of creation in the continuous address space of the underlying storage device;
  • step 2) include:
  • the file system receives the metadata update operation sent by the application
  • step 2.2 Determine the type of metadata update operation. If it is to create a new directory or file, skip to step 2.3); if it is to update an existing directory or file, skip to step 2.4); if it is to delete an existing directory or file Then skip to step 2.5);
  • implementation steps for metadata retrieval include:
  • the first component of the directory path is parsed layer by layer to the last component, and finally the directory or file to be accessed is obtained; and when parsing a sub-directory under a parent directory, first Read all data in the continuous address space corresponding to the parent directory, and then search the target subdirectory or subfile on the read data until the match is successful.
  • the process when searching for the target subdirectory or subfile on the read data, the process is specifically reversed from the tail to the head of the continuous address space. Once the subdirectory/subfile to be searched is retrieved, it can be terminated The retrieval process immediately returns the corresponding metadata.
  • the detailed steps of parsing a sub-directory under a parent directory include:
  • a metadata retrieval request sent by an application is received, and the metadata retrieval request is to retrieve whether the target directory or file exists from a parent directory;
  • Step S2.3 Determine the size of the parent directory to be parsed. If the total number of subdirectories/subfiles in the parent directory is less than the preset first threshold TH 1 , skip to step S2.4); if the total number of subdirectories/subfiles in the parent directory is within the preset Between the set first threshold TH 1 and the preset second threshold TH 2 , jump to step S2.5); if the total number of subdirectories/subfiles in the parent directory is greater than the preset second threshold TH 2 , jump Step S2.6);
  • step S2.6 Using many-core acceleration technology to retrieve the target subdirectory or subfile in the parent directory, skip to step S2.7);
  • the search is performed in reverse processing.
  • the present invention also provides a metadata management method.
  • the implementation steps of metadata retrieval include:
  • the first component of the directory path is parsed layer by layer to the last component, and finally the directory or file to be accessed is obtained; and when parsing a sub-directory under a parent directory, first Read all the data in the continuous address space, and then search the target subdirectory or subfile on the read data until the match is successful.
  • the detailed steps of parsing a sub-directory under a parent directory include:
  • a metadata retrieval request sent by an application is received, and the metadata retrieval request is to retrieve whether the target directory or file exists from a parent directory;
  • Step S2.3 Determine the size of the parent directory to be parsed. If the total number of subdirectories/subfiles in the parent directory is less than the preset first threshold TH 1 , skip to step S2.4); if the total number of subdirectories/subfiles in the parent directory is within the preset Between the set first threshold TH 1 and the preset second threshold TH 2 , jump to step S2.5); if the total number of subdirectories/subfiles in the parent directory is greater than the preset second threshold TH 2 , jump Step S2.6);
  • step S2.6 Using many-core acceleration technology to retrieve the target subdirectory or subfile in the parent directory, skip to step S2.7);
  • the present invention also provides a metadata management system, including a computer system that is programmed to execute the steps of the foregoing metadata management method of the present invention, or a storage medium of the computer system is programmed to execute the foregoing steps of the present invention.
  • a computer program describing metadata management methods including a computer system that is programmed to execute the steps of the foregoing metadata management method of the present invention, or a storage medium of the computer system is programmed to execute the foregoing steps of the present invention.
  • the present invention also provides a computer-readable storage medium on which is stored a computer program programmed to execute the aforementioned metadata management method of the present invention.
  • the present invention can effectively solve the problem of large directories, the directory path resolution has lower delay, can reduce the number of IO requests in the metadata access process, can accelerate the metadata access of the file system, and improve the file The overall performance of system data access.
  • the specific reasons are reflected in the following aspects:
  • the present invention aggregates the metadata of all sub-directories/sub-files under a parent directory and saves them on the continuous address space of the storage device to ensure that the metadata of these sub-directories/sub-files can be obtained from the storage device through a read operation. Therefore, When parsing a sub-directory under a parent directory, you only need to wait for one IO delay. In contrast, EXT4 indexes all subdirectories/subfiles under a parent directory in a two-level HTree. When parsing a directory, you need to search layer by layer in the HTree.
  • At least two IO operations are required, and the second layer search Corresponding IO operations must wait for the completion of the first-level search processing before being issued.
  • Two IO operations cannot be concurrent, which results in a greater delay in directory resolution.
  • Other file systems such as TableFS build complex indexes for all subdirectories/subfiles under the same parent directory, and there is a similar problem of excessively high directory resolution delay.
  • the present invention takes out all sub-directories/sub-files in a parent directory at the same time through one IO, which will cause larger IO operations, but because the current new storage devices such as solid state disks can provide very high bandwidth, one-time large IO operation does not cause a significant increase in IO latency.
  • the present invention can reduce IO operations caused by metadata update, thereby improving metadata update performance.
  • the present invention records all updates of metadata in the form of a log. When operations such as creation, update, and deletion of subdirectories/subfiles occur under a parent directory, new information is appended to the end of the continuous address space in the form of logs. When the updated information is persisted to the storage device, only a write operation needs to be initiated at the end of the continuous address space, and the write amplification effect will not be triggered.
  • EXT4 may cause the index structure to be updated when the metadata is updated
  • TableFS may cause the split of the SSTable in LevelDB when the metadata is updated. The above two situations will cause additional write operations.
  • FIG. 1 is a basic flowchart of metadata update in Embodiment 1 of the present invention.
  • Figure 2 is a file system metadata storage structure adopted in Embodiment 1 of the present invention.
  • FIG. 3 is a process of updating file system metadata in Embodiment 1 of the present invention.
  • Fig. 4 is a file system metadata retrieval process in the first embodiment of the present invention.
  • the key to the metadata management method lies in metadata update and metadata retrieval.
  • the key to the implementation of this embodiment lies in how to save the metadata of the directory/file on the storage device, and how to quickly retrieve a specific child from the parent directory. Directory/subfile.
  • the implementation steps of the metadata management method of this embodiment for metadata update include:
  • All directories and files in the file system are organized in a tree structure, and all directories and sub-files in a single directory are stored as a whole in the order of creation in the continuous address space of the underlying storage device;
  • the storage structure of file system metadata includes two aspects.
  • the first is the logical organization of all directories and files in the file system, that is, the name space of the file system. At present, most file systems use a tree structured name space; It is a storage structure of a large number of subdirectories/subfiles under a single directory.
  • the above two aspects are critical to the access performance of file system metadata.
  • the name space of the tree structure best conforms to the user's usage habits, this embodiment keeps this organization mode unchanged.
  • TableFS integrates all subdirectories/subfiles in a directory and stores them in a NoSQL database.
  • ETX4 uses HTree to index all subdirectories/subfiles in a directory into one In a two-level tree structure.
  • the common problem of the above methods is that each metadata operation will cause multiple IO requests, and these IO requests have certain dependencies, which are difficult to process concurrently, which fundamentally determines the low performance of file system metadata access.
  • An important idea of this embodiment is to ensure as far as possible that only one IO request is triggered for each metadata operation.
  • this embodiment saves all sub-directories/sub-files in a directory as a whole in the continuous address space of the underlying storage device, ensuring that one read request can obtain relevant information of all sub-directories/sub-files (similarly , One write request can save all sub-directory/sub-file related information to the storage device).
  • this embodiment does not create any index for all subdirectories/subfiles under a directory, nor does it perform Sort, just save all subdirectories/subfiles in sequential address space in the order of creation.
  • Figure 2 shows the metadata storage structure used in this embodiment.
  • the name space of the file system is organized into a tree structure, where directory e contains four subdirectories/subfiles i, j, n, and p.
  • the file system allocates a continuous address space for directory e, where i, j, n, and p are stored in this continuous address space in the order of creation/update.
  • step 2 As shown in Figure 3, the detailed steps of step 2) include:
  • the file system receives the metadata update operation sent by the application
  • step 2.2 Determine the type of metadata update operation. If it is to create a new directory or file, skip to step 2.3); if it is to update an existing directory or file, skip to step 2.4); if it is to delete an existing directory or file Then skip to step 2.5);
  • generating a file/directory creation log specifically refers to encapsulating the name, identification number and other information of the new file/directory into the log;
  • generating a directory/file update log specifically means that this operation is the same as file/directory creation, completely generating a new directory or file, the original directory or The file is still kept in the storage system. Due to the reverse retrieval method during metadata retrieval, the old version information of a directory or file will not be retrieved;
  • step 2.6 To generate a directory/file deletion log, go to step 2.6); in this embodiment, generating a directory/file deletion log specifically refers to copying the original information of the directory/file, but marking it as "already" on a special flag bit. delete";
  • Metadata updates include creation of new directories/files, changes to original directories/files, and deletion of original directories/files.
  • all sub-directories/sub-files under a parent directory are aggregated and stored in a continuous address space.
  • the following three update operations may occur: (1) New directory/file creation: When a new directory or file needs to be created, the relevant metadata information is directly appended to the end of the continuous address space.
  • (2) Existing directory/file update When an upper-level application initiates a file renaming request, it will cause an update operation for an existing directory/file. This embodiment adopts a log update method instead of directly updating the original directory/file.
  • this embodiment adopts the log update method, instead of directly deleting the original directory/file, a deletion log is generated and directly appended to the end of the continuous address space .
  • this embodiment uses a log format to implement update operations on all subdirectories/subfiles under a directory, and all metadata updates are appended to the end of the continuous address space corresponding to the directory in the order in which they occur.
  • the implementation steps for metadata retrieval include:
  • the first component of the directory path is parsed layer by layer to the last component, and finally the directory or file to be accessed is obtained; and when parsing a sub-directory under a parent directory, first Read all data in the continuous address space corresponding to the parent directory, and then search the target subdirectory or subfile on the read data until the match is successful.
  • the process when searching for the target sub-directory or sub-file on the read data, the process is specifically reversed from the tail to the head of the continuous address space. Once the sub-directory/sub-file to be found is retrieved, The corresponding metadata is returned immediately after the retrieval process is terminated.
  • special acceleration is implemented for the retrieval of active files/directories. The specific reasons are as follows: Generally speaking, recently created or updated files are hot files and are more likely to be Visit again. In this embodiment, all sub-directories/sub-files under a parent directory are stored in a continuous address space in the order of creation/update. When the directory is resolved, the reverse processing starts from the end of the continuous address space to the head. Or the updated files are closer to the end, and this reverse process causes them to be retrieved faster.
  • the optimization method can significantly reduce the retrieval delay of hot directories/files.
  • this embodiment still uses a tree-shaped directory structure, the overall process of directory path analysis is the same as that of a traditional file system: the first component of the directory path is parsed layer by layer to the last component, and finally the directory or directory to be accessed is obtained. file.
  • the difference between this embodiment and the traditional file system lies in: when parsing a specific component, how to obtain the metadata information corresponding to the component from the parent directory of the component, that is, the method of parsing a single directory. This problem largely depends on the storage structure adopted by all subdirectories/subfiles in a directory.
  • EXT4 uses HTree to index all sub-directories/sub-files under a parent directory, and the process of parsing a sub-directory under a parent directory is HTree search.
  • TableFS uses LevelDB to store all sub-directories/sub-files under a parent directory. The process of parsing a sub-directory under a parent directory is to read the corresponding Value for a Key in LevelDB.
  • the metadata of all sub-directories/sub-files under a parent directory are stored as a whole in a continuous address space. To resolve a sub-directory under a parent directory, first read all the data in the continuous address space, and then Search the target subdirectory or subfile on the read data.
  • this embodiment does not establish any index for all subdirectories/subfiles under the same parent directory, and the metadata corresponding to these subdirectories/subfiles are not sorted in the continuous address space, the search process is actually a linear search operation , You need to check all subdirectories/subfiles until the match is successful.
  • the detailed steps of parsing a sub-directory under a parent directory include:
  • a metadata retrieval request sent by an application is received, and the metadata retrieval request is to retrieve whether the target directory or file exists from a parent directory;
  • Step S2.3 Determine the size of the parent directory to be parsed. If the total number of subdirectories/subfiles in the parent directory is less than the preset first threshold TH 1 , skip to step S2.4); if the total number of subdirectories/subfiles in the parent directory is within the preset Between the set first threshold TH 1 and the preset second threshold TH 2 , jump to step S2.5); if the total number of subdirectories/subfiles in the parent directory is greater than the preset second threshold TH 2 , jump Step S2.6);
  • step S2.4 Using multi-threading technology to retrieve the target subdirectory or subfile in the parent directory, skip to step S2.7); because the target subdirectory or subfile as a whole is stored in the underlying storage device in the order of creation.
  • each thread can be allocated to process different address segments of the continuous address space to achieve acceleration.
  • the continuous address space can be traversed in a for loop for processing, and the use of vector instruction acceleration means passing Use vectors to instruct to reduce the number of iterations of the for loop, thereby achieving an acceleration effect.
  • step S2.6 Using many-core acceleration technology to retrieve the target subdirectory or subfile in the parent directory, skip to step S2.7);
  • each processor core can be allocated to process different address segments of the continuous address space to achieve acceleration.
  • this embodiment uses technologies such as multithreading, vector processing, and many-core acceleration to accelerate the catalog analysis process. Since this embodiment does not create any index for all subdirectories/subfiles under the same parent directory, when retrieving a file under a parent directory, it needs to match all subdirectories/subfiles under the parent directory. This linear search process The computational overhead is large.
  • the three technologies of multithreading, vector processing, and many-core acceleration are flexibly selected according to the size of the parent directory to accelerate the matching process, which can significantly shorten the calculation time.
  • this embodiment adopts the method of replacing IO with calculation to reduce the delay of catalog parsing. The key reason for this method to achieve good results is that it is difficult to concurrently perform IO operations in the catalog parsing process, and the calculation process can use current parallelism. The implementation of computing technology has accelerated significantly.
  • this embodiment proposes a fusion scheme that uses three technologies, namely multithreading, vector operation, and many-core acceleration, to implement parallel analysis of directories of different sizes. Specifically, this embodiment sets two thresholds TH 1 and TH 2 , both of which are integers and TH 1 ⁇ TH 2 . Suppose you need to retrieve the sub-directory/sub-file b from the parent directory a.
  • this embodiment uses log append to record all metadata update operations.
  • This measure makes all subdirectories/subfiles in a parent directory meet the following two characteristics in storage: (I) Recently created The sub-directory/sub-file of the parent directory is stored closer to the end in the continuous address space corresponding to the parent directory; (II) The latest updated sub-directory/sub-file is stored in the continuous address space corresponding to the parent directory closer to the end .
  • this embodiment proposes an accelerated optimization scheme: reverse processing from the tail to the head of the continuous address space during directory retrieval. Once the subdirectory/subfile to be searched is retrieved, the retrieval process can be terminated immediately Return the corresponding metadata. Step S2.4), Step S2.5), Step S2.6) When retrieving the target subdirectory or subfile in the parent directory, the search is performed by reverse processing from the tail to the head of the continuous address space.
  • the aforementioned accelerated optimization method may be used in at least one of the three steps of step S2.4), step S2.5), and step S2.6) as required.
  • This optimization measure has similar acceleration effects for the above two scenarios: 1. According to the principle of locality, the recently created file is easier to be accessed again by upper-level applications, and this embodiment saves the recently created file at the end of the continuous address space. Reverse processing from the tail to the head can retrieve the recently created file faster. 2. According to the principle of log update, the most recent update of a directory or file is always stored closer to the end of the log. Reverse processing from the tail to the head can ensure that the metadata version retrieved first is the latest update information. In a word, the optimization measure of reverse retrieval from the tail to the head proposed in this embodiment can speed up the metadata access of the active file.
  • this embodiment also provides a metadata management system, including a computer system, which is programmed to execute the steps of the metadata management method of this embodiment, or the storage medium of the computer system is programmed to execute The computer program of the aforementioned metadata management method in this embodiment.
  • This embodiment also provides a computer-readable storage medium on which is stored a computer program programmed to execute the aforementioned metadata management method of this embodiment.
  • This embodiment is basically the same as the first embodiment, and the main difference is: this embodiment is a subset of the first embodiment, this embodiment only includes the relevant content of the metadata update in the first embodiment, and provides the corresponding metadata. Data management system and computer readable media.
  • This embodiment is basically the same as the first embodiment, and the main difference is: this embodiment is a subset of the first embodiment, this embodiment only includes the relevant content of the metadata retrieval in the first embodiment, and provides the corresponding metadata. Data management system and computer readable media.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

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 1，跳转步骤S2.4)；若父目录内子目录/子文件总数在预设的第一阈值TH 1与预设的第二阈值TH 2之间，则跳转步骤S2.5)；若父目录内子目录/子文件总数大于预设的第二阈值TH 2时，跳转步骤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 1，跳转步骤S2.4)；若父目录内子目录/子文件总数在预设的第一阈值TH 1与预设的第二阈值TH 2之间，则跳转步骤S2.5)；若父目录内子目录/子文件总数大于预设的第二阈值TH 2时，跳转步骤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展示了本实施例采用的元数据存储结构。如图2右侧部分所示，文件系统的名字空间被组织成树形结构，其中，目录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 1，跳转步骤S2.4)；若父目录内子目录/子文件总数在预设的第一阈值TH 1与预设的第二阈值TH 2之间，则跳转步骤S2.5)；若父目录内子目录/子文件总数大于预设的第二阈值TH 2时，跳转步骤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 1和TH 2，两者均为整数且TH 1<TH 2。假设需要从父目录a中检索子目录/子文件b，当目录a下的子目录/子文件数小于TH 1时，说明b下的子目录/子文件数较少，可采用CPU的线程实施目录解析；当目录a下的子目录/子文件数在TH 1与TH 2之间时，说明b下的子目录/子文件数相对较多，可采用CPU的向量指令实施并行解析；当目录a下的子目录/子文件数大于TH 2时，说明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 1，跳转步骤S2.4)；若父目录内子目录/子文件总数在预设的第一阈值TH 1与预设的第二阈值TH 2之间，则跳转步骤S2.5)；若父目录内子目录/子文件总数大于预设的第二阈值TH 2时，跳转步骤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 1，跳转步骤S2.4)；若父目录内子目录/子文件总数在预设的第一阈值TH 1与预设的第二阈值TH 2之间，则跳转步骤S2.5)；若父目录内子目录/子文件总数大于预设的第二阈值TH 2时，跳转步骤S2.6)；
    S2.4)采用多线程技术在父目录中检索目标子目录或子文件，跳转步骤S2.7)；
    S2.5)采用向量指令在父目录中检索目标子目录或子文件，跳转步骤S2.7)；
    S2.6)采用众核加速技术在父目录中检索目标子目录或子文件，跳转步骤S2.7)；
    S2.7)若在父目录中查找到目标子目录或子文件则检索成功；否则检索失败，向上层应用返回检索结果。
  9. 一种元数据管理系统，包括计算机系统，其特征在于，该计算机系统被编程以执行权利要求1～8中任意一项所述元数据管理方法的步骤，或者该计算机系统的存储介质上存储有被编程以执行权利要求1～8中任意一项所述元数据管理方法的计算机程序。
  10. 一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有被编程以执行权利要求1～8中任意一项所述元数据管理方法的计算机程序。
PCT/CN2019/080279 2019-03-15 2019-03-29 一种元数据管理方法、系统及介质 Ceased WO2020186549A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/279,606 US11693830B2 (en) 2019-03-15 2019-03-29 Metadata management method, system and medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910198998.3 2019-03-15
CN201910198998.3A CN109933570B (zh) 2019-03-15 2019-03-15 一种元数据管理方法、系统及介质

Publications (1)

Publication Number Publication Date
WO2020186549A1 true WO2020186549A1 (zh) 2020-09-24

Family

ID=66987422

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/080279 Ceased WO2020186549A1 (zh) 2019-03-15 2019-03-29 一种元数据管理方法、系统及介质

Country Status (3)

Country Link
US (1) US11693830B2 (zh)
CN (1) CN109933570B (zh)
WO (1) WO2020186549A1 (zh)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110708355A (zh) * 2019-09-05 2020-01-17 北京浪潮数据技术有限公司 一种文件上传的方法、系统、设备及可读存储介质
CN110659257B (zh) * 2019-09-05 2022-04-22 北京浪潮数据技术有限公司 一种元数据对象修复方法、装置、设备及可读存储介质
CN112527757B (zh) * 2019-09-18 2022-11-15 无锡江南计算技术研究所 基于大规模芯片测试结果的快速检索方法
CN110928498B (zh) * 2019-11-15 2023-11-10 浙江大华技术股份有限公司 一种目录遍历的方法、装置、设备和存储介质
CN111352586B (zh) * 2020-02-23 2023-01-06 苏州浪潮智能科技有限公司 一种加速文件读写的目录聚合方法、装置、设备和介质
US12499085B2 (en) 2024-01-29 2025-12-16 Pure Storage, Inc. Home directory level storage management of a file system
US12585621B2 (en) 2024-01-29 2026-03-24 Pure Storage, Inc. Directory level storage management of a file system
CN111694847B (zh) * 2020-06-04 2023-07-18 贵州易鲸捷信息技术有限公司 一种特大lob数据高并发低延迟的更新访问方法
CN111858496B (zh) * 2020-07-27 2021-09-17 北京大道云行科技有限公司 一种元数据的检索方法、装置、存储介质和电子设备
CN114363355B (zh) * 2020-09-29 2025-09-12 华为云计算技术有限公司 数据同步的方法、存储网关、系统及计算机可读存储介质
CN114625713A (zh) * 2020-12-10 2022-06-14 华为技术有限公司 一种存储系统中元数据管理方法、装置及存储系统
CN112698976B (zh) * 2020-12-24 2023-12-22 北京浪潮数据技术有限公司 一种元数据修复方法、装置、设备及介质
CN114490514A (zh) * 2022-01-26 2022-05-13 清华大学 文件系统的元数据管理方法、装置、设备
CN114415971B (zh) * 2022-03-25 2022-09-23 阿里云计算有限公司 数据处理方法以及装置
CN114968926B (zh) * 2022-05-31 2025-06-10 济南浪潮数据技术有限公司 一种数据管理方法、装置、设备及存储介质
CN117493282A (zh) * 2022-07-25 2024-02-02 华为云计算技术有限公司 一种基于文件系统的元数据管理方法及其相关设备
CN115422137B (zh) * 2022-09-05 2026-01-16 北京星辰天合科技股份有限公司 文件创建方法、装置、电子设备及计算机可读存储介质
CN116383166A (zh) * 2022-09-09 2023-07-04 支付宝(杭州)信息技术有限公司 针对分布式文件系统的数据处理方法及装置
CN115563057A (zh) * 2022-09-26 2023-01-03 中电云数智科技有限公司 一种基于daos的文件系统元数据存储方法及设备
CN116467277B (zh) * 2023-03-17 2026-01-02 清华大学 元数据处理方法、装置、设备、存储介质及产品
CN116737113B (zh) * 2023-04-23 2024-01-02 中国科学院高能物理研究所 面向海量科学数据的元数据目录管理系统及方法
CN116737659B (zh) * 2023-06-12 2026-01-13 中山大学 文件系统的元数据管理方法、终端设备及计算机存储介质
CN117056245B (zh) * 2023-08-18 2024-02-23 武汉麓谷科技有限公司 一种基于zns固态硬盘的面向日志记录应用的数据组织方法
CN117171109B (zh) * 2023-08-31 2026-01-09 阿维塔科技(重庆)有限公司 数据存储管理方法、装置、系统及存储介质
CN116955219B (zh) * 2023-09-13 2024-01-19 新华三信息技术有限公司 一种数据镜像方法、装置、主机及存储介质
CN117453682B (zh) * 2023-09-26 2024-07-09 广州海量数据库技术有限公司 在openGauss数据库上并行创建列存表btree索引的方法和系统
CN117235313B (zh) * 2023-11-09 2024-02-13 苏州元脑智能科技有限公司 一种存储目录统计方法、装置及电子设备和存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102024020A (zh) * 2010-11-04 2011-04-20 曙光信息产业(北京)有限公司 一种分布式文件系统中高效的元数据访存方法
CN106170012A (zh) * 2016-06-29 2016-11-30 上海上大海润信息系统有限公司 一种面向云渲染的分布式文件系统及构建和访问方法
CN106649601A (zh) * 2016-11-24 2017-05-10 郑州云海信息技术有限公司 一种文件系统数据处理方法、客户端、服务端及系统
CN107239569A (zh) * 2017-06-27 2017-10-10 郑州云海信息技术有限公司 一种分布式文件系统子树存储方法及装置

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100392382B1 (ko) * 2001-07-27 2003-07-23 한국전자통신연구원 동적 크기 변경 및 메타 데이터 양의 최소화를 위한 논리볼륨 관리 방법
US8612404B2 (en) * 2002-07-30 2013-12-17 Stored Iq, Inc. Harvesting file system metsdata
US7107385B2 (en) * 2002-08-09 2006-09-12 Network Appliance, Inc. Storage virtualization by layering virtual disk objects on a file system
US7401104B2 (en) * 2003-08-21 2008-07-15 Microsoft Corporation Systems and methods for synchronizing computer systems through an intermediary file system share or device
US7908562B2 (en) * 2003-10-23 2011-03-15 Microsoft Corporation System and a method for presenting items to a user with a contextual presentation
US7930508B2 (en) * 2006-03-07 2011-04-19 Apple Inc. File systems for data processing systems
US8402071B2 (en) * 2009-06-19 2013-03-19 Aptare, Inc. Catalog that stores file system metadata in an optimized manner
US10509776B2 (en) * 2012-09-24 2019-12-17 Sandisk Technologies Llc Time sequence data management
KR102050725B1 (ko) * 2012-09-28 2019-12-02 삼성전자 주식회사 컴퓨팅 시스템 및 컴퓨팅 시스템의 데이터 관리 방법
KR102127116B1 (ko) * 2014-03-12 2020-06-26 삼성전자 주식회사 분산 데이터 저장 장치 및 분산 데이터 저장 방법
CN105786724B (zh) * 2014-12-24 2018-12-25 华为技术有限公司 空间管理方法及装置
CN104537050B (zh) * 2014-12-25 2017-12-15 华中科技大学 一种批量快速创建文件系统元数据和数据的方法
CN104933133B (zh) * 2015-06-12 2018-09-07 中国科学院计算技术研究所 分布式文件系统中的元数据快照存储和访问方法
CN106293511B (zh) * 2016-07-26 2018-12-04 北京理工大学 一种面向连续数据存储的动态局部并行数据布局方法
CN106547703B (zh) * 2016-10-08 2019-05-14 华中科技大学 一种基于块组结构的ftl优化方法
CN106708442B (zh) * 2016-12-30 2020-02-14 硬石科技(武汉)有限公司 同时适应磁盘与固态硬盘读写特性的海量数据存储方法
CN107066505A (zh) * 2017-01-10 2017-08-18 郑州云海信息技术有限公司 一种性能优化的小文件存储访问的系统及方法
CN107862064B (zh) * 2017-11-16 2021-09-10 北京航空航天大学 一个基于nvm的高性能、可扩展的轻量级文件系统
CN109213699B (zh) * 2018-09-21 2021-10-29 郑州云海信息技术有限公司 一种元数据管理方法、系统、设备及计算机可读存储介质
CN109359062A (zh) * 2018-11-02 2019-02-19 郑州云海信息技术有限公司 一种元数据读缓存方法、装置及设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102024020A (zh) * 2010-11-04 2011-04-20 曙光信息产业(北京)有限公司 一种分布式文件系统中高效的元数据访存方法
CN106170012A (zh) * 2016-06-29 2016-11-30 上海上大海润信息系统有限公司 一种面向云渲染的分布式文件系统及构建和访问方法
CN106649601A (zh) * 2016-11-24 2017-05-10 郑州云海信息技术有限公司 一种文件系统数据处理方法、客户端、服务端及系统
CN107239569A (zh) * 2017-06-27 2017-10-10 郑州云海信息技术有限公司 一种分布式文件系统子树存储方法及装置

Also Published As

Publication number Publication date
CN109933570B (zh) 2020-02-07
US11693830B2 (en) 2023-07-04
CN109933570A (zh) 2019-06-25
US20220027326A1 (en) 2022-01-27

Similar Documents

Publication Publication Date Title
CN109933570B (zh) 一种元数据管理方法、系统及介质
CN109213772B (zh) 数据存储方法及NVMe存储系统
US10754878B2 (en) Distributed consistent database implementation within an object store
US9665304B2 (en) Storage system with fast snapshot tree search
CN100483420C (zh) 基于快照的细粒度文件与目录版本管理方法
CN113094336B (zh) 基于Cuckoo哈希的文件系统目录管理方法及系统
Yue et al. Building an efficient put-intensive key-value store with skip-tree
Bernstein et al. Optimizing optimistic concurrency control for tree-structured, log-structured databases
CN111522791B (zh) 一种分布式文件重复数据删除系统及方法
CN103595797B (zh) 一种分布式存储系统中的缓存方法
CN103942301B (zh) 一种面向多数据类型访问应用的分布式文件系统
CN113535670B (zh) 一种虚拟化资源镜像存储系统及其实现方法
US20170147225A1 (en) Unified table delta dictionary memory size and load time optimization
CN114416742A (zh) Key-Value存储引擎实现方法及系统
CN117120998A (zh) 用于读取树数据结构中保存的数据的方法和装置
WO2013139379A1 (en) Replicated data storage system and methods
CN116226497A (zh) 检索方法、介质、装置和计算设备
Jiao et al. BetrFS: A compleat file system for commodity SSDs
CN110032543A (zh) 一种存储文件系统的管理方法
US11586353B2 (en) Optimized access to high-speed storage device
WO2024254899A1 (zh) 文件系统的元数据管理方法、终端设备及计算机存储介质
Carter et al. Nanosecond indexing of graph data with hash maps and VLists
US12014070B2 (en) Method, device, and computer program product for storage management
Cai et al. The Embedded IoT Time Series Database for Hybrid Solid‐State Storage System
Saloustros et al. Rethinking HBase: design and implementation of an elastic key-value store over log-structured local volumes

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19920120

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19920120

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 19920120

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 070322)

122 Ep: pct application non-entry in european phase

Ref document number: 19920120

Country of ref document: EP

Kind code of ref document: A1