Load balancing method and device of storage system, storage medium and electronic device

Abstract

The application discloses a load balancing method and device of a storage system, a storage medium and an electronic device, relates to the technical field of storage systems, and comprises the following steps: searching for at least one reference state element matched with each of reference data corresponding to the address of target data in a data state table based on target data information of the target data; determining reference sub-data that coincides with the address of the target data in the reference data, and adjusting synchronization information corresponding to the reference sub-data in the reference state element to a no-data state; determining a target state element matched with the target data in the data state table, adjusting synchronization information corresponding to the target data in the target state element to an unsynchronized state; and writing the target data with the unsynchronized state of the synchronization information into a storage device, and adjusting the synchronization information corresponding to the target data from the unsynchronized state to a synchronized state. The technical problem that the storage system has low performance is solved, and the technical effect of improving the performance of the storage system is achieved.

Description

Technical Field

[0001] This application relates to the field of storage systems, and more particularly to a load balancing method and apparatus for a storage system, a storage medium, and an electronic device. Background Technology

[0002] Modern storage systems often employ a multi-controller cluster architecture. Storage systems need to use intelligent algorithms to allocate and manage data, ensuring that data can still be accessed even if a single controller fails, while avoiding uneven distribution of load among controllers in the cluster to maintain efficient system operation.

[0003] While multi-controller cluster architectures significantly improve the performance and reliability of storage systems, current storage systems typically employ static sharding strategies based on addresses or volumes to achieve load balancing among controllers. This divides the storage space into multiple data segments, each assigned to a specific controller. Static sharding can cause consecutive data requests to be split into multiple non-consecutive requests. Processing and transmitting these non-consecutive requests increases latency and impacts the overall performance of the storage system. In other words, storage systems in this technology suffer from relatively low performance. Summary of the Invention

[0004] This application provides a load balancing method and apparatus for a storage system, a storage medium and an electronic device, to at least solve the problem of low performance in storage systems in related technologies.

[0005] This application provides a load balancing method for a storage system, comprising: searching a data status table for reference status elements that match at least one reference data corresponding to the address of the target data based on the target data information of the target data, wherein the target data is data written by the server to the storage system, and the data status table is used to store the status elements that match the data in the caches of multiple controllers.

[0006] Identify the reference sub-data in the reference data whose address coincides with the target data, and adjust the synchronization information in the reference state element corresponding to the reference sub-data to a no-data state.

[0007] In the data status table, identify the target status element that matches the target data, and adjust the synchronization information in the target status element corresponding to the target data to the unsynchronized state.

[0008] Write the target data, which is in an unsynchronized state, to the storage device, and adjust the synchronization information corresponding to the target data from an unsynchronized state to a synchronized state.

[0009] This application also provides a load balancing device for a storage system, including: a first lookup module, used to look up reference status elements in a data status table that match the address of at least one reference data based on the target data information of the target data, wherein the target data is data written by the server to the storage system, and the data status table is used to store the status elements that match the data in the caches of multiple controllers.

[0010] The first adjustment module is used to determine the reference sub-data in the reference data whose address coincides with the target data, and adjust the synchronization information in the reference state element corresponding to the reference sub-data to a no-data state.

[0011] The second adjustment model is used to determine the target state element that matches the target data in the data state table, and adjust the synchronization information corresponding to the target data in the target state element to the unsynchronized state.

[0012] The third adjustment module is used to write the target data, which is in an unsynchronized state, into the storage device, and adjust the synchronization information corresponding to the target data from an unsynchronized state to a synchronized state.

[0013] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the load balancing method of any of the above-described storage systems when executing the computer program.

[0014] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the load balancing method of any of the above-described storage systems.

[0015] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described load balancing methods for storage systems.

[0016] This application describes a method for identifying reference status elements in a data status table that match the address of target data. The target data is data written by the server to the storage system. The data status table stores the status elements that match the data in the caches of multiple controllers. The method involves identifying reference sub-data in the reference data that overlaps with the address of the target data and adjusting the synchronization information corresponding to the reference sub-data in the reference status elements to a "no data" state. Next, the application identifies the target status element matching the target data in the data status table and adjusts the synchronization information corresponding to the target data in the target status element to an "unsynchronized" state. Finally, the application writes the target data (in an "unsynchronized" state) to the storage device and adjusts the synchronization information corresponding to the target data from an "unsynchronized" state to a "synchronized" state. By searching for reference status elements corresponding to the target data address in the data status table, the system ensures that data copies exist in multiple controller caches. Even if one or more controllers fail, data can still be recovered from other controllers or backend storage devices, enhancing the system's fault tolerance and data consistency. The process of adjusting the synchronization information of the target data from an "unsynchronized" state to a "synchronized" state ensures that data written from the server to the storage system can be correctly and promptly synchronized to the backend storage device. This step is crucial for maintaining data persistence and consistency, especially in scenarios requiring frequent data updates. Therefore, it can address the issue of low performance in storage systems within related technologies. Attached Figure Description

[0017] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the hardware environment of an optional load balancing method for a storage system according to an embodiment of this application;

[0019] Figure 2 This is a flowchart of an optional load balancing method for a storage system according to an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of an optional data status table according to an embodiment of this application;

[0021] Figure 4 This is a schematic diagram of another optional data status table according to an embodiment of this application;

[0022] Figure 5 This is a schematic diagram of an optional storage space according to an embodiment of this application;

[0023] Figure 6 This is a schematic diagram of an optional data writing process according to an embodiment of this application;

[0024] Figure 7 This is a schematic diagram of an optional data download process according to an embodiment of this application;

[0025] Figure 8 This is a schematic diagram of an optional memory reclamation process according to an embodiment of this application;

[0026] Figure 9 This is a structural block diagram of an optional load balancing device for a storage system according to an embodiment of this application. Detailed Implementation

[0027] 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.

[0028] 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.

[0029] In current multi-controller storage cluster systems, such as those involving RAID (Redundant Arrays of Independent Disks) technology and vendor-specific software, load balancing is typically achieved by slicing storage capacity into fixed sizes (e.g., 1MB) and then allocating these segments to specific controllers using algorithms such as modulo operations. While this fixed addressing and allocation mechanism can achieve a certain degree of load balancing, it has the following drawbacks in actual operation:

[0030] When a host initiates a read / write request spanning multiple data segments, existing technologies require splitting the originally continuous data request into multiple non-contiguous requests, each sent to a different controller. This splitting not only increases the number of communications between controllers but can also lead to data transmission delays, thereby reducing overall processing efficiency. The self-developed multipathing program on the server needs to parse the address range of the requested data and calculate the data segment ownership using a fixed algorithm. This process increases the host's CPU load, especially under high load, causing additional performance degradation.

[0031] The host machine must be equipped with a multipathing program developed by the storage manufacturer, which increases the dependence on vendor-specific software and limits the system's cross-platform compatibility and flexibility during upgrades. Updates and maintenance of this self-developed multipathing program often depend on the storage device manufacturer and may be incompatible with other software or operating system versions running on the host machine, leading to increased maintenance costs.

[0032] Data segment allocation methods based on fixed algorithms may fail to adapt to dynamically changing workloads or network conditions, leading to situations where some controllers are overloaded while others are idle, thus reducing the overall resource utilization of the system. Once data segment ownership is determined, even if the load on a certain controller exceeds its processing capacity, the system cannot intelligently reallocate the load to other less busy controllers. To address the above technical problems, this application proposes a load balancing method and apparatus for a storage system, as well as a storage medium and electronic device.

[0033] 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.

[0034] According to one aspect of the embodiments of this application, a load balancing method for a storage system is provided. As an optional implementation, the load balancing method for the storage system can be applied, but is not limited to, to applications such as... Figure 1 The illustrated hardware environment includes a load balancing system for the storage system. This load balancing system may include, but is not limited to, server 102, storage cluster 104, and storage disks 108. Storage cluster 104 includes controller A, controller B, controller C, controller D, and switch 106. In practice, there is no limit to the number of controllers in the storage cluster. Figure 1 The four controllers shown are for illustrative purposes only.

[0035] Server 102, as the initiator of data storage and retrieval, is the front-end entry point of the entire storage system. The server connects to the storage controller via an external card, sending read and write requests to the controller to access data on the storage devices. The server is the source of the storage system's workload, and the performance and response time of its read and write requests directly affect the user's experience with the system.

[0036] Server 102 includes external cards, such as Fibre Channel (FC) cards or Remote Direct Memory Access (RDMA) cards, providing a high-speed data transfer channel between the server and the storage controller. FC cards establish a dedicated storage network between the server and the controller via the FC protocol, while RDMA cards allow direct memory access between the server and the controller, reducing data transfer latency. The external card acts as a bridge between the server and the storage controller, and its performance determines the data transfer rate and efficiency.

[0037] Storage controllers (A, B, C, D) are responsible for handling read and write requests from the server, managing the cache, controlling data reading, writing and synchronization, and communicating with backend storage devices. Each controller has its own independent cache and external cards, and can communicate with other controllers through various methods (such as NTB, FC, RDMA, IB) to achieve data redundancy and distribution. The cache is a high-speed storage area in the storage controller, used to temporarily store frequently accessed data or data to be written to backend storage devices. By improving data access speed and reducing dependence on slow backend storage devices, the cache speeds up the response time of read and write operations.

[0038] Each storage controller can have a back-end external card, such as a Serial Attached SCSI (SAS) card, used to connect the controller to the back-end storage disks. Compared to front-end FC or RDMA cards, back-end cards may have slightly lower performance due to transmission distance or protocol characteristics.

[0039] Storage disk 108 is the actual data storage device in the storage system, which can be a RAID array composed of multiple disks or other types of storage media. The disk is responsible for persistently storing data and is fundamental to data durability and security. Storage disks provide the actual data storage space and are a key component for data redundancy and persistence.

[0040] A switch (or simply switch) is used to connect servers, controllers, and back-end storage devices to enable network communication. It is responsible for packet routing and forwarding, serving as a crucial hub for data flow within the system. Switches are essential network infrastructure that ensures smooth data communication between different parts of the system; their performance and stability are critical to the overall system operation.

[0041] After any controller (such as controller A) receives the target data sent by server 102, it searches the data status table for reference status elements that match the address of at least one reference data, based on the target data information. Here, the target data is the data written by the server to the storage system, and the data status table is used to store the status elements that match the data in the caches of multiple controllers. It then determines the reference sub-data in the reference data that overlaps with the address of the target data and adjusts the synchronization information corresponding to the reference sub-data in the reference status element to a no-data state. It then determines the target status element that matches the target data in the data status table and adjusts the synchronization information corresponding to the target data in the target status element to an unsynchronized state. Finally, it writes the target data in the unsynchronized state to the storage device (storage disk 108) and adjusts the synchronization information corresponding to the target data from the unsynchronized state to the synchronized state.

[0042] The data status table can be a table in controller A. After it is modified, the updated information can be transmitted to other controllers through switch 106. Other controllers can then synchronously update their internal data status tables to keep the data synchronized.

[0043] The application scenarios of the solution in this application are not limited to the above examples. The load balancing method of the storage system in this application can be used in storage clusters.

[0044] Embodiments of this application provide a load balancing method for a storage system. Figure 2 This is a flowchart of an optional load balancing method for a storage system according to an embodiment of this application; as follows: Figure 2 As shown, the load balancing method of this storage system includes:

[0045] Step S202: Based on the target data information of the target data, search the data status table for the reference status element that matches at least one reference data corresponding to the address of the target data. The target data is the data written by the server to the storage system, and the data status table is used to store the status elements that match the data in the caches of multiple controllers.

[0046] It should be noted that target data refers to the data written by the server to the storage system, which is the data unit in the entire data writing process. Target data information includes information used to locate and describe the data, such as the starting address (Logical Block Addressing, LBA), volume identifier (Logical Unit Number Identifier, LUN ID), and data length.

[0047] The data state table is a crucial data structure used to store and track the data state across multiple controller caches, including but not limited to whether the data is modified or unmodified, and in which controller caches the data exists. Each controller has its own independent data state table, which can only be accessed by itself. However, each data state table contains information about the data in each controller's cache, allowing information to be read even if the data is not in the same cache.

[0048] Reference data refers to a copy of data that already exists in the storage system and is associated with the target data address; it may reside in different controller caches. Reference status elements are elements associated with the reference data in the data status table. These elements contain status information about the reference data, such as which controller cache holds the latest copy of the data.

[0049] Based on the target data information, the system uses a data status table to find existing reference data and its corresponding status elements that match the logical block address of the target data. This is done to determine whether replicas of the target data already exist, the current status of these replicas (modified or unmodified), and which controller caches the replicas reside in.

[0050] In an optional implementation, upon the initial data write, the server sends a data request to the storage system. This request includes information such as the LUN ID, LBA, and data length of the target data. Upon receiving this data request, a controller in the storage system (e.g., controller A) parses the storage location and size information of the target data. Based on the LBA and LUN ID in the target data information, a hash value (feature value) is calculated using a specific hash function. This hash value is crucial for locating the relevant record in the data status table.

[0051] Using the calculated hash value, access the corresponding position in the data state table to find the reference state element that matches the target data address (LBA and LUN ID). The data state table is designed based on a hash linked list, meaning that each hash value corresponds to a linked list, and each element in the linked list stores the state information of the reference data. Traverse the linked lists associated with the hash values ​​and examine each reference state element.

[0052] It should be noted that each storage controller maintains a data status table (i.e., a linked list of data replica records). This table mainly contains the following information:

[0053] LUN ID and LBA_align of the data: used to identify the precise location of the data within the storage volume.

[0054] Data modification status: Indicates whether the data is modified (data in the cache is inconsistent with data on the backend disk) or unmodified (data in the cache is consistent with data on the backend disk).

[0055] Data holder: Records which controllers hold the latest version of the data in their cache.

[0056] Although each controller has its own data state table, these tables are not isolated. When data is written from the server to the storage system, the relevant data state information is synchronized to the data state tables of multiple controllers. For example, if data is first written to controller A, in addition to recording the data information in controller A's data state table, the data is also synchronized to controller B's cache, and the corresponding data state information is recorded in controller B's data state table.

[0057] In an optional implementation, the data state table can be stored and managed using a hash bucket linked list. This data structure combines the fast lookup characteristics of hash tables with the dynamic storage advantages of linked lists, making it well-suited for handling large amounts of scattered data state information that requires fast access.

[0058] Each hash bucket is an independent linked list used to store a set of data state elements. These buckets are located using a hash function, allowing specific data state information to be stored and retrieved quickly. The structure of a hash bucket can be as follows:

[0059] struct hash_bucket{

[0060] struct record *head;

[0061] struct record *tail;

[0062] };

[0063] typedef struct hash_bucket bucket_t;

[0064] The entire data state table is a linked list consisting of multiple hash buckets. Each bucket is accessed through an array index, which is the hash value minus 1 (because the index of the hash_chain array starts from 0). This format allows the system to quickly locate and manipulate data state information.

[0065] Step S204: Determine the reference sub-data in the reference data whose address coincides with the target data, and adjust the synchronization information corresponding to the reference sub-data in the reference state element to a no-data state;

[0066] It's important to note that reference sub-data is defined as the overlapping portion of data (i.e., data already existing in the controller cache) when the address of the target data coincides with that of the data already in the controller cache. In the data status table, the synchronization status reflects whether data synchronization between the cache and the backend storage device is complete. Adjusting to a no-data state means that if a write operation to the target data overwrites the reference sub-data, the original copy of the reference sub-data in the controller cache will be marked as invalid, i.e., a no-data state, indicating that the latest version of this data is no longer stored in the cache.

[0067] In an optional implementation, the synchronization information can be "Modified" or "Unmodified". "Modified" refers to a situation where data has been modified in the storage system's cache but has not yet been synchronized back to disk. This means that the cache stores the latest updated state relative to the data on the backend disk. For example, when a host performs a write operation on a data segment, a copy of that data segment is marked as "Modified" in the cache. At this time, the copy on the backend disk is still the old version of the data until a write-back or write-through operation is completed, at which point the data on the disk will be updated to be consistent with the cache. Conversely, "Unmodified" means that the data in the storage system is identical on both the cache and the disk; that is, the data copy in the cache is consistent with the version on the backend disk, or the data read from the backend disk into the cache has not been modified. In this state, both read and write operations can directly retrieve or update data from the cache or disk without additional synchronization steps.

[0068] When a data segment is marked as "Modified" in a controller's cache, it performs data redundancy according to preset rules (such as synchronizing only with another specific controller) to ensure data security and consistency. If the data remains in the "Modified" state after a period of time, the controller will flush the data to the backend disk at an appropriate time, at which point the data state changes to "Unmodified". During read operations, if a data segment is marked as "Unmodified" in the cache, the controller can choose to read from the cache or directly from the backend disk, depending on the real-time monitoring of response time and load status to select the most efficient read path.

[0069] It's important to note that, specifically in terms of numerical representation, the values ​​in the modified data record bit field indicate which sectors have modified data copies in the cache. Typically, bits set to True in the bit field correspond to data sectors that have been modified by the host but not yet written back to disk. In bits 44-51 (for modified data) and 52-59 (for unmodified data) of the status element, each bit corresponds to the status of a sector; a true value indicates that the sector contains data, and for the modified status, it means that the data in this sector has been modified in the cache. For unmodified data, if its status bits are set to all zeros (00000000), this means that no copy of this data exists in any controller cache, or all copies have expired, and the data needs to be read again from the backend disk.

[0070] In an optional implementation, the system needs to determine which controller caches contain data that overlap with the newly written target data address. If the target data completely or partially covers the reference sub-data, the system adjusts the status information of these reference sub-data to a no-data state, indicating that this part of the data is no longer considered a valid copy.

[0071] In an optional implementation, for reference sub-data that overlaps with the target data address, its corresponding modified and unmodified bits are adjusted to a no-data state (this is represented by modifying the modified and unmodified bits to 0 in the record element). This indicates that the write operation of the target data overwrites this part of the data, so a copy of this part of the data is no longer stored in the cache.

[0072] Step S206: Determine the target status element that matches the target data in the data status table, and adjust the synchronization information corresponding to the target data in the target status element to the unsynchronized state.

[0073] It should be noted that the target state element is a state record element that matches the target data, which includes the storage location of the target data, state information, and the identifier of the controller holding the data.

[0074] In an optional implementation, the LUN ID and LBA_align address of the target data can be used as input parameters. A hash value is calculated using a previously defined hash function. This hash value is used to locate a specific hash bucket in the data status table. The linked list of that hash bucket is traversed to find the element whose info field matches the LUN ID and LBA_align of the target data. Here, the info field contains address information and a data status identifier.

[0075] Once a matching record element, i.e., the target state element, is found, the synchronization information flag in that element is checked and updated. The synchronization information status related to the target data in the target state element is set to "Not Synchronized". In this state, the data is considered modified, meaning it has been modified in the cache but has not yet been persisted to the backend disk. The modified status bit in the target state element is updated to reflect the presence and modification status of the target data in the current controller cache. Simultaneously, based on the data holding status, bits 60-63 of the controller identifier are updated to indicate which controller caches hold the latest version of the target data.

[0076] Step S208: Write the target data, which is in an unsynchronized state, to the storage device, and adjust the synchronization information corresponding to the target data from an unsynchronized state to a synchronized state.

[0077] It's important to note that the unsynchronized state refers to the target data being in a controller cache but not yet flushed to the backend storage device. The synchronized state refers to the target data having been flushed from the cache to the backend storage device, and the data content on the storage device is consistent with that in the cache. Backend storage devices refer to disks or other non-volatile storage media in the storage system; data written to these devices is permanently stored and will not be lost even if the system loses power.

[0078] In an optional implementation, the system needs to check the synchronization status of the target data in the controller cache. If the target data is marked as "unsynchronized," it means that the system is ready to write this data to the backend storage device, thereby ensuring data persistence and consistency. After confirming that the target data's synchronization status is "unsynchronized," the controller will initiate a data flush operation to write the target data in the cache to the storage device.

[0079] Specific flushing operations may include: performing an integrity check on the target data before flushing to ensure that the data has not been corrupted or modified before writing; writing the data from the cache to a specified location on the storage device. This typically involves communication with the storage device and performing the actual write operation. During the data writing process, if any anomalies are encountered (such as storage device failure, communication errors, etc.), the system needs to have corresponding error detection and handling mechanisms, which may include data rewriting and fault recovery.

[0080] Once the data is successfully written to the storage device, the system updates the synchronization status information of the target data, that is, adjusts it from an unsynchronized state to a synchronized state. This process involves updating the status of record elements in the data status table to ensure that the data status tables of all controllers are consistent and reflect the latest data status. The specific flushing operation will be explained in detail later and will not be repeated here.

[0081] Example 1:

[0082] Taking a four-controller storage system as an example, assuming the server writes data to controller A, the following is an overall implementation process including steps S202, S204, S206, and S208:

[0083] After receiving a write request from the server, controller A parses the request information, calculates the hash value based on the LUN ID and LBA_align, and searches for a matching record element in the data state table. If no match is found, or if the record needs to be updated based on overwriting requirements, controller A records this new data state in the data state table, marking its synchronization state as "unsynchronized." The system determines whether other controllers have reference sub-data in their caches that overlap with the target data address, and adjusts the state of these reference sub-data to "no data." This step ensures the exclusivity of the data write and avoids data redundancy. Controller A synchronizes the data to controller B's cache and simultaneously updates controller B's data state table, so that controller B also records the state of the target data, but saves it as unsynchronized. At the appropriate time, controller A writes the unsynchronized target data to the backend storage device. After a successful write, controller A updates the state of the record element corresponding to this data in the data state table, adjusting it from unsynchronized to synchronized. Simultaneously, through a message passing mechanism, controller B and other controllers are notified of this state change, ensuring that the data state tables of all controllers are synchronized.

[0084] This application describes a method for identifying reference status elements in a data status table that match the address of target data. The target data is data written by the server to the storage system. The data status table stores the status elements that match the data in the caches of multiple controllers. The method involves identifying reference sub-data in the reference data that overlaps with the address of the target data and adjusting the synchronization information corresponding to the reference sub-data in the reference status elements to a "no data" state. Next, the application identifies the target status element matching the target data in the data status table and adjusts the synchronization information corresponding to the target data in the target status element to an "unsynchronized" state. Finally, the application writes the target data (in an "unsynchronized" state) to the storage device and adjusts the synchronization information corresponding to the target data from an "unsynchronized" state to a "synchronized" state. By searching for reference status elements corresponding to the target data address in the data status table, the system ensures that data copies exist in multiple controller caches. Even if one or more controllers fail, data can still be recovered from other controllers or backend storage devices, enhancing the system's fault tolerance and data consistency. The process of adjusting the synchronization information of the target data from an "unsynchronized" state to a "synchronized" state ensures that data written from the server to the storage system can be correctly and promptly synchronized to the backend storage device. This step is crucial for maintaining data persistence and consistency, especially in scenarios requiring frequent data updates. Therefore, it can address the issue of low performance in storage systems within related technologies.

[0085] It should be noted that in a storage system with multiple storage controllers, each storage controller can have its own data status table, and the information in each data status table should be synchronized. Therefore, each storage controller needs to create a data status table before storing data.

[0086] In an optional implementation, a hash list structure, typically implemented as a hash table, can be initialized for each controller. Each hash bucket corresponds to a fixed key value, incrementing from key=0 to key=n, where n represents the maximum number of hash buckets, preset by the system designer.

[0087] Create the following structure `struct hash`, and implement it as an array `struct hashhash_chain[n]` inside the controller;

[0088] struct hash{

[0089] int key;

[0090] void *head;

[0091] };

[0092] Wherein, key: a unique identifier for each hash bucket, used for hash calculation.

[0093] `head`: Points to the first `record` element of the hash linked list. The `record` element records the state and position information of the data segment. `head` is typically used as the head pointer of the linked list, allowing fast access to the first element. When adding a new data record to the linked list corresponding to the hash bucket, the `head` pointer can be used to traverse the entire list to find the appropriate insertion position, or it can be used to directly insert the new element at the head of the list (if the linked list supports this operation). Similarly, if you want to delete an element from the linked list, or need to traverse all elements in the linked list to perform certain operations (such as updating the state or searching for specific data), the `head` pointer is also the starting point for traversal.

[0094] Figure 3 This is a schematic diagram of an optional data status table according to an embodiment of this application; as shown... Figure 3 As shown, the data status table 302 can include multiple hash buckets, with each key value corresponding to a hash bucket. Data with the same key value can be placed into that hash bucket later.

[0095] You can also create a resource pool containing a certain number of record structure elements, which will be dynamically allocated and recycled as data is written and the status is updated.

[0096] The state element can be a struct record, which is defined as follows:

[0097] struct record{

[0098] uint64 info;

[0099] void*next;

[0100] };

[0101] The info field is a 64-bit unsigned integer used to store composite data information, where different bit segments represent different information.

[0102] Bits 0-31: These 32 bits represent the lba_align address, which is the alignment result of the logical block address (data block sequence number). It identifies the specific location of the data on the volume, facilitating data location and management.

[0103] Bits 32-43: These 12 bits are used to store the volume ID (lun_id), which is the logical unit number (data unit number). In a storage cluster, there may be multiple volumes, each corresponding to a different storage space or dataset. The lun_id is used to distinguish different volume information.

[0104] Bits 44-51: Each of these 8 bits corresponds to a storage sector. When a bit is set to true, it indicates that the sector exists in the current controller's cache and its data status is modified, meaning that the data has been modified but has not yet been synchronized to the backend disk.

[0105] Bits 52-59: Similar to bits 44-51, each of these 8 bits also represents a storage sector, but here it marks the unmodified state of the sector, that is, the data has not been modified and the data in the cache is consistent with the data on the disk.

[0106] Bits 60-63: Each of these four bits corresponds to a controller in the cluster. When a bit is set to true, it indicates that the latest copy of the current data segment exists in the cache of the corresponding controller. This flag is crucial for load balancing and data redundancy management because it helps the system quickly locate the location of data copies to make the optimal choice when reading or synchronizing data. This bit can be set according to the number of storage controllers in the cluster, with the number of bits matching the number of controllers. The four bits given above are an example for four controllers.

[0107] The `next` field is used in the linked list implementation; it's a pointer to the next `record` structure in the list. In a hash linked list, the `next` pointer allows traversal from the current `record` structure to the next record, until the end of the list or a matching key value is found. During system initialization, multiple `record` resources (state elements) are generated and stored in a resource pool. These resources will be used for subsequent actual data writing and state update operations.

[0108] In addition, each controller initializes a monitor structure to record the communication response time with other controllers (response_controller) and the response time with the backend disk (response_backend).

[0109] The struct monitor is defined as follows:

[0110] response_controller[]: An array that records the communication response times between the current controller and the other three controllers.

[0111] response_backend: Records the communication response time between the current controller and the backend disk.

[0112] Example 2:

[0113] Assuming the system is designed with 1024 hash buckets, controller A begins initializing its data synchronization recording and query resources: It initializes `struct hash hash_chain

[1024] `, ensuring each hash bucket has a corresponding structure instance. It generates 10,000 `record` resource instances, stores them in a resource pool, and waits for allocation during subsequent data write operations. It initializes `struct monitor`, setting all `response_controller` array elements and `response_backend` to initial values, such as 0 or the maximum possible latency, to mark the startup status of the monitoring mechanism. As the system runs, each data write triggers a resource pool allocation, synchronously recording it in the corresponding hash bucket, and simultaneously updating the response time in the monitoring mechanism, providing real-time performance metrics for subsequent load balancing and data reading decisions. This ensures the system can flexibly adapt to constantly changing network environments and workloads, maintaining high performance and stability.

[0114] In an optional implementation, searching a data status table for reference status elements that match at least one reference data corresponding to the address of the target data based on the target data information includes: determining the target feature value corresponding to the target data according to the target data information, wherein the target data information includes the target data unit number, the target data address, and the target data length; determining at least one candidate data with the same target feature value in the data status table, wherein the data status table is used to manage at least one data according to the feature value; and determining at least one candidate data corresponding to the target data address as reference data.

[0115] It should be noted that the target data information is the data identification information carried in server write or read operations, mainly including the target data unit number (LUN ID), target data address (LBA), and target data length. The target feature value is a value calculated using a hash function based on the target data information, used to quickly locate the corresponding data status record in the data status table.

[0116] In an optional implementation, the target data unit number (LUN ID), target data address (LBA), and target data length are extracted from the target data information. Using a predefined hash function, the target feature value `hash_id` is calculated as input to the LUN ID and `LBA_align`. This feature value is used to locate the relevant record in the data status table. In the data status table, the calculated `hash_id` is used to locate the corresponding hash bucket. The linked lists in the hash bucket are traversed to find candidate data record elements with the same `hash_id`. For each candidate data record element, the `lun_id` and `lba_align` in the `record.info` field are further checked to see if they completely match the target data information. If they match, then this record element records the reference data corresponding to the target data address. Based on the data status (modified or unmodified) and the data holder information (60-63 bits), it can be determined where to obtain the data or how to process the data.

[0117] In optional implementations, a suitable hash function is selected to ensure high hashing performance and low collision rate. For example, high-performance hash functions such as MurmurHash and CityHash can be used. The data status table is indexed based on the target feature value `hash_id` to quickly locate the hash bucket storing the target data status. Then, the linked lists in that bucket are traversed to find records that match the target data information. For each candidate data record element found, the system needs to determine its status. If the data status is "modified," the data is read from the controller holding the data; if the status is "unmodified," it can be preferentially read from the backend disk, or the best data source can be selected based on the backend response time and the controller cache status.

[0118] Figure 4 This is a schematic diagram of another optional data status table according to an embodiment of this application; as shown Figure 4 As shown, each hash bucket in the data status table 302 can store a status element corresponding to the data. Searching the data status table means searching for the status element within it.

[0119] Suppose the storage system is processing a read request from a server. The request contains target data with LUN ID=0, lba=2, and length=10. A hash function is used to calculate the target feature value `hash_id`. In the data status table, the `hash_id` is used to locate the specific hash bucket. Then, the linked lists in the bucket are traversed to find candidate data record elements with the same `hash_id`. For each found candidate data record element, the system checks if `lun_id` and `lba_align` match the target data information. If they match, the reference data represented by that record element will be used to process the read request. If the reference data is in a modified state, the system will read the data from the controller cache holding the data and return it to the server. If the reference data is in an unmodified state, the system can choose to read the data from the backend disk or from the controller cache with a shorter response time, based on the monitored response time.

[0120] Through the above embodiments of this application, it can be seen how the storage system utilizes a data status table and feature value mechanism to efficiently and accurately locate reference data, thereby making optimal processing decisions during read or write operations. This mechanism effectively improves the load balancing capability and data redundancy management efficiency of the storage system, and is one of the important technologies for realizing high-performance storage systems.

[0121] In an optional implementation, before searching for a reference status element in the data status table that matches the address of at least one reference data based on the target data information of the target data, the method includes: receiving a first instruction sent by a server, wherein the first instruction instructs to write first data to a storage device; calculating a first ratio of the data address of the first data to the data block size, and determining the first ratio as the data block number of the starting data block of the first data; determining the number of data blocks covered by the first data according to the data block number of the starting data block and the data length of the first data; and dividing the first data into at least one target data according to the number of data blocks, wherein each target data corresponds to one data block.

[0122] Figure 5 This is a schematic diagram of an optional storage space according to an embodiment of this application; as shown Figure 5 As shown, the physical resources of the disk array 506 can be abstracted into a storage pool 504 and provided to servers or hosts in the form of data units 502 (including multiple volumes).

[0123] In storage system architecture, volumes, storage pools, and disks are three important components, each playing a different role and working together to provide efficient and reliable data storage services.

[0124] A volume (LUN - Logical Unit Number), often referred to as a LUN (Logical Unit Number, i.e., Data Unit Number), is a logical unit of storage provided by a storage system to a host. From the host's (such as a server's) perspective, a volume is like a local disk; it can be formatted, partitioned, and mounted for storing data and running applications. A volume is the basic unit of storage resource allocation. When a host needs storage space, it is allocated one or more volumes, each with a specific size and access attributes. Volumes can be configured with different RAID levels to provide data redundancy and performance optimization. The host accesses volumes through standard storage protocols (such as FC, iSCSI, NFS, etc.) to perform read and write operations. The host operates on volumes as if they were local disks, while the storage system is responsible for managing the specific physical disk space and data distribution.

[0125] A storage pool (504) is a logical container in a storage system that virtualizes and manages multiple physical disks or storage devices in a unified manner. A storage pool can contain multiple disks, integrating their storage space into a contiguous, scalable storage resource using software-defined storage technology. Storage pools allow for dynamic allocation and reclamation of storage resources. By aggregating the storage capacity of multiple disks, a storage pool can provide the necessary space for a volume and can dynamically adjust the volume size as needed. The storage pool also performs fault tolerance, such as RAID 5 / 6, to protect data from disk failures. It distributes data and redundant information across multiple disks using striping and parity checking techniques. A volume is allocated from the storage pool, and its actual storage space is provided by the disks within the pool. The volume provides the host with a logical view of the storage, while the storage pool manages the actual state and distribution of the backend physical disks.

[0126] A disk is a physical storage device in a storage system used to store data and parity information. Disks can be traditional HDDs (Hard Disk Drives) or SSDs (Solid State Drives), connecting to the storage controller via high-speed interfaces such as SAS and NVMe. Disks provide basic storage space and are the final destination for persistent data storage. All data, including data within a volume, must ultimately be written to the disk to ensure it is not lost due to power failures or controller crashes. Disks are also responsible for data read and write operations, as well as responding to commands from the storage controller, such as data synchronization and parity reconstruction. Disks are the fundamental building blocks of a storage system; their performance and reliability directly affect the overall system performance and data security. In a multi-controller redundant storage cluster, disks are connected to multiple controllers, allowing controllers to synchronize data via disks to achieve redundant data storage.

[0127] It should be noted that a data block can be the basic unit used to manage and store data in a storage system; here, the data block size is set to 4KB. The data block number is the location identifier of the data block in the storage system, obtained through a modulo operation between the data address and the data block size. The data address can be a logical address. The smallest granularity for reading and writing storage is 512 bytes, or 1 sector; 4KB = 8 sectors. Therefore, a data block can include data from 8 data sectors, and the data address indicates which data sector it is. The data unit number is the same as the volume number mentioned above.

[0128] After receiving the first instruction from the server, which directs the storage system to write the first data, the system needs to perform a series of preprocessing steps to determine how to effectively manage and store this data, while taking into account the updates to the data status table and the overwriting of data blocks on the storage device.

[0129] In an optional implementation, a first instruction sent by the server is received, which contains a request to write first data. This is the starting point of the storage system's data management process, and subsequent operations are performed based on this instruction. A first ratio of the data address of the first data to the data block size is calculated, and this ratio is determined as the starting data block number of the first data. This step is crucial for determining the precise location of the data on the storage device and is the basis for subsequent data block processing. Based on the starting data block number and the data length of the first data, the number of data blocks on the storage device that the first data will cover is determined. This helps the system understand the scope of the data write operation to accurately manage the use and status of data blocks. According to the determined number of data blocks, the first data is divided into at least one target data, with each target data corresponding to one data block. This ensures efficient data management in blocks, facilitating subsequent storage, retrieval, and state synchronization.

[0130] In an optional implementation, the server write request received by the controller contains information about the first data (such as LUN ID, LBA address, and write data length), which the controller parses and stores. The starting data block number of the first data is calculated using the following formula:

[0131] lba_align=lba%block_size;

[0132] Here, `block_size` is 4KB, and `lba` is the logical block address (i.e., the data address). The result is the starting data block number, and the remainder can be the starting data address within the starting data block. Based on the length and `block_size` of the first data block, the number of data blocks to be covered is determined. For example, if `length` is 10 sectors and `block_size` is 4KB (i.e., 8 sectors), then the data will cover one complete data block, and some data may extend beyond the first data block, but will not exceed the size of the next data block.

[0133] Through the above-described embodiments of this application, this data processing method not only optimizes the data management process of the storage system and improves write efficiency, but also effectively updates the data status table, ensuring data consistency and reliability. This is one of the key steps in achieving efficient and reliable operation of the storage system.

[0134] In an optional implementation, determining the target feature value corresponding to the target data based on the target data information includes: determining the number of feature values ​​included in the data status table; and determining the remainder between the sum of the target data unit number of the target data and the data block sequence number of the data block to which the target data belongs and the number of feature values ​​as the target feature value.

[0135] It should be noted that, as mentioned earlier, the target data can be data from a data block in the first data. For each data block in the first data, its feature value must be calculated, and its corresponding reference data must be found in the data status table.

[0136] In an optional implementation, the number of feature values ​​in the data state table (i.e., the total number of hash buckets) is set during the system initialization phase. This number is typically based on the expected performance and capacity of the storage system, as well as the probability of possible hash collisions. The LUN ID and LBA_align values ​​are extracted from the target data information. The target feature value is calculated using the formula hash_id = (lun_id + lba_align) % (n + 1). Here, hash_id is the target feature value, lun_id and lba_align are the identification information of the target data, and n + 1 is the total number of feature values ​​(hash buckets) in the data state table.

[0137] During system startup or configuration, the number of feature values ​​in the data state table (i.e., the total number of hash buckets) is determined and stored as a global constant. From server write or read requests, the LUN ID and 4k-granular LBA_align address of the target data are parsed. Using the calculated hash_id, the specific record element is located in the hash chain of the data state table to retrieve or update the state information of the target data.

[0138] The above-described embodiments of this application enable efficient determination of the location of target data in the data status table, which is crucial for storage systems handling large amounts of data states. It not only accelerates data retrieval but also simplifies data management processes, serving as an important technological foundation for optimizing storage system performance and managing data redundancy.

[0139] In an optional implementation, determining the target state element matching the target data in the data state table includes: determining the reference controller where the reference data is located and the target controller where the target data is located; if the reference controller and the target controller are the same controller, updating the reference state element to obtain the target state element; if the reference controller and the target controller are different controllers, creating a new target state element in the data state table.

[0140] It should be noted that the reference controller can be the storage system controller holding the reference data, and may not be the same controller processing the target data. The target controller can be the controller currently processing the target data, and needs to update or add target state elements to the data state table.

[0141] The process of determining the target state element that matches the target data in the data state table includes two main steps: first, determining whether the controller where the reference data is located and the controller where the target data is located are the same controller; second, based on the determination result, deciding whether to update the original data state record or create a new target state element in the data state table.

[0142] If the reference controller and the target controller are the same controller, it means that the current controller already knows the existence and state of the data. In this case, the system will directly update the existing reference state elements to reflect the state information of the target data. The updates may include the data's modified state, unmodified state, and data holder identifier, etc.

[0143] If the reference controller and the target controller are not the same controller, it means that the target controller needs to add a new record to manage the status information of the target data. Therefore, the system will create a new target status element in the data status table to store the relevant status information of the target data, and update fields such as the data holder identifier to ensure the accuracy and completeness of the data status information.

[0144] In an optional implementation, if the target and reference controllers are the same, the target feature value `hash_id` is calculated using the LUN ID and LBA_align of the target data to locate the hash bucket in the data status table. The hash bucket linked list (data status table) is traversed to find a reference status element that matches the target data address. If the reference data and target data completely or partially overlap, the `info` field of the reference status element is updated to reflect the existence and modification status of the target data. The `modified` or `unmodified` status bits are modified, and the controller identifier bits 60-63 are updated based on whether the data has been modified and which controller caches the data. The data status is updated, marking the target controller as the data holder, i.e., updating the corresponding controller identifier bits in bits 60-63 to 1, indicating that the latest version of the data exists in the target controller's cache.

[0145] In an optional implementation, if the target controller and the reference controller are different, and if the reference controller and the target controller are not the same controller, the system needs to create a new target state element in the data state table. A new record element is requested from the data record resource pool, populated with the LUN ID, LBA_align, and data state information, and the target controller is marked as the data holder. The hash bucket determined by the hash_id is located, and the newly created target state element is inserted into the linked list of that hash bucket.

[0146] Through the above-described implementation methods of this application, regardless of whether the target data and reference data are located on the same controller, the system can efficiently and accurately update or add data status information, ensuring that the data status table always reflects the most accurate and complete data status in the storage system. This is crucial for load balancing, data redundancy, and consistency management in the storage system.

[0147] In an optional implementation, updating the reference state element to obtain the target state element includes: when all the reference data and the address of the target data overlap, adjusting the synchronization information in the reference state element corresponding to the address of the target data to an unsynchronized state; adjusting the controller indicator bit in the reference state element to indicate the target controller where the target data is located to obtain the target state element, wherein the controller indicator bit is used to indicate the controller where the data corresponding to the state element is located.

[0148] It should be noted that the controller indicator bit is part of the state element and is used to indicate which controllers hold copies of the data corresponding to the state element in their caches.

[0149] When a server requests to write target data to the storage system, if the address of the target data overlaps with the address of existing data, the system needs to update the status information (reference status element) in the data status table that matches these data addresses to reflect the latest status of the target data. This includes marking it as "unsynchronized" and updating the controller indicator bit to indicate the target controller where the target data is now located. This process ensures the accuracy of the data status table and the consistency of data management.

[0150] In an optional implementation, the characteristic value hash_id of the target data is calculated based on the target data information (LUN ID, LBA_align, and length). In the data status table, the linked list corresponding to hash_id is located, and a reference status element that overlaps with the target data address is searched. If the address of the reference data completely overlaps with the target data, the synchronization information (modified bit) in the reference status element is adjusted to the "unsynchronized" state, indicating that the data is still in the cache and has not been flushed to disk. This update operation ensures that the system can track which data needs to be flushed to disk as soon as possible to ensure data persistence and consistency. The controller indicator bits (bits 60-63) in the reference status element are updated to indicate the target controller where the target data resides. This step is to update the data holder information, letting the system know the current storage location of the target data. If multiple controllers simultaneously hold copies of the target data, then the corresponding controller indicator bits will all be set to true.

[0151] Example 3:

[0152] In a four-controller storage cluster, the system is processing a new write I / O request aimed at updating data on a specific storage volume (lun_id=0). The request begins at logical block address lba=2 and requires writing data equivalent to 6 sectors, i.e., length=6. The current record state of the system is as follows:

[0153] The record.info field for lba=2 contains the following information:

[0154] The modified data record bits 44-51 are 00111100, which means that in the previous operation, controllers A and B cached modified data (data that was modified but not synchronized to the backend disk) of some sectors starting from lba=2.

[0155] Alternatively, if unmodified data record bits 52-59 are 00011100, it means that in addition to controllers A and B, controller C also caches unmodified data (a cached copy consistent with the backend disk data) for some sectors starting from lba=2.

[0156] This write IO request covers all 6 sectors starting from lba=2, therefore it will cover the portion of the modified data record bits 44-51 and the unmodified data record bits 52-59 in the record.info field that corresponds to this coverage range.

[0157] Because the new data completely covers the six sectors starting from lba=2, the modified data record bits (bits 44-51) are updated accordingly to 00111111, which accurately reflects the modified status of the current data segment. If the previous unmodified data record bits (bits 52-59) contained sectors within this coverage range, they now need to be cleared because the data status of these sectors has changed to modified. Therefore, the unmodified data record bits will be updated to 00000000.

[0158] Since the latest modified data is now held in the caches of controllers A and B, the controller indicator bits 60-63 are updated to 1100, which means that only the latest copy of the data for the 6 sectors starting with lba=2 is held in the caches of controllers A and B.

[0159] After the above operations, the record.info field status is updated as follows: Modified data record bits 44-51 are updated to 00111111, indicating that the data in the 6 sectors starting from lba=2 has been modified, and the data status of these sectors is marked as modified. Alternatively, unmodified data record bits 52-59 are updated to 00000000, meaning that the data in the 6 sectors starting from lba=2 is no longer considered a cached copy consistent with the backend disk data. Controller indication bits 60-63 are updated to 1100, explicitly indicating that the caches of controllers A and B now hold the latest data for the 6 sectors starting from lba=2.

[0160] Through the above-described embodiments of this application, the system not only efficiently updates the data status table but also ensures the accuracy of the data status information, thereby helping to improve data read / write efficiency and system consistency. In subsequent operations, when a read request occurs, the controller can quickly locate the data based on the information in the data status table and determine from which to read the data based on the controller's instruction bits, achieving load balancing and redundancy optimization.

[0161] In an optional implementation, updating the reference state element to obtain the target state element includes: adjusting the synchronization information in the reference state corresponding to the address of the target data to an unsynchronized state when the address of the reference data does not overlap with that of the target data.

[0162] In an optional implementation, a target feature value is calculated using a hash function based on the LUN ID and LBA_align address of the target data, thereby locating the reference status element in the data status table that matches the target data address. The system checks whether the data address recorded in the reference status element completely overlaps with the address of the target data. If the address of the reference data does not completely overlap with the address of the target data, it means that the writing of the target data will overwrite part or all of the content of the reference data. For reference data whose address does not completely overlap with the target data address, the system adjusts the synchronization status in its status information to the unsynchronized state. This reflects the situation where the data may exist in the cache after the write operation, but has not yet been flushed to the backend storage device.

[0163] Example 4:

[0164] In a four-controller storage cluster, the system is processing a new write I / O request. The target data segment starts at lba=2 and covers 6 sectors (length=6). Before processing this write I / O request, the status of the record.info field is:

[0165] If modified data record bits 44-51 are 11000000, it means that data was previously stored in the caches of controllers A and B, but this data is not covered by this write operation. Similarly, if unmodified data record bits 52-59 are 11000000, controllers A and B hold copies of the data identical to the backend disk data in their caches, but these copies are also outside the scope of this write operation. If controller indicator bits 60-63 are 1100, it indicates that controllers A and B hold some data copies at this location in their caches.

[0166] This write operation (starting from lba=2 and covering 6 sectors) did not affect the data status recorded in the record.info field. However, considering data redundancy and consistency maintenance strategies, it is necessary to check whether the original data holder is the same as the current data holder, and update the modified and unmodified data record bits and the controller indicator bits in the record.info field accordingly.

[0167] For the data overwritten by this write operation, bits 44-51 of the modified data records are updated to 00111111. This indicates that the data in the six sectors starting from lba=2 is now in a modified state, and only controller A holds a copy of the data in these sectors. Because the data in these sectors is now marked as modified, the bits previously marked as unmodified need to be cleared. Even in controllers A and B, bits 52-59 of the unmodified data records are updated to 11111111. These updates ensure the accuracy of the modified and unmodified bit fields in the record.info field, reflecting the true state of the data.

[0168] Since controller A now holds the latest modified data for the six sectors starting at lba=2, controller indicator bits 60-63 need to be updated to reflect this change. In this example, controller A's indicator bits remain at 1, while the indicator bits for the other controllers (B, C, D) are at 0. Therefore, the indicator bits remain at 1100, indicating that controllers A and B still hold unmodified data copies in their caches, while controller A has now added a modified data copy.

[0169] Through the above-described implementation of this application, even if the write operation does not rewrite the data recorded in the record.info field, the system still updates the data redundancy status and controller indicator bits, ensuring the accurate implementation of the data redundancy strategy while maintaining data consistency and load balancing among controllers. This meticulous data management strategy is key to data reliability and performance optimization in storage systems.

[0170] In an optional implementation, before determining the reference sub-data in the reference data that overlaps with the target data address, the method includes: if no reference data corresponding to the address of the target data is found in the data status table, a new target status element is created in the data status table.

[0171] It should be noted that when processing server requests, if no existing data (reference data) corresponding to the target data address is found in the data status table, the system needs to create a new target status element to record the status information of the target data during this read / write operation. This mechanism ensures that the data status can be correctly tracked and managed even without previous data records, ensuring data redundancy and load balancing.

[0172] In an optional implementation, the instructions sent by the server are parsed to obtain the LUN ID, LBA_align, and length of the target data. Based on the LUN ID and LBA_align, a hash function is used to calculate the characteristic value hash_id of the target data, which serves as the basis for finding or creating a new state element. The hash_id is used to attempt to find an existing reference state element in the data state table. If no reference state element corresponding to the target data address is found, it indicates that this is the first time the data information has been recorded. A new record resource is requested from the data record resource pool as the target state element. The record.info field is populated, including the LUN ID, LBA_align, the corresponding modified or unmodified status bits, and the target controller identifier bits (bits 60-63). The newly created target state element is inserted into the hash bucket determined by hash_id.

[0173] Through the above-described embodiments of this application, when processing data read requests in a storage system, if the data at the target address is not yet recorded in the data status table, the system will automatically create a target status element to track and manage the status and location information of this new data. This not only improves the content of the data status table but also provides the necessary basis for subsequent data management operations (such as data synchronization and read redirection), ensuring the load balancing and data redundancy capabilities of the storage cluster.

[0174] In an optional implementation, a new target state element is created in the data state table, including: obtaining candidate state elements and setting each position of the candidate state element as an initial value; writing the target data unit number of the target data and the data block sequence number of the data block to which the target data belongs into the candidate state element; adjusting the synchronization information corresponding to the address of the target data in the candidate state element to an unsynchronized state, and adjusting the controller indicator bit in the candidate state element to indicate the target controller where the target data is located, thereby obtaining the target state element.

[0175] In an optional implementation, a new record element is allocated from the data record resource pool as a candidate state element. All fields of the candidate state element are set to their initial or default values. For example, the modified and unmodified state bits might be set to all 0, indicating an unknown or initialized data state. The LUN ID and LBA_align of the target data are written to the candidate state element to identify the data's storage location. The synchronization information corresponding to the target data address is adjusted to an unmodified state (if the data comes from a backend disk) or a modified state (if the data is being written to the cache for the first time). The controller indicator bit in the candidate state element is set to indicate the target controller where the target data resides, thus identifying the target controller as the one currently holding the latest version of the target data.

[0176] In an optional implementation, a new record element is allocated as a candidate for creating a new target status element. All bits in the record.info field are set to their initial state, for example, 0000000000000000000000000000000000. The corresponding bits in the record.info field are updated based on the LUN ID and LBA_align information of the target data. If the target data is being written for the first time, the modified status bit of record.info is set to true, indicating that the data is in a modified state in the controller cache and has not yet been flushed to the backend disk. Bits 60-63 are set to the identifier of the target controller; for example, if the target controller is A, these four bits are set to 0001, indicating that controller A stores the latest version of the target data in its cache.

[0177] Through the above-described implementation method of this application, a target status element is successfully created in the data status table to accurately record the latest status and location information of the target data. This not only helps optimize data management but also ensures that the system can quickly and accurately locate and process the target data during subsequent data reading and redundancy management, achieving efficient and stable operation of the storage system.

[0178] Example 5:

[0179] Figure 6This is a schematic diagram of an optional data writing process according to an embodiment of this application. When the server performs a write operation, it generates a write IO request, which contains the data to be written and the target location information of the data. Instead of directly sending the write IO to a fixed storage controller, the storage system adopts a controller round-robin scheduling method. In a four-controller storage cluster, this means that write IO requests will be sent to each of the four controllers (A, B, C, D) in a predetermined order for processing. This round-robin controller selection method is based on a simple loop algorithm. It can be based on the controller number order or a more complex dynamic scheduling based on load conditions, but the core objective is to ensure that the number of write IO requests processed by each controller is approximately equal within a certain period of time.

[0180] The storage system has a controller selection queue in the backend. Each time a server initiates a write I / O request, the storage system checks the current order of the queue and assigns the write I / O request to the next "turned" controller. The queue order can be fixed in advance, for example, cycling through controllers A→B→C→D; or it can be dynamically adjusted according to real-time load conditions to ensure that requests are always sent to the controller with the lightest current load.

[0181] In a storage cluster with four controllers (A, B, C, and D), the data synchronization mechanism aims to achieve data redundancy and load balancing, thereby ensuring data security and system performance. It allows one controller to receive data and then send the target data to the other controllers, such as... Figure 6 As shown, controller A sends the target data to controller B to achieve data synchronization. Controller A can also send update information to controllers C and D to achieve information synchronization of the data status tables of all controllers.

[0182] The choice of controller for data synchronization can be made according to needs. For example, you can synchronize all controllers or any number of controllers. The following example demonstrates synchronizing one controller. A synchronization rule can be set for it, such as: A→B→C→D.

[0183] Any write operation from the host, if received by controller A, will synchronize that data to the cache of controller B. This ensures data replication at at least one redundant point, so that even if controller A fails, the data can still be recovered from controller B. Similarly, upon receiving a write IO, controller B will synchronize the data to controller C, establishing data redundancy and avoiding infinite loops or unnecessary multiple copies of data within controller B. Upon receiving a write IO request, controller C will synchronize the data to controller D in the next link in the chain. This ensures data redundancy while adhering to the chain propagation rules, avoiding duplicate data synchronization and potential performance bottlenecks. When controller D receives a write IO request, it will synchronize the data back to the beginning of the chain, i.e., controller A. This forms a closed-loop chain synchronization pattern, allowing each controller to be both the start and end point of data propagation, achieving a uniform distribution of data within the cluster.

[0184] For controller A, after receiving the target data, it can process the target data. The server initiates a write request to the storage cluster through the FC card. The write request data packet contains the LUN ID of the target volume, the starting LBA address of the target data, and the data length. In order to better manage the data, the system divides the data into 4KB granularities to facilitate subsequent data synchronization and status updates. With LBA=2, lba_align=0 is calculated by lba_align=lba%4k. The hash value is calculated using lba_align and LUNID to locate the hash bucket. The hash value is calculated by hash_id=(0+0)%(n+1). Assuming that n+1=5 during initialization, hash_id=0%5=0 is obtained. In the data status table, the calculated hash_id is used to locate the corresponding hash bucket, i.e., hash_chain[0]. The record elements in the hash bucket are traversed to find the record related to the current write operation. In hash_chain[0], a record element is found with lun_id=0 and lba_align=0.

[0185] The target data segment starts at address lba=2 and covers 6 sectors (length=6). Assuming that bits 44-51 of the modified data record in the record.info field are 11111100, this means that data from 8 sectors is in a modified state in the caches of controllers A and B, but this write operation only covers the first 6 sectors. Similarly, bits 52-59 of the unmodified data record are 11011100, indicating that controllers A and D hold copies of the data consistent with the backend disk in their caches, but only a portion of these copies are covered by this write operation.

[0186] This write operation covered six sectors starting from lba=2. These six sectors were marked in the record.info field as existing in the caches of different controllers, but the coverage only overlapped with the sectors related to controllers A and B. When some data is overwritten and the original data holder is different from the current data holder, the modified or unmodified data record bits in the record.info field need to be updated to reflect the latest data status.

[0187] Specifically, if the original data is marked as modified, then the modified data record bits (bits 44-51) of the overwritten portion are updated to 1100000. This preserves the modified data of the uncovered portion while clearing the mark of the overwritten portion. Similarly, if the original data is marked as unmodified, then the unmodified data record bits (bits 52-59) of the overwritten portion are updated to 11000000. This preserves the unmodified data of the uncovered portion while clearing the mark of the overwritten portion.

[0188] To record the data status of this write operation, the system will request a new record resource from the data record resource pool. In this new record, the `lun_id`, `lba_align`, and `modified` data record bits in the `info` field are set to the data information of this write operation, i.e., `lun_id`=0, `lba_align`=0 (calculated based on `lba=2`), and the `modified` data record bit is set to 00111111, reflecting that the data in the 6 sectors starting from `lba=2` is now in a modified state. Finally, the controller indicator bits (bits 60-63) are modified to 1100, indicating that controllers A and B now hold the latest data copies of the 6 sectors starting from `lba=2` in their caches.

[0189] After the data is cached and stored in controller A, the system needs to synchronize the data to controller B to achieve data redundancy. Figure 5 The data channel transmits newly written data from controller A to controller B, ensuring data security and availability. In addition to directly synchronizing data to controller B, it's also necessary to inform controllers C and D of data updates so they can maintain the consistency of their data state tables. The message channel notifies controllers C and D of data changes (such as LUN ID, LBA, length, and updated data state).

[0190] In an optional implementation, after writing the target data with synchronization information in an unsynchronized state to the storage device, the process includes: upon receiving a second instruction from the reference controller, searching in the data status table for reference status elements that match at least one reference data corresponding to the address of the second data, based on the second data information of the second data, wherein the second data is the data carried by the second instruction; determining reference sub-data in the reference data that overlaps with the address of the second data, and adjusting the synchronization information in the reference status element corresponding to the reference sub-data to a no-data state; determining a second status element matching the second data in the data status table, and adjusting the synchronization information in the second status element corresponding to the second data to an unsynchronized state.

[0191] It should be noted that similar steps can be performed after receiving synchronized data. The second instruction refers to a subsequent instruction associated with the write operation to the target data, typically issued by another controller (reference controller), involving a data synchronization or update request. The second data is the data carried in the second instruction and may overlap in address with the target data already existing in the system.

[0192] After controller A finishes writing the target data and flushes it to the storage device, it may receive a second instruction from a reference controller (e.g., controller B). This instruction carries information about the second data and is used to synchronize or update the data state. Based on the LUN ID and LBA_align information of the second data, its characteristic value `hash_id` is calculated. The `hash_id` is used to locate the corresponding hash bucket in the data state table, and a reference state element that overlaps with the address of the second data is found. The found reference state elements are analyzed to determine which data completely or partially overlaps with the address of the second data (i.e., reference sub-data). The synchronization information corresponding to the reference sub-data is adjusted to a no-data state, meaning that this part of the data in the reference controller's cache has been flushed or no longer holds the latest version. In the data state table, a second state element matching the second data is found or created. The synchronization information of the second state element is adjusted to an unsynchronized state, indicating that the second data is now in the controller cache but has not yet been flushed to the backend storage device.

[0193] Through the above-described embodiments of this application, the system can effectively manage and update data status, ensure the correct implementation of data redundancy and load balancing strategies, improve data read / write efficiency and consistency, and guarantee data security.

[0194] In an optional implementation, after writing the target data in an unsynchronized state to the storage device, the process includes: upon receiving a third instruction from the reference controller, searching for a third state element corresponding to the address of the third data in the data state table based on the third data information of the third data; and determining the state of the data whose address coincides with the third data based on the third state element.

[0195] It should be noted that the third instruction can be sent by the reference controller to notify the target controller that part or all of the data it holds (i.e., the third data) has become unmodified, meaning that this part of the data has been flushed to the backend storage device and is consistent with the data stored on the backend storage device. The third data is the data that the reference controller notifies the target controller that this part of the data has been flushed.

[0196] In an optional implementation, when the target controller receives a third instruction from the reference controller, it first parses the instruction content to obtain the LUN ID, LBA_align, and length information of the third data. It then uses the LUN ID and LBA_align information to calculate a hash_id to locate the status information corresponding to the third data address in the data status table. Based on the obtained hash_id, it searches for a matching third status element in the hash chain of the data status table. It iterates through the third status elements, checking if they overlap with the address of the third data. For elements that overlap with the third data address, it updates their synchronization information (modified or unmodified status). Changing the modified status to unmodified indicates that this data has been flushed to the backend storage device and is consistent with the data on the storage device. Based on the third data information, it updates the controller indicator bits (bits 60-63) in the third status element, reflecting which controllers still hold copies of this data in their caches.

[0197] Through the embodiments described above in this application, the storage controller can efficiently update its data status table to reflect the latest data status, including whether the data has been synchronized to the backend storage device and which controller caches still hold copies of the data. This helps improve data read / write efficiency, achieve load balancing, and ensure the consistency and stability of the storage system in terms of data redundancy management.

[0198] Example 6: In a multi-controller storage cluster, assume that controller A receives a write request from the host and completes the data writing and synchronization to controller B.

[0199] Controller B receives synchronized data through the data channel with Controller A. It uses the same hash calculation method as Controller A, namely, calculating the hash_id of the data in the data state table using the LUN ID and LBA_align. Based on the hash function set during initialization, it calculates the hash_id. Using the calculated hash_id, it locates the relevant hash bucket in the data state table and attempts to find the record element corresponding to that data address.

[0200] If a matching record element is found in the hash bucket, the modified status bit of that element is updated to indicate that the controller now also stores the latest version of the data. Assuming the initial status bit is 00000000, it will be updated to 00000001 or 00000011, depending on the status bit before controller A's synchronization and whether other controllers also store the latest version of the data. If the matching record element does not exist, a new status element is created and initialized and populated accordingly, as described in the controller A's processing flow. A new status element, `record`, is created, populated with the LUN ID, LBA_align, and the modified status bit is set to true. The controller indicator bit is then updated to the current controller identifier.

[0201] Controllers C and D receive update information from controller A via a message channel, rather than through direct data synchronization. Controllers C and D receive update information from controller A via message passing, including the LUN ID, LBA_align, and related data status information. Using the received LUN ID and LBA_align information, they calculate a hash_id, locate the relevant hash bucket in the data status table, and find the record element corresponding to the data address in the update information. Based on the received update information, they update the data status information and controller indicator bits in the found record element to reflect the latest data status and holder information. If the received information indicates that data has changed from a modified state to an unmodified state, they update the modified and unmodified data record bits in the corresponding record.info field, and simultaneously update the controller identifier bit to correctly reflect the data holding status. After completing the status element update, they verify whether the data status table maintenance operations resulted in the deletion or release of any elements (e.g., when data is marked as no longer present in any cache), and update the status of memory management and the data record resource pool as needed.

[0202] In an optional implementation, after writing the target data in an unsynchronized state to the storage device and adjusting the synchronization information corresponding to the target data from an unsynchronized state to a synchronized state, the process includes: if the amount of data cached in the target controller is greater than a preset data threshold, adjusting the controller indicator bit in the target state element to not indicate the target controller; if the number of controllers indicated by the controller indicator bit is 0, adjusting the value of the target state element to the initial value to obtain a candidate state element.

[0203] It's important to note that the preset data threshold can be a threshold defined in the storage system, used to determine whether the amount of data in the controller cache has reached a level requiring memory reclamation. When the cached data amount of the target controller (i.e., the controller that receives and processes host write I / O requests) reaches the preset threshold, the system needs to reclaim some memory to avoid cache overflow. At this time, for unmodified data that has already been synchronized to the backend disk, its holding controller flag will be removed from the record structure, no longer indicating that the target controller holds the latest copy of that data segment. If a data segment has no copies in any controller cache, i.e., all controller indicator bits in the record structure are 0, it means that all modified data has been successfully flushed to the backend disk, and all controller-related cache copies have been reclaimed. In this case, the record structure will be reset to its initial state, i.e., all status flags will be cleared, making it usable for recording the status of new data segments.

[0204] In storage systems, managing cached data is crucial for optimizing performance and ensuring data consistency. When data is synchronized from a modified state to an unmodified state, and the cached data volume of the target controller reaches a preset threshold, the storage system executes a memory reclamation mechanism. This involves clearing the target controller's holding flag from the record structure and notifying other controllers to update their corresponding data records. When all controllers no longer hold copies of a specific data segment in their caches (i.e., all controller indicator bits are 0), the system resets the record structure to its initial state. This allows the record structure to be reused to store new data segment status information, achieving efficient reuse of storage resources.

[0205] Example 7:

[0206] Figure 7 This is a schematic diagram of an optional data flushing process according to an embodiment of this application; controller A can send data to the storage disk 108 for flushing, and then send the update information to the other three controllers.

[0207] In a redundant storage cluster with four controllers (A, B, C, and D), when controller A receives a write request from a host, the data is marked as modified and stored in controller A's cache. To ensure data persistence and consistency, controller A flushes (writes) the modified data from its cache to the backend storage device, and then updates the data status information to ensure that data records of all relevant controllers in the system are synchronized.

[0208] After receiving a write request from the host, controller A stores the data in its cache. When certain conditions are met (such as cache fullness, periodic flush events triggering, etc.), controller A writes the modified data from the cache to the backend storage device, completing the data flush. Assume that the modified data block in controller A's cache corresponds to LUN ID=0, LBA_align=0 (i.e., the first data block under 4KB granularity management in the storage system), and the data length is 4KB. After the data is flushed to the backend storage device, controller A updates the status information of the corresponding data block in the data status table. The modified data block becomes unmodified after flushing, indicating that the data is consistent between the cache and the disk.

[0209] Using the example data above, controller A updates the data block status information corresponding to LBA_align=0 in the data status table. The status information before the update might have the modified bit set to 0011111 and the unmodified bit set to 11000000, while the data to be flushed could be 00111111. After the flush operation is complete, the status information of the data block corresponding to LBA_align=0 in the data status table is updated. The modified bit is cleared to zero, and the unmodified bit is set to 11111111 (indicating the data block is in an unmodified state).

[0210] After completing the data flushing and updating its local data status table, controller A needs to notify the other controllers in the controller cluster (i.e., B, C, and D) of the update information to maintain the consistency of data status information. Controller A sends the updated data status information to the other controllers through a message mechanism, indicating which data blocks have changed from modified to unmodified, as well as the update status of the controller indicator bits.

[0211] Example 8:

[0212] Figure 8 This is a schematic diagram of an optional memory reclamation process according to an embodiment of this application; as shown... Figure 8 As shown, after memory reclamation, update information can be sent to the remaining controllers.

[0213] In a storage cluster with four controllers (A, B, C, and D), the system employs specific strategies to manage data redundancy, synchronization, and load balancing. When data is marked as unmodified, meaning it is consistent with data on backend storage devices (such as disks), the system initiates a memory reclamation process to remove this data that is no longer needed for caching, in order to optimize memory resources.

[0214] When the memory usage of a controller cache (such as the cache of controller A) reaches a preset threshold (e.g., 80%), a memory reclamation mechanism is triggered. Data transitioning from a modified state to an unmodified state signifies that the data has been persisted on the backend storage device, and the data in the current cache is consistent with the data on the backend device. Controller A's memory management system periodically monitors memory usage, and when it detects that the usage has reached the preset reclamation threshold, it initiates the memory reclamation process. The system scans the data status table, searching for data record elements marked as unmodified. This indicates that the data corresponding to the record is redundant in all controller caches and is consistent with the data stored on the backend. For example, if a data block is marked with 11111111 in the unmodified field of record.info, it means the data is completely consistent with the backend disk, and controller flag bits 60-63 are marked with 1100, indicating that copies of this data block are stored in the caches of controllers A and B. When the data block is reclaimed from the cache of controller A, its corresponding record.info will be updated, clearing the holding information of controller A. For example, the controller flag bits 60-63 will be modified to 0100, indicating that only controller B still has a copy of the data block.

[0215] The memory management system releases the cache memory corresponding to the unmodified data, making it available for storing new data blocks. Simultaneously, via a message channel, controller A sends an update message to other controllers (B, C, D), indicating that this data no longer exists in controller A, so they can also update their own data status tables. Upon receiving the message from controller A, controller B updates its corresponding data status table, i.e., the controller flag in record.info. If the data block is also marked as unmodified in controller B at this time, and controllers C and D also mark the data block as unmodified, then when controller B's cache memory reaches its reclamation threshold, it will also perform a data reclamation operation, changing the controller flag of the data record element to 0000, indicating that the data block no longer exists in any controller cache, and then removing the element from the hash chain and returning it to the resource pool.

[0216] Through the above implementation manners of the present application, the memory recycling process ensures that limited cache memory resources can be recycled, reduces memory occupation, and improves the overall performance and response speed of the storage system. Through the updated data status table and notification mechanism, the consistency of data status among all controllers is ensured. Even after memory recycling, the latest copy of the data can be quickly located, supporting redundancy management and load balancing strategies. It alleviates the pressure on the controller cache, avoids performance bottlenecks caused by excessive cache, and at the same time reduces unnecessary data synchronization operations, saving network resources and communication overhead between controllers.

[0217] In an optional implementation manner, after writing target data with unsynchronized synchronization information to a storage device, it includes: determining a first time when the target data is written to the storage device, and obtaining a second time, where the second time is used to indicate the historical interaction time between the target controller and the storage device; performing a weighted sum of the first time and the second time to obtain a target time; and setting the interaction time of at least one controller to the target time.

[0218] It should be noted that the first time may be the moment when the target data is written to the storage device, that is, the specific time point when the data is flushed from the cache to the disk. The second time represents the historical time of the past interaction between the target controller and the storage device, and is usually used to predict or evaluate the response speed and performance of the storage device. The target time comprehensively considers the calculation results of the first time (the actual time of the current write operation) and the second time (the weighted average of the historical interaction time), and is used to update the response time benchmark between the target controller and the storage device, which helps to more accurately evaluate the performance of the storage device and optimize the data flushing strategy.

[0219] When the target data is flushed from the target controller to the storage device, record the exact time point when the data write operation is completed, that is, the first time. Read the historical interaction time between the target controller and the storage device from the monitoring mechanism, that is, the second time. This time may be an average value, reflecting the response speed of the past interaction between the target controller and the storage device. Use a preset weighting factor a (0 < a < 1) to perform a weighted sum of the first time and the second time to obtain an updated target time. Update the calculated target time to the monitoring mechanism of the target controller as the new benchmark interaction time. This helps the system evaluate the current performance of the storage device and adjust the data flushing strategy according to real-time data.

[0220] Assume a storage system where controller A needs to write target data to a storage device. After a series of data processing and flush operations, the target data is successfully written to the disk. The first time the target data is written is 152310ms, while the historical interaction time between the target controller A and the storage device is 15000ms (i.e., second_time). After the first data write operation is completed, the current time of 152310ms is recorded as the first time. The historical interaction time between the target controller A and the storage device is read, and the current second time is 15000ms. Using a weighting factor a=0.7, the calculated target time is 56193ms. The calculated target time of 56193ms is updated in the monitoring mechanism of the target controller A as the latest baseline for the interaction time with the storage device. This will be used for subsequent performance evaluation and data flush strategy adjustments.

[0221] Similarly, the latest response time for the interaction response time between controllers can be obtained using the same method described above.

[0222] Through the above-described embodiments of this application, the system can dynamically adjust the evaluation benchmark of the interaction time between the target controller and the storage device based on real-time data and historical statistics, thereby optimizing the data flushing strategy and ensuring data redundancy, consistency, and the overall performance of the storage system.

[0223] In an optional implementation, before writing target data in an unsynchronized state to the storage device, the method includes: receiving a fourth instruction sent by a server, wherein the fourth instruction indicates reading fourth data from the storage system; finding a fourth state element matching the fourth data in a data state table based on the fourth data information of the fourth data; and reading the fourth data from at least one reference controller corresponding to the controller indication bit in the fourth state element.

[0224] It should be noted that the fourth instruction is initiated by the server and is used to request the reading of a specific data block (fourth data) from the storage system. The fourth data is the data block the server wishes to read; its status may be unmodified or modified, depending on previous read / write operations and data synchronization status. The fourth data information is carried in the fourth instruction, including the LUN ID, LBA address, and length of the target data, used to locate and read the specific data block. The fourth status element can be an element in the data status table that records the fourth data status and controller indication bits.

[0225] When a server needs to read a data block with a "modified" status—meaning the block hasn't been flushed to a consistent state on the backend storage device—the storage system performs a series of operations to locate and read the block. First, the server sends a fourth command, carrying the LUN ID, LBA, and length information of the fourth data. The storage system (specifically, the controller handling the read request) uses this information to search the data status table for a matching status element. Once a matching element is found, the system refers to the controller indication bit in that element and reads the data from at least one identified reference controller, ensuring the latest version of the data is read while avoiding potential latency from direct access to the backend storage device.

[0226] In an optional implementation, the fourth instruction sent by the server is received, and the LUN ID, LBA, and length information of the fourth data are parsed out. A hash value (hash_id) is calculated using the LUN ID and LBA_align. The corresponding hash bucket in the data status table is located based on the hash_id, and a status element matching the fourth data information is searched. Controller indication bits are read from the matching fourth status elements to determine which controllers still store copies of the fourth data. Based on the controller indication bits, one or more reference controllers are selected as the source for data reading. The cache status and network communication conditions of the reference controllers can be considered during selection to optimize read performance. A read request is sent to the selected reference controller to read the data block matching the fourth data.

[0227] Through the above-described embodiments of this application, the controller, based on the server's read request, effectively and efficiently reads the fourth data of the modified state through the data status table and the reference controller mechanism, demonstrating the advantages of the storage system in data read performance and network resource optimization.

[0228] In an optional implementation, finding a fourth state element matching the fourth data in the data state table based on the fourth data information includes: determining a first feature value corresponding to the fourth data according to the fourth data information; determining at least one candidate data that is the same as the first feature value in the data state table; and determining the candidate data that is the same as the unit number and data block number of the fourth data as the fourth data.

[0229] It should be noted that the first feature value is calculated from the LUN ID and LBA_align, and is used to locate the value of the record associated with a specific data block in the data status table. Candidate data can be records in the data status table that match the first feature value of the fourth data; these records may be potential matches for the fourth data.

[0230] In an optional implementation, a hash_id is calculated using the LUN ID and LBA_align as the first feature value. The hash_id is used to locate the corresponding hash bucket in the data status table, which contains a series of record elements that may be related to the target data. The record elements in the hash bucket are traversed, and the LUN ID, LBA_align, and data segment size (calculated from length and LBA) in record.info are checked to determine the element that perfectly matches the fourth state. Once a matching fourth state element is found, the data status information in that element is updated as needed, such as changing the modified state to the unmodified state, updating controller indicator bits to reflect changes in data distribution, etc. If the data status changes, a message is sent to other controllers, notifying them to update the corresponding element in their own data status tables.

[0231] Through the above-described embodiments of this application, the specific process of searching and updating status elements in the data status table based on the fourth data information ensures that the data status information in the storage system remains consistent across all controllers, thereby supporting efficient data read / write operations and redundancy management.

[0232] In an optional implementation, after a fourth state element matching the fourth data is found in the data state table based on the fourth data information, the process includes: if the fourth state element indicates that the fourth data is in an unsynchronized state, reading the fourth data from at least one reference controller where the fourth data is located; if the fourth state element indicates that the fourth data is in a synchronized state, determining a first interaction time of the reference controller and a second interaction time of the storage device, and determining a reading device based on the first interaction time and the second interaction time; if the fourth data is not found, reading the fourth data from the storage device.

[0233] It should be noted that the first interaction time is the time for reading data from the reference controller, including network transmission time and controller processing time. The second interaction time is the time for directly reading data from the back-end storage device, which may involve disk seek time and read time. The reading device can be optimized based on read time, and can be either the reference controller or the back-end storage device, used to obtain the fourth data.

[0234] Based on the host's read request, the system searches for a matching status element in the data status table using the fourth data information. Then, based on the found status element, it determines where to read the data. The system first attempts to read data from the controller holding the replica to reduce latency when reading from the backend storage device. If the data has been cleared from all controller caches, the system reads directly from the backend storage device.

[0235] In a four-controller storage cluster environment, when controller C processes a read I / O request from a server, it needs to locate the requested data within the cluster, whether it's modified or an unmodified copy. The following is a detailed explanation and example of this process:

[0236] The data is in a modified state:

[0237] Suppose controller C receives a read I / O request targeting data in six sectors starting at address lba=2. Controller C searches its record.info field and finds an entry matching this request, indicating the data status is marked as modified. This means the data is in the cache of one (or more) controllers but has not yet been synchronized to the backend disk, possibly due to recent write operations. Controller C needs to request the data from the controllers holding the modified data in sectors lba=2 to lba=7. In this example, let's assume the data is held by controllers A and B. Based on the response speed monitoring mechanism, controller C will evaluate the response speeds of controllers A and B, selecting the faster one to retrieve the data to reduce read latency. If only two controllers (such as A and B) hold the modified data, controller C will compare their response speeds and send the data request to the faster one.

[0238] The data is in an unmodified state:

[0239] If controller C finds a matching entry for the read I / O request in the `record.info` field, and this data is marked as unmodified, this indicates that the requested data is consistent with the data on the backend disk in the cache of one (or more) controllers and has not been recently modified. Controller C needs to choose a data source: either the controller holding the unmodified data, or directly from the backend disk. This depends on the results of the response time monitoring mechanism and the specific system configuration. Again utilizing the response time monitoring mechanism, controller C will select the fastest data source to retrieve the data based on its response time data compared to controllers A, B, and D, as well as the backend disk.

[0240] No matching record found:

[0241] If no entry matching the read I / O request is found in record.info, this could be because the data has no copy in any controller cache, or the data state is not being recorded correctly for some reason. In this case, controller C will read the data directly from the backend disk, as this is the original storage location of the data. After reading the data, if the current controller's memory space allows, it may cache the data so that future read requests can retrieve it directly from the cache, improving read speed.

[0242] Controller C employs a multi-layered read request handling strategy. It first attempts to retrieve data replicas from other controllers within the cluster to reduce disk accesses and improve read speed. This strategy heavily relies on response time monitoring mechanisms, enabling Controller C to make real-time performance-based decisions that ensure efficient data reading and overall system performance. If a data replica is unavailable or the response time is unsatisfactory, it reverts to a basic strategy of reading data directly from the backend disk. While this may impact read speed, it provides the highest level of guarantee regarding data consistency and integrity.

[0243] Through the above-described embodiments of this application, the system can intelligently select the reading device based on data status and response time monitoring mechanisms when reading data, thereby reducing the latency of reading operations and improving data access efficiency. If the data is not found in any controller cache, the system will read it directly from the back-end storage device, ensuring data integrity. This strategy can significantly optimize the read and write performance of the storage system in practical applications and maintain data redundancy and load balancing.

[0244] In an optional implementation, an intelligent data prefetching and dynamic load balancing mechanism is proposed to further optimize the read and write performance of the storage system, while ensuring high availability and efficiency of the system under different workloads.

[0245] Develop and deploy a machine learning model that predicts which data blocks are likely to be frequently accessed in the near future based on historical data access patterns. Preload the predicted frequently accessed data blocks into the caches of various controllers, even before the data is actually requested. The model periodically learns and updates itself based on new data access patterns to adapt to changes in data access behavior.

[0246] By utilizing a real-time performance monitoring mechanism, information such as processing load, cache utilization, and network communication latency of each controller is continuously collected. An intelligent scheduling algorithm is designed to dynamically adjust the data synchronization direction and data read path based on the aforementioned monitoring information, ensuring load balancing among controllers. When a controller is detected to be overloaded, subsequent data requests are redirected to controllers with lower loads. Simultaneously, based on a prefetching mechanism, the controller will prepare potentially needed data blocks in advance.

[0247] In addition to simple modified and unmodified status markings, intelligent state adjustment based on load and prefetching strategies is introduced. For example, a "warm-up" state is defined, indicating that data blocks have been preloaded into the cache but have not yet been accessed by the host. When a data block is prefetched and stored in the cache, the state is adjusted to "warm-up," and after it is actually accessed by the host, the state is intelligently transitioned to modified or unmodified based on the data state and the synchronization status of the backend storage.

[0248] The system continuously collects data such as host data access patterns, controller load information, and data block state transition history. Using this collected data, machine learning models are periodically trained to improve data prefetching accuracy and dynamic load balancing efficiency.

[0249] In an alternative implementation, in a four-controller storage cluster, the server has recently been frequently accessing a data segment located at LUNID=1, LBA=32KB. This data segment was initially processed by controller A and then synchronized to controller B.

[0250] The machine learning prediction model analyzes historical data access records and predicts that the data segment with LBA=32KB will be frequently accessed in the near future. The model prediction result triggers the prefetching mechanism, which preloads the data segment with LBA=32KB into the caches of controllers C and D, and adjusts the status to "warm-up".

[0251] The monitoring system shows that controller A's load has reached 85%, while controllers C and D's loads are only 60% and 55%, respectively. The intelligent scheduling algorithm detects that controller A is overloaded and decides to redirect subsequent read / write requests to controllers C and D. The server issues a read request for a data segment with LUN ID=1 and LBA=32KB; according to the dynamic load balancing strategy, the request is sent to controller C.

[0252] Upon receiving a read request, controller C changes the data status from "warmed up" to "unmodified" because the data is consistent with that on the backend storage device. Controller C updates its data status table and synchronizes the status information to controllers A and B via a messaging mechanism, informing them of the latest status and owner information of the data block.

[0253] Because the data is pre-loaded into controller C's cache, server read requests receive a rapid response, eliminating the need to wait for data to be transferred from controller A or backend storage to controller C. By redirecting requests to the less loaded controller C, further load on controller A is avoided, ensuring a balanced processing capacity across controllers. The prefetching mechanism and intelligent state transition strategy reduce unnecessary data synchronization and flushing operations, improving cache resource utilization efficiency and lowering overall system energy consumption and operating costs.

[0254] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0255] Embodiments of this application also provide a load balancing device for a storage system. Figure 9 This is a structural block diagram of an optional load balancing device for a storage system according to an embodiment of this application, such as... Figure 9 As shown, the device includes:

[0256] The first lookup module 902 is used to look up reference status elements in the data status table that match the address of the target data based on the target data information of the target data. The target data is the data written by the server to the storage system, and the data status table is used to store the status elements that match the data in the caches of multiple controllers.

[0257] The first adjustment module 904 is used to determine the reference sub-data in the reference data whose address coincides with the target data, and adjust the synchronization information in the reference state element corresponding to the reference sub-data to a no-data state.

[0258] The second adjustment model 906 is used to determine the target state element that matches the target data in the data state table, and adjust the synchronization information corresponding to the target data in the target state element to the unsynchronized state.

[0259] The third adjustment module 908 is used to write the target data, which is in an unsynchronized state, into the storage device, and adjust the synchronization information corresponding to the target data from an unsynchronized state to a synchronized state.

[0260] Optionally, the first search module 902 described above is further configured to: determine the target feature value corresponding to the target data based on the target data information, wherein the target data information includes the target data unit number, the target data address, and the target data length; determine at least one candidate data that is the same as the target feature value in the data status table, wherein the data status table is used to manage at least one data based on the feature value; and determine at least one candidate data corresponding to the target data address as reference data.

[0261] Optionally, the first lookup module 902 described above is further configured to: receive a first instruction sent by the server, wherein the first instruction instructs to write first data to the storage device; calculate a first ratio of the data address of the first data to the data block size, and determine the first ratio as the data block number of the starting data block of the first data; determine the number of data blocks covered by the first data according to the data block number of the starting data block and the data length of the first data; and divide the first data into at least one target data according to the number of data blocks, wherein each target data corresponds to one data block.

[0262] Optionally, the first lookup module 902 described above is further configured to: determine the number of feature values ​​included in the data status table; and determine the remainder between the sum of the target data unit number of the target data and the data block sequence number of the data block to which the target data belongs and the number of feature values ​​as the target feature value.

[0263] Optionally, the second adjustment model 906 described above is further used to: determine the reference controller where the reference data is located and the target controller where the target data is located; when the reference controller and the target controller are the same controller, update the reference state element to obtain the target state element; when the reference controller and the target controller are different controllers, create a new target state element in the data state table.

[0264] Optionally, the second adjustment model 906 described above is further used to: adjust the synchronization information corresponding to the address of the target data in the reference state element to an unsynchronized state when all the reference data overlaps with the address of the target data; adjust the controller indicator bit in the reference state element to indicate the target controller where the target data is located to obtain the target state element, wherein the controller indicator bit is used to indicate the controller where the data corresponding to the state element is located.

[0265] Optionally, the second adjustment model 906 described above is also used to: adjust the synchronization information corresponding to the address of the target data in the reference state to an unsynchronized state when the address of the reference data does not coincide with that of the target data.

[0266] Optionally, the second adjustment model 906 described above is also used to: create a new target state element in the data state table when no reference data corresponding to the address of the target data is found in the data state table.

[0267] Optionally, the second adjustment model 906 described above is further configured to: obtain candidate state elements and set each position of the candidate state elements as an initial value; write the target data unit number of the target data and the data block sequence number of the data block to which the target data belongs into the candidate state elements; adjust the synchronization information corresponding to the address of the target data in the candidate state elements to an unsynchronized state; and adjust the controller indicator bit in the candidate state elements to indicate the target controller where the target data is located, thereby obtaining the target state element.

[0268] Optionally, the third adjustment module 908 is further configured to: adjust the controller indicator bit in the target state element to not indicate the target controller when the amount of data cached in the target controller is greater than a preset data threshold; and adjust the value of the target state element to the initial value when the number of controllers indicated by the controller indicator bit is 0, thereby obtaining a candidate state element.

[0269] Optionally, the third adjustment module 908 described above is further configured to: determine a first time when the target data is written to the storage device, and obtain a second time, wherein the second time is used to indicate the historical interaction time between the target controller and the storage device; perform a weighted summation of the first time and the second time to obtain a target time; and set the interaction time of at least one controller as the target time.

[0270] Optionally, the third adjustment module 908 described above is further configured to: upon receiving a second instruction sent by the reference controller, search in the data status table for reference status elements that match at least one reference data corresponding to the address of the second data, based on the second data information of the second data, wherein the second data is the data carried by the second instruction; determine the reference sub-data in the reference data that overlaps with the address of the second data, and adjust the synchronization information in the reference status element corresponding to the reference sub-data to a no-data state; determine the second status element matching the second data in the data status table, and adjust the synchronization information in the second status element corresponding to the second data to an unsynchronized state.

[0271] Optionally, the third adjustment module 908 described above is further configured to: upon receiving a third instruction sent by the reference controller, search for a third state element corresponding to the address of the third data in the data state table based on the third data information of the third data; and determine the state of the data whose address coincides with the address of the third data based on the third state element.

[0272] Optionally, the third adjustment module 908 described above is further configured to: receive a fourth instruction sent by the server, wherein the fourth instruction indicates that fourth data is read from the storage system; find a fourth state element matching the fourth data in the data state table based on the fourth data information of the fourth data; and read the fourth data from at least one reference controller corresponding to the controller indication bit in the fourth state element.

[0273] Optionally, the third adjustment module 908 described above is further configured to: determine the first feature value corresponding to the fourth data based on the fourth data information; determine at least one candidate data that is the same as the first feature value in the data status table; and determine the candidate data that is the same as the unit number and data block number of the fourth data as the fourth data.

[0274] Optionally, the third adjustment module 908 described above is further configured to: read the fourth data from at least one reference controller where the fourth data is located when the fourth state element indicates that the fourth data is in an unsynchronized state; determine the first interaction time of the reference controller and the second interaction time of the storage device when the fourth state element indicates that the fourth data is in a synchronized state, and determine the reading device based on the first interaction time and the second interaction time; and read the fourth data from the storage device when the fourth data is not found.

[0275] For a description of the features of the load balancing device in the storage system in the corresponding embodiment, please refer to the relevant description of the load balancing method in the storage system in the corresponding embodiment, which will not be repeated here.

[0276] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described embodiments of the load balancing method for a storage system.

[0277] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the load balancing method for storage systems.

[0278] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0279] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described embodiments of the load balancing method for a storage system.

[0280] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described embodiments of the load balancing method for storage systems.

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

[0282] The foregoing has provided a detailed description of a load balancing method and apparatus for a storage system, as well as a storage medium and electronic device. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to aid in understanding the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A load balancing method for a storage system, characterized in that, include: Based on the target data information, the data status table searches for reference status elements that match at least one reference data corresponding to the address of the target data. The target data is the data written by the server to the storage system, and the data status table is used to store the status elements that match the data in the caches of multiple controllers. Identify the reference sub-data in the reference data whose address coincides with the target data, and adjust the synchronization information in the reference state element corresponding to the reference sub-data to a no-data state; In the data status table, determine the target status element that matches the target data, and adjust the synchronization information in the target status element corresponding to the target data to the unsynchronized state. Write the target data whose synchronization information is in an unsynchronized state to the storage device, and adjust the synchronization information corresponding to the target data from an unsynchronized state to a synchronized state; The step of searching the data status table for reference status elements that match at least one reference data corresponding to the address of the target data, based on the target data information, includes: The target feature value corresponding to the target data is determined based on the target data information, wherein the target data information includes the target data unit number, the target data address, and the target data length; In the data status table, at least one candidate data that is the same as the target feature value is determined, wherein the data status table is used to manage at least one data according to the feature value; The at least one candidate data corresponding to the target data address is determined as reference data; The process includes, before searching the data status table for reference status elements that match at least one reference data corresponding to the address of the target data, based on the target data information, including: Receive a first instruction sent by the server, wherein the first instruction instructs to write first data to the storage device; Calculate the first ratio of the data address of the first data to the data block size, and determine the first ratio as the data block number of the starting data block of the first data; The number of data blocks covered by the first data is determined based on the data block sequence number of the starting data block and the data length of the first data. The first data is divided into at least one target data according to the number of data blocks, wherein each target data corresponds to one data block; Wherein, determining the target feature value corresponding to the target data based on the target data information includes: Determine the number of feature values ​​included in the data status table; The remainder between the sum of the target data unit number of the target data and the data block number of the data block to which the target data belongs, and the number of the feature values, is determined as the target feature value.

2. The method according to claim 1, characterized in that, The step of determining the target state element that matches the target data in the data state table includes: Determine the reference controller where the reference data is located and the target controller where the target data is located; If the reference controller and the target controller are the same controller, the reference state element is updated to obtain the target state element; If the reference controller and the target controller are different controllers, a new target state element is created in the data state table.

3. The method according to claim 2, characterized in that, The step of updating the reference state element to obtain the target state element includes: If all the reference data overlaps with the address of the target data, the synchronization information in the reference state element corresponding to the address of the target data is adjusted to an unsynchronized state; The controller indicator bit in the reference state element is adjusted to indicate the target controller where the target data is located to obtain the target state element, wherein the controller indicator bit is used to indicate the controller where the data corresponding to the state element is located.

4. The method according to claim 2, characterized in that, The step of updating the reference state element to obtain the target state element includes: If the address of the reference data does not overlap with that of the target data, the synchronization information in the reference state corresponding to the address of the target data is adjusted to an unsynchronized state.

5. The method according to claim 2, characterized in that, Before determining the reference sub-data in the reference data that coincides with the target data address, the process includes: If no reference data corresponding to the address of the target data is found in the data status table, a new target status element is created in the data status table.

6. The method according to any one of claims 2 to 5, characterized in that, Creating the target status element in the data status table includes: Obtain candidate state elements and set each position of the candidate state elements as an initial value; Write the target data unit number of the target data and the data block number of the data block to which the target data belongs into the candidate state element; The synchronization information corresponding to the address of the target data in the candidate state element is adjusted to an unsynchronized state, and the controller indicator bit in the candidate state element is adjusted to indicate the target controller where the target data is located, thus obtaining the target state element.

7. The method according to claim 6, characterized in that, After writing the target data, which is in an unsynchronized state, to the storage device, and adjusting the synchronization information corresponding to the target data from an unsynchronized state to a synchronized state, the process includes: If the amount of data cached in the target controller is greater than a preset data threshold, the controller indicator bit in the target status element will be adjusted to not indicate the target controller. When the number of controllers indicated by the controller indicator bit is 0, the value of the target state element is adjusted to the initial value to obtain the candidate state element.

8. The method according to claim 7, characterized in that, After writing the target data, whose synchronization information is in an unsynchronized state, to the storage device, the process includes: Determine a first time when the target data is written to the storage device, and obtain a second time, wherein the second time is used to indicate the historical interaction time between the target controller and the storage device; The first and second times are weighted and summed to obtain the target time. Set the interaction time of at least one controller to the target time.

9. The method according to claim 1, characterized in that, After writing the target data, whose synchronization information is in an unsynchronized state, to the storage device, the process includes: Upon receiving a second instruction from the reference controller, the reference status element that matches at least one reference data corresponding to the address of the second data is searched in the data status table based on the second data information of the second data, wherein the second data is the data carried by the second instruction; Determine the reference sub-data whose address coincides with the address of the second data in the reference data, and adjust the synchronization information corresponding to the reference sub-data in the reference state element to a no-data state; In the data status table, determine the second status element that matches the second data, and adjust the synchronization information in the second status element corresponding to the second data to the unsynchronized state.

10. The method according to claim 9, characterized in that, After writing the target data, whose synchronization information is in an unsynchronized state, to the storage device, the process includes: Upon receiving a third instruction from the reference controller, the third state element corresponding to the address of the third data is searched in the data state table based on the third data information of the third data. The state of the data whose address overlaps with the third data is determined based on the third state element.

11. The method according to claim 1, characterized in that, Before writing the target data, whose synchronization information is in an unsynchronized state, to the storage device, the process includes: Receive a fourth instruction sent by the server, wherein the fourth instruction instructs to read fourth data from the storage system; Based on the fourth data information, a fourth state element matching the fourth data is found in the data state table; The fourth data is read from at least one reference controller corresponding to the controller indication bit in the fourth state element.

12. The method according to claim 11, characterized in that, The process of finding a matching fourth state element in the data state table based on the fourth data information includes: Determine the first feature value corresponding to the fourth data based on the fourth data information; In the data status table, at least one candidate data that is the same as the first feature value is determined; The candidate data that has the same unit number and data block number as the fourth data is determined as the fourth data.

13. The method according to claim 11, characterized in that, After the fourth data information based on the fourth data is used to find a fourth state element that matches the fourth data in the data state table, the process includes: If the fourth state element indicates that the fourth data is in an unsynchronized state, the fourth data is read from at least one reference controller where the fourth data is located; When the fourth state element indicates that the fourth data is in a synchronized state, the first interaction time of the reference controller and the second interaction time of the storage device are determined, and the reading device is determined based on the first interaction time and the second interaction time. If the fourth data is not found, the fourth data is read from the storage device.

14. A load balancing device for a storage system, characterized in that, include: The first lookup module is used to look up reference status elements in the data status table that match at least one reference data corresponding to the address of the target data based on the target data information of the target data. The target data is the data written by the server to the storage system, and the data status table is used to store the status elements that match the data in the caches of multiple controllers. The first adjustment module is used to determine the reference sub-data in the reference data whose address coincides with the target data, and adjust the synchronization information in the reference state element corresponding to the reference sub-data to a no-data state. The second adjustment model is used to determine the target state element that matches the target data in the data state table, and adjust the synchronization information in the target state element that corresponds to the target data to the unsynchronized state. The third adjustment module is used to write the target data whose synchronization information is in an unsynchronized state into the storage device, and to adjust the synchronization information corresponding to the target data from an unsynchronized state to a synchronized state. The step of searching the data status table for reference status elements that match at least one reference data corresponding to the address of the target data, based on the target data information, includes: The target feature value corresponding to the target data is determined based on the target data information, wherein the target data information includes the target data unit number, the target data address, and the target data length; In the data status table, at least one candidate data that is the same as the target feature value is determined, wherein the data status table is used to manage at least one data according to the feature value; The at least one candidate data corresponding to the target data address is determined as reference data; The process includes, before searching the data status table for reference status elements that match at least one reference data corresponding to the address of the target data, based on the target data information, including: Receive a first instruction sent by the server, wherein the first instruction instructs to write first data to the storage device; Calculate the first ratio of the data address of the first data to the data block size, and determine the first ratio as the data block number of the starting data block of the first data; The number of data blocks covered by the first data is determined based on the data block sequence number of the starting data block and the data length of the first data. The first data is divided into at least one target data according to the number of data blocks, wherein each target data corresponds to one data block; Wherein, determining the target feature value corresponding to the target data based on the target data information includes: Determine the number of feature values ​​included in the data status table; The remainder between the sum of the target data unit number of the target data and the data block number of the data block to which the target data belongs, and the number of the feature values, is determined as the target feature value.

15. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the load balancing method for the storage system as described in any one of claims 1 to 13 when executing the computer program.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the load balancing method of the storage system as described in any one of claims 1 to 13.

17. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the load balancing method for the storage system as described in any one of claims 1 to 13.

Images