Solid state disk block raid write model optimization method and device and computer equipment

Abstract

The application relates to a solid state disk BlockRAID write model optimization method and device, computer equipment and a storage medium, wherein the method comprises the following steps: in the case of a plurality of physical block groups forming a RAID group, only one group of physical blocks is allocated for data writing each time; whether the current writing is the last group of physical blocks in the RAID group is judged during the data writing process; if the current writing is not the last group of physical blocks in the RAID group, no parity is generated during the data writing process; if the current writing is the last group of physical blocks in the RAID group, corresponding data on other groups in the strip is read before the corresponding RAID strip is written to initialize the parity; for the last group of physical blocks in the RAID group, the parity is calculated in real time when the corresponding RAID strip is written, and the parity is written to the NAND after the strip writing is completed. The application reduces the requirement of the system to reserve physical blocks during data writing, improves the tolerance of bad blocks and the product yield.

Description

Technical Field

[0001] This invention relates to the field of solid-state drive (SSD) technology, and in particular to a method, apparatus, computer device, and storage medium for optimizing the Block RAID write model of a solid-state drive. Background Technology

[0002] SSDs (Solid State Drives) have been widely used in various applications and are gradually replacing traditional HDDs in the PC market, providing users with a better experience in terms of reliability and performance.

[0003] Due to the characteristics of NAND flash memory, the data within it is at risk of corruption. To ensure data reliability, RAID is typically configured within an SSD for data protection. Depending on the physical structure of the SSD, RAID can be configured as Page RAID, Block RAID, Die RAID, etc. Different types of RAID offer varying levels of protection, each designed to combat different NAND failure scenarios. Among them, Block RAID is one of the most widely used models. It can tolerate the failure of a single physical block, providing strong data protection capabilities, while offering moderate overprovisioning (OP) requirements and costs.

[0004] However, in typical N+1 Block RAID configurations, N is usually a large value, such as 31. Since the number of internal DIEs in a typical SSD is limited (e.g., 4 or 8), a RAID group needs to contain multiple physical blocks within a single DIE. Inside the SSD, when writing data, blank physical blocks need to be allocated for the write operation. To ensure availability, the system needs to reserve corresponding blank physical blocks during runtime. Due to the RAID write strategy, multiple sets of physical blocks are needed for a single allocation, resulting in a larger number of reserved blank physical blocks. This, in turn, reduces the tolerable number of bad blocks in the reserved area, impacting SSD yield. Summary of the Invention

[0005] Therefore, it is necessary to provide a method, apparatus, computer device, and storage medium for optimizing the Block RAID write model of solid-state drives in response to the above-mentioned technical problems.

[0006] A method for optimizing the write model of a solid-state drive (SSD) Block RAID, the method comprising:

[0007] In a scenario where multiple physical blocks form a RAID Group, only one physical block is allocated for data writing at a time;

[0008] During the data writing process, determine whether the current write is the last physical block in the RAID Group;

[0009] If it is not the last physical block in the RAID Group, no Parity will be generated during the data writing process;

[0010] If it is the last physical block in the RAID Group, then before writing the corresponding RAID stripe, read the corresponding data from other groups in the stripe to initialize the Parity;

[0011] For the last group of physical blocks within the RAID Group, the Parity is calculated in real time during the corresponding RAID stripe write and written to the NAND after the stripe write is completed.

[0012] In one embodiment, the step of determining whether the currently written data is the last physical block in the RAID Group further includes:

[0013] If it is the last physical block in the RAID Group, mark the corresponding identifier as 1; otherwise, mark the corresponding identifier as 0.

[0014] In one embodiment, after the step of marking the corresponding identifier as 1 if it is the last group of physical blocks in the RAID Group, and otherwise marking the corresponding identifier as 0, the method further includes:

[0015] Check if the physical block's corresponding identifier is 1. If it is, continue to check if it is the first write to the corresponding stripe within the current physical block.

[0016] If it is the first write, the data in other physical blocks in the stripe is read, XORed, and then written to the RAIDParity Buffer.

[0017] In one embodiment, after the step of continuing to determine whether it is the first write to the corresponding stripe within the current physical block, the method further includes:

[0018] If it is not the first write, the data to be written is XORed with the data in the RAID ParityBuffer and then written back to the RAID ParityBuffer.

[0019] A solid-state drive (SSD) Block RAID write model optimization device, the device comprising:

[0020] The allocation module is used in scenarios where multiple physical blocks form a RAID Group, to allocate only one group of physical blocks for data writing at a time;

[0021] The first judgment module is used to determine whether the data being written is the last physical block in the RAID Group during the data writing process.

[0022] A write module, wherein if the data is not the last physical block in the RAID Group, no Parity is generated during the data write process;

[0023] An initialization module is used to read the corresponding data from other groups within a RAID group to initialize Parity before writing the corresponding RAID stripe if it is the last physical block in the RAID group.

[0024] The calculation module is used to calculate the parity in real time for the last group of physical blocks in the RAID Group when the corresponding RAID stripe is written, and write it to NAND after the stripe writing is completed.

[0025] In one embodiment, the first determining module is further configured to:

[0026] If it is the last physical block in the RAID Group, mark the corresponding identifier as 1; otherwise, mark the corresponding identifier as 0.

[0027] In one embodiment, the device further includes a second determining module, the second determining module being used to:

[0028] Check if the physical block's corresponding identifier is 1. If it is, continue to check if it is the first write to the corresponding stripe within the current physical block.

[0029] If it is the first write, the data in other physical blocks in the stripe is read, XORed, and then written to the RAIDParity Buffer.

[0030] In one embodiment, the second determining module is further configured to:

[0031] If it is not the first write, the data to be written is XORed with the data in the RAID ParityBuffer and then written back to the RAID ParityBuffer.

[0032] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the methods described above.

[0033] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the above methods.

[0034] The aforementioned SSD Block RAID write model optimization method, apparatus, computer equipment, and storage medium, for scenarios where multiple physical blocks form a RAID Group, allocate only one physical block for data writing at a time; for physical blocks that are not the last group within the RAID Group, no parity is generated during the write process; for the last group of physical blocks within the RAID Group, before writing the corresponding RAID stripe, the corresponding data on other groups within the stripe is read to initialize the parity; for the last group of physical blocks within the RAID Group, the parity is calculated in real time during the corresponding RAID stripe write and written to the NAND after the stripe ends. This invention, while ensuring Block RAID protection capabilities, reduces the system's need to retain physical blocks during data writing, improving bad block tolerance and product yield. Attached Figure Description

[0035] Figure 1 A schematic diagram of the existing SSD Block RAID write model;

[0036] Figure 2 A schematic diagram of the partitioning of physical blocks within an existing SSD;

[0037] Figure 3 This is a flowchart illustrating a method for optimizing the write model of a solid-state drive (SSD) Block RAID in one embodiment.

[0038] Figure 4 This is a schematic diagram of an optimized SSD Block RAID write model in one embodiment;

[0039] Figure 5 This is a flowchart illustrating the solid-state drive Block RAID write model optimization method in another embodiment;

[0040] Figure 6 This is a structural block diagram of a solid-state drive Block RAID write model optimization device in one embodiment;

[0041] Figure 7 This is a structural block diagram of a solid-state drive Block RAID write model optimization device in another embodiment;

[0042] Figure 8 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0044] like Figure 1 The diagram shown illustrates an existing SSD Block RAID write model. For ease of explanation, it uses 4 DIEs, with Block RAID having a 7+1 configuration (7 user data entries and 1 parity data entry within each RAID Stripe).

[0045] A RAID Group (correlated physical blocks) contains two sets of physical blocks, with each DIE containing two physical blocks, denoted as Block X / Y for ease of explanation. Pages with the same type within each physical block of a RAID Group form a RAID Stripe. During writing, data is written sequentially to each page of RAID Stripe 0, then to each page of RAID Stripe 1, and so on. Taking writing to Stripe 0 as an example, data is written sequentially to Data_0_0 / Data_0_1….Data_0_6, and parity data is generated in real-time during the writing process (typically using an XOR algorithm); after the user data is written, Parity_0 is written to DIE 3, Block Y, Page 0.

[0046] During this process, the generation of RAID Stripe 0 and Parity writing must be completed first, thus requiring interleaved writing of the RAID Group (Block X / Y). To ensure that there are always available blank physical blocks in the system, one or more RAID Group physical blocks need to be reserved at runtime for data writing. However, the number of available physical blocks in an SSD is limited. The more blank physical blocks that need to be reserved, the greater the operation (OP) required, and consequently, the fewer bad blocks it can tolerate. This necessitates stricter control over bad block thresholds during SSD production, reducing yield. Furthermore, the reduced tolerance for bad blocks at runtime can cause the SSD to become unusable prematurely due to an increase in bad blocks, impacting its lifespan.

[0047] Based on this, this solution proposes an optimization method for the Block RAID write model of solid-state drives, which aims to keep only a single group required when allocating physical blocks, thereby effectively reducing the threshold of the reserved area - blank blocks at runtime.

[0048] like Figure 2The diagram showing the partitioning of the internal physical blocks of the SSD includes: System Data Area, which stores SSD system management data, such as firmware / mapping tables / metadata / bad block tables, etc.; User Data Area, which stores user data; Reserved Area - blank physical blocks, used to allocate space for writing user data or for garbage collection to release available physical blocks; Reserved Area - bad blocks, bad physical blocks generated at the factory or during operation, which need to be isolated and cannot be used for data writing.

[0049] During runtime, the system data area is occupied by system data, and the bad block area is unusable. When the disk is fully written, the user data area is also fully loaded. If the host writes new data at this time, it must allocate blank physical blocks from the reserved area - blank physical blocks for the new data to be written. When some data in the user data area becomes invalid, garbage collection can be performed using the reserved area - blank physical blocks to release the physical space occupied by invalid data in the user data area.

[0050] In one embodiment, such as Figure 3 As shown, a method for optimizing the write model of a solid-state drive (SSD) Block RAID is provided, the method including:

[0051] Step 302: In a scenario where multiple physical blocks form a RAID Group, only one physical block is allocated for data writing at a time.

[0052] Step 304: During the data writing process, determine whether the currently written data is the last physical block in the RAID Group;

[0053] Step 306: If it is not the last physical block in the RAID Group, then no Parity will be generated during the data writing process;

[0054] Step 308: If it is the last physical block in the RAID Group, then before writing the corresponding RAID stripe, read the corresponding data on other groups in the stripe to initialize Parity;

[0055] Step 310: For the last group of physical blocks in the RAID Group, the Parity is calculated in real time during the corresponding RAID stripe writing and written to NAND after the stripe writing is completed.

[0056] This embodiment provides a method for optimizing the write model of a solid-state drive (SSD) Block RAID. Specifically, please refer to... Figure 4 The optimized SSD Block RAID write model shown is illustrated using a 7+1 Block RAID configuration with 4 DIEs as an example for clarity:

[0057] When writing data requires allocating a blank physical block, only one set of blank physical blocks (Block X) is allocated initially. User data is then written sequentially to the physical pages of Block X in each DIE. During this process, no Parity data needs to be generated; the above process is illustrated in Stage 1.

[0058] Next, once Block X is full, only one set of blank physical blocks (Block Y) is allocated again. If Block Y is identified as the last set of blank physical blocks in the current RAID Group, then before each stripe is written, the data in the physical blocks preceding that stripe is read and XORed to generate Parity data.

[0059] Then, as shown in Stage 2, read the user data of Page 0 of DIE 0-3 in BlockX in sequence, perform XOR, and store the result in Stripe 0ParityBuffer.

[0060] Then, as shown in Stage 3, the user data to be written is sequentially written to positions Data_0_4 / Data_0_5 / Data_0_6. During the writing process, the corresponding data is XORed with the data in Stripe 0Parity Buffer, and the result is stored in ParityBuffer.

[0061] Finally, after writing all user data to Stripe 0, write the Stripe 0 Parity Buffer data to DIE 3BlockYPage 0: Parity_0, and repeat the above steps to complete the writing of other stripe data.

[0062] In this embodiment, for scenarios where multiple physical blocks form a RAID Group, only one physical block is allocated for data writing at a time. For physical blocks that are not the last group within the RAID Group, no parity is generated during the writing process. For the last group of physical blocks within the RAID Group, before writing the corresponding RAID stripe, the corresponding data from other groups within the stripe is read to initialize the parity. For the last group of physical blocks within the RAID Group, the parity is calculated in real-time during the writing of the corresponding RAID stripe and written to the NAND after the stripe ends. This solution, while ensuring Block RAD protection capabilities, reduces the system's need to retain physical blocks during data writing, improving bad block tolerance and product yield.

[0063] In one embodiment, a method for optimizing the write model of a solid-state drive (SSD) Block RAID is provided. The step of determining whether the currently written data is the last physical block within the RAID Group further includes:

[0064] If it is the last physical block in the RAID Group, mark the corresponding identifier as 1; otherwise, mark the corresponding identifier as 0.

[0065] Check if the physical block's corresponding identifier is 1. If it is, continue to check if it is the first write to the corresponding stripe within the current physical block.

[0066] If it is the first write, the data in other physical blocks in the stripe is read, XORed, and then written to the RAIDParity Buffer;

[0067] If it is not the first write, the data to be written is XORed with the data in the RAID ParityBuffer and then written back to the RAID ParityBuffer.

[0068] In this embodiment, a method for optimizing the write model of a solid-state drive (SSD) Block RAID is provided, referring to... Figure 5 As shown, the specific execution steps are as follows:

[0069] Step 5.1: Write data to the SSD.

[0070] Step 5.2: Determine whether physical blocks need to be allocated?

[0071] If so, proceed to step 5.3;

[0072] If not, proceed to step 5.7.

[0073] Step 5.3: Allocate a set of blank physical blocks.

[0074] Step 5.4: Determine if this is the last group of physical blocks in the current RAID Group?

[0075] If so, proceed to step 5.5;

[0076] If not, proceed to step 5.6.

[0077] Step 5.5: Set raid_group_last_block to 1, then proceed to step 5.7.

[0078] Step 5.6: Set raid_group_last_block to 0.

[0079] Step 5.7: Determine if raid_group_last_block is 1?

[0080] If so, proceed to step 5.8;

[0081] If not, proceed to step 5.11.

[0082] Step 5.8: Is this the first write to the corresponding stripe within the current physical block (Stripe X)?

[0083] If so, proceed to step 5.9;

[0084] If not, proceed to step 5.10.

[0085] Step 5.9: Read the data from other physical blocks of Stripe X, XOR it, and write it to the RAID Parity Buffer.

[0086] Step 5.10: Perform an XOR operation between the data to be written and the data in the ParityBuffer, and then write it back to the ParityBuffer.

[0087] Step 5.11: Write user data to NAND.

[0088] Step 5.12: Determine if this is the last piece of user data within this strip?

[0089] If so, proceed to step 5.13;

[0090] If not, proceed to step 5.1.

[0091] Step 5.13: Write the Parity data to NAND, then skip to step 5.1.

[0092] In this embodiment, by optimizing the write model of Block RAID, only a single group is needed when allocating physical blocks, thereby effectively reducing the threshold of reserved area-blank blocks at runtime, thus improving the tolerance for the number of reserved area-bad blocks and improving SSD yield.

[0093] It should be understood that, although Figures 1-5 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figures 1-5 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0094] In one embodiment, such as Figure 6 As shown, a solid-state drive Block RAID write model optimization device 600 is provided, the device comprising:

[0095] The allocation module 601 is used to allocate only one set of physical blocks for data writing at a time in a scenario where multiple sets of physical blocks form a RAID Group.

[0096] The first judgment module 602 is used to determine whether the currently written data is the last physical block in the RAID Group during the data writing process.

[0097] The write module 603 is configured to not generate a Parity during the data write process if the data is not the last physical block in the RAID Group.

[0098] Initialization module 604 is used to read the corresponding data on other groups in the stripe to initialize Parity before writing the corresponding RAID stripe if it is the last physical block in the RAID Group.

[0099] The calculation module 605 is used to calculate the parity in real time for the last group of physical blocks in the RAID Group when the corresponding RAID stripe is written, and write it to the NAND after the stripe writing is completed.

[0100] In one embodiment, the first determining module 602 is further configured to:

[0101] If it is the last physical block in the RAID Group, mark the corresponding identifier as 1; otherwise, mark the corresponding identifier as 0.

[0102] In one embodiment, such as Figure 7 As shown, a solid-state drive Block RAID write model optimization device 600 is provided. This device further includes a second judgment module 606, which is used for:

[0103] Check if the physical block's corresponding identifier is 1. If it is, continue to check if it is the first write to the corresponding stripe within the current physical block.

[0104] If it is the first write, the data in other physical blocks in the stripe is read, XORed, and then written to the RAIDParity Buffer.

[0105] In one embodiment, the second determining module 606 is further configured to:

[0106] If it is not the first write, the data to be written is XORed with the data in the RAID ParityBuffer and then written back to the RAID ParityBuffer.

[0107] For specific limitations regarding the SSD Block RAID write model optimization device, please refer to the limitations of the SSD Block RAID write model optimization method mentioned above, which will not be repeated here.

[0108] In one embodiment, a computer device is provided, the internal structure of which can be shown as follows: Figure 8 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a solid-state drive (SSD) Block RAID write model optimization method.

[0109] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0110] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps in the various method embodiments described above.

[0111] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the various method embodiments described above.

[0112] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0113] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0114] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for optimizing the write model of a solid-state drive (SSD) BlockRAID, the method comprising: In scenarios where multiple physical blocks form a RAIDGroup, only one set of physical blocks is allocated for data writing at a time; During the data writing process, determine whether the current write is the last physical block in the RAIDGroup; If it is not the last physical block in the RAIDGroup, no Parity will be generated during the data writing process; If it is the last physical block in the RAIDGroup, then before writing the corresponding RAID stripe, read the corresponding data from other groups in the stripe to initialize the Parity; For the last physical block in the RAIDGroup, the Parity is calculated in real time during the corresponding RAID stripe writing and written to NAND after the stripe writing is completed.

2. The solid-state drive BlockRAID write model optimization method according to claim 1, characterized in that, The step of determining whether the currently written data is the last physical block in the RAIDGroup during the data writing process also includes: If it is the last physical block in the RAIDGroup, mark the corresponding identifier as 1; otherwise, mark the corresponding identifier as 0.

3. The solid-state drive BlockRAID write model optimization method according to claim 2, characterized in that, Following the step of marking the corresponding identifier as 1 if it is the last physical block in the RAIDGroup, and otherwise marking the corresponding identifier as 0, the method further includes: Check if the physical block's corresponding identifier is 1. If it is, continue to check if it is the first write to the corresponding stripe within the current physical block. If it is the first write, the data in other physical blocks in the stripe is read, XORed, and then written to the RAIDParityBuffer.

4. The solid-state drive BlockRAID write model optimization method according to claim 3, characterized in that, Following the step of determining whether it is the first write to the corresponding stripe within the current physical block, the method further includes: If this is not the first write operation, the data to be written is XORed with the data in the RAIDParityBuffer and then written back to the RAIDParityBuffer.

5. A solid-state drive BlockRAID write model optimization device, characterized in that, The device includes: The allocation module is used in scenarios where multiple physical blocks form a RAIDGroup, to allocate only one set of physical blocks for data writing at a time; The first judgment module is used to determine whether the data being written is the last physical block in the RAIDGroup during the data writing process. A write module, wherein if the data is not the last physical block in the RAIDGroup, no Parity is generated during the data write process; An initialization module is used to read the corresponding data from other groups within a RAID stripe to initialize Parity before writing the corresponding RAID stripe if it is the last physical block in the RAID Group. The calculation module is used to calculate the Parity in real time for the last group of physical blocks in the RAIDGroup during the corresponding RAID stripe writing and write it to NAND after the stripe writing is completed.

6. The solid-state drive BlockRAID write model optimization device according to claim 5, characterized in that, The first judgment module is also used for: If it is the last physical block in the RAIDGroup, mark the corresponding identifier as 1; otherwise, mark the corresponding identifier as 0.

7. The solid-state drive BlockRAID write model optimization device according to claim 6, characterized in that, The device further includes a second determination module, the second determination module being used for: Check if the physical block's corresponding identifier is 1. If it is, check if it is the first write to the corresponding stripe within the current physical block. If it is the first write, read the data from other physical blocks in the stripe, XOR it, and then write it to the RAIDParityBuffer.

8. The solid-state drive BlockRAID write model optimization device according to claim 7, characterized in that, The second judgment module is also used for: If this is not the first write operation, the data to be written is XORed with the data in the RAIDParityBuffer and then written back to the RAIDParityBuffer.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 4.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.

Images