Fault processing method of cluster file system and related products

Abstract

The invention relates to a fault processing method of a cluster file system and a related product. The fault processing method for the cluster file system comprises the following steps: in response to an operation request of a user on resources in the cluster file system, judging whether the cluster file system is in a fault log recovery state or not; and under the condition that the cluster file system is in the fault log recovery state, executing locking operation on the resources. And judging whether the main node of the lock is a fault node. And under the condition that the main node of the lock is the fault node, searching records about resources in the log, and playing back the records about the resources in the log by using a log playback thread pre-started by the fault node. And executing the operation according to the operation request after the pay-back thread is completed. According to the fault processing method of the cluster file system, log playback is not put in a node fault processing flow, so that the node fault processing time can be effectively shortened, and the influence of node faults on other normal services can be reduced.

Description

Technical Field

[0001] This invention relates to the field of cluster file system technology, and in particular to a fault handling method and related products for cluster file systems. Background Technology

[0002] Clustered file systems, as a distributed storage technology that connects multiple computers or servers, are primarily used to achieve distributed storage, sharing, and efficient access to large-scale data. With their high scalability and reliability, they are widely used in enterprise data centers and large-scale data processing scenarios. To ensure strong data consistency during concurrent access by multiple nodes, existing clustered file systems require the use of distributed locks when performing various file operations to prevent multiple nodes from modifying the same file or resource simultaneously, thus ensuring the integrity of data operations.

[0003] Mainstream cluster file systems record all metadata modifications in real time to a log, which serves as the core basis for data consistency recovery. When a node in the cluster fails, the cluster management system quickly detects the anomaly and removes it from the cluster. Upon receiving the node offline notification, the cluster file system immediately reads the log file left by the failed node, extracts the recorded metadata modification information, reloads this information into memory, and writes it to the corresponding disk location. This synchronizes the modifications made by the failed node, ensuring data consistency across the entire cluster file system.

[0004] However, existing cluster file system failure handling methods require pausing services during recovery and waiting for log replay to complete before services can resume. If the log volume is large, log replay requires reading the logs and then rewriting the recorded content to disk. Log replay can be time-consuming, leading to prolonged service recovery times for healthy nodes. Furthermore, other services on healthy nodes may not involve modifications to the logs of the failed node, and log replay of the failed node could cause other services to be affected for an extended period. Summary of the Invention

[0005] One objective of this invention is to overcome at least one deficiency in the prior art and to provide a fault handling method and related products for a cluster file system.

[0006] A further objective of this invention is to optimize the fault handling method of the cluster file system, thereby shortening the node fault handling time and reducing the impact of node faults on other normal services.

[0007] Specifically, the present invention provides a fault handling method for a clustered file system, comprising: In response to user requests to operate on resources in the cluster file system, determine whether the cluster file system is in a fault log recovery state; When the cluster file system is in a fault log recovery state, perform a locking operation on the resource; Determine if the master node of the lock is a faulty node; If the master node of the lock is a faulty node, search the log for records about the resource and use the log replay thread that was pre-started by the faulty node to replay the records of the resource in the log; After the replay thread completes, the operation is executed according to the operation request.

[0008] Optionally, if the master node of the lock is not a faulty node, the following is also included: Identify the node that last operated on the resource; Determine whether the node that last operated on the resource is a faulty node; If so, execute the steps of searching the records of resources in the log and replaying the records of resources in the log using the log replay thread pre-started by the faulty node; If not, proceed directly to execute the steps requested in the operation request.

[0009] Optionally, the step of replaying resource records in the log using a log replay thread pre-started by the failed node also includes: In response to offline events sent by the cluster management node in the cluster file system, a log replay thread is started in the background.

[0010] Optionally, the steps for performing a locking operation on a resource include: Determine whether the node requesting the lock is the master node of the lock; If the node requesting the lock is the master node of the lock, determine whether the master node of the lock is already occupied; If the master node of the lock is not occupied, lock the master node of the lock and update the node that was last locked in the cluster file system; If the master node holding the lock is occupied, the lock request is added to the waiting queue. After the occupier releases the node that requested the lock, the master node is locked, and the node that was last locked in the cluster file system is updated.

[0011] Optionally, if the node responding to the lock request is not the master node of the lock, the following is also included: Send the lock request to the lock's master node; Then, it further executes the step of determining whether the master node of the lock is occupied.

[0012] Optionally, after updating the last locked node in the cluster file system, the following steps are also included: Determine whether a response message needs to be sent to the node that issued the lock request; When it is necessary to send a response message to the node that issued the lock request, the master node of the lock sends a response message to the node that issued the lock request; The steps to terminate the locking operation on the resource; The process of locking the resource ends if there is no need to send a response message to the node that issued the lock request.

[0013] Optionally, logs are categorized and sorted according to log type and log information; wherein, Log types include resource group information and file information. Log information includes resource group number and inode number.

[0014] According to another aspect of the present invention, a computer program product is also provided, which, when executed by a processor, implements the steps of the fault handling method of the cluster file system according to any one of the preceding claims.

[0015] According to another aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the fault handling method of the cluster file system according to any of the preceding claims.

[0016] According to another aspect of the present invention, a computer device is also provided, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the fault handling method of the cluster file system according to any of the above claims.

[0017] The fault handling method for a cluster file system provided by this invention, in response to a user's operation request for resources in the cluster file system, determines whether the cluster file system is in a fault log recovery state. If the cluster file system is in a fault log recovery state, a locking operation is performed on the resource. Then, it is determined whether the master node of the lock is a faulty node. If the master node of the lock is a faulty node, the records related to the resource in the log are searched, and the resource records in the log are replayed using a log replay thread pre-started by the faulty node. After the replay thread completes, the operation is executed according to the operation request. The pre-started log replay thread only replays the resource records in the log if the master node of the lock is a faulty node. That is, other nodes will not be affected by the log replay thread when processing normal business, reducing fault handling events during the operation of the cluster file system.

[0018] Furthermore, if the master node of the lock is not a faulty node, determine the node that last operated on the resource. Check if the node that last operated on the resource is a faulty node. If so, execute the steps to search the resource-related records in the log and replay the resource records in the log using the log replay thread pre-started by the faulty node. If not, directly execute the steps to perform the operation according to the operation request. Log replay for that resource is only necessary when the node that last operated on the resource is a faulty node. If the last operating node is not a faulty node, it proves that the faulty node did not modify the resource, and log processing is unnecessary; the user operation can be executed directly. This can further reduce the impact of the cluster file system on other services during fault handling.

[0019] The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments of the invention in conjunction with the accompanying drawings. Attached Figure Description

[0020] The following sections will describe some specific embodiments of the invention in detail by way of example and not limitation, with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar parts or portions. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings: Figure 1 This is a flowchart illustrating a fault handling method for a cluster file system according to an embodiment of the present invention. Figure 2 This is a flowchart illustrating a fault handling method for a clustered file system according to another embodiment of the present invention; Figure 3 This is a step of performing a locking operation on resources in a fault handling method for a cluster file system according to an embodiment of the present invention; Figure 4 This is a flowchart illustrating a fault handling method for a clustered file system according to another embodiment of the present invention; Figure 5 This is a schematic diagram of a computer program product according to an embodiment of the present invention; Figure 6 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention; and Figure 7 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0021] Those skilled in the art should understand that the embodiments described below are merely a part of the embodiments of the present invention, and not all of the embodiments of the present invention. These partial embodiments are intended to explain the technical principles of the present invention and are not intended to limit the scope of protection of the present invention. Based on the embodiments provided by the present invention, all other embodiments obtained by those skilled in the art without creative effort should still fall within the scope of protection of the present invention.

[0022] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein can be considered as a ordered list of executable instructions for implementing logical functions, which can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-based system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0023] This invention provides a fault handling method for a cluster file system, such as... Figure 1 As shown, the fault handling method of the cluster file system includes at least the following steps S101 to S106.

[0024] Step S101: Responding to a user's request to operate on resources in the cluster file system.

[0025] Step S102: Determine if the cluster file system is in a fault log recovery state. Subsequent locking and judgment processes will only be executed if the system is in a fault log recovery state. If the system is in a normal state, the fault handling steps can be skipped, and operations can be performed according to normal logic without affecting the system's operating efficiency under normal conditions.

[0026] Step S103: While the cluster file system is in the fault log recovery state, a locking operation is performed on the resource. This prevents user operations and the log replay thread from simultaneously modifying the same resource, which could lead to data corruption or inconsistency. The locked object is the resource requested by the user, not a global lock on the cluster file system, so it will not block operations on other unrelated resources. This ensures that fault recovery only affects the resource requested by the user and does not affect the overall cluster's business operations.

[0027] Step S104: Determine if the lock's master node is a faulty node. By judging the state of the lock's master node, it is distinguished into two states: the lock's master node is a faulty node and the lock's master node is not a faulty node. This avoids performing invalid log replay operations regardless of whether the lock's master node is normal or not. When the lock's master node is not faulty, resource modification records can be directly obtained through the lock's master node. Log replay is only triggered when the lock's master node is faulty, allowing for targeted fault log recovery.

[0028] Step S105: If the master node of the lock is a faulty node, search the log for records related to the resource and use the log replay thread pre-started by the faulty node to replay the resource records in the log. The log replay thread is a pre-started thread; log replay is not performed immediately during the faulty node handling process, only one thread is started to process the fault log. The pre-started log replay thread is only used to replay the resource records in the log when the master node of the lock is determined to be a faulty node. This avoids immediately performing log replay after the log replay thread is started, reducing node fault handling events and the impact of node failure on other normal business operations.

[0029] Furthermore, before using the log replay thread to replay records of a resource in the log, searching the log for records related to that resource first allows for quick identification of the record corresponding to the resource that needs replaying, eliminating the need for the log replay thread to replay all records in the log. This method of searching the log for records related to a resource before using the log replay thread to replay records of that resource effectively improves the efficiency of handling group file system failures.

[0030] Step S106: After the replay thread completes, execute the operation according to the operation request. After log replay is complete, the resource status has been synchronized with the modifications to the faulty node. User operations are executed based on the latest data, avoiding operational errors caused by data synchronization issues. In some alternative embodiments, such as Figure 2 As shown, the fault handling method of the cluster file system includes at least the following steps S201 to S204 when the master node of the lock is not the faulty node.

[0031] Step S201: Determine the node that last operated on the resource.

[0032] Step S202: Determine whether the node that last operated on the resource is a faulty node. Log replay for that resource is only triggered if the last operating node is a faulty node. If it is a normal node, it proves that the faulty node did not make any modifications to the resource, and there is no need to perform a replay operation, thus avoiding the log replay thread from hindering other business operations.

[0033] Step S203: If the node that last operated on the resource is a faulty node, the steps are as follows: search the records related to the resource in the log, and use the log replay thread pre-started by the faulty node to replay the resource records in the log. Then, the steps are executed according to the operation request. Replaying the faulty node's log for that resource ensures that the modifications made by the faulty node are completely synchronized to the current node, avoiding data loss or inconsistencies. After the replay is completed, the user operation is executed, ensuring that the operation is based on the latest synchronized data and avoiding potential business pauses or waiting.

[0034] Step S204: If the node that last operated on the resource is not a failed node, directly execute the step of performing the operation according to the operation request. Skipping the log replay thread when the node that last operated on the resource is not a failed node can improve the operating efficiency of the cluster file system.

[0035] In some optional embodiments, before the step of replaying resource records in the log using a log replay thread pre-started by the faulty node, the method further includes: starting the log replay thread in the background in response to an offline event sent by the cluster management node in the cluster file system. After responding to the offline event sent by the cluster management node, instead of waiting for log replay to complete in the fault handling process, the log replay thread is started in the background and the node enters a fault log recovery state, in which normal business operations are allowed. Pre-starting the log replay thread avoids prolonged blocking of normal business operations due to long replay times, and ensures that business operations not involving modifications by the faulty node continue to execute normally without any impact during fault recovery, greatly reducing the impact of node failures on the overall business operations in the cluster file system.

[0036] In some alternative embodiments, such as Figure 3 As shown, the fault handling method of the cluster file system includes at least the following steps S301 to S308 for performing a locking operation on the resource.

[0037] Step S301: Determine whether the node requesting the lock is the lock's master node. In the distributed environment of a clustered file system, the lock's master node is the core node that uniformly handles lock requests. By determining whether the node requesting the lock is the lock's master node, the node that is already the lock's master node can directly process the request locally, saving the network overhead and latency of cross-node communication. At the same time, other nodes can forward the request to the lock's master node, ensuring that all locking operations are uniformly managed by the lock's master node.

[0038] Step S302: If the node requesting the lock is the master node of the lock, determine whether the master node of the lock is occupied. Determining whether the master node of the lock is occupied can provide a direction for subsequent request processing. If it is not occupied, the lock is acquired directly; if it is occupied, the requests are queued in an orderly manner to avoid request processing chaos and ensure the standardization and stability of the locking process.

[0039] Step S303: If the master node of the lock is not occupied, lock the master node and update the last locked node in the cluster file system. The locking operation implements exclusive access control of the resource, preventing consistency issues that may arise from concurrent modifications. Updating the information of the last locked node provides data support for determining whether log replay is needed during subsequent fault recovery, enabling the cluster file system to quickly complete locking and information updates, ensuring efficient business execution.

[0040] Step S304: If the master node of the lock is occupied, the lock request is added to the waiting queue. After the occupier releases the node requesting the lock, the master node is locked, and the node that was last locked in the cluster file system is updated. Adding the lock request to the waiting queue ensures the orderliness of concurrent lock requests, avoiding request loss or out-of-order contention due to lock occupancy. Locking the master node promptly after the occupier releases the lock maximizes lock resource utilization and reduces request idle time. Synchronously updating the node information after locking maintains the master node's record of the latest resource operation status, ensuring accurate judgment during fault handling. This improves concurrent processing efficiency and guarantees data consistency.

[0041] Step S305, if the node responding to the lock request is not the lock's master node, further includes: sending the lock request to the lock's master node; and further executing a step to determine whether the lock's master node is already occupied. Forwarding lock requests from nodes other than the lock's master node to the lock's master node ensures that all locking operations are uniformly handled by the lock's master node, avoiding state chaos in a distributed environment. This eliminates the need for additional independent process design, simplifies the fault handling logic of the cluster file system, and guarantees the uniformity and standardization of the locking process.

[0042] Step S306: Determine whether a response message needs to be sent to the node that issued the lock request. Determining whether to send a response message based on the business scenario avoids meaningless message interactions that consume cluster file system resources. For scenarios requiring a clear lock result, a response can support subsequent operations. For scenarios where real-time waiting for a result is not required, not sending a response reduces communication overhead and pressure on the lock's master node, improving system efficiency.

[0043] In step S307, when a response message needs to be sent to the node that issued the lock request, the lock's master node sends a response message to the node that issued the lock request. The response message sent by the lock's master node provides the requesting node with a clear locking result, ensuring that the requesting node knows whether subsequent resource operations or log replay processes can be executed, avoiding errors that may result from blind operations. Sending a response message from the lock's master node to the node that issued the lock request also achieves a closed loop in the locking process, allowing the requesting node to adjust subsequent logic in a timely manner, ensuring the continuity of fault handling and business processes in the cluster file system, and reducing system anomalies that may be caused by missing information.

[0044] Step S308: End the process of performing the locking operation on the resource.

[0045] Without needing to send a response message to the node that issued the lock request, the locking operation on the resource can be terminated directly. This reduces unnecessary operations and improves system efficiency.

[0046] In some optional embodiments, logs are categorized and sorted according to log type and log information. Log types include resource group information and file information, and log information includes resource group number and inode number. Sorting logs by resource group information, file information, resource group number, and inode number facilitates faster retrieval of log information for corresponding resources, thereby ensuring business continuity and processing efficiency of the cluster file system under fault conditions.

[0047] In some optional embodiments, after receiving an offline event from the cluster management node, the cluster file system simply starts a thread to handle log replay without waiting for the replay to complete. Business operations can continue normally in this state, but each business operation requires confirming that the lock's master node maintains information about the resource node that last modified it. The implementation method for confirming that the lock's master node maintains this information can be as follows: the lock's master node maintains a global sequence number. Each time a lock is requested, the sequence number on the lock's master node increments. The lock's master node also records the latest sequence number of the resource for each node requesting the lock and passes this sequence number to the requesting node for storage. During fault handling, each lock request requires comparing the sequence number stored locally with the sequence number of the faulty node.

[0048] In some alternative embodiments, the method for determining that the master node of the lock maintains the information of the last modified resource node can also be as follows: the master node of the lock maintains the sequence number of the last node to acquire the exclusive lock, and the sequence number of the last node to acquire the exclusive lock needs to be updated on the master node each time an exclusive lock is acquired. During fault handling, each time a lock is requested, it needs to be determined whether the last node to acquire the exclusive lock is itself.

[0049] Furthermore, the method for implementing the lock master node maintenance information can be as follows: a separate lock server assumes the function of the lock master node, and each time a lock is requested, the latest sequence number or the node number of the last exclusive lock is obtained from the separate lock server.

[0050] In some optional embodiments, the method for implementing the lock master node maintenance information can also be as follows: the lock master node is distributed on various nodes. During a fault, if the lock master node is not on the faulty node, the sequence number information or the sequence number of the node that last acquired the exclusive lock is obtained from the lock master node. If the lock master node is on the faulty node, the faulty node sequence number or the node sequence number cannot be obtained, and the information of the resource needs to be read from the log to determine whether it has been modified.

[0051] In some optional embodiments, if the resource corresponding to the fault log remains unaccessed, the relevant logs of the faulty node need to be replayed through the log replay thread of the fault recovery. When the log replay thread reads the log of the resource, it needs to lock the resource first to prevent it from being operated on by other nodes before performing the log replay operation. The fault log recovery state ends after the log replay is completed.

[0052] In some alternative embodiments, such as Figure 4 As shown, the fault handling method for the cluster file system may also include the following steps S401 to S408.

[0053] Step S401, responding to a user's request to operate on resources in the cluster file system.

[0054] Step S402: Determine whether the cluster file system is in the fault log recovery state.

[0055] Step S403: If the cluster file system is in a fault log recovery state, perform a locking operation on the resource.

[0056] Step S404: Determine whether the master node of the lock is a faulty node.

[0057] Step S405: If the master node of the lock is not a faulty node, determine the node that last operated on the resource.

[0058] Step S406: Determine whether the node that last operated on the resource is a faulty node.

[0059] Step S407: If the node that last operated on the resource is not a faulty node, execute the step of performing the operation according to the operation request.

[0060] Step S408: If the node that last operated on the resource is a faulty node, execute the step of replaying the resource record in the log using the log replay thread that was pre-started by the faulty node, and mark the resource in the log as replayed. Then execute the step of performing the operation according to the operation request.

[0061] Furthermore, if the master node of the lock is a faulty node, proceed to step S408. If the cluster file system is not in a fault log recovery state, proceed to step S407.

[0062] This embodiment also provides a computer program product 10, a computer-readable storage medium 20, and a computer device 30. Figure 5 This is a schematic diagram of a computer program product 10 according to an embodiment of the present invention. Figure 6 This is a schematic diagram of a computer-readable storage medium 20 according to an embodiment of the present invention. Figure 7 This is a schematic diagram of a computer device 30 according to an embodiment of the present invention. The computer program product 10 includes a computer program 11, which, when executed by the processor 32, implements the steps of the fault handling method of any of the above-described clustered file systems. A computer-readable storage medium 20 stores the computer program 11 thereon, which, when executed by the processor 32, implements the steps of the fault handling method of any of the above-described clustered file systems. The computer device 30 may include a memory 31, a processor 32, and the computer program 11 stored on the memory 31 and running on the processor 32.

[0063] The computer program 11 used to perform the operations of this invention may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages ​​and procedural programming languages. The computer program 11 may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a Local Area Network (LAN) or Wide Area Network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, to perform aspects of this invention, electronic circuits, including, for example, programmable logic circuits, Field-Programmable Gate Arrays (FPGAs), or Programmable Logic Arrays (PLAs), may execute computer-readable program instructions to personalize the electronic circuits by utilizing state information from computer-readable program instructions.

[0064] For the purposes of this embodiment, computer program product 10 is a related product containing computer program 11. For the purposes of this embodiment, computer-readable storage medium 20 is a tangible device capable of holding and storing computer program 11, and can be any device capable of containing, storing, communicating, propagating, or transmitting program 11 for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable storage medium 20 include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanical encoding device, and any suitable combination thereof.

[0065] Computer device 30 can be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computer device 30 can be a cloud computing node. Computer device 30 can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer device 30 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can reside on local or remote computing system storage media, including storage devices.

[0066] Computer device 30 may include a processor 32 adapted to execute stored instructions and a memory 31 that provides temporary storage space for the operation of instructions during operation. The processor 32 may be a single-core processor, a multi-core processor, a computing cluster, or any other configuration. The memory 31 may include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0067] Computer device 30 may also include a network adapter / interface and an input / output (I / O) interface. The I / O interface allows external devices that can be connected to the computer device to input and output data. The network adapter / interface provides communication between the computer device and a network, typically represented as a communication network.

[0068] Therefore, those skilled in the art should recognize that although numerous exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications conforming to the principles of the present invention can be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Thus, the scope of the present invention should be understood and construed as covering all such other variations or modifications.

Claims

1. A fault handling method for a clustered file system, comprising: In response to a user's request to operate on resources in the cluster file system, determine whether the cluster file system is in a fault log recovery state; If the cluster file system is in a fault log recovery state, a locking operation is performed on the resource; Determine if the master node of the lock is a faulty node; If the master node of the lock is the faulty node, search the log for records related to the resource, and use the log replay thread pre-started by the faulty node to replay the records of the resource in the log. After the playback thread completes, the operation is performed according to the operation request.

2. The fault handling method for a clustered file system according to claim 1, characterized in that, If the master node of the lock is not the faulty node, the following is also included: Identify the node that last operated on the resource; Determine whether the node that last operated on the resource is the faulty node; If so, perform the steps of searching the records of the resource in the log and replaying the records of the resource in the log using the log replay thread pre-started by the faulty node; If not, proceed directly to the steps of performing the operation according to the operation request.

3. The fault handling method for a clustered file system according to claim 1, characterized in that, The step of replaying the resource records in the log using the log replay thread pre-started by the faulty node also includes: In response to an offline event sent by the cluster management node in the cluster file system, the log replay thread is started in the background.

4. The fault handling method for a clustered file system according to claim 1, characterized in that, The steps of performing the locking operation on the resource include: Determine whether the node requesting the lock is the master node of the lock; If the node requesting the lock is the master node of the lock, determine whether the master node of the lock is occupied; If the master node of the lock is not occupied, lock the master node of the lock and update the node that was last locked in the cluster file system; If the master node of the lock is occupied, the lock request is added to the waiting queue. After the occupier releases the node for which the lock was requested, the master node of the lock is locked, and the node last locked in the cluster file system is updated.

5. The fault handling method for a clustered file system according to claim 4, characterized in that, If the node responding to the locking request is not the master node of the lock, the method further includes: Send the locking request to the master node of the lock; And further execute the step of determining whether the master node of the lock is occupied.

6. The fault handling method for a clustered file system according to claim 4, characterized in that, Following the step of updating the last locked node in the cluster file system, the method further includes: Determine whether a response message needs to be sent back to the node that issued the locking request; When it is necessary to send a response message to the node that issued the locking request, the master node of the lock sends the response message to the node that issued the locking request; The step of performing the locking operation on the resource is terminated; The process of locking the resource ends if it is not necessary to send a response message to the node that issued the lock request.

7. The fault handling method for a clustered file system according to claim 1, characterized in that, The logs are categorized and sorted according to log type and log information; among them, The log types include resource group information and file information, and the log information includes resource group number and inode number.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the fault handling method of the cluster file system according to any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that... When the computer program is executed by the processor, it implements the steps of the fault handling method of the cluster file system according to any one of claims 1 to 7.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the fault handling method for the cluster file system according to any one of claims 1 to 7.

Images