RAID card device and data recovery method based on RAID card device

Abstract

The invention relates to the technical field of storage equipment, in particular to an RAID card device and a data recovery method based on the RAID card device, and the RAID card device comprises an RAID engine module which is used for processing RAID 1 / 10 level read-write operation and automatic reconstruction; the Cookie generation module is used for dynamically generating and filling the mirror image disk identification information to the APPID field of the protection information field in the read response; the Cookie analysis module is used for extracting mirror image disk identification information in the rereading request and switching a reading path; and the repair execution module executes mirror disk data synchronization according to a host instruction. A host does not need to generate check block information, cookie is stored through an APPID of protection information (hereinafter referred to as PI) to transmit mirror image position information, a mirror image disk information tracking mechanism is simplified, the host does not need to calculate check data in a block device layer, and only cookie participates in a repair process, so that a CPU of the host is prevented from participating in check calculation, and resource occupation is reduced; the repair write operation does not need to transmit user data, and the repair efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of storage device technology, and more specifically to a RAID card device and a data repair method based on the RAID card device. Background Technology

[0002] Traditional block storage employs RAID (Rapid Replication) to protect data reliability, using disk redundancy (mirror redundancy or parity redundancy) to address data integrity issues arising from disk or media failures. However, for data inconsistencies caused by bit flips in the read / write link or silent data alterations on the storage medium, detection is limited to mirrored data comparison or checksum algorithms; repair is impossible because RAID only detects checksum errors, not the location of the data causing the error. To address this, the industry has proposed end-to-end data consistency solutions like PI (Picture-Based Consistency) or DIF (Differentiated Components). These solutions allocate a portion of the storage device to store user data checksums. When the host writes data to the storage device, it calculates the checksum and then writes both the user data and the corresponding checksum together. The block storage device can be an HDD, SSD, or storage array. This solution requires the block storage device to support variable sector lengths, such as 512+8 or 4KB+64 data storage formats. Furthermore, the host system must also support checksum calculation, requiring modifications to the block device driver or upper-layer applications to support the simultaneous generation and transmission of user data and checksums to the storage device.

[0003] In summary, current solutions require storage devices to support DIF functionality, formatting block storage into a special format. Since PI data needs to be stored, this impacts both the performance and capacity of the storage device. Alternatively, the host needs to support DIF functionality, generating PI content and calculating checksums for user data during host write I / O. This consumes host CPU resources and affects host performance. When the host reads data, it also needs to calculate the checksum of the read data and compare it with the read PI content, which also consumes a significant amount of CPU resources. Summary of the Invention

[0004] To overcome the aforementioned technical problems in the prior art, embodiments of the present invention provide a RAID card device and a data repair method based on the RAID card device. By eliminating the need for the host to generate parity block information and transmitting mirror location information through the APPID storage cookie of the protection information (hereinafter referred to as PI), the mirror disk information tracking mechanism is simplified. The host does not need to calculate parity data at the block device layer and only participates in the repair process through the cookie, thereby avoiding the host CPU from participating in the parity calculation and reducing resource consumption. Repair write operations do not require the transmission of user data, improving repair efficiency.

[0005] To achieve the above objectives, embodiments of the present invention provide a RAID card device, comprising: a RAID engine module for processing read and write operations and automatic reconstruction at RAID 1 / 10 levels; a cookie generation module for dynamically generating and filling mirror disk identification information into the APPID field of the protection information field in the read response; a cookie parsing module for extracting mirror disk identification information and switching the read path in the reread request; and a repair execution module for performing mirror disk data synchronization according to host instructions.

[0006] Preferably, the RAID supports hard drives with standard 512B or 4KB sector format.

[0007] Preferably, the cookie generation module and the cookie parsing module use a protected information field to achieve request-response context passing.

[0008] Accordingly, the present invention also provides a data repair method based on a RAID card device, applied to the RAID card device provided by the present invention. The data repair method includes the following steps: S1: When the host initiates a write request, the host sends user data and protection information to the RAID card; when the host initiates a read request, the RAID card receives the read request and performs a read operation to read data from the mirror disk of the RAID group; S2: Returns response data to the host, the response data writing the mirror disk identification information corresponding to the read operation as cookie data into the APPID field of the protection information; S3: When the host detects a data error, the host initiates a reread request carrying the cookie data; S4: The RAID card parses the content of the cookie data, rereads the data through other mirror disks, and returns reread response data to the host; S5: When the host re-verifies and confirms that the reread data is correct, it initiates a repair write request, and the RAID card synchronizes the correct data to the mirror disk.

[0009] Preferably, the protection information in S1 includes a CRC field, an LBA field, and an APPID field; when the host initiates a write request, the host always fills the CRC field with an invalid value, the host always fills the LBA field with an invalid value, and the host leaves the APPID field blank; the format of the invalid value is 0×FFFFFFFF.

[0010] Preferably, the cookie data in S2 is used to identify the physical address of the data source, specifically including any of the following information: (1) the unique number of the currently read mirror disk in the RAID group; (2) the logical mirror group identifier to which the currently read mirror data belongs.

[0011] Preferably, step S3 further includes: the number of times a reread request is initiated is determined based on the number of mirrors in the RAID group; the maximum number of rereads is equal to the number of mirrors minus 1.

[0012] Preferably, S4 specifically includes: the RAID card receiving the reread request; the RAID card parsing the mirror disk identification information in the cookie data; the RAID card sending a reread command to the storage medium; the reread command switching to the other mirror disk to reread the data; using the identification information of the other mirror disk as new cookie data; and the reread response data containing the new cookie data.

[0013] Preferably, the repair write request in step S5 specifically includes: the RAID card synchronizing the correct data to the mirror disk based on the new cookie data; the repair write request supports any of the following three modes: Mode 1: the host only sends a cookie without carrying user data, the RAID card locates the correct mirror disk based on the cookie, and performs data synchronization repair within the RAID group; Mode 2: the host sends complete user data, and the RAID card writes the data to all mirror disks; Mode 3: the host sends complete user data, and the RAID card writes the data to the mirror disk corresponding to the data with the verification error.

[0014] The present invention has at least the following technical effects through the technical solution provided by the present invention: By eliminating the need for the host to generate protection information when initiating normal write requests, the resource consumption of the host CPU due to verification calculations and data processing in traditional DIF schemes is avoided, thus improving host operating efficiency. When the host makes read requests, it does not need to parse the cookie information returned by the RAID card; a reread is only initiated when inconsistencies are found during data verification, reducing the processing logic of the host during normal read and write processes and improving host performance. It does not rely on the CRC checksum within the protection information and can seamlessly integrate with existing file system verification methods (such as EXT4's FSCK tool) without modifying the underlying file system logic, improving compatibility with existing systems. By recording mirror disk information through the cookie mechanism, it can switch to a different mirror disk during rereads, bypassing the previously misread mirror disk. This invention avoids the repair failure problem caused by the inability to locate the error in traditional RAID solutions. During repair write operations, the host can carry only the successfully verified data and cookie information. The RAID card completes data synchronization internally by parsing the cookie, without transmitting complete user data, which greatly improves repair efficiency. The RAID card does not need to save the mirror disk information for each I / O access, thereby reducing the memory usage and logical complexity of the RAID card and lowering hardware design costs. In summary, this invention, through the combined design of "cookie mechanism" and "RAID card-led verification and repair," reduces the burden on the host and storage devices while taking into account compatibility, efficiency, and reliability, and solves the problems of performance loss, hardware dependence, and insufficient repair capabilities in traditional RAID and DIF solutions. Attached Figure Description

[0015] The accompanying drawings are provided to further illustrate embodiments of the present invention and form part of the specification. They are used together with the following detailed description to explain the embodiments of the present invention, but do not constitute a limitation thereof. In the drawings: Figure 1 This is a schematic diagram of the data interaction and processing flow of the storage system based on the RAID card device provided in the embodiments of the present invention; Figure 2 This is a schematic diagram of a RAID card device using a DIF hard drive provided in an embodiment of the present invention; Figure 3 This is a flowchart of a data repair method based on a RAID card provided in an embodiment of the present invention. Detailed Implementation

[0016] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit the scope of the present invention.

[0017] In this invention, the terms "system" and "network" are used interchangeably. "Multiple" refers to two or more; therefore, in this invention, "multiple" can also be understood as "at least two." "And / or" describes 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, or B alone. Additionally, the character " / ", unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, it should be understood that in the description of this invention, terms such as "first" and "second" are used only for descriptive purposes and should not be construed as indicating or implying relative importance or order.

[0018] This invention provides a RAID card device, comprising: a RAID engine module for handling read / write operations and automatic reconstruction at RAID 1 / 10 levels; a cookie generation module for dynamically generating and filling mirror disk identification information into the APPID field of the protection information field in the read response; a cookie parsing module for extracting mirror disk identification information and switching the read path in the reread request; and a repair execution module for performing mirror disk data synchronization according to host instructions. Specifically, the RAID engine module is a RAID algorithm engine responsible for handling RAID read / write data and configuration (supporting RAID0, RAID1, and RAID10 levels). The RAID card device also includes an automatic reconstruction function for RAID1 disk replacement. The RAID card device is equipped with SSD hot-swappable processing. The RAID card device can be combined with various file systems, such as EXT4, BtrFS, and ZFS file systems. Using the FSCK file system repair tool, when processing read operations using RAID1 and RAID10 mirror redundancy algorithms in the RAID engine, the device records the mirror disk information of the current read IO and records it as a cookie in the PI field of the read response, returning it to the host. When the host needs to initiate a reread, it carries this cookie to initiate the read operation, indicating that the read result corresponding to this cookie does not meet the verification requirements. The cookie parsing module parses the cookie, determines the next set of mirror disks for read and write, and records the mirror disk information as a new cookie in the reread response PI and returns it to the host. In this way, it is not necessary to record the mirror disk information of each IO access inside the RAID card, but to have it carried by the IO.

[0019] Furthermore, the RAID card does not require the host to calculate the protection information field checksum, i.e., it does not require the host to calculate the CRC checksum of the PI, and it supports hard drives with standard 512B or 4KB sector format; and the cookie generation module and cookie parsing module do not rely on the local IO status table, and realize the request-response context passing through the protection information field.

[0020] In one embodiment, the RAID card device provided by this invention is applied to data interaction and processing in a storage system, such as... Figure 1 As shown, the top layer is the host layer. The core components of the host layer are the file system and file system repair tool. The file system can be selected from EXT4, BtrFS, and ZFS, and the file system repair tool is FSCK. The data structure consists of user data and PI (Pi). User data is the actual business content to be stored and read / written, with a sector / block size of 4KB / 512B. The PI occupies 64B / 8B of space. The host communicates with the RAID card in the middle layer via NVMe / SATA / SCSI read / write commands. The middle layer is the RAID card layer. The core component of the RAID card layer is the RAID engine, which is the core logical unit for implementing RAID (Redundant Array of Independent Disks) functionality. It is responsible for data striping, parity calculation, and redundancy recovery. Data processing in the RAID card layer includes receiving read / write commands from the host, processing them through the RAID engine, and then sending them to the hard disk layer via NVMe / SATA / SCSI read / write commands. Cookies generated by the cookie generation module are written to the PI, also occupying 64B / 8B of space. The bottom layer is the hard disk layer. The core components of the hard disk layer are multiple physical hard drives, such as... Figure 1 The three physical hard drives shown are the actual hardware carriers for storing data. They receive read and write commands from the RAID card, perform physical read and write operations on the data, and the data is stored in 512-byte sectors or 4-byte blocks. The process logic for the host to initiate a write operation is as follows: the host packages the "user data" + "PI without content" and sends it to the RAID card via NVMe / SATA / SCSI commands. The RAID engine splits and calculates the verification according to the RAID strategy, and then sends it to multiple hard drives for distributed storage via NVMe / SATA / SCSI commands. The process logic for the host to initiate a read operation is as follows: the host issues a read command, the RAID card receives the read command and reads the data from the hard drive, and fills the PI with the mirror disk identification information corresponding to the read operation as a cookie. It then responds with "user data" + "PI written to cookie" to the host. The host file system processes the response and provides it for use by upper-layer services.

[0021] In yet another implementation, such as Figure 2As shown, the top layer is the host layer. The core components of the host layer are the file system and file system repair tools. The file system can be selected from EXT4, BtrFS, and ZFS, and the file system repair tool is FSCK. The data structure is user data, with a sector / block size of 4KB / 512B. The host communicates with the RAID card in the middle layer via NVMe / SATA / SCSI read / write commands. The middle layer is the RAID card layer. The core components of the RAID card layer are the RAID engine and the parity calculation engine, responsible for data striping, parity calculation, and redundancy recovery. Data processing at the RAID card layer includes user data and the PI (Performance Index) obtained by the parity calculation engine. User data and PI data (composed of CRC, LBA, and APPID) are sent to the hard disk layer via NVMe / SATA / SCSI read / write commands. The sector / block size of user data is 4KB / 512B, and the PI data occupies 64B / 8B of space. The bottom layer is the hard disk layer, whose core components are multiple physical hard drives, such as... Figure 2 The three physical hard drives shown are the actual hardware carriers for storing data. They receive read and write commands from the RAID card and perform physical data read and write operations. Specifically, HDDs or SSDs with PI (Pi) functionality are used at the back end of the RAID group. The host's access interface to the RAID block device does not enable DIF (Digital Interference Function). Instead, DIF functionality is implemented within the RAID card. Each time the host performs a write I / O, the RAID card calculates the PI of the data block, which can be achieved using a CRC algorithm. The user data and PI data are then written to the hard drive. Simultaneously, the RAID card can perform background data consistency checks. If data inconsistency is detected, the PI information of the data read from each disk can be checked to determine which disk has the inconsistent data, allowing for repair through mirroring or data verification. The advantage of this approach is its wider applicability; it can be used for all RAID levels and does not require host intervention for verification.

[0022] Please see Figure 3 This invention provides a data repair method based on a RAID card, applied to the RAID card device provided in this invention. The data repair method includes the following steps: S1: When the host initiates a write request, the host sends user data and protection information to the RAID card; When the host initiates a read request, the RAID card receives the read request and performs a read operation to read data from the mirror disk of the RAID group; S2: Return response data to the host, wherein the response data writes the mirror disk identification information corresponding to the read operation as cookie data into the APPID field of the protection information; S3: When the host detects a data error, the host initiates a reread request carrying the cookie data; S4: The RAID card parses the contents of the cookie data, rereads the data through other mirror disks, and returns the reread response data to the host; S5: When the host re-verifies and confirms that the reread data is correct, it initiates a repair write request, and the RAID card synchronizes the correct data to the mirror disk.

[0023] For S1, the current solution is as follows: When the host initiates a write I / O, it needs to perform a CRC calculation on the data to be written and put the calculated CRC checksum into the CRC field of the protection information (hereinafter referred to as PI). The host also needs to fill in the LBA and APPID. Then, the host sends the user data along with the PI to the device, and the device will save the user data and PI to disk together. When the host reads data, it does not calculate the CRC, but it needs to fill in the LBA and APPID. After the device reads the data and PI, it returns a read response to the host. When the host receives the read response, it needs to recalculate the CRC checksum based on the data and compare it with the CRC in the PI returned by the device. If they match, the read is successful; otherwise, the read fails. In addition, the host will also check the LBA and APPID. If they do not match, it will also return a read failure. In this embodiment of the invention, the RAID card is configured to support RAID1 / 10 mirrored redundancy levels, providing the host with a read / write block device interface. When the host initiates a normal write I / O, the host sends user data and protection information (hereinafter referred to as PI), which is directly written to the mirror disk by the RAID card. Specifically, the PI includes a CRC field, an LBA field, and an APPID field. When the host initiates a write I / O, the host fills the CRC and LBA fields of the PI with invalid values ​​in the format 0xFFFFFFFF. The APPID field in the PI is left blank, thereby reducing the burden of host verification calculation and improving host operating efficiency. Furthermore, when the host initiates a normal read I / O, the RAID card receives the read I / O request sent by the host and sends a read request to the RAID1 / 10 member disk, performs the read I / O operation, reads data from the mirror disk of the RAID group, and then executes S2.

[0024] In this embodiment of the invention, for S2, when returning response data to the host after completing the data reading, the mirror disk identification information corresponding to the read operation is written as cookie data into the APPID field of the PI in the response data. The response data returned to the host includes data and the PI written as cookie. Specifically, the cookie data is used to identify the physical address of the data source. The cookie data specifically includes any of the following information (1) and (2), where the content of the sequence number (1) is: the unique number of the currently read mirror disk in the RAID group, i.e., the mirror disk ID; the content of the sequence number (2) is: the logical mirror group identifier to which the currently read mirror data belongs, i.e., the mirror group ID; the format of the PI written as cookie returned to the host is: the CRC field is filled with 0×FFFFFFFF (indicating that the host does not need to calculate the check code), the LBA field is filled with 0×FFFFFFFF (indicating that the host does not need to fill in the logical block address), and the APPID field is filled with cookie (used to record the position of the member disk in the RAID group). Then, S3 is executed.

[0025] Furthermore, for S3, after the host receives the returned response data, it does not need to parse it or check the APPID field, meaning it does not need to check the cookie data. The host performs data verification, which is done using methods that do not rely on the PI's internal CRC checksum. For example, for a file system, it compares the metadata consistency in the inode; for BTRFS, it calculates the checksum of the user data itself. These methods differ from the block device layer's verification scheme. When the host finds that the data or metadata is inconsistent, it initiates a reread request, i.e., executes S4. Furthermore, the number of reread requests initiated by the host is determined by the number of mirrors in the RAID group. The maximum number of rereads is equal to the number of mirrors in the RAID group minus 1. For example, if the number of mirrors in the RAID group is 2, the host is allowed to reread once; if the number of mirrors is 3, the host is allowed to reread a maximum of 2 times.

[0026] In this embodiment of the invention, for S4, the host initiates a reread request, filling the APPID field content from the response data received by the host into the reread request, that is, the APPID field of the reread request PI is filled with a cookie; the RAID card receives the reread request, and the RAID card parses the cookie filled in the APPID field of the reread request PI, specifically parsing the mirror disk identification information in the cookie data, such as parsing the mirror disk ID or mirror group ID information in the cookie data. After parsing, the RAID card sends a reread command to the storage medium. This reread command will bypass the previous mirror disk and reread the data, that is, the reread command will select another mirror disk to reread the data. The other mirror disk is any mirror disk other than the mirror disk for reading IO. After rereading the data, the reread response data is returned to the host. Specifically, the reread response data includes data and new cookie data, which is the identification information of the other mirror disk; after receiving the reread response data, the host executes S5.

[0027] In this embodiment of the invention, for S5, after receiving the reread response data, the host will perform verification again. If the host succeeds in verifying again, the reread is successful. At this time, the host can initiate a repair write request, adding the successfully verified data and the failed cookie to the RAID card. The RAID card will synchronize the correct data to the faulty mirror disk. Specifically, the RAID card synchronizes the correct data to the faulty mirror disk based on the new cookie data. The repair write operation can put the cookie data in the PI's APPID, without carrying user data. After the device parses the cookie data and knows the mirror disk and mirror group where the correct data is located, it can perform the data synchronization repair operation in the device. This avoids data transfer between the host and the device. In summary, the repair write request supports any of the following three modes: Mode 1: The host only sends a cookie without carrying user data. The RAID card locates the correct mirror disk based on the cookie and performs data synchronization repair within the RAID group. Mode 2: The host sends complete user data. The RAID card writes the data to all mirror disks. That is, the host's repair write operation can be performed like a normal write IO without filling in cookie data. In this case, all mirror groups of the RAID card are written with data, and the repair operation is completed at the same time. Mode 3: The host sends complete user data. The RAID card writes the data to the mirror disk corresponding to the error detected during the previous data read.

[0028] In one implementation, the host initiates a normal read / write process. First, the host sends a 4KB data write request to the RAID card to transmit user data. The host does not need to fill in the PI content; that is, the PI information it carries is blank. Next, the RAID card writes the data to disks 0 and 1 of the RAID1 mirror group. Then, the host initiates a read request, and the RAID card reads data from disk 0, writes "0" (this is cookie data) to the APPID field of the PI, and returns "data + PI" to the host. The host directly uses the data after receiving it without parsing the cookie. In another implementation, when the host detects data inconsistency and needs to repair it, the host first discovers the data inconsistency through BTRFS verification and extracts the cookie "0" returned by the last read operation. Then, the host sends a reread request with cookie "0". The RAID card then parses the request, bypasses disk 0, and switches to read data from disk 1, returning a new cookie "1" to the host. The host then verifies that the data on disk 1 is correct and initiates a repair write request, carrying cookie "0". Finally, the RAID card parses the request and synchronizes the correct data from disk 1 to disk 0, completing the repair.

[0029] The RAID card device and data repair method based on the RAID card device provided by this invention have the following beneficial effects: 1. Reduced host performance consumption: The host does not need to calculate checksums or process PI data, and the CPU resource consumption during normal read and write processes is significantly reduced, solving the host load problem of traditional DIF solutions; 2. Enhanced hardware compatibility: No storage device is required to support DIF function; ordinary HDDs and SDDs formatted with 512B or 4KB can be used directly, reducing hardware costs and expanding applicable scenarios. 3. Improve repair efficiency: Accurately locate faulty image disks through cookies to avoid blind retries; repair write operations do not require the transfer of user data, and only realize intra-device synchronization through cookies, reducing data transfer overhead; 4. Compatible with existing file systems: It can seamlessly cooperate with file systems with built-in verification mechanisms such as EXT4 (FSCK), BTRFS, and ZFS without modifying the underlying file system logic; 5. Simplify RAID card design: No need to internally record IO access status; image information is tracked through cookies, reducing memory usage and logical complexity, and lowering hardware design costs.

[0030] The optional embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the embodiments of the present invention are not limited to the specific details in the above embodiments. Within the scope of the technical concept of the embodiments of the present invention, various simple modifications can be made to the technical solutions of the embodiments of the present invention, and these simple modifications all fall within the protection scope of the embodiments of the present invention.

[0031] It should also be noted that the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, the embodiments of the present invention will not describe the various possible combinations separately.

[0032] Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a microcontroller, chip, or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0033] Furthermore, various different implementations of the present invention can be combined arbitrarily, as long as they do not violate the spirit of the present invention, they should also be regarded as the content disclosed in the present invention.

Claims

1. A RAID card device, characterized in that, include: RAID engine module, used to handle read and write operations and automatic reconstruction at RAID 1 / 10 levels; The Cookie generation module dynamically generates and populates the image disk identification information into the APPID field of the protection information field in the read response; The Cookie parsing module extracts the image disk identification information and switches the read path in the reread request; Repair the execution module to perform image disk data synchronization according to host instructions.

2. The RAID card device according to claim 1, characterized in that, The RAID supports hard drives with standard 512B or 4KB sector format.

3. The RAID card device according to claim 2, characterized in that, The cookie generation module and the cookie parsing module use protected information fields to achieve request-response context passing.

4. A data repair method based on a RAID card device, characterized in that, The data repair method for the RAID card device according to any one of claims 1-3 includes the following steps: S1: When the host initiates a write request, the host sends user data and protection information to the RAID card; When the host initiates a read request, the RAID card receives the read request and performs a read operation to read data from the mirror disk of the RAID group; S2: Return response data to the host, wherein the response data writes the mirror disk identification information corresponding to the read operation as cookie data into the APPID field of the protection information; S3: When the host detects a data error, the host initiates a reread request carrying the cookie data; S4: The RAID card parses the contents of the cookie data, rereads the data through other mirror disks, and returns the reread response data to the host; S5: When the host re-verifies and confirms that the reread data is correct, it initiates a repair write request, and the RAID card synchronizes the correct data to the mirror disk.

5. The data repair method according to claim 4, characterized in that, The protection information in S1 includes a CRC field, an LBA field, and an APPID field; When the host initiates a write request, the host always fills the CRC field with an invalid value, the host always fills the LBA field with an invalid value, and the host leaves the APPID field blank. The format of the invalid value is 0xFFFFFFFF.

6. The data repair method according to claim 4, characterized in that, The cookie data in S2 is used to identify the physical address from which the data originates, and specifically includes any of the following information: (1) The unique number of the currently read mirror disk in the RAID group; (2) The identifier of the logical image group to which the currently read image data belongs.

7. The data repair method according to claim 4, characterized in that, S3 further includes: The number of times a reread request is initiated depends on the number of mirrors in the RAID group; The maximum number of rereads is equal to the number of images minus 1.

8. The data repair method according to claim 4, characterized in that, S4 specifically includes: The RAID card receives the reread request and parses the mirror disk identification information in the cookie data; The RAID card sends a reread command to the storage medium, which switches to the other mirror disk to reread the data. The identification information of the other mirror disks is used as new cookie data, and the reread response data includes the new cookie data.

9. The data repair method according to claim 8, characterized in that, Initiating a repair write request in S5 specifically includes: The RAID card synchronizes the correct data to the mirror disk based on the new cookie data; The repair write request supports any of the following three modes: Mode 1: The host only sends cookies without carrying user data. The RAID card locates the correct mirror disk based on the cookie and performs data synchronization and repair within the RAID group. Mode 2: The host sends complete user data, and the RAID card writes the data to all mirror disks; Mode 3: The host sends complete user data, and the RAID card writes the data to the mirror disk corresponding to the data with the verification error.

Images