Access method in distributed file system, computing equipment and file access equipment

Abstract

The embodiment of the invention discloses an access method in a distributed file system, computing equipment and file access equipment. The method is applied to a first metadata node, the first metadata node belongs to the multiple metadata nodes, the same directory information is stored in each metadata node in the multiple metadata nodes, and the directory information is used for storing directory metadata of the distributed file system. The method comprises the following steps: receiving a first access request from a client, wherein the first access request comprises an object path to be accessed; determining first file fragment information corresponding to first metadata according to the directory information and the to-be-accessed object path; determining an operation result corresponding to the first metadata according to the first file fragment information and the fragment routing information of the first metadata node; and sending the operation result to the client.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an access method and computing device in a distributed file system, as well as a file access device. Background Art

[0002] In a data-centric file system architecture, the amount of data continues to expand, resulting in the continuous expansion of the file system size. This makes metadata management of large-scale file systems extremely complex.

[0003] Current distributed file systems manage metadata in a variety of ways. For example, a single physical node maintains file metadata. This single physical node stores large amounts of metadata, but suffers from the problem that a single node cannot store and manage large amounts of metadata.

[0004] There is currently another way to manage metadata. For example, the metadata of a file can be broken up into multiple shards, and these shards are distributed to multiple physical machine nodes. Specifically, a distributed file system stores the metadata of a directory in the distributed file system on a physical machine node through hash calculation, thereby storing and managing the metadata of directories and files in the distributed file system.

[0005] In the above-mentioned method for managing file metadata, it is necessary to perform layer-by-layer resolution according to the physical machine nodes distributed by the path to the intermediate directory entries, which results in the overhead of distributed path resolution. Therefore, the above-mentioned technical solution reduces the access performance of the distributed file system. Summary of the Invention

[0006] The present application provides an access method, computing device, and file access device in a distributed file system, which are used to reduce the overhead of distributed path resolution and improve the access performance of the distributed file system. In addition, the present application also provides a computer-readable storage medium and a computer program product corresponding to the above method.

[0007] To solve the above technical problems, the embodiments of the present application provide the following technical solutions:

[0008] In a first aspect, an embodiment of the present application provides an access method in a distributed file system, the method being applied to a first metadata node in the distributed file system, the distributed file system including multiple metadata nodes, the first metadata node belonging to the multiple metadata nodes, each of the multiple metadata nodes storing the same directory information, the directory information being used to store directory metadata of the distributed file system;

[0009] The method includes: receiving a first access request from a client, the first access request including an object path to be accessed; determining first file shard information corresponding to first metadata based on the directory information and the object path to be accessed; determining an operation result corresponding to the first metadata based on the first file shard information and shard routing information of the first metadata node; and sending the operation result to the client.

[0010] In the above technical solution, since each of the multiple metadata nodes stores the same directory information, the client can initiate access to any metadata node among the multiple metadata nodes. The first metadata node among the multiple metadata nodes can determine the first file shard information based on the stored directory information, and can feedback the operation results to the client. Therefore, the metadata operation can complete the access to the meta-object between the first metadata node and the client, without the need for layer-by-layer path resolution, reducing the overhead of distributed path resolution and improving the access performance of the distributed file system.

[0011] In a possible implementation of the first aspect, the operation result corresponding to the first metadata is determined based on the first file shard information and the shard routing information of the first metadata node, including: determining that the metadata node storing the first metadata is the second metadata node among the multiple metadata nodes based on the first file shard information and the shard routing information of the first metadata node; sending a second access request to the second metadata node, in which the index shard and metadata shard corresponding to the first metadata are stored; and receiving the operation result of the second metadata node operating on the metadata shard based on the index shard. In the above technical solution, high concurrency throughput across metadata nodes is provided by a large number of index shards, and each metadata node can create multiple metadata shards and index shards, thereby providing high concurrency within a single metadata node.

[0012] In a possible implementation of the first aspect, the operation result corresponding to the first metadata is determined based on the first file shard information and the shard routing information of the first metadata node, including: determining that the metadata node storing the first metadata is the first metadata node and the index shard of the first metadata in the first metadata node based on the first file shard information and the shard routing information of the first metadata node; searching for the metadata shard corresponding to the first metadata based on the index shard; operating on the metadata shard corresponding to the first metadata, and generating the operation result. In the above technical solution, high concurrency throughput within the metadata node is provided by a large number of index shards. Each metadata node can create many metadata shards and index shards, thereby providing high concurrency within a single metadata node.

[0013] In a possible implementation of the first aspect, operating the metadata shard corresponding to the first metadata includes: determining an operation type corresponding to the first metadata based on the first access request; performing a locking operation on the parent directory corresponding to the first metadata based on the operation type; and performing an operation on the metadata shard after the parent directory has been locked based on the operation type. In the above technical solution, the locking operation can ensure metadata consistency under high concurrency.

[0014] In a possible implementation of the first aspect, the locking operation is performed on the parent directory corresponding to the first metadata according to the operation type corresponding to the first metadata, including: when the operation type includes at least one of the following: write operation, update operation, and delete operation, adding a mutual exclusion lock to the parent directory; when the operation type includes a read operation, adding a shared lock to the parent directory. In the above technical solution, when the operation to be performed on the metadata is a write operation, an update operation, or a delete operation, it is necessary to add a mutual exclusion lock to the parent directory corresponding to the metadata shard, so as to avoid other metadata nodes from performing read and write operations at the same time; when the operation to be performed on the metadata is a read operation, it is necessary to add a shared lock to the parent directory corresponding to the metadata shard, so as to avoid other metadata nodes from performing modification operations at the same time. Through the locking operation, the consistency of metadata data can be guaranteed under high concurrency.

[0015] In a possible implementation of the first aspect, the first file shard information corresponding to the first metadata is determined based on the directory information and the object path to be accessed, including: determining the parent directory identifier of the object path and the object name of the first metadata from the directory information based on the object path to be accessed; generating a distribution column combination identifier based on the parent directory identifier and the object name of the first metadata, the first file shard information including: the distribution column combination identifier, the distribution column combination identifier including: the combination result of the mapping value of the parent directory identifier and the object name. In the above technical solution, the embodiment of the present application does not adopt the mapping method of the parent directory identifier, but combines the mapping value of the parent directory identifier and the object name of the first metadata and then maps them, thereby solving the problem of uneven distribution of metadata load across nodes, supporting fine-grained metadata distribution balancing capabilities, providing fine-grained distributed file system file / directory metadata distribution, and avoiding the decrease in metadata operation throughput caused by hot spots.

[0016] In a possible implementation of the first aspect, the determining of the first file shard information corresponding to the first metadata based on the directory information and the object path to be accessed includes: determining that the lock added to the directory information has been released; and determining the first file shard information corresponding to the first metadata based on the directory information after the lock is released and the object path to be accessed. In the above technical solution, the first metadata node needs to determine that the lock added to the directory information has been released to determine whether the directory information can continue to be read. After determining that the lock has been released, the first metadata node determines the first file shard information corresponding to the first metadata based on the directory information after the lock is released and the object path to be accessed. By releasing the lock, it can be ensured that the metadata node can use the directory information normally.

[0017] In a possible implementation of the first aspect, determining the first file shard information corresponding to the first metadata based on the directory information and the path of the object to be accessed includes: obtaining a shared memory flag for the directory information; adding a shared lock to the directory information when the shared memory flag indicates that a lock is required; and determining the first file shard information corresponding to the first metadata based on the directory information after the lock is added and the path of the object to be accessed. In the above technical solution, before performing a structural permission change operation on the directory information, a shared memory flag (Fast-path to false) can be set. When the shared memory flag is set to false, a shared lock on the directory information needs to be added during the path resolution process to prevent other metadata nodes from performing modification operations at the same time.

[0018] In a possible implementation of the first aspect, the distributed file system further includes: a coordinating node storing the directory information; the method further includes: receiving a directory update command from the coordinating node, the directory update command indicating updated directory information; performing a locking operation and a directory update operation on the directory information of the first metadata node according to the directory update command; and storing the updated directory information. In the above technical solution, in the embodiment of the present application, performing a directory update operation can resolve conflicts with transactions on a single metadata node through distributed locks.

[0019] In a possible implementation of the first aspect, the distributed file system further includes: a directory storage node, the directory storage node being used to synchronize directory information in the multiple metadata nodes; the method further includes: when the first metadata node does not store the directory metadata corresponding to the object path, sending a directory request to the directory storage node; receiving directory information sent from the directory storage node; and storing the received directory information. In the above technical solution, to avoid redundant storage overhead of a large amount of directory information, the distributed file system provided in the embodiment of the present application may further include a directory storage node, and the redundant storage overhead is alleviated by the directory storage node.

[0020] In a second aspect, an embodiment of the present application further provides a file access method in a distributed file system, the method being applied to a coordination node in the distributed file system, wherein the distributed file system further includes a plurality of metadata nodes;

[0021] The method includes: receiving a directory creation request from a client; generating directory information based on the directory creation request, wherein the directory information is used to store directory metadata of the distributed file system; and sending the directory information to the multiple metadata nodes via a distributed transaction. In the above technical solution, the embodiment of the present application uses a coordinating node to enable each of the multiple metadata nodes in the distributed file system to store the same directory information, so that each metadata node can respond to the client's access request and complete the client's operation on the metadata.

[0022] In a possible implementation of the first aspect, the method further includes: receiving a directory update request from the client; performing a directory update operation on the directory information according to the directory update request to generate a directory update command, wherein the directory update command indicates the updated directory information; and sending the directory update command to the multiple metadata nodes in a distributed transaction. In the above technical solution, after the first metadata node receives the directory update operation from the coordination node, it can lock the directory information, and after locking, perform the directory update operation according to the directory update command. In the embodiment of the present application, the coordination node can play the role of timely updating the directory, so that the metadata nodes in the distributed file system can obtain the latest directory information.

[0023] In a possible implementation of the first aspect, the distributed file system further includes: a directory storage node, the directory storage node being used for synchronizing the directory information in the multiple metadata nodes; the method further includes: receiving a directory update request from the client; performing a directory update operation on the directory information according to the directory update request, generating a directory update command, the directory update command indicating the updated directory information; and sending the directory update command to the directory storage node. In the above technical solution, after the directory storage node receives the directory update operation from the coordination node, it can perform an update operation on the directory information. In the embodiment of the present application, the coordination node can play the role of timely updating the directory, so that the directory storage node in the distributed file system can obtain the latest directory information.

[0024] In a third aspect, an embodiment of the present application further provides a file access method in a distributed file system, the method being applied to a directory storage node in the distributed file system, the distributed file system further comprising a plurality of metadata nodes, the directory storage node being used to synchronize directory information in the plurality of metadata nodes;

[0025] The method includes: receiving a directory request from a first metadata node, the first metadata node being one of the plurality of metadata nodes; obtaining directory information based on the directory request; and sending the directory information to the first metadata node. In the above technical solution, the directory storage node may send the directory information to the first metadata node. The first metadata node receives the directory information from the directory storage node and stores the received directory information in the first metadata node for use in path queries when a subsequent access request is received.

[0026] In a possible implementation of the first aspect, the distributed file system further includes: a coordination node, in which the directory information is stored; the method further includes: receiving a directory update command from the coordination node, wherein the directory update command indicates the updated directory information; performing a locking operation and a directory update operation on the directory information according to the directory update command; and storing the updated directory information. In the above technical solution, after the directory storage node receives the directory update operation from the coordination node, it can update the directory information. In the embodiment of the present application, the coordination node can play a role in timely updating the directory information, so that the directory storage node in the distributed file system can obtain the latest directory information.

[0027] In a fourth aspect, an embodiment of the present application further provides a file access device, wherein the file access device is specifically a first metadata node in a distributed file system, the distributed file system includes multiple metadata nodes, the first metadata node belongs to the multiple metadata nodes, each of the multiple metadata nodes stores the same directory information, and the directory information is used to store directory metadata of the distributed file system;

[0028] The file access device comprises:

[0029] A receiving module, configured to receive a first access request from a client, wherein the first access request includes a path of an object to be accessed;

[0030] A fragment determination module, configured to determine first file fragment information corresponding to the first metadata according to the directory information and the path of the object to be accessed;

[0031] an acquisition module, configured to determine an operation result corresponding to the first metadata according to the first file shard information and the shard routing information of the first metadata node;

[0032] A sending module is used to send the operation result to the client.

[0033] In the fourth aspect of the present application, the constituent modules of the file access device may also execute the steps described in the aforementioned first aspect and various possible implementations. For details, please refer to the aforementioned description of the first aspect and various possible implementations.

[0034] In a fifth aspect, an embodiment of the present application further provides a file access device, wherein the file access device is specifically a coordination node in a distributed file system, and the distributed file system includes multiple metadata nodes;

[0035] The file access device comprises:

[0036] A receiving module, used for receiving a directory creation request from a client;

[0037] A generating module, configured to generate directory information according to the directory creation request, wherein the directory information is used to store directory metadata of the distributed file system;

[0038] A sending module is used to send the directory information to the multiple metadata nodes through a distributed transaction.

[0039] In the fifth aspect of the present application, the constituent modules of the file access device may also execute the steps described in the aforementioned second aspect and various possible implementations. For details, please refer to the aforementioned description of the second aspect and various possible implementations.

[0040] In a sixth aspect, an embodiment of the present application further provides a file access device, wherein the file access device is specifically a directory storage node in a distributed file system, wherein the distributed file system further includes a plurality of metadata nodes, and the directory storage node is used to synchronize directory information in the plurality of metadata nodes;

[0041] The file access device comprises:

[0042] a receiving module, configured to receive a directory request sent by a first metadata node, where the first metadata node belongs to the plurality of metadata nodes;

[0043] An acquisition module, configured to acquire directory information according to the directory request;

[0044] A sending module is used to send the directory information to the first metadata node.

[0045] In the sixth aspect of the present application, the constituent modules of the file access device may also execute the steps described in the aforementioned third aspect and various possible implementations. For details, please refer to the aforementioned description of the third aspect and various possible implementations.

[0046] In a seventh aspect, an embodiment of the present application provides a computer-readable storage medium, wherein instructions are stored in the computer-readable storage medium, which, when executed on a computer, enables the computer to execute the method described in the first aspect, the second aspect, or the third aspect above.

[0047] In an eighth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the method described in the first, second or third aspect above.

[0048] In the ninth aspect, an embodiment of the present application provides a communication device, which may include a terminal device, or a computing device, or a file access device or a chip and other entities, and the communication device includes: a processor, a memory; the memory is used to store instructions; the processor is used to execute the instructions in the memory, so that the communication device performs the method as described in any one of the first aspect, second aspect or third aspect above.

[0049] In a tenth aspect, the present application provides a chip system, which includes a processor for supporting a terminal device, a computing device, or a file access device to implement the functions involved in the above aspects, for example, sending or processing the data and / or information involved in the above methods. In one possible design, the chip system also includes a memory, which is used to store program instructions and data necessary for the terminal device. The chip system can be composed of a chip, or it can include a chip and other discrete devices.

[0050] In the eleventh aspect, an embodiment of the present application provides a chip comprising one or more interface circuits and one or more processors; the interface circuit is used to receive a signal from a memory of an electronic device and send a signal to the processor, the signal comprising a computer instruction stored in the memory; when the processor executes the computer instruction, the electronic device executes an access method in a distributed file system in any possible implementation of the first aspect, the second aspect, or the third aspect.

[0051] The twelfth aspect and any implementation of the twelfth aspect respectively correspond to any implementation of the first aspect, the second aspect, or the third aspect. The technical effects corresponding to any implementation of the twelfth aspect can be referred to the technical effects corresponding to any implementation of the first aspect, the second aspect, or the third aspect, and will not be repeated here.

[0052] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0053] In an embodiment of the present application, a distributed file system includes multiple metadata nodes, a first metadata node belongs to the multiple metadata nodes, and each of the multiple metadata nodes stores the same directory information, and the directory information is used to store the directory metadata of the distributed file system. The multiple metadata nodes can interact with the client. Taking the interaction process between the first metadata node and the client as an example, the client generates a first access request based on the path of the object to be accessed and sends the first access request to the distributed file system. The first metadata node receives the first access request from the client, and the first metadata node determines the first file shard information corresponding to the first metadata based on the directory information and the path of the object to be accessed. After determining the first file allocation information, the first metadata node determines the operation result corresponding to the first metadata based on the first file shard information and the shard routing information of the first metadata node. Finally, the first metadata node sends the operation result to the client to enable the client to access the distributed file system. In an embodiment of the present application, since each of the multiple metadata nodes stores the same directory information, the client can initiate access to any metadata node among the multiple metadata nodes. The first metadata node among the multiple metadata nodes can determine the first file shard information based on the stored directory information, and can feedback the operation results to the client. Therefore, the metadata operation can complete the access to the meta-object between the first metadata node and the client, without the need for layer-by-layer path resolution, reducing the overhead of distributed path resolution and improving the access performance of the distributed file system. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 A schematic diagram of a system framework for an access method applied in a distributed file system provided in an embodiment of the present application;

[0055] Figure 2 A schematic diagram of an application scenario of an access method in a distributed file system provided in an embodiment of the present application;

[0056] Figure 3 A schematic diagram of an application scenario of another access method in a distributed file system provided in an embodiment of the present application;

[0057] Figure 4 A schematic diagram of an implementation form of a metadata node in platform software and server hardware provided in an embodiment of the present application;

[0058] Figure 5 A schematic diagram of a system framework for a metadata node application provided in an embodiment of the present application;

[0059] Figure 6 A schematic diagram of a system framework for applying an access method in another distributed file system provided in an embodiment of the present application;

[0060] Figure 7 A schematic diagram of an implementation of a coordination node in platform software and server hardware provided in an embodiment of the present application;

[0061] Figure 8 A schematic diagram of a system framework for metadata node and coordination node applications provided in an embodiment of the present application;

[0062] Figure 9 A schematic diagram of a system framework for applying an access method in another distributed file system provided in an embodiment of the present application;

[0063] Figure 10 A schematic diagram of an implementation of a directory storage node in platform software and server hardware provided in an embodiment of the present application;

[0064] Figure 11 A schematic diagram of an interaction process between a first metadata node and a client provided in an embodiment of the present application;

[0065] Figure 12 A schematic diagram of the interaction process between a first metadata node and a client, and a second metadata node provided in an embodiment of the present application;

[0066] Figure 13 A schematic diagram of another interaction process between a first metadata node and a client provided in an embodiment of the present application;

[0067] Figure 14 A schematic flow chart of another access method in a distributed file system provided in an embodiment of the present application;

[0068] Figure 15 A schematic flow chart of another access method in a distributed file system provided in an embodiment of the present application;

[0069] Figure 16 A schematic diagram of the overall distribution scenario of distributed object metadata provided in an embodiment of the present application;

[0070] Figure 17 A schematic diagram of fine-grained metadata fragmentation into multiple metadata nodes provided in an embodiment of the present application;

[0071] Figure 18 Schematic diagram of the metadata access process provided in the embodiment of the present application;

[0072] Figure 19a A schematic diagram of concurrent processing of distributed metadata provided in an embodiment of the present application;

[0073] Figure 19b A schematic diagram of a directory storage node storing a directory provided in an embodiment of the present application;

[0074] Figure 20a A schematic diagram of a directory global consistency storage provided by an embodiment of the present application;

[0075] Figure 20b A schematic diagram of scalable directory metadata management provided by an embodiment of the present application;

[0076] Figure 21 A schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0077] Figure 22 A schematic diagram of the composition of another computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0078] The embodiments of the present application provide an access method, a computing device, and a file access device in a distributed file system, which are used to reduce the overhead of distributed path resolution and improve the access performance of the distributed file system.

[0079] The embodiments of the present application are described below with reference to the accompanying drawings.

[0080] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, and this is merely a way of distinguishing the objects of the same attributes when describing them in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0081] The embodiments of the present application relate to the technical field of computer distributed files and storage systems. In the era of data-centric architecture, the scale of data and clusters continues to expand, and the stored data is constantly doubling, resulting in the continuous expansion of the scale of files. This has brought great challenges to the metadata management of files at the scale of hundreds of billions of files. The current distributed file system uses a single physical machine node to maintain file directory metadata, such as the Hadoop Distributed File System (HDFS). In the current path resolution scheme, it is necessary to perform layer-by-layer resolution of the metadata nodes distributed according to the path to the intermediate directory items, which has the overhead of distributed path resolution, thereby reducing the access performance of the distributed file system.

[0082] The technical solutions of the embodiments of the present application can be applied to various distributed file systems, which can also be called distributed cache file systems. The distributed file systems can provide a data processing platform for implementing the access methods of the distributed file systems of the embodiments of the present application through the data processing platform. The specific forms of the distributed file systems and the corresponding data processing platforms are not limited herein.

[0083] like Figure 1 As shown, in embodiments of the present application, a client can interact with a distributed file system. For example, before accessing data, the client must first access the corresponding metadata. The client can send access requests, such as requesting to open a file or obtain file attributes. The distributed file system includes N metadata nodes, for example, the N metadata nodes can specifically include metadata nodes 1, ..., metadata nodes N. The metadata nodes in the distributed file system can respond to the client's access requests, perform metadata operations, and feedback the operation results to the client.

[0084] The client described above refers to the client side of the distributed software system, providing an input / output (I / O) read / write interface for applications. The client caches directory tree and routing table information. When a client submits a metadata access request, it uses the routing table information to route the metadata it needs to access and calculate the metadata node where the metadata resides. The client then sends the metadata access request to a metadata node.

[0085] Next, the client involved in the application embodiments is described. The client can be specifically a terminal, which can also be called a terminal device. The terminal device can include at least one of the following: user equipment (UE), mobile station (MS), mobile terminal (MT), terminal, terminal device, etc., which is a device that provides voice and / or data connectivity to a user, or a chip set in the device, such as a handheld device with wireless connection function, a vehicle-mounted device, etc. Currently, some examples of terminal devices include: mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, etc.

[0086] A metadata node can also be called a metadata engine node, or a distributed metadata engine. Each metadata node has distributed routing and distributed transaction management capabilities. A metadata node can store and manage metadata shards distributed to the metadata node. Each metadata node runs on a computer or virtual computer with complete computing, storage, and communication capabilities. For example, N metadata nodes can run on one or more computing devices. The type of any computing device is not limited here. For example, any computing device can be a terminal device, a server, a container, or a virtual machine.

[0087] In one example, N metadata nodes can run on one or more servers. The server includes a hardware layer and a software layer. The hardware layer includes the hardware configured on the server, and the software layer includes the operating system installed and running on the server. A distributed file system is configured with multiple servers, which can be used to run virtual machines. The specifications of each virtual machine can be the same or different. Among them, virtual machines can also be called cloud servers (elastic compute services, ECS), elastic instances, etc., and different cloud service providers may have different names.

[0088] like Figure 2 The figure shows an application scenario diagram of an access method in a distributed file system provided in an embodiment of the present application. The distributed file system provided in an embodiment of the present application can be specifically applied to the open source Alluxio. The Hadoop Distributed File System (HDFS) or cloud object storage (such as Object Storage Service (OBS) and Simple Storage Service (S3)) interacts with the client through the storage network access layer (HDFS / NAS / S3 interface).

[0089] There are many ways to implement the client. For example, the client may include: a central processing unit (CPU), a dynamic random access memory (DRAM), and a solid state disk (SSD). The transmission rate between the CPU and the DRAM can be 100GB / s. The client can send an access request to the distributed file system provided in the embodiment of the present application. The distributed file system may include the aforementioned multiple metadata nodes. The metadata node has distributed routing and distributed transaction management capabilities. The metadata node can store and manage metadata shards distributed to the metadata node, and the metadata node feeds back the operation results to the client. The embodiment of the present application can achieve efficient access to metadata shards in the distributed file system and provide high throughput, low latency, horizontally scalable and highly available metadata services, wherein the horizontally scalable metadata service refers to the throughput and capacity of the metadata server having the same changing trend as the number of metadata nodes.

[0090] like Figure 3As shown, it is a schematic diagram of an application scenario of an access method in another distributed file system provided in an embodiment of the present application. A data node can interact with a client, for example, the client can be a file system (FS) client. The client sends an access request to the distributed file system provided in an embodiment of the present application. The distributed file system may include the aforementioned multiple metadata nodes, which have distributed routing and distributed transaction management capabilities. The metadata node can store and manage metadata shards distributed to the metadata node, and the metadata node feeds back the operation results to the client. In the distributed file system, HDFS and CephFS provide distributed metadata services. For example, CephFS can implement a file system sharing function, and the client mounts through the Ceph file system protocol and uses the Ceph cluster as a data storage server. The embodiment of the present application can achieve efficient access to metadata shards in a distributed file system, and provide high throughput, low latency, horizontal scalability and high availability metadata services.

[0091] like Figure 4 The figure shows a schematic diagram of the implementation of a metadata node in platform software and server hardware according to an embodiment of the present application. The metadata node provided by the embodiment of the present application can be included in each metadata node instance in the distributed metadata engine. The metadata node can include directory metadata, a coordinator, and multiple local index shards.

[0092] In the embodiments of the present application, directory metadata is stored within a metadata node instance. The directory metadata is used for directory resolution locally on the metadata node. The directory metadata may specifically be a directory metadata table. For example, the directory metadata may include an inode ID, a parent directory ID, and an object name. The object may include directories and files.

[0093] The coordinator uses the transaction management module to manage the transaction consistency of the metadata node, uses the routing table to perform routing analysis on the metadata to be accessed, and sends it to the designated metadata node for corresponding operations.

[0094] The metadata node establishes an index shard, which is used for fast retrieval of metadata. The metadata node can be responsible for storing and managing the metadata shards distributed to the metadata node. The index shard establishes an index for the metadata of the metadata node, so that metadata retrieval can be performed quickly.

[0095] like Figure 5As shown in FIG. 1 , a schematic diagram of a system framework of a metadata node application provided in an embodiment of the present application is provided. The distributed file system includes N metadata nodes (meta data nodes), namely metadata node 1, metadata node 2, ..., metadata node N. The description of each metadata node can be found in Figure 4 The metadata node shown.

[0096] Figure 5 The client in the distributed file system provides an input / output read / write interface for applications, and caches directory trees and routing tables on the client.

[0097] Figure 5 Each metadata node in the system simultaneously manages and stores the metadata shards distributed to it. Through Multiversion Concurrency Control (MVCC) and Write-Ahead Log (WAL), transactions within a single metadata node are guaranteed to adhere to the ACID (atomicity, consistency, isolation, and durability) properties. The metadata node also indexes the metadata shards to support fast retrieval.

[0098] In embodiments of the present application, each metadata node may include a coordinator, which may also function as a coordinator node. For example, each metadata node may accept metadata access requests submitted by clients, acting as a coordinator. Each metadata node maintains an identical sharded distributed routing table (shard map), and distributed ACID can be supported through the metadata node and the transaction management module in the coordinator.

[0099] Based on the aforementioned Figure 5, the access method in the distributed file system provided in the embodiment of the present application is explained. Before the client in the distributed file system accesses data, it must first access the corresponding metadata service, such as opening a file, obtaining file attributes, etc. The performance of the metadata will affect the I / O performance of the entire distributed file system. The performance of the metadata may include: throughput and latency. The distributed file system stores directory metadata and file metadata in a table of a distributed database, and supports the expansion of horizontal capacity and throughput by sharding the table. Among them, file metadata may include index node (such as inode information) permissions, access time, etc. In addition, in the embodiment of the present application, by placing multiple metadata shards inside a physical machine, the lock synchronization overhead inside each index shard on a multi-core machine can be reduced.

[0100] The distributed file system provided in embodiments of the present application provides a distributed metadata engine with horizontally scalable throughput and capacity. Horizontally scalable throughput and capacity means that the throughput and capacity change in the same direction as the number of metadata nodes. That is, as the number of metadata nodes increases, the throughput and capacity of the distributed metadata engine also increase. Each metadata node runs on a computer or virtual computer with complete computing, storage, and communication capabilities, and can store and manage metadata shards distributed to it.

[0101] When a client submits a metadata access request, the client routes the metadata to be accessed through the cached routing table information and calculates the metadata node where the metadata is located. The client then sends the metadata access request to a metadata node. If the routing table cache is invalid or the metadata node where the metadata is located cannot be calculated, the client sends the metadata access request to any metadata node. At this time, the metadata node will act as a coordination node. Among them, the routing table cache failure can be eliminated when the client's cache space is insufficient. The client cannot calculate the metadata node where the metadata is located. This means that in a scenario with multiple clients, one client creates a new directory, and another client cannot calculate the metadata node where the metadata is located.

[0102] The metadata node receives the metadata access request from the client. The metadata node performs path resolution locally based on the transmission path and calculates the file shard information to be accessed. The metadata node then calculates the file shard location based on the shard routing information and the file shard information. The access is then routed to the metadata node where the metadata is located. The routed metadata node provides access services. Finally, the metadata node, acting as the coordinator, reads the operation results from the metadata node providing the access service and sends the operation results to the client. In addition, if the metadata node where the metadata shard to be accessed is located is the same as the coordinator node, the metadata node directly accesses the local metadata shard.

[0103] like Figure 6 FIG. 1 is a schematic diagram of a system framework for applying an access method in another distributed file system provided by an embodiment of the present application. The distributed file system includes N metadata nodes and coordination nodes. Figure 6 The example above uses a distributed file system including a single coordinating node. In practice, the number of coordinating nodes is not limited. Unlike the previous embodiment, the coordinating node is a separate node independent of the N metadata nodes. The coordinating node can interact with each of the N metadata nodes and the client.

[0104] Specifically, the coordination node can obtain the command to create or modify the directory from the client, generate a directory table based on the command, and distribute the directory table to N metadata nodes. When N metadata nodes are updated, the coordination node can update the shard distributed routing table (shard map) and then distribute it to each metadata node synchronously.

[0105] like Figure 7 As shown, it is a schematic diagram of an implementation form of a coordination node in platform software and server hardware provided by an embodiment of the present application. The coordination node may include directory metadata and a coordinator.

[0106] In the embodiment of the present application, directory metadata is stored within the instance of the coordination node. The directory metadata may specifically be a directory metadata table. For example, the directory metadata may include an index identifier (inode id), a parent directory identifier (id), and an object name. The object may include a directory and a file.

[0107] The coordinator uses the transaction management module to manage the transaction consistency of the coordination node, uses the routing table to perform routing analysis on the metadata to be accessed, and sends it to the designated metadata node for corresponding operations.

[0108] like Figure 8The figure shows a schematic diagram of a system framework of a metadata node and a coordination node application provided by an embodiment of the present application. The functions of the client and metadata node are the same as those described above. Figure 6 The coordinator node can interact with the client and N metadata nodes separately. For example, if the client initiates a distributed transaction operation, such as a directory operation or rename operation, the coordinator node can manage the distributed transaction through the coordinator.

[0109] In some embodiments of the present application, the distributed file system includes N metadata nodes and directory storage nodes. The number of directory storage nodes can be one or more, which is not limited here.

[0110] The Directory Storage Node provides directory storage functionality, serving directory queries to N metadata nodes. For example, a metadata node can autonomously eliminate directory cache entries. When a file is accessed and a directory cache miss is detected during path resolution on the metadata node, the metadata node reads the latest directory from the Directory Storage Node.

[0111] It is understandable that in other embodiments of the present application, in order to expand the throughput of the directory creation operation, the directory metadata hash can also be scattered to N metadata nodes, thereby avoiding the bottleneck of one directory storage node.

[0112] like Figure 9 Figure 2 shows a schematic diagram of a system framework for an access method in another distributed file system according to an embodiment of the present application. The distributed file system includes N metadata nodes, a coordination node, and a directory storage node. The directory storage node can interact with each of the N metadata nodes and the coordination node. The directory storage node can provide directory storage functionality to provide directory queries to the N metadata nodes.

[0113] See also Figure 10 Figure 1 shows a schematic diagram of an implementation of a directory storage node in platform software and server hardware according to an embodiment of the present application. The directory storage node includes a directory table and implements directory storage functions through an I / O interface. The directory storage node can provide directory queries to N metadata nodes.

[0114] The embodiments of the present application can achieve efficient access to metadata shards of distributed file system directory files, completely eliminate the overhead of distributed directory resolution, provide a fine-grained distribution method for distributed file system file or directory metadata, avoid the decrease in metadata operation throughput caused by hot spots, and at the same time, for large directories, provide cross-node concurrent reading of directories to achieve accelerated directory reading effect.

[0115] Next, some technical terms involved in the embodiments of this application are introduced.

[0116] Directory Information:

[0117] Each of the multiple metadata nodes in the distributed file system stores the same directory information. The directory information can specifically be a directory set or a directory table, etc., which is not limited here. The directory table can also be called a directory tree resolution replication table. Directory metadata is stored in the directory information. For example, the embodiment of the present application uses a directory table to store metadata used for path resolution in the distributed file system. For example, the directory metadata may include: globally unique directory ID, parent directory ID, directory name, permissions and other information. The directory table can be copied to all metadata nodes to ensure that the directory table on each metadata node in all metadata nodes is consistent, supporting low-overhead path resolution.

[0118] The directory metadata (such as size, modification time, etc.) of each directory in the directory information is stored in the index node (Inode) table. The directory information only maintains the information used for path resolution in the directory, and the Inode table maintains detailed metadata information in all directories and files.

[0119] Inode table:

[0120] The inode table, also known as the distributed inode table, can include shard routing information and is used to store metadata about objects in a distributed file system, such as directories and files. For example, an inode table represents a data structure that stores metadata about directories and files in a distributed file system. The inode table records metadata such as the file / directory name, file / directory size, modification and access time, and permissions.

[0121] Tuple:

[0122] A tuple refers to a row of records in the Inode table, that is, the metadata of an object.

[0123] File fragment information:

[0124] The file sharding information includes a distribution column combination identifier, which includes a combination of mapping values ​​of a parent directory identifier and an object name. Objects may include directories and files. For example, the distribution column combination identifier is specifically the parent directory ID_partID field.

[0125] The inode table records metadata for directories and files across the distributed file system, including unique inode IDs, names, parent directory IDs / partIDs, and permissions. The inode table hashes the parent directory ID and the file name's hash value to a local identifier (PartID) to obtain the parent directory ID / partID field. This field is then distributed across different metadata nodes.

[0126] Shard routing information:

[0127] Shard routing information is used to calculate the metadata shards to which object metadata is mapped. For example, the shard routing information can specifically be a shard distributed routing (Shard map) table. In this embodiment of the application, a Shard map table is maintained for each directory's Inode table to calculate the index shard to which a tuple (i.e., metadata for an object) is mapped. The Shard map table records the mapping relationship between non-overlapping hash values ​​(or hash ranges) and shard IDs.

[0128] Index shards and metadata shards:

[0129] Each metadata node simultaneously manages and stores metadata shards distributed to the metadata node. The metadata node also creates index shards for the metadata shards, and supports fast metadata shard retrieval through index shards.

[0130] Based on the system architecture of the distributed file system introduced above, an embodiment of the present application further provides an access method in a distributed file system. The access method in the distributed file system of the present application is introduced below from the perspective of the distributed file system.

[0131] See also Figure 11 The figure shows a schematic diagram of the interaction process between a first metadata node and a client provided in an embodiment of the present application. The distributed file system includes multiple metadata nodes, and the first metadata node belongs to multiple metadata nodes. Each of the multiple metadata nodes stores the same directory information, which is used to store directory metadata of the distributed file system. The access method in the distributed file system provided in an embodiment of the present application mainly includes the following steps:

[0132] 101. The client sends a first access request to the first metadata node.

[0133] The first access request includes a path of an object to be accessed.

[0134] Before accessing data, the client must first access the corresponding metadata. The client generates a first access request based on the path of the object that the user needs to access. The object may include directories and files. For example, the client routes the metadata to be accessed through cached routing table information, calculates that the metadata node where the metadata is located is the first metadata node, and then sends the first access request to the first metadata node. If the client's routing table cache fails or the metadata node where the metadata is located cannot be calculated, the client sends the first access request to the first metadata node among multiple metadata nodes.

[0135] 102. The first metadata node receives a first access request from a client.

[0136] The first access request includes a path of an object to be accessed.

[0137] The first metadata node can interact with the client. When the first metadata node receives the first access request, the first metadata node can perform path resolution on the object path to be accessed.

[0138] 103. The first metadata node determines first file fragment information corresponding to the first metadata according to the directory information and the path of the object to be accessed.

[0139] Among them, each metadata node in the multiple metadata nodes stores the same directory information, and the directory information is used to store the directory metadata of the distributed file system. For example, the directory information can specifically be a directory table. In the subsequent embodiments, the directory information is specifically a directory table for example.

[0140] The first metadata node obtains the object path from the first access request, and calculates the first file shard information based on the object path and directory information, wherein the metadata that the client needs to access is called the first metadata, the first metadata is the metadata to be accessed, and the first file shard information refers to the file shard information corresponding to the first metadata, and the first file shard information indicates the shard information storing the first metadata.

[0141] Specifically, the directory information includes directory metadata, as shown in Table 1 below, which is a composition structure table of the directory information:

[0142] Directory Name Catalog ID Parent directory ID Other metadata / 1 0 … a 2 1 … b 5 2 … e 3 2 … f 4 2 …

[0143] Based on the example of Table 1 above, it can be seen that the directory metadata may include: directory name, globally unique directory ID, parent directory ID, other metadata (such as permissions) and other information. The " / " in Table 1 represents the root directory, and a, b, e, and f represent specific directory names.

[0144] In some embodiments of the present application, if the metadata under each directory is hashed and distributed according to the parent directory identifier, there is a problem of uneven distribution of data load across nodes. In the embodiments of the present application, a method of combining the mapping value of the parent directory identifier and the object name can be used to achieve fine-grained metadata distribution balancing capabilities. Specifically, 103 the first metadata node determines the first file shard information corresponding to the first metadata based on the directory information and the object path to be accessed, including:

[0145] 1031. The first metadata node determines the parent directory identifier of the object path and the object name of the first metadata from the directory information according to the object path to be accessed.

[0146] The directory information includes the parent directory identifier and the object name.

[0147] 1032. The first metadata node generates a distribution column combination identifier based on the parent directory identifier and the object name of the first metadata. The first file shard information includes: the distribution column combination identifier, and the distribution column combination identifier includes: a combination result of the mapping value of the parent directory identifier and the object name.

[0148] Specifically, the first metadata node combines the mapping values ​​of the parent directory identifier and the object name of the first metadata to obtain a distribution column combination identifier. For example, the mapping value of the object name of the first metadata is obtained by hashing the object name of the first metadata. The embodiment of the present application does not adopt the mapping method of the parent directory identifier, but combines the mapping values ​​of the parent directory identifier and the object name of the first metadata and then maps them, thereby solving the problem of uneven distribution of metadata load across nodes, supporting fine-grained metadata distribution balancing capabilities, providing fine-grained distributed file system file / directory metadata distribution, and avoiding the reduction of metadata operation throughput caused by hot spots.

[0149] An example is given below. The first metadata node combines the parent directory ID and the local identifier PartID mapped to the file name hash to obtain a distribution column combination identifier, which is specifically the parent directory ID_partID field.

[0150] In some embodiments of the present application, 103 the first metadata node determines the first file shard information corresponding to the first metadata according to the directory information and the path of the object to be accessed, including:

[0151] 1033. The first metadata node determines that the lock added to the directory information has been released;

[0152] 1034. The first metadata node determines the first file shard information corresponding to the first metadata according to the directory information after the lock is released and the path of the object to be accessed.

[0153] In an embodiment of the present application, when a first metadata node uses directory information, if a metadata node other than the first metadata node among multiple metadata nodes has added a lock to the directory information, the first metadata node needs to determine whether the lock added to the directory information has been released to determine whether it can continue to read the directory information. After determining that the lock has been released, the first metadata node determines the first file shard information corresponding to the first metadata based on the directory information after the lock is released and the path of the object to be accessed. By releasing the lock, it is ensured that the metadata node can normally use the directory information.

[0154] In some embodiments of the present application, 103 the first metadata node determines the first file shard information corresponding to the first metadata according to the directory information and the path of the object to be accessed, including:

[0155] 1035. The first metadata node obtains a shared memory tag of the directory information.

[0156] 1036. When the shared memory flag indicates that locking is required, the first metadata node adds a shared lock to the directory information;

[0157] 1037. The first metadata node determines the first file shard information corresponding to the first metadata according to the directory information after the lock is added and the object path to be accessed.

[0158] In order to improve the performance of metadata operations in an embodiment of the present application, a shared memory flag (Fast-path to false) can be set before the structural permission change operation of the directory information is performed. When the shared memory flag is set to false (false), a shared lock of the directory information needs to be added during the path resolution process to prevent other metadata nodes from performing modification operations at the same time.

[0159] 104. The first metadata node determines an operation result corresponding to the first metadata based on the first file shard information and the shard routing information of the first metadata node.

[0160] In an embodiment of the present application, after the first metadata node determines the first file shard information, the first metadata node determines the metadata node where the metadata shard to be accessed is located based on the first file shard information and the shard routing information of the first metadata node, and obtains the operation result corresponding to the first metadata.

[0161] Among them, the shard routing information can specifically be a shard distributed routing (Shard map) table. The embodiment of the present application configures a Shard map table for the index node table of each directory. The Shard map table is used to calculate the index shard to which the tuple (that is, the metadata of an object) is mapped.

[0162] In some embodiments of the present application, Figure 12 As shown, 104, the first metadata node determines the operation result corresponding to the first metadata according to the first file shard information and the shard routing information of the first metadata node, including:

[0163] 1041. The first metadata node determines that the metadata node storing the first metadata is the second metadata node among the multiple metadata nodes based on the first file shard information and the shard routing information of the first metadata node.

[0164] Among them, each metadata node in the multiple metadata nodes stores a different metadata shard. The first metadata node determines that the metadata shard corresponding to the first metadata is not stored in the first metadata node based on the first file shard information and the shard routing information of the first metadata node, and determines that the metadata node storing the first metadata is the second metadata node among the multiple metadata nodes. At this time, the first metadata node acts as a coordinating node.

[0165] 1042. The first metadata node sends a second access request to the second metadata node, where the second metadata node stores index shards and metadata shards corresponding to the first metadata.

[0166] Among them, the first metadata node can serve as a coordination node, and the first metadata node sends a second access request to the second metadata node, and the second metadata node stores index fragments and metadata fragments corresponding to the first metadata.

[0167] 1043. The second metadata node sends the operation result of operating the metadata shard according to the index shard.

[0168] Among them, the first metadata node acts as a coordination node, the first metadata node determines that the second metadata node is the node storing the first metadata, the index shard is used to quickly locate the metadata shard where the index established for the data is located, and the second metadata node operates on the metadata shard according to the index shard and generates an operation result.

[0169] 1044. The first metadata node receives an operation result from the second metadata node that operates on the metadata shard according to the index shard.

[0170] Among them, the second metadata node operates on the metadata shard according to the index shard, and the second metadata node can obtain the operation result. The first metadata node acts as a coordination node and can receive the operation result from the second metadata node.

[0171] This embodiment of the application provides high concurrency throughput across metadata nodes by using a large number of index shards. Each metadata node can create multiple metadata shards and index shards, thereby providing high concurrency within a single metadata node. Furthermore, for large directories, it provides accelerated parallel reading of directory information across metadata nodes.

[0172] In other embodiments of the present application, Figure 13 As shown, 104, the first metadata node determines the operation result corresponding to the first metadata according to the first file shard information and the shard routing information of the first metadata node, including:

[0173] 1045. The first metadata node determines that the metadata node storing the first metadata is the first metadata node, and the index shard of the first metadata in the first metadata node based on the first file shard information and the shard routing information of the first metadata node.

[0174] Among them, each metadata node in the multiple metadata nodes stores a different metadata shard, and the first metadata node determines the metadata shard corresponding to the first metadata stored in the first metadata node based on the first file shard information and the shard routing information of the first metadata node. At this time, the first metadata node can provide operations for the first metadata, and the operation is determined according to the operation type requested by the client.

[0175] 1046. The first metadata node searches for the metadata shard corresponding to the first metadata according to the index shard.

[0176] The index shard is used to quickly locate the metadata shard where the index established for the data is located, and the first metadata node finds the metadata shard corresponding to the first metadata based on the index shard.

[0177] 1047. The first metadata node operates on the metadata shard corresponding to the first metadata and generates an operation result.

[0178] The first metadata is locally accessed according to the index shard, an operation is performed on the metadata shard corresponding to the first metadata, and an operation result is generated.

[0179] This embodiment of the application provides high concurrency throughput within a metadata node by using a large number of index shards. Each metadata node can create many metadata shards and index shards, thereby providing high concurrency within a single metadata node. Furthermore, for large directories, it provides accelerated parallel reading of directory information across metadata nodes.

[0180] Furthermore, in some embodiments of the present application, the first metadata node 1047 operates on the metadata shard corresponding to the first metadata, including:

[0181] 10471. The first metadata node determines the operation type corresponding to the first metadata based on the first access request.

[0182] The first access request sent by the client may also carry an operation type, which may include multiple operation types, such as read operation, write operation, update operation, delete operation, etc.

[0183] 10472. The first metadata node performs a locking operation on the parent directory corresponding to the first metadata according to the operation type corresponding to the first metadata.

[0184] Among them, the first metadata node can determine the parent directory identifier corresponding to the first metadata based on the directory information, and then perform a locking operation on the parent directory corresponding to the first metadata according to the operation type corresponding to the first metadata. For example, when the operation type requested by the client is different, the locking operation performed by the first metadata is different.

[0185] 10473. The first metadata node operates on the metadata shard after the parent directory is locked according to the operation type.

[0186] Among them, after the first metadata node locks the parent directory, it operates on the metadata shard to avoid other metadata nodes from operating on the metadata shard at the same time.

[0187] In the embodiment of the present application, the locking operation can ensure the consistency of metadata data under high concurrency.

[0188] Furthermore, in some embodiments of the present application, the first metadata node performs a locking operation on the parent directory corresponding to the first metadata according to the operation type corresponding to the first metadata, including:

[0189] When the operation type includes at least one of the following: a write operation, an update operation, and a delete operation, the first metadata node adds a mutex lock to the parent directory;

[0190] When the operation type includes a read operation, the first metadata node adds a shared lock to the parent directory.

[0191] Specifically, when metadata operations require write, update, or delete operations, a mutual exclusion lock must be added to the parent directory corresponding to the metadata shard to prevent other metadata nodes from performing simultaneous read and write operations. When metadata operations require read operations, a shared lock must be added to the parent directory corresponding to the metadata shard to prevent other metadata nodes from performing simultaneous modification operations. This locking operation ensures metadata consistency under high concurrency.

[0192] 105. The first metadata node sends the operation result to the client.

[0193] In the embodiment of the present application, each of the multiple metadata nodes stores the same directory information. Therefore, after the client initiates access to the first metadata node, the operation result corresponding to the first metadata can be obtained through the first metadata node. Finally, the first metadata node returns the operation result to the client, thereby completely eliminating the overhead of distributed path resolution, and the operation of metadata can be completed between the client and the first metadata node.

[0194] In other embodiments of the present application, directory information is copied to all metadata nodes, so operations on directory information need to use two-phase commit (2PC) distributed transactions and two-phase locking (2PL) to resolve conflicts with single metadata node file metadata operation transactions and maintain the consistency of directory information.

[0195] The distributed file system further includes a coordination node, in which directory information is stored. The access method in the distributed file system executed by the first metadata node further includes:

[0196] 106. The first metadata node receives a directory update command from the coordination node, where the directory update command indicates updated directory information.

[0197] The coordination node may also interact with the client to receive a directory update command sent by the client, the directory update command indicating updated directory information, and the coordination node may send the directory update command to the first metadata node. For example, the directory update command may include a directory rename command.

[0198] 107. The first metadata node performs a locking operation and a directory update operation on the directory information of the first metadata node according to the directory update command.

[0199] After receiving the directory update operation from the coordinating node, the first metadata node may lock the directory information and then perform the directory update operation according to the directory update command. The locking operation on the directory information may include applying a shared lock or a mutually exclusive lock to the directory entries in the directory information, which is not limited here.

[0200] 108. The first metadata node stores the updated directory information.

[0201] After the first metadata node performs a directory update operation according to the directory update command, the updated directory information can be obtained, and the first metadata node can store the directory information. In the embodiment of the present application, the directory update operation can be performed to resolve conflicts with single metadata node transactions through distributed locks.

[0202] In other embodiments of the present application, in order to avoid redundant storage overhead of a large amount of directory information, the distributed file system provided in the embodiments of the present application may further include directory storage nodes to alleviate the redundant storage overhead.

[0203] The directory storage node is used to synchronize directory information across multiple metadata nodes. In this embodiment, a centralized directory storage node can be used to persistently store directory information, while each metadata node only caches a portion of the directory information. A hybrid consistency protocol with row-level locking and conflict-free replicated data types (CRDTs) is used to ensure global directory consistency.

[0204] The access method in the distributed file system executed by the first metadata node further includes:

[0205] 109. When the first metadata node does not store directory metadata corresponding to the object path, the first metadata node sends a directory request to the directory storage node.

[0206] Among them, in addition to including N metadata nodes, the distributed file system in the embodiment of the present application also includes a directory storage node. The directory information of the first metadata node does not contain directory metadata corresponding to the storage object path. The first metadata node can send a directory request to the directory storage node.

[0207] 110. The first metadata node receives directory information sent from the directory storage node.

[0208] The directory storage node receives the directory request from the first metadata node and obtains the directory information requested by the first metadata node. The directory storage node may then send the directory information to the first metadata node, and the first metadata node may receive the directory information sent from the directory storage node.

[0209] 111. The first metadata node stores the received directory information.

[0210] The first metadata node receives the directory information sent from the directory storage node, and stores the received directory information in the first metadata node for use in path query when an access request is subsequently received.

[0211] As can be seen from the examples of the aforementioned embodiments, a distributed file system includes multiple metadata nodes, a first metadata node belongs to multiple metadata nodes, and each metadata node in the multiple metadata nodes stores the same directory information, and the directory information is used to store the directory metadata of the distributed file system. Multiple metadata nodes can interact with the client. Taking the interaction process between the first metadata node and the client as an example, the client generates a first access request based on the path of the object to be accessed, and sends the first access request to the distributed file system. The first metadata node receives the first access request from the client, and the first metadata node determines the first file shard information corresponding to the first metadata based on the directory information and the path of the object to be accessed. After determining the first file allocation information, the first metadata node determines the operation result corresponding to the first metadata based on the first file shard information and the shard routing information of the first metadata node. Finally, the first metadata node sends the operation result to the client to enable the client to access the distributed file system. In an embodiment of the present application, since each of the multiple metadata nodes stores the same directory information, the client can initiate access to any metadata node among the multiple metadata nodes. The first metadata node among the multiple metadata nodes can determine the first file shard information based on the stored directory information, and can feedback the operation results to the client. Therefore, the metadata operation can complete the access to the meta-object between the first metadata node and the client, without the need for layer-by-layer path resolution, reducing the overhead of distributed path resolution and improving the access performance of the distributed file system.

[0212] Next, another file access method in a distributed file system provided by an embodiment of the present application is introduced. The method is applied to a coordination node in a distributed file system, and the distributed file system also includes multiple metadata nodes. Directory information is copied to all metadata nodes, so operations on directory information need to use 2PC distributed transactions and 2PL to resolve conflicts with metadata operation transactions of a single metadata node file and maintain the consistency of directory information. Next, it is explained from the coordination node side, such as Figure 14 As shown, the file access method in the distributed file system executed by the coordination node includes:

[0213] 1401. The coordinating node receives a directory creation request from a client.

[0214] The coordinating node can interact with the client. After the user creates a directory tree on the client, the client can send a directory creation request to the coordinating node, so that each metadata node in the distributed file system can create directory information locally. The coordinating node receives the directory creation request from the client, which may include directory metadata.

[0215] 1402. The coordinating node generates directory information according to the directory creation request. The directory information is used to store directory metadata of the distributed file system.

[0216] After the coordination node receives the directory creation request from the client, it generates directory information based on the directory creation request. The directory information is used to store the directory metadata of the distributed file system. The detailed content of the directory information is detailed in the aforementioned terminology description and the directory information shown in the aforementioned Table 1, which will not be repeated here.

[0217] 1403. The coordination node sends directory information to multiple metadata nodes through distributed transactions.

[0218] Based on the description of the distributed file system introduced above, it can be known that the coordination node can interact with multiple metadata nodes, and the coordination node sends directory information to multiple metadata nodes in the form of distributed transactions, so that each metadata node can store directory information. For example, the distributed transaction can specifically include a two-phase commit (2PC) distributed transaction, or a three-phase commit protocol (3PC) to ensure the consistency and reliability of the distributed transaction. In the embodiment of the present application, the coordination node can be used to achieve that each metadata node in the multiple metadata nodes in the distributed file system stores the same directory information, so that each metadata node can respond to the client's access request and complete the client's operation on the metadata.

[0219] Furthermore, in some embodiments of the present application, in addition to executing the aforementioned method embodiments, the method executed by the coordinating node may also include the following steps:

[0220] The coordinating node receives directory update requests from clients;

[0221] The coordinating node performs a directory update operation on the directory information according to the directory update request and generates a directory update command, where the directory update command indicates the updated directory information;

[0222] The coordinating node sends directory update commands to multiple metadata nodes through distributed transactions.

[0223] Specifically, when the directory tree created by the user through the client needs to be updated, the client can send a directory update request to the coordination node. The coordination node can also interact with the client to receive the directory update request sent by the client. The coordination node performs a directory update operation on the directory information according to the directory update request and generates a directory update command. The directory update command indicates the updated directory information. The coordination node can send a directory update command to the first metadata node in the form of a distributed transaction. For example, the directory update command may include a directory rename (rename) command. After the first metadata node receives the directory update operation from the coordination node, it can lock the directory information, and after locking, perform a directory update operation according to the directory update command. In the embodiment of the present application, the coordination node can play the role of timely updating the directory, so that the metadata nodes in the distributed file system can obtain the latest directory information.

[0224] Furthermore, in some embodiments of the present application, the distributed file system further includes: a directory storage node, the directory storage node being used for synchronizing directory information in a plurality of metadata nodes;

[0225] In addition to executing the aforementioned method embodiment, the method executed by the coordinating node may further include the following steps:

[0226] The coordinating node receives directory update requests from clients;

[0227] The coordinating node performs a directory update operation on the directory information according to the directory update request and generates a directory update command, where the directory update command indicates the updated directory information;

[0228] The coordinating node sends a directory update command to the directory storage node.

[0229] Specifically, when the directory tree created by the user through the client needs to be updated, the client can send a directory update request to the coordination node. The coordination node can also interact with the client to receive the directory update request sent by the client. The coordination node performs a directory update operation on the directory information according to the directory update request and generates a directory update command. The directory update command indicates the updated directory information. The coordination node can send a directory update command to the directory storage node in the form of a distributed transaction. For example, the directory update command may include a directory rename command. After receiving the directory update operation from the coordination node, the directory storage node can perform an update operation on the directory information. In the embodiment of the present application, the coordination node can play the role of timely updating the directory, so that the directory storage node in the distributed file system can obtain the latest directory information.

[0230] Next, another file access method in a distributed file system provided by an embodiment of the present application is described. The method is applied to a directory storage node in a distributed file system, wherein the distributed file system further includes multiple metadata nodes; the directory storage node is used to synchronize directory information in the multiple metadata nodes;

[0231] like Figure 15 As shown, the file access method in the distributed file system executed by the directory storage node includes:

[0232] 1501. A directory storage node receives a directory request sent by a first metadata node, where the first metadata node belongs to multiple metadata nodes.

[0233] In the embodiment of the present application, in addition to including N metadata nodes, the distributed file system also includes a directory storage node. When the directory information of a first metadata node does not contain directory metadata corresponding to a storage object path, the first metadata node may send a directory request to the directory storage node. The directory storage node may determine the directory information requested by the first metadata node based on the directory request.

[0234] 1502. The directory storage node obtains directory information according to the directory request.

[0235] The directory storage node stores directory information of the distributed file system, and the directory storage node obtains the directory information requested by the first metadata node according to the directory request.

[0236] 1503. The directory storage node sends directory information to the first metadata node.

[0237] After determining the directory information requested by the first metadata node, the directory storage node may send the directory information to the first metadata node. The first metadata node receives the directory information sent from the directory storage node and stores the received directory information in the first metadata node for use in path queries when a subsequent access request is received.

[0238] Furthermore, in some embodiments of the present application, the distributed file system further includes: a coordinating node, wherein the coordinating node stores directory information;

[0239] In addition to executing the aforementioned method embodiment, the method executed by the directory storage node may further include the following steps:

[0240] The directory storage node receives a directory update command from the coordination node, where the directory update command indicates updated directory information;

[0241] The directory storage node performs locking and directory update operations on the directory information according to the directory update command;

[0242] The directory storage node stores updated directory information.

[0243] Specifically, when the directory tree created by the user through the client needs to be updated, the client can send a directory update request to the coordination node. The coordination node can also interact with the client to receive the directory update request sent by the client. The coordination node performs a directory update operation on the directory information according to the directory update request and generates a directory update command. The directory update command indicates the updated directory information. The coordination node can send a directory update command to the directory storage node in the form of a distributed transaction. For example, the directory update command may include a directory rename command. After receiving the directory update operation from the coordination node, the directory storage node can perform an update operation on the directory information. In the embodiment of the present application, the coordination node can play a role in timely updating the directory information, so that the directory storage node in the distributed file system can obtain the latest directory information.

[0244] To facilitate a better understanding and implementation of the above-mentioned solutions in the embodiments of the present application, the following examples are given for specific explanation.

[0245] like Figure 16 As shown, a schematic diagram of the overall distribution scenario of the distributed object metadata provided in an embodiment of the present application is used to illustrate the process of creating directory metadata in the distributed file system of an embodiment of the present application. For the directory tree created by the user, two types of metadata tables are maintained in the distributed file system, namely the directory resolution tree replication table (referred to as the directory table) and the index node table. The index node table can also be called the Inode distributed table or Inode. It can be seen from the composition information of the directory table described in Table 1 above that the directory table records the directory structure of the entire distributed file system. Each row (tuple) in the directory table records a directory entry, which includes metadata for path resolution. The directory table includes metadata information such as directory name, directory ID, parent directory ID and other metadata.

[0246] In the embodiment of the present application, the directory table is copied to all metadata nodes 1-N, and the directory table is stored in all metadata nodes 1-N, that is, the directory structure of the distributed file system is exactly the same on all metadata nodes.

[0247] The Inode distributed table records the detailed metadata of the directories and files in the entire distributed file system. For example, the Inode distributed table includes a unique index identifier (InodeID), name, parent directory ID_partID, permissions and other metadata information. The Inode distributed table can obtain the parent directory ID_partID field according to the local identifier PartID combination mapped to the specified parent directory ID+file name hash, and then hash the parent directory ID_partID field to scatter and distribute it to different metadata nodes. After the "parent directory ID_partID" composed of the parent directory ID+file name hash adopted in the embodiment of the present application is hashed again and scattered into metadata nodes 1-N, it can ensure global scattering. The Inode distributed table of each metadata uses an index for retrieval, for example, using the combination of <parent directory ID_partID, name> as a unique index. This combination can ensure that the same file does not exist in the same directory.

[0248] Figure 17 The schematic diagram of the fine-grained metadata fragmentation across multiple metadata nodes provided in the embodiment of this application illustrates the process of fine-grained metadata fragmentation. Each metadata node receives a read directory function (Readdir) operation, and the metadata in the Inode distributed table is finely fragmented across different metadata nodes. This fine-grained distribution ensures that the metadata achieves a good load balancing effect. Fine-grained distribution refers to the distribution of files as the finest objects in the distributed file system. Each metadata shard is queried using an index shard, and each metadata shard supports searching for metadata information for a file or directory by the value (key) of the file or directory's parent directory ID_partID.

[0249] This embodiment of the application uses a large number of index shards to search metadata shards, providing high concurrency throughput across and within nodes. Each metadata node can create multiple metadata shards and index shards, thereby achieving high concurrency within a single metadata node. Furthermore, for large directories, it provides accelerated cross-node parallel reading of directory entries.

[0250] like Figure 18 As shown in the figure, the sharded distributed routing table is stored and managed as a table on disk. After loading into memory, it is organized into an ordered array, supporting fast binary search. Each entry in the sharded distributed routing table includes a shard ID, a hash order of the shard (including start and end values), and the location record of the index shard to which it is mapped, i.e., the node ID. Index shards are named with the shard ID as a suffix, supporting the location of index shards.

[0251] like Figure 18The diagram shown is a schematic diagram of the metadata access process provided in the embodiment of the present application, which mainly includes the following processes:

[0252] Step 1: The metadata node performs directory resolution of / a / b / e / .

[0253] The metadata node obtains the file path transmitted from the client and first performs path resolution. Since the directory table in this embodiment of the application adopts a replicated table model, directory resolution can be performed directly on the metadata node. By resolving the path layer by layer and querying the directory table, the parent directory ID of the file / directory to be operated on can be obtained.

[0254] Step 2: The metadata node obtains the parent directory ID of d.txt (i.e., the directory ID of directory e), which is 3.

[0255] like Figure 18 As shown, the path of / a / b / e / d.txt is parsed. First, the root directory / is queried to obtain its ID as 0. Then, according to the parent directory ID = 0 and name = a, the directory a is further queried to obtain the ID of a as 2. And so on, the ID of the directory e is queried as 3.

[0256] Step 3: Obtain the parent directory ID_partID field by hashing the parent directory ID and the file name: 3<<13|hash(d.txt)=9813.

[0257] Hash the file / directory name to obtain the local identifier partID, and then combine it with the parent directory ID of the file / directory queried in step 1 to form a parent directory ID_partID combination.

[0258] Step 4: Hash the ID_partID field of the parent directory of the file to obtain: hash(9813)=1005, and query the shard distributed routing table for routing.

[0259] Perform a hash search based on the parent directory ID_partID obtained in step 3 to store the metadata node and metadata shard where the metadata to be searched is located.

[0260] Step 5: Route the query instruction to the table with shard ID 2 on metadata node 1 to query the data.

[0261] If the metadata to be operated is stored locally on the metadata node, the metadata shard will be operated locally on the metadata node. If the metadata to be operated is not stored locally on the metadata node, the metadata node will act as a coordinator and route the metadata query to the specified metadata node for query.

[0262] like Figure 19aAs shown, this is a schematic diagram of concurrent processing of distributed metadata provided in an embodiment of the present application. Directory renaming (Rename) locks and modifies the directory table on all metadata nodes, adds shared locks to the root directory / and a, and adds mutually exclusive locks to the directories b and f. All metadata nodes perform the same locking and directory modification operations.

[0263] To improve the performance of metadata operations, a shared memory flag must be set before directory structure permission changes are performed (for example, set Fast-path to false). When the shared memory flag is set to false, path resolution requires adding shared locks to directory entries along the path.

[0264] Other parallel metadata nodes also acquire shared or exclusive locks when accessing directory entries. When other metadata nodes acquire shared locks, access can proceed normally, meaning that all parallel programs need to read the directory entry. However, when other metadata nodes attempt to modify the directory entry, they must acquire exclusive locks. However, these attempts will fail, forcing the metadata nodes to wait for permission to acquire the lock, thus preventing simultaneous read and write operations.

[0265] When metadata is being written, updated, or deleted, a mutual exclusion lock is placed on the parent directory of the corresponding metadata shard to prevent other metadata nodes from reading or writing the shard at the same time. When the metadata is being read, a shared lock is placed on the parent directory of the corresponding metadata shard to prevent other metadata nodes from modifying the shard at the same time. This locking ensures metadata consistency even under high concurrency.

[0266] In some embodiments of the present application, operations can also be performed on directory metadata. Since the directory table is replicated to all metadata nodes, operations on directory metadata require the use of two-phase commit (2PC) distributed transactions and two-phase locking (2PL) to resolve conflicts with individual metadata node file metadata operations and maintain the consistency of the directory tree.

[0267] like Figure 19a As shown in the following example, a system-wide rename operation (Rename / a / b -> / a / f / b) locks and modifies the directory tables on all metadata nodes. This operation applies shared locks to the root directory / and a, and exclusive locks to directories b and f. The coordinating node then sends the rename command to all metadata nodes, which then perform the same locking and directory modification operations.

[0268] Because distributed file systems involve directory modification operations, user-submitted file metadata queries place shared locks on the directory tree during directory resolution. Furthermore, exclusive locks are placed when users initiate file creation, modification, or deletion. Metadata operations must automatically wait for the directory operation to complete and release the lock before successfully acquiring the lock and performing the corresponding metadata operation. Therefore, directory operations can resolve conflicts with transactions on individual metadata nodes through distributed locks.

[0269] like Figure 19b The figure shows a schematic diagram of a directory storage node storing a directory according to an embodiment of the present application. To avoid redundant storage overhead of directory tables in certain scenarios, such as when there are a large number of directory tables, the embodiment of the present application further supports the use of directory storage nodes added to metadata nodes to cache directory entries to alleviate this redundant storage overhead.

[0270] Figure 19b The present invention demonstrates that embodiments of the present invention can employ a centralized directory storage node to persistently store directory entries, while each metadata node caches only a subset of directory entries. This approach employs a hybrid consistency protocol with row-level locking and conflict-free replicated data types (CRDTs) to ensure global directory consistency. Metadata nodes can autonomously eliminate directory entries from the directory cache, for example, using a least recently used (LRU) algorithm. Metadata nodes can retrieve missing directory entries from directory storage nodes.

[0271] like Figure 20a As shown, this is a schematic diagram of the directory global consistency storage provided by an embodiment of the present application. Directory metadata can be divided into directory key metadata columns and directory non-key metadata columns. For directory key metadata columns such as directory tree structure and directory permissions, a 2PL serializable isolated distributed transaction is used to ensure strong consistency. For directory non-key metadata columns such as directory time and directory size, a CRDT-based modification merge mechanism and redo log playback recovery are used. The directory deletion operation locks the directory to be deleted through a 2PL mutex lock on all nodes, checks whether there are any files or directories below, and performs the deletion operation only when the file or directory is empty. When a directory modification operation occurs, a distributed transaction is executed on all nodes, and consistency is guaranteed by 2PL. The directory non-key metadata columns synchronize the directory modifications of each metadata node to the metadata node to which the directory is mapped through a periodic synchronization mechanism for persistent storage. Similarly, the conflict between directory path resolution and directory structure / permission modification operations (rename / chmoddir) still relies on the aforementioned concurrency model to ensure distributed consistency.

[0272] The metadata node autonomously eliminates directory caches. When a directory cache miss is found during path resolution on a metadata node, the latest directory metadata is read from the directory storage node. To increase the throughput of directory creation operations, embodiments of the present application can distribute the directory metadata hash across all nodes, thus avoiding the bottleneck of a single directory storage node.

[0273] like Figure 20b As shown, it is a schematic diagram of the scalable directory metadata management provided by an embodiment of the present application. Each directory metadata and file metadata can be hashed to a shard of a metadata node in the same manner according to the directory / file name consistency. When each metadata node encounters a missing directory item during path resolution, it reads the metadata node to which the directory item is mapped according to the consistent hash. The directory creation operation is routed to the metadata node to which the directory item to be created is mapped for execution, thereby providing scalable directory creation operation throughput.

[0274] As can be seen from the examples in the preceding embodiments, the directory file metadata sharding method in a distributed file system provided by the embodiments of this application completely fragments the metadata, achieving fine-grained metadata load balancing. Furthermore, the directory table exists on all metadata nodes in the form of a replicated table or directory cache, allowing path resolution to be performed locally, completely eliminating the overhead of distributed path resolution.

[0275] It should be noted that for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by this application.

[0276] In order to better implement the above-mentioned solutions of the embodiments of the present application, relevant devices for implementing the above-mentioned solutions are also provided below.

[0277] See also Figure 21 As shown, an embodiment of the present application provides a computing device 2100, which may specifically be the aforementioned first metadata node. The computing device 2100 may include: a receiving module 2101, a processing module 2102, and a sending module 2103, wherein:

[0278] A receiving module, configured to receive a first access request from a client, wherein the first access request includes a path of an object to be accessed;

[0279] a processing module, configured to determine first file fragment information corresponding to the first metadata according to the directory information and the path of the object to be accessed;

[0280] a processing module, configured to determine an operation result corresponding to the first metadata according to the first file shard information and the shard routing information of the first metadata node;

[0281] A sending module is used to send the operation result to the client.

[0282] In some embodiments of the present application,

[0283] See also Figure 21 As shown, an embodiment of the present application provides a computing device 2100, which may be the aforementioned coordination node. The computing device 2100 may include: a receiving module 2101, a processing module 2102, and a sending module 2103, wherein:

[0284] A receiving module, used for receiving a directory creation request from a client;

[0285] a processing module, configured to generate directory information according to the directory creation request, wherein the directory information is used to store directory metadata of the distributed file system;

[0286] A sending module is used to send the directory information to the multiple metadata nodes through a distributed transaction.

[0287] See also Figure 21 As shown, an embodiment of the present application provides a computing device 2100, which may be the aforementioned directory storage node. The computing device 2100 may include: a receiving module 2101, a processing module 2102, and a sending module 2103, wherein:

[0288] a receiving module, configured to receive a directory request sent by a first metadata node, where the first metadata node belongs to the plurality of metadata nodes;

[0289] A processing module, configured to obtain directory information according to the directory request;

[0290] A sending module is used to send the directory information to the first metadata node.

[0291] It should be noted that the information interaction, execution process, etc. between the modules / units of the above-mentioned device are based on the same concept as the method embodiment of the present application, and the technical effects they bring are the same as those of the method embodiment of the present application. For specific contents, please refer to the description in the method embodiment shown above in the present application, and no further details will be given here.

[0292] An embodiment of the present application further provides a computer storage medium, wherein the computer storage medium stores a program, and the program executes some or all of the steps recorded in the above method embodiment.

[0293] Next, another computing device provided by the embodiment of the present application is introduced. Figure 22 As shown, the computing device 2200 is specifically the aforementioned first metadata node, or coordination node, or directory storage node, and the computing device 2200 includes:

[0294] Receiver 2201, transmitter 2202, processor 2203 and memory 2204 (wherein the number of processors 2203 in the computing device 2200 may be one or more, Figure 22 In some embodiments of the present application, the receiver 2201, the transmitter 2202, the processor 2203 and the memory 2204 may be connected via a bus or other means, wherein: Figure 22 The bus connection is taken as an example.

[0295] Memory 2204 may include read-only memory and random access memory, and provides instructions and data to processor 2203. A portion of memory 2204 may also include non-volatile random access memory (NVRAM). Memory 2204 stores an operating system and operating instructions, executable modules, or data structures, or subsets thereof, or extended sets thereof. The operating instructions may include various operating instructions for implementing various operations. The operating system may include various system programs for implementing various basic services and processing hardware-based tasks.

[0296] Processor 2203 controls the operation of the computing device and may also be referred to as a central processing unit (CPU). In specific applications, the various components of the computing device are coupled together via a bus system. In addition to a data bus, the bus system may also include a power bus, a control bus, and a status signal bus. However, for clarity, all bus systems are referred to as a bus system in the figure.

[0297] The methods disclosed in the above embodiments of the present application can be applied to or implemented by processor 2203. Processor 2203 can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by hardware integrated logic circuits in processor 2203 or by software instructions. The above processor 2203 can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The methods, steps, and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of the present application can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software modules can be located in storage media well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory 2204 , and the processor 2203 reads the information in the memory 2204 and completes the steps of the above method in combination with its hardware.

[0298] The receiver 2201 can be used to receive input digital or character information, and generate signal input related to the relevant settings and function control of the computing device. The transmitter 2202 may include a display device such as a display screen, and the transmitter 2202 can be used to output digital or character information through an external interface.

[0299] In an embodiment of the present application, the processor 2203 is used to execute the access method in the distributed file system executed by the aforementioned first metadata node, coordination node or directory storage node.

[0300] In another possible design, when the computing device is a terminal device or a chip in a server, the chip includes: a processing unit and a communication unit. The processing unit may be, for example, a processor, and the communication unit may be, for example, an input / output interface, a pin, or a circuit. The processing unit may execute computer-executable instructions stored in the storage unit to enable the chip in the terminal to perform any of the above methods. Optionally, the storage unit is a storage unit in the chip, such as a register, a cache, etc. The storage unit may also be a storage unit in the terminal located outside the chip, such as a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM), etc.

[0301] The processor mentioned in any of the above places can be a general-purpose central processing unit, a microprocessor, an ASIC, or one or more integrated circuits for controlling the execution of the program of the above-mentioned first aspect method.

[0302] It should also be noted that the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed across multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment. In addition, in the drawings of the device embodiments provided in this application, the connection relationship between the modules indicates that there is a communication connection between them, which can be specifically implemented as one or more communication buses or signal lines.

[0303] Through the description of the above embodiments, it is clear to those skilled in the art that the present application can be implemented by means of software plus necessary general-purpose hardware, and of course it can also be implemented by means of dedicated hardware including application-specific integrated circuits, dedicated CPUs, dedicated memories, dedicated components, etc. In general, all functions performed by computer programs can be easily implemented with corresponding hardware, and the specific hardware structures used to implement the same function can also be various, such as analog circuits, digital circuits, or dedicated circuits, etc. However, for the present application, software program implementation is a better implementation method in most cases. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer's floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes a number of instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0304] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0305] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, a computer, a server, or a data center by wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) mode to another website, a computer, a server, or a data center. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a server or a data center that includes one or more available media integrations. The available medium can be a magnetic medium, (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid-state drive (SSD)).

Claims

1. An access method in a distributed file system, characterized in that: The method is applied to a first metadata node in the distributed file system, the distributed file system including a plurality of metadata nodes, the first metadata node belonging to the plurality of metadata nodes, each of the plurality of metadata nodes storing the same directory information, the directory information being used to store directory metadata of the distributed file system; The method comprises: receiving a first access request from a client, wherein the first access request includes a path of an object to be accessed; Determine first file fragment information corresponding to the first metadata according to the directory information and the object path to be accessed; Determine an operation result corresponding to the first metadata according to the first file shard information and the shard routing information of the first metadata node; Send the operation result to the client.

2. The method according to claim 1, characterized in that The determining the operation result corresponding to the first metadata according to the first file shard information and the shard routing information of the first metadata node includes: Determine, based on the first file shard information and the shard routing information of the first metadata node, that the metadata node storing the first metadata is a second metadata node among the multiple metadata nodes; Sending a second access request to the second metadata node, where the second metadata node stores index shards and metadata shards corresponding to the first metadata; Receive an operation result from the second metadata node performing an operation on the metadata shard based on the index shard.

3. The method according to claim 1, characterized in that The determining the operation result corresponding to the first metadata according to the first file shard information and the shard routing information of the first metadata node includes: Determine, based on the first file shard information and the shard routing information of the first metadata node, a metadata node storing the first metadata as the first metadata node, and an index shard of the first metadata in the first metadata node; Searching for a metadata shard corresponding to the first metadata according to the index shard; An operation is performed on the metadata slice corresponding to the first metadata, and the operation result is generated.

4. The method according to claim 3, characterized in that The operating the metadata fragment corresponding to the first metadata includes: determining, according to the first access request, an operation type corresponding to the first metadata; performing a locking operation on the parent directory corresponding to the first metadata according to the operation type corresponding to the first metadata; The metadata shard after the parent directory lock operation is operated according to the operation type.

5. The method according to claim 4, characterized in that The performing a locking operation on the parent directory corresponding to the first metadata according to the operation type corresponding to the first metadata includes: When the operation type includes at least one of the following: a write operation, an update operation, and a delete operation, adding a mutex lock to the parent directory; When the operation type includes a read operation, a shared lock is added to the parent directory.

6. The method according to any one of claims 1 to 5, characterized in that The determining, according to the directory information and the path of the object to be accessed, the first file fragment information corresponding to the first metadata includes: Determining, from the directory information according to the object path to be accessed, a parent directory identifier of the object path and an object name of the first metadata; A distribution column combination identifier is generated based on the parent directory identifier and the object name of the first metadata, and the first file shard information includes: the distribution column combination identifier, and the distribution column combination identifier includes: the combination result of the mapping value of the parent directory identifier and the object name.

7. The method according to any one of claims 1 to 5, characterized in that The determining, according to the directory information and the path of the object to be accessed, the first file fragment information corresponding to the first metadata includes: Determining that the lock added to the directory information has been released; The first file fragment information corresponding to the first metadata is determined according to the directory information after the lock is released and the object path to be accessed.

8. The method according to any one of claims 1 to 5, characterized in that The determining, according to the directory information and the path of the object to be accessed, the first file fragment information corresponding to the first metadata includes: Obtaining a shared memory tag of the directory information; When the shared memory mark indicates that locking is required, adding a shared lock to the directory information; The first file fragment information corresponding to the first metadata is determined according to the directory information after the lock is added and the object path to be accessed.

9. The method according to any one of claims 1 to 8, characterized in that The distributed file system further includes: a coordination node, wherein the directory information is stored in the coordination node; The method further comprises: receiving a directory update command from the coordinating node, wherein the directory update command indicates updated directory information; Performing a locking operation and a directory update operation on the directory information of the first metadata node according to the directory update command; The updated directory information is stored.

10. The method according to any one of claims 1 to 9, characterized in that The distributed file system further comprises: a directory storage node, the directory storage node being used for synchronizing directory information in the plurality of metadata nodes; The method further comprises: When the first metadata node does not store the directory metadata corresponding to the object path, sending a directory request to the directory storage node; receiving directory information sent from the directory storage node; Stores the received directory information.

11. A file access method in a distributed file system, characterized in that: The method is applied to a coordination node in the distributed file system, wherein the distributed file system further comprises a plurality of metadata nodes; The method comprises: Receive directory creation request from client; Generate directory information according to the directory creation request, where the directory information is used to store directory metadata of the distributed file system; The directory information is sent to the multiple metadata nodes in a distributed transaction manner.

12. The method according to claim 11, characterized in that The method further comprises: receiving a directory update request from the client; performing a directory update operation on the directory information according to the directory update request to generate a directory update command, wherein the directory update command indicates the updated directory information; The directory update command is sent to the multiple metadata nodes in a distributed transaction manner.

13. The method according to claim 11 or 12, characterized in that The distributed file system further comprises: a directory storage node, the directory storage node being used for synchronizing directory information in the plurality of metadata nodes; The method further comprises: receiving a directory update request from the client; performing a directory update operation on the directory information according to the directory update request to generate a directory update command, wherein the directory update command indicates the updated directory information; Send the directory update command to the directory storage node.

14. A file access method in a distributed file system, characterized in that: The method is applied to a directory storage node in the distributed file system, the distributed file system further comprising a plurality of metadata nodes, the directory storage node being used for synchronizing directory information in the plurality of metadata nodes; The method comprises: receiving a directory request sent by a first metadata node, the first metadata node belonging to the plurality of metadata nodes; obtaining directory information according to the directory request; Send the directory information to the first metadata node.

15. The method according to claim 14, characterized in that The distributed file system further includes: a coordination node, wherein the directory information is stored in the coordination node; The method further comprises: receiving a directory update command from the coordinating node, wherein the directory update command indicates updated directory information; performing a locking operation and a directory update operation on the directory information according to the directory update command; The updated directory information is stored.

16. A computing device, characterized in that The computing device includes at least one processor and at least one memory, wherein the at least one memory stores computer-readable instructions; the at least one processor executes the computer-readable instructions so that the computing device cluster executes the method as described in any one of claims 1 to 10, or 11 to 13, or 14 to 15.

17. A file access device, characterized in that: The file access device is specifically a first metadata node, and the first metadata node executes the method described in any one of claims 1 to 10.

18. A file access device, characterized in that: The file access device is specifically a coordination node, and the coordination node executes the method according to any one of claims 11 to 13.

19. A file access device, characterized in that: The file access device is specifically a directory storage node, and the directory storage node executes the method according to any one of claims 14 to 15.

20. A computer-readable storage medium, characterized in that The method comprises computer-readable instructions; the computer-readable instructions are used to implement the method according to any one of claims 1 to 10, or 11 to 13, or 14 to 15.

Images