Access request handling methods and electronic devices under centralized storage

Abstract

This application discloses an access request processing method and electronic device under centralized storage, relating to the field of centralized storage technology. The method includes: setting up a virtual file system in nodes and using the virtual file system to synchronize cache mirrors between nodes. When any node receives an access request, it first determines whether the request is a read or write request, and then uses the cache mirror to process the request. This solves the problems of data corruption due to the lack of memory consistency protection when using a local file system to provide read / write services to multiple nodes, and the reliance on a single node for protocol processing. This method introduces a virtual file system into the nodes, enabling nodes to mount the same volume and use the virtual file system for inter-node cache synchronization, thus achieving unified cache mirroring between nodes. Through inter-node cache mirroring, the ability for multiple nodes to provide services to the outside world is realized.

Description

Technical Field

[0001] This invention relates to the field of centralized storage technology, and more specifically to a method and electronic device for handling access requests under centralized storage. Background Technology

[0002] Centralized storage is an architecture that stores data uniformly on a single or a few central nodes. It can simultaneously provide SAN (Storage Area Network) and NAS (Network Attached Storage) services through dedicated storage devices. NAS provides file-level storage services within a local area network (LAN) through dedicated devices, supporting multiple nodes to share files, back up data, and collaborate via standard network protocols. Currently, NAS services can be implemented using local file systems, and active-passive architectures (APs) can be implemented using local file systems. In an active-passive architecture, only one node can provide read / write services externally at a time. To enable multiple nodes to provide read / write services using a local file system, the node hosting the local file system shares the protocol, while the remaining nodes connect internally before sharing the service.

[0003] However, traditional local file systems are designed based on the assumption that volumes are mounted by only a single node. When multiple nodes mount the same volume simultaneously, data corruption can occur due to the lack of consistency protection in memory structures such as page caches, logs, and allocation group bitmaps. Furthermore, using internal protocols for forwarding means that protocol processing is ultimately concentrated on a single node, failing to leverage the advantage of all nodes providing shared services.

[0004] Therefore, when using multiple nodes of the local file system to provide read and write services, the lack of consistency protection in the memory structure can easily lead to data corruption, and there is also the problem of relying on a single node for protocol processing. Summary of the Invention

[0005] In view of this, the present invention provides an access request processing method and electronic device under centralized storage to solve the problems that when using a local file system with multiple nodes to provide read and write services to the outside world, the lack of consistency protection of the memory structure can easily lead to data corruption, and the reliance on a single node for protocol processing.

[0006] Firstly, this application provides a method for handling access requests under centralized storage, the method comprising:

[0007] This method is applied to a preset number of nodes, each node including a virtual file system. The virtual file system is used for cache mirror synchronization between nodes. The method includes:

[0008] Mount a local file system, which is used to cache data exchange between the image and the volume;

[0009] Upon receiving an access request, if the access request is a read request and the cache image does not contain the target data corresponding to the access request, the target data is retrieved from the volume based on the cache image, the target data is updated to the cache image, and the target data is output.

[0010] If the access request is a write request and the cache image contains the target cache corresponding to the access request, the target cache is changed according to the write request, and the changed cache image is synchronized to other nodes through the virtual file system.

[0011] Secondly, this application provides an access request processing system under centralized storage, the system comprising: a preset number of nodes; each node includes a virtual file system, wherein the virtual file system is used for cache mirror synchronization between nodes;

[0012] A node is used to mount a local file system, which is used to cache data exchange between the image and the volume.

[0013] The node is used to, upon receiving an access request, if the access request is a read request and the cache image does not contain the target data corresponding to the access request, retrieve the target data from the volume according to the cache image, update the cache image with the target data, and output the target data;

[0014] The node is also used to modify the target cache according to the write request if the access request is a write request and the cache image contains the target cache corresponding to the access request, and to synchronize the modified cache image to other nodes through the virtual file system.

[0015] Thirdly, this application provides an access request processing apparatus under centralized storage, the apparatus comprising:

[0016] The system mount module is used to mount the local file system, which is used to cache data exchange between the image and the volume.

[0017] The read request processing module is used to, upon receiving an access request, if the access request is a read request and the cache image does not contain the target data corresponding to the access request, retrieve the target data from the volume according to the cache image, update the cache image with the target data, and output the target data.

[0018] The write request processing module is used to modify the target cache according to the write request if the access request is a write request and the cache image contains the target cache corresponding to the access request, and then synchronize the modified cache image to other nodes through the virtual file system.

[0019] Fourthly, this application provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the access request processing method under centralized storage described in the first aspect or any corresponding embodiment.

[0020] Fifthly, this application provides a computer-readable storage medium storing computer instructions for causing a computer to execute the centralized storage access request processing method described in the first aspect or any corresponding embodiment thereof.

[0021] In a sixth aspect, this application provides a computer program product, including computer instructions for causing a computer to execute the centralized storage access request processing method described in the first aspect or any corresponding embodiment thereof.

[0022] This application addresses the issue of data corruption and protocol processing reliance when multiple nodes rely on a single node for cache mirroring. By introducing a virtual file system within nodes, enabling them to mount the same volume and synchronize caches across nodes, this method achieves unified cache mirroring. This inter-node cache mirroring enables the ability of multiple nodes to provide read / write services. The method solves the problem of data corruption due to lack of memory consistency protection when using a local file system for multi-node read / write operations, and the reliance on a single node for protocol processing. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this application, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating the access request processing method under centralized storage according to an embodiment of this application;

[0025] Figure 2 This is a schematic diagram of the cache space distribution according to an embodiment of this application;

[0026] Figure 3 This is a schematic diagram of a data volume space according to an embodiment of this application;

[0027] Figure 4 This is a schematic diagram of the structure of an access request processing system under centralized storage according to an embodiment of this application;

[0028] Figure 5 This is a schematic diagram of a dual-node centralized storage structure according to an embodiment of this application;

[0029] Figure 6 This is a structural block diagram of an access request processing apparatus under centralized storage according to an embodiment of this application;

[0030] Figure 7 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0031] 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, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0032] 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, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0033] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0034] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0035] Centralized storage is an architecture that stores data uniformly on a single or a few central nodes. It can provide both SAN and NAS services simultaneously through dedicated storage devices. NAS services are divided into AP (Action-Active) and AA (Active-Active) architectures based on access type. AP is a master-slave architecture where only the master node handles I / O (Input / Output) requests, while slave nodes are in standby mode. When the master node fails, the slave nodes take over. AA, on the other hand, is a dual-active architecture where two controllers handle I / O requests simultaneously. All controllers are active and process I / O requests concurrently, acting as backups for each other, thus improving system reliability and performance. This architecture offers superior performance through load balancing, but it also requires higher technical expertise and hardware performance.

[0036] Currently, there are two main approaches to implementing a NAS file system: 1. Using a local file system to implement an AP architecture. This approach has relatively low integration difficulty and low device performance requirements, with only one node providing external read / write access through sharing. 2. Integrating a distributed file system to implement an AA architecture. However, this approach has higher integration difficulty and higher requirements for device performance and the number of nodes. To enable multiple nodes to provide services using a local file system, the node containing the file system shares a protocol, and the remaining nodes form internal connections before sharing services. Examples of local file systems include the X File System (XFS) and the Fourth Extended File System (EXT4). The X File System is a 64-bit journaling file system designed specifically for high-performance, high-capacity storage.

[0037] However, local file systems are designed based on the assumption that block devices such as volumes are mounted by a single node. When multiple nodes mount the same volume simultaneously, data corruption can occur due to the lack of consistency protection in memory structures such as page caches, logs, and allocation group bitmaps. Using internal protocols for forwarding means that protocol processing is ultimately concentrated on a single node, failing to leverage the advantage of all nodes providing shared services. Furthermore, distributed file systems cannot be directly upgraded from local file systems, and because distributed file system components are relatively large and basic services consume significant resources, they cannot leverage the advantages of parallel processing in centralized storage with fewer nodes. Additionally, the integration of distributed file systems with applications requires adaptation for private clients.

[0038] Based on the above, this application provides an access request processing system under centralized storage. By introducing an enhanced VFS (Virtual File System) layer, a unified cache management layer, and a lease service, it intercepts all system calls without modifying the XFS source code. Through inter-node cache mirroring, it enables multiple nodes to provide services externally. Furthermore, it achieves offline node awareness through lease space on a shared volume, eliminating the need for third-party arbitration. All node caches are consistent; when flushing the cache, only one node needs to be flushed, ensuring the uniqueness of the XFS logs. While maintaining the high-performance characteristics of XFS, this system solves the core challenge of multi-node concurrent access through an innovative collaborative VFS layer, providing a new shared storage solution for high-performance computing and other scenarios. Specifically, it enables multi-node shared access to the local file system, transparent compatibility with existing applications, proposes a method for strong cache consistency, and uses distributed locks, thereby reducing failover time.

[0039] According to an embodiment of this application, an embodiment of an access request processing method under centralized storage is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0040] This embodiment provides a method for handling access requests under centralized storage. Figure 1 This is a flowchart of an access request processing method under centralized storage according to an embodiment of this application. The method is applied to a preset number of nodes in an access request processing system under centralized storage. The access request processing system under centralized storage is described in detail below. Each node includes a virtual file system, which is used for cache mirror synchronization between nodes. Figure 1 As shown, the process includes the following steps:

[0041] Step S101: Mount a local file system, whereby the local file system is used to cache data exchange between the image and the volume.

[0042] Specifically, the local file system has volume read and write capabilities. Therefore, nodes mount the local file system and exchange data between the cache image and the volume through the local file system. This embodiment sets up a virtual file system in the node and combines the virtual file system with the RDMA protocol to implement synchronization services between nodes. Through the synchronization service, the cache images between nodes can be unified.

[0043] Step S102: Upon receiving an access request, if the access request is a read request and the cache image does not contain the target data corresponding to the access request, retrieve the target data from the volume according to the cache image, update the cache image with the target data, and output the target data.

[0044] Specifically, after receiving an access request, the node determines whether it is a read or write request. If the access request is a read request and the cached image does not contain the target data corresponding to the access request, the node retrieves the target data from the volume based on the cached image, returns it, updates the cached image with the target data, and then outputs the target data to the corresponding application. The process of the node handling read requests based on the cached image is as follows: when processing a read request, it first searches in the local cached image; if it does not find the data, it reads the contents of the volume. A portion of the file content is cached in the cached image.

[0045] Step S103: If the access request is a write request and the cache image contains the target cache corresponding to the access request, change the target cache according to the write request, and synchronize the changed cache image to other nodes through the virtual file system.

[0046] Specifically, if the access request is a write request and the cache image contains the target cache corresponding to the access request, the node modifies the target cache according to the write request and synchronizes the modified cache image to other nodes via the virtual file system. After synchronization is complete on all nodes, it returns and waits for the master node to write the modified cache image to disk, i.e., flush it to the volume. This includes: when processing a write request, first checking if the cache image has a cache; if so, directly modifying the cache and synchronizing the changes to other nodes via RDMA.

[0047] The centralized storage access request processing method provided in this embodiment sets up a virtual file system in the nodes and uses the virtual file system to synchronize cache mirrors between nodes. When any node receives an access request, it first determines whether the request is a read or write request, and then uses the cache mirror to process the request. This method introduces a virtual file system into the nodes, enabling them to mount the same volume and use the virtual file system for inter-node cache synchronization, thus achieving unified cache mirroring between nodes. Through inter-node cache mirroring, the ability for multiple nodes to provide services externally is realized. This solves the problems of data corruption due to the lack of memory structure consistency protection when using a local file system for multiple nodes to provide read and write services, and the reliance on a single node for protocol processing.

[0048] As an optional embodiment, upon receiving an access request, the method further includes:

[0049] If the access request is a read request and the cached image contains the target data, obtain the disk version and local cache version corresponding to the target data. If the values ​​of the disk version and the local cache version are the same, output the target data.

[0050] If the access request is a write request and the cache image does not contain the target cache, determine whether there is a free cache in the node's cache memory; if there is a free cache in the cache memory, use the free cache as the target cache; if there is no free cache in the cache memory, use the cache in the cache memory that has not been accessed for a longer period than a first preset threshold as the cache to be released, release the cache to be released, and use the released cache to be released as the target cache.

[0051] Specifically, after receiving an access request, the node determines whether the access request is a read request or a write request.

[0052] If the access request is a read request and the cached image contains the target data, the node obtains the disk version and local cache version corresponding to the target data. For example, it retrieves the disk version and local cache version from the index information corresponding to the target data. The index information stores the location of the local cache version, the disk version, and the lock slot identifier. When processing a read request, if the target data corresponding to the read request exists in the cached image, and if the disk version of the target data matches the value of the local cache version, then the target data is output directly.

[0053] If the access request is a write request, when processing the write request, the data of the write request is updated to the cache. After synchronization is completed on all nodes, it returns and then waits for the master node to write the data to disk. Specifically, if the access request is a write request and the cache image does not contain the target cache, it checks whether there is a free cache in the node's cache memory. If there is a free cache in the cache memory, a memory image is allocated in the cache memory to store it. If there is no free cache in the cache memory, it means that the cache area is full. In this case, the cache that has not been used for the longest time is designated as the cache to be released, or the cache that has not been accessed for more than a first preset threshold is designated as the cache to be released. For example, if the first preset threshold is 1 day, if a cache has not been accessed for more than 1 day, it is designated as the cache to be released. The cache to be released is released, and the released cache to be released is designated as the target cache. The lookup of free space in the cache area and the correspondence between file locations are stored in the cache management area.

[0054] As an optional embodiment, the method further includes:

[0055] When mounting the local file system, determine the cache memory allocated to the node, where the cache memory is used to store cache images;

[0056] Retrieve file system information, cache memory space management information, and information index from the local file system;

[0057] Write file system information, space management information, and information indexes into cache memory;

[0058] After mounting the local file system, the node is connected to other nodes via a remote direct memory access channel;

[0059] The memory address of the cached memory is broadcast to other nodes through a remote direct memory access channel, whereby the other nodes retrieve the cache image from the cached memory based on the memory address.

[0060] Specifically, the virtual file system is recognized after a node mounts its local file system. When mounting the local file system, the node ID (Identity document) and node role (whether it's a master node) are passed in. In centralized storage, there can only be one master node. The cache image is divided into three parts: file system information, cache management area, and cache content area. The cache content in the cache content area is identical across all nodes. The file system information includes the master node location and the header information of the mounted file system. The cache management area stores cache space management information and information indexes, using a universal mechanism. Changes are synchronized to other nodes via RDMA. Information indexes include, for example, inode indexes. Figure 2 As shown, the cache space of the cache image is distributed as basic file system information, cache space management area, and cache data.

[0061] It's important to note that during a file read / write operation, an inode index is created, adding the following information: `--uint64 cache_ver` (representing the local node's cache version), `--uint64 disk_ver` (representing the disk version location), and `--uint64 slot_ID` (representing the slot location). After finding the space location in the disk version, it's stored in the inode information. `slot_ID` is initialized using `hash(inode-123)&max-1`, where `max` is 0x800000, occupying 128MB of slot space. The remaining 128MB is used for hotspot spare slots, file system information, and locks for the cache management area. `disk_ver` is `uint64 disk_version`, incrementing the corresponding version by 1 with each write operation, but initialized to 0 when the inode is first bound. The local node's cache version represents the local version number, while the disk version location represents the version of the content on the disk. Since each node updates during a write operation, inconsistencies between the local cache version and the disk version can occur.

[0062] After mounting the local file system, the virtual file system registers RDMA based on the allocated cache memory and broadcasts the memory address of its cache memory to other nodes in the UD domain, enabling the node to connect with other nodes via the remote direct memory access channel. Other nodes retrieve the cache image from the cache memory based on the memory address. The cache image is then synchronized to other nodes, letting them know the location of the master node and synchronizing the initial cache information to prevent inconsistencies in cache information between nodes caused by each node reading from its own disk.

[0063] In this embodiment, file system information, space management information, and information index are written into cache memory as a cache image. The cache image is synchronized to other nodes so that they know where the master node is and synchronize the initial cache information, preventing inconsistencies in cache information between nodes caused by each node reading disk independently.

[0064] As an optional embodiment, after mounting the local file system, the method further includes:

[0065] In the volume where the local file system resides, determine the preset storage area;

[0066] Obtain the lock slot, disk version, and node lease information, and store the lock slot, disk version, and lease information in the preset storage area;

[0067] The preset storage area is mapped to the cache memory, and the memory address of the cache memory is registered with the Remote Direct Memory Access Protocol (RDP) so that other nodes can obtain the cache image in the cache memory through the RDP channel.

[0068] Specifically, a local file system, such as the XFS file system, is used. Within the volume containing the local file system, a predefined storage area is determined; for example, at the end of the XFS volume, additional space is allocated as the predefined storage area.

[0069] Retrieve the lock slot, disk version, and node lease information. The disk version is, for example, inode diskversion. Store the lock slot, disk version, and lease information in a preset storage area. For example, after the XFS data, expand the space by 512MB to store the lock slot, expand the space by 512MB to store the diskversion, and expand the space by 1MB to store the lease information.

[0070] The sub-regions in the preset storage area, which contain storage lock slots, inode diskversion, and lease information for each node, are mapped to the cache memory, and the memory address of the cache memory is registered using RDMA. This allows other nodes to obtain the cache image in the cache memory through the remote direct memory access channel. Non-master nodes wait for the master node to mount the XFS file system before performing cache synchronization. Only after cache synchronization is complete will the non-logged XFS file system be mounted.

[0071] The data volume space of the volume where the local file system resides is as follows Figure 3 As shown, this includes the local file system, lock slot data, disk version location, and heartbeat lease.

[0072] As an optional embodiment, retrieving target data from the volume based on the cache image, updating the cache image with the target data, and outputting the target data includes:

[0073] Read the target data from the volume based on the cached image;

[0074] Obtain the disk version corresponding to the target data in the volume, and obtain the local cache version corresponding to the target data in the cache image;

[0075] If the disk version and the local cache version are the same, update the target data to the cache image and output the target data.

[0076] Specifically, the node retrieves the target data from the volume based on the cached image and returns it. For example, it determines the information index corresponding to the read request in the cached image, finds the corresponding file in the volume based on the corresponding information index, and reads the data in the file as the target data.

[0077] Retrieve the disk version corresponding to the target data from the volume, and retrieve the local cache version corresponding to the target data from the cache image. Alternatively, the disk version and local cache version can be retrieved from the information index.

[0078] The system checks if the disk version and the local cache version are the same. If they are different, it indicates that the target data version read is incorrect; therefore, the target data is not output, and an error message is output. If the disk version and the local cache version are the same, the target data is updated to the cache image and then output. Additionally, after updating the cache image, it is synchronized to other nodes via the RDMA channel.

[0079] As an optional embodiment, after storing the lock slot, disk version, and lease information to a preset storage area, the method further includes:

[0080] The first identifier of the information index is retrieved;

[0081] The second identifier of the lock slot is determined by a preset algorithm and the first identifier;

[0082] Write the second identifier, disk version, and local cache version into the information index;

[0083] If the modification frequency of the information index is greater than the second preset threshold, a spare lock slot is determined in the lock slot, and a third identifier of the spare lock slot is determined by a preset algorithm and a first identifier.

[0084] The second identifier in the information index is replaced with the third identifier to obtain the updated information index, and the updated information index is synchronized to other nodes through the remote direct memory access channel.

[0085] Specifically, the information index is, for example, inode cache information. The first identifier of the information index is retrieved, for example, the inode number. The second identifier of the lock slot is, for example, the slot_ID number.

[0086] Preset algorithms include hash algorithms such as SHA-1 and SHA256. The first identifier is input into the preset algorithm, and the output value is used as the second identifier of the slot. For example, the hash value calculated using the inode number is used as the slot_ID. The inode cache information stores the location of the local cache version, the disk version, and the second identifier of the slot. The disk version location is the offset on the volume, used to store the number of writes from the cache. When the inode cache information is cached for the first time, the disk version location is allocated, and the local cache version is written to 0. For each subsequent write, the version is incremented by 1. Therefore, the second identifier, disk version, and local cache version are written to the information index.

[0087] Each lock slot occupies 16 bytes, including: uint8 nodeID representing the ID of the node currently holding the lock, 0 representing no lock; uint64 inode representing which inode cache information is being locked; and uint8 resev[7] representing a reserved field, reserving space. The lock slot and inode cache information are bound by hash, and are recorded in the slot_ID attribute of the inode cache information when the inode cache information is cached. Due to hash collision issues, there may be a situation where one lock slot corresponds to multiple inode cache information.

[0088] If frequent operations on a certain information index are detected, a new spare lock slot is requested, and the corresponding lock slot's slot_ID is recorded in the inode cache. Then, it is synchronized to other nodes via RDMA. This includes: if the information index modification frequency exceeds a second preset threshold, a spare lock slot is determined from the lock slots, and a third identifier of the spare lock slot is determined using a preset algorithm and a first identifier. The second preset threshold is, for example, 2 times per second, 20 times per minute, etc. A modification frequency exceeding the second preset threshold indicates frequent operations on the information index. The third identifier replaces the second identifier in the information index, resulting in an updated information index, which is then synchronized to other nodes via the remote direct memory access channel.

[0089] In this embodiment, the second identifier, disk version, and local cache version are written into the information index to facilitate comparison of the validity of cached data based on the disk version and local cache version. Furthermore, when operations on the information index are frequent, a spare lock slot is determined to avoid multiple information indexes corresponding to one lock slot due to hash collisions.

[0090] As an optional embodiment, after writing the file system information, space management information, and information index into the cache memory, the method further includes:

[0091] When updating the cache image, check if the information index exists in the cache image;

[0092] If an information index exists, lock the information index and then update it to obtain the updated cache image;

[0093] The updated cache image is synchronized to other nodes via a remote direct memory access channel, and the updated cache image is flushed to the volume after the information index is unlocked.

[0094] If the information index does not exist, lock the cache management area in the cache memory and obtain the initial information index;

[0095] Lock the initial information index, update the data cache in the cache management area and cache memory, and obtain the updated cache memory;

[0096] The updated data in the cache memory is synchronized to other nodes via a remote direct memory access channel, and the initial information index and cache management area are unlocked.

[0097] Specifically, information indexes include, for example, inode cache information. The address offsets of the inode cache information in each node are exactly the same, therefore, cache synchronization can be achieved directly through RDMA for memory synchronization.

[0098] When updating the cache image, check if there is an information index in the cache image, such as inode cache information.

[0099] If inode cache information exists, lock the information index and then update the information index to obtain the updated cache image. Synchronize the updated cache image to other nodes through the remote direct memory access channel. After unlocking the information index, wait for the master node to flush the updated cache image to the volume.

[0100] If the information index does not exist, lock the cache management area in cache memory and obtain the initial information index. Obtaining the initial information index involves, for example, initializing inode cache resources, including the inode index, lock slot ID, diskversion location, and data cache location. Lock the initial information index, update the cache management area and the data cache in cache memory, obtaining the updated cache memory. Synchronize the updated data in cache memory to other nodes via a remote direct memory access channel, and unlock the initial information index and cache management area.

[0101] It's important to note that locking is accomplished through local node reads and writing lock information to the master node via RDMA CAS (Compare and Swap) operations. RDMA CAS operations are atomic operations used for atomically modifying remote memory. Each file system basic information area and cache management area corresponds to a lock. The cache content area corresponds to each lock slot in units of inode cache information, linked by a hash to the inode cache information. The lock information defaults to 0. When a lock is acquired, the master node writes the node ID that acquired the lock into the lock information. Non-master nodes write the node ID that acquired the lock into the lock information via RDMA CAS, while the master node directly writes the node ID that acquired the lock into the lock information via local CAS, ensuring atomicity during disk writes. This way, all nodes can see the inode locking status. After a node comes online, there's no need to rescan the inode information in the cache or establish a mapping relationship with slot_IDs; it directly maps to the lock space on the volume, and reading reveals the current lock status. For example, if the lock slot is not 0, it means it's already locked.

[0102] As an optional embodiment, the locking types in the above embodiments can be divided into several types: forced lock, suggested lock, shared lock, and exclusive lock. Correspondingly, the locks can be further subdivided into "shared lock (S lock)," "exclusive lock (X lock)," "forced lock," and "suggested lock," specifically including:

[0103] Shared locks (S locks) are suitable for "read-only operations" and allow multiple nodes to hold them simultaneously. For example, when multiple nodes read the same file at the same time, they can all acquire the S lock for the corresponding lock slot of that file. In this case, the lock information can be represented as "node ID + S tag". When all nodes read the lock slot, they will recognize that "multiple S locks coexisting" is legal.

[0104] Exclusive locks (X locks) are used for "modification operations" (write, delete, etc.), allowing only one node to hold them, and are mutually exclusive with S locks. For example, when a node wants to modify a file, it needs to acquire an X lock on the corresponding lock slot for that file. The lock information is represented as "node ID + X tag". At this time, other nodes will fail to acquire either an S lock or an X lock because the "X tag" is detected, ensuring that only one node can modify the file at a time.

[0105] Forced locking: This method involves mandatory checks by the virtual file system. Operations without the lock are directly rejected, making it suitable for untrusted environments. For example, if a node attempts to write to a file without acquiring the X lock, the virtual file system will intercept the operation and return an error.

[0106] Suggested locks: These are merely "agreements" between nodes; the virtual file system does not enforce them, making them suitable for trusted environments. For example, a node may proactively check the lock status before performing an operation, but can still execute the operation even without acquiring the lock.

[0107] Based on the above, the locking and unlocking logic in the above embodiments is modified.

[0108] The CAS operation logic for requesting a lock is modified as follows: When requesting a shared lock (S lock), the node checks the lock slot status through a CAS operation: if the lock slot value is 0 (no lock), then write "its own node ID + S" (e.g., "103_S"); if the lock slot value is another node's "S lock" (e.g., "102_S"), then append "its own node ID + S" (e.g., "102_S, 103_S", supporting multiple nodes coexisting through a predefined format).

[0109] If the lock information is "X lock" (e.g., "101_X"), the CAS operation fails and the request is rejected. Requesting an exclusive lock (X lock): The node strictly checks that the lock slot is 0 (no locks) through the CAS operation; otherwise, the request fails directly. Only when the lock information is 0 is "its own node ID + X" written to ensure exclusivity.

[0110] The lock release logic has been modified as follows: When releasing an S lock, if the lock slot only contains the node's own S lock, the lock information is set to 0; if there are other nodes' S locks, the node's own ID is removed from the lock information (e.g., "102_S,103_S" is changed to "102_S"). When releasing an X lock, the lock information is directly set to 0, allowing other nodes to request S or X locks.

[0111] It should be noted that in this embodiment, the mapping between lock slots and inodes is still bound by hash. Lock type information is directly stored in the lock slot (e.g., "node ID + type flag"). When a node comes online and maps the lock space on the volume, the lock type can be directly resolved (without rescanning). When any node reads a lock slot, it can not only see "whether there is a lock", but also "what type of lock" and "which nodes hold it", thus determining whether its operation is legal.

[0112] In this embodiment, the lock is subdivided into shared locks and exclusive locks to control read and write permissions; the lock is further subdivided into mandatory locks and suggested locks to control the constraint strength, which can more flexibly adapt to multi-node concurrent scenarios, ensuring that reads can be parallel and writes must be exclusive, and can choose whether to enforce constraints according to the trust environment, while not destroying the original atomicity and visibility design.

[0113] As an optional embodiment, mounting a local file system includes:

[0114] When the node is the master node, retrieve the system logs from the local file system;

[0115] When mounting a local file system on the master node, log replay repair is performed on the local file system based on the system log;

[0116] After the local file system is repaired, instruct the slave node to mount the repaired local file system.

[0117] Specifically, non-master nodes wait for the master node to mount the XFS file system before performing cache synchronization. Only after the cache synchronization is complete will the non-log replay XFS be mounted.

[0118] Only when the master node mounts the file system is log replay repair allowed, and file system information can be read. For example, when the node is the master node, the system log of the local file system can be retrieved; when the master node mounts the local file system, log replay repair can be performed on the local file system based on the system log. After the local file system repair is complete, the slave nodes are instructed to mount the repaired local file system, but log replay is not performed.

[0119] In this embodiment, all nodes have consistent caches, so when flushing the cache, only one node needs to be flushed, thus ensuring the uniqueness of the XFS logs.

[0120] As an optional embodiment, after storing the lock slot, disk version, and lease information to a preset storage area, the method further includes:

[0121] At each preset interval, the lease information will be incremented by a preset step size;

[0122] If the value of the lease information remains unchanged within the second preset time period, the node corresponding to the lease information will be designated as an offline node.

[0123] When the offline node is the master node, a new master node is determined from the slave nodes;

[0124] If the offline node is a slave node, mark the offline node as offline.

[0125] Determine the lock corresponding to the offline node based on the lock slot, and release the lock corresponding to the offline node.

[0126] Specifically, each lease information occupies 16 bytes. The lease information includes: uint8 nodeID representing the node ID, uint64 beat representing the lease information, uint8 resev[7] representing the reserved field, and reserved space. The lease information can be directly located based on the node identifier nodeID as the offset.

[0127] The first preset duration is the heartbeat time, such as 50ms, 60ms, or other durations. Every first preset duration, each node will increment the value of its lease information by a preset step size, such as 1, 2, or other values.

[0128] The file system's basic cache information includes a master node. When a node can correctly read the lease information and finds that the value of the lease information on the peer node has remained unchanged for a second preset time period, the node corresponding to the lease information, i.e., the peer node, is considered an offline node. The second preset time period can be, for example, 150ms, 160ms, or other durations. Additionally, the second preset time period can be set as an integer multiple of the heartbeat time. For example, each node increments the value in its lease volume location by 1 every heartbeat time; if the value remains unchanged after 3 * heartbeat times, the node is considered offline.

[0129] When the offline node is a slave node, it is marked as offline. When the offline node is the master node, a new master node is determined from among the slave nodes, for example, the next node after the master node becomes the new master node. At this time, the new master node modifies the lease information in the header file in memory, synchronizes it to other nodes via RDMA, then queries all lock slots, determines the lock corresponding to the offline node based on the lock slot, writes all tokens of the offline node to 0, and forcibly releases the lock corresponding to the offline node.

[0130] It should be noted that this embodiment is independent of whether a node is a primary node. For a two-node cluster, one is the primary node and the other is a backup primary node. All nodes monitor the status of all other nodes. If a node is determined to be offline, it queries the primary node to determine if the node is valid. If it is invalid, the current primary node updates the lease status to offline. If the offline node is the primary node, the backup primary node becomes the primary node and refreshes the status of all nodes according to the lease information. When a node performs cache synchronization, it does not update the synchronization of offline nodes. After a node goes offline, the node with the next node number will take over the business of that node.

[0131] In this embodiment, offline node awareness is achieved through the leased space on the shared volume, eliminating the need for third-party arbitration.

[0132] This embodiment provides an access request processing system under centralized storage. Figure 4 This is a schematic diagram of the structure of an access request processing system under centralized storage according to an embodiment of this application, as shown below. Figure 4 As shown, the system includes: a preset number of nodes; each node includes a virtual file system, which is used for cache mirror synchronization between nodes;

[0133] A node is used to mount a local file system, which is used to cache data exchange between the image and the volume.

[0134] The node is used to, upon receiving an access request, if the access request is a read request and the cache image does not contain the target data corresponding to the access request, retrieve the target data from the volume according to the cache image, update the cache image with the target data, and output the target data;

[0135] The node is also used to modify the target cache according to the write request if the access request is a write request and the cache image contains the target cache corresponding to the access request, and to synchronize the modified cache image to other nodes through the virtual file system.

[0136] Specifically, centralized storage is an architecture that stores data uniformly on a single or a few central nodes; therefore, the preset number can be one or more. For example: Figure 4The centralized storage shown comprises two nodes, Node 1 and Node 2. Both Node 1 and Node 2 include virtual file systems, such as an enhanced VFS layer. This enhanced VFS layer takes over the default VFS layer and uses the RDMA (Remote Direct Memory Access) protocol to unify cache mirroring between nodes, handle locks, and manage node leases. Therefore, the virtual file system is used for cache mirroring synchronization between nodes. The virtual file system connects different nodes via the RDMA protocol, for example, by creating remote direct memory access channels between different nodes based on the RDMA protocol. Local file systems include, for example, the X file system and a fourth extended file system.

[0137] The local file system has volume read / write capabilities; therefore, nodes mount the local file system and use it for data exchange between cached images and volumes. This embodiment implements synchronization services between nodes by setting up a virtual file system within the nodes and combining the virtual file system with the RDMA protocol. This synchronization service enables the unification of cached images across nodes. Figure 4 Node 1 and Node 2 are mounted on the same volume. Multiple nodes form a cluster, and all nodes within a cluster are in the UD (Unreliable Datagram) domain.

[0138] After a node mounts its local file system, the virtual file system is recognized. The virtual file system registers with RDMA based on the allocated cache memory and notifies the node of its cache memory address via the UD field, broadcasting the information through RDMA. When mounting the local file system, the node ID (Identity document) and node role (whether it is a master node) are passed in. In centralized storage, there can only be one master node. The cache image consists of three parts: file system information, cache management area, and cache content area. The cache content in the cache content area is identical across all nodes. The file system information includes the master node location and the header information of the mounted file system. The cache management area stores cache space management information and information indexes. This mechanism is universal, and changes are synchronized to other nodes via RDMA. Information indexes include, for example, inode indexes. Inode indexes store core file information, such as file size, who can read and write to it, and the actual location of the data on the hard drive. When a node needs to find file content, it doesn't directly recognize the filename but first finds this information through the inode index before locating and reading the file data. The cache image is synchronized to other nodes so that they know where the master node is and synchronize the initial cache information, preventing inconsistencies in cache information between nodes caused by each node reading from the disk itself.

[0139] like Figure 4 As shown, node 1 can receive access requests from application 1, and node 2 can receive requests from application 2. After receiving an access request, the node determines whether the access request is a read request or a write request.

[0140] If the access request is a read request and the cached image does not contain the target data corresponding to the access request, the node retrieves the target data from the volume based on the cached image, returns it, updates the cached image with the target data, and then outputs the target data to the corresponding application. The process of a node handling read requests based on a cached image is as follows: when processing a read request, it first searches in the local cached image; if the data is not found there, it reads the contents of the volume. A portion of the file content is cached in the cached image.

[0141] If the access request is a write request and the cache image contains the target cache corresponding to the access request, the node modifies the target cache according to the write request and synchronizes the modified cache image to other nodes via the virtual file system. After synchronization is complete on all nodes, it returns and waits for the master node to write the modified cache image to disk (i.e., flush it to the volume). This includes: when processing a write request, first checking if the cache image has a cache; if so, directly modifying the cache and synchronizing the changes to other nodes via RDMA.

[0142] The centralized storage access request processing system provided in this embodiment sets up a virtual file system in the nodes and uses the virtual file system to synchronize cache mirrors between nodes. When any node receives an access request, it first determines whether the request is a read or write request, and then uses the cache mirror to process the request. This system achieves unified cache mirroring between nodes by introducing a virtual file system into the nodes, enabling nodes to mount the same volume and using the virtual file system for cache synchronization. Through cache mirroring between nodes, the system enables multiple nodes to provide services externally. This solves the problems of data corruption due to the lack of memory consistency protection when using a local file system for multiple nodes to provide read and write services, and the reliance on a single node for protocol processing.

[0143] As an optional embodiment, the node is also configured to, if the access request is a read request and the cached image contains the target data, obtain the disk version and local cache version corresponding to the target data, and if the values ​​of the disk version and the local cache version are the same, output the target data;

[0144] The node is also used to determine whether there is a free cache in the node's cache memory if the access request is a write request and the cache image does not contain the target cache; if there is a free cache in the cache memory, the free cache is used as the target cache; if there is no free cache in the cache memory, the cache in the cache memory that has not been accessed for a longer period than a first preset threshold is used as the cache to be released, the cache to be released is released, and the released cache to be released is used as the target cache.

[0145] Specifically, after receiving an access request, the node determines whether the access request is a read request or a write request.

[0146] If the access request is a read request and the cached image contains the target data, the node obtains the disk version and local cache version corresponding to the target data. For example, it retrieves the disk version and local cache version from the index information corresponding to the target data. The index information stores the location of the local cache version, the disk version, and the lock slot identifier. When processing a read request, if the target data corresponding to the read request exists in the cached image, and if the disk version of the target data matches the value of the local cache version, then the target data is output directly.

[0147] If the access request is a write request, when processing the write request, the data of the write request is updated to the cache. After synchronization is completed on all nodes, it returns and then waits for the master node to write the data to disk. Specifically, if the access request is a write request and the cache image does not contain the target cache, it checks whether there is a free cache in the node's cache memory. If there is a free cache in the cache memory, a memory image is allocated in the cache memory to store it. If there is no free cache in the cache memory, it means that the cache area is full. In this case, the cache that has not been used for the longest time is designated as the cache to be released, or the cache that has not been accessed for more than a first preset threshold is designated as the cache to be released. For example, if the first preset threshold is 1 day, if a cache has not been accessed for more than 1 day, it is designated as the cache to be released. The cache to be released is released, and the released cache to be released is designated as the target cache. The lookup of free space in the cache area and the correspondence between file locations are stored in the cache management area.

[0148] As an optional embodiment, a preset number of nodes are included in a node cluster, wherein the nodes in the node cluster are located in a preset communication domain; the nodes are connected to each other through a remote direct memory access channel; the preset number of nodes includes: master nodes and slave nodes;

[0149] A virtual file system is used to broadcast cached images to nodes in a node cluster via a remote direct memory access channel within a preset communication domain.

[0150] The node is used to obtain mount parameters when mounting a virtual file system;

[0151] The node is also used to determine the node identifier, the virtual file system to be mounted, the master node, and the slave nodes based on the mount parameters.

[0152] Specifically, a preset communication domain, such as a UD domain, is defined. Multiple nodes form a node cluster, and all nodes within a node cluster reside in the UD domain. The nodes in the node cluster have identical hardware configurations and memory sizes, are connected via an RDMA channel, and are joined to a UD domain. A preset number of nodes includes one master node, with the other nodes serving as slave nodes.

[0153] After mounting the local file system, the virtual file system registers with RDMA based on the allocated cache memory and notifies the memory address via the UD field, broadcasting the information through the RDMA channel. Subsequently, the virtual file system can broadcast the cache image to nodes in the node cluster via the RDMA channel.

[0154] Virtual file systems, such as Enhanced VFS, are used. When a node mounts a virtual file system, it registers a new file system type, xfs_dtr, in Linux. The node obtains the mount parameters, for example: `mount -t xfs_dtr -o nodeID=1,primary / dev / sdx / fs / fsX` or `mount -t xfs_dtr -o nodeID=2 / dev / sdx / fs / fsX`. Here, the front space of `sdx` is the xfs file system, `-t xfs_dtr` indicates the use of Enhanced VFS, `-onodeID=1` represents the node ID, and `Primary` indicates that the current node is the primary node. Additionally, `mount -t xfs_dtr -onodeID=1` determines that the first node is the specified primary node.

[0155] The node determines its identifier, the virtual file system to be mounted, the master node, and the slave nodes based on the mount parameters. For example, the node identifier is determined to be nodeID=1 based on the mount parameter nodeID=1; the virtual file system to be mounted is determined to be Enhanced VFS based on the mount parameter -t xfs_dtr; the first node is determined to be the specified master node based on mount -t xfs_dtr -o nodeID=1; and the other nodes are slave nodes.

[0156] In this embodiment, nodes are configured according to mounting parameters to ensure accurate node configuration. This prevents incorrect node configuration from causing the inability to provide read and write services and avoids data corruption.

[0157] As an optional embodiment, the node includes network-attached storage services and storage area network services, wherein the local file system is included in the network-attached storage services;

[0158] Storage Area Networking (SLAN) service is used to provide volume services for network-attached storage services.

[0159] The local file system is used for reading and writing volumes according to the volume service.

[0160] Specifically, Figure 5 This is a schematic diagram of a dual-node centralized storage structure, such as... Figure 5 As shown, both Node 1 and Node 2 include Network Attached Storage Service (NAS) and Storage Area Network Service (SAN), with the local file system contained within the NAS. Node 1 and Node 2 are connected via a Remote Direct Memory Access (RDM) channel. The NAS service can access volumes through the SAN service, and the SAN layer guarantees data atomicity during reads and writes. Nodes are connected via an RDMA channel and joined to a UD domain. Additionally, Figure 5 The dual-node centralized storage in the system can be expanded into a multi-node centralized storage system. It is necessary to ensure that each node has the same hardware configuration and memory size, and that all nodes are connected through an RDMA channel.

[0161] Storage Area Networking (SAN) services can provide volume services for Network Attached Storage (NAS). SAN services include backend shared media, such as: Figure 5 The system includes a Job Order Bin (JOB) and a Joint Operating Facility (JOF). The backend shared media provides read / write functionality for the same volumes to the network-attached storage service (NAS).

[0162] The local file system performs read and write operations on the volume based on the volume service provided by the Storage Area Network Service (SAN) for the Network Attached Storage Service (NAS).

[0163] In this embodiment, each node contains a Storage Area Network Service (SAN) and a Network Attached Storage Service (NAS). The NAS can access volumes through the SAN, and the SAN layer guarantees the atomicity of data during read and write operations. Nodes are connected via RDMA and joined to a UD domain to facilitate cache synchronization between nodes.

[0164] This embodiment also provides an access request processing device under centralized storage, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as already described. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0165] This embodiment provides an access request processing device under centralized storage, such as... Figure 6 As shown, it includes:

[0166] The system mount module 601 is used to mount a local file system, which is used to cache data exchange between the image and the volume.

[0167] The read request processing module 602 is used to, upon receiving an access request, if the access request is a read request and the cache image does not contain the target data corresponding to the access request, retrieve the target data from the volume according to the cache image, update the cache image with the target data, and output the target data.

[0168] The write request processing module 603 is used to modify the target cache according to the write request if the access request is a write request and the cache image contains the target cache corresponding to the access request, and synchronize the modified cache image to other nodes through the virtual file system.

[0169] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0170] In this embodiment, the access request processing device under centralized storage is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0171] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0172] The following is a detailed reference. Figure 7 This diagram illustrates a suitable structural schematic for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 701, which can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) 702 or a program loaded from memory 708 into random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the electronic device. The processor 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0173] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 708 including, for example, magnetic tapes, hard disks, etc.; and communication devices 709. Communication device 709 allows electronic devices to exchange data via wireless or wired communication with other devices. Although Figure 7 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0174] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code 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 709, or installed from a memory 708, or installed from a ROM 702. When the computer program is executed by the processor 701, it performs the functions defined in the centralized storage access request processing method of the embodiments of the present invention.

[0175] Figure 7 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0176] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the access request processing method under centralized storage shown in the above embodiments is implemented.

[0177] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0178] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by this application.

Claims

1. A method for processing access requests under centralized storage, characterized in that, The method is applied to a preset number of nodes, the nodes including a virtual file system used for synchronization of cache mirroring between the nodes, and the method includes: mounting a local file system, wherein the local file system is used for data exchange between the cache mirroring and a volume; in a case where an access request is received, if the access request is a read request and the cache mirroring does not contain target data corresponding to the access request, obtaining the target data from the volume according to the cache mirroring, updating the target data to the cache mirroring, and outputting the target data; if the access request is a write request and the cache mirroring contains target cache corresponding to the access request, changing the target cache according to the write request, and synchronizing the changed cache mirroring to other nodes through the virtual file system; if the access request is a read request and the cache mirroring contains the target data, obtaining a disk version and a local cache version corresponding to the target data, and if the disk version and the local cache version are the same in value, outputting the target data; if the access request is a write request and the cache mirroring does not contain the target cache, determining whether there is free cache in cache memory of the node; if the cache memory contains the free cache, taking the free cache as the target cache; if the cache memory does not contain the free cache, taking cache with a non-access duration greater than a first preset threshold in the cache memory as to-be-released cache, releasing the to-be-released cache, and taking the released to-be-released cache as the target cache.

2. The method of claim 1, wherein, The method further includes: when mounting the local file system, determining cache memory allocated to the node, wherein the cache memory is used for storing the cache mirroring; obtaining file system information of the local file system, space management information of the cache memory, and information index; writing the file system information, the space management information, and the information index into the cache memory; after mounting the local file system, connecting the node to other nodes through a remote direct memory access channel; broadcasting a memory address of the cache memory to the other nodes through the remote direct memory access channel, wherein the other nodes are used for obtaining the cache mirroring from the cache memory according to the memory address.

3. The method of claim 2, wherein, After mounting the local file system, the method further includes: determining a preset storage area in a volume where the local file system is located; obtaining a lock slot, a disk version, and lease information of the node, and storing the lock slot, the disk version, and the lease information to the preset storage area; mapping the preset storage area to the cache memory, and performing remote direct memory access protocol registration on a memory address of the cache memory, so that the other nodes can obtain the cache mirroring in the cache memory through the remote direct memory access channel.

4. The method of claim 3, wherein, The obtaining the target data from the volume according to the cache image, updating the target data to the cache image and outputting the target data comprise: reading the target data in the volume according to the cache image; obtaining the disk version corresponding to the target data in the volume and obtaining the local cache version corresponding to the target data in the cache image; updating the target data to the cache image and outputting the target data in the case that the disk version and the local cache version are the same.

5. The method of claim 4, wherein, After the storing the lock slot, the disk version and the lease information to the preset storage area, the method further comprises: obtaining a first identifier of the information index; determining a second identifier of the lock slot through a preset algorithm and the first identifier; writing the second identifier, the disk version and the local cache version into the information index; determining a standby lock slot in the lock slot in the case that the modification frequency of the information index is greater than a second preset threshold, and determining a third identifier of the standby lock slot through the preset algorithm and the first identifier; replacing the second identifier in the information index with the third identifier to obtain an updated information index, and synchronizing the updated information index to other nodes through the remote direct memory access channel.

6. The method of claim 2, wherein, After the writing the file system information, the space management information and the information index into the cache memory, the method further comprises: judging whether the information index exists in the cache image when updating the cache image; if the information index exists, locking the information index and updating the information index to obtain an updated cache image; synchronizing the updated cache image to other nodes through the remote direct memory access channel, unlocking the information index and downgrading the updated cache image to the volume; if the information index does not exist, locking a cache management area in the cache memory and obtaining an initial information index; locking the initial information index, updating the cache management area and the data cache in the cache memory to obtain an updated cache memory; synchronizing the data in the updated cache memory to the other nodes through the remote direct memory access channel, and unlocking the initial information index and the cache management area.

7. The method of claim 1, wherein, The mounting the local file system comprises: in the case that the node is a master node, obtaining a system log of the local file system; when the master node mounts the local file system, performing log replay repair on the local file system according to the system log; after the repair of the local file system is completed, instructing a slave node to mount the repaired local file system.

8. The method of claim 3, wherein, After the storing the lock slot, the disk version and the lease information to the preset storage area, the method further comprises: increasing the lease information by a preset step length every first preset time length; if the value of the lease information does not change within a second preset time length, regarding the node corresponding to the lease information as an offline node. In a case where the offline node is a master node, determining a new master node in a slave node; In a case where the offline node is the slave node, marking the offline node as offline; According to the lock slot, determining the lock corresponding to the offline node, and releasing the lock corresponding to the offline node.

9. An electronic device, comprising: Comprise: A memory and a processor, which are in communication connection with each other, and the memory stores computer instructions, and the processor executes the computer instructions to perform the access request processing method under centralized storage in any one of claims 1 to 8.

Images