Implementation method and system of compatible file hard link and s3 shallow copy based on distributed key-value pair

Abstract

An implementation method and system compatible with file hard link and S3 shallow copy based on distributed key-value pairs, taking file metadata key-value pairs as the metadata storage body of files or directories, the key of which is composed of file system ID, parent directory ID and file or directory name, and the value contains metadata information; a reverse index file handle key-value pair is introduced as a unique invariant identifier, the key of which is composed of file system ID, initial parent directory ID, initial file or directory name N characters and file ID, and the value contains current file metadata key and reference count. When creating and deleting files or directories, they are probably in the same key-value pair node with high probability, supporting one-phase commit to improve performance; at the same time, hard link and S3 shallow copy are implemented, both of which create independent file metadata key-value pairs and reverse index file handle key-value pairs, the file metadata value of which records the reverse index file handle key of the target file, and updates the reference count of the reverse index file handle value of the target file, taking into account performance and compatibility.

Description

TECHNICAL FIELD

[0001] The present application relates to a distributed key-value pair storage technology, in particular to an implementation method of compatible file hard link and S3 shallow copy based on distributed key-value pair. BACKGROUND

[0002] A distributed key-value pair storage system is a distributed database with a key-value pair as the core data model. By dispersing data according to a specific strategy (such as consistent hashing and range sharding) and storing it on multiple nodes, it achieves horizontal expansion, high availability, and fault tolerance. Its architecture usually includes data partitioning (Partition / Shard), replication (Replica), and inter-node communication mechanisms, supporting strong consistency (such as Raft / Paxos protocol) or eventual consistency (such as Dynamo model) data synchronization methods, and relying on caching, batch writing, and other optimization techniques to improve performance. Typical systems such as Redis Cluster, Cassandra, and TiKV are widely used in cache acceleration, metadata management, and real-time analysis scenarios, providing flexible trade-offs between scalability, latency, and data consistency.

[0003] In a distributed key-value pair storage system, the performance difference between one-phase commit (such as Best Efforts 1PC) and two-phase commit (2PC) is mainly reflected in the trade-off between transaction execution efficiency, resource occupation, and consistency guarantee:

[0004] One-phase commit simplifies the process (directly sends a commit request and relies on local transaction logs to complete operations), significantly shortening transaction execution time, reducing inter-node communication overhead, and thus improving system throughput, especially suitable for low-latency, high-concurrency scenarios (such as cache updates or log appends). However, one-phase commit can only be used when all keys of the commit task are in the same key-value pair node, otherwise there will be data inconsistency.

[0005] When all keys of the commit task are distributed to different key-value pair nodes, in order to ensure data consistency, two-phase commit must be used. Two-phase commit ensures strong consistency by introducing a strict coordination of "preparation phase" and "commit phase", ensuring that all participants either all successfully commit or all roll back, thus ensuring strong consistency. However, this process requires multiple inter-node communications (such as preparation requests, responses, and final commit instructions), and participants need to lock resources during the preparation phase until the transaction is completed, causing synchronization blocking problems and reducing system performance.

[0006] File system is an abstract data structure in operating system for organizing, storing and managing files and directories. Its core mechanism is to map file metadata and logical path through inode and dirent. Inode is the unique identifier of a file, which stores file attributes (such as permission, size, timestamp) and data block pointers, but does not contain file or directory name. Dirent, as an entry in directory file, records the association between file or directory name and corresponding inode number, thus constructing a directory tree structure. When a user accesses a file through path name, the system finds the target inode by parsing the directory entries in each directory, and finally locates the file data block, realizing efficient storage and retrieval.

[0007] Distributed file system based on distributed key-value pair is a storage architecture that combines distributed key-value storage and file management functions. Its core idea is to use distributed key-value pair storage engine as the underlying storage backend, and through unified metadata management and data sharding mechanism, file data is stored in the form of key-value pair on multiple nodes, while providing traditional file system access interface (such as directory tree operation, file read-write, etc.) to the upper layer. This system usually contains three key components: metadata service (Meta data Service) is responsible for maintaining file namespace, permission and the mapping relationship between data block and key-value pair key; data sharding service divides files into fixed or variable size data blocks, and distributes key-value pairs to different nodes through hash or range sharding strategy; key-value pair storage engine (such as RocksDB, Cassandra) provides efficient key-value storage and retrieval capabilities, supports data persistence, replica replication and fault tolerance processing. Its advantage is that it combines the high scalability and low latency characteristics of distributed key-value pair storage, and the logical transparency of file system. Users do not need to be aware of the physical location of data to access distributed storage resources like operating local files, which is suitable for big data processing, cloud storage and virtualization environment scenarios.

[0008] AWS S3 shallow copy refers to copying only the metadata and basic attributes of an object when creating a new object through APIs such as CopyObject, without copying the data blocks of the object itself. The new object shares the same data content as the original object at the storage layer, and is distinguished only by different keys or version identifiers (VersionID). Under this mechanism, if a user accesses the copied object through a new key, S3 will directly return the data of the original object, so modifying the data content of the original object will synchronously affect all shallow copy objects, but modifying the metadata (such as ACL permissions, storage type, etc.) will not interfere with each other. Shallow copy is suitable for scenarios that require quick object reference creation or template metadata (such as uniformly setting encryption properties for multiple objects), but data consistency requirements need to be handled carefully to avoid accidental overwriting due to shared data. If a completely independent data copy is required, it needs to be achieved by downloading and re-uploading (i.e. deep copy).

[0009] A typical prior art solution implements a distributed file system by organizing dirent key-value pairs (dirent KV) and inode key-value pairs (inode KV) into a distributed key-value pair, and further supports hard link (hardlink) function. For example, Baidu's CFS (creating a large-scale distributed file system with a capacity of hundreds of billions of files) is an example of consistency optimization improvement based on traditional layout. The traditional file layout is shown in Figure 1 , and the main flowchart is shown in Figure 2 . The directory entry of a file or directory is recorded in the dirent key-value pair, and the dirent key is composed of the file system ID, the inode number (INO) of the parent directory, and the file (or directory) name. The dirent value stores the INO of the corresponding file or directory. The inode of the file or directory is recorded in the inode key-value pair, and the inode key is the INO of the file or directory. The inode value includes file layout, attributes, extended attributes, and other metadata information. When creating a file or directory, the contents of the dirent key-value pair and the inode key-value pair are prepared synchronously and submitted to the distributed key-value pair. When searching for a file or directory, the inode number of the file (or directory) is first found through the inode number of the parent directory and the file (or directory) name, and then the metadata information is obtained through the inode number to operate the file or directory. When creating a hard link, only the dirent key-value pair needs to be created (its key is still composed of the inode number of the parent directory and the file (or directory) name, and the value stores the inode number of the target inode), and the reference count of the target inode is incremented by 1. When deleting a file, if the inode reference count is reduced by 1 and is not 0, only the dirent key-value pair is deleted. Otherwise, the dirent key-value pair and the inode key-value pair are deleted, and no special handling is required for hard links. When renaming, only the dirent key needs to be changed, and the others remain unchanged. Hard links also do not need to be handled.

[0010] In the prior art, the hard link is implemented simply and intuitively, and the renaming operation is also simple and only needs to modify the directory entry key; however, there are obvious deficiencies: when a file or a directory is created or deleted, the directory entry key value pair and the index node key value pair are likely to fall on different key value pair storage nodes, and need to rely on the two-phase commit or the two-time one-phase commit with poor performance, resulting in poor performance of creation and deletion; when a file or a directory is queried, the directory entry key value pair needs to be queried first and then the index node key value pair is queried, and the two-time query results in poor performance; when a child file or a child directory under a directory is traversed, the directory entry key value pair needs to be obtained in the directory entry table first, and then the metadata information of the child file or the directory is obtained according to the index node number, and the performance is poor; and the scheme is difficult to be compatible with the AWS S3 shallow copy.

[0011] It should be noted that the information disclosed in the above background section is only for understanding the background of the present application, and therefore can include information that does not constitute prior art known to those of ordinary skill in the art. SUMMARY

[0012] The main purpose of the present application is to overcome the defects in the background art, and to provide an implementation method of compatible file hard link and S3 shallow copy based on distributed key value pair, which significantly improves the performance of core metadata operation while realizing the compatibility and support of hard link and S3 shallow copy protocol.

[0013] To achieve the above purpose, the present application adopts the following technical scheme:

[0014] In the first aspect of the present application, an implementation method of compatible file hard link and S3 shallow copy based on distributed key value pair, comprising:

[0015] In the distributed key value pair storage system, file metadata (meta) key value pair (KV) is used as the metadata storage main body of the file or the directory, wherein the file metadata key is composed of file system ID, parent directory ID and file or directory name, and the file metadata value contains the metadata information of the file or the directory;

[0016] A reverse index file handle (FH) is introduced as the unique and unchangeable identifier of the file or the directory, wherein the reverse index file handle key is composed of file system ID, initial parent directory ID, initial file or directory name N characters and file ID, and the reverse index file handle value contains the current file metadata key and the reference count;

[0017] Based on the layout of the file metadata key value pair and the reverse index file handle key value pair, the metadata operation is optimized, so that when a file or a directory is created or deleted, the file metadata key and the reverse index file handle key are likely to be located in the same key value pair node due to the same prefix, and one-phase commit is supported to improve the performance;

[0018] Based on the metadata layout, file hard link and S3 shallow copy are implemented, wherein the file hard link and S3 shallow copy both create independent file metadata key-value pairs and reverse index file handle key-value pairs, the file metadata value of which records the reverse index file handle key of the target file, and the reference count in the target reverse index file handle value is updated.

[0019] In a second aspect of the present application, a system compatible with file hard link and S3 shallow copy based on distributed key-value pairs includes a metadata server cooperating with a distributed file system client and a distributed key-value pair storage system.

[0020] The metadata server is configured to:

[0021] File metadata key-value pairs and reverse index file handle key-value pairs are maintained in the distributed key-value pair storage system, wherein the file metadata key is composed of a file system ID, a parent directory ID and a file or directory name, and the file metadata value contains metadata information of the file or directory; the reverse index file handle key is composed of a file system ID, an initial parent directory ID, an initial file or directory name N characters and a file ID, and the reverse index file handle value contains the current file metadata key and the reference count.

[0022] In response to a file operation request of the distributed file system client, metadata operation is performed by using the layout of the file metadata key-value pairs and the reverse index file handle key-value pairs, so that when a file or directory is created and deleted, the file metadata key and the reverse index file handle key are located in the same key-value pair node with a high probability due to the same prefix, and one-phase commit is adopted.

[0023] Based on the metadata layout, file hard link and S3 shallow copy are implemented in response to a client request, by creating independent file metadata key-value pairs and reverse index file handle key-value pairs, the file metadata value of which records the reverse index file handle key of the target file, and the reference count in the target reverse index file handle value is updated.

[0024] The present application has the following beneficial effects:

[0025] The present application provides an implementation method compatible with file hard link and S3 shallow copy based on distributed key-value pairs, and proposes an implementation scheme compatible with file hard link and S3 shallow copy based on distributed key-value pairs. By optimizing the file metadata layout and introducing the reverse index technical means, the core problem existing in the existing distributed file system scheme based on distributed key-value pairs is effectively solved, that is, not only the operation performance of creating, deleting, querying and directory traversal is poor, but also the S3 shallow copy function cannot be supported.

[0026] Compared with the traditional scheme, the present application has the following advantages:

[0027] a. When creating or deleting a file (or directory), in a distributed key-value pair storage system, the two related keys can be completed by one-phase commit operation with high probability, without relying on the two-phase commit (2PC) with large performance loss, effectively improving the efficiency of file (or directory) creation and deletion.

[0028] b. When looking for a file (or directory), the parent directory ID and the file or directory name can be used to directly locate the metadata; compared with the two-stage query method of "first querying the directory entry to obtain the inode number, and then querying the inode according to the inode number" in the traditional scheme, the efficiency is significantly improved.

[0029] c. When traversing the sub-file (or sub-directory) under the directory, only the distributed key-value pair system needs to be scanned to obtain the matching key-value pair containing inode information, so that the directory entry and inode related data can be obtained synchronously, without obtaining inode information according to the inode number one by one, greatly improving the directory traversal efficiency.

[0030] d. The present application can not only support hard link function, but also be compatible with S3 shallow copy mechanism, providing convenience for compatibility with S3 protocol, and expanding the applicability of the system in cloud storage scenarios.

[0031] Other beneficial effects in the embodiments of the present application will be further described below. BRIEF DESCRIPTION OF DRAWINGS

[0032] Figure 1 is a file layout diagram of a traditional distributed file system.

[0033] Figure 2 is a main operation flow diagram of a traditional distributed file system.

[0034] Figure 3 is a distributed file system architecture diagram based on a distributed key-value pair of an embodiment of the present application.

[0035] Figure 4 is a metadata layout diagram of a distributed file system of an embodiment of the present application.

[0036] Figure 5 is a directory structure diagram corresponding to a metadata layout example of an embodiment of the present application.

[0037] Figure 6 is a distributed key-value pair layout table of a metadata layout example of an embodiment of the present application.

[0038] Figure 7 is a file metadata key composition structure diagram of an embodiment of the present application.

[0039] Figure 8is a schematic diagram of a reverse index file handle key composition structure of an embodiment of the present application.

[0040] Figure 9 is a distributed key-value pair key-value pair change diagram after file renaming of an embodiment of the present application.

[0041] Figure 10 is a metadata basic operation flowchart of an embodiment of the present application.

[0042] Figure 11 is a hard link operation flowchart of an embodiment of the present application.

[0043] Figure 12 is an S3 shallow copy operation flowchart of an embodiment of the present application.

[0044] Figure 13 is a file ID-reverse index file handle key memory mapping table when interfacing with FUSE of an embodiment of the present application. DETAILED DESCRIPTION

[0045] The embodiments of the present application are described in detail below. It should be emphasized that the following description is only exemplary and is not intended to limit the scope of the present application and its applications.

[0046] In addition, the terms "first", "second" are only for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Therefore, the features defined with "first", "second" can explicitly or implicitly include one or more of the features. In the description of the embodiments of the present application, the meaning of "multiple" is two or more, unless otherwise specifically limited.

[0047] The present application aims to solve the problem of poor performance of operations such as creation, deletion, query and directory traversal in existing distributed file systems based on distributed key-value pairs, and the inability to support S3 shallow copy. A technical solution is proposed by optimizing file metadata layout (integrating directory items and index node metadata using file metadata key-value pairs) and introducing reverse index file handles (as unique and unchanging identifiers for files or directories). This solution can improve efficiency and simplify query and traversal processes by allowing one-phase commit for creation / deletion operations with high probability, and can also support hard links and S3 shallow copy simultaneously, facilitating compatibility with S3 protocols.

[0048] Referring to Figure 1 , the embodiment of the present application provides an implementation method for compatible file hard link and S3 shallow copy based on distributed key-value pairs, comprising:

[0049] In a distributed key-value pair storage system, a file metadata key-value pair is used as a file or directory metadata storage subject, wherein the file metadata key is composed of a file system ID, a parent directory ID and a file or directory name, and the file metadata value contains metadata information of the file or directory;

[0050] A reverse index file handle is introduced as a unique and unchangeable identifier of a file or directory, wherein the reverse index file handle key is composed of a file system ID, an initial parent directory ID, an initial file or directory name N characters and a file ID, and the reverse index file handle value contains a current file metadata key and a reference count; it can be understood that N can be selected by a suitable fixed value or dynamically determined according to the length distribution of the file name, the conflict probability and other requirements in the actual application scenario;

[0051] Based on the layout of the file metadata key-value pair and the reverse index file handle key-value pair, the metadata operation is optimized, so that when a file or directory is created or deleted, the file metadata key and the reverse index file handle key are located in the same key-value pair node with a high probability due to the same prefix, and one-stage submission is supported to improve the performance;

[0052] Based on the metadata layout, file hard link and S3 shallow copy are implemented, wherein the hard link and the S3 shallow copy both create independent file metadata key-value pairs and reverse index file handle key-value pairs, the file metadata value of which records the reverse index file handle key of the target file, and the reference count in the target reverse index file handle value is updated.

[0053] In some embodiments, the file metadata value includes file layout, attributes, extended attributes and reverse index file handle key; the initial parent directory ID and the initial file or directory name in the reverse index file handle key are the parent directory ID and the file or directory name at the time of file or directory creation, and the rename operation does not change the reverse index file handle key, but updates the file metadata key recorded in the reverse index file handle value; when interfacing with FUSE, a mapping table of file ID and reverse index file handle key is maintained in memory, and the file ID is used as a simulated inode number; when interfacing with NFS, the reverse index file handle key is directly used as the reverse index file handle.

[0054] In some embodiments, implementing file hard link includes: when creating a hard link, obtaining its file metadata key-value pair according to the parent directory ID and file or directory name of the link target, and resolving the reverse index file handle key of the target file therefrom; obtaining its reverse index file handle key-value pair according to the reverse index file handle key of the target file, and adding 1 to the reference count in the reverse index file handle value thereof; creating the file metadata key-value pair and reverse index file handle key-value pair of the hard link itself, wherein the file metadata value of the hard link records the reverse index file handle key of the target file and sets a hard link identification; when finding or traversing to the hard link, finding the file metadata key of the target file through the target reverse index file handle key recorded in the file metadata value thereof, and then obtaining the metadata of the target file; when performing an operation other than deletion and renaming on the hard link, redirecting all operations to the target file for execution; when deleting the hard link, finding the target reverse index file handle key-value pair according to the target reverse index file handle key in the file metadata value thereof, and reducing 1 from the reference count in the target reverse index file handle value; if the result is 0, further deleting the file metadata key-value pair and reverse index file handle key-value pair of the target file; regardless of whether the target is deleted, ultimately deleting the file metadata key-value pair and reverse index file handle key-value pair of the hard link itself.

[0055] In some embodiments, implementing S3 shallow copy includes: when creating an S3 shallow copy, obtaining its file metadata key-value pair according to the parent directory ID and file or directory name of the copy target, and resolving the reverse index file handle key of the target file therefrom; obtaining its reverse index file handle key-value pair according to the reverse index file handle key of the target file, and adding 1 to the reference count in the reverse index file handle value thereof; creating the file metadata key-value pair and reverse index file handle key-value pair of the S3 shallow copy itself, wherein the file metadata value of the S3 shallow copy records the reverse index file handle key of the target file and sets an S3 shallow copy identification; when finding or traversing to the S3 shallow copy, finding the file metadata key of the target file through the target reverse index file handle key recorded in the file metadata value thereof, and then obtaining the metadata of the target file; when performing a data read-write operation on the S3 shallow copy, redirecting the operation to the target file for execution; when performing a metadata operation on the S3 shallow copy, performing it on its own file metadata key-value pair; when deleting the S3 shallow copy, finding the target reverse index file handle key-value pair according to the target reverse index file handle key in the file metadata value thereof, and reducing 1 from the reference count in the target reverse index file handle value; if the result is 0, further deleting the file metadata key-value pair and reverse index file handle key-value pair of the target file; regardless of whether the target is deleted, ultimately deleting the file metadata key-value pair and reverse index file handle key-value pair of the S3 shallow copy itself.

[0056] In some embodiments, in the metadata operation based on the file metadata key-value pairs and the reverse index file handle key-value pairs, the process of creating a file or a directory comprises: allocating a file ID with a unique identity for the file or the directory to be created; organizing its file metadata key-value pairs, the key of which consists of the file system ID, the parent directory ID and the file or directory name, and the value of which contains the metadata information of the file and its reverse index file handle key; organizing its reverse index file handle key-value pairs, the key of which consists of the file system ID, the initial parent directory ID, the first N characters of the initial file or directory name and the file ID, and the value of which contains the corresponding current file metadata key and the initial reference count; submitting the file metadata key-value pairs and the reverse index file handle key-value pairs to the distributed key-value pair storage system.

[0057] In some embodiments, in the metadata operation based on the file metadata key-value pairs and the reverse index file handle key-value pairs, the process of querying a file or a directory comprises: composing its file metadata key according to the parent directory ID and the file or directory name of the file or the directory to be queried; querying in the distributed key-value pair storage system using the file metadata key to directly obtain the corresponding file metadata value; parsing the metadata information of the file from the obtained file metadata value.

[0058] In some embodiments, in the metadata operation based on the file metadata key-value pairs and the reverse index file handle key-value pairs, the process of traversing the child files or directories under a directory comprises: composing a prefix key according to the ID of the directory to be traversed; performing a range scan in the distributed key-value pair storage system using the prefix key to obtain all matched file metadata key-value pairs; parsing each obtained file metadata value to directly obtain the complete metadata information of the child files or directories.

[0059] In some embodiments, in the metadata operation based on the file metadata key-value pairs and the reverse index file handle key-value pairs, the process of deleting a file or a directory comprises: composing its file metadata key according to the parent directory ID and the file or directory name of the file or the directory to be deleted; obtaining its file metadata value according to the file metadata key and parsing the reverse index file handle key therefrom; obtaining the reverse index file handle key-value pair according to the reverse index file handle key and reducing the reference count in its reverse index file handle value by 1; judging whether the reference count after reduction by 1 is 0: if yes, deleting the file metadata key-value pair and the reverse index file handle key-value pair of the file or the directory; if not, moving the file or the directory to the link reservation directory inside the system.

[0060] In some embodiments, in the metadata operation based on the file metadata key-value pair and the reverse index file handle key-value pair, the process of renaming a file or a directory includes: composing a current file metadata key of the file or the directory according to a current parent directory ID and a current file or directory name of the file or the directory; obtaining a file metadata value and a reverse index file handle key of the file or the directory according to the current file metadata key; generating a new file metadata key according to a new parent directory ID and a new file or directory name of the file or the directory; creating a new file metadata key-value pair, the key of which is the new file metadata key, and the value content of which is the same as the old file metadata value; obtaining a reverse index file handle key-value pair according to the reverse index file handle key, updating the file metadata key recorded in the reverse index file handle value to the new file metadata key, and deleting the old file metadata key-value pair.

[0061] The embodiment of the present application also provides a system compatible with file hard link and S3 shallow copy based on distributed key-value pairs, comprising a metadata server, which cooperates with a distributed file system client and a distributed key-value pair storage system; the metadata server is configured to:

[0062] maintain a file metadata key-value pair and a reverse index file handle key-value pair in the distributed key-value pair storage system, wherein the file metadata key is composed of a file system ID, a parent directory ID and a file or directory name, and the file metadata value contains metadata information of the file or the directory; the reverse index file handle key is composed of a file system ID, an initial parent directory ID, an initial file or directory name N characters and a file ID, and the reverse index file handle value contains a current file metadata key and a reference count;

[0063] in response to a file operation request of the distributed file system client, performing a metadata operation by using the layout of the file metadata key-value pair and the reverse index file handle key-value pair, so that when a file or a directory is created or deleted, the file metadata key and the reverse index file handle key are located in the same key-value pair node with a high probability due to the same prefix, and one-phase commit is supported;

[0064] based on the metadata layout, realizing file hard link and S3 shallow copy in response to a client request, by creating independent file metadata key-value pairs and reverse index file handle key-value pairs, the file metadata value of which records the reverse index file handle key of a target file, and updating the reference count in the target reverse index file handle value.

[0065] According to some embodiments of the present application, the present application realizes a file metadata layout scheme based on distributed key-value pairs, and the implementation is as follows:

[0066] The metadata information of a file (or a directory) is stored in a file metadata key-value pair, wherein the file metadata key is composed of a file system ID, a parent directory ID and a file (or directory) name, and the file metadata value stores the metadata information of the file (or directory), which includes file layout, attributes, extended attributes and reverse index file handle key, etc.

[0067] The reverse index file handle is introduced as the unique and unchangeable identifier of a file, wherein the reverse index file handle key is composed of a file system ID, an initial parent directory ID, the first N characters of an initial file (or directory) name and a file ID; the reverse index file handle value is composed of a file metadata key and a reference count, and the reverse index file handle key-value pair is persisted in a distributed key-value pair storage system. The initial parent directory ID specifically refers to the parent directory ID corresponding to the file (or directory) when it is created, and the initial file (or directory) name specifically refers to the file (or directory) name corresponding to the file (or directory) when it is created.

[0068] When a rename operation is performed on a file (or directory), the file metadata key of the file (or directory) is updated to a new file metadata key, but the content of the file metadata value remains unchanged; the reverse index file handle key remains unchanged, but the file metadata key recorded in the reverse index file handle value is updated to the new file metadata key synchronously. The file metadata key only changes when the rename operation is performed, and remains stable under other operations (such as creation, query, deletion, attribute modification, etc.), ensuring the consistency of the metadata access path.

[0069] When a delete operation is performed on a file (or directory), the reference count recorded in the reverse index file handle value of the file (or directory) is first reduced by 1: if the reference count is not 0 after being reduced by 1, the file metadata key-value pair of the file (or directory) is moved to a link reservation directory (which is a hidden directory used by the system to store files whose reference count is not 0 when deleted); if the reference count is 0 after being reduced by 1, the relevant data corresponding to the file (or directory) can be directly deleted.

[0070] Further, based on the above file metadata layout, a hard link is implemented, and the specific implementation manner is as follows:

[0071] The hard link has independent file metadata key-value pair and reverse index file handle key-value pair, wherein the value of the file metadata key-value pair of the hard link stores the reverse index file handle key of the target file, and it is marked in the attributes that the current file is a hard link; at the same time, in the process of creating the hard link, the reference count recorded in the reverse index file handle value of the target file is increased by 1.

[0072] When the operation object is a hard link, all operations (such as reading and writing data, obtaining / modifying attributes, adding / deleting / modifying / querying extended attributes, etc.) except renaming, creating and deleting operations are redirected to the target file, and actual operations are performed on the target file.

[0073] When the hard link is deleted, the reference count recorded in the reverse index file handle value of the target file is first reduced by 1: if the reference count after being reduced by 1 is not 0, only the file metadata key-value pair and the reverse index file handle key-value pair of the hard link itself are deleted; if the reference count after being reduced by 1 is 0, the file metadata key-value pair, the reverse index file handle key-value pair of the target file and the file metadata key-value pair, the reverse index file handle key-value pair of the hard link itself are all deleted. The deletion process needs to ensure that the key-value pair deletion operations of the target file (if it needs to be deleted) and the hard link itself are performed synchronously to avoid metadata residue or reference count abnormalities caused by partial deletion.

[0074] Further, S3 shallow copy is implemented based on the above file metadata layout, and the specific implementation manner is as follows:

[0075] The S3 shallow copy file has independent file metadata key-value pairs and reverse index file handle key-value pairs, wherein the value of the file metadata key-value pair of the S3 shallow copy file stores the reverse index file handle key of the target file, and it is marked in the attribute that the current file is an S3 shallow copy; meanwhile, during the creation of the S3 shallow copy, the reference count recorded in the reverse index file handle value of the target file is increased by 1.

[0076] When the operation object is an S3 shallow copy file, data reading and writing operations are redirected to the target file, and all data reading and writing operations are performed on the target file; and metadata operations (including file creating, deleting and renaming, attribute obtaining and modifying, adding, deleting, modifying and querying extended attributes, etc.) are performed on the S3 shallow copy file itself.

[0077] When the S3 shallow copy file is deleted, the reference count recorded in the reverse index file handle value of the target file is first reduced by 1: if the reference count after being reduced by 1 is not 0, only the file metadata key-value pair and the reverse index file handle key-value pair of the S3 shallow copy file itself are deleted; if the reference count after being reduced by 1 is 0, the file metadata key-value pair, the reverse index file handle key-value pair of the target file and the file metadata key-value pair, the reverse index file handle key-value pair of the S3 shallow copy file itself are all deleted. The deletion process needs to ensure that the key-value pair deletion operations of the target file (if it needs to be deleted) and the S3 shallow copy itself are performed synchronously to avoid metadata residue or reference count abnormalities caused by partial deletion.

[0078] The features, working principles and advantages of the specific embodiments of the present application are further described below.

[0079] The distributed file system based on distributed key-value pairs is generally composed of a distributed file system client, a metadata server, a distributed key-value pair storage system, and a distributed data storage system, as shown in Figure 3 .

[0080] Metadata layout:

[0081] The present application is based on the metadata server implementation scheme of the distributed key-value pair storage system. The metadata performance is improved by improving the metadata layout, and the S3 shallow copy is compatible. The specific scheme is as follows: the file metadata key-value pair is introduced as the storage main body of the file or directory metadata, which stores the metadata information including the directory item record and the inode; at the same time, the reverse index file handle is introduced as the unique identifier of the file metadata to replace the inode number (this scheme no longer supports the inode number), and the file metadata key-value pair and the reverse index file handle key-value pair are persisted in the distributed key-value pair. Based on the file metadata key-value pair and the reverse index file handle key-value pair, the distributed file system can be realized, and the hard link and the S3 shallow copy are supported, and the metadata layout is as shown in Figure 4 .

[0082] In the metadata tree, the metadata information of the file (or directory) is stored through the file metadata key-value pair, wherein the file metadata key is composed of the file system ID, the parent directory ID, and the file (or directory) name, and the file metadata value stores the metadata information of the file (or directory), including the file layout, the attribute, the extended attribute, and the like. In the reverse index file handle table, the introduced reverse index file handle key is used as the unique identifier of the file, and the reverse index file handle key is composed of the file system ID, the initial parent directory ID, the first N characters of the initial file (or directory) name, and the file ID, and the reverse index file handle value contains the file metadata key and the reference count; wherein the initial parent directory ID refers to the parent directory ID when the file (or directory) is created, and the initial file (or directory) name refers to the name when the file (or directory) is created.

[0083] When interfacing with Fuse, Fuse identifies the metadata information through the inode number. After loading the metadata of the file, the ID of the file (or directory) is used as the inode number, and a mapping table of the ID of the file (or directory) and the reverse index file handle key is maintained in the memory; when interfacing with NFS, the reverse index file handle no longer uses the inode number, but uses the reverse index file handle key. The metadata key can be found through the reverse index file handle key, and then the metadata can be obtained.

[0084] Metadata operation:

[0085] Based on the above metadata layout, the operation of metadata makes corresponding adjustments: when creating a file (or directory), first allocate a file ID for the file, then prepare the file metadata key-value pair and the reverse index file handle key-value pair and submit them to the distributed database; since the file metadata key and the reverse index file handle key have the same prefix, in the distributed key-value pair using range partitioning, they will most likely fall into the same key-value pair node, so one-phase commit can be used to greatly improve performance.

[0086] When querying a file (or directory), the file metadata key is composed of the file system ID, the initial parent directory ID, and the file or directory name. Through this key, the metadata can be directly found, and the query performance is good. When traversing the child files (or directories) under the directory, only the file metadata key-value pairs under the directory need to be traversed to obtain the metadata of all child files (or directories), without the need for individual queries, and the traversal performance is good.

[0087] When deleting a file (or directory), first reduce the reference count of the reverse index file handle key-value pair by 1, and if the reference count is 0 after reducing by 1, the file metadata key-value pair and the reverse index file handle key-value pair need to be deleted; if the reference count is not 0, the file is moved to the link preservation directory (the link preservation directory is a system internal hidden directory used to store files with a reference count of 0 when deleted). If the file (or directory) has not been renamed after creation, the task of deleting the two key-value pairs can most likely be completed through one-phase commit, with higher performance; if the file (or directory) has been renamed after creation, the task of deleting the two key-value pairs most likely needs to be completed through two-phase commit, with a slight decrease in performance.

[0088] When renaming a file (or directory), the file metadata key and the reverse index file handle value stored in the file metadata key are modified, but the reverse index file handle key remains unchanged; at this time, the reverse index file handle key and the file metadata key most likely do not fall into the same key-value pair node, so two-phase commit is used, and the performance will decrease slightly.

[0089] Hard link implementation:

[0090] The method for implementing hard links based on the above metadata layout is as follows: when creating a hard link, an independent metadata key-value pair and a reverse index file handle key-value pair are generated, and in the metadata value, it is identified that the file is a hard link, and the reverse index file handle key of the link target file is recorded, and then the reference count recorded in the reverse index file handle value of the target file is increased by 1.

[0091] When searching for a file or traversing a directory, if the current file is found to be a hard link, the target file's file metadata key needs to be found through the target file's reverse index file handle key recorded in the metadata value, and then the directory file's metadata is obtained through the target file's file metadata key.

[0092] When the operation object is a hard link, other operations (such as reading and writing data, obtaining / modifying attributes, adding / deleting / modifying / querying extended attributes, etc.) other than delete and rename are redirected to the metadata of the target file for execution.

[0093] When the deleted file is not a hard link, if the reference count recorded in the reverse index file handle value is reduced by 1 and becomes 0, the file is directly deleted; if the reference count is not 0, it means that the file is the target file of other hard link files, and the file will be moved to the link reservation directory.

[0094] When the deleted file is a hard link, if the reference count recorded in the reverse index file handle value of the target file is reduced by 1 and becomes 0, the target file is deleted in the link reservation directory, and regardless of whether the target file is deleted, the current hard link file is deleted.

[0095] S3 shallow copy implementation:

[0096] The method for implementing S3 shallow copy based on the above metadata layout is as follows: when creating an S3 shallow copy, independent metadata key-value pairs and reverse index file handle key-value pairs are generated, the file is identified as an S3 shallow copy in the metadata value, and the reverse index file handle key of the link target file is recorded, and then the reference count recorded in the reverse index file handle value of the target file is increased by 1.

[0097] When searching for a file or traversing a directory, if the current file is found to be an S3 shallow copy, the file metadata key of the target file is found through the target file reverse index file handle key recorded in the metadata value, and the metadata of the directory file is obtained through the file metadata key of the target file.

[0098] When the operation object is an S3 shallow copy, data reading and writing operations are redirected to the metadata of the target file for execution, and metadata operations (including creating / deleting / rename files, obtaining / modifying attributes, adding / deleting / modifying / querying extended attributes, etc.) are executed in the current S3 shallow copy file.

[0099] When the deleted file is not an S3 shallow copy, if the reference count recorded in the reverse index file handle value is reduced by 1 and becomes 0, the file is directly deleted; if the reference count is not 0, it means that the file is the target file of other S3 shallow copy files, and the file will be moved (rename) to the link reservation directory.

[0100] When the deleted file is a hard link, if the reference count recorded in the reverse index file handle value of the target file is reduced by 1 and becomes 0, the target file is deleted in the link reservation directory, and regardless of whether the target file is deleted, the current hard link file is deleted.

[0101] Example:

[0102] The present application mainly relates to file system metadata layout, hard link implementation and s3 shallow copy implementation.

[0103] Metadata layout example:

[0104] Based on the metadata layout of the present application, in order to realize Figure 5 The directory structure shown in the figure, the key-value in the layout of distributed key-value pair Figure 6 As shown.

[0105] Among them:

[0106] The file metadata key is composed of file system ID, parent directory ID and name, and the file metadata value includes file layout, attribute, extended attribute, reverse index file handle key and other information, as shown in Figure 6 The file metadata key of / dir001 / hardlink003 is explained as follows (see Figure 7 ): 01 / 02 / hardlink003, where "hardlink003" is the file or directory name, "02" is the parent directory ID, and "01" is the file system ID.

[0107] The reverse index file handle key is composed of file system ID, initial parent directory ID, first N characters of initial file or directory name and file (or directory) ID, and the reverse index file handle value includes metadata key and reference count, as shown in Figure 6 The reverse index file handle key of / dir001 / hardlink003 is explained as follows (see Figure 8 ): 01 / 02 / hardlink / 04, where "04" is the file (or directory) ID, "hardlink" is the first 8 characters of the initial file or directory name "hardlink003", "02" is the initial parent directory ID, and "01" is the file system ID.

[0108] Among them, the initial file or directory name and the initial parent directory ID are the file or directory name and the ID of the parent directory when the file is created, and the file or directory name or the parent directory after renaming will change, but the initial file or directory name and the initial parent directory ID will not change; "hardlink" is the first 8 characters of the initial file or directory name "hardlink003".

[0109] When renamed, the file metadata key will change, the reverse index file handle key remains unchanged, but the metadata key recorded in the reverse index file handle value will also change, as shown in Figure 9 The red part changes (the others remain unchanged).

[0110] Metadata basic operation flow:

[0111] The basic operations of metadata include creating a file (directory), finding a file (directory), traversing a child file (directory), deleting a file (directory), and renaming a file (directory), the specific process is as follows, and the operation flowchart is as shown in Figure 10

[0112] Creating a file or directory:

[0113] Assign an ID with a unique identifier to the file (directory) to be created; organize the contents of the metadata key-value and reverse index file handle key-value (the contents are described above); save the metadata key-value pair and the reverse index file handle key-value pair to the distributed key-value pair.

[0114] Finding a file (directory):

[0115] According to the parent directory ID and the name to form a metadata key; according to the metadata key to find the metadata value in the distributed key-value pair; after finding the metadata value, the metadata information can be obtained.

[0116] Traversing a child file (directory):

[0117] According to the parent directory ID to form a prefix key; according to the prefix key to traverse the key-value in the distributed key-value pair; parse the traversed key-value pair one by one, and the metadata of the child file (subdirectory) can be obtained.

[0118] Deleting a file (directory):

[0119] According to the parent directory ID and the name to form a metadata key; according to the metadata key to find the metadata value in the distributed key-value pair; according to the reverse index file handle key in the metadata value to obtain the reverse index file handle value; if the reference count in the reverse index file handle value is reduced by 1 and becomes 0, then delete the metadata key-value pair and the reverse index file handle key-value pair, otherwise move the file to the link reservation directory.

[0120] Renaming a file (directory):

[0121] According to the parent directory ID and the name to form a metadata key; according to the metadata key to find the metadata value in the distributed key-value pair; according to the reverse index file handle key in the metadata value to obtain the reverse index file handle value; according to the new parent directory ID and the new name to create a new metadata key-value pair; update the recorded metadata key in the reverse index file handle value to the new metadata key-value pair; delete the old metadata key-value pair.

[0122] Attribute and extended attribute modification:

[0123] ​According to the parent directory ID and name, a metadata key is formed; according to the metadata key, a metadata value is found in the distributed key-value pair; in the metadata value, attribute or (extended attribute) information is updated, and is submitted to the distributed key-value pair system.

[0124] Hard link implementation:

[0125] The operations involved in the hard link of the file system include creation, deletion, query, reading and writing data, attribute modification, extended attribute modification, renaming, etc., and the operation process is as shown in Figure 11

[0126] Creating a hard link:

[0127] According to the parent directory ID and name of the link target, a metadata key value pair of the target is obtained; according to the reverse index file handle key in the metadata key value pair of the target, a reverse index file handle key value pair of the target is obtained; the reference count in the reverse index file handle value of the target is increased; the reverse index file handle key of the target is recorded in the metadata value of the hard link; the metadata key value pair and the reverse index file handle key value pair of the hard link are created.

[0128] Deleting a hard link:

[0129] According to the parent directory ID and name, a metadata key value pair is obtained, and whether the current file is a hard link is determined according to the metadata key value pair; if it is not a hard link, the general deletion process in the metadata basic operation process is executed; if it is a hard link, the reverse index file handle key value pair of the target is obtained according to the target reverse index file handle key in the metadata key value pair of the hard link, the reference count in the reverse index file handle value of the target is reduced by 1, if the reference count is 0 after the reduction, the metadata key value pair and the reverse index file handle key value pair of the target are deleted under the link retention directory, otherwise only the reference count in the reverse index file handle value of the target is updated, and finally the metadata key value pair and the reverse index file handle key value pair of the hard link are deleted.

[0130] Querying a hard link:

[0131] According to the parent directory ID and name, a metadata key value pair is obtained, and whether the current file is a hard link is determined according to the metadata key value pair; if it is not a hard link, the general query process in the metadata basic operation process is executed; if it is a hard link, the reverse index file handle key value pair of the target is obtained according to the target reverse index file handle key in the metadata key value pair of the hard link, and then the metadata key value pair of the target is queried according to the target metadata key in the reverse index file handle value of the target, and the metadata can be obtained by analyzing the metadata key value pair.

[0132] Reading and writing data, modifying attributes and extended attributes of a hard link:

[0133] ​According to the above query hard link process, the metadata of the hard link is obtained, and operations such as read and write data of the hard link, modification of attributes and extension attributes are redirected to the target file.

[0134] Renaming hard link:

[0135] The renaming process is consistent with the general renaming process in the metadata basic operation process.

[0136] S3 shallow copy implementation:

[0137] The operations involved in the file system compatible S3 shallow copy include creation, deletion, query, read and write data, modification of attributes, modification of extension attributes, renaming, etc., and the operation process is as shown in Figure 12

[0138] Creating S3 shallow copy:

[0139] According to the parent directory ID and name of the S3 shallow copy target, the metadata key-value pair of the target is obtained; according to the reverse index file handle key in the target metadata key-value pair, the target reverse index file handle key-value pair is obtained; the reference count in the target reverse index file handle value is increased; the reverse index file handle key of the target is recorded in the metadata value of the S3 shallow copy file; the metadata key-value pair and the reverse index file handle key-value pair of the S3 shallow copy file are created.

[0140] Deleting S3 shallow copy:

[0141] According to the parent directory ID and name, the metadata key-value pair is obtained, and according to the metadata key-value pair, it is judged whether the current file is an S3 shallow copy; if it is not an S3 shallow copy, the general deletion process in the metadata basic operation process is executed; if it is an S3 shallow copy, the target reverse index file handle key in the metadata key-value pair of the S3 shallow copy is obtained, the target reverse index file handle key-value pair is obtained, the reference count in the target reverse index file handle value is reduced by 1, if the reference count is 0 after the reduction, the metadata key-value pair and the reverse index file handle key-value pair of the target are deleted in the link reservation directory, otherwise only the reference count in the target reverse index file handle value is updated, and finally the metadata key-value pair and the reverse index file handle key-value pair of the S3 shallow copy are deleted.

[0142] Querying S3 shallow copy:

[0143] ​According to the parent directory ID and the name, a metadata key-value pair is acquired, and whether the current file is an S3 shallow copy is determined according to the metadata key-value pair; if not, a general query process in a metadata basic operation process is executed; if yes, a target reverse index file handle key value pair is acquired according to a target reverse index file handle key in the metadata key-value pair of the S3 shallow copy, a target metadata key value pair is acquired according to a target metadata key in the target reverse index file handle value, and the metadata can be acquired by analyzing the metadata key-value pair.

[0144] Read and write data of the S3 shallow copy:

[0145] According to the above S3 shallow copy query process, the metadata of the S3 shallow copy is acquired, and the read and write data operation of the S3 shallow copy is redirected to the target file for execution.

[0146] Renaming, attribute modification and extension attribute of the S3 shallow copy:

[0147] Consistent with the general renaming, attribute modification and extension attribute process in the metadata basic operation process.

[0148] FUSE file index number simulation and use of the NFS reverse index file handle:

[0149] When interfacing with FUSE, FUSE identifies metadata information through an index node number, so after loading the metadata of a file, the ID of the file (or directory) is used as the index node number, and a mapping table of the ID of the file (or directory) and the reverse index file handle key is maintained in the memory, as shown in Figure 13 .

[0150] When the memory structure of the FUSE recorded file metadata is discarded, the corresponding relationship between the file ID and the reverse index file handle key is also deleted from the mapping table, so as to control the memory size.

[0151] When interfacing with NFS, the reverse index file handle should use the reverse index file handle key, through which the metadata key can be found, and the metadata can be acquired, and the index node number cannot be used.

[0152] In summary, the application provides an implementation scheme compatible with file hard link and S3 shallow copy based on a distributed key-value pair, which effectively solves the problems of poor operation performance of creating, deleting, querying and directory traversal and the inability to support S3 shallow copy in the existing distributed file system scheme based on a distributed key-value pair by optimizing the file metadata layout and introducing a reverse index.

[0153] Compared with the traditional scheme, the application has the following outstanding features and technical advantages:

[0154] The traditional distributed file system adopts a "directory entry + inode" separation layout mode, the directory entry is saved in the directory entry of the parent directory, the inode number of the corresponding file (or directory) is found through the file or directory name, and the inode storing metadata is found through the inode number; when creating or deleting a file, the directory entry table and the inode table need to be modified at the same time, after this operation is mapped to a distributed key-value pair system, the two tables are most likely to fall on different nodes, and the transaction needs to be completed by relying on two-phase commit (2PC), which is low in efficiency; when finding a file, the inode number is obtained by querying the directory entry first, and then the metadata is obtained by querying the inode, two queries cause performance loss, especially when executing `ls-l` or list operation compatible with S3 protocol, the directory entry needs to be obtained in batches first, and then the inode is queried one by one, the delay problem is more obvious; although the renaming only needs to modify the directory entry, and the hard link only needs to create an independent directory entry with the target inode number, the implementation is simple, but the overall high-frequency operation (lookup, list, create, delete) efficiency short board is obvious.

[0155] In view of the deficiencies of the traditional scheme, the metadata layout is restructured and the reverse index is introduced, so that the performance and compatibility are optimized:

[0156] On the one hand, the application discards the traditional "directory entry + inode" separation storage design, and integrates the metadata of the directory entry and the inode into the same storage carrier (corresponding to the file metadata key-value pair), the key is composed of "file system ID / parent directory ID / file (or directory) name" (that is, the directory entry itself), and the value directly contains the complete metadata such as file layout, attribute, extended attribute and subsequent introduced reverse index file handle key. This design makes it unnecessary to query the directory entry to obtain the inode number when finding a file (or directory), and the metadata can be directly located by the key composed of the parent directory ID and the file or directory name, which greatly reduces the query steps; when traversing the directory sub-file, only the prefix key composed of the parent directory ID is needed, and the matching file metadata key-value pair is scanned in the distributed key-value pair, so that the metadata of all sub-files (or sub-directories) can be obtained in batches, without the need to query the inode one by one according to the inode number, which significantly improves the traversal efficiency.

[0157] On the other hand, in order to solve the problem of "inode number invalidation after file renaming and unable to be used as unique identifier" in the traditional scheme, the application introduces a reverse index file handle (reverse index file handle) as a unique and unchangeable identifier of a file / directory. The reverse index file handle key is composed of "file system ID / initial parent directory ID / first N characters of the name of the file (or directory) / file ID", and the value contains the current file metadata key and the reference count. Even if the file renaming causes the file metadata key to change, the reverse index file handle key remains unchanged, and only the file metadata key recorded in the value needs to be updated. At the same time, since the file metadata key and the prefix of the reverse index file handle key are highly consistent (for example, the file metadata key is "01 / 02 / file002", and the reverse index file handle key is "01 / 02 / file002 / 03"), in a distributed key-value pair using range sharding, the two keys are most likely to fall into the same node, so that the creation or deletion of a file can be completed through a one-phase commit operation, avoiding the communication and resource locking overhead of a two-phase commit between nodes, and improving the transaction execution efficiency.

[0158] In addition, in view of the compatibility requirement of the traditional scheme and FUSE when interfacing, "metadata needs to be identified by inode number", the application maintains a mapping table of file ID and reverse index file handle key in memory, simulates the file ID as the inode number required by FUSE, and ensures that the FUSE kernel logic can be adapted without modification; when interfacing with NFS, the reverse index file handle key is directly used as the reverse index file handle, and the file metadata key can be quickly located through the reverse index file handle key to obtain the metadata, avoiding the adaptation difficulty caused by the dependence of inode number in the traditional scheme.

[0159] In summary, through the design of "integrating the metadata layout of directory entry and inode" and "introducing a reverse index file handle as a unique and unchangeable index", the application not only solves the problem of low efficiency of high-frequency operations in the traditional scheme, but also realizes the compatibility of hard link and S3 shallow copy. The specific advantages can be summarized as follows:

[0160] a. When creating or deleting a file (directory), the file metadata key-value pair and the reverse index file handle key-value pair are most likely to be located in the same key-value pair node due to the consistent prefix, supporting one-phase commit and greatly improving the efficiency of creation and deletion;

[0161] b. When searching for a file (directory), the file metadata key composed of the parent directory ID and the name can directly find the metadata, without the multi-step operation of "searching directory entry -> searching inode", and the efficiency is significantly improved;

[0162] c. When traversing child files (directories), only the file metadata key-value pairs under the prefix of the parent directory need to be scanned to batch obtain the metadata, without querying each according to the inode number, and the traversal efficiency is significantly improved;

[0163] d. Not only can support hard link, but also compatible with S3 shallow copy, convenient to interface S3 protocol, expand the system's applicable scenario.

[0164] The above is a further detailed description of the present application in combination with specific / preferred embodiments, and cannot be regarded as limiting the specific implementation of the present application to these descriptions. For ordinary skilled persons in the art to which the present application belongs, without departing from the concept of the present application, they can make several substitutions or modifications to the described embodiments, and these substitutions or modifications shall be regarded as belonging to the protection scope of the present application.

Claims

1. A method for implementing compatible file hard link and S3 shallow copy based on distributed key-value pairs, characterized in that, Comprise: In a distributed key-value pair storage system, a file metadata key-value pair is used as the metadata storage subject of a file or directory, wherein the file metadata key is composed of a file system ID, a parent directory ID, and a file or directory name, and the file metadata value contains the metadata information of the file or directory; A reverse index file handle is introduced as the unique and unchangeable identifier of a file or directory, wherein the reverse index file handle key is composed of a file system ID, an initial parent directory ID, an initial file or directory name, and a file or directory ID, and the reverse index file handle value contains the current file metadata key and a reference count; Based on the layout of the file metadata key-value pair and the reverse index file handle key-value pair, the metadata operation is optimized so that when a file or directory is created or deleted, the file metadata key and the reverse index file handle key are likely to be located in the same key-value pair node due to the same prefix, and one-stage submission is supported to improve performance; Based on the layout of the file metadata key-value pair and the reverse index file handle key-value pair, file hard link and S3 shallow copy are implemented, wherein both the hard link and the S3 shallow copy create independent file metadata key-value pairs and reverse index file handle key-value pairs, and the file metadata value of the target file records the reverse index file handle key of the target file, and updates the reference count in the reverse index handle value of the target file; The implementation of file hard link includes: obtaining the reverse index file handle key-value pair of the target file according to the reverse index file handle key of the target file, and increasing the reference count in the reverse index file handle value by 1; The file metadata key-value pair and the reverse index file handle key-value pair of the hard link itself are created, wherein the file metadata value of the hard link records the reverse index file handle key of the target file and sets the hard link identifier; regardless of whether the target is deleted, the file metadata key-value pair and the reverse index file handle key-value pair of the hard link itself are finally deleted.

2. The method of claim 1, wherein, The file metadata value includes file layout, attributes, extended attributes, and reverse index file handle key; The initial parent directory ID and the initial file or directory name in the reverse index file handle key are the parent directory ID and the file or directory name at the time of file or directory creation, and the rename operation does not change the reverse index file handle key, but updates the file metadata key recorded in the reverse index file handle value; When interfacing with FUSE, a mapping table of file ID and reverse index file handle key is maintained in memory, and the file ID is used as the simulated index node number; When interfacing with NFS, the reverse index file handle key is directly used as the reverse index file handle.

3. The method of claim 1, wherein, The implementation of file hard link includes: Obtaining the reverse index file handle key-value pair of the target file according to the reverse index file handle key of the target file, and increasing the reference count in the reverse index file handle value by 1; The file metadata key-value pair and the reverse index file handle key-value pair of the hard link itself are created, wherein the file metadata value of the hard link records the reverse index file handle key of the target file and sets the hard link identifier; Regardless of whether the target is deleted, the file metadata key-value pair and the reverse index file handle key-value pair of the hard link itself are finally deleted.

4. The method of claim 1, wherein, The implementation of S3 shallow copy includes: When creating the S3 shallow copy, the file metadata key-value pair of the copy target is obtained according to the parent directory ID and the file or directory name of the copy target, and the reverse index file handle key of the target file is parsed from the file metadata key-value pair; The reverse index file handle key-value pair of the target file is obtained according to the reverse index file handle key of the target file, and the reference count in the reverse index file handle value is increased by 1; The file metadata key-value pair and the reverse index file handle key-value pair of the S3 shallow copy are created, wherein the file metadata value of the S3 shallow copy records the reverse index file handle key of the target file and sets the S3 shallow copy identifier; When searching or traversing the S3 shallow copy, the file metadata key of the target file is found through the target reverse index file handle key recorded in the file metadata value, and the metadata of the target file is obtained; When performing data read-write operation on the S3 shallow copy, the operation is redirected to the target file for execution; When performing metadata operation on the S3 shallow copy, the operation is executed on the file metadata key-value pair of the S3 shallow copy; When deleting the S3 shallow copy, the target reverse index file handle key-value pair is found according to the target reverse index file handle key in the file metadata value of the S3 shallow copy, and the reference count in the target reverse index file handle value is decreased by 1; if the reference count is 0 after the decrease, the file metadata key-value pair and the reverse index file handle key-value pair of the target file are further deleted; regardless of whether the target is deleted, the file metadata key-value pair and the reverse index file handle key-value pair of the S3 shallow copy are finally deleted.

5. The method of claim 1, wherein, In the metadata operation based on the file metadata key-value pair and the reverse index file handle key-value pair, the process of creating a file or a directory includes: allocating a file ID with a unique identifier to the file or the directory to be created; organizing the file metadata key-value pair, wherein the key is composed of the file system ID, the parent directory ID and the file or directory name, and the value contains the metadata information of the file and the reverse index file handle key of the file; organizing the reverse index file handle key-value pair, wherein the key is composed of the file system ID, the initial parent directory ID, the first N characters of the initial file or directory name and the file ID, and the value contains the current file metadata key and the initial reference count; submitting the file metadata key-value pair and the reverse index file handle key-value pair to the distributed key-value pair storage system.

6. The method of claim 1, wherein, In the metadata operation based on the file metadata key-value pair and the reverse index file handle key-value pair, the process of querying a file or a directory includes: composing the file metadata key according to the parent directory ID and the file or directory name of the file or the directory to be queried; querying in the distributed key-value pair storage system using the file metadata key to directly obtain the corresponding file metadata value; parsing the metadata information of the file from the obtained file metadata value.

7. The method of claim 1, wherein, In the metadata operation based on the file metadata key-value pair and the reverse index file handle key-value pair, the process of traversing the child files or directories under a directory includes: composing the prefix key according to the ID of the directory to be traversed; performing range scanning in the distributed key-value pair storage system using the prefix key to obtain all matched file metadata key-value pairs; parsing each obtained file metadata value to directly obtain the complete metadata information of the child file or the child directory.

8. The method of claim 1, wherein, In the metadata operation based on the file metadata key-value pair and the reverse index file handle key-value pair, the process of deleting a file or a directory comprises: According to the parent directory ID and the file or directory name of the file or directory to be deleted, a file metadata key is formed; According to the file metadata key, a file metadata value is obtained, from which a reverse index file handle key is parsed; According to the reverse index file handle key, a reverse index file handle key-value pair is obtained, and the reference count in the reverse index file handle value is reduced by 1; It is judged whether the reference count is 0 after being reduced by 1: if yes, the file metadata key-value pair and the reverse index file handle key-value pair of the file or directory are deleted; if not, the file or directory is moved to a link reservation directory inside the system.

9. The method of claim 1, wherein, In the metadata operation based on the file metadata key-value pair and the reverse index file handle key-value pair, the process of renaming a file or a directory comprises: According to the current parent directory ID and the current file or directory name of the file or directory, a current file metadata key is formed; According to the current file metadata key, a file metadata value and a reverse index file handle key are obtained; According to the new parent directory ID and the new file or directory name, a new file metadata key is generated; A new file metadata key-value pair is created, the key of which is the new file metadata key, and the value content is the same as the old file metadata value; According to the reverse index file handle key, a reverse index file handle key-value pair is obtained, and the recorded file metadata key in the reverse index file handle value is updated to the new file metadata key; The old file metadata key-value pair is deleted.

10. A system for compatible file hard linking and S3 shallow copying based on distributed key-value pairs, the system comprising: A metadata server is configured to cooperate with a distributed file system client and a distributed key-value pair storage system; The metadata server is configured to: Maintain a file metadata key-value pair and a reverse index file handle key-value pair in the distributed key-value pair storage system, wherein the file metadata key is composed of a file system ID, a parent directory ID and a file or directory name, and the file metadata value contains metadata information of the file or directory; the reverse index file handle key is composed of a file system ID, an initial parent directory ID, an initial file or directory name N characters and a file ID, and the reverse index file handle value contains a current file metadata key and a reference count; In response to a file operation request of the distributed file system client, a metadata operation is performed by using the layout of the file metadata key-value pair and the reverse index file handle key-value pair, so that when a file or a directory is created or deleted, the file metadata key and the reverse index file handle key are located in the same key-value pair node with a high probability due to the same prefix, and one-phase commit is supported; Based on the layout of the file metadata key-value pair and the reverse index file handle key-value pair, file hard link and S3 shallow copy are realized in response to a client request, by creating independent file metadata key-value pairs and reverse index file handle key-value pairs, the file metadata value of which records the reverse index file handle key of the target file, and the reference count in the target reverse index file handle value is updated; The implementation of the file hard link comprises: obtaining the reverse index file handle key value pair of the target file according to the reverse index file handle key of the target file, and increasing the reference count in the reverse index file handle value of the target file by 1; The file metadata key value pair and the reverse index file handle key value pair of the hard link itself are created, wherein the file metadata value of the hard link records the reverse index file handle key of the target file and sets the hard link identification; no matter whether the target is deleted or not, the file metadata key value pair and the reverse index file handle key value pair of the hard link itself are finally deleted.

Images