Dummy data writing method and apparatus, storage system, and computer-readable storage medium

Abstract

The present application relates to the technical field of computers, and discloses a dummy data writing method and apparatus, a storage system, and a computer-readable storage medium. In the present method, for a partial stripe, a service processing node sends a target write request to a storage node, so as to instruct the storage node to write dummy data to a target sector, which corresponds to the partial stripe and to which no data has been written, in the storage disk; and upon receiving the target write request, the storage node generates dummy data for the target sector, and writes the dummy data to the target sector. Thus, the service processing node does not need to transmit the dummy data to the storage node via a network between the service processing node and the storage node, so that the bandwidth of the network can be prevented from being occupied by the dummy data, and the bandwidth overhead of the network can be reduced.

Description

Pseudo-data writing method, apparatus, storage system and computer-readable storage medium

[0001] This application claims priority to Chinese Patent Application No. 202510249651.2, filed on February 28, 2025, entitled "Pseudo-data writing method, apparatus, storage system and computer-readable storage medium", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computer technology, and in particular to a pseudo-data writing method, apparatus, storage system, and computer-readable storage medium. Background Technology

[0003] Current storage systems consist of multiple storage disks (such as hard disks or disks). The physical storage space of these disks can be logically divided into several logical blocks. Logical blocks are taken from different disks to form logical block groups. The logical blocks within a logical block group are erasure-coded (EC) with each other. The logical blocks in a logical block group are horizontally divided into multiple stripes. Each stripe contains multiple stripe units. The physical storage space corresponding to each stripe unit is provided by multiple sectors in the storage medium. That is, one stripe unit corresponds to multiple sectors in the storage medium, and one stripe corresponds to multiple sectors in multiple storage media.

[0004] In a storage system, business processing nodes write business data to the storage medium in stripes. For example, a batch of business data is first written to stripe 1, and after stripe 1 is full, another batch of business data is written to stripe 2. However, when writing a batch of business data to a stripe, if the amount of data is small, there may be sectors in the corresponding sectors that have not been written with business data (called target sectors), resulting in the stripe not being fully written. To fill the stripe, the business processing node can write dummy data to these target sectors. Dummy data refers to non-real business data used to fill the unfilled target sectors in the stripe, thus completing the business data in the unfilled stripe.

[0005] Currently, the pseudo-data writing process can be as follows: the business processing node prepares pseudo-data for the target sector corresponding to the incomplete segment, and sends a write request to the storage node in the storage system to instruct data to be written to the target sector; the storage node receives the write request and requests the data to be written to the target sector from the business processing node; the business processing node sends the prepared pseudo-data to the storage node according to the request of the storage node; the storage node uses the received pseudo-data as the data to be written and writes the pseudo-data to the target sector.

[0006] However, during the aforementioned pseudo-data writing process, when sending pseudo-data to the storage node, the business processing node transmits the pseudo-data through the network between the business processing node and the storage node. The pseudo-data consumes network bandwidth, thereby increasing network bandwidth overhead. Summary of the Invention

[0007] This application provides a method, apparatus, storage system, and computer-readable storage medium for writing pseudo-data, which can reduce the bandwidth overhead of the network between the business processing node and the storage node when writing pseudo-data to the storage disk in the storage system. The technical solution is as follows:

[0008] Firstly, a pseudo-data writing method is provided. This method is applied to a storage system, which also includes a business processing node, a storage node, and multiple storage disks. The business processing node can be used to manage each storage disk in the storage system, and the storage node can be used to manage at least one storage disk in the storage system. The business processing node is the upper-level management device of the storage node, and the storage disk can be a disk or a hard disk.

[0009] This method can be applied to storage nodes in a storage system. The method includes: receiving a target write request from a business processing node in the storage system; generating pseudo data after receiving the target write request; and writing the pseudo data to a target sector, wherein the target write request indicates that pseudo data be written to a target sector, and the target sector is a sector in the storage disk that corresponds to an incomplete row and has not yet been written with data.

[0010] In this method, for incomplete segments, the business processing node sends a target write request to the storage node, instructing the storage node to write pseudo-data to the target sector corresponding to the incomplete segment that has not yet been written to. Upon receiving the target write request, the storage node generates pseudo-data for the target sector and writes the pseudo-data to the target sector. This eliminates the need for the business processing node to transmit pseudo-data to the storage node via the network, thus avoiding the pseudo-data consuming network bandwidth and reducing network bandwidth overhead.

[0011] In one possible implementation, the target write request is defined by the storage protocol supported by the storage node. This storage protocol includes non-volatile memory standard protocols, block storage protocols, object storage protocols, file storage protocols, network-attached storage protocols, storage area network protocols, etc., but the type of storage protocol is not limited to these.

[0012] Based on the above possible implementation methods, the target write request and its data format can be defined by extending the storage protocols supported by the storage node, so that the storage node can identify the target write request from the received commands.

[0013] In one possible implementation, generating the pseudo data includes reading a backup of the pseudo data from memory. Furthermore, writing the pseudo data to the target sector includes writing a backup of the pseudo data to the target sector.

[0014] Based on the above possible implementation methods, the backup of reading pseudo data realizes the generation of pseudo data without the storage node having to generate pseudo data according to the target data format. This enables the storage node to quickly obtain pseudo data, improves the efficiency of pseudo data acquisition, and reduces the consumption of storage node computing resources.

[0015] In one possible implementation, before receiving the target write request from the business processing node in the storage system, the method further includes: receiving a backup of the pseudo-data sent by the business processing node and storing the backup in memory. This allows the storage node to quickly retrieve the backup of the pseudo-data from memory when processing the target write request, thereby improving the efficiency of pseudo-data retrieval.

[0016] In one possible implementation, writing pseudo data to the target sector includes writing pseudo data and metadata of the pseudo data to the target sector, wherein the metadata can verify the reliability of the pseudo data.

[0017] Based on the above possible implementation methods, when reading data from the target sector later, the business processing node can perform reliability verification on the pseudo data based on the metadata of the pseudo data. This reduces network bandwidth overhead while also verifying the reliability of the pseudo data, thus improving the reliability of the storage system data.

[0018] In one possible implementation, before writing the pseudo data and its metadata to the target sector, the method further includes: sending a metadata read request to the business processing node; and receiving the metadata returned by the business processing node, wherein the metadata read request indicates reading the metadata of the pseudo data.

[0019] Based on the above possible implementation methods, the storage node can obtain the metadata of the pseudo data so that the pseudo data and its metadata can be written together to the target sector. In this way, when reading data from the target sector later, the business processing node can perform reliability verification on the pseudo data based on its metadata. This reduces network bandwidth overhead while also verifying the reliability of the pseudo data, thus improving the reliability of the storage system data.

[0020] In one possible implementation, before writing pseudo-data and its metadata to the target sector, the method further includes generating metadata based on key information from the metadata in the target write request.

[0021] Based on the above possible implementation methods, the storage node can generate the metadata of the pseudo data itself, without the storage node needing to read the metadata of the pseudo data from the business processing node. This avoids the metadata of the pseudo data occupying the network bandwidth between the business processing node and the storage node, further reducing network bandwidth overhead.

[0022] In one possible implementation, the key information includes the identifier of the stripe to which the target sector belongs and the identifier of the logical block group in which the stripe is located.

[0023] Based on the above possible implementation methods, when reading data from the target sector, the business processing node can verify whether the read pseudo data belongs to the expected stripe and logical block group based on the stripe identifier and logical block group identifier in the key information, thereby enabling the reliability verification of the pseudo data.

[0024] In one possible implementation, the metadata generated based on the key information of the metadata in the target write request includes: generating integrity verification data for the pseudo data; generating system metadata for the pseudo data; and concatenating the integrity verification data and the system metadata to obtain the metadata, wherein the integrity verification data is used to verify the integrity of the pseudo data, and the system metadata includes the key information of the metadata.

[0025] Based on the above possible implementation methods, storage nodes can generate metadata for pseudo data. Since the generated metadata includes integrity verification data and system metadata, subsequent business processing nodes can verify the pseudo data they read based on this metadata, thereby improving the reliability of the storage system.

[0026] In one possible implementation, the above-mentioned concatenation of integrity verification data and system metadata yields metadata that includes: concatenating integrity verification data and system metadata based on target location information, where the target location information indicates the position of the system metadata within the metadata. This ensures that the arrangement of integrity verification data and system metadata in the metadata is identical to the arrangement of the data integrity field and system metadata field in the sector's metadata area. This allows for subsequent writing of pseudo-data metadata to the target sector's metadata area, ensuring that the integrity verification data and system metadata are written to the data integrity field and system metadata field of the metadata area, respectively.

[0027] In one possible implementation, before receiving the target write request from the business processing node in the storage system, the method further includes receiving target location information sent by the business processing node. This allows the storage node to subsequently generate metadata for the pseudo-data based on the target location information.

[0028] Secondly, a pseudo-data writing method is provided. This method is applied to the business processing nodes in a storage system, which can be the storage system described in the first aspect above. The method includes: determining a target sector from the storage disk in the storage system for any incomplete rows; sending a target write request to a storage node in the storage system, the target write request instructing pseudo-data to be written to the target sector. The target sector is the sector in the storage disk corresponding to the incomplete row that has not yet been written to, and the pseudo-data is generated by the storage node.

[0029] In this method, when writing pseudo data to the target sector corresponding to the incomplete stripe in the storage disk and to which no data has been written, the pseudo data is generated by the storage node. The business processing node does not need to transmit the pseudo data to the storage node through the network between the business processing node and the storage node, which can avoid the pseudo data occupying the network bandwidth and reduce the network bandwidth overhead.

[0030] In one possible implementation, the target write request is defined by the storage protocol supported by the storage node.

[0031] In one possible implementation, before determining the target sector from the storage disk in the storage system for incomplete segments in the storage system, the method further includes: sending a backup of pseudo-data to the storage node.

[0032] In one possible implementation, after sending a target write request to a storage node in the storage system, the method further includes: receiving a metadata read request from the storage node and sending metadata to the storage node, wherein the metadata read request indicates reading the metadata of the pseudo data, and the metadata is capable of verifying the reliability of the pseudo data.

[0033] In one possible implementation, the target write request includes key information about the metadata of the pseudo data, which can verify the reliability of the pseudo data.

[0034] In one possible implementation, the key information includes the identifier of the stripe to which the target sector belongs and the identifier of the logical block group in which the stripe is located.

[0035] In one possible implementation, before determining the target sector from the storage disk in the storage system for an incomplete stripe in the storage system, the method further includes: sending target location information to the storage node, the target location information indicating the location of the system metadata in the metadata.

[0036] Each possible implementation method in the second aspect has a corresponding possible implementation method in the first aspect. The beneficial effects achieved by each possible implementation method in the second aspect can be referred to the corresponding possible implementation methods in the first aspect, and will not be repeated here.

[0037] Thirdly, a pseudo-data writing apparatus is provided for performing the method provided in the first aspect or any alternative manner of the first aspect.

[0038] Fourthly, a pseudo-data writing apparatus is provided for performing the method provided in the second aspect or any alternative manner of the second aspect.

[0039] Fifthly, a storage system is provided, comprising a service processing node, a storage node, and a plurality of storage disks, wherein the service processing node is used to execute the method provided in the second aspect or any optional mode of the second aspect, and the storage node is used to execute the method provided in the first aspect or any optional mode of the first aspect.

[0040] A sixth aspect provides a storage control device including a processor for executing program code that causes the storage control device to perform a method as provided in the first aspect above or any alternative to the first aspect above.

[0041] In a seventh aspect, a host is provided, the host including a processor for executing program code, causing the host to perform a method as provided in the second aspect above or any alternative to the second aspect above.

[0042] Eighthly, a computer-readable storage medium is provided, the storage medium storing at least one piece of program code, the program code being read by a processor to cause a storage control device to perform a method as provided in the first aspect above or any alternative method of the first aspect above.

[0043] A ninth aspect provides a computer-readable storage medium storing at least one piece of program code that is read by a processor to cause a host to perform a method as provided in the second aspect above or any alternative method of the second aspect above.

[0044] In a tenth aspect, a computer program product or computer program is provided, the computer program product or computer program including program code stored in a computer-readable storage medium, a processor reading the program code from the computer-readable storage medium, the processor executing the program code, causing a storage control device to perform the method provided in the first aspect or various optional implementations of the first aspect.

[0045] Eleventhly, a computer program product or computer program is provided, the computer program product or computer program including program code stored in a computer-readable storage medium, a processor reading the program code from the computer-readable storage medium, the processor executing the program code, causing a host to perform the method provided in the second aspect or various optional implementations of the second aspect.

[0046] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0047] Figure 1 is a schematic diagram of a storage system provided in an embodiment of this application;

[0048] Figure 2 is a schematic diagram of another storage system provided in an embodiment of this application;

[0049] Figure 3 is a schematic diagram of a logic block group provided in an embodiment of this application;

[0050] Figure 4 is a schematic diagram of the structure of a sector provided in an embodiment of this application;

[0051] Figure 5 is a flowchart of writing pseudo data to an incomplete stripe according to an embodiment of this application;

[0052] Figure 6 is a flowchart of a pseudo-data writing method provided in an embodiment of this application;

[0053] Figure 7 is a flowchart of another pseudo-data writing method provided in an embodiment of this application;

[0054] Figure 8 is a flowchart of writing pseudo data in a scenario where a business processing node provides metadata, according to an embodiment of this application.

[0055] Figure 9 is a flowchart of another pseudo-data writing method provided in an embodiment of this application;

[0056] Figure 10 is a flowchart of writing pseudo data in a scenario where a storage node generates metadata, according to an embodiment of this application.

[0057] Figure 11 is a schematic diagram of a pseudo-data writing device provided in an embodiment of this application;

[0058] Figure 12 is a schematic diagram of another pseudo-data writing device provided in an embodiment of this application;

[0059] Figure 13 is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0060] To facilitate understanding of the specific embodiments of this application, the specific embodiments are described below in conjunction with the accompanying drawings.

[0061] Figure 1 is a schematic diagram of a storage system provided in an embodiment of this application. Referring to Figure 1, the storage system includes a service processing node 101, a storage node 102, and multiple storage disks 103. The service processing node 101 and the storage node 102 are connected through a first network 104. The service processing node 101 and the storage node 102 communicate based on the transmission protocol supported by the first network 104. The transmission protocol includes the peripheral component interconnect express (PCIE) protocol, the remote direct memory access over Converged Ethernet (ROCE) protocol, the unified bus (UB) protocol, the compute express link (CXL) protocol, the cache coherent interconnect for accelerators (CCIX) protocol, etc. Here, the type of transmission protocol is not limited in this embodiment of the application.

[0062] The service processing node 101 can be a host, which can be a physical server, such as a single physical server or a node in a server cluster. Alternatively, the host can be other storage devices with storage capabilities, such as storage array devices or storage servers. Alternatively, the host can be a terminal device, such as a mobile phone, personal computer (PC), desktop computer, laptop, tablet computer, wearable device, etc. This embodiment does not limit the type of host device. In some embodiments, the service processing node 101 can also be a module within the host; specifically, it can be a hardware module, a software module, or a combination of hardware and software.

[0063] Storage disk 103 is a storage device used to store data, such as a disk or hard disk. The hard disk can be a hard disk drive (HDD), a solid state disk (SSD), or a hybrid hard drive (HHD), etc. Here, the type of storage disk 103 is not limited in this embodiment of the application.

[0064] Storage node 102 is used to manage multiple storage disks 103. Multiple storage disks 103 can be deployed in storage node 102. In this case, storage node 102 can be a storage device, such as a storage array device or a storage server.

[0065] Alternatively, multiple storage disks 103 can be deployed outside of storage node 102. For example, storage node 102 can be connected to at least one storage device via a second network. The storage device includes multiple storage disks 103, and can be a storage array device or a storage server. The second network and the first network 104 can be the same network or different networks. The storage node 102 communicates with the storage device based on the transmission protocol supported by the second network. This transmission protocol includes PCIe, ROCE, UB, CXL, CCIX, etc. Here, this embodiment does not limit the type of transmission protocol. In this case, storage node 102 can be a computer device, which is a physical server, such as a single physical server or a node in a server cluster.

[0066] Alternatively, storage node 102 is the controller in storage disk 103, used to manage the storage disk 103 it resides in.

[0067] Figure 1 illustrates a storage system with one storage node 102 as an example. In other embodiments, the storage system includes multiple storage nodes 102, and each storage node 102 is responsible for managing multiple storage disks 103. Here, the embodiments of this application do not limit the number of storage nodes 102 in the storage system or the number of storage disks 103 managed by each storage node 102.

[0068] Business processing node 101 is a node in the storage system used for processing business operations. Business processing node 101 manages the storage disk 103 in the storage system and also provides data read / write services to users. Users can write business data to and read business data from the storage disk 103 through business processing node 101. For example, when writing business data, business processing node 101 can write business data to the storage disk 103 through storage node 102; when reading business data, business processing node 101 can also read business data from the storage disk 103 through storage node 102. The business processing node 101 runs the storage system's business software, and it implements the above-mentioned functions by running this software.

[0069] This application involves striping. Next, we will introduce striping in conjunction with the storage system shown in Figure 2.

[0070] The storage system shown in Figure 2 is applicable to both distributed and centralized storage systems. This system comprises several storage disks 103. The actual addresses of the storage space provided by the storage disks 103 are not directly exposed to the service processing nodes 101. Each storage disk 103 is divided into several physical chunks 104. These physical chunks 104 are mapped to logical chunks to form a storage pool 105. The storage pool 105 provides storage space, which actually originates from the storage disks 103 contained in the system. Of course, not all storage disks 103 need to provide space to the storage pool 105. In practical applications, the storage system may contain one or more storage pools 105, and a storage pool 105 may include some or all of the storage disks 103. Multiple logical chunks from different storage disks 103 or different storage nodes 102 form a logical block group, which is the smallest allocation unit of the storage pool 105. When a storage service layer (such as business processing node 101) requests storage space from the storage pool 105, the storage pool 105 can provide one or more logical block groups to the storage service layer. The storage service layer further virtualizes the storage space provided by the logical block groups into logical units (LUs) 106 for use by the business processing node 101. Each logical unit has a unique logical unit number (LUN). Since the business processing node 101 can directly perceive the logical unit number, those skilled in the art typically use LUN to refer to the logical unit. Each LUN has a LUN identifier (ID), which is used to identify the LUN. The specific location of data within a LUN can be determined by the starting address and the length of the data. The starting address is typically referred to as the logical block address (LBA). It is understood that the LUN ID, LBA, and length identify a specific address range. Data access requests generated by the application server of business processing node 101 typically include the LUN ID, LBA, and length in the request.

[0071] The number of blocks in a logical block group depends on the mechanism (also known as redundancy mode) used to ensure data reliability. Typically, to guarantee data reliability, storage systems employ either a multi-replica mechanism or an EC (Extreme Error Correction) mechanism to store data. A multi-replica mechanism means storing at least two identical copies of the data; if one copy is lost, it can be recovered using the other copies. If a multi-replica mechanism is used, a logical block group contains at least two blocks, each located on a different storage disk 103 or a different storage node 102. An EC mechanism involves dividing the data to be stored into at least two data fragments and calculating a check fragment according to a specific algorithm. If one data fragment is lost, the data can be recovered using the other data fragment and the check fragment. If an EC mechanism is used, a logical block group contains at least three blocks, each located on a different storage disk 103 or a different storage node 102.

[0072] Taking the EC (Extended Array of Independent Disks) verification mechanism as an example, multiple logical blocks from different storage disks 103 or located in different storage nodes 102 are divided into data groups and parity groups according to a set (Redundant Array of Independent Disks, RAID) type. Each data group includes at least two logical blocks for storing data fragments, and each parity group includes at least one block for storing parity fragments of the data fragments. When data accumulates to a certain size in memory, it can be divided into multiple data fragments according to the set RAID type, and parity fragments can be calculated. These data fragments and parity fragments are then sent to the multiple different storage disks or located in different storage nodes to be stored in the logical block group. After storage, these data fragments and parity fragments constitute a stripe. A logical block group can contain one or more stripes. The data fragments and parity fragments contained in a stripe can both be called stripe units. In this embodiment, an example of a stripe unit size of 8KB is used, but it is not limited to 8 kilobytes (KB). For example, suppose a block is taken from each of six solid-state storage disks to form a logical block set (a subset of the storage pool). This logical block set is then grouped based on a set RAID type (e.g., RAID 6). Chunk 0, Chunk 1, Chunk 2, and Chunk 3 are data block groups, and Chunk 4 and Chunk 5 are parity block groups. When the data stored in memory reaches 8KB * 4 = 32KB, the data is divided into four data shards (data shard 0, data shard 1, data shard 2, and data shard 3), each 8KB in size. Two parity shards (P0 and Q0) are then calculated, each also 8KB in size. The service processing node 101 sends these data shards and parity shards to the storage disks to store the data in the logical block groups. Understandably, according to the redundancy protection mechanism of RAID 6, if any two data shards or parity shards fail, the failed unit can be reconstructed from the remaining data shards or parity shards. Furthermore, before sending data to the storage disk 103, the service processing node 101 needs to determine whether there is an already allocated logical block group. If so, and the logical block group still has enough space to accommodate the data, then the service processing node 101 can instruct the storage disk 103 to write the data into the already allocated logical block group. Specifically, the service processing node 101 obtains an unused logical address from the logical address range of the already allocated logical block group and sends the logical address to the storage disk 103 along with a write data request. Taking a solid-state drive (SSD) as an example, after the SSD saves the data, a mapping relationship between the logical address and the actual address where the data is saved is created in the flash translation layer.

[0073] In summary, a logical block group comprises multiple stripes, each stripe comprises multiple logical blocks, and each logical block corresponds to a physical block on storage disk 103. A physical block consists of multiple sectors within the same storage disk 103. Therefore, a logical block corresponds to multiple sectors within a physical block on a storage disk 103, and a stripe corresponds to multiple sectors on multiple storage disks 103 within a logical block group.

[0074] Taking Figure 3 as an example, assuming storage disk 103 is a disk, each of disks 0 to 9 includes 2 physical blocks, and each physical block includes N sectors. The logical blocks mapped from the physical blocks of disks 0 to 9 form a logical block group. In this logical block group, a stripe includes multiple logical blocks, and one logical block corresponds to N sectors in one storage disk 103. The sectors corresponding to different logical blocks in the same stripe are in the same position in their respective storage disks 103. For example, the logical blocks in the same stripe correspond to sectors 0 to N-1 in different storage disks 103, or the logical blocks in the same stripe correspond to sectors N to 2N in different storage disks 103. N is an integer greater than 1. Figure 3 illustrates an example of mapping 10 physical blocks from storage disks 103 to one logical block group. In other embodiments, fewer than 10 or more physical blocks from storage disks 103 can also be mapped to one logical block group.

[0075] A logical block group can be a RAID or EC group. Within a RAID or EC group, the logical block used to write data shards can be called a data block, and the logical block used to write parity shards can be called a parity block.

[0076] The business processing node 101 maintains the mapping relationship between each logical block group, each stripe, each logical block in the stripe, each physical block, and each sector in the physical block in the storage system, so that the business processing node can manage each storage disk 103 in the storage system based on the mapping relationship and read data from the stripe, etc.

[0077] To improve data reliability, as shown in Figure 4, the sector can be divided into a data area and a metadata area. The data area has a storage capacity of 4096 bytes (B), or 4KB, and the metadata area has a storage capacity of 46B. In some embodiments, the storage capacity of the data area may be less than or greater than 4096B, and the storage capacity of the metadata area may also be less than or greater than 46B. The storage capacity of the data area and the metadata area can be defined by the storage protocol supported by the storage system. Here, the storage capacity of the data area and the metadata area in this application embodiment is not limited.

[0078] A data area is used to store data, the length of which is the same as the storage capacity of the data area. Writing data of this length to the data area will fill it up. This data can be business data within a data block or verification data within a verification block. For example, in a striping structure, the data area of ​​the sector corresponding to a data block stores business data, while the data area of ​​the sector corresponding to a verification block stores verification data.

[0079] The metadata area stores the metadata of the data in the data area. This metadata describes the data and can be used to verify its reliability. The metadata includes integrity verification data and system metadata. Integrity verification data verifies the integrity of the data. System metadata verifies the reliability and / or availability of the data. System metadata includes attribute information for at least one attribute of the data, such as data type, data position within the stripe, and data position from the user's perspective. This attribute can be flexibly defined by the storage system provider; however, this embodiment does not limit the specific attribute. The length of the metadata is the same as the storage capacity of the metadata area. Writing metadata of this length to the metadata area means the metadata area is full. A sector is full when both its data area and metadata area are full.

[0080] In some embodiments, the metadata area includes a data integrity field (DIF) and a system metadata area. The DIF stores integrity verification data for the data (i.e., the data in the data area), and the system metadata area stores system metadata for that data. The storage capacities of the DIF and the system metadata area are 8 bytes and 56 bytes, respectively. In some embodiments, the storage capacity of the DIF may be less than or greater than 8 bytes, and the storage capacity of the system metadata area may be less than or greater than 56 bytes. The storage capacities of the DIF and the system metadata area can be defined by the storage protocol supported by the storage system. Here, the storage capacities of the DIF and the system metadata area are not limited in the embodiments of this application. It should be understood that the storage capacity of the DIF is the same as the length of the integrity verification data, and the storage capacity of the system metadata area is the same as the length of the system metadata.

[0081] When writing data to a sector, the business processing node 101 provides the data to be written and the metadata of the data to the storage node 102, so that the storage node 102 can write the data to the data area of ​​the sector and write the metadata of the data to the metadata area of ​​the sector, thereby realizing the writing of data to the sector and the metadata of the data.

[0082] For a batch of business data to be written to the storage system, business processing node 101 allocates strips for this batch of business data. Storage node 102 then writes the business data from this batch of data into the logical blocks of the strips in the storage system. For example, the batch of business data can be divided into multiple data shards, and multiple verification shards can be generated for this batch of business data. Each data shard includes a portion of the business data in this batch of business data. The number of data shards is less than or equal to the number of data blocks in the strips, and the data size of each data shard is less than or equal to the storage capacity of the data blocks. For example, the data size of the last data shard in multiple data shards is less than or equal to the storage capacity of the data blocks, while the data size of the other data shards is equal to the storage capacity of the data blocks. The number of verification shards is the same as the number of verification blocks in the strips, and the data size of the verification shards is the same as the storage capacity of the verification blocks.

[0083] The business processing node 101 writes a data fragment to each of the multiple data blocks in the stripe through the storage node 102, and writes a verification fragment to each verification block in the stripe.

[0084] When writing a data fragment to a data block within a stripe, the business processing node 101 divides the data fragment into multiple business data pieces, generating metadata for each piece. Each business data piece corresponds to a sector within the data block, and the length of each business data piece is the same as the storage capacity of the data area within the sector. The business processing node 101, through the data node 102, writes each piece of business data and its metadata to the corresponding sector. For example, the business processing node concatenates a piece of business data and its metadata to obtain a sector data piece (i.e., data to be written to a sector). It then concatenates multiple sector data pieces to obtain a target data piece. The business processing node 101 sends a write request to the data node 102, indicating that the target data should be written to the data block. The write request includes the LBA (Local Basic Architecture) and the length of the target data; this LBA is the starting LBA of the first sector in the data block. Upon receiving the write request, the storage node 102 requests the target data from the business processing node 101. The business processing node 101 then sends the target data to the storage node 102 according to the request. After receiving the target data, storage node 102 writes the target data from the location indicated by LBA to the physical block corresponding to the data block, so that each sector of the target data is written to a sector of the physical block.

[0085] The writing process for verification fragments is similar to that for data fragments. The difference lies in that the data written to the corresponding sector of the verification block in the stripe consists of verification data and its metadata. This will not be elaborated further here.

[0086] After this batch of business data is written, if the number of data shards in this batch of business data is less than the number of data blocks in the strip, then some data blocks in this strip will not be written with data. For example, if a strip has 8 data blocks, but this batch of business data is divided into 6 data shards, then 2 data blocks in this strip will not be written with data. If the amount of data in a certain data shard is less than the storage capacity of the data blocks, then the data blocks written to that data shard will not be full. For ease of description, both data blocks that have not been written with data and data blocks that are not full are referred to as incomplete data blocks. A strip that still has incomplete data blocks after the business data has been written is called an incomplete strip. In other words, an incomplete strip is a strip that has not been full after the business data has been written.

[0087] Taking Figure 5(a) as an example, assume stripe 500 includes 7 logical blocks: data blocks 1-5, check blocks 6 and 7, with each logical block corresponding to 4 sectors. After writing a batch of business data into stripe 500, each sector corresponding to check blocks 6 and 7 contains 4096 bytes of check data and 64 bytes of metadata. The check data in the sector corresponding to check block 6 is represented by P data, and the check data in the sector corresponding to check block 7 is represented by Q data. Each sector corresponding to data blocks 1-3 contains 4096 bytes of business data and 64 bytes of metadata. Only one sector corresponding to data block 4 contains 4096 bytes of business data and 64 bytes of metadata. No data is written to any sector corresponding to data block 5. Therefore, data blocks 4 and 5 are incomplete logical blocks, and stripe 500 is an incomplete stripe.

[0088] In a scenario where the business processing node 101 writes business data to the storage disk 103 in the storage system at the granularity of stripes, if the stripe of the business data being written is not full, then pseudo data and the metadata of the pseudo data need to be written to the target sector corresponding to the not full stripe in order to fill the stripe so that the business processing node 101 can write business data to the next stripe.

[0089] The target sector refers to the sector in storage disk 103 where no data has been written to the sector corresponding to the incomplete segment. Pseudo-data refers to non-real business data used to fill the target sector corresponding to the incomplete segment, thus completing the data in the incomplete segment. The pseudo-data is used to fill the data area in the target sector; therefore, the length of the pseudo-data is the storage capacity of that data area. In other words, pseudo-data is non-real data written to fill the target sector. For example, pseudo-data may be all zeros, all one values, random data, or data with other data arrangements.

[0090] The metadata of pseudo-data can verify its reliability. This metadata includes integrity verification data and system metadata. The integrity verification data verifies the integrity of the pseudo-data and includes cyclic redundancy check (CRC) checks and the lower 32 bits of the LBA in the sector. The system metadata verifies the reliability of the pseudo-data and includes the data type identifier, the identifier of the stripe to which the sector belongs, and the identifier of the logical block group to which the stripe belongs. The data type identifier indicates the data type of the pseudo-data, indicating that the data in the data area of ​​the sector is pseudo-data. The stripe identifier indicates the stripe, and the logical block group identifier indicates the logical block group.

[0091] In related technologies, when writing pseudo-data to the target sector corresponding to an incomplete segment, the business processing node first prepares the pseudo-data to be written to the target sector along with its metadata. Then, it sends a write request to the storage node. This write request carries the starting LBA of the target sector and the target length, which is the total length of the pseudo-data and its metadata. The write request indicates that data of the target length should be written to the target sector. After receiving the write request, the storage node requests the data to be written to the target sector from the business processing node. Based on the storage node's request, the business processing node returns the pseudo-data and its metadata to the storage node. The storage node then writes the returned pseudo-data and its metadata to the target sector. However, the transmission of the pseudo-data and its metadata to the storage node via the network between the business processing node and the storage node causes the pseudo-data and its metadata to consume network bandwidth, thus increasing network bandwidth overhead.

[0092] Based on this, this application provides a method for writing pseudo-data. In this method, for incomplete sectors, the business processing node triggers the storage node to generate pseudo-data and writes the pseudo-data to the target sector corresponding to the incomplete sector. This eliminates the need for the business processing node to transmit pseudo-data over the network with the storage node, thus avoiding the pseudo-data consuming network bandwidth and reducing network bandwidth overhead.

[0093] Next, referring to Figure 6, the flow of this pseudo-data writing method will be introduced. This pseudo-data writing method is applied to any of the storage systems described above. As shown in Figure 6, the method includes the following steps.

[0094] 601. For incomplete rows in the storage system, the business processing node determines the target sector from the storage disk in the storage system, wherein the target sector is the sector in the storage disk corresponding to the incomplete row that has not been written with data.

[0095] The business processing node can be the business processing node 101 described above, and the storage disk can be the storage disk 103 described above. An incomplete segment is a segment that has not been filled with data after business data has been written. An incomplete segment corresponds to multiple sectors, and each of these sectors that has not been written with data is a target sector; therefore, there is at least one target sector. When there are multiple target sectors, these target sectors may belong to the same storage disk or different storage disks. The multiple sectors corresponding to an incomplete segment include the sectors in the physical blocks corresponding to each logical block within the incomplete segment.

[0096] For incomplete data strips, the business processing node identifies the sectors with no written data corresponding to each incomplete logical block within the incomplete strip as target sectors. Taking strip 500 as shown in Figure 5(a) as an example, sectors 1-3 corresponding to data block 4 have no written data, so the business processing node identifies these sectors as target sectors. Similarly, sectors 0-3 corresponding to data block 5 have no written data, so the business processing node identifies these sectors as target sectors.

[0097] 602. The business processing node sends a target write request to the storage node in the storage system. The target write request indicates that pseudo data should be written to the target sector.

[0098] In this context, the storage node corresponds to the target sector, and this storage node is the one in the storage system responsible for managing the storage disk where the target sector resides. A target write request can also be called a dummy write request. The target write request includes a target type identifier, which indicates the command type of the target write request so that the receiving device can identify the target write request based on the target type identifier.

[0099] The target write request indicates that pseudo-data will be written to M target sectors, where M is an integer greater than or equal to 1, representing the number of sectors to be written. If M > 0, the M target sectors can be multiple consecutive target sectors on the same storage disk, corresponding to the same logical block within an incomplete segment. The target write request includes a starting LBA and the number of sectors. The starting LBA is the starting LBA of the first target sector among the M target sectors, indicating the starting position for this pseudo-data write. The number of sectors is the total number of sectors for which pseudo-data is to be written in this request, i.e., M sectors.

[0100] Optionally, the target write request may also include the identifier of the stripe to which the target sector belongs (i.e., the incomplete stripe) and the identifier of the logical block group to which the stripe belongs, to indicate the stripe and the logical block group to which the target sector belongs. The stripe identifier may be the stripe index number, and the logical block group identifier may be the logical block group index number. In some embodiments, the target write request may not include the stripe identifier and the logical block group identifier. For example, the stripe identifier and the logical block group identifier are key information of the system metadata of the pseudo-data. In a scenario where the business processing node provides the metadata of the pseudo-data to the storage node, the target write request may not include the stripe identifier and the logical block group identifier.

[0101] The target write request is defined by the storage protocol supported by the storage node. This storage protocol includes nonvolatile memory express (NVMe) protocol, block storage protocol, object storage protocol, file storage protocol, network attached storage (NAS) protocol, storage area network (SAN) protocol, etc., but the type of storage protocol is not limited to these.

[0102] Taking the NVMe protocol as an example, the target write request defined by the NVMe protocol includes several fields as shown in Table 1.

[0103] Table 1

[0104] The CID field is a field already defined in the NVMe protocol, and the CID of the target write request can be an extended CID. The opcode field is a field already defined in the NVMe protocol, and the opcode of the target write request can be an extended opcode. The NS ID is a field already defined in the NVMe protocol, and the NS ID of the target write request can be an extended NS ID. The PSDT field is a field already defined in the NVMe protocol. The MPTR field is a field already defined in the NVMe protocol. In this embodiment, the MPTR field in the target write request is used to store the metadata pointer of the pseudo data. The MPTR field is an optional field. In some embodiments, the target write request does not include the MPTR field. For example, in some scenarios, the service processing node does not provide the metadata of the pseudo data, and the storage node generates the metadata of the pseudo data itself. The target write request used by the service processing node may not include the MPTR field, or the target write request includes the MPTR field, but the MPTR in the MPTR field is invalid data, and the storage node will not check the MPTR in the MPTR field. The SLBA field is a field already defined in the NVMe protocol. In this embodiment, the SLBA carried by the SLBA field in the target write request is the starting LBA of the first target sector among the M target sectors. The NLBA field is a field already defined in the NVMe protocol. In this embodiment, the NLBA carried by the NLBA field in the target write request is used as the number of sectors to be written for pseudo-data, i.e., NLBA = M. The Strip Index field and GroupNum field are fields extended in the NVMe protocol in this application. The Strip Index field and GroupNum field are optional fields in the target write request.

[0105] By extending the storage protocols supported by the storage nodes, the target write request and its data format can be defined so that the storage nodes can identify the target write request from the received commands.

[0106] For any incomplete logical block in the incomplete segment, after determining the target sectors corresponding to the incomplete logical block, the business processing node sends a target write request to the storage node corresponding to the incomplete logical block. The storage node corresponding to the incomplete logical block refers to the storage node responsible for managing the storage disk where the physical block corresponding to the incomplete logical block is located. The target write request includes the starting LBA and the number of sectors. The starting LBA is the starting LBA of the first target sector among the M target sectors corresponding to the incomplete logical block, and the number of sectors is the total number of target sectors corresponding to the incomplete logical block, which is M.

[0107] Taking stripe 500 shown in Figure 5(a) as an example of an incomplete stripe, data blocks 4 and 5 in stripe 500 are both incomplete logical blocks. Sectors 1-3 corresponding to data block 4 are all target sectors, and sectors 0-3 corresponding to data block 5 are also target sectors. For data block 4, the service processing node sends target write request 1 to the storage node. The starting LBA in target write request 1 is the starting LBA of sector 1 corresponding to data block 4, and the number of sectors in the target write request is 3. For data block 5, the service processing node sends target write request 2 to the storage node. The starting LBA in target write request 2 is the starting LBA of sector 0 corresponding to data block 5, and the number of sectors in target write request 2 is 4.

[0108] The above explanation uses the logical block granularity of sending target write requests as an example. In other embodiments, target write requests can also be sent at the sector granularity. For example, for each target sector, the service processing node sends a target write request to the storage node corresponding to each target sector. In this case, the starting LBA in the target write request is the starting LBA of a target sector, and the number of sectors in the target write request is 1. The storage node corresponding to the target sector is the storage node responsible for managing the storage disk where the target sector is located.

[0109] 603. After receiving the target write request, the storage node generates pseudo data.

[0110] The definition of pseudo data is as described above and will not be repeated here.

[0111] The storage node obtains the number of sectors from the target write request and generates pseudo-data representing the number of sectors. Assuming the number of sectors is M, the storage node generates M copies of this pseudo-data.

[0112] The generation process for each piece of pseudo-data is similar. Taking the generation of one piece of pseudo-data as an example, the generation process of pseudo-data will be described in an exemplary manner. For example, the storage node generates pseudo-data that meets the target data arrangement pattern. Here, the target data arrangement pattern is the arrangement pattern of the data in the pseudo-data, such as a data arrangement pattern of all 0s, or a data arrangement pattern of all 1s, or a data arrangement pattern of alternating 0s and 1s, or a data arrangement pattern of random arrangement.

[0113] Taking a data arrangement of all zeros as an example, the storage node generates 4096 bytes of zeros, which constitutes pseudo-data. Taking a random data arrangement as another example, the storage node generates 4096 bytes of random data, which also constitutes pseudo-data.

[0114] The target data arrangement can be flexibly set; however, this application embodiment does not limit the target data arrangement. The target data arrangement can be defined by extending the transmission protocols supported by the storage node, enabling the storage node to identify and generate pseudo data according to the defined target data arrangement.

[0115] For each set of M pseudo-data, the storage node also obtains the metadata of each pseudo-data. Taking Figure 5 as an example, if the storage node receives target write request 1 from the business processing node, and target write request 1 contains 3 sectors, then the storage node generates 3 sets of pseudo-data and obtains the metadata of each set. If the storage node receives target write request 2 from the business processing node, and target write request 2 contains 4 sectors, then the storage node generates 4 sets of pseudo-data and obtains the metadata of each set.

[0116] The storage node can obtain metadata for each piece of pseudo data from the business processing node (as in steps A1 to A3 in the method embodiment below), or the storage node can generate metadata for each piece of pseudo data separately (as in steps B1 to B3 in the method embodiment below), which will not be elaborated here.

[0117] 604. The storage node writes pseudo-data to the target sector.

[0118] In response to the target write request, the storage node generated M copies of pseudo data in step 603 above and also obtained the metadata of the M copies of pseudo data. For any target sector indicated by the target write request, the storage node writes one copy of the pseudo data and the metadata of that pseudo data (i.e., one copy of metadata) to the target sector to fill the target sector.

[0119] For example, after generating M sets of pseudo-data and obtaining the metadata of each set, for any given set of pseudo-data, the storage node concatenates the pseudo-data with its metadata (e.g., appends the metadata to the end of the pseudo-data) to obtain one sector data, thus obtaining M sets of sector data. The storage node obtains the starting LBA from the target write request, and starting from the position indicated by the starting LBA on the storage disk, writes M sets of sector data to the storage disk, such that each set of sector data fills a target sector, and the pseudo-data in each set of sector data fills the data area of ​​the target sector, and the metadata in each set of sector data fills the metadata area of ​​the target sector, thus filling the M target sectors starting from the starting LBA.

[0120] Taking Figure 5(b) as an example, when the storage node receives the target write request 1, it generates three sets of pseudo data and metadata for each set of pseudo data for data block 4 in stripe 500. The pseudo data and metadata of each set of pseudo data are concatenated into one set of sector data, resulting in three sets of sector data. The starting LBA in the target write request 1 is the starting LBA of sector 1 corresponding to data block 4. Then, the storage node writes one set of sector data to sectors 1, 2, and 3 corresponding to data block 4, respectively. The length of the pseudo data in one set of sector data is 4096B, which is the same as the storage capacity of the data area in the sector. The length of the metadata in one set of pseudo data is 64B, which is the same as the storage capacity of the metadata area in the sector. In this way, the pseudo data in one set of sector data can fill the data area in one sector, the metadata in one set of sector data can fill the metadata area in one sector, and the sector data can fill one sector. Thus, these three sets of sector data can fill sectors 1 to 3 corresponding to data block 4. The process of writing pseudo data to the four sectors corresponding to data block 5 in stripe 500 is similar. The difference is that when writing pseudo data to the sector corresponding to data block 5, the writing starts from sector 1 corresponding to data block 5, which will not be elaborated here.

[0121] After writing pseudo-data and its metadata to each target sector indicated by the target write request, the target write request is completed. The storage node can also send a write response to the target write request to the business processing node, which indicates that pseudo-data has been written to the target sectors. For incomplete stripes, the business processing node sends at least one target write request. If the business processing node receives a write response for each target write request, it means that each target sector corresponding to the incomplete stripe has been filled with data, and the incomplete stripe is also filled with data. For example, stripe 500 shown in Figure 5(b) is filled with data.

[0122] In the method provided in this application embodiment, for incomplete segments, the service processing node sends a target write request to the storage node, instructing the storage node to write pseudo-data to the target sector corresponding to the incomplete segment and for which no data has been written. Upon receiving the target write request, the storage node generates pseudo-data for the target sector and writes the pseudo-data to the target sector. This eliminates the need for the service processing node to transmit pseudo-data to the storage node via a network (such as a first network), avoiding the pseudo-data consuming network bandwidth and reducing network bandwidth overhead. Furthermore, since the metadata of the pseudo-data can verify its reliability, writing the pseudo-data and its metadata together to the target sector allows the service processing node to perform reliability verification based on the pseudo-data's metadata when subsequently reading data from the target sector. This reduces network bandwidth overhead while simultaneously verifying the reliability of the pseudo-data, improving the reliability of the storage system data.

[0123] In some embodiments, the business processing node can first configure a backup of the pseudo-data on the storage node, so that when the storage node processes the target write request, it writes the backup of the pseudo-data to the generated target sector. This implementation will be described below with reference to Figure 7.

[0124] Figure 7 is a flowchart of another pseudo-data writing method provided in an embodiment of this application. This method is applied to any of the storage systems described above and includes the following steps.

[0125] 701. The business processing node sends a backup of pseudo-data to the storage node in the storage system.

[0126] In this context, a backup of pseudo-data can be understood as a copy of pseudo-data, or a template of pseudo-data. This storage node can be any storage node in the storage system.

[0127] The method of sending pseudo data backups is as follows: For example, the business processing node can send a pseudo data configuration request to the storage node. The pseudo data configuration request instructs the storage node to configure the backup of pseudo data, and the pseudo data configuration request includes the backup of pseudo data.

[0128] 702. The storage node receives and stores a backup of the pseudo data.

[0129] For example, a storage node receives a pseudo-data configuration request from a business processing node, retrieves a backup of the pseudo-data from the request, and stores the backup in the storage node's memory to achieve pseudo-data backup. This allows the storage node to quickly retrieve the backup of the pseudo-data from memory when processing a target write request, thus improving the efficiency of pseudo-data retrieval.

[0130] Taking Figure 8 as an example, assume a storage system includes service processing nodes and storage nodes. The service processing node is a host, which can be a server or a storage array device, and the storage node is a storage disk or a storage device. In step 1, the service processing node configures a dummy template on the storage node. The dummy template is a template for pseudo data, which can be a 4096B copy of pseudo data. The dummy template is a backup of the pseudo data.

[0131] The business processing node can send backups of pseudo-data to each storage node in the storage system, ensuring that each storage node is configured with backups of pseudo-data. Steps 701 and 702 above are optional. For example, if backups of pseudo-data are manually configured on each storage node, or if the storage nodes can generate pseudo-data themselves according to the target data format, then the business processing node does not need to send backups of pseudo-data to the storage nodes, and steps 701 and 702 above can be omitted.

[0132] 703. For incomplete rows in the storage system, the business processing node sends a target write request to the storage node. The target write request indicates that pseudo data should be written to the target sector, which is the sector in the storage disk corresponding to the incomplete row that has not yet been written with data.

[0133] Step 703 is similar to steps 601 and 602 above, and will not be described again in this embodiment.

[0134] 704. Upon receiving the write request for the target, the storage node reads a backup of the pseudo-data from memory.

[0135] The storage node receives a target write request, obtains the number of sectors M from the request, and reads a backup of pseudo-data from memory. This backup is a copy of the pseudo-data, thus generating one copy of the pseudo-data. If M = 1, the read backup is the pseudo-data generated for the target write request. If M > 1, the storage node copies the read backup M-1 times, resulting in M ​​copies of the pseudo-data, thus generating M copies of the pseudo-data for the target write request.

[0136] Alternatively, for the number of sectors M, the storage node reads M backups of pseudo data from memory, thus obtaining M backups of pseudo data. These M backups of pseudo data are also the M pseudo data generated for the target write request.

[0137] Reading a backup of pseudo data from memory once generates one copy of pseudo data. Copying the backup of pseudo data or reading the backup of pseudo data from memory multiple times can yield more pseudo data. It is not necessary to generate each copy of pseudo data according to the target data format, which enables storage nodes to quickly obtain pseudo data, improves the efficiency of pseudo data acquisition, and reduces the consumption of storage node computing resources.

[0138] For M sets of pseudo data, the storage node also obtains the metadata of the M sets of pseudo data. Taking the storage node obtaining the metadata of the M sets of pseudo data from the business processing node as an example, the metadata of the M sets of pseudo data can be obtained through the following steps A1 to A3.

[0139] Step A1: The storage node sends a metadata read request to the business processing node. The metadata read request indicates that the metadata of the pseudo data should be read.

[0140] The metadata read request includes location information for M pieces of metadata, indicating their positions in the memory of the business processing node. These M pieces of metadata are metadata for M pieces of pseudo-data.

[0141] Before sending a target write request to the storage node, the application processing node generates M metadata copies for the M target sectors corresponding to the same incomplete logical block in the incomplete stripe. One of these metadata copies is the metadata of pseudo-data for one target sector (i.e., metadata of pseudo-data). The application processing node stores the M metadata copies in its memory. Based on the number of sectors M, the starting LBA of the first target sector among the M target sectors, and the location information of the M metadata copies, it generates a target write request. This target write request indicates that pseudo-data be written to the M target sectors and that the metadata of the pseudo-data be retrieved from the application processing node. The number of sectors M, the starting LBA, and the location information are located in the MLBA, SLBA, and MPTR fields of the target write request, respectively. After generating the target write request, the application processing node sends the target write request to the storage node corresponding to the M target sectors.

[0142] The storage node obtains the location information of M pieces of metadata from the received target write request, generates a metadata read request based on the location information of the M pieces of metadata, and sends the generated metadata read request to the service processing node. The storage node can send the metadata read request before or after generating the M pieces of pseudo data. Here, this embodiment of the application does not limit the timing of sending the metadata read request.

[0143] Taking Figure 8 as an example, assuming that there are four target sectors corresponding to a certain incomplete logical block in the incomplete segment, the business processing node generates a 64B metadata copy for each of these four target sectors' pseudo-data, thus obtaining four 64B metadata copies, which are stored in the memory of the business processing node. In step 2, the business processing node performs a pseudo-data write operation, which includes the business processing node sending a pseudo-data write command (CMD) to the storage node. The pseudo-data write command is transmitted to the storage node through the first network. The pseudo-data write command is a target write request, and it includes the location information of the four 64B metadata copies. The storage node receives the pseudo-data write command and, based on the location information of the metadata in the pseudo-data write command, returns a metadata read request to the business processing node. The metadata read request includes this location information.

[0144] Step A2: The business processing node receives the metadata read request from the storage node and sends the metadata of the pseudo data to the storage node.

[0145] The business processing node obtains the location information of the metadata of M pseudo data from the metadata read request. Based on the location information, it reads the metadata of M pseudo data from the memory of the business processing node and returns the metadata of M pseudo data to the storage node.

[0146] Taking Figure 8 as an example, in step 2, after receiving the metadata read request from the storage node, the service processing node returns four 64B copies of metadata stored in memory to the storage node. These four 64B copies of metadata are transmitted to the storage node through the first network. Therefore, when the service processing node writes pseudo-data to the storage node, it only sends a CMD (target write request) and the metadata of the pseudo-data to the storage node, without sending the pseudo-data itself. Compared to the scheme where the storage node obtains the pseudo-data and its metadata from the service processing node, the service processing node in this embodiment does not provide pseudo-data to the storage node, thus avoiding the pseudo-data consuming network bandwidth between the service processing node and the storage node and reducing network bandwidth overhead.

[0147] Step A3: The storage node receives the metadata of the pseudo data returned by the business processing node.

[0148] For example, the storage node receives metadata for M sets of pseudo-data returned by the business processing node.

[0149] Steps A1 to A3 above illustrate the example of a storage node retrieving metadata for all pseudo-data to be written from a business processing node at once. In other embodiments, the storage node may read metadata for only one copy of the pseudo-data at a time. For example, for any one of the M copies of pseudo-data, the storage node sends a pseudo-data read request to the business processing node. This pseudo-data read request instructs the storage node to read the metadata of that copy of pseudo-data, and includes the location information of the metadata of that copy of pseudo-data in the memory of the business processing node. Upon receiving the pseudo-data read request, the business processing node returns the metadata of one copy of pseudo-data to the storage node based on the location information in the pseudo-data read request. In this way, by sending M pseudo-data read requests to the business processing node, the storage node can read the metadata of M copies of pseudo-data from the business processing node.

[0150] In other embodiments, the storage node may also generate its own metadata for M copies of pseudo-data instead of obtaining the metadata for M copies of pseudo-data from the business processing node. The method by which the storage node generates metadata can be found in steps B1 to B3 of the embodiments below, and will not be repeated here.

[0151] 705. Backup of pseudo-data written by the storage node to the target sector.

[0152] In response to the target write request, the storage node generates M copies of pseudo data in step 704 above. When M=1, this pseudo data is a backup of the pseudo data. When M>1, one copy of the pseudo data is a backup of the pseudo data, and M-1 copies of the pseudo data are backups of the copied pseudo data.

[0153] In response to the target write request, the storage node also obtained the metadata of M sets of pseudo-data in step 704 above. For any target sector indicated by the target write request, the storage node writes one set of pseudo-data and its metadata (i.e., one set of metadata) from these M sets of pseudo-data to that target sector to fill it. This process can be referred to the relevant description in step 604 above, and will not be repeated here.

[0154] Taking Figure 8 as an example, in step 3, the storage node uses host metadata and a dummy template to generate host user write data. The host metadata is the metadata of the pseudo-data sent by the service processing node. The dummy template is a backup of the pseudo-data. The host user write data is the sector data to be written. The host user data is generated in the following way: for a specific target sector, the storage node reads the dummy template from memory, concatenates the read dummy template with a 64-byte metadata provided by the service processing node to obtain the host user data, and then writes the host user data to that target sector.

[0155] This application provides a method that distributes a backup of pseudo-data through a service processing node. This allows the storage node, upon receiving a target write request, to use the empty backup as the pseudo-data to be written. This eliminates the need for the service processing node to transmit pseudo-data over the network with the storage node when writing it to the target sector, thus avoiding bandwidth consumption and reducing network bandwidth overhead. Furthermore, since the metadata of the pseudo-data can verify its reliability, writing the backup and metadata together to the target sector allows the service processing node to perform reliability verification based on the metadata when reading data from the target sector. This reduces network bandwidth overhead while simultaneously verifying the reliability of the pseudo-data, improving the reliability of the storage system data.

[0156] Steps A1 to A3 above are illustrated using the example of the business processing node providing metadata of pseudo data to the storage node. In other embodiments, the storage node can also generate the metadata of pseudo data itself. Next, this implementation method will be introduced with reference to Figure 9.

[0157] Figure 9 is a flowchart of another pseudo-data writing method provided in an embodiment of this application. The method is applied to a storage system, which can be any of the storage systems described above. The method also includes the following steps.

[0158] 901. The business processing node sends a metadata generation policy to the storage node in the storage system. The metadata generation policy instructs the generation of pseudo-data metadata based on key information.

[0159] The storage node can be any storage node in the storage system. This key information is crucial metadata used to generate pseudo data. This key information includes the identifier of the stripe to which the target sector belongs and the identifier of the logical block group to which the stripe is located. The target sector has been described above and will not be repeated here. The stripe to which the target sector belongs is an incomplete stripe.

[0160] The metadata generation strategy includes target location information, which indicates the position of the system metadata in the metadata. For example, the target location information can be the offset of the system metadata relative to the integrity verification data (called the target offset). For example, if the length of the integrity verification data is 8B, then the target offset is 8B.

[0161] In some embodiments, the metadata generation strategy does not include target location information. The business processing node sends the target location information to the storage node, and the storage node receives and stores the target location information so that metadata can be generated for pseudo-data based on the target location information later. In some embodiments, the target location information is manually configured to the storage node. In this case, the business processing node may not send the target location information to the storage node, and the metadata generation strategy may not include the target location information.

[0162] 902. Storage nodes receive and store metadata generation strategies.

[0163] Upon receiving the metadata generation strategy, the storage node can store the metadata generation strategy in the storage node's memory to configure the metadata generation strategy so that pseudo-data metadata can be generated based on the configured metadata generation strategy when processing target write requests.

[0164] In some embodiments, prior to step 902, the service processing node can also configure the backup of pseudo-data on the storage node. The configuration method can be referred to the processes shown in steps 701 and 702 above, and will not be repeated here. Taking Figure 10 as an example, assume a storage system includes service processing nodes and storage nodes, where the service processing node is a host, which can be a server or a storage array device, and the storage node is a storage disk or a storage device. In step 1, the service processing node configures a dummy template on the storage node. The dummy template is a template for pseudo-data, which can be a 4096B copy of pseudo-data; the dummy template is a backup of the pseudo-data. In the subsequent step 2, the service processing node configures metadata generation rules (i.e., metadata generation strategies) on the storage node.

[0165] In some embodiments, prior to step 902, the business processing node may not configure the backup of pseudo data on the storage node. For example, in some scenarios, the backup of pseudo data is manually configured on the storage node, or the storage node can generate pseudo data according to the target data format. In this scenario, the business processing node may not configure the backup of pseudo data on the storage node.

[0166] The business processing node can send metadata generation policies to each storage node in the storage system so that each storage node is configured with pseudo-data containing metadata. Steps 901 and 902 above are optional. For example, if the metadata generation policies are manually configured in each storage node, or if the business processing node can provide the metadata for the pseudo-data, then the business processing node does not need to send metadata generation policies to the storage nodes, and steps 901 and 902 above can be omitted.

[0167] 903. For incomplete rows in the storage system, the business processing node sends a target write request to the storage node. The target write request indicates that pseudo data should be written to the target sector, which is the sector in the storage disk corresponding to the incomplete row that has not yet been written with data.

[0168] Step 903 is similar to steps 601 and 602 above. The difference is that in step 903, the target write request includes key metadata information of the pseudo data.

[0169] For example, for M target sectors corresponding to the same incomplete logical block within an incomplete stripe, the business processing node generates a target write request based on the number of sectors M, the starting LBA of the first target sector among the M target sectors, and key metadata information. This target write request indicates the writing of pseudo-data to the M target sectors and the metadata for generating the pseudo-data based on the key metadata information. The number of sectors M and the starting LBA are located in the NLBA and SLBA fields of the target write request, respectively. The key metadata information includes the identifier of the stripe to which the target sector belongs and the identifier of the logical block group to which the stripe belongs. The stripe identifier and the logical block group identifier are located in the Strip Index and GroupNum fields of the target write request, respectively. Since these M target sectors belong to the same stripe, they can share the same key metadata information; therefore, the target write request only needs to include one set of key metadata information. After generating the target write request, the business processing node sends the target write request to the storage node corresponding to these M target sectors.

[0170] Taking Figure 10 as an example, in step 3, the business processing node performs a pseudo-data write operation. This write operation includes the business processing node sending a pseudo-data write command (CMD) to the storage node. The pseudo-data write command is transmitted to the storage node through the first network. The pseudo-data write command is a target write request and includes key information about the pseudo-data's metadata. Since the storage node subsequently generates metadata for the pseudo-data based on the key information of the metadata, without requesting the pseudo-data's metadata from the business processing node, the business processing node only sends one CMD when writing data to the target sector. Compared to the scheme where the storage node requests pseudo-data and its metadata from the business processing node, in this embodiment, the business processing node does not need to provide pseudo-data and its metadata to the storage node. Therefore, it can avoid the pseudo-data and its metadata occupying the network bandwidth between the business processing node and the storage node, reducing the network bandwidth overhead.

[0171] 904. Upon receiving the target write request, the storage node generates pseudo data, which is based on the key information of the metadata in the target write request, and generates the metadata of the pseudo data.

[0172] For a target write request, the storage node can generate M copies of pseudo-data in the same way as in step 603 above, or it can generate M copies of pseudo-data in the same way as in step 704 above. Further details will not be provided here.

[0173] For M pieces of pseudo data, the storage node generates metadata for each piece of pseudo data based on the key information of the metadata in the target write request. The generation process of the metadata for each piece of pseudo data is similar. Next, taking the generation of metadata for one piece of pseudo data as an example, the metadata generation process will be described in illustrative terms in conjunction with the following steps B1 to B3.

[0174] Step B1: The storage node generates integrity verification data for the pseudo data, which is used to verify the integrity of the pseudo data.

[0175] The integrity verification data has the same storage capacity as the DIF data in the metadata area of ​​the target sector. The specific content of the integrity verification data for the pseudo-data is as described above and will not be repeated here.

[0176] Step B2: The storage node generates system metadata for pseudo data. This system metadata includes key information about the metadata.

[0177] The storage node obtains key information of the metadata from the target write request, and generates system metadata based on the data type identifier of the pseudo data and the key information of the metadata. The system metadata includes the data type identifier and the key information.

[0178] Step B3: The storage node concatenates the integrity verification data and system metadata to obtain the metadata of the pseudo data.

[0179] The storage node retrieves the target location information, which indicates the position of the system metadata within the metadata. This retrieval can occur in several ways, such as by obtaining the target location information from the metadata generation strategy, or by reading the target location information from memory if it is stored there.

[0180] After obtaining the target location information, the storage node concatenates the integrity verification data and system metadata based on the target location information. For example, assuming the target location information is a target offset of 8B, the storage node generates 8B of integrity verification data. After concatenating the 8B of integrity verification data, it concatenates the system metadata to obtain a pseudo-data metadata. This ensures that the arrangement of the integrity verification data and system metadata in the metadata is the same as the arrangement of the DIF and system metadata areas in the sector's metadata area. This allows the integrity verification data and system metadata to be written to the DIF and system metadata areas of the metadata area respectively when writing pseudo-data metadata to the target sector's metadata area later.

[0181] Taking Figure 10 as an example, in step 4, the storage node uses metadata generation rules to generate host metadata. This host metadata is pseudo-data metadata. For example, the storage node generates 64B of metadata based on the target location information in the metadata generation rules and the key information of the metadata in the pseudo-data CMD. The generation process can be referred to steps B1 to B3 above.

[0182] Following steps B1 to B3 above, the storage node can generate metadata for each of the M sets of pseudo-data, thus obtaining the metadata for the M sets of pseudo-data. Since the generated metadata includes integrity verification data and system metadata, subsequent business processing nodes can verify the read pseudo-data based on this metadata, thereby improving the reliability of the storage system. Key information in the metadata includes the identifier of the stripe to which the target sector belongs and the identifier of the logical block group to which the stripe belongs. This allows business processing nodes to verify whether the read pseudo-data belongs to the expected stripe and logical block group based on the stripe and logical block group identifiers in the key information when reading data from the target sector, thus enabling reliability verification of the pseudo-data.

[0183] 905. The storage node writes pseudo data and its metadata to the target sector.

[0184] In response to the target write request, the storage node generates M copies of pseudo-data and metadata for each copy of pseudo-data in step 904 above. For any target sector indicated by the target write request, the storage node writes one copy of the M copies of pseudo-data and its metadata (i.e., one copy of metadata) to that target sector to fill it. This process can be referred to the relevant description in step 604 above, and will not be repeated here.

[0185] Taking Figure 10 as an example, in step 4, host user write data is generated using metadata generation rules. The host user write data is the sector data to be written. The generation method of host user data is, for example, for a certain target sector, the storage node reads a dummy template from memory, uses the read dummy template as a 4096B pseudo data, uses metadata generation rules to generate 64B of metadata for the pseudo data, and concatenates the 4096B pseudo data with the 64B metadata to obtain the host user write data, and writes the host user write data to the target sector.

[0186] In the method provided in this application embodiment, for incomplete segments, the service processing node sends a target write request to the storage node, instructing the storage node to write pseudo-data to the target sector corresponding to the incomplete segment and for which no data has been written. Upon receiving the target write request, the storage node generates pseudo-data and its metadata for the target sector and writes the pseudo-data and its metadata to the target sector to fill it. During this process, the storage node does not need to request the pseudo-data and its metadata from the service processing node, nor does the service processing node need to transmit the pseudo-data and its metadata to the storage node through the network (such as a first network) between them. This avoids the pseudo-data and its metadata consuming network bandwidth, reducing network bandwidth overhead. Furthermore, since the metadata of the pseudo-data can verify its reliability, writing the pseudo-data and its metadata together to the target sector allows the service processing node to perform reliability verification on the pseudo-data based on its metadata when reading data from the target sector later. This reduces network bandwidth overhead while also verifying the reliability of the pseudo-data, improving the reliability of the storage system data.

[0187] The methods of the embodiments of this application have been described above, and the apparatus of the embodiments of this application is described below. It should be understood that the apparatus described below has any of the functions of the storage node or the service processing node in the above methods. The pseudo-data writing method according to the embodiments of this application has been described in detail above with reference to Figures 3 to 10. Based on the same inventive concept, the apparatus for pseudo-data writing according to the embodiments of this application will be described below with reference to Figures 11 to 13. It should be understood that the technical features described in the method embodiments are also applicable to the apparatus embodiments below.

[0188] Figure 11 is a schematic diagram of a pseudo-data writing device provided in an embodiment of this application. The pseudo-data writing device 1100 shown in Figure 11 can be a storage node involved in the previous embodiments, or it can be a component in the storage node. The pseudo-data writing device 1100 is used to execute the method steps executed by the storage node in the above-described pseudo-data writing method. As shown in Figure 11, the pseudo-data writing device 1100 includes:

[0189] The receiving module 1101 is used to receive a target write request from a business processing node in the storage system. The target write request indicates that pseudo data is written to a target sector, where the target sector is a sector in the storage disk that is not full and has not yet been written with data.

[0190] The first generation module 1102 is used to generate the pseudo data after receiving the target write request;

[0191] The writing module 1103 is used to write the pseudo data to the target sector.

[0192] Optionally, the target write request is defined by the storage protocol supported by the storage node.

[0193] Optionally, the first generation module 1102 is used to read a backup of the pseudo data from memory;

[0194] The writing module 1103 is used to write a backup of the pseudo data to the target sector.

[0195] Optionally, the receiving module 1101 is further configured to receive a backup of the pseudo data sent by the service processing node and store the backup in the memory.

[0196] Optionally, the writing module 1103 is used to write the pseudo data and the metadata of the pseudo data into the target sector, wherein the metadata can verify the reliability of the pseudo data.

[0197] Optionally, the pseudo-data writing device 1100 further includes:

[0198] The sending module is used to send a metadata read request to the service processing node, wherein the metadata read request indicates that the metadata of the pseudo data be read;

[0199] The receiving module 1101 is also used to receive the metadata returned by the service processing node.

[0200] Optionally, the pseudo-data writing device 1100 further includes:

[0201] The second generation module is used to generate the metadata based on the key information of the metadata in the target write request.

[0202] Optionally, the key information includes the identifier of the stripe to which the target sector belongs and the identifier of the logical block group to which the stripe is located.

[0203] Optionally, the second generation module includes:

[0204] A generation unit is used to generate integrity verification data for the pseudo data, and the integrity verification data is used to verify the integrity of the pseudo data.

[0205] The generation unit is also used to generate system metadata of the pseudo data, the system metadata including key information of the metadata;

[0206] The splicing unit is used to splice the integrity verification data and system metadata to obtain the metadata.

[0207] Optionally, the splicing unit is used to splice the integrity verification data and system metadata based on target location information, wherein the target location information indicates the position of the system metadata in the metadata.

[0208] Optionally, the receiving module 1101 is further configured to receive the target location information sent by the service processing node.

[0209] It should be understood that the pseudo data writing device 1100 corresponds to the storage node in the above method embodiment. The modules in the pseudo data writing device 1100 and the other operations and / or functions described above are various steps and methods implemented by the storage node in the method embodiment. For specific details, please refer to the above method embodiment. For the sake of brevity, they will not be repeated here.

[0210] It should be understood that the pseudo-data writing device 1100 is only illustrated by the above-described division of functional modules when writing pseudo-data. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the pseudo-data writing device 1100 can be divided into different functional modules to complete all or part of the functions described above. In addition, the pseudo-data writing device 1100 provided in the above embodiments and the above method embodiments belong to the same concept, and its specific implementation process is detailed in the above method embodiments, which will not be repeated here.

[0211] Figure 12 is a schematic diagram of another pseudo-data writing device provided in an embodiment of this application. The pseudo-data writing device 1200 shown in Figure 12 can be a business processing node involved in the previous embodiments, or it can be a component in the business processing node. The pseudo-data writing device 1200 is used to execute the method steps performed by the business processing node in the above pseudo-data writing method. As shown in Figure 12, the pseudo-data writing device 1200 includes:

[0212] The determining module 1201 is used to determine a target sector from the storage disk in the storage system for the incomplete stripe in the storage system. The target sector is the sector in the storage disk that corresponds to the incomplete stripe and has not been written with data.

[0213] The sending module 1202 is used to send a target write request to a storage node in the storage system. The target write request indicates that pseudo data be written to the target sector. The pseudo data is generated by the storage node.

[0214] Optionally, the target write request is defined by the storage protocol supported by the storage node.

[0215] Optionally, the sending module 1202 is also used to send a backup of the pseudo data to the storage node.

[0216] Optionally, the pseudo-data writing device 1200 further includes:

[0217] A receiving module is configured to receive a metadata read request from the storage node, the metadata read request indicating the reading of the metadata of the pseudo data, the metadata being able to verify the reliability of the pseudo data;

[0218] The sending module 1202 is also used to send the metadata to the storage node.

[0219] Optionally, the target write request includes key information about the metadata of the pseudo data, which can verify the reliability of the pseudo data.

[0220] Optionally, the key information includes the identifier of the stripe to which the target sector belongs and the identifier of the logical block group to which the stripe is located.

[0221] Optionally, the sending module 1202 is further configured to send target location information to the storage node, the target location information indicating the location of the system metadata in the metadata.

[0222] It should be understood that the pseudo data writing device 1200 corresponds to the business processing node in the above method embodiment. The modules in the pseudo data writing device 1200 and the other operations and / or functions described above are various steps and methods implemented by the business processing node in the method embodiment. For specific details, please refer to the above method embodiment. For the sake of brevity, they will not be repeated here.

[0223] It should be understood that the pseudo-data writing device 1200 is only illustrated by the above-described division of functional modules when writing pseudo-data. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the pseudo-data writing device 1200 can be divided into different functional modules to complete all or part of the functions described above. In addition, the pseudo-data writing device 1200 provided in the above embodiments and the above method embodiments belong to the same concept, and its specific implementation process is detailed in the above method embodiments, which will not be repeated here.

[0224] Figure 13 is a schematic diagram of a communication device provided in an embodiment of this application. The communication device 1300 shown in Figure 13 can be configured as a host or as a storage control device. The host corresponds to the service processing node described above, and the storage control device corresponds to the storage node described above. When configured as a host, the communication device 1300 is used to execute the method steps executed by the service processing node in the above method embodiment. When configured as a storage control device, the communication device 1300 is used to execute the method steps executed by the storage node in the above method embodiment.

[0225] As shown in Figure 13, the communication device 1300 includes a bus 1302, a processor 1304, a memory 1306, and a communication interface 1308. The processor 1304, memory 1306, and communication interface 1308 communicate with each other via the bus 1302. The bus 1302 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, only one line is used in Figure 13, but this does not imply that there is only one bus or one type of bus. The bus 1302 can include pathways for transmitting information between the various components of the communication device 1300 (e.g., memory 1306, processor 1304, communication interface 1308). The processor 1304 can include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 1304 can be implemented using at least one of the following hardware forms: digital signal processing (DSP), field-programmable gate array (FPGA), programmable logic array (PLA), and application-specific integrated circuit (ASIC). Processor 1301 may also include a main processor and a coprocessor. The main processor, also known as a central processing unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1304 may integrate a graphics processing unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 1304 may also include an artificial intelligence (AI) processor, which handles computational operations related to machine learning, such as a neural network processing unit (NPU) or a tensor processing unit (TPU), but the type of AI processor is not limited to these.

[0226] The memory 1306 can serve as the main memory or secondary storage of the communication device 1300. The memory 1306 can be a non-transitory memory, which can be volatile memory or non-volatile memory, or a combination of both. Volatile memory, for example, is random access memory (RAM). Non-volatile memory, for example, can be read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD).

[0227] When the communication device 1300 is configured as a storage control device, the memory 1306 stores executable first program code, and the processor 1304 reads and executes the first program code, so that the communication device 1300 (i.e. the storage control device) implements the method steps executed by the storage node in the above-mentioned pseudo data writing method.

[0228] When the communication device 1300 is configured as a host, the memory 1306 stores executable second program code, and the processor 1304 reads and executes the second program code, so that the communication device 1300 (i.e. the host) implements the method steps executed by the service processing node in the above-mentioned pseudo data writing method.

[0229] The communication interface 1308 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the communication device 1300 and other devices or communication networks.

[0230] This application also provides a chip including logic circuitry for executing the method steps performed by the storage node or business processing node in the aforementioned pseudo-data writing method. In one possible implementation, the chip further includes a power supply circuit coupled to the logic circuitry, and the functional circuitry provides power to the logic circuitry so that it can execute the aforementioned data center energy-saving control method. Exemplarily, the logic circuitry is a DSP, FPGA, PLA, ASIC, programmable logic device (PLD), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0231] In an exemplary embodiment, a computer-readable storage medium is also provided, such as a memory including program code that can be executed by a processor in a storage control device to complete the method steps performed by the storage node in the pseudo-data writing method of the above embodiments. For example, the computer-readable storage medium is a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device.

[0232] In an exemplary embodiment, a computer-readable storage medium is also provided, such as a memory including program code that can be executed by a processor in a host to perform the method steps executed by the service processing node in the pseudo-data writing method of the above embodiments. For example, the computer-readable storage medium is the non-temporary computer-readable storage medium described above.

[0233] This application also provides a computer program product or computer program, which includes program code. The computer instructions are stored in a computer-readable storage medium. The processor of the storage control device reads the program code from the computer-readable storage medium and executes the program code, causing the storage control device to perform the method steps executed by the storage node in the above-described pseudo-data writing method.

[0234] This application also provides a computer program product or computer program, which includes program code and computer instructions stored in a computer-readable storage medium. The host's processor reads the program code from the computer-readable storage medium and executes the program code, causing the host to execute the method steps performed by the business processing node in the above-described pseudo-data writing method.

[0235] In the description of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more, and "multiple" means two or more. The terms "first," "second," etc., do not limit the quantity or order of execution, and "first," "second," etc., do not necessarily imply differences.

[0236] In this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0237] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the business data involved in this application were all obtained with full authorization.

[0238] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0239] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for writing pseudo-data, characterized in that, The method, applied to storage nodes in a storage system, includes: Receive a target write request from a business processing node in the storage system. The target write request indicates that pseudo data be written to a target sector. The target sector is a sector in the storage disk that corresponds to an incomplete row and has not yet been written with data. After receiving the target write request, the pseudo data is generated; Write the pseudo data into the target sector.

2. The method according to claim 1, characterized in that, The target write request is defined by the storage protocol supported by the storage node.

3. The method according to claim 1 or 2, characterized in that, The generation of the pseudo data includes: Read a backup of the pseudo data from memory; The step of writing the pseudo data to the target sector includes: A backup of the pseudo data is written to the target sector.

4. The method according to claim 3, characterized in that, Before receiving the target write request from the service processing node in the storage system, the method further includes: The system receives a backup of the pseudo data sent by the service processing node and stores the backup in the memory.

5. The method according to any one of claims 1-4, characterized in that, The step of writing the pseudo data to the target sector includes: The pseudo data and its metadata are written to the target sector, and the metadata can verify the reliability of the pseudo data.

6. The method according to claim 5, characterized in that, Before writing the pseudo data and its metadata to the target sector, the method further includes: Send a metadata read request to the business processing node, the metadata read request indicating that the metadata of the pseudo data be read; Receive the metadata returned by the service processing node.

7. The method according to claim 5, characterized in that, Before writing the pseudo data and its metadata to the target sector, the method further includes: The metadata is generated based on the key information of the metadata in the target write request.

8. The method according to claim 7, characterized in that, The key information includes the identifier of the stripe to which the target sector belongs and the identifier of the logical block group to which the stripe is located.

9. The method according to claim 7 or 8, characterized in that, The generation of the metadata based on the key information of the metadata in the target write request includes: Generate integrity verification data for the pseudo data, which is used to verify the integrity of the pseudo data. The system metadata that generates the pseudo data, the system metadata including key information of the metadata; The integrity verification data and system metadata are concatenated to obtain the metadata.

10. The method according to claim 9, characterized in that, The process of concatenating the integrity verification data and system metadata to obtain the metadata includes: Based on the target location information, the integrity verification data and system metadata are concatenated, and the target location information indicates the position of the system metadata in the metadata.

11. The method according to claim 10, characterized in that, Before receiving the target write request from the service processing node in the storage system, the method further includes: Receive the target location information sent by the service processing node.

12. A method for writing pseudo-data, characterized in that, The method, applied to a business processing node in a storage system, includes: For the incomplete rows in the storage system, a target sector is determined from the storage disk in the storage system. The target sector is the sector in the storage disk corresponding to the incomplete row that has not been written with data. A target write request is sent to a storage node in the storage system. The target write request instructs that pseudo data be written to the target sector. The pseudo data is generated by the storage node.

13. The method according to claim 12, characterized in that, The target write request is defined by the storage protocol supported by the storage node.

14. The method according to claim 12 or 13, characterized in that, Before determining the target sector from the storage disk in the storage system for the incomplete segments in the storage system, the method further includes: The backup of the pseudo data is sent to the storage node.

15. The method according to any one of claims 12-14, characterized in that, After sending the target write request to the storage node in the storage system, the method further includes: Receive the metadata read request from the storage node, the metadata read request instructing the reading of the metadata of the pseudo data, the metadata being able to verify the reliability of the pseudo data; Send the metadata to the storage node.

16. The method according to any one of claims 12-14, characterized in that, The target write request includes key information about the metadata of the pseudo data, which can verify the reliability of the pseudo data.

17. The method according to claim 16, characterized in that, The key information includes the identifier of the stripe to which the target sector belongs and the identifier of the logical block group to which the stripe is located.

18. The method according to claim 16 or 17, characterized in that, Before determining the target sector from the storage disk in the storage system for the incomplete segments in the storage system, the method further includes: Send target location information to the storage node, the target location information indicating the location of the system metadata in the metadata.

19. A pseudo-data writing device, characterized in that, The device includes: The receiving module is used to receive the target write request from the business processing node in the storage system. The target write request indicates that pseudo data should be written to the target sector, which is the sector in the storage disk that is not full and has not been written with data. The first generation module is used to generate the pseudo data after receiving the target write request; The writing module is used to write the pseudo data into the target sector.

20. The apparatus according to claim 19, characterized in that, The target write request is defined by the storage protocol supported by the storage node.

21. The apparatus according to claim 19 or 20, characterized in that, The first generation module is used to read a backup of the pseudo data from memory; The writing module is used to write a backup of the pseudo data to the target sector.

22. The apparatus according to any one of claims 19-20, characterized in that, The writing module is used for: The pseudo data and its metadata are written to the target sector, and the metadata can verify the reliability of the pseudo data.

23. The apparatus according to claim 22, characterized in that, The device further includes: The sending module is used to send a metadata read request to the service processing node, wherein the metadata read request indicates that the metadata of the pseudo data be read; The receiving module is also used to receive the metadata returned by the service processing node.

24. A pseudo-data writing device, characterized in that, The device includes: The determination module is used to determine the target sector from the storage disk in the storage system for the incomplete stripe in the storage system. The target sector is the sector in the storage disk that corresponds to the incomplete stripe and has not been written with data. The sending module is used to send a target write request to a storage node in the storage system. The target write request indicates that pseudo data be written to the target sector. The pseudo data is generated by the storage node.

25. The apparatus according to claim 24, characterized in that, The device further includes: A receiving module is configured to receive a metadata read request from the storage node, the metadata read request indicating the reading of the metadata of the pseudo data, the metadata being able to verify the reliability of the pseudo data; The sending module is used to send the metadata to the storage node.

26. A storage system, characterized in that, The storage system includes a business processing node, a storage node, and multiple storage disks. The business processing node is used to execute the method as described in any one of claims 12 to 18, and the storage node is used to execute the method as described in any one of claims 1 to 11.

27. A storage control device, characterized in that, The storage control device includes a processor for executing program code that causes the host to perform the method as described in any one of claims 1 to 11.

28. A host computer, characterized in that, The host includes a processor for executing program code that causes the host to perform the method as described in any one of claims 12 to 18.

29. A computer-readable storage medium, characterized in that, The storage medium stores at least one piece of program code, which is read by a processor to cause the storage control device to perform the method as described in any one of claims 1 to 11.

30. A computer-readable storage medium, characterized in that, The storage medium stores at least one piece of program code, which is read by a processor to cause the host to execute the method as described in any one of claims 12 to 18.

Images