File lock management method and device for distributed file system, equipment and medium

Abstract

The invention discloses a file lock management method and device for a distributed file system, equipment and a medium, and is applied to the technical field of computers, and the method comprises the following steps: after receiving a first file access request initiated by a client to a first access node, constructing first file lock information according to an identification parameter in the access request, persistently storing the first file lock information to a shared disk space and caching the first file lock information to a local first access node; the access node is a mounting node for the client to access the distributed file system; switching the mounting node from the first access node to a second access node, and clearing the first file lock information locally cached by the first access node; and after a second file access request initiated by the client to the second access node is received, querying the first file lock information in the shared disk space based on the identification parameter in the access request so as to locally reconstruct the file lock cache at the second access node. According to the method and the device, the problem of file lock loss and residue in a distributed cluster access node switching scene is solved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device and medium for managing file locks in a distributed file system. Background Technology

[0002] Currently, open-source components of the Network File System (NFS) and Common Internet File System (CIFS) protocol access layers, such as Ganesha and Samba, as well as file system components of the Ceph Distributed Storage System, all support file locks (also known as record locks). However, when a distributed cluster fails and access nodes need to switch between multiple nodes, problems such as file lock loss and file lock residue can easily occur, leading to two serious consequences: If a process locks file A and is writing data, the loss of the file lock will allow other processes to repeatedly lock and write to file A, resulting in multiple processes writing to the file simultaneously, ultimately causing data inconsistency and business errors; If a process locks file A and finishes writing data, and then encounters a file lock residue that cannot be unlocked, all subsequent processes will be unable to lock file A, causing business to freeze and malfunction. Summary of the Invention

[0003] The purpose of this application is to provide a file lock management method, device, equipment, and medium for a distributed file system, which solves the problem of file lock loss and residual in the scenario of switching access nodes in a distributed cluster.

[0004] To address the aforementioned problems, this application provides a file lock management method for a distributed file system, comprising:

[0005] After receiving the first file access request initiated by the client to the first access node, the first file lock information is constructed based on the first identifier parameter in the first file access request, and the first file lock information is persistently stored in the shared disk space and cached locally on the first access node; wherein, the access node is the mount node for the client to access the distributed file system;

[0006] If it is necessary to switch the mounted node, switch the mounted node from the first access node to the second access node, and clear the first file lock information cached locally on the first access node;

[0007] Upon receiving a second file access request initiated by the client to the second access node, the system queries the corresponding first file lock information in the shared disk space based on the second identifier parameter in the second file access request, and rebuilds the file lock cache locally on the second access node according to the first file lock information; wherein, the first file access request and the second file access request are used to access the same target file.

[0008] Optionally, the file lock information includes a file lock key value, which is constructed based on the client's Internet Protocol address, the virtual Internet Protocol address of the corresponding access node, the protocol type of the client protocol, and the protocol random number of the client protocol; wherein, the client protocol is the file sharing network protocol used by the client when accessing the distributed file system; and the protocol random number is used to characterize the mapping relationship between the target file and the file lock.

[0009] Optionally, if it is necessary to switch the mounted node, switching the mounted node from the first access node to the second access node, and clearing the first file lock information cached locally on the first access node, includes:

[0010] If it is necessary to switch the mounted node, the mounted node is switched from the first access node to the second access node through virtual IP migration, and the file handle of the target file that has been opened on the first access node is closed, and the first file lock information cached locally on the first access node is cleared.

[0011] Optionally, the client protocol may include the Network File System Protocol (NFS) or the Universal Internet File System (ULS).

[0012] Optionally, the file access request includes a file lock request and a file reopen request. The file reopen request is a request initiated by the client to restore the file access connection and corresponding operation permissions after the original connection is broken due to the switching of the mount node. The reconstruction process of the file lock cache is completed synchronously during the processing of the file reopen request.

[0013] Optionally, the step of persistently storing the first file lock information to the shared disk space includes:

[0014] Determine whether there is a valid mutually exclusive file lock that overlaps with the byte range of the first file lock information;

[0015] If there is no valid mutex type file lock that overlaps with the byte range of the first file lock information, then the first file lock information is persistently stored in the shared disk space.

[0016] Optionally, the valid mutex type file lock is a file lock that has been persistently stored and has not exceeded a preset time limit.

[0017] This application also provides a file lock management device for a distributed file system, including:

[0018] The persistent storage module is used to construct first file lock information based on the first identifier parameter in the first file access request after receiving the first file access request initiated by the client to the first access node, and persistently store the first file lock information to the shared disk space and cache the first file lock information locally on the first access node; wherein, the access node is the mount node for the client to access the distributed file system;

[0019] The switching and cleaning module is used to switch the mounted node from the first access node to the second access node if it is necessary to switch the mounted node, and to clear the first file lock information cached locally on the first access node.

[0020] The file lock cache reconstruction module is used to, upon receiving a second file access request initiated by a client to the second access node, query the corresponding first file lock information in the shared disk space based on the second identifier parameter in the second file access request, and reconstruct the file lock cache locally on the second access node according to the first file lock information; wherein, the first file access request and the second file access request are used to access the same target file.

[0021] This application also provides a file lock management device for a distributed file system, including:

[0022] Memory, used to store computer programs;

[0023] A processor, used to implement the file lock management method of the distributed file system as described above when executing the computer program.

[0024] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the file lock management method of the distributed file system as described above.

[0025] This application provides a file lock management method for a distributed file system, comprising: after receiving a first file access request initiated by a client to a first access node, constructing first file lock information based on a first identifier parameter in the first file access request, persistently storing the first file lock information in a shared disk space, and caching the first file lock information locally on the first access node; wherein, the access node is the mount node for the client to access the distributed file system; if it is necessary to switch the mount node, switching the mount node from the first access node to a second access node, and clearing the first file lock information cached locally on the first access node; after receiving a second file access request initiated by a client to the second access node, querying the corresponding first file lock information in the shared disk space based on the second identifier parameter in the second file access request, and rebuilding the file lock cache locally on the second access node based on the first file lock information; wherein, the first file access request and the second file access request are used to access the same target file.

[0026] In summary, upon receiving a first file access request from a client to the first access node, this application constructs first file lock information based on the first identifier parameter in the request. This information is then persistently stored on the shared disk space and cached locally on the first access node. The first identifier parameter uniquely corresponds to the same client's access to the same target file. This dual storage mechanism avoids the risk of lock information loss that might occur with single storage and leverages the cross-node access capabilities of the shared disk to provide a reliable data foundation for lock cache reconstruction. When a node switch is required, this application switches the node from the first access node to the second access node and simultaneously clears the first file lock information cached locally on the first access node. This timely clearing of the old node's local lock cache resolves the file lock residue problem during access node switching scenarios. Since both the first and second file access requests are for accessing the same target file, and both the first and second identifier parameters are core identifiers associated with this target file access, upon receiving the second file access request from the client to the second access node, the second access node can accurately match the first file lock information stored in the shared disk space based on the second identifier parameter, and rebuild the file lock cache locally based on this lock information. The entire process requires no additional lock requests or manual configuration from the client, achieving seamless transition of lock states after node switching, ensuring the integrity and availability of file lock information, effectively avoiding file lock loss and file lock residue issues caused by node switching, thereby guaranteeing data consistency and improving business stability.

[0027] This application also provides a file lock management device, equipment, and medium for a distributed file system, which has the above-mentioned beneficial effects, and will not be elaborated here. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0029] Figure 1 A flowchart illustrating a file lock management method for a distributed file system provided in this application embodiment;

[0030] Figure 2 A schematic diagram of a file lock management device for a distributed file system provided in an embodiment of this application;

[0031] Figure 3 This is a schematic diagram of a file lock management device for a distributed file system provided in an embodiment of this application. Detailed Implementation

[0032] The core of this application is to provide a file lock management method, device, equipment, and medium for a distributed file system, which effectively avoids file lock loss and file lock residue problems caused by node switching, thereby ensuring data consistency and improving business stability.

[0033] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0034] When a distributed cluster fails and access nodes need to switch between multiple nodes, issues such as lost file locks and residual file locks can easily occur, leading to two serious consequences: If a process locks file A and is writing data, the loss of the file lock will allow other processes to repeatedly lock and write to file A, resulting in multiple processes writing to the file simultaneously, ultimately causing data inconsistency and business errors; If a process locks file A and finishes writing data, but encounters a residual file lock that cannot be unlocked when trying to unlock it, then all subsequent processes will be unable to lock file A, causing business operations to stall and fail to run normally.

[0035] Based on this, upon receiving a first file access request from a client to the first access node, this application constructs first file lock information based on the first identifier parameter in the request. This information is then persistently stored in the shared disk space and cached locally on the first access node. The first identifier parameter uniquely corresponds to the same client's access to the same target file. This dual storage mechanism avoids the risk of lock information loss that might occur with single storage and leverages the cross-node access capabilities of the shared disk to provide a reliable data foundation for lock cache reconstruction. When a node switch is required, this application switches the node from the first access node to the second access node and simultaneously clears the first file lock information cached locally on the first access node. This ensures timely clearing of the old node's local lock cache, resolving the issue of file lock remnants during access node switching scenarios. Since both the first and second file access requests are for accessing the same target file, and both the first and second identifier parameters are core identifiers associated with this target file access, upon receiving the second file access request from the client to the second access node, the second access node can accurately match the first file lock information stored in the shared disk space based on the second identifier parameter, and rebuild the file lock cache locally based on this lock information. The entire process requires no additional lock requests or manual configuration from the client, achieving seamless transition of lock states after node switching, ensuring the integrity and availability of file lock information, effectively avoiding file lock loss and file lock residue issues caused by node switching, thereby guaranteeing data consistency and improving business stability.

[0036] The following examples illustrate a file lock management method for a distributed file system provided in this application.

[0037] Figure 1 This is a flowchart illustrating a file lock management method for a distributed file system provided in an embodiment of this application.

[0038] In this embodiment, the method may include:

[0039] S101: After receiving the first file access request initiated by the client to the first access node, construct the first file lock information according to the first identifier parameter in the first file access request, persist the first file lock information to the shared disk space, and cache the first file lock information locally on the first access node; wherein, the access node is the mount node for the client to access the distributed file system.

[0040] It should be noted that file access requests include file lock requests and file reopen requests. A file reopen request is a request initiated by the client to restore the file access connection and corresponding operation permissions after the original connection is broken due to the switching of the mount node. The reconstruction process of the file lock cache is completed synchronously during the processing of the file reopen request.

[0041] In this embodiment, the first file access request initiated by the client to the first access node is accompanied by a file lock request. The purpose of initiating the file lock request is to obtain exclusive access to a specific byte range of the target file. Specifically, the file lock request is transmitted through the network connection between the client and the first access node, and carries key data such as client identity information, target file information, and the byte range of the file to be locked. This data prevents multiple processes from simultaneously reading and writing to the same area of ​​the file, thereby avoiding data conflict issues.

[0042] The composition of the identifier parameters will be explained in detail below. Before that, the system structure of this application needs to be explained: This application includes a client part and a distributed file system part. The distributed file system includes multiple access nodes, a virtual IP management service (VIP_MGR, Virtual IP Address Manager), a metadata management service (MDS, Metadata Service), and shared disk space. The access nodes are the mounting nodes for clients to access the distributed file system. A file sharing service (samba_server) is deployed on the access nodes to receive file access requests from clients and handle lock caching-related operations. The virtual IP (Internet Protocol Address) management service is responsible for the allocation, management, and mounting node switching scheduling of the virtual Internet Protocol Address (VIP) of the access nodes. The metadata management service is responsible for the persistent storage of file lock information. The shared disk space is used to store persistent file lock information.

[0043] Based on this, the first file lock information includes a first file lock key value, which is constructed based on the first identifier parameter combined with relevant information obtained by the access node. The first identifier parameter is directly carried in the file access request initiated by the client, specifically including the client's Internet Protocol address (passed by the client to the access node) and the client's protocol random number (passed by the client to the access node). After receiving the file access request, the access node further obtains its own Virtual Internet Protocol address (assigned and managed by the Virtual IP Management Service) and the client's protocol type (identified by the access node), and combines these two types of information with the first identifier parameter to jointly construct the first file lock key value. The client protocol is the file-sharing network protocol used by the client when accessing the distributed file system, including Network File System (NFS) or Common Internet File System (CIFS). The protocol random number represents the mapping relationship between the target file and the file lock, and is generated separately for each file. That is, if the client establishes locks on different files on the same access node (e.g., lock 1 for file 1 and lock 2 for file 2), it needs to pass in the corresponding random number separately for each file to provide a unique identifier for the lock information of different files. It should be noted that the above method of constructing the first file lock (key value) is merely exemplary. This application embodiment does not impose any restrictions on the construction method of the first file lock or the method of storing lock information (e.g., storing it in key value mode).

[0044] The file lock key value constructed based on the above fields does not contain any identity characteristics of the server node, but only contains the core identifiers related to the client, target file and access protocol. In this way, it can ensure that each file lock key value is globally unique, and also realize the cross-node identification and compatibility of lock information in the distributed cluster. For example, the first file lock key value is constructed based on the client's Internet Protocol address, the virtual Internet Protocol address (VIP) of the first access node, the corresponding client protocol type, and the protocol random number. The second file lock key value is constructed based on the same client Internet Protocol address, protocol type, protocol random number, and the virtual Internet Protocol address (VIP) of the second access node. It should be noted that the virtual Internet Protocol addresses of the first and second access nodes are uniformly managed by VIP_MGR. Since virtual IP migration only switches the mapping node corresponding to the global VIP (from the first access node to the second access node), the VIP itself remains unchanged, and the client IP, protocol type, and protocol random number (bound to the target file) are always consistent. Therefore, this embodiment can match the corresponding first file lock information in the shared disk space based on the second file lock key value, thereby realizing cross-node lock identification and cache reconstruction.

[0045] In this embodiment, persistently storing the first file lock information containing the first file lock key value to the shared disk space includes: determining whether there is a valid mutually exclusive file lock that overlaps with the byte range of the first file lock information; if there is no such valid mutually exclusive file lock, then persistently storing the first file lock information containing the first file lock key value to the shared disk space through the metadata management service; wherein, a valid mutually exclusive file lock is a file lock that has been persistently stored by the metadata management service and has not exceeded a preset time limit. In this way, the same byte range of the same file is prevented from being locked by multiple processes simultaneously, thereby avoiding data inconsistency.

[0046] S102: If it is necessary to switch the mounted node, switch the mounted node from the first access node to the second access node, and clear the first file lock information cached locally on the first access node.

[0047] In this embodiment, if a switch of the mounted node is required, the mounted node is switched from the first access node to the second access node through virtual IP migration, and the file handles of the target files that have been opened on the first access node are closed, as well as the first file lock information cached locally on the first access node is cleared. Specifically, if a switch of the mounted node is required, the virtual IP management service performs the following operations: switches the virtual IP of the mounted node from the first access node to the second access node; sends a cleanup notification to the file sharing service of the first access node so that the file sharing service of the first access node closes the opened file handles, and sends a lock cleanup instruction to the metadata management service; wherein, after receiving the lock cleanup instruction, the metadata management service returns a cleanup success response to the file sharing service of the first access node, and after receiving the cleanup success response, the file sharing service of the first access node clears the locally cached file lock information.

[0048] The node switching includes two scenarios: passive switching and active switching. Passive switching is triggered when the first access node experiences an anomaly, such as hardware failure, service downtime, or its load exceeding a preset threshold, preventing it from handling business requests. Active switching is triggered by system maintenance, cluster expansion, node upgrades, etc., ensuring smooth system operation and maintenance while avoiding impact on business operations. The lock cleanup command only clears file lock information cached locally on the first access node, without deleting persistently stored file lock information in the shared disk space. This provides a foundation for rebuilding the lock cache on subsequent new nodes and prevents lock loss, thus preventing the target file from being locked by multiple processes simultaneously and avoiding data inconsistency.

[0049] In this embodiment, by prioritizing the switching operation of the mounted node, it can be ensured that subsequent file access requests initiated by the client can be seamlessly routed to the second access node, effectively avoiding service interruption caused by switching delays and thus ensuring the continuity of business operations. Secondly, after the mounted node switching is completed, the file sharing service of the first access node closes its locally opened file handles, which can quickly release the resource occupation of the old node (i.e., the first access node) and prevent resource waste or operation conflicts caused by file handle leakage. Finally, the file sharing service of the first access node cleans up its local file lock cache only after receiving the cleanup success response. In this way, it avoids the residual lock cache on the old node from interfering with the relevant operations of the new node (i.e., the second access node) and provides a basis for the second access node to rebuild the file lock cache locally.

[0050] S103: After receiving the second file access request initiated by the client to the second access node, query the corresponding first file lock information in the shared disk space based on the second identifier parameter in the second file access request, and rebuild the file lock cache locally on the second access node according to the first file lock information; wherein, the first file access request and the second file access request are used to access the same target file.

[0051] In this embodiment, the second file access request is a file reopening request. Based on the foregoing analysis, this request is initiated by the client to restore the file access connection and corresponding operation permissions after the original connection is broken due to the switching of the mount node. The reconstruction process of the file lock cache is completed synchronously during the processing of this request.

[0052] Since the Virtual Internet Protocol (VIP) addresses of the first and second access nodes are uniformly managed by VIP_MGR, and the client IP, protocol type, and protocol random number (bound to the target file) are always consistent, this embodiment can match the corresponding file lock information with the first file lock key value in the shared disk space based on the second file lock key value, thereby achieving cross-node lock identification and cache reconstruction. In this embodiment, the reconstruction of the file lock cache is embedded in the client's regular file reopening request processing flow. The client does not need to initiate a separate lock reconstruction operation, and the entire process is seamless, achieving high availability of lock features with minimal business cost. This design effectively avoids the problem of file lock loss in access node switching scenarios, ensuring that subsequent read and write operations on files by the client can be executed normally based on complete lock permissions, guaranteeing data consistency and business continuity. At the same time, the accurate matching of cross-node lock information based on unified identifier parameters also provides a basis for cross-node unlocking operations, further avoiding the problem of file lock residue.

[0053] The following example illustrates a file access request initiated by a Windows client:

[0054] 1. The Windows client accesses the first access node via VIP and initiates a file lock request to that node. After receiving the request, the file sharing service (such as samba_server1) of the first access node assembles the first file lock key based on the Internet Protocol address of the Windows client, the virtual Internet Protocol address of the first access node, the client protocol type, and the random number built into the client protocol. Then, it sends the key to initiate a lock request to the MDS deployed on the metadata management service deployment node.

[0055] 2. After receiving a locking request, the MDS deployed on the metadata management service deployment node first determines whether there is a valid mutex file lock in the shared disk space that overlaps with the byte range of the file lock information. If there is no valid mutex file lock, the complete file lock information (including lock type, locking range, validity period, etc.) containing the first file lock key is persistently stored in the shared disk space. After the samba_server1 of the first access node receives the locking success response returned by the MDS, it synchronously caches the file lock information locally. The locking operation of the Windows client is completed, and file read and write operations can be performed based on the lock permissions.

[0056] 3. When the first access node is abnormal (such as hardware failure or service timeout) or the node load exceeds the preset threshold, the node switching condition is met; after VIP_MGR detects that the connection between the first access node and the virtual Internet Protocol address is broken, it will prioritize switching the mount node of the virtual Internet Protocol address from the first access node to the second access node to ensure that subsequent request routing is not interrupted, and then synchronously notify samba_server1 to clear the local cached file handles.

[0057] 4. samba_server1 identifies the file lock association information that needs to be unbound from the handle and sends an unlock request to the metadata management service deployed on the metadata management service deployment node. After receiving the request, the metadata management service only performs the connection unbinding operation between the first access node and the lock service, without clearing the global file lock information persistently stored in the shared disk space, and at the same time sends a lock service unbinding notification to the first access node. After receiving the notification, the file sharing service of the first access node accurately clears the corresponding file lock information in the local cache, completing the cache clearing process of the old node.

[0058] 5. After the original connection is broken due to the switching of the mount node, the Windows client automatically sends a file reopening request to the second access node to restore the file access connection and corresponding operation permissions. After receiving the request, the file sharing service (such as samba_server2) of the second access node assembles and generates a second file lock key based on the second identification parameters in the request (including the Internet Protocol address of the Windows client, the virtual Internet Protocol address of the second access node, the client protocol type, and the random number built into the client protocol), and sends a lock information query request to the MDS deployed on the metadata management service deployment node with this key.

[0059] 6. The metadata management service deployed on the metadata management service deployment node traverses and queries the shared disk space based on the second file lock key, quickly locates the corresponding global file lock information, and returns it to the file sharing service of the second access node. The file sharing service of the second access node rebuilds the file lock cache locally based on the returned complete lock information. After the file reopening request is processed, the Windows client can perform subsequent file read, write, lock update and other operations normally based on the rebuilt lock cache, ensuring the consistency of file lock status and business continuity throughout the entire switching process.

[0060] In summary, this application redesigns the file lock identifier key to include the client's Internet Protocol address, the corresponding access node's virtual Internet Protocol address, the client's protocol type, and a protocol random number. This satisfies the compatibility requirements of network file system protocols and general Internet file system protocols, while ensuring that any access node can accurately identify the lock's identity. By persistently storing the file lock information and identifier key together in shared disk space, the problem of file lock loss in node failure scenarios is avoided. The virtual Internet Protocol address management service triggers the old node's file lock cache cleanup operation, ensuring that no invalid lock information remains on the old node after access node switching. Furthermore, the file lock cache reconstruction process is embedded in the client-initiated file reopening request processing, achieving cross-node lock cache reconstruction without the client's awareness. Ultimately, through the above steps, the problem of file lock loss and residue in distributed cluster access node switching scenarios is solved collaboratively, ensuring the high availability of file lock features.

[0061] This application provides a file lock management method for a distributed file system, comprising: after receiving a first file access request initiated by a client to a first access node, constructing first file lock information based on a first identifier parameter in the first file access request, persistently storing the first file lock information in a shared disk space, and caching the first file lock information locally on the first access node; wherein, the access node is the mount node for the client to access the distributed file system; if it is necessary to switch the mount node, switching the mount node from the first access node to a second access node, and clearing the first file lock information cached locally on the first access node; after receiving a second file access request initiated by a client to the second access node, querying the corresponding first file lock information in the shared disk space based on the second identifier parameter in the second file access request, and rebuilding the file lock cache locally on the second access node based on the first file lock information; wherein, the first file access request and the second file access request are used to access the same target file.

[0062] In summary, upon receiving a first file access request from a client to the first access node, this application constructs first file lock information based on the first identifier parameter in the request. This information is then persistently stored on the shared disk space and cached locally on the first access node. The first identifier parameter uniquely corresponds to the same client's access to the same target file. This dual storage mechanism avoids the risk of lock information loss that might occur with single storage and leverages the cross-node access capabilities of the shared disk to provide a reliable data foundation for lock cache reconstruction. When a node switch is required, this application switches the node from the first access node to the second access node and simultaneously clears the first file lock information cached locally on the first access node. This timely clearing of the old node's local lock cache resolves the file lock residue problem during access node switching scenarios. Since both the first and second file access requests are for accessing the same target file, and both the first and second identifier parameters are core identifiers associated with this target file access, upon receiving the second file access request from the client to the second access node, the second access node can accurately match the corresponding first file lock information stored in the shared disk space based on the second identifier parameter, and rebuild the file lock cache locally based on this lock information. The entire process requires no additional lock requests or manual configuration from the client, achieving seamless transition of lock states after node switching, ensuring the integrity and availability of file lock information, effectively avoiding file lock loss and file lock residue issues caused by node switching, thereby guaranteeing data consistency and improving business stability.

[0063] This application also provides a file lock management device, equipment, and medium for a distributed file system, which has the above-mentioned beneficial effects, and will not be elaborated here.

[0064] The file lock management device for the distributed file system provided in this application embodiment is described below.

[0065] Figure 2 This is a schematic diagram of the structure of a file lock management device for a distributed file system provided in an embodiment of this application.

[0066] In this embodiment, the device may include:

[0067] The persistent storage module 100 is used to construct first file lock information based on the first identifier parameter in the first file access request after receiving a first file access request initiated by the client to the first access node, and persistently store the first file lock information to the shared disk space and cache the first file lock information locally on the first access node; wherein, the access node is the mount node for the client to access the distributed file system;

[0068] The switching and cleaning module 200 is used to switch the mounted node from the first access node to the second access node if it is necessary to switch the mounted node, and clear the first file lock information cached locally on the first access node.

[0069] The file lock cache reconstruction module 300 is used to, after receiving a second file access request initiated by the client to the second access node, query the corresponding first file lock information in the shared disk space based on the second identifier parameter in the second file access request, and rebuild the file lock cache locally on the second access node according to the first file lock information; wherein, the first file access request and the second file access request are used to access the same target file.

[0070] Figure 3 This is a schematic diagram of the structure of a file lock management device for a distributed file system provided in an embodiment of this application.

[0071] This application embodiment also provides a file lock management device for a distributed file system, the device may include:

[0072] Memory, used to store computer programs;

[0073] A processor is configured to implement the steps of the file lock management method for a distributed file system as described in the above embodiments when executing the computer program.

[0074] like Figure 3 The diagram shows the structural composition of a file lock management device for a distributed file system. This device may include a processor 10, a memory 11, a communication interface 12, and a communication bus 13. The processor 10, memory 11, and communication interface 12 all communicate with each other via the communication bus 13.

[0075] In this embodiment, the processor 10 may be a central processing unit (CPU), an application-specific integrated circuit, a digital signal processor, a field-programmable gate array, or other programmable logic devices.

[0076] The processor 10 can call programs stored in the memory 11. Specifically, the processor 10 can execute operations in the embodiment of the file lock management method of the distributed file system.

[0077] The memory 11 is used to store one or more programs. The programs may include program code, which includes computer operation instructions. In this embodiment, the memory 11 stores at least a program for implementing the following functions:

[0078] After receiving the first file access request initiated by the client to the first access node, the first file lock information is constructed based on the first identifier parameter in the first file access request, and the first file lock information is persistently stored in the shared disk space and cached locally on the first access node; wherein, the access node is the mount node for the client to access the distributed file system;

[0079] If it is necessary to switch the mounted node, switch the mounted node from the first access node to the second access node, and clear the first file lock information cached locally on the first access node;

[0080] Upon receiving a second file access request initiated by the client to the second access node, the system queries the corresponding first file lock information in the shared disk space based on the second identifier parameter in the second file access request, and rebuilds the file lock cache locally on the second access node according to the first file lock information; wherein, the first file access request and the second file access request are used to access the same target file.

[0081] In one possible implementation, the memory 11 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; and the data storage area may store data created during use.

[0082] In addition, memory 11 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device or other volatile solid-state storage device.

[0083] Communication interface 12 can be an interface for the communication module, used to connect with other devices or systems.

[0084] Of course, it should be noted that, Figure 3 The structure shown does not constitute a limitation on the file lock management device of the distributed file system in the embodiments of this application. In practical applications, the file lock management device of the distributed file system may include more than Figure 3 More or fewer components as shown, or combinations of certain components.

[0085] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the file lock management method of the distributed file system as described in the above embodiments.

[0086] The computer-readable storage medium may include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0087] For a description of the computer-readable storage medium provided in this application, please refer to the above method embodiments; further details will not be repeated here.

[0088] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0089] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0090] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0091] The foregoing has provided a detailed description of a file lock management method, apparatus, device, and medium for a distributed file system provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A file lock management method for a distributed file system, characterized in that, include: After receiving the first file access request initiated by the client to the first access node, the first file lock information is constructed based on the first identifier parameter in the first file access request, and the first file lock information is persistently stored in the shared disk space and cached locally on the first access node; wherein, the access node is the mount node for the client to access the distributed file system; If it is necessary to switch the mounted node, switch the mounted node from the first access node to the second access node, and clear the first file lock information cached locally on the first access node; Upon receiving a second file access request initiated by the client to the second access node, the system queries the corresponding first file lock information in the shared disk space based on the second identifier parameter in the second file access request, and rebuilds the file lock cache locally on the second access node according to the first file lock information; wherein, the first file access request and the second file access request are used to access the same target file.

2. The file lock management method for a distributed file system according to claim 1, characterized in that, The first file lock information includes a file lock key value, which is constructed based on the client's Internet Protocol address, the virtual Internet Protocol address of the corresponding access node, the protocol type of the client protocol, and the protocol random number of the client protocol; wherein, the client protocol is the file sharing network protocol used by the client when accessing the distributed file system; the protocol random number is used to represent the mapping relationship between the target file and the file lock.

3. The file lock management method for a distributed file system according to claim 1, characterized in that, If it is necessary to switch the mounted node, the mounted node is switched from the first access node to the second access node, and the first file lock information cached locally on the first access node is cleared, including: If it is necessary to switch the mounted node, the mounted node is switched from the first access node to the second access node through virtual IP migration, and the file handle of the target file that has been opened on the first access node is closed, and the first file lock information cached locally on the first access node is cleared.

4. The file lock management method for a distributed file system according to claim 2, characterized in that, The client protocol includes the Network File System Protocol or the General Internet File System Protocol.

5. The file lock management method for a distributed file system according to claim 1, characterized in that, File access requests include file lock requests and file reopen requests. The file reopen request is a request initiated by the client to restore the file access connection and corresponding operation permissions after the original connection is broken due to the switching of the mount node. The reconstruction process of the file lock cache is completed synchronously during the processing of the file reopen request.

6. The file lock management method for a distributed file system according to any one of claims 1 to 5, characterized in that, The step of persistently storing the first file lock information to the shared disk space includes: Determine whether there is a valid mutually exclusive file lock that overlaps with the byte range of the first file lock information; If there is no valid mutex type file lock that overlaps with the byte range of the first file lock information, then the first file lock information is persistently stored in the shared disk space.

7. The file lock management method for a distributed file system according to claim 6, characterized in that, The valid mutex type file lock is a file lock that has been persistently stored and has not exceeded the preset time limit.

8. A file lock management device for a distributed file system, characterized in that, include: The persistent storage module is used to construct first file lock information based on the first identifier parameter in the first file access request after receiving the first file access request initiated by the client to the first access node, and persistently store the first file lock information to the shared disk space and cache the first file lock information locally on the first access node; wherein, the access node is the mount node for the client to access the distributed file system; The switching and cleaning module is used to switch the mounted node from the first access node to the second access node if it is necessary to switch the mounted node, and to clear the first file lock information cached locally on the first access node. The file lock cache reconstruction module is used to, upon receiving a second file access request initiated by a client to the second access node, query the corresponding first file lock information in the shared disk space based on the second identifier parameter in the second file access request, and reconstruct the file lock cache locally on the second access node according to the first file lock information; wherein, the first file access request and the second file access request are used to access the same target file.

9. A file lock management device for a distributed file system, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the file lock management method of the distributed file system as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the file lock management steps of the distributed file system as described in any one of claims 1 to 7.

Images