Method and system for realizing compatible file hard link and S3 shallow copy based on distributed key-value pair

Abstract

The invention discloses a method and a system for realizing compatible file hard link and S3 shallow copy based on a distributed key-value pair, a file metadata key-value pair is used as a metadata storage main body of a file or a directory, a key consists of a file system ID (Identity), a parent directory ID and a file or directory name, and a value contains metadata information; a reverse index file handle key value pair is introduced to serve as a unique invariant identifier, a key is composed of a file system ID, an initial parent directory ID, an initial file or first N characters of a directory name and a file ID, and a value contains a current file metadata key and a reference count. When files or directories are created and deleted, the files or the directories are located at the same one-key value pair node in a large probability, and one-stage submission is supported to improve performance; hard linking and S3 shallow copying are achieved at the same time, independent file metadata key-value pairs and reverse index file handle key-value pairs are created for the hard linking and the S3 shallow copying, reverse index file handle keys of the target file are recorded by file metadata values of the file metadata key-value pairs, reference counts of the reverse index file handle values of the target file are updated, and performance and compatibility are both considered.

Description

TECHNICAL FIELD

[0001] The present application relates to a distributed key-value pair storage technology, in particular to an implementation method for compatible file hard link and S3 shallow copy based on distributed key-value pairs. 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: 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.

[0004] 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.

[0005] 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 users access files through path name, the system finds the target inode by parsing directory entries in directories, and finally locates file data blocks, achieving efficient storage and retrieval.

[0006] Distributed file system based on distributed key-value pairs 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 pairs on multiple nodes, while providing traditional file system access interfaces (such as directory tree operations, 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, permissions and the mapping relationship between data blocks and key-value pair keys; 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 advantages are high scalability, low latency characteristics of distributed key-value pair storage, and 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.

[0007] 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).

[0008] 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 distributed key-value pairs, and further supports hard link (hardlink) functions. For example, Baidu's CFS (a large-scale distributed file system capable of handling 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 a 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.

[0009] 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, resulting in poor performance; and the scheme is difficult to be compatible with the AWS S3 shallow copy.

[0010] 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

[0011] The main purpose of the present application is to overcome the defects in the above background, 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.

[0012] To achieve the above purpose, the present application adopts the following technical scheme: 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: In the distributed key value pair storage system, a 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 the file system ID, the parent directory ID and the file or directory name, and the file metadata value contains the metadata information of the file or the directory; 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 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 current file metadata key and the 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 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; Based on the metadata layout, file hard link and S3 shallow copy are implemented, wherein the file 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.

[0013] 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 that cooperates with a distributed file system client and a distributed key-value pair storage system. The metadata server is configured to: The file metadata key-value pairs and the 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. In response to a file operation request of the distributed file system client, metadata operations are 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 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 a one-phase commit is adopted. 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.

[0014] The present application has the following beneficial effects: 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.

[0015] Compared with the traditional scheme, the present application has the following advantages: 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.

[0016] b. When looking up 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.

[0017] c. When traversing the sub-files (or sub-directories) 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.

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

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

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

[0021] Figure 2 is a main operation flowchart of a traditional distributed file system.

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

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

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

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

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

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

[0028] Figure 9 is the distributed key-value pair change graph after file renaming of the embodiment of the present application.

[0029] Figure 10 is the basic metadata operation flowchart of the embodiment of the present application.

[0030] Figure 11 is the hard link operation flowchart of the embodiment of the present application.

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

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

[0033] 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.

[0034] 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 the 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.

[0035] 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. The technical solution is proposed by optimizing file metadata layout (integrating directory items and inode metadata using file metadata key-value pairs) and introducing reverse index file handles (as the only unchanging identifier of 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 at the same time, facilitating compatibility with S3 protocols.

[0036] 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: In a distributed key-value pair storage system, file metadata key-value pairs are used as the main metadata storage of files or directories, 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; 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 with 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 needs in the actual application scenario; 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 performance; 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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 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.

[0042] 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 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 files or directories.

[0043] 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 the 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 the 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 the reverse index file handle value thereof 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.

[0044] 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 recorded file metadata key in the reverse index file handle value to the new file metadata key, and deleting the old file metadata key-value pair.

[0045] Embodiments of the present application also provide a system for compatible file hard link and S3 shallow copy based on distributed key-value pairs, comprising a metadata server, the metadata server is operated in cooperation 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 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; 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; 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 the target file, and the reference count in the target reverse index file handle value is updated.

[0046] 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: 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] Further, based on the above file metadata layout, a hard link is implemented, and the specific implementation manner is as follows: 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.

[0051] 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.

[0052] When the hard link is deleted, the reference count recorded in the reverse index file handle value of the target file is 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 the target file needs to be deleted) and the hard link itself are performed synchronously to avoid metadata residue or reference count abnormality caused by partial deletion.

[0053] Further, S3 shallow copy is implemented based on the above file metadata layout, and the specific implementation manner is as follows: The S3 shallow copy file 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 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 process of creating the S3 shallow copy, the reference count recorded in the reverse index file handle value of the target file is increased by 1.

[0054] 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.

[0055] When the S3 shallow copy file is deleted, the reference count recorded in the reverse index file handle value of the target file is 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 the target file needs to be deleted) and the S3 shallow copy itself are performed synchronously to avoid metadata residue or reference count abnormality caused by partial deletion.

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

[0057] A distributed file system based on distributed key-value pairs generally consists 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 .

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

[0059] In the metadata tree, the metadata information of a file (or directory) is stored through file metadata key-value pairs, 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 metadata information of the file (or directory), including file layout, attributes, extended attributes, and the like. In the reverse index file handle table, the introduced reverse index file handle key is used as the unique identifier of a file, and 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, and the reverse index file handle value contains a file metadata key and a reference count; wherein the initial parent directory ID refers to the parent directory ID at the time of file (or directory) creation, and the initial file (or directory) name refers to the name at the time of file (or directory) creation.

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

[0061] Metadata operation: 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] Hard link implementation: 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.

[0066] 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.

[0067] 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 deleting (delete) and renaming (rename) are redirected to the metadata of the target file for execution.

[0068] 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.

[0069] 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 whether the target file is deleted or not, the current hard link file is deleted.

[0070] S3 shallow copy implementation: 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.

[0071] 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.

[0072] 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.

[0073] 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.

[0074] 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 whether the target file is deleted or not, the current hard link file is deleted.

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

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

[0077] Among them: File metadata key is composed of file system ID, parent directory ID and name, and 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.

[0078] 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 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.

[0079] 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".

[0080] 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 rest remains unchanged).

[0081] Metadata basic operation flow: 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 flow is as shown in Figure 10 Creating a file or directory: 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.

[0082] Finding a file (directory): 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.

[0083] Traversing a child file (directory): 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.

[0084] Deleting a file (directory): 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.

[0085] Renaming a file (directory): 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.

[0086] Attribute and extended attribute modification: 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; update the attribute or (extended attribute) information in the metadata value, and submit it to the distributed key-value pair system.

[0087] Hard link implementation: The operations involved in the hard link of the file system include creation, deletion, query, read and write data, attribute modification, extended attribute modification, renaming, etc., and the operation flow is as follows​Figure 11 As shown.

[0088] Creating a hard link: According to the parent directory ID and the name of the link 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 hard link; the metadata key-value pair and the reverse index file handle key-value pair of the hard link are created.

[0089] Deleting a hard link: According to the parent directory ID and the name, the metadata key-value pair is obtained, and whether the current file is a hard link is judged 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 target 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 target reverse index file handle value is reduced by 1, and if the reference count is 0 after being reduced by 1, the metadata key-value pair and the reverse index file handle key-value pair of the target are deleted in the link retention 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 hard link are deleted.

[0090] Querying a hard link: According to the parent directory ID and the name, the metadata key-value pair is obtained, and whether the current file is a hard link is judged 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 target 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 target metadata key-value pair of the target is queried according to the target metadata key in the target reverse index file handle value, and the metadata can be obtained by analyzing the metadata key-value pair.

[0091] Reading and writing data, modifying attributes and extended attributes of a hard link: According to the above-mentioned hard link query process, the metadata of the hard link is obtained, and the reading and writing data, modification attributes and extended attributes of the hard link are redirected to the target file.

[0092] Renaming a hard link: It is consistent with the general renaming process in the metadata basic operation process.

[0093] S3 shallow copy implementation: The operations involved in the file system compatible with the S3 shallow copy include creation, deletion, query, reading and writing data, modifying attributes, modifying extended attributes, renaming, etc., and the operation process is as shown in Figure 12 .

[0094] Create S3 shallow copy: 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.

[0095] Delete S3 shallow copy: According to the parent directory ID and name, the metadata key-value pair is obtained, and whether the current file is an S3 shallow copy is judged according to the metadata key-value pair; 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-value pair of the target is obtained according to the target reverse index file handle key in the metadata key-value pair of the S3 shallow copy, the reference count in the target reverse index file handle value is reduced by 1, and if the reference count is 0 after being reduced by 1, 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.

[0096] Query S3 shallow copy: According to the parent directory ID and name, the metadata key-value pair is obtained, and whether the current file is an S3 shallow copy is judged according to the metadata key-value pair; if it is not an S3 shallow copy, the general query process in the metadata basic operation process is executed; if it is an S3 shallow copy, the target 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 S3 shallow copy, and then the target metadata key-value pair of the target is queried according to the target metadata key in the target reverse index file handle value, and the metadata can be obtained by parsing the metadata key-value pair.

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

[0098] Rename, modify attribute and extended attribute of S3 shallow copy: It is consistent with the general rename, modify attribute and extended attribute process in the metadata basic operation process.

[0099] FUSE file index number simulation and use of NFS reverse index file handle: When interfacing with FUSE, FUSE identifies metadata information by inode number, so after loading the metadata of a 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, as shown in Figure 13

[0100] When the memory structure of the file metadata recorded by FUSE 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 size of the memory.

[0101] When interfacing with NFS, the reverse index file handle should use the reverse index file handle key, by which the metadata key can be found, and the metadata can be obtained, and the inode number cannot be used.

[0102] In summary, the present application provides an implementation scheme compatible with file hard link and s3 shallow copy based on distributed key-value pairs, which effectively solves the problems of poor operation performance such as creation, deletion, query and directory traversal and the inability to support s3 shallow copy in the existing distributed file system scheme based on distributed key-value pairs by optimizing the file metadata layout and introducing reverse index.

[0103] Compared with the traditional scheme, the present application has the following outstanding features and technical advantages: The traditional distributed file system adopts a layout mode of "directory entry + inode" separation, 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 number is used to find the inode storing the metadata; when creating or deleting a file, the directory entry table and the inode table need to be modified at the same time, and after this operation is mapped to the 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 first querying the directory entry, and then the metadata is obtained by querying the inode, and the performance is lost by twice querying, especially when executing `ls-l` or list operation compatible with S3 protocol, the directory entry needs to be obtained in batches and then the inode is queried one by one, and 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 of the target inode number, the implementation is simple, but the overall high-frequency operation (lookup, list, create, delete) efficiency short board is obvious.

[0104] In view of the shortcomings of the traditional scheme, the present application realizes the dual optimization of performance and compatibility by reconstructing the metadata layout and introducing the reverse index: ​In one aspect, the application discards the traditional "directory entry + inode" separate storage design, integrates the directory entry and the metadata of 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" (i.e. 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 searching for 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, greatly reducing the query steps; when traversing the directory sub-files, only the prefix key composed of the parent directory ID is needed to scan the matching file metadata key-value pair in the distributed key-value pair, and the metadata of all sub-files (or sub-directories) can be batch obtained, without the need to query the inode according to the inode number one by one, significantly improving the traversal efficiency.

[0105] On the other hand, in order to solve the problem of "inode number invalidation with 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 the unique and unchanging identifier of the file / directory. 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) / file ID", and the value contains the current file metadata key and the reference count; even if the file metadata key changes due to file renaming, the reverse index file handle key remains unchanged, and only the file metadata key recorded in its value needs to be updated. At the same time, since the file metadata key and the reverse index file handle key have a high degree of consistency in the prefix (such as the file metadata key being "01 / 02 / file002" and the reverse index file handle key being "01 / 02 / file002 / 03"), in a distributed key-value pair using range sharding, they are likely to fall into the same node, so that the operation can be completed through one-phase commit when creating or deleting a file, avoiding the communication and resource locking overhead of two-phase commit between nodes, and improving the transaction execution efficiency.

[0106] In addition, in view of the compatibility requirement of the traditional scheme and FUSE when interfacing, which requires to identify the metadata through the 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 the inode number in the traditional scheme.

[0107] In summary, the present application solves the problem of low efficiency of high-frequency operation in the traditional scheme by the design of "integrating the metadata layout of directory items and index nodes" and "introducing the reverse index file handle as a unique invariant index", and realizes the compatibility of hard link and S3 shallow copy. The specific advantages can be summarized as follows: a. When creating or deleting a file (directory), the file metadata key-value pair and the reverse index file handle key-value pair are located in the same key-value pair node with a high probability due to the same prefix, supporting one-phase commit and greatly improving the efficiency of creation and deletion; 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 items -> searching index nodes", and the efficiency is significantly improved; 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 metadata, without querying according to the index node number one by one, and the traversal efficiency is significantly improved; d. Not only can support hard link, but also can be compatible with S3 shallow copy, which is convenient for interfacing S3 protocol and expands the application scenarios of the system.

[0108] The above is a further detailed description of the present application in combination with specific / preferred embodiments, and the specific implementation of the present application cannot be limited to these descriptions. For ordinary skilled persons in the technical field to which the present application belongs, without departing from the concept of the present application, they can make several alternatives or modifications to the described embodiments, and these alternatives or modifications should 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 N characters, 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 metadata layout, 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, and the reference count in the reverse index handle value of the target file is updated.

2. The method of claim 1, wherein, The file metadata value includes file layout, attributes, extended attributes, and reverse index file handle keys; 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 IDs and reverse index file handle keys is maintained in memory, and the file ID is used as a 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, Implementing file hard link includes: When creating a hard link, the file metadata key-value pair of the link target is obtained according to the parent directory ID and the file or directory name of the link target, and the reverse index file handle key of the target file is parsed from it; 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; Create a file metadata key-value pair and a reverse index file handle key-value pair for the hard link, 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; When finding or traversing to the hard link, the target file metadata key is found through the target reverse index file handle key recorded in the file metadata value, and then the metadata of the target file is obtained; When performing operations on the hard link other than deletion and renaming, all operations are redirected to the target file for execution; When deleting the hard link, 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 hard link, the reference count in the target reverse index file handle value is reduced by 1, and if the reference count is 0 after the reduction, 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 hard link itself are finally deleted.

4. The method of claim 1, wherein, Implementing the S3 shallow copy comprises: When creating the S3 shallow copy, the file metadata key value pair of the target file is obtained according to the parent directory ID and the file or directory name of the target file, 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 of the target file 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 to the S3 shallow copy, the file metadata key of the target file is found according to the target reverse index file handle key recorded in the file metadata value of the S3 shallow copy, 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, the reference count in the target reverse index file handle value is reduced by 1, and if the reference count is 0 after the reduction, 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 itself 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 comprises: 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 comprises a file system ID, a parent directory ID and a file or directory name, and the value contains metadata information of the file and a reverse index file handle key of the file; organizing the reverse index file handle key value pair, wherein the key comprises a file system ID, an initial parent directory ID, an initial file or directory name with N characters and a file ID, and the value contains a current file metadata key and an initial reference count; submitting the file metadata key value pair and the reverse index file handle key value pair to a 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 comprises: composing the file metadata key of the file or the directory to be queried according to the parent directory ID and the file or directory name of the file or the directory; querying in the distributed key-value pair storage system using the file metadata key to directly obtain the corresponding file metadata value; Resolving 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 sub-file or sub-directory under the 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; resolving each obtained file metadata value to directly obtain complete metadata information of the sub-file or sub-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 the file or directory comprises: composing a file metadata key of the file or directory to be deleted according to the parent directory ID and the file or directory name of the file or directory to be deleted; obtaining the file metadata value according to the file metadata key, and resolving a reverse index file handle key from the file metadata value; obtaining the reverse index file handle key-value pair according to the reverse index file handle key, and reducing the reference count in the reverse index file handle value of the reverse index file handle key-value pair by 1; judging whether the reference count is 0 after being reduced by 1: if yes, deleting the file metadata key-value pair and the reverse index file handle key-value pair of the file or directory; if not, moving the file or directory 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 the file or directory comprises: composing a current file metadata key of the file or directory according to the current parent directory ID and the current file or directory name of the file or directory; obtaining the file metadata value and the reverse index file handle key 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; creating a new file metadata key-value pair, of which the key is the new file metadata key and the value content is the same as that of the old file metadata value; obtaining the reverse index file handle key-value pair according to the reverse index file handle key, and updating the recorded file metadata key in the reverse index file handle value of the reverse index file handle key-value pair to the new file metadata key; deleting the old file metadata key-value pair.

10. A system for compatible file hard linking and S3 shallow copying based on distributed key-value pairs, the system comprising: The metadata server is configured to: maintain the file metadata key-value pair and the reverse index file handle key-value pair in the distributed key-value pair storage system, 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 contains the metadata information of the file or directory; 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 current file metadata key and the reference count; in response to the file operation request of the distributed file system client, perform the metadata operation by using the layout of the file metadata key-value pair and the reverse index file handle key-value pair, so that 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 when creating and deleting the file or directory, and one-phase commit is supported. ​ Based on the metadata layout, file hard links and S3 shallow copies are implemented in response to client requests by creating separate file metadata key-value pairs and reverse index file handle key-value pairs whose file metadata values record the reverse index file handle keys of the target files and update the reference count in the target reverse index file handle values.

Images