Distributed file storage metadata service method, server, client and system

Abstract

The application provides a distributed file storage metadata service method, a server, a client and a system. The method comprises the following steps: the server receives a request by using a user mode protocol stack and converts the request into a KV instruction to execute on a KV SSD; the KV SSD maintains two types of key-value pairs: the first type of key-value pair takes a file ID generated based on file original identity information and combined with an attribute identifier as a Key, and stores metadata attribute values; the second type of key-value pair takes a file current path as a Key, and stores original identity information. When accessing, the first type of key-value pair is preferentially searched by using a candidate ID calculated based on the current path; if no hit is found, the second type of key-value pair is used to obtain the original identity information to determine a real file ID and perform an operation. The application does not need to query a directory layer by layer, can locate metadata in at most two interactions, eliminates performance fluctuation, does not need to cache a directory tree, significantly reduces memory consumption and improves scalability.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer data service, and particularly relates to a distributed file storage metadata service method, a server, a client and a system. BACKGROUND

[0002] With the rapid development of artificial intelligence (AI) and intelligence computing field, massive training data sets put forward very high requirements to the underlying storage system. Distributed file storage systems are usually used as the preferred storage base due to their wide adaptability of interfaces. In these application scenarios, the system not only needs to have the characteristics of high throughput and low latency, but also must still provide stable storage and access performance in the face of hundreds of billions of small files.

[0003] The core bottleneck of these performance indicators is usually the metadata management of the distributed file storage system. In order to improve the metadata service capability, the existing mainstream distributed file storage systems (such as HDFS, CephFS, CurveFS, etc.) mostly adopt a hybrid architecture of "memory cache + database persistence". In this architecture, the metadata is stored persistently in the database on the disk, and at the same time, the system uses a large amount of memory resources to build a cache layer (including client local cache and server cache), trying to achieve high throughput and low latency through the high-speed read and write capability of memory.

[0004] However, the above prior art solution has the following significant technical defects when facing large-scale intelligence computing scenarios:

[0005] First, the I / O path of persistent storage is too long, which limits the underlying read and write performance. In the traditional architecture, the database is usually built on the host file system based on hard disk. When persistent read and write are needed, the data stream needs to go through a complex hierarchical transmission: from the database to the file system, from the file system to the block device request, and then from the block request to the hard disk. Inside the solid state drive (SSD), it also needs to go through the flash translation layer (FTL) for logical address to physical address conversion, mapping or indexing. This multi-level transmission process, accompanied by multiple segments of write amplification, log recording and additional transaction overhead, makes it difficult to meet the performance requirements of high-performance access by directly reading and writing metadata through the database.

[0006] Second, there is the issue of severe performance spikes. Due to performance bottlenecks in the underlying persistence path, existing systems heavily rely on memory caching. When metadata access fails to hit the memory cache (Cache Miss), the request must penetrate to the underlying database for access. In this case, the request latency will be significantly higher than the average latency, resulting in severe performance spikes. For file systems, performance stability is fundamental to availability; frequent spikes will severely impact the operational efficiency of upper-layer applications. Currently, most solutions can only optimize caching strategies for specific types of applications and cannot achieve universally stable performance.

[0007] Third, excessive memory resource consumption limits scalability. To alleviate performance glitches, some systems adopt aggressive caching strategies, such as increasing cache capacity or even attempting to load all metadata into memory (full caching). However, in scenarios with hundreds of billions or even higher numbers of small files, the amount of metadata is extremely large. Full caching leads to a dramatic increase in memory usage, which not only exceeds the system's scalability but also brings enormous cost pressure. Especially in AI computing scenarios, valuable memory resources should be prioritized for computing tasks, rather than being consumed in large quantities by managing metadata in the storage system.

[0008] In addition, some emerging solutions attempt to introduce techniques such as Log Structure Merging Tree (LSM-Tree) to balance memory and performance. However, when performing compaction operations, it often leads to additional long-tail latency of read requests and accelerates the wear and tear of NVMe SSDs due to write amplification issues, thus reducing hardware lifespan.

[0009] Therefore, a new distributed file storage metadata service is needed to meet current metadata management requirements. Summary of the Invention

[0010] The purpose of this invention is to provide a distributed file storage metadata service method, server, client, and system that eliminates the overhead of the FTL layer and solves the performance spikes in metadata access without relying on massive memory caching, thereby achieving stable and high-performance access to billions of files.

[0011] To achieve the above objectives, the present invention provides a distributed file storage metadata service method, applied on a server side, comprising:

[0012] The user-space protocol stack is used to receive metadata access requests, which are then converted into key-value pairs (KV) instructions and executed on the key-value pair solid-state drive (KV SSD).

[0013] The KV SSD maintains a first type of key-value pairs and a second type of key-value pairs.

[0014] The first type of key-value pair uses the file ID combined with the attribute identifier as the key and the corresponding metadata attribute value as the value; wherein, the file ID is calculated and generated based on the original identity information of the file; the original identity information includes at least the path information and file name when the file was created;

[0015] The second type of key-value pair uses the current path of the file as the key and the original identity information of the file as the value.

[0016] The access request includes a candidate file ID calculated based on the current path of the target file;

[0017] In response to the access request, if no corresponding first type key-value pair is found based on the candidate file ID, then the current path of the target file is used as the key to retrieve the second type key-value pair to obtain the original identity information, and the real file ID is determined accordingly, and corresponding operations are performed on the first type key-value pair.

[0018] Preferably, the original identity information includes: the parent node ID when the file was created, the absolute path when the file was created, and an adjustment factor that is a constant; the file ID is a unique identifier obtained by calculating the parent node ID, the absolute path, and the adjustment factor using a hash function.

[0019] Preferably, the method for retrieving the second type of key-value pairs using the current path as the key to obtain the original identity information and determining the real file ID accordingly includes: parsing the parent node ID, absolute path, and adjustment factor of the file when it was created from the value of the retrieved second type of key-value pairs, and recalculating the real file ID based on the parsed information using the hash function.

[0020] Preferably, the server includes multiple metadata service nodes; the method further includes: constructing a distributed hash table using a consistent hashing algorithm, and distributing and storing the first type of key-value pairs on different metadata service nodes through the distributed hash table.

[0021] Preferably, it also includes a method for handling path verification requests from clients:

[0022] Receive a path verification request for a target file sent by the client, the path verification request carrying the current path of the target file;

[0023] Based on the current path, search the KV SSD to see if a second type of key-value pair exists;

[0024] If the second type of key-value pair is retrieved, the original identity information stored in the second type of key-value pair is returned to the client so that the client can correct the calculation result of the file ID of the target file based on the original identity information.

[0025] Preferably, the second type of key-value pairs are generated when a renaming operation, a move operation, or a hash collision occurs during the creation of the target file.

[0026] Preferably, when a renaming operation, a move operation, or a hash collision occurs during the creation of any of the target files is detected, a corresponding second type of key-value pair is generated in each of the metadata service nodes.

[0027] Preferably, when multiple renaming or moving operations are detected on the target file, a new second type of key-value pair is generated using a Key including the latest path and a Value including the original identity information, and the old second type of key-value pair is replaced by the new second type of key-value pair.

[0028] Preferably, if the corresponding second type of key-value pair is not found in the KV SSD according to the current path in the path verification request, a response message indicating that the path is valid is returned to the client to indicate that the client confirms that the file ID predicted initially is correct.

[0029] This invention also provides a distributed file storage metadata service method, applied to a client, comprising:

[0030] Based on the current path information of the target file to be accessed, a predicted file ID of the target file is generated using a preset hash algorithm;

[0031] Based on the predicted file ID, a metadata access request is initiated to the server, and a path verification request is also initiated to the server, the path verification request carrying the current path information;

[0032] When the server returns a response that the metadata corresponding to the predicted file ID does not exist, the server receives the original identity information returned by the server in response to the path verification request. The original identity information includes the path information and file name when the target file was created.

[0033] Using the original identity information, the hash algorithm is used again to generate the real file ID of the target file;

[0034] Metadata access is performed on the target file based on the real file ID.

[0035] Preferably, the original identity information includes: the parent node ID at the time of file creation, the absolute path at the time of file creation, and an adjustment factor that is a constant; the file ID is a unique identifier obtained by calculating the parent node ID, the absolute path, and the adjustment factor using a hash function.

[0036] Preferably, the method for generating the predicted file ID of the target file using a preset hash algorithm includes:

[0037] Obtain the current parent node ID and current filename of the target file;

[0038] The predicted file ID is calculated using the current parent node ID, the current file name, and the preset default adjustment factor as input parameters and the preset hash algorithm.

[0039] Preferably, the method for initiating a path verification request to the server includes:

[0040] A search request is sent to the server, the search request containing the current parent node ID and current file name of the target file, in order to request the server to retrieve the corresponding original identity information in the second type of key-value pairs.

[0041] The present invention also provides a server, characterized in that the server provides services to the client based on the distributed file storage metadata service method described above.

[0042] The present invention also provides a client, characterized in that the client exchanges with the server based on the distributed file storage metadata service method described above.

[0043] The present invention also provides a distributed file storage metadata service system, which includes:

[0044] One or more processors;

[0045] Memory;

[0046] And one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the programs including instructions for performing the distributed file storage metadata service method as described above.

[0047] The present invention also provides a computer-readable storage medium, characterized in that it includes a computer program, which can be executed by a processor to perform the distributed file storage metadata service method as described above.

[0048] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the distributed file storage metadata service method as described above.

[0049] Compared to existing technologies, the distributed file storage metadata service method provided by the above technical solution firstly allows the client to directly generate a predicted file ID based on the current path using a hash algorithm. This eliminates the need for layer-by-layer querying of parent directory metadata (i.e., multiple network interactions) as in traditional file systems, reducing access complexity linearly with directory depth. When the metadata corresponding to the predicted ID is missing, the client receives the original identity information returned by the server and recalculates the real file ID for a secondary access. This means that regardless of changes in the file path, the client only needs at most two interactions to locate the metadata. This deterministic access mode eliminates performance fluctuations (glitches) caused by cache misses or different path depths, ensuring stable system performance. Furthermore, the client's path resolution relies on algorithmic calculations and on-demand verification interactions, rather than caching the entire directory tree structure in local memory. In scenarios involving billions of files, this stateless or weakly stateful design significantly reduces client memory resource consumption, resulting in better scalability as the number of clients and files increases. Attached Figure Description

[0050] Figure 1 This is a structural diagram of the distributed file storage metadata service system in an embodiment of the present invention.

[0051] Figure 2 This is a schematic diagram illustrating the metadata storage principle in an embodiment of the present invention.

[0052] Figure 3 for Figure 2 File ID generation and distribution diagram.

[0053] Figure 4 To Figure 3 Directory tree diagram of the renamed files in the metadata.

[0054] Figure 5 This is a graph of metadata file name duplication nodes in an embodiment of the present invention. Detailed Implementation

[0055] To illustrate the technical content, structural features, objectives, and effects of the present invention in detail, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0056] This embodiment discloses a distributed file storage metadata service method for use in metadata access services of distributed file storage systems.

[0057] In simple terms, distributed file storage is a data storage technology that divides file data into multiple parts and stores them on multiple computers (nodes) connected by a network. To the user, it appears as a unified, massive hard drive, with a core management system that records the file's metadata (such as filename, directory structure, and the location of each data block).

[0058] First, such as Figure 1 In this embodiment, the management system for managing metadata includes a server and a client, wherein the server includes a root service module (RS) and a metadata service (MS) node.

[0059] As the centralized coordinating node of the interconnected system, the Resource Server (RS) is primarily responsible for handling global transaction coordination. In addition, the RS is also responsible for lightweight permission management, such as granting access permissions to directory tree nodes to clients. Because the RS only needs to maintain a lightweight directory tree (containing only permission information, not full metadata) and a conflict table, its data can reside entirely in memory, ensuring extremely high processing efficiency.

[0060] MS (Multi-Instance Manager) is a lightweight metadata service node responsible for persistent storage and read / write services of metadata. In this embodiment, MS does not rely on traditional file systems or databases to manage metadata, but is directly built on key-value solid-state drives (KV SSDs) that support key-value command sets. MSs form a cluster using a consistent hashing algorithm, achieving global load balancing of metadata. The core function of MS is to translate the upper-layer metadata access semantics into lower-layer key-value KV commands and interact directly with the KV SSDs, thereby eliminating redundant overhead in traditional storage paths.

[0061] The client is typically deployed as a private client within a general-purpose file storage gateway. Its main responsibilities include metadata indexing, initiating metadata access requests, and handling some distributed transactions in a distributed environment (such as transactions when creating child nodes). Through interaction with the MS and RS, the client achieves the ability to efficiently locate metadata without caching the entire directory tree locally.

[0062] For several metadata files, a consistent hashing algorithm is used to store them on different MSs, such as... Figure 2 For the six files A to F stored in the root directory, files A and D are stored on MS1, files B and E are stored on MS2, and files C and F are stored on MS3.

[0063] When a client wants to access a metadata file, such as file B, it needs to first find that file B is located on MS2 before it can access it.

[0064] The metadata service method in this embodiment will now be described in detail from the perspective of the server. The service method includes the following steps:

[0065] S10: Receive metadata access requests using the user-space protocol stack, convert them into KV instructions, and execute them on the KVSSD.

[0066] Unlike the traditional method of handling I / O requests through the operating system kernel, this embodiment uses the Storage High Performance Development Kit (SPDK) technology, which enables network requests and disk I / O operations to be completed in user space, thereby bypassing the operating system kernel and avoiding the CPU overhead caused by context switching and data copying.

[0067] After receiving a metadata access request (such as reading file attributes, listing directory entries, etc.), the server directly converts it into key-value pair command set (KVCommandsSet) instructions (such as Put, Get, Delete, Iterator, etc.) that conform to the NVMe 2.0 protocol family specification.

[0068] The converted KV instructions are directly sent to the KVSSD for execution. Since KVSSD supports direct mapping of physical addresses via keys, it eliminates the logical block address translation process of the flash translation layer (FTL) in traditional SSDs, significantly improving transactions per second (TPS) and reducing latency.

[0069] The KVSSD maintains a first type of key-value pairs and a second type of key-value pairs.

[0070] For the first type of key-value pairs, the file ID combined with the attribute identifier is used as the key, and the corresponding metadata attribute value is used as the value. The file ID is calculated based on the file's original identity information. This original identity information includes at least the path information and filename at the time of file creation.

[0071] The file ID is generated by a hash function based on the file's original identity information. This means that once a file is created, its ID, generated based on its birth information, remains unchanged regardless of how its path changes (renamed or moved) afterward.

[0072] The first type of key-value pairs stores the actual metadata content of the file system and is the main object for read and write operations.

[0073] Specifically, since the server contains multiple metadata service nodes, a consistent hashing algorithm is used to construct a distributed hash table, and the first type of key-value pairs are distributed and stored on different metadata service nodes through the distributed hash table.

[0074] The second type of key-value pair uses the current path of the file as the key and the original identity information of the file as the value.

[0075] S11: The access request includes a candidate file ID calculated based on the current path of the target file.

[0076] In response to the access request, if no corresponding first type key-value pair is found based on the candidate file ID, then the current path of the target file is used as the key to retrieve the second type key-value pair to obtain the original identity information, and the real file ID is determined accordingly, and corresponding operations are performed on the first type key-value pair.

[0077] Specifically, the request received by the server typically contains a "candidate file ID" (i.e., a predicted ID) calculated by the client based on the current path. The server first attempts to retrieve the first type of key-value pairs in KVSSD that are prefixed with this "candidate file ID".

[0078] If the retrieval is successful, it means that the file has not been modified since its creation. Directly perform read or write operations on the first type of key-value pairs and return the results.

[0079] If no corresponding first-type key-value pair is found based on the "candidate file ID", it indicates that the file has been modified after its creation (for example, the client is unaware that the file has been renamed and still uses the old path to calculate the ID; or a hash collision has occurred, causing the predicted ID to mismatch). The server will then initiate an error correction mechanism:

[0080] Use the current path in the access request as the key to retrieve the second type of key-value pairs in KVSSD.

[0081] If the search finds a match, the server will retrieve the original identity information stored in Value. Using this original identity information, it will recalculate the file's unique and true file ID on the storage medium.

[0082] Based on the determined real file ID, the server locates the corresponding first type of key-value pair again and performs the corresponding metadata operations.

[0083] Therefore, the service method in this embodiment first skips the file system layer and block device layer of the operating system kernel, and interacts with the hardware directly in key-value (KV) form. This eliminates the metadata overhead and hierarchy conversion latency of traditional file systems, significantly shortens the I / O path, and thus greatly improves the throughput of metadata access and reduces latency.

[0084] Secondly, the file's metadata attributes are stored in the first type of key-value pairs, whose keys are generated based on the original identity information (path and filename at creation time), which means that once the file is created, its physical storage location is fixed.

[0085] When a file is renamed or moved (the current path changes), the system only needs to update the second type of key-value pairs (establishing a mapping from the new path to the original identity information), without migrating or modifying the larger first type of key-value pairs (the actual metadata). This greatly reduces write amplification and processing overhead for the file system when handling renaming operations.

[0086] Next, we will describe this metadata service method from the client's perspective. The specific process is as follows:

[0087] S20: Based on the current path of the target file to be accessed, generate a predicted file ID using a preset hash algorithm.

[0088] When a client needs to access a target file (or directory) in a distributed file storage system, it first obtains the current path information of the target file.

[0089] This current path information is the path provided when the application layer initiates an access request. For example, a user requests access to a file at the path / data / project / file_A.

[0090] This path information is known at the application layer and is stored in the application layer's memory cache. It's important to note that cached paths and cached metadata are not the same thing, nor are they on the same scale. Cacheing the paths of millions of files, even if all millions of files are cached using the least efficient absolute path (4096 characters), would only occupy a maximum of 1GB of memory. Even caching hundreds of millions of files would only occupy 100GB of memory, which is minimal for applications such as AI computing.

[0091] The term "predictive" is used because in a distributed file system, a file's physical storage ID is typically generated based on its "birth path" at creation time and remains unchanged. However, the file's current path may change due to renaming or moving operations. Therefore, the ID calculated based on the current path may match the actual storage ID (if the path hasn't changed) or it may not match (if the path has changed).

[0092] S21: Based on the predicted file ID, the client initiates a metadata access request to the server. Simultaneously, the client initiates a path verification request to the server. This verification request explicitly carries the current path information of the target file.

[0093] Specifically, the method by which the client initiates a path verification request to the server includes:

[0094] A search request is sent to the server, the search request containing the current parent node ID and current file name of the target file, in order to request the server to retrieve the corresponding original identity information in the second type of key-value pairs.

[0095] The purpose of this step is to allow the server to verify whether the path has been changed using the second type of key-value pairs (path mapping relationship) while attempting to retrieve metadata.

[0096] S22: When the server processes the above request, if it finds that the corresponding metadata cannot be retrieved based on the predicted file ID (for example, the ID does not exist in the system, or the server finds that the current path does not match the ID), the server will return a "metadata does not exist" or similar failure response.

[0097] At this point, the client will receive the error correction data returned by the server in response to the path verification request, which is the original identity information.

[0098] This situation typically occurs when the target file (or its parent directory) has been renamed or moved. For example, a file originally named / data / old / file_A was later renamed / data / project / file_A. The ID calculated by the client using the new path cannot find a corresponding metadata entity in the system.

[0099] The server retrieves the original identity information corresponding to the current path by searching its internally maintained path mapping table (type II key-value pairs) and returns it to the client. The original identity information includes at least the path information and filename of the target file when it was created (i.e., the file's "birth address").

[0100] S23: After receiving the original identity information returned by the server, the client uses this information to perform secondary parsing of the ID:

[0101] The client uses the aforementioned preset hash algorithm again, but this time the input is no longer the current path, but the original identity information returned by the server (i.e., the path at the time of creation).

[0102] Through this calculation, the client generates the true file ID of the target file. Because the system design ensures that the file ID is generated based on creation information and remains unchanged throughout its lifespan, this recalculated ID is a unique and correct physical index of the file in the storage system.

[0103] S24: After determining the actual file ID, the client performs the final access steps:

[0104] The client initiates another request: Based on this real file ID, the client sends another metadata access request to the server.

[0105] Access successful: Since the ID used at this time is calculated based on the original creation information, the server can accurately locate the metadata in the first type of key-value pairs and return it to the client, thus completing the access to the target file.

[0106] Therefore, it can be seen that the client uses a hash algorithm to directly generate a "predicted file ID" based on the current path, without having to query the parent directory metadata layer by layer as in traditional file systems (i.e., without having to perform multiple network interactions), thus reducing the access complexity from a linear level of directory depth.

[0107] When the metadata corresponding to the predicted ID does not exist, the client receives the original identity information returned by the server and recalculates the real file ID for a second access. This means that regardless of changes in the file path, the client only needs at most two interactions to locate the metadata. This deterministic access mode eliminates performance fluctuations (glitch) caused by cache misses or different path depths, ensuring the stability of system performance.

[0108] Secondly, client-side path resolution relies on algorithmic calculations and on-demand verification interactions, rather than caching the entire directory tree structure in local memory. When dealing with massive scenarios involving billions of files, this stateless or weakly stateful design significantly reduces client-side memory consumption, resulting in better scalability as the number of clients and files increases.

[0109] Furthermore, by including the current path information for verification when initiating access requests, the system can detect whether the predicted ID has expired in real time. If it expires, the server uses the original identity information provided by the second type of key-value pair as an "error correction code" and returns it to the client, ensuring that the client can calculate a unique and genuine file ID. This closed-loop verification and correction mechanism guarantees that even if path changes occur in a distributed environment, metadata access remains accurate and reliable.

[0110] On the other hand, the original identity information includes: the parent node ID at the time of file creation, the absolute path at the time of file creation, and an adjustment factor that is a constant. The file ID is a unique identifier calculated by a hash function using the parent node ID, the absolute path, and the adjustment factor.

[0111] In this embodiment, the file ID is generated based on the following function f:

[0112] f(pid,path,mix=ID);

[0113] Where pid is the parent node ID, path is the absolute path when the file is created, and mix is ​​the adjustment factor.

[0114] The parent node ID is a unique identifier for the parent directory where the file to be created resides. Since the parent directory already exists before the file is created, its ID is fixed. Introducing the parent node ID as a hash input allows for initial isolation of the file ID namespace through directory hierarchy, reducing the probability of global collisions.

[0115] The absolute path (Path) when a file is created refers to the complete path string of the file at the time of creation (e.g., / data / project / config.xml) or the filename string in the parent directory.

[0116] It's important to note that the "absolute path" here specifically refers to the snapshot at the time of creation. Even if the file is subsequently renamed or moved, this path parameter used to generate the ID will remain the value it was at creation and will not change. This ensures the constancy of the file ID.

[0117] The adjustment factor (mix), which takes a constant value, is a numerical variable used for hash collision resolution.

[0118] When first attempting to generate a file ID, this adjustment factor is set to a default constant (e.g., 0 or 0x00).

[0119] When different files generate the same file ID due to hash collisions, the result of the hash calculation can be completely changed by changing the value of this adjustment factor, thereby generating a new file ID.

[0120] On the other hand, the method for retrieving the second type of key-value pairs using the current path as the key to obtain the original identity information, and determining the real file ID accordingly, includes:

[0121] Parse the parent node ID, absolute path, and adjustment factor of the file when it was created from the Value of the retrieved second type of key-value pair, and recalculate the actual file ID using the hash function f based on the parsed information.

[0122] On the other hand, the methods for the server to handle path verification requests from the client include:

[0123] Receive a path verification request for a target file sent by the client, the path verification request carrying the current path of the target file;

[0124] Based on the current path, search the KVSSD to see if a second type of key-value pair exists;

[0125] If a corresponding second type of key-value pair is found, the original identity information stored in the second type of key-value pair is returned to the client so that the client can correct the calculation result of the file ID of the target file based on the original identity information;

[0126] Additionally, if the corresponding second type key-value pair is not found in the KVSSD based on the current path in the path verification request, a response message indicating that the path is valid is returned to the client to indicate that the client confirms that the initially predicted file ID is correct.

[0127] In another embodiment, in a distributed file system, clients typically attempt to access a file by directly calculating its file ID based on its current path. However, when a file has been renamed, moved, or created using a non-zero mixing factor due to hash collisions, the directly calculated file ID will fail to locate the correct file. To address this issue, this embodiment introduces a second type of key-value pair as a "path correction" or "reverse mapping" mechanism.

[0128] That is, the second type of key-value pairs are generated when a renaming operation, a move operation, or a hash collision occurs during the creation of the target file.

[0129] Scenario 1: Renaming operation.

[0130] For example, a file originally named / A / B has its file ID generated based on this. When the user renames it to / A / X, the file ID remains unchanged. In this case, the system must record the mapping from / A / X to / A / B (i.e., the original identity information); otherwise, the ID calculated by the client for the new path will be incorrect.

[0131] Scenario 2: Mobile operation.

[0132] For example, a file is moved from / A / C to / B / C. The physical storage location and file ID remain the same, but the path has changed. The system needs to generate a mapping from the new path / B / C to the original identity information.

[0133] Scenario 3: A hash collision occurs during creation.

[0134] When a new file / A / B is created, the default calculated ID (mix=0) is already in use, forcing the system to use mix=1 to generate the final file ID. To ensure that subsequent clients know that the file uses mix=1 instead of the default 0, the system must record the mapping information of mix=1 for / A / B.

[0135] On the other hand, when any of the above-mentioned triggering events occur, the MS or RS responsible for handling the request will broadcast the generated second type of key-value pair to every MS in the cluster.

[0136] This means that each MS node in the cluster maintains a complete "special path mapping table". When a client sends a path verification request to any MS, the MS can quickly retrieve whether there is an error correction record for the path in its local KV storage without performing network forwarding.

[0137] This design greatly improves the speed of path resolution and avoids multiple network jumps during the error correction phase.

[0138] Furthermore, files may undergo multiple renamings or moves during their lifecycle. The system must ensure that the second type of key-value pairs always reflects the mapping from the "current latest path" to the "original identity".

[0139] Suppose the file has undergone the following changes: / path / v1 -> / path / v2 -> / path / v3.

[0140] The file ID is always determined by / path / v1 (the original identity).

[0141] When it becomes / path / v2, a key-value pair is generated: Key=" / path / v2", Value=" / path / v1".

[0142] When it changes back to / path / v3, the system performs a "replacement" operation:

[0143] Generate a new record: Construct a new key-value pair, Key=" / path / v3" (latest path), Value=" / path / v1" (always keep the original identity information unchanged).

[0144] At the same time, delete old key-value pairs (records with the key / path / v2) in all MS.

[0145] With this mechanism, no matter how many times the file path changes, the client only needs to look up the table once through the current path to directly obtain the original identity information of the file, and then calculate the correct file ID in one step, without the need for chain backtracking.

[0146] Below, we will use a comparative example to illustrate the working principle of the above metadata service method.

[0147] 1. In traditional distributed file systems, if clients do not have caches, accessing metadata for deeply nested directory files (e.g., / A / C / D) typically requires a step-by-step index lookup. For example... Figure 2 As shown, the process is as follows:

[0148] 1. Access the metadata of the root directory / to obtain the index of file A;

[0149] 2. Access the metadata of file A (located in MS1) and obtain the index of file C;

[0150] 3. Access the metadata of file C (located in MS3) and obtain the index of file D;

[0151] 4. Finally, access the metadata of file D (located in MS1).

[0152] This method requires N interactions with the server (N being the directory level), which is the main reason for the high latency in metadata access.

[0153] 2. This invention employs a "predictive parsing" approach, aiming to compress multiple interactions into a single one. Its core lies in the client using a consistent hashing algorithm and an ID generation function f to directly calculate the target file's ID, thereby locating and accessing its metadata service node (MS).

[0154] like Figure 3 Ideal access flow (taking access to / A / C / D as an example):

[0155] On the client side, calculate the ID of file A: f(0," / A",0)=1;

[0156] Calculate the ID of file C: f(1," / A / C",0)=3;

[0157] Calculate the ID of file D: f(3," / A / C / D",0)=4;

[0158] The client directly accesses the metadata of file ID 4 (i.e., directly accesses MS1).

[0159] With this mechanism, the client can complete path resolution and metadata access with only one interaction under ideal circumstances.

[0160] However, in practical engineering, file IDs are immutable once generated (based on their "birth information" at creation time). Client-based predictions based on the "current path" will fail under the following conditions:

[0161] Rename / Move: The directory tree structure changes, but the file IDs remain the same.

[0162] Hash collision: The file ID is created with the default mix=0, which causes a collision. The server uses a non-zero mix value (such as mix=1) to generate the ID.

[0163] like Figure 4If file C is renamed to X, its ID remains 3 (generated based on the original path / A / C). The client performs calculations based on the new path / A / X:

[0164] f(0," / A",0)=1;

[0165] f(1," / A / X",0)=11 (Error ID, should actually be 3);

[0166] f(11," / A / X / D",0)=12 (incorrect ID, should actually be 4); at this point, the client attempts to access the incorrect ID "12", but the corresponding ID "12" does not exist, resulting in access failure.

[0167] To address the aforementioned issues, this invention introduces an "error correction record" and a "parallel check" mechanism to ensure that access is completed within at most two interactions.

[0168] In other words, when a hash collision occurs during the renaming, moving, or creation of a node in the directory tree, the system broadcasts a special set of key-value pairs (KV) across all metadata service nodes (MS):

[0169] Key: The latest current path of the file (e.g., / A / X);

[0170] Value: Original identity triple <biological father ID, birth path, birth mix>;

[0171] For example, when / A / C is renamed to / A / X, all MS records are added: <" / A / X",<1," / A / C",0>>.

[0172] The access process is as follows:

[0173] Step 1: Initial ID Prediction and Parallel Check

[0174] The client performs an initial calculation based on the current path and initiates a parallel request:

[0175] Prediction calculation: Calculate the prediction ID "12" (based on / A / X / D).

[0176] Parallel requests:

[0177] Request A: Attempting to access metadata for ID 12.

[0178] Request B (Validity Check): Simultaneously send a path verification request to the relevant MS to confirm the validity of paths / A and / A / X.

[0179] Step Two: Server-side Retrieval and Feedback

[0180] MS searches locally for error correction records for the requested path:

[0181] If no record is found: Return "Path valid".

[0182] If there is a record (in this example): MS2 finds that / A / X has a mapping, and returns "path invalid" and the corresponding original identity triple <1," / A / C",0>.

[0183] Step 3: Client-side correction and secondary calculation

[0184] After receiving the failure feedback, the client uses the returned triples to correct the calculation parameters:

[0185] Parent node matching: Confirm that the parent ID "1" in the triplet matches the ID of / A.

[0186] Path replacement: Replace the current path / A / X with the birth path / A / C.

[0187] Mix replacement: If there are any changes to the mix, it will be replaced accordingly.

[0188] Cascade Correction: Based on the corrected file C (ID 3), recalculate the ID of the subsequent file D.

[0189] The corrected formula is: f(3," / A / C / D",0)=4;

[0190] Step 4: Second Visit

[0191] The client initiated a second access using the corrected ID "4" and successfully retrieved the metadata.

[0192] If a file undergoes multiple changes from / A / C -> / A / X -> / A / α, the system will generate a new key-value pair <" / A / α",<1," / A / C",0>> and replace the old key-value pair. The client always obtains the most original birth information directly through the latest path, without the need for chained backtracking.

[0193] If a conflict occurs when creating / A / C with mix=0, the system will use mix=1 to generate the ID. In this case, <" / A / C",<1," / A / C",1>> will be recorded. The client will initially fail to calculate using mix=0 by default; after checking, mix=1 will be used for correction.

[0194] like Figure 5 After renaming / A / C to / A / X, a new file named / A / C was recreated in the original location.

[0195] Old file record: <" / A / X",<1," / A / C",0>>;

[0196] New file record (assuming conflict): <" / A / C",<1," / A / C",1>>;

[0197] Both can coexist on MS without interfering with each other, and the client matches them separately based on the access path.

[0198] A move operation is equivalent to a path change. For example, moving / A / C to / A / B / F / C generates a record <" / A / B / F / C",<1," / A / C",0>>. The client then resolves the record by restoring the original path.

[0199] If files on multiple ancestor nodes along the path are modified, the client's checking mechanism will match the file record of the nearest modified ancestor node to the target file. By correcting the file ID at that node, the file IDs of subsequent child nodes can be correctly derived, following the same logic as for single-node file changes.

[0200] This solution achieves the following technical effects through a strategy of "secondary prediction and parsing, and parallel inspection and access":

[0201] Reduce latency: Compress the N rounds of serial access to N-level directories in the traditional no-caching mode into at most 2 rounds of parallel execution.

[0202] Stable performance: Access latency is reduced from linear to constant.

[0203] No caching dependency: The client does not need to consume memory to maintain a complex metadata cache, which can ensure high access performance and avoid the huge performance jitter caused by cache hits and misses in traditional solutions.

[0204] In another preferred embodiment of the present invention, a server and a client are also disclosed, which interact based on the distributed file storage metadata service method in the above embodiments.

[0205] This invention also discloses another metadata service system, which includes one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors. The programs include instructions for performing the metadata service method as described above. The processor may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, used to execute the relevant programs to implement the functions required by the modules in the metadata service system of this application embodiment, or to execute the metadata service method of the method embodiment of this application.

[0206] The present invention also discloses a computer-readable storage medium comprising a computer program executable by a processor to perform the metadata service method described above. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be read-only memory (ROM), random access memory (RAM), or magnetic media, such as floppy disks, hard disks, magnetic tapes, magnetic disks, or optical media, such as digital versatile discs (DVDs), or semiconductor media, such as solid-state disks (SSDs).

[0207] This application also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the aforementioned metadata service method.

[0208] The above-disclosed embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of the present invention. Therefore, any equivalent variations made in accordance with the claims of the present invention are still within the scope of the present invention.

Claims

1. A distributed file storage metadata service method, applied on the server side, characterized in that, include: The user-space protocol stack is used to receive metadata access requests, which are then converted into key-value pairs (KV) instructions and executed on the key-value pair solid-state drive (KV SSD). The KV SSD maintains a first type of key-value pairs and a second type of key-value pairs. The first type of key-value pair uses the file ID combined with the attribute identifier as the key and the corresponding metadata attribute value as the value; wherein, the file ID is calculated and generated based on the original identity information of the file; the original identity information includes at least the path information and file name when the file was created; The second type of key-value pair uses the current path of the file as the key and the original identity information of the file as the value. The access request includes a candidate file ID calculated based on the current path of the target file; In response to the access request, if no corresponding first type key-value pair is found based on the candidate file ID, then the current path of the target file is used as the key to retrieve the second type key-value pair to obtain the original identity information, and the real file ID is determined accordingly, and corresponding operations are performed on the first type key-value pair. The original identity information includes: the parent node ID when the file was created, the absolute path when the file was created, and an adjustment factor that is a constant; the file ID is a unique identifier calculated by a hash function using the parent node ID, the absolute path, and the adjustment factor.

2. The distributed file storage metadata service method according to claim 1, characterized in that, The method for retrieving the second type of key-value pairs using the current path as the key to obtain the original identity information and determining the real file ID accordingly includes: parsing the parent node ID, absolute path, and adjustment factor of the file when it was created from the value of the retrieved second type of key-value pairs, and recalculating the real file ID based on the parsed information using the hash function.

3. The distributed file storage metadata service method according to claim 1, characterized in that, The server includes multiple metadata service nodes; the method further includes: constructing a distributed hash table using a consistent hashing algorithm, and distributing and storing the first type of key-value pairs on different metadata service nodes through the distributed hash table.

4. The distributed file storage metadata service method according to claim 3, characterized in that, It also includes methods for handling path verification requests from clients: Receive a path verification request for a target file sent by the client, the path verification request carrying the current path of the target file; Based on the current path, search the KV SSD to see if a second type of key-value pair exists; If the second type of key-value pair is retrieved, the original identity information stored in the second type of key-value pair is returned to the client so that the client can correct the calculation result of the file ID of the target file based on the original identity information.

5. The distributed file storage metadata service method according to claim 4, characterized in that, The second type of key-value pairs are generated when a renaming operation, a move operation, or a hash collision occurs during the creation of the target file.

6. The distributed file storage metadata service method according to claim 5, characterized in that, When a renaming operation, a move operation, or a hash collision occurs during the creation of any of the target files is detected, a corresponding second type of key-value pair is generated in each of the metadata service nodes.

7. The distributed file storage metadata service method according to claim 5, characterized in that, When multiple renaming or moving operations are detected on the target file, a new second-type key-value pair is generated using the Key including the latest path and the Value including the original identity information, and the new second-type key-value pair replaces the old second-type key-value pair.

8. The distributed file storage metadata service method according to claim 4, characterized in that, If the corresponding second type of key-value pair is not found in the KV SSD according to the current path in the path verification request, a response message indicating that the path is valid is returned to the client to indicate that the client confirms that the file ID predicted in the initial test is correct.

9. A distributed file storage metadata service method, applied to a client, characterized in that, include: Based on the current path information of the target file to be accessed, a predicted file ID of the target file is generated using a preset hash algorithm; Based on the predicted file ID, a metadata access request is initiated to the server, and a path verification request is also initiated to the server, the path verification request carrying the current path information; When the server returns a response that the metadata corresponding to the predicted file ID does not exist, the server receives the original identity information returned by the server in response to the path verification request. The original identity information includes the path information and file name when the target file was created. Using the original identity information, the hash algorithm is used again to generate the real file ID of the target file; Access the metadata of the target file based on the real file ID; The original identity information includes: the parent node ID when the file was created, the absolute path when the file was created, and an adjustment factor that is a constant. The file ID is a unique identifier calculated using a hash function based on the parent node ID, the absolute path, and the adjustment factor.

10. The distributed file storage metadata service method according to claim 9, characterized in that, The method for generating the predicted file ID of the target file using a preset hash algorithm includes: Obtain the current parent node ID and current filename of the target file; The predicted file ID is calculated using the current parent node ID, the current file name, and the preset default adjustment factor as input parameters and the preset hash algorithm.

11. The distributed file storage metadata service method according to claim 9, characterized in that, The methods for initiating a path verification request to the server include: A search request is sent to the server, the search request containing the current parent node ID and current file name of the target file, in order to request the server to retrieve the corresponding original identity information in the second type of key-value pairs.

12. A server, characterized in that, The server provides services to the client based on the distributed file storage metadata service method according to any one of claims 1 to 8.

13. A client application, characterized in that, The client exchanges metadata with the server based on the distributed file storage metadata service method according to any one of claims 9 to 11.

14. A distributed file storage metadata service system, characterized in that, include: One or more processors; Memory; And one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the programs including instructions for performing the distributed file storage metadata service method as claimed in any one of claims 1 to 8 or the distributed file storage metadata service method as claimed in any one of claims 9 to 11.

15. A computer-readable storage medium, characterized in that, Includes a computer program that can be executed by a processor to perform the distributed file storage metadata service method as described in any one of claims 1 to 8 or the distributed file storage metadata service method as described in any one of claims 9 to 11.

16. A computer program product comprising a computer program that, when executed by a processor, implements the distributed file storage metadata service method as described in any one of claims 1 to 8 or the distributed file storage metadata service method as described in any one of claims 9 to 11.

Images