Distributed data storage control methods, devices and electronic equipment

Abstract

This disclosure provides a distributed data storage control method, apparatus, and electronic device. The method includes: receiving an access request for a target file in a NAS cluster through a proxy node, and determining the target metadata corresponding to the access request; determining whether the target metadata needs to be synchronized and valid with a target metadata distributed lock based on the target file's metadata and distributed lock setting information; if it is determined that the target metadata needs to be synchronized and valid with the target metadata distributed lock, and the current target metadata distributed lock is invalid, sending a first lock request to a distributed lock management node; the distributed lock management node responding to the receipt of the first lock request by configuring a target metadata distributed lock for the access request and returning response information to the proxy node; and controlling the access request for the target file in the NAS cluster based on the target metadata distributed lock. This solves the problem of inconsistency between the proxy node and the metadata in the NAS cluster.

Description

Technical Field

[0001] This disclosure relates to the field of Internet technology, and in particular to a distributed data storage control method, apparatus, and electronic device. Background Technology

[0002] Network Attached Storage (NAS) clusters can store and share files. NAS clusters provide users with access to and management of stored files over a network. NAS storage devices can be directly connected to an Ethernet network, and proxy nodes can be set up between the NAS cluster and the client. The proxy node can retrieve file data from the NAS and cache this data. When a user requests this data, the proxy node can provide the service to the client from the cache.

[0003] Due to the concurrency of proxy nodes accessing the NAS cluster (including modifying file data in the NAS cluster), there is currently an issue of inconsistency between the proxy nodes and the data stored in the NAS cluster. Summary of the Invention

[0004] This disclosure provides a distributed data storage control method, apparatus, and electronic device.

[0005] In a first aspect, embodiments of this disclosure provide a distributed data storage control method, the method comprising: receiving an access request for a target file in a network attached storage (NAS) cluster via a proxy node, and determining the target metadata corresponding to the access request; determining, via the proxy node, whether the target metadata needs to be synchronized and valid with a target metadata distributed lock based on the target file's metadata and distributed lock setting information; if it is determined that the target metadata needs to be synchronized and valid with the target metadata distributed lock, and if the proxy node determines that the current target metadata distributed lock is invalid based on the attribute value of the target metadata distributed lock, sending a first lock request to a distributed lock management node; wherein the first lock request is used to request the reallocation of a target metadata distributed lock for the target metadata; the target metadata distributed lock is used to control exclusive access to the target metadata shared in the NAS cluster; in response to receiving the first lock request, the distributed lock management node configures the target metadata distributed lock for the access request and returns response information to the proxy node, the response information indicating that the target metadata distributed lock was successfully configured for the access request; and controlling access requests to the target file in the NAS cluster based on the target metadata distributed lock.

[0006] Secondly, embodiments of this disclosure provide a distributed data storage control device, comprising: a first receiving unit, configured to receive an access request for a target file in a network attached storage (NAS) cluster via a proxy node, and determine the target metadata corresponding to the access request; a first determining unit, configured to determine, via the proxy node, whether the target metadata needs to be synchronized and valid with a target metadata distributed lock based on the target file's metadata and distributed lock setting information; and a first sending unit, configured to, if the proxy node determines that the current target metadata distributed lock is invalid based on the attribute value of the target metadata distributed lock, send a request to the first receiving unit, provided that the target metadata needs to be synchronized and valid with the target metadata distributed lock. A distributed lock management node sends a first lock request; wherein the first lock request is used to request the reallocation of a target metadata distributed lock for the target metadata; the target metadata distributed lock is used to control exclusive access to the target metadata shared in the NAS cluster; a first locking unit is used to, in response to receiving the first lock request, configure the target metadata distributed lock for the access request through the distributed lock management node, and return response information to the proxy node, the response information indicating that the target metadata distributed lock was successfully configured for the access request; a first execution unit is used to control access requests to the target file in the NAS cluster based on the target metadata distributed lock.

[0007] Thirdly, embodiments of this disclosure provide an electronic device, including: a processor and a memory; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory, causing the at least one processor to perform the methods described in the first aspect and various possible methods described in the first aspect.

[0008] Fourthly, embodiments of this disclosure provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the first aspect and various possible methods described above.

[0009] Fifthly, embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the methods described in the first aspect and various possible methods of the first aspect.

[0010] The distributed data storage control method, apparatus, and electronic device disclosed herein receive access requests for target files in a network attached storage (NAS) cluster via a proxy node, and determine the target metadata corresponding to the access request. The proxy node, based on the target file's metadata and distributed lock settings, determines whether the target metadata needs to be synchronized with a target metadata distributed lock. If the proxy node determines that the target metadata needs to be synchronized with the target metadata distributed lock, and if the proxy node determines that the current target metadata distributed lock is invalid based on its attribute value, it sends a first lock request to the distributed lock management node. The first lock request requests the reallocation of the target metadata distributed lock for the target metadata. The target metadata distributed lock controls exclusive access to the shared target metadata in the NAS cluster. Upon receiving the first lock request, the distributed lock management node configures the target metadata distributed lock for the access request and returns response information to the proxy node, indicating that the target metadata distributed lock was successfully configured for the access request. Access requests to the target file in the NAS cluster are controlled based on the target metadata distributed lock. This solves the problem of inconsistent metadata between the proxy node and the NAS cluster. In addition, fine-grained distributed locks are made into metadata distributed locks, which can improve the concurrency of different accesses to different metadata in the NAS cluster. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this disclosure 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 some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of an application scenario;

[0013] Figure 2 Flowchart of the distributed data storage control method provided in the embodiments of this disclosure Figure 1 ;

[0014] Figure 3 Flowchart of the distributed data storage control method provided in this disclosure Figure 2 ;

[0015] Figure 4 A schematic structural block diagram of a distributed data storage control device provided in an embodiment of this disclosure;

[0016] Figure 5This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

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

[0018] Please refer to Figure 1 , Figure 1 This is a diagram illustrating an application scenario. For example... Figure 1 As shown, the NAS cluster includes multiple block service nodes (BlockServer, or BS for short) and distributed lock control nodes. Additionally, multiple proxy nodes are set up between the NAS cluster and multiple clients. Each proxy node can receive access requests from multiple clients and forward these requests to the NAS cluster, thereby alleviating the pressure of concurrent access requests in the NAS cluster.

[0019] Files can include different file attributes, also known as metadata. File metadata includes: size, file open mode, owner ID (user id, uid), group ID (group id, gid), access control list (ACL), link attribute, extended attribute (xattr), last access time (atime), last change time (ctime), last modify time, etc.

[0020] The BS (Browser / Server) is responsible for file read / write operations and storing file content. In some embodiments, the BS is also responsible for file size metadata, modification time, and status modification time.

[0021] File access requests include, but are not limited to: creating a file (create), creating a directory (make directories, mkdir), and requests to get file attributes (Getattr), set file attributes (Setattr), read file content (read), and write file content (write).

[0022] The above-mentioned functions for files, such as creat, mkdir, Getattr, Setatt, read, and write, require interaction with the BS.

[0023] The proxy node can cache file metadata to alleviate the excessive resource consumption of retrieving file attributes from the NAS cluster. However, since file write operations can occur at any time in a distributed NAS cluster, the file metadata cached in the proxy node may be inconsistent with the metadata in the NAS cluster.

[0024] Therefore, current NAS clusters suffer from excessive hardware resource consumption by proxy nodes, making it impossible to guarantee consistency.

[0025] In this disclosure, after receiving an access request for a file, the proxy node determines the target metadata corresponding to the access request. If the target metadata needs to be synchronized and valid with the distributed lock, the distributed lock management node configures the corresponding metadata distributed lock for the access request. The proxy node accesses the target file according to the access request holding the metadata distributed lock. Due to the mutual exclusion of the metadata distributed lock, the target metadata of the target file obtained by the proxy node due to the access request is consistent with the real metadata in the NAS cluster, thereby solving the consistency problem.

[0026] Please refer to Figure 2 , Figure 2 A flowchart illustrating the distributed data storage control method provided in this disclosure is shown. Figure 1 .like Figure 2 As shown, the method includes the following steps:

[0027] S201: Receive access requests for target files in the network-attached storage (NAS) cluster through the proxy node, and determine the target metadata corresponding to the access request.

[0028] S202: Based on the target file's metadata and distributed lock settings, the proxy node determines whether the target metadata needs to be synchronized and valid with the target metadata distributed lock.

[0029] S203: If it is determined that the target metadata needs to be synchronized and valid with the target metadata distributed lock, and if the agent node determines that the current target metadata distributed lock is invalid based on the attribute value of the target metadata distributed lock, it sends a first lock request to the distributed lock management node; wherein, the first lock request is used to request the reallocation of the target metadata distributed lock for the target metadata; the target metadata distributed lock is used to control exclusive access to the target metadata shared in the NAS cluster.

[0030] S204: Upon receiving the first lock request, the distributed lock management node configures the target metadata distributed lock for the access request and returns response information to the proxy node, indicating that the target metadata distributed lock was successfully configured for the access request.

[0031] S205: Controls access requests to target files in the NAS cluster based on a distributed lock that controls the target metadata.

[0032] In this disclosure, the NAS cluster may include BS nodes and distributed lock management nodes. The number of BS nodes may be multiple. The distributed lock management nodes may include multiple distributed lock management nodes in a master-slave configuration. The distributed lock management nodes are responsible for allocating and managing metadata distributed locks. Furthermore, the distributed lock management nodes store metadata information for files within the NAS cluster.

[0033] Multiple proxy nodes can be configured between the NAS cluster and multiple clients. Each proxy node can be used to distribute access requests from multiple clients to the NAS cluster through load balancing.

[0034] The proxy node here can be any one of multiple proxy nodes. The target file mentioned above can be any file among multiple files providing shared services in the NAS cluster.

[0035] The above access request can be an access request from a client.

[0036] Access requests from clients can request arbitrary operations on files in the NAS cluster, such as reading file content, writing file content, or reading file metadata.

[0037] After receiving an access request from a client, the proxy node can determine the target metadata corresponding to the access request.

[0038] Different access requests can be associated with different metadata. For example, a write request that writes to the contents of a target file, or a read request that reads from the contents of a file, is associated with the target file's size metadata. Similarly, an access request to retrieve the file's modification time (mtime) corresponds to the mtime metadata.

[0039] Each access request can be associated with one or more metadata. For example, an access request can specify reading or modifying one or more metadata of a file. Similarly, write and read operations on file content are typically associated with metadata such as the target file's size and modification time.

[0040] In other words, the target metadata can be explicitly stated in the above access request, or the target metadata corresponding to the access request can be determined by the operation to be performed on the target file in the access request.

[0041] After determining the target metadata corresponding to the aforementioned access request, it can be determined whether the target metadata needs to be synchronized and valid with the distributed lock. The aforementioned metadata must be synchronized and valid with the distributed lock. During the period the distributed lock is valid, the target data obtained by the distributed lock is valid; after the distributed lock is revoked, the metadata obtained by the distributed lock becomes invalid.

[0042] The proxy node can store file metadata and distributed lock settings. The settings include the metadata distributed locks corresponding to different metadata, as well as information on whether different metadata needs to be synchronized with the corresponding metadata distributed locks.

[0043] Once the proxy node determines the target metadata related to the above access request, it can use the locally stored metadata and distributed lock settings to determine the target metadata distributed lock corresponding to the target metadata, and whether the target metadata needs to be synchronized and valid with the target metadata distributed lock.

[0044] After confirming that the aforementioned target metadata must be synchronized and valid with the target metadata distributed lock, the proxy node can determine whether its own target metadata distributed lock is currently valid. This can be determined by the attribute values ​​of the target metadata distributed lock. These attribute values ​​include "valid" and "invalid."

[0045] If successful, step S205 can be executed.

[0046] Otherwise, a first lock request needs to be sent to the distributed lock management node. This first lock request requests the distributed lock management node to configure a distributed lock for the access request. The first lock request may include information about the target metadata distributed lock. Upon receiving the first lock request, the distributed lock management node checks if there is an existing lock mutually exclusive with the requested target metadata distributed lock. If so, the distributed lock management node can send a revocation request to other proxy nodes holding the existing lock. Upon receiving the revocation request, the proxy nodes holding the existing lock respond by destroying their local lock. After revoking the existing lock, the distributed lock management node can configure the corresponding target metadata distributed lock for the access request.

[0047] To improve concurrency, different metadata distributed locks can be pre-configured, each corresponding to a different group of metadata. These different metadata distributed locks include:

[0048] Distributed locks for file size metadata, file permission metadata, hard link metadata, directory modification time metadata, and file extended attribute metadata; each metadata distributed lock corresponds to a set of metadata.

[0049] Each group of metadata includes one or more metadata items. These metadata groups include: file size metadata, file permission metadata, directory and file hard link metadata, directory modification time metadata, and file extended attribute metadata.

[0050] The file size group includes file size metadata. The file permission metadata group includes metadata such as mode, uid, gid, and acl. This metadata is modified infrequently and is related to file permissions (AUTH), therefore it belongs to the AUTH group, and a distributed lock (AUTH_LOCK) is used to ensure consistency. The directory and file hard link metadata group includes directory and file hard link metadata, and a distributed lock (LINK_LOCK) is used to ensure consistency of directory and file hard links. The directory modification time metadata group can include directory modification time metadata, and a directory modification time metadata lock (DIR_MTIME_LOCK) is used to ensure directory mtime consistency. The file extension metadata group includes file extension metadata (XATTR), and a file extension attribute metadata lock (XATTR_LOCK) is used to ensure consistency of file extension metadata.

[0051] In these embodiments, different metadata distributed locks are set, and different metadata distributed locks correspond to different groups of metadata. This can ensure that each group of metadata in the NAS cluster is consistent with each group of metadata cached in the proxy node. In addition, different proxy nodes can concurrently access different groups of metadata in the NAS cluster according to different metadata distributed locks, which can improve the concurrency of the NAS cluster.

[0052] After configuring the corresponding target metadata distributed lock for the access request, the distributed lock management node can send a response message to the proxy node. This response message indicates that the access request was successfully acquired using the corresponding target metadata distributed lock; that is, the proxy node holds the target metadata distributed lock for the access request. After holding this target metadata distributed lock, the proxy node can perform the operations related to the target metadata in the access request on the target files of the NAS cluster.

[0053] In distributed systems, distributed locks are used to control exclusive access to shared metadata in a NAS cluster, protecting the consistency of distributed caches across different agent nodes. In this embodiment, the metadata distributed lock and metadata synchronization are valid. When the agent node's distributed lock is valid, it can cache metadata; when the agent node's distributed lock is valid, the cached metadata is valid. When the agent node's distributed lock is invalid, the cached metadata can be cleared.

[0054] In this embodiment, for access requests to modify the metadata of a target file, a target metadata distributed lock ensures the mutual exclusion of access requests from different proxy nodes to access the target metadata of the target file at the same time. That is, the target metadata distributed lock guarantees that among multiple access requests to the target metadata of the target file on different nodes, only one access request is valid at any given time; that is, the access request with the target metadata distributed lock is valid.

[0055] The proxy node sends an access request to the NAS cluster based on its held target metadata distributed lock to perform direct operations on the target file. If the NAS cluster updates the target metadata accordingly, the proxy node can retrieve the updated target metadata from the NAS cluster and cache it locally. If the NAS cluster does not update the target metadata based on the access request, the proxy node can retrieve the target metadata from the NAS cluster (distributed lock control node) and associate its held target metadata distributed lock with the retrieved target metadata for storage.

[0056] The proxy node can associate and store a distributed lock on the target metadata it holds, as well as the target metadata obtained based on the distributed lock. When subsequent access requests from clients require the target metadata, the locally cached target metadata can be sent to the client. This reduces the resource consumption of the NAS cluster in processing access requests.

[0057] When a proxy node receives a revocation request to revoke the target metadata distributed lock, it can invalidate the local target metadata distributed lock and clear the target metadata cached locally.

[0058] Taking a request to retrieve file size metadata as an example, proxy node 1 sends a file size metadata distributed read lock request to the distributed lock management node. The distributed lock management node can configure a file size metadata distributed lock for proxy node 1's file size metadata retrieval request. Proxy node 1 retrieves the file size metadata from the distributed lock management node based on the file size metadata retrieval request configured with the file size metadata distributed lock. Proxy node 1 stores the file size metadata and the file size metadata distributed lock in its cache. Subsequently, when proxy node 1 receives an access request from a client wanting to retrieve the target file's target metadata, proxy node 1 can check if the file size metadata distributed lock in the cache is valid. If valid, it directly uses the file size metadata stored in the cache. The distributed lock management node will only revoke proxy node 1's file size metadata distributed lock when another proxy node 2 attempts to modify the target file's file size metadata. After receiving the revocation request from the distributed lock management node, proxy node 1 needs to clear the associated file size metadata distributed lock and file size metadata from the cache. Subsequently, when receiving a client access request requiring file size metadata, it needs to re-apply for the file size metadata distributed lock from the distributed lock management node.

[0059] The proxy node synchronizes the target metadata with a distributed lock, ensuring the target metadata cached by the proxy node is valid while the distributed lock is active. If the distributed lock is revoked on a proxy node, another proxy node may hold the same lock, potentially altering the target metadata in the NAS cluster. Therefore, after the distributed lock is revoked, the target metadata obtained based on that lock must also be cleared. This ensures that the proxy node does not have inconsistent target metadata with the NAS cluster.

[0060] In this embodiment, for target metadata that needs to be synchronized and valid with the metadata distributed lock, when an access request related to the target metadata needs to be executed, if the local target metadata distributed lock is invalid, a metadata distributed lock needs to be requested from the distributed lock management node. After the metadata distributed lock of the proxy node is revoked, the target metadata obtained by the proxy node is also invalid, thereby ensuring the consistency between the target metadata in the proxy node and the first metadata in the NAS.

[0061] In some embodiments, the method further includes:

[0062] In response to the access request, the target metadata was updated. The proxy node cached the updated target metadata and synchronized it to the distributed lock management node, which stores the target file's metadata.

[0063] In related technologies, the file size and modification time (mtime) of a file are stored in a Base Window (BS). When writing file content to a BS node, the file content to be written is usually divided into multiple segments, and each segment is assigned a BS. Assuming the file content is divided into 16 segments, each of these 16 segments is written to its corresponding BS; that is, the file is written to 16 BSs according to different segments. For example, BS1 writes [0M, 2M), BS2 writes [2M, 4M), BS3 writes [4M, 6M), ..., BS16 writes [14M, 16M). Each BS stores the file size as a range of sizes to be written to its own file; for example, BS1 stores the file size range as [0M, 2M), along with the modification time t1 for that range. For a single file, only one BS records the final file size. However, since it's unknown which BS records the last range of the file, when a request to retrieve the file size is received, the proxy node needs to send file size retrieval requests to multiple BSs corresponding to the file, and then receive the file size and modification time returned from each BS. The proxy node can determine the maximum value from the returned file sizes and use that as the file size. Therefore, the proxy node sends a large number of file size retrieval requests, resulting in significant resource consumption for both the proxy node and the NAS cluster. If one or more BSs experience long-tail latency in their responses to file size retrieval requests, the entire request process will be slowed down. In other words, the resource consumption for the proxy node and the NAS cluster in responding to client metadata retrieval requests is excessive.

[0064] In this embodiment, the distributed lock management node of the NAS cluster stores all metadata of files in the NAS cluster. That is, the file size metadata and modification time metadata originally recorded by the BS are also transferred to the distributed lock management node for storage. In this way, when the proxy node obtains any metadata information of the target file, it does not need to interact with the BS. This avoids the need for the proxy node to access multiple BSs to obtain accurate metadata information when different parts of the same metadata are distributed across different BSs. This reduces the number of access requests that the proxy node needs to issue to obtain metadata, thus reducing the resource consumption of the proxy node. Simultaneously, it also reduces the total number of access requests received and processed by the NAS cluster, resulting in an overall reduction in the NAS cluster's resource consumption.

[0065] Furthermore, the distributed lock management node is responsible for configuring distributed locks for metadata for each access request and for revoking configured distributed locks for metadata. When a proxy node receives an access request related to the target metadata of a file, it can request the corresponding distributed lock for that metadata from the distributed lock management node. Since the distributed lock management node is responsible for configuring and revoking the distributed locks for metadata, there is no need to set up a separate service node for distributed lock services. Additionally, because the distributed lock management node stores all the file's metadata, when making a read request for the target metadata stored in the distributed lock management node, it only needs to retrieve the file's target metadata from the distributed lock management node itself, eliminating the need to access multiple browser windows (BSs) to obtain the file's target metadata. This reduces the total number of requests sent by the proxy node to the NAS, thereby reducing the overall resource consumption of the proxy node and the NAS cluster.

[0066] Furthermore, due to the file update visibility requirement—that is, when a client opens a file, it should have the latest version of that file—the agent node must return the latest file attributes of the target file when it receives a client's request to open the target file; this is known as close-to-open (CTO) semantics. Since the distributed lock control node stores all metadata of shared files in the NAS cluster, and the total number of requests sent by the agent node to the NAS cluster is reduced, the agent node has more resources to meet the update visibility requirement.

[0067] In some embodiments, the above method further includes the following:

[0068] The proxy node responds to determine that the target metadata does not need to be synchronized with the target metadata distributed lock, and generates response information for the access request from the locally cached target metadata;

[0069] The target metadata cached locally is updated periodically.

[0070] In this embodiment, the metadata that does not need to be synchronized with the target metadata distributed lock can be the metadata of files that are modified frequently and have low priority.

[0071] To illustrate, the metadata that does not need to be synchronized with the target metadata distributed lock includes access time, modification time, and change time.

[0072] The target metadata mentioned above can be any one or more of the access time, modification time, and change time mentioned above.

[0073] In these embodiments, it is not necessary to synchronize valid metadata with the target metadata distributed lock. Even after the metadata distributed lock is revoked, the metadata obtained by the proxy node through the metadata distributed lock may still be valid. The validity period of the metadata can be set. If the proxy node detects that its continuous storage time for this metadata exceeds a preset duration, it invalidates the locally stored metadata and automatically retrieves it from the distributed lock management node. That is, the proxy node periodically updates this metadata to ensure consistency with the metadata in the distributed lock management node. This reduces the resource consumption on the distributed lock management node caused by frequent configuration and revocation of metadata distributed locks.

[0074] In some embodiments, step S203 includes: if the access request does not directly or indirectly update the file size, sending a first lock request for the target metadata distributed read lock to the distributed lock management node.

[0075] The target metadata corresponding to the aforementioned access request can be any metadata that needs to be synchronized and valid with the target metadata distributed lock. After determining that the file size of the target file will not be updated, the proxy node can determine that the target metadata distributed lock is a target metadata distributed read lock. The aforementioned proxy node can request the target metadata distributed read lock from the distributed lock management node for the aforementioned access request. For metadata distributed locks corresponding to the same metadata, metadata distributed read locks are compatible with each other, while metadata distributed write locks are mutually exclusive with metadata distributed write locks and metadata distributed read locks.

[0076] Taking AUTH group metadata as an example, when proxy node 1 modifies the file mode metadata and requests an AUTH write lock from the distributed lock management node, the distributed lock management node revokes the AUTH read lock held by proxy node 2. Subsequently, when proxy node 2 wants to obtain the mode metadata, it needs to re-request the AUTH read lock. The distributed lock management node then revokes the write lock on file size metadata 1. If proxy node 1 needs the mode file size metadata again, it needs to request an AUTH read lock from the distributed lock management node again. The entire process involves a total of 5 lock interactions, which is overly cumbersome and reduces the performance of metadata requests.

[0077] For access requests that do not update the file size, using the metadata-distributed read lock corresponding to the metadata of the access request can improve the resource consumption caused by invalid lock interactions.

[0078] In some embodiments, step S203 includes:

[0079] In response to the determination that the access request directly or indirectly changes the file size of the target file, a first lock request for a file size metadata write lock is sent to the distributed lock management node. This first lock request is used to request a distributed write lock for the file size metadata.

[0080] File size metadata is the most important attribute of a file and is modified frequently, so a distributed lock (size lock) can be set for it. The types of distributed locks for file size metadata can include read locks and write locks.

[0081] Since operations on file size involve operations on file content in the BS, write locks and read locks are set for the file size metadata distributed lock.

[0082] Specifically, the size lock type can be determined based on whether the access request directly or indirectly modifies the file size metadata of the target file. For example, if the operation described above requires modification of the file content, the size lock can be identified as a write lock (i.e., a distributed write lock for file size metadata). If the operation described above requires reading the file content, the size lock can be identified as a read lock (i.e., a distributed read lock for file size metadata).

[0083] The distributed metadata write lock is mutually exclusive with other metadata locks (write locks are mutually exclusive with each other, and write locks are mutually exclusive with read locks), ensuring that only one proxy node can have a valid access request for file size metadata at any given time.

[0084] The aforementioned access request to change the file size metadata of the target file is either an append write request to add new content to the target file, or a metadata update request to update the size metadata.

[0085] When a proxy node initiates an append write request or a file size metadata update request, it needs to request a file size metadata write lock from the distributed lock control node.

[0086] The above operations modify the file size, requiring a write lock on the file size metadata. Upon receiving a request from a proxy node for a write lock on the file size metadata, the distributed lock management node first revokes any read or write locks allocated to other proxy nodes, and then assigns a write lock on the file size metadata to that proxy node. Because the proxy node holding the write lock on the file size metadata modifies the file size metadata and updates the modification time and state change time, the latest file size metadata, modification time, and state change time need to be synchronized with the distributed lock management node whenever the file size metadata is updated.

[0087] Agent node 1 holds a distributed write lock for file size metadata. If agent node 2 requests a distributed read lock for file size metadata from the distributed lock control node, the distributed lock control node revokes agent node 1's distributed write lock for file size metadata and allocates a distributed read lock for file size metadata to agent node 2. In this application, "agent node holding a distributed lock" means that the agent node's distributed lock is valid.

[0088] If proxy node 1 holds a distributed read lock for file size metadata, and proxy node 2 requests a distributed write lock for file size metadata: the distributed lock control node revokes the distributed read lock for file size metadata of proxy node 1 and assigns a distributed write lock for file size metadata to the proxy node.

[0089] If proxy node 1 holds a distributed write lock for file size metadata, and proxy node 2 requests a distributed write lock for file size metadata, the distributed lock control node revokes the distributed write lock for file size metadata from proxy node 1 and allocates the distributed write lock for file size metadata to proxy node 2.

[0090] If the file size metadata of the target file is updated based on the access request, a write lock is applied to the file size metadata of the access request configuration file. Due to the mutual exclusion of distributed locks for different file size metadata, it can be ensured that only one of the access requests from multiple proxy nodes that directly or indirectly update the file size metadata is valid, thereby guaranteeing the consistency of file size metadata between the proxy nodes and the NAS cluster.

[0091] In some embodiments, the access request is a read request instructing the reading of the target file content, and the target metadata distributed lock is a size metadata distributed read lock. Prior to step S205 above, the method further includes the following steps:

[0092] First, check whether the access range indicated by the read request exceeds the file size of the target file;

[0093] Secondly, in response to the detection that the file range exceeds the file size of the target file, the access range corresponding to the access request is modified so that the modified access range falls within the file size of the target file.

[0094] A read request for the contents of a target file may include an access range of the target file content to be read. This access range may include, for example, a starting offset and a size to be read. The starting offset may be an offset equivalent to the beginning of the entire target file. For example, the starting offset could be 2MB. The size to be read could be the length of the file content to be read. Illustratively, the starting offset could be 2MB, and the size to be read could be 5MB. The access range to be read could be the [2MB, 7MB] portion of the target file content.

[0095] The aforementioned proxy node can obtain the file size of the target file from the distributed lock management node. Taking the access request request as an example, where the target file's content is [2M, 7M]. If the target file size obtained from the distributed lock management node is 8M, then the access request does not exceed the target file size. The proxy node can then send an access request to the BS of the NAS cluster to read the target file's content of [2M, 7M]. If the target file size obtained from the distributed lock management node is 6M, then the range corresponding to the access request exceeds the target file size. The proxy node resets the upper limit of the access range in the aforementioned access request. For example, it resets the access range from [2M, 7M] to [2M, 6M].

[0096] In these embodiments, the access range of read access requests that exceed the file size is adjusted by the proxy node, so that the access request is not invalidated due to exceeding the size, which can improve the response efficiency of the access request.

[0097] Please refer to Figure 3 , Figure 3 Flowchart of the distributed data storage control method provided in this disclosure Figure 2 .like Figure 3 As shown, the method includes the following steps:

[0098] S301: Receives access requests for target files in the network-attached storage (NAS) cluster through the proxy node and determines the target metadata corresponding to the access request.

[0099] S302: The proxy node determines whether the target metadata needs to be synchronized and valid with the target metadata distributed lock based on the target file's metadata and distributed lock settings; where the access request is a write request to write file content to the target file, the target metadata is file size metadata, and the file size metadata needs to be synchronized and valid with the file size metadata.

[0100] S303: If the agent node determines that the current size metadata distributed lock is invalid based on the attribute value of the size metadata distributed lock, it reads the first file size of the target file from the distributed lock control node through the file size metadata distributed read lock.

[0101] S304: In response to determining that the size of the second file indicated by the write request is greater than the size of the first file of the target file, send a file size metadata write lock request to the distributed lock management node.

[0102] S305: The distributed lock management node configures a file size metadata distributed write lock for the write request based on the file size metadata write lock request, and revokes the file size metadata distributed read lock and / or file size metadata distributed write lock configured for other access requests.

[0103] S306: Distributed write lock control based on file size metadata controls the writing of file content to the target file.

[0104] Upon receiving the access request, the proxy node determines that it is a write request to write file content to the target file. It then first checks whether it holds a distributed read lock for file size metadata. If not, it requests the distributed read lock for file size metadata from the distributed lock management node. After acquiring the distributed read lock for file size metadata, it obtains the first file size from the distributed lock management node. The proxy node then determines whether the write request is an append write based on the second file size corresponding to the write request and the obtained first file size.

[0105] If the write request indicates a second file size greater than the second file size obtained from the distributed lock management node, the write request is an append write. An append write changes the target file size, requiring a distributed write lock on the file size metadata to be acquired for the write request. This means revoking the distributed locks on the file size metadata (including read and write locks) already configured for access requests from other agent nodes, and then acquiring the distributed write lock on the file size metadata for that access request. This ensures that after an indirect change to the target file size, only one valid file size exists in the NAS cluster and on the agent nodes.

[0106] In some embodiments, the access request requests to overwrite the existing content of the target file. This access request is an overwrite write request. The overwrite write request does not modify the file size metadata, so there is no need to add a file size metadata distributed write lock to the overwrite write access request.

[0107] For overwrite write access requests, the file content corresponding to the overwrite write access request is overwritten with the existing content of the target file according to the scope indicated by the overwrite write access request, using the held file size metadata read lock.

[0108] In some embodiments, Figure 2 and Figure 3 The method shown also includes:

[0109] First, the lock identifier of the target metadata distributed lock is determined by the proxy node based on the response information. The lock identifiers of different target metadata distributed locks are incremented according to the order in which the target metadata distributed locks are configured.

[0110] Secondly, determine whether the lock identifier of the target metadata distributed lock is less than the lock identifier of the target metadata distributed lock already held;

[0111] Finally, if so, discard the target metadata distributed lock indicated by the response information.

[0112] For the same metadata, the distributed lock management node can allocate a target metadata distributed lock to different target metadata distributed lock requests from the same proxy node and send response information for each lock request to the proxy node. Due to network congestion and other reasons, the response information received by the proxy node from the distributed lock management node regarding the successful configuration of the target metadata distributed lock for different lock requests may be out of order. If a proxy node requests an AUTH read lock, the distributed lock management node returns the current AUTH read lock 1. However, due to network congestion, AUTH read lock 1 has not yet been sent to the proxy node. At the same time, a concurrent access request from the proxy node completes a modification of the mode metadata, and the proxy node has already cached AUTH read lock 2. Only then does the proxy node receive the response information indicating successful locking of AUTH read lock 1. The proxy node can process this response information, and the AUTH read lock 1 stored in the proxy node will overwrite AUTH read lock 2, that is, an old lock overwrites a new lock in the proxy node.

[0113] To prevent older locks from overwriting newer locks on proxy nodes, the distributed lock management node assigns a lock identifier to each target metadata distributed lock. The lock identifiers for different distributed locks on the same target metadata are incremented according to the order in which they were configured. For example, the distributed lock management node assigns lock identifiers to target metadata distributed locks based on timestamps. The lock identifier can be used to determine whether the target metadata distributed lock corresponding to the response information sent by the distributed lock management node is a new lock or an old lock. Newly received responses with old locks can be discarded to prevent inconsistencies between the target metadata in the proxy node and the actual target metadata in the NAS cluster caused by older target metadata distributed locks replacing newer ones.

[0114] In some embodiments, Figure 2 and Figure 3 The method shown also includes:

[0115] First, the proxy node responds to the received response information and determines whether the target metadata distributed lock has been revoked based on the lock identifier of the target metadata distributed lock indicated in the response information.

[0116] Secondly, if the result is confirmed to be yes, discard the target metadata lock.

[0117] Due to network congestion and other reasons, the response information of the distributed lock management node to different agent nodes regarding distributed read lock requests for the same target metadata may be out of order, which may lead to inconsistencies in the distributed lock records for the same target metadata in the agent nodes and the distributed lock management node. For example, the distributed lock management node allocates an AUTH read lock to agent node 1 and sends a response message indicating that the allocation of the AUTH read lock to agent node 1 was successful. Then, agent node 2 sends a metadata update request to the distributed lock management node to update the mode metadata. The distributed lock management node sends a revocation request to agent node 1 to revoke the AUTH read lock of agent node 1. However, the distributed lock management node cannot guarantee which of the response message indicating the successful allocation of the distributed lock to agent node 1 arrives at agent node 1 first. If agent node 1 receives the revocation request first and then receives the successful lock acquisition response message, agent node 1 will store the old AUTH read lock. Since the distributed lock management node records that the AUTH read lock of agent node 1 has been revoked, agent node 1 no longer has an AUTH read lock. Therefore, a new AUTH read lock is reallocated to agent node 2, resulting in inconsistencies between the metadata distributed lock held by agent node 1 and the metadata distributed lock stored in the distributed lock management node.

[0118] To resolve the inconsistency between the target metadata distributed lock held by proxy node 1 and the target metadata distributed lock stored in the distributed lock management node due to the aforementioned reasons, the proxy node needs to store the lock identifier of the revoked target metadata distributed lock after receiving a revocation request. Upon receiving a response from the distributed lock management node confirming successful allocation of the target metadata distributed lock, the proxy node matches the lock identifier of the target metadata distributed lock in the response with the stored revoked lock identifier. If a match is found, the proxy node discards the target metadata distributed lock corresponding to the aforementioned response.

[0119] Corresponding to the above text Figure 2 The distributed data storage control method of the embodiment, Figure 4 This is a schematic structural block diagram of a distributed data storage control device provided in an embodiment of the present disclosure. For ease of explanation, only the parts relevant to the embodiments of the present disclosure are shown. (Refer to...) Figure 4 The device 40 includes: a first receiving unit 401, a first determining unit 402, a first sending unit 403, a first locking unit 404, and a first execution unit 405.

[0120] The first receiving unit 401 is used to receive access requests for target files in the network attached storage (NAS) cluster through the proxy node and determine the target metadata corresponding to the access request.

[0121] The first determining unit 402 is used to determine, through the proxy node, whether the target metadata needs to be synchronized and valid with the target metadata distributed lock based on the target file's metadata and distributed lock setting information;

[0122] The first sending unit 403 is used to send a first lock request to the distributed lock management node when it is determined that the target metadata needs to be synchronized and valid with the target metadata distributed lock. If the proxy node determines that the current target metadata distributed lock is invalid based on the attribute value of the target metadata distributed lock, the first lock request is used to request the reallocation of the target metadata distributed lock for the target metadata. The target metadata distributed lock is used to control exclusive access to the target metadata shared in the NAS cluster.

[0123] The first locking unit 404 is used to respond to the first lock request received by the distributed lock management node, configure the target metadata distributed lock for the access request, and return response information to the proxy node, the response information indicating that the target metadata distributed lock was successfully configured for the access request.

[0124] The first execution unit 405 is used to control access requests to target files in the NAS cluster based on target metadata distributed lock control.

[0125] In some embodiments, the first execution unit 404 is further configured to:

[0126] In response to the completion of updating the target metadata upon executing the access request, the proxy node caches the updated target metadata and synchronizes the updated target metadata to the distributed lock management node. The distributed lock management node stores the target file's metadata to provide metadata access services to the proxy node.

[0127] In some embodiments, the first transmitting unit 403 is further configured to:

[0128] If the access request does not directly or indirectly update the file size, send the first lock request for the distributed read lock of the target metadata to the distributed lock management node.

[0129] In some embodiments, the first transmitting unit 403 is further configured to:

[0130] In response to determining that the access request directly or indirectly changes the file size of the target file, a first lock request for writing the file size metadata is sent to the distributed lock management node.

[0131] In some embodiments, the apparatus 40 further includes a range modification unit (not shown), which is used before the first sending unit 403 sends the first lock request to the distributed lock management node:

[0132] Check whether the access range indicated by the read request exceeds the file size of the target file;

[0133] In response to the detection that the file range exceeds the file size of the target file, the access range corresponding to the access request is modified so that the modified access range falls within the file size of the target file.

[0134] In some embodiments, the access request is a write request to write file content to the target file, the target metadata is file size metadata, and the file size metadata must be synchronized and valid with the file size metadata. The device 40 also includes a range acquisition unit (not shown in the figure), which is used before the first sending unit 403 sends the first lock request to the distributed lock control node:

[0135] The first file size of the target file is read from the distributed lock control node using the file size metadata distributed read lock; and the first sending unit 403 is further used for:

[0136] In response to the determination that the size of the second file indicated by the write request is greater than the size of the first file of the target file, a file size metadata write lock request is sent to the distributed lock control node;

[0137] The first locking unit 404 is further used for:

[0138] The distributed lock management node, based on the file size metadata write lock request, configures a file size metadata distributed write lock for the write request and revokes the file size metadata distributed read lock and / or file size metadata distributed write lock configured for other access requests; and

[0139] The first execution unit 405 is further used for:

[0140] Distributed write locks based on file size metadata control the writing of file content to the target file.

[0141] In some embodiments, the apparatus 40 further includes a second execution unit (not shown), the second execution unit being used for:

[0142] If the proxy node determines that the target metadata distributed lock is valid, it controls access requests to the target file in the NAS cluster based on the target metadata distributed lock.

[0143] In some embodiments, the apparatus 40 further includes a third execution unit (not shown), the third execution unit being configured to:

[0144] The proxy node responds to determine that the target metadata does not need to be synchronized with the target metadata distributed lock, and generates response information for the access request from the locally cached target metadata;

[0145] The target metadata cached locally is updated periodically.

[0146] In some embodiments, the apparatus 40 further includes a first processing unit (not shown), the first processing unit being configured to:

[0147] The lock identifier of the target metadata distributed lock is determined by the proxy node based on the response information. The lock identifiers of different target metadata distributed locks are incremented according to the order in which the target metadata distributed locks are configured.

[0148] Determine whether the lock identifier of the target metadata distributed lock is less than the lock identifier of the target metadata distributed lock already held;

[0149] If so, the distributed lock indicating the target metadata of the discarded response information is disposed of. In some embodiments, the device 40 further includes a second processing unit (not shown in the figure), the second processing unit being used for:

[0150] Upon receiving the response information, the proxy node determines whether the target metadata distributed lock has been revoked based on the lock identifier of the target metadata distributed lock indicated in the response information.

[0151] If the result is yes, discard the target metadata lock.

[0152] To implement the above embodiments, this disclosure also provides an electronic device.

[0153] refer to Figure 5 It illustrates an electronic device suitable for implementing embodiments of the present disclosure. Figure 5 The diagram shows the structure of the electronic device 500, which can be a terminal device or a server. The terminal device can include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, personal digital assistants (PDAs), portable Android devices (PADs), portable media players (PMPs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0154] like Figure 5As shown, the electronic device 500 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the electronic device 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0155] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0156] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code (computer execution instructions) for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a storage device 508, or installed from a ROM 502. When the computer program is executed by the processing device 501, it performs the functions defined in the methods of embodiments of this disclosure.

[0157] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0158] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0159] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods shown in the above embodiments.

[0160] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed 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 cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0161] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0162] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0163] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0164] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0165] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0166] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0167] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A distributed data storage control method characterized by, The method comprises: receiving, by a proxy node, an access request for a target file in a network attached storage (NAS) cluster, and determining target metadata corresponding to the access request; determining, by the proxy node, whether the target metadata needs to be synchronized with a target metadata distributed lock based on metadata of the target file and distributed lock setting information; if the proxy node determines that the current target metadata distributed lock is invalid according to an attribute value of the target metadata distributed lock, sending a first lock request to a distributed lock management node in a case where it is determined that the target metadata needs to be synchronized with the target metadata distributed lock; the first lock request is used to request re-allocation of the target metadata distributed lock for the target metadata; the target metadata distributed lock is used to control exclusive access to the target metadata shared in the NAS cluster; configuring, by the distributed lock management node, the target metadata distributed lock for the access request in response to receiving the first lock request, and returning response information to the proxy node, the response information indicating that the target metadata distributed lock is successfully configured for the access request; controlling the access request for the target file in the NAS cluster based on the target metadata distributed lock.

2. The method of claim 1, wherein, The method further comprises: in response to completing updating the target metadata according to the access request, the proxy node caches the updated target metadata and synchronizes the updated target metadata to the distributed lock management node, wherein the distributed lock management node stores metadata of the target file to provide metadata access service to the proxy node.

3. The method of claim 1, wherein, if the proxy node determines that the current target metadata distributed lock is invalid, sending the first lock request to the distributed lock management node in a case where it is determined that the target metadata needs to be synchronized with the target metadata distributed lock, comprising: if the access request does not directly or indirectly update the file size, sending a first lock request requesting a target metadata distributed read lock to the distributed lock management node.

4. The method of claim 1, wherein, if the proxy node determines that the current target metadata distributed lock is invalid, sending the first lock request to the distributed lock management node in a case where it is determined that the target metadata needs to be synchronized with the target metadata distributed lock, comprising: in response to determining that the access request directly or indirectly changes the file size of the target file, sending a first lock request requesting a file size metadata write lock to the distributed lock management node.

5. The method of claim 1, wherein, The access request is a read request indicating reading the content of the target file, and the target metadata distributed lock is a file size metadata distributed read lock. Before the access request for the target file in the NAS cluster is controlled based on the target metadata distributed lock, the method further comprises: detecting whether the access range indicated by the read request exceeds the file size of the target file; in response to detecting that the access range exceeds the file size of the target file, modifying the access range corresponding to the access request so that the modified access range falls within the file size of the target file.

6. The method of claim 1, wherein, The access request is a write request for writing file content to the target file, and the target metadata is file size metadata that needs to be synchronously valid with a file size metadata distributed lock; Before sending a first lock request to the distributed lock management node, the method further includes: reading a first file size of the target file from the distributed lock management node through a file size metadata distributed read lock; and sending a file size metadata write lock request to the distributed lock management node in response to determining that the second file size indicated by the write request is greater than the first file size of the target file; and configuring the target metadata distributed lock for the access request by the distributed lock management node in response to receiving the first lock request, including: configuring a file size metadata distributed write lock for the write request and revoking a file size metadata distributed read lock and / or a file size metadata distributed write lock configured for other access requests by the distributed lock management node according to the file size metadata write lock request; and controlling the access request for the target file in the NAS cluster based on the target metadata distributed lock, including: controlling writing file content to the target file based on the file size metadata distributed write lock.

7. The method of claim 1, wherein, The method further includes: controlling the access request for the target file in the NAS cluster based on the target metadata distributed lock if the proxy node determines that the target metadata distributed lock is valid.

8. The method of claim 1, wherein, The method further includes: generating response information for the access request from the target metadata locally cached by the proxy node in response to determining that the target metadata does not need to be synchronously valid with the target metadata distributed lock; wherein the target metadata locally cached is periodically updated.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: determining a lock identifier of the target metadata distributed lock according to the response information by the proxy node, wherein the lock identifiers of different target metadata distributed locks of the target metadata are sequentially increased according to the order in which the target metadata distributed locks are configured; determining whether the lock identifier of the target metadata distributed lock is less than the lock identifier of a target metadata distributed lock already held; if yes, discarding the target metadata distributed lock indicated by the response information.

10. The method according to any one of claims 1 to 8, characterized in that, The method further includes: determining whether the target metadata distributed lock has been revoked according to the lock identifier of the target metadata distributed lock indicated by the response information by the proxy node in response to receiving the response information; if the determination result is yes, discarding the target metadata distributed lock.

11. A distributed data storage control apparatus, comprising: a first receiving unit configured to receive, by a proxy node, an access request for a target file in a network-attached storage (NAS) cluster, and determine target metadata corresponding to the access request; a first determining unit configured to determine, by the proxy node, whether the target metadata needs to be synchronously valid with a target metadata distributed lock based on metadata of the target file and distributed lock setting information. The first sending unit is configured to, in a case where it is determined that the target metadata needs to be synchronized with the target metadata distributed lock, send a first lock request to the distributed lock management node if the proxy node determines that the current target metadata distributed lock is invalid according to the attribute value of the target metadata distributed lock; the first lock request is used to request that the target metadata distributed lock be re-allocated for the target metadata; and the target metadata distributed lock is used to control exclusive access to the target metadata shared in the NAS cluster. The first locking unit is configured to, in response to receiving the first lock request, configure the target metadata distributed lock for the access request by the distributed lock management node, and return response information to the proxy node, the response information indicating that the target metadata distributed lock is successfully configured for the access request. The first execution unit is configured to control the access request for the target file in the NAS cluster based on the target metadata distributed lock.

12. An electronic device, comprising: Comprise: A processor and a memory; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory, so that the processor executes the method in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, and when the processor executes the computer execution instructions, the method in any one of claims 1 to 10 is realized.

Images