Method and apparatus for local dynamic reconstruction of cross-grain raid stripe based on logical-physical mapping bitmap index

Abstract

The application discloses a cross-grain RAID strip local dynamic reconstruction method and device based on a logical-physical mapping bitmap index, comprising the following steps: first, a logical-physical mapping bitmap index for marking the validity of each sector data in a RAID strip is maintained in a flash translation layer (FTL) of a solid state disk; when a target grain failure is detected, the bitmap index is called by the system for analysis; then, according to the marking of the bitmap index, the effective data area on other healthy grains in the corresponding strip is accurately scheduled to perform local reading and XOR calculation, and all invalid data areas are actively skipped to reconstruct the effective data in the failed grain; finally, the recovered discrete effective data is dynamically aggregated into a new complete strip and then written into a standby physical space. Through the application, internal read amplification and write amplification in the reconstruction process can be significantly reduced, the failure recovery time is shortened, and the performance stability of the SSD in the degradation mode is ensured.

Description

Technical Field

[0001] This invention relates to enterprise-level solid-state storage controller technology, and more specifically, to a method and apparatus for local dynamic reconstruction of cross-chip RAID stripes based on logical-physical mapping bitmap indexes. Background Technology

[0002] With the rapid development of big data, cloud computing, and artificial intelligence technologies, the demands for data storage density, speed, and reliability are increasing daily. Solid-state drives (SSDs), especially enterprise-grade SSDs using NAND flash memory as the storage medium, have become critical infrastructure in data centers and high-performance computing due to their high performance and low latency. In enterprise applications, data security and business continuity are paramount; therefore, improving the fault tolerance and recovery efficiency of SSDs in the face of storage media failures has become one of the core technical challenges in this field. To ensure that data is not lost when one or more flash memory physical cells fail, modern enterprise-grade SSD controllers generally integrate multi-die redundant array (RAID) protection mechanisms internally.

[0003] However, the existing internal RAID reconstruction technology of enterprise-grade SSDs cannot effectively utilize data validity information, resulting in unnecessary internal I / O overhead and performance penalties. This causes the SSD to be in a state of severely degraded Quality of Service (QoS) for a long time during the fault degradation period, making it difficult to meet the stringent requirements of modern mission-critical businesses for high availability and high performance. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a method and apparatus for local dynamic reconstruction of cross-chip RAID stripes based on logical-physical mapping bitmap index, so as to overcome the defects of existing solid-state drives when performing internal data reconstruction, such as high reconstruction read / write amplification, long recovery time and serious degradation of service quality due to lack of awareness of data validity.

[0005] To achieve the above objectives, one aspect of the present invention provides a method for local dynamic reconstruction of cross-chip RAID stripes based on a logical-physical mapping bitmap index. This method is applied to a solid-state drive (SSD) containing multiple flash memory chips and configured with a flash translation layer. The method includes the following steps: First, obtaining the logical-physical mapping bitmap index recorded in the flash translation layer, which characterizes the validity of data in the multiple flash memory chips; next, when a fault is detected in the target chip, resolving the physical address corresponding to the valid data stored in the target chip based on the logical-physical mapping bitmap index; subsequently, according to the physical address corresponding to the valid data, controlling the SSD to perform local data reading from other healthy chips within the same RAID stripe as the target chip to obtain the data required for reconstruction, and skipping data reading from the other healthy chips corresponding to the physical addresses of invalid data in the target chip; then, using the data required for reconstruction, recovering the valid data in the target chip to obtain recovered data; finally, dynamically aggregating the recovered data to form a new data stripe, and writing the new data stripe into a spare physical space.

[0006] Specifically, the logical-physical mapping bitmap index is generated and maintained in real time by the flash memory translation layer during the logical-to-physical address mapping process. It tracks the data write, update, or erase status of each physical storage unit at the data page or data sector level. This fine-grained status tracking ensures that the bitmap index accurately reflects the true data validity distribution of the underlying physical storage space, providing a reliable data foundation for subsequent precise reconstruction.

[0007] Furthermore, the step of skipping the reading of invalid data areas is particularly crucial during the reconstruction process. This step is specifically implemented as follows: when generating the physical read instruction sequence for the reconstruction task, the solid-state drive's control unit pre-determines whether the marker corresponding to a target physical address in the logical-physical mapping bitmap index is invalid. If the query result confirms that the marker is invalid, indicating that the data stored at that physical address is outdated or useless, the control unit will actively suppress or prevent the generation and sending of physical read instructions to the physical address corresponding to the target physical address in all other healthy dies within the same RAID stripe. In this way, the reading path to invalid data is directly cut off at the hardware instruction level, achieving precise localized reconstruction.

[0008] Preferably, the step of dynamically aggregating the recovered data aims to avoid write amplification and storage fragmentation during the reconstruction process. This step specifically includes: temporarily storing the typically discrete, valid recovered data, recovered through methods such as XOR calculations, in a high-speed data buffer unit located within the solid-state drive's internal controller; simultaneously, a monitoring unit continuously monitors the amount of recovered data temporarily stored in this buffer unit. When the accumulated data volume reaches a pre-set physical block write threshold (e.g., the size of a complete physical block), the integration controller integrates and reorders all temporarily stored recovered data in the buffer unit, and the parity generation unit calculates and appends new parity data to this integrated data. Ultimately, this integrated data, together with the new parity data, constitutes a new, structurally complete data stripe free of invalid data, preparing for subsequent write operations.

[0009] Optionally, to optimize the SSD's responsiveness to host I / O requests during degradation and reconstruction, the method may further include a concurrent conflict handling mechanism. During the recovery of valid data in the target die, if the SSD receives a write request from the host for a specific logical address on the target die, and a query of the bitmap index reveals that the original physical address of that logical address is marked as valid (i.e., awaiting recovery), the system will take the following optimization measures: prioritize processing the host write request, directly write the new data it carries to a new, healthy physical space, and immediately update the logical-physical address mapping in the flash translation layer so that the logical address points to this new physical address. Simultaneously, the system will forcibly update the marking of the original physical address corresponding to that logical address in the bitmap index to "invalid." This update action will notify the reconstruction engine to automatically suspend the recovery operation for that original physical address, thereby avoiding invalid recovery work and ensuring low-latency completion of the host write operation.

[0010] To achieve the above objectives, another aspect of the present invention provides a cross-chip RAID stripe local dynamic reconstruction apparatus based on a logical-physical mapping bitmap index. This apparatus is also applied to solid-state drives comprising multiple flash memory chips and configured with a flash translation layer. The apparatus includes: an index acquisition module, used to acquire a logical-physical mapping bitmap index recorded in the flash translation layer, which characterizes the validity of data in the multiple flash memory chips;

[0011] The fault analysis module is used to parse out the physical address corresponding to the data marked as valid stored in the target die based on the logical-physical mapping bitmap index when a fault is detected in the target die.

[0012] The scheduling and reconstruction module is used to control the solid-state drive (SSD) to perform partial data reading from other healthy dies within the same RAID stripe as the target die, based on the physical addresses corresponding to the data marked as valid, to obtain the data required for reconstruction, and to skip data reading from the other healthy dies corresponding to the physical addresses of invalid data in the target die; and to use the data required for reconstruction to recover the valid data in the target die, obtaining the recovered data; and

[0013] The dynamic aggregation module is used to dynamically aggregate the recovered data to form new data stripes and write the new data stripes into the spare physical space.

[0014] Specifically, the index acquisition module is coupled to the flash memory conversion layer and is used to acquire in real time the logical-physical mapping bitmap index generated by the flash memory conversion layer by tracking the data status of each physical storage unit at the data page or data sector level.

[0015] Furthermore, the scheduling and reconfiguration module can integrate an instruction controller. This instruction controller is specifically configured such that, when generating the physical read instruction required for reconfiguration, if it determines that a certain target physical address in the target die is marked as invalid in the bitmap index, it will proactively, at the hardware level, suppress the generation and sending of physical read instructions to the corresponding physical addresses of other healthy dies within the same RAID stripe, thereby achieving precise I / O jumps.

[0016] Preferably, the internal structure of the dynamic aggregation module may include: an internal data buffer unit for temporarily storing the recovered discrete data; an integration controller for monitoring the amount of recovered data temporarily stored in the internal data buffer unit, and integrating the temporarily stored recovered data when the amount of data reaches a preset physical block write threshold; and a verification generation unit for generating new parity check data for the data integrated by the integration controller, so as to form the new data stripe together with the integrated data.

[0017] Optionally, the device may further include a concurrent processing module. This module is configured to, during the recovery operation performed by the scheduling and refactoring module, if it receives a host write request for a logical address on the target die, and the logical address is marked as valid in the logical-physical mapping bitmap index, control the writing of the data of the host write request to a new physical space, update the mapping relationship, and update the mark of the original physical address corresponding to the logical address in the logical-physical mapping bitmap index to invalid, thereby notifying the scheduling and refactoring module to abort the recovery operation for that original physical address.

[0018] Furthermore, this invention also provides a method for local dynamic reconstruction of cross-die RAID stripes based on logical-physical mapping bitmap indexes, which is applied to solid-state drives containing multiple flash memory dies, configured with a flash translation layer, and employing a cross-die RAID stripe protection mechanism, and includes the following steps:

[0019] Obtain the logical-physical mapping bitmap index maintained synchronously by the flash conversion layer. The logical-physical mapping bitmap index records whether the corresponding physical address unit currently stores valid user data, with physical pages, subpages, data sectors, or ECC codewords as the granularity.

[0020] When a target die failure is detected, multiple target physical addresses in the target die are determined according to the RAID stripe mapping relationship, as well as a set of healthy die physical addresses that are in the same old RAID stripe as each target physical address;

[0021] For each target physical address, query the logical-physical mapping bitmap index to determine whether the target physical address is marked as valid;

[0022] If the target physical address is marked as invalid, the generation of reconstruction read instructions for the set of healthy dies physical addresses within the same old RAID stripe corresponding to the target physical address is suppressed, and the recovery operation for the target physical address is skipped.

[0023] If the target physical address is marked as valid, then according to the RAID stripe mapping relationship, a reconstruction read instruction is generated for the healthy granule data page and / or parity page that participates in the old parity relationship within the same old RAID stripe, and the valid user data corresponding to the target physical address is recovered using the read data and parity data to obtain the recovered data;

[0024] Before submitting the recovery data to the dynamic aggregation buffer, the logical-physical mapping bitmap index or the corresponding mapping version information is queried again to confirm that the data corresponding to the target physical address is still valid; if it is confirmed that it has been updated to invalid, the recovery data is discarded and the corresponding recovery task is aborted; if it is confirmed that it is still valid, the recovery data and the corresponding logical address information are encapsulated into a recovery data packet and written to the dynamic aggregation buffer.

[0025] When the dynamic aggregation buffer meets the preset aggregation triggering conditions, multiple recovery data packets are integrated into a new data stripe, and new parity data is regenerated for the new data stripe.

[0026] The new data stripe and its new parity data are written to the spare physical space, and after successful writing, the logical-physical mapping relationship, the logical-physical mapping bitmap index, and the corresponding new stripe metadata in the flash conversion layer are atomically updated.

[0027] Preferably, determining the set of physical addresses of healthy dies based on the RAID stripe mapping relationship includes: querying the RAID stripe mapping table to obtain the stripe number, member number, intra-strip offset, and physical addresses of other members within the same old RAID stripe where the target physical address is located.

[0028] Preferably, the preset aggregation triggering conditions include: the amount of recovery data in the dynamic aggregation buffer reaches a capacity threshold, the residence time of the recovery data in the buffer reaches a time threshold, a host refresh command is received, or the solid-state drive is ready to enter a low-power state.

[0029] Preferably, the mapping version information includes the mapping version number or validity version number corresponding to the logical address; when a host write request causes the corresponding logical address to be remapped to a new physical address, the mapping version number or validity version number is incremented so that the reconstruction task can identify and discard expired recovery data before submitting the recovery data; the new stripe metadata includes the new stripe number, the new stripe member physical address, the logical address corresponding to the recovery data packet, the data member sequence number, and the new parity page physical address.

[0030] This invention establishes a logical-physical mapping bitmap index-based communication bridge between the Flash Translation Layer (FTL) of a solid-state drive (SSD) and the underlying hardware RAID reconstruction engine. When a physical die of the SSD fails and data reconstruction is required, this invention no longer employs the traditional method of indiscriminately reading all data across the entire RAID stripe. Instead, the underlying reconstruction scheduler first queries the bitmap index to precisely identify which physical areas on the failed die store "valid data" meaningful to upper-layer applications and which are "invalid data" that have been overwritten or discarded. Based on this precise identification, the reconstruction engine only initiates localized, targeted data read requests to other healthy dies within the same stripe for those data points marked as "valid," completely skipping all physical areas corresponding to "invalid data." This precise reading significantly reduces the traffic on the internal data bus during the reconstruction process. More importantly, after data recovery, this invention does not immediately write all the recovered, originally discrete, valid data blocks back to the spare space. Instead, they are first accumulated and reassembled in an internal buffer. Once one or more new, high-density, complete stripes are formed, they are then written along with the newly generated verification information. This process is equivalent to performing an efficient, event-driven garbage collection while performing disaster recovery.

[0031] Compared with the prior art, the present invention has the following significant advantages:

[0032] First, this invention accurately identifies and skips the reading of all invalid data through bitmap indexing, avoiding the internal bus bandwidth being occupied by a large amount of meaningless data transmission. Under typical enterprise-level application workloads, invalid data may account for 50% or more of the physical space. Therefore, this invention can reduce the total amount of data read required for reconstruction by a considerable order of magnitude, thereby significantly shortening the time window of the entire reconstruction process and reducing the risk of data exposure of the array in a degraded state.

[0033] Secondly, through a dynamic aggregation mechanism, this invention integrates fragmented recovery data into new, compact, complete stripes before writing, avoiding the need to copy the old stripe structure containing a large amount of invalid data to the spare space. This not only saves on writing to the spare space but also fundamentally eliminates storage fragmentation introduced by reconstruction, avoiding the performance dip that occurs again after reconstruction when garbage collection (GC) is required. Overall write amplification (WA) is effectively controlled, helping to extend the program / erase (P / E) cycle life of NAND flash memory.

[0034] Third, because internal bus contention is greatly reduced, normal read / write I / O requests from the host can receive faster and more stable responses during reconstruction. Simultaneously, through a concurrent processing mechanism, this invention can intelligently handle address conflicts that may occur between host writes and internal reconstruction, prioritizing the continuity of host services. This results in a smaller performance degradation and fewer latency spikes when the SSD faces a single die failure, better meeting the stringent requirements of enterprise applications for high availability and performance stability. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 This is a schematic diagram of the system architecture of a cross-crystal RAID stripe local dynamic reconstruction device based on logical-physical mapping bitmap index, provided in an embodiment of the present invention.

[0037] Figure 2 The flowchart illustrates a cross-crystal RAID stripe local dynamic reconstruction method based on logical-physical mapping bitmap index, as provided in an embodiment of the present invention.

[0038] Figure 3 This is a schematic diagram comparing the local jump reconstruction principle of this invention with the full reconstruction principle in the prior art.

[0039] Figure 4 This is a schematic diagram of the dynamic aggregation and writing process according to an embodiment of the present invention.

[0040] Figure 5 This is a comparison chart showing the effects of the technical solutions of this invention and existing technologies in terms of reconstruction performance, quality of service (QoS), and internal bandwidth usage. Detailed Implementation

[0041] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0042] It should be understood that in the description of this invention, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0043] RAID mechanisms are typically implemented at the physical level, logically combining multiple flash memory chips distributed across different channels or packages into a RAID array. When the host issues a write request, the SSD controller fragments the user data, calculates the corresponding parity data, and then writes the data fragments and parity data, in units of physical pages or physical blocks, to multiple different chips within the array. This cross-chip data redundancy distribution ensures that even if any chip in the array suffers permanent physical damage, the controller can still recover the lost data by reading the same data and parity data from other healthy chips, thus guaranteeing the integrity of the entire disk's data.

[0044] However, in traditional SSD internal RAID mechanisms, when a die fails and triggers the data reconstruction process, existing technologies generally suffer from serious design flaws, leading to a sharp decline in the overall performance and stability of the SSD. Firstly, the underlying hardware RAID reconstruction engine in existing mechanisms typically cannot perceive the fine-grained data validity status maintained by the FTL layer when performing data recovery. Therefore, when a stripe needs reconstruction, the hardware engine issues read commands to all healthy dies within that stripe, reading all data at the corresponding physical locations—whether it's valid data currently needed by the host or outdated data already marked as invalid—and performing an XOR operation. This process results in significant internal reconstruction read amplification; a large amount of valuable internal bus bandwidth is used to transmit worthless invalid data, greatly extending the overall reconstruction time and severely impacting the response performance of normal host I / O requests.

[0045] Secondly, the macro-level scheduling of the reconstruction mechanism is coarse-grained. When performing specific recovery operations on individual physical blocks or stripes, the underlying read behavior is a full read. Data validity information is not penetrated to the hardware instruction level, making it impossible to achieve precise and selective reading of individual data pages or sectors. Furthermore, when writing reconstructed data back to the spare space, existing technologies typically employ a write-back strategy, meaning the recovered data (including valid and invalid parts) is written verbatim to the new physical block to maintain stripe consistency. This approach not only wastes valuable spare space and flash write cycles (P / E cycles), but also creates a large amount of storage fragmentation in the new physical space, inevitably triggering garbage collection again shortly after reconstruction, leading to a secondary degradation in SSD performance.

[0046] Example 1

[0047] To address the aforementioned issues, this embodiment provides a cross-die RAID stripe local dynamic reconstruction method based on logical-physical mapping bitmap indexing. (Refer to...) Figure 2 The flowchart illustrates the complete steps for efficient data recovery in the event of a failure of one or more flash memory chips within a solid-state drive (SSD). The implementer of this method can be hardware logic, firmware, or a tight combination of both integrated into a high-performance enterprise-grade NVMe SSD controller, which may be built, for example, based on a multi-core ARM Cortex-R series processor.

[0048] The method begins by the solid-state drive's background health monitoring system or the underlying NAND flash memory channel interface controller, which, through its built-in low-density parity-check (LDPC) engine, reports a persistent, uncorrectable ECC error on one or more physical blocks, or detects a die link down in the physical connection of a flash memory die, thus determining that the target die has suffered a permanent physical failure. Once the fault management module in the controller firmware confirms this serious failure, it immediately and logically isolates the target die from the available resource pool and triggers an interrupt, activating the reconstruction process of this invention.

[0049] Next, a key preparatory step in the reconstruction task is to acquire and load the logical-physical mapping bitmap index recorded in the Flash Translation Layer (FTL) of the solid-state drive. This bitmap index is the core tool of this invention for bridging the "semantic gap" between the FTL and the underlying RAID engine. During normal operation of the solid-state drive, the FTL continuously tracks and records the data validity of all physical storage units on the entire disk at a very fine granular level (e.g., in this embodiment, at 4KB data sectors). For example, when data at a logical address LBA-A is updated from physical address PBA-Old to PBA-New, the FTL not only updates its master mapping table but also simultaneously flips the corresponding bit in the bitmap index of PBA-Old from "1" (valid) to "0" (invalid) and sets the corresponding bit in PBA-New to "1". This bitmap index, as a high-density metadata structure, is typically stored entirely in the DRAM connected to the controller. In this step, the index acquisition module, which serves as the method execution unit, rapidly loads the entire bitmap index data block associated with the faulty target die (e.g., the bitmap data for a single die of a 16TB SSD may be hundreds of MB) into the static random access memory (SRAM) inside the controller chip through a high-priority direct memory access (DMA) channel. This provides the hardware basis for subsequent millisecond-level query decisions.

[0050] Subsequently, the fault analysis module firmware begins a systematic, end-to-end scan and analysis of the entire physical address space of the target die, based on the bitmap index loaded into the SRAM in the previous step. This module starts from physical block 0 and physical page 0 of the target die, traversing upwards step by step. For each physical sector address encountered, it queries the status flag corresponding to that address in the bitmap index. Its core task is to construct an accurate "reconstruction task queue" or "valid address list," which only contains the physical addresses of data marked as "valid" in the bitmap index. For example, in a block containing 1024 physical pages, after analysis, it might be found that only pages 5, 12, 128, and 512 store valid data; therefore, the task queue will only contain these four page addresses.

[0051] Next, the process enters a crucial decision and branching step that determines refactoring efficiency. The scheduling refactoring module retrieves the next valid address from the refactoring task queue and checks whether its marker in the bitmap index is valid. (See reference...) Figure 3 The way this step is performed is the key difference between this invention and the prior art.

[0052] If the judgment result is "yes" (which is always the case for addresses in the reconstruction task queue), it means that user data is stored at that address and must be recovered. The process then proceeds to the recovery step. The scheduling reconstruction module immediately generates and sends a set of parallel, asynchronous local physical read commands to all other healthy dies in the same RAID stripe as the target die. For example, in a 7D+1P RAID-5 array, the controller will issue read requests to the same page address (e.g., page 5) of the other 7 healthy dies (6 data dies, 1 parity die). This is a surgically precise local read operation, mobilizing internal bus resources only to recover this specific valid data page.

[0053] During the traversal of all physical addresses, if the judgment result of the marker is "no" (i.e., the currently scanned physical address is not in the reconstruction task queue, and its bitmap is marked as invalid), it proves that the address stores outdated and useless garbage data. At this time, the process enters the skip step. The scheduling reconstruction module will perform instruction suppression or intelligent skip operation. Its hardware instruction generator will completely skip the step of generating any read instructions for this invalid address. (See reference...) Figure 3 Existing technologies generate read instructions for each old stripe location; this invention, however, first queries the validity flag of the target address corresponding to the faulty die. If the target address of the faulty die is invalid, the entire group of reads for the same stripe corresponding to that target address is skipped; if the target address of the faulty die is valid, all healthy member pages and check pages participating in the old check relationship in the same old stripe are read to recover the faulty page. The recovered faulty page is only sent to the dynamic aggregation module if the corresponding LBA is still valid. Invalid data pages in healthy dies can participate in old stripe XOR recovery, but are not written as valid user data for the new stripe.

[0054] Furthermore, the "skip" mentioned in this embodiment means that when the target physical address on the faulty die is marked as invalid in the logical-physical mapping bitmap index, the controller will no longer initiate a same-strip recovery read operation for that target physical address; when the target physical address on the faulty die is marked as valid, to ensure that the old RAID parity relationship is valid, the controller still reads all healthy member data and parity data involved in the parity relationship within the same old stripe. For invalid pages among these healthy members, their data is only used as the XOR input for recovering the target valid page and is not written as valid user data in the new stripe.

[0055] like Figure 3As the comparison shows, existing technologies blindly generate read instructions for all 1024 page addresses, while this invention, guided by bitmap indexing, may only generate 4 read instruction sets, directly avoiding access to invalid data regions from the hardware source. In write-intensive enterprise application scenarios, invalid data often accounts for more than 60%, which means that this invention can save more than 60% of internal reconstruction read bandwidth with just this one step.

[0056] Next, once the scheduling and refactoring module has collected the necessary refactoring data (i.e., 6 data pages and 1 parity page) from all healthy dies, this data is immediately fed into a dedicated hardware XOR calculation engine located within the controller. This engine performs a high-speed XOR operation, accurately recovering the lost valid data page (page 5) with extremely low latency. The recovered data is clean and contains no invalid information.

[0057] Subsequently, in order to eliminate the write amplification and fragmentation problems caused by write-back as is in the prior art, this embodiment introduces a reference... Figure 4 The dynamic aggregation steps are shown. All recovered valid data pages that may be physically discontinuous (such as page 5, page 12, page 128, page 512, etc.) are not immediately written back, but are pushed as a data packet (containing LBA, the data itself, and other information) to a dedicated dynamic aggregation module.

[0058] Finally, the dynamic aggregation module continuously accumulates these valid data pages. When the amount of data in its internal buffer reaches a preset write threshold (e.g., the accumulated data is sufficient to fill a new, complete Super-Block), it initiates the consolidation process. This process rearranges and compacts these logically discrete valid data pages, forming one or more continuous, entirely new physical stripes. Simultaneously, an inline parity generation unit recalculates and generates a new parity data set to match this new stripe. Then, this new, nearly 100% data-density complete data stripe is written as a standard write task to the reserved spare physical space in one go. After the write is complete, the FTL atomically updates the mapping relationships of these LBAs in batches, making them point to these new physical addresses. The entire process repeats until all valid data on the faulty die is recovered and safely written, and the process is finally completed at the "end" node.

[0059] As can be seen from the detailed steps of this embodiment, the present invention optimizes the traditional, extensive reconstruction process, which has a serious impact on system performance, into a refined, intelligent background data processing and recovery task that minimizes the impact on upper-layer business.

[0060] Example 2

[0061] This embodiment will elaborate on various specific implementation methods and maintenance mechanisms of the logical-physical mapping bitmap index in Embodiment 1. The bitmap index is the cornerstone of this invention's leap from blind full reconstruction to intelligent partial reconstruction. Its specific implementation architecture, management granularity, and maintenance strategy directly affect the reconstruction accuracy, execution efficiency, and system resource overhead of this invention.

[0062] In a preferred implementation, the bitmap index exists as an embedded master mapping table within the Flash Translation Layer (FTL). To achieve high performance, enterprise-grade SSDs typically employ DRAM-based page-level mapping or its variants in their FTL. In this architecture, each logical address to physical address mapping entry records information such as the core physical page address (PBA) and the virtual block (VB) to which the data belongs. This invention also specifically extends this entry with an additional bit (e.g., a 1-bit "Valid-Flag") as a validity flag.

[0063] Furthermore, when the logical-physical mapping bitmap index is implemented in an embedded manner, the FTL also maintains a reverse index from the physical address to the validity tag, or maintains a validity summary table with the PBA as the query key outside the mapping entry, enabling the scheduling refactoring module to directly query the validity status based on the target physical address. The embedded implementation is not limited to querying validity only through the LBA.

[0064] Taking a specific mapping entry as an example, its data structure in DRAM can be designed as follows: | LBA_Tag (24-bit) | PBA (32-bit) | Erase_Count (16-bit) | Valid_Flag (1-bit) | Reserved (7-bit) |. When a logical address LBA-A is written to for the first time or its data is updated, the FTL allocates a new physical page PBA-New for it. At this time, in the mapping entry created or updated for LBA-A, Valid_Flag will be automatically set to "1" by the hardware or firmware. Meanwhile, if LBA-A previously occupied an old physical page PBA-Old, when the old mapping entry corresponding to PBA-Old is discarded, its Valid_Flag will be cleared to zero or the entry itself will be marked as waiting to be reclaimed.

[0065] The primary reason for choosing this embedded implementation is its extremely high resource efficiency and data consistency. First, it significantly saves valuable DRAM space. In a 16TB SSD, with 16KB pages, there would be approximately 1 billion physical pages. Maintaining a separate 8-byte mapping entry for each page would require approximately 8GB of DRAM for the main mapping table alone. The embedded approach only adds one bit to each existing entry, resulting in almost no additional memory usage, which is crucial for controlling the SSD's Bill of Materials (BOM) cost. Second, it inherently guarantees the atomic updating of mapping relationships and validity states. Modifications to a mapping entry (such as updating the PBA) and its validity flag by the FTL firmware can be completed within a single CPU memory write cycle. This naturally avoids synchronization issues that may arise between two independent data structures, simplifying firmware logic and improving system robustness.

[0066] In another high-performance alternative implementation, the bitmap index can be a separate, dedicated bitmap structure, separate from the FTL master mapping table, and stored in a specific, contiguous physical address space of the controller DRAM. This separate bitmap is essentially a huge bit array that can be directly addressed by physical address.

[0067] For a specific example, a physical address (PBA) can be composed of a die ID, a block ID, a page ID, and a sector ID. The conversion from this PBA to its corresponding bit index (Bit_Index) in the bitmap can be performed using a fixed hardware calculation formula, for example: Bit_Index = Die_Offset + Block_ID * (Pages_Per_Block * Sectors_Per_Page) + Page_ID * Sectors_Per_Page + Sector_ID. The hardware refactoring engine only needs to know the base address of the bitmap to directly calculate the byte address and bit offset of the corresponding status bit for any PBA through simple shift and addition operations, thus enabling extremely fast lookups. Wherein, Die_Offset represents the starting bit offset of the target die in the bitmap; Block_ID represents the target physical block number; Pages_Per_Block represents the number of physical pages contained in each physical block; Sectors_Per_Page represents the number of data sectors contained in each physical page; Page_ID represents the page number within the block; and Sector_ID represents the sector number within the page. If the SSD's physical address also includes fields such as Channel_ID, LUN_ID, and Plane_ID, then Die_Offset can be further calculated from Channel_ID, LUN_ID, Die_ID, and Plane_ID.

[0068] The reason for choosing this standalone implementation is its extreme query performance and architectural decoupling. This is especially important for top-tier enterprise-class SSDs that pursue ultimate performance. Because the bitmap structure is simple and address calculations are fixed, query operations do not require parsing the complex hash, tree, or chain structures of the FTL master mapping table, resulting in extremely low latency. More importantly, it achieves decoupling between the refactoring hardware and the FTL software. The hardware portion of the refactoring module (e.g., a dedicated ASIC coprocessor) does not need to understand the FTL software logic and can directly and efficiently prefetch large blocks of bitmap data for analysis using its own DMA engine, without consuming any computing resources of the main CPU. This allows the refactoring analysis process to run in parallel with host I / O processing, minimizing the impact of refactoring on the SSD's foreground performance.

[0069] The advantage of this approach is that it minimizes the time spent in the reconstruction preparation phase (i.e., effective address resolution), allowing physical data recovery to begin more quickly. Simultaneously, by offloading hardware, it significantly reduces the burden on the main CPU during reconstruction, enabling the CPU to concentrate resources on ensuring the host's Quality of Service (QoS). This is of decisive value for latency-sensitive applications such as financial transactions and real-time analytics.

[0070] Regarding the management granularity of the bitmap index, this invention also supports flexible configuration. Using the 4KB sector granularity described above achieves the highest reconstruction accuracy, but the bitmap occupies the largest space. For applications primarily handling large file read / write operations, a 16KB page granularity can also be configured. This reduces the bitmap's memory footprint to one-quarter of its original size, sacrificing a small amount of accuracy (if only one sector within a page is invalid, the entire page can still be recovered). Another adaptive strategy is that the FTL can dynamically adjust its bitmap management granularity based on the write characteristics of different LBA regions, allocating sector granularity for small file random write regions and page granularity for large file sequential write regions, achieving the optimal balance between accuracy and overhead.

[0071] Finally, regarding the persistence and consistency maintenance mechanism of the bitmap index in the event of unexpected power loss, this invention utilizes the Power Loss Protection (PLP) capacitor array, a standard feature of enterprise-grade SSDs, and the firmware's logging mechanism to jointly ensure consistency. Whether embedded or standalone, any state change of the bitmap index is bound to the update operation of the FTL master mapping table within the same transaction. When the firmware executes a host write command, it first writes all metadata updates, including FTL mapping changes and bitmap state changes, as an atomic log entry to a PLP-protected log area located in DRAM or SLC NAND. The host write command is only acknowledged after the log entry has been confirmed as safely written. In the event of an unexpected power loss, the remaining power provided by the PLP capacitors is sufficient to completely flush the contents of the log area to the non-volatile NAND flash memory. When the SSD is powered on again, the controller first performs Log Replay, reapplying all incompletely committed metadata changes based on the log entries, thereby ensuring that the FTL master mapping table and bitmap index are accurately restored to the last consistent state before the power loss.

[0072] Example 3

[0073] This embodiment provides a specific structure for a cross-die RAID stripe local dynamic reconfiguration device based on a logical-physical mapping bitmap index. (Refer to...) Figure 1This device is typically integrated into the controller SoC chip of an enterprise-grade solid-state drive, which can be part of an ASIC (Application-Specific Integrated Circuit) or an FPGA (Field-Programmable Gate Array) and works in conjunction with the controller's embedded CPU (such as an ARM core) and its firmware.

[0074] The device mainly includes an index acquisition module, a fault analysis module, a scheduling reconstruction module, a dynamic aggregation module, and an optional concurrent processing module. For example... Figure 1 As shown, the index acquisition module obtains the valid bitmap corresponding to the target die from the FTL master mapping table or independent bitmap table and writes it into the internal SRAM; the fault analysis module reads the bitmap data in the SRAM and generates a valid address reconstruction task queue; the scheduling reconstruction module generates a healthy die read instruction based on the task queue and the RAID stripe mapping table, and sends the read data to the XOR calculation unit; the dynamic aggregation module receives the recovery data packet and forms a new data stripe according to a preset strategy; the concurrent processing module is located between the host I / O path and the reconstruction path and is used to handle address conflicts between host writes and reconstruction tasks.

[0075] The function of this index acquisition module is to obtain the logical-physical mapping bitmap index recorded in the Flash Translation Layer (FTL) that is used to characterize the validity of data in multiple flash dies.

[0076] In hardware, this module is implemented as a hardware unit equipped with a dedicated Direct Memory Access (DMA) engine. This DMA engine is directly connected to the memory controller of the main DRAM of the controller via a high-speed internal bus (such as the AMBA or AXI bus). The firmware interface of this module is designed to be tightly coupled with the FTL firmware. When the FTL firmware modifies the bitmap index due to host writes, updates, or garbage collection (GC), it synchronously updates a "Dirty Region" marker. The index acquisition module then periodically, or at the start of a refactoring task, uses its DMA engine to efficiently and non-blockingly fetch and refresh the bitmap data regions marked as "dirty" in the main DRAM to a dedicated SRAM within the controller.

[0077] For example, when the reconstruction task is initiated, the fault resolution module sends a request to the index acquisition module to retrieve the bitmap index corresponding to the faulty die (e.g., Die 3). The DMA controller of the index acquisition module then automatically completes a 64MB data block transfer based on the preset DRAM base address and the address offset of Die 3, moving the complete bitmap index of Die 3 from the main DRAM to the internal SRAM, preparing for subsequent sub-microsecond queries.

[0078] The function of this fault resolution module is to parse the physical address corresponding to the valid data stored in the target die when a fault is detected, based on the logical-physical mapping bitmap index provided by the index acquisition module. This module is typically implemented by a firmware program segment running on the controller's embedded CPU. After receiving the fault die ID from the upper-layer firmware, it starts a scanning loop. This loop systematically traverses all physical addresses of the faulty die (from Block 0, Page 0 to the last address). At each step of the loop, it queries the bitmap index already loaded into the internal SRAM.

[0079] For example, suppose the current scan finds physical page address 0x0123. The fault resolution module will initiate a read operation to the corresponding address in the bitmap-indexed SRAM, querying the four bits corresponding to the four 4KB sectors of that page. If the query result is [1, 0, 0, 1], it means that sectors 0 and 3 of the page are valid. The fault resolution module will then add the two task items {PBA: 0x0123, Sector: 0} and {PBA: 0x0123, Sector: 3} to a "reconstruction task queue" located in shared memory for subsequent use by the scheduling reconstruction module.

[0080] Based on the valid physical addresses provided by the fault analysis module, the scheduling and reconstruction module controls the solid-state drive to perform partial data reads from other healthy dies within the same RAID stripe, skipping data reads from physical addresses in those other healthy dies that correspond to invalid data in the target die, and recovering valid data using the acquired data. This is a complex unit that works in conjunction with hardware and software. Its firmware is responsible for retrieving task items from the reconstruction task queue, while its hardware includes a high-performance instruction sequence generator and one or more hardware XOR calculation units.

[0081] For example, to achieve precise control over skipping invalid reads, its internally integrated instruction controller is specifically configured with the following logic:

[0082] The firmware retrieves the task item {PBA: 0x0123, Sector: 0} from the queue. Since this is a valid task, the instruction controller generates a set of parallel physical read commands for it, sending them to the other seven healthy dies within the same RAID stripe at PBA: 0x0123, Sector: 0 addresses. However, when the firmware processes PBA: 0x0123, Sector: 1 during normal address traversal (not retrieving items from the task queue), it queries the bitmap and finds it marked as "invalid." At this point, the instruction controller performs a suppression operation, meaning it doesn't generate any physical read commands for that address. This suppression behavior at the source of instruction generation is key to achieving precise I / O jumps and saving internal bus bandwidth. The recovered data (e.g., data in Sector: 0) is then sent to the dynamic aggregation module.

[0083] The function of this dynamic aggregation module is to dynamically aggregate the data recovered by the scheduling and reconstruction module, form new data stripes, and write them to the spare physical space. The hardware implementation of this module is divided into the following three sub-units:

[0084] 1. Internal data buffer unit: used to temporarily store the recovered data. For example, a dedicated 2MB embedded SRAM is used to efficiently store the recovered data packets.

[0085] 2. Integration Controller: This controller monitors the amount of recovery data temporarily stored in the internal data buffer unit and integrates the temporarily stored recovery data when the data amount reaches a preset physical block write threshold. For example, it can be a control unit implemented using a hardware finite state machine and a capacity counter. Its function is to monitor the amount of data temporarily stored in SRAM and integrate all temporarily stored data packets according to LBA when the data amount reaches a preset threshold of 16MB.

[0086] 3. Parity Generation Unit: This unit generates new parity data for the data integrated by the integration controller, so that it, together with the integrated data, forms the new data stripe. For example, it can be a dedicated, pipelined hardware XOR engine. Its function is to generate new parity data at high speed for the 16MB data block integrated by the integration controller, thus forming a new write stripe.

[0087] This device may also optionally include a concurrent processing module. The function of this module is to, during the recovery operation performed by the scheduling and reconstruction module, if a host write request for a specific logical address on the target die is received, and the logical address is marked as valid in the logical-physical mapping bitmap index, control the writing of the data requested by the host to a new physical space, update the mapping relationship, and update the mark of the original physical address corresponding to the logical address in the logical-physical mapping bitmap index to invalid, thereby notifying the scheduling and reconstruction module to abort the recovery operation for that original physical address. This handles write conflicts from the host during reconstruction, ensuring quality of service. This module is implemented by the controller firmware at the front end of the I / O processing path.

[0088] For example, during the reconstruction process, a write request from the host for LBA-X arrives. The concurrent processing module intercepts this request. It first queries the "reconstruction task queue" and finds that the original physical address PBA-Old of LBA-X is waiting for recovery in the queue. At this point, it immediately executes the conflict handling process: 1. It commands the FTL's physical space allocator to allocate a brand new physical address PBA-New from the free pool. 2. It writes the host's write data to PBA-New. 3. It updates the FTL's main mapping table atomically, making LBA-X point to PBA-New. 4. The most crucial step is that it writes an instruction to the SRAM where the bitmap index resides, forcibly updating the validity flag corresponding to PBA-Old to "invalid". This action serves as a notification; when the scheduling reconstruction module subsequently processes the task item PBA-Old, it will automatically abort its recovery operation because it finds that the bitmap has become invalid upon re-querying the bitmap. This process ensures low latency for host writes and avoids the system performing unnecessary work.

[0089] For example, the solid-state drive controller maintains a RAID stripe mapping table, Stripe_Map. For a target physical address PBA_f, Stripe_Map(PBA_f) returns the stripe number Stripe_ID, the target member number Member_ID, the stripe offset Stripe_Offset, and the set of physical addresses of other members in the same stripe {PBA_0,...,PBA_m}. The scheduling reconfiguration module generates healthy die read instructions based on this mapping table, instead of mechanically generating read instructions based solely on the same page number.

[0090] Each refactoring task carries a mapping version number (Map_Ver) and a validity version number (Valid_Ver) generated at the time of task generation. The concurrent processing module increments the version number corresponding to the LBA after the host write is committed; the scheduling refactoring module verifies the version number again before performing XOR recovery and before committing the recovered data to the dynamic aggregation module. If a version number change or the bitmap marker becomes invalid is found, the old data that has been read or recovered is discarded, and it is prohibited from entering the new stripe write process.

[0091] These modules are interconnected and work together through a high-speed bus (such as the AMBA AXI bus) inside the controller. Together they constitute the technical entity of this invention, realizing a complete closed loop from accurate identification and partial reading to dynamic aggregation and writing, and efficiently completing the data reconstruction task.

[0092] Example 4

[0093] This embodiment aims to explain, with reference to, the embodiments described in Embodiments 1 and 3, and further referencing Figure 4 The specific hardware implementation, core working principle, and multi-dimensional aggregation strategy of the dynamic aggregation module are described in depth and detail. This module is the key technical entity of this invention, which fundamentally eliminates write amplification during the reconstruction process, avoids storage fragmentation, and achieves the core beneficial effect of garbage collection driven by reconstruction events.

[0094] Reference Figure 1 In this embodiment, the device is integrated into a solid-state drive controller and interacts with the host system and the NAND flash array. The host system communicates with the Flash Translation Layer (FTL) within the controller via host I / O requests. The FTL maintains the logical-physical mapping while providing a bitmap index to the index acquisition module. When a target die in the NAND flash array fails, the fault resolution module generates a list of valid addresses based on this bitmap index and hands it over to the scheduling and reconstruction module. The scheduling and reconstruction module recovers data by performing partial reads on healthy dies and sends the recovered data to the dynamic aggregation module. After processing, the dynamic aggregation module writes the new complete stripe to the spare space of the flash array. Furthermore, the concurrent processing module can handle concurrent write requests from the host and interacts with the FTL and the scheduling and reconstruction module to jointly ensure quality of service.

[0095] First, at the hardware implementation level, the dynamic aggregation module is designed as a highly optimized data processing pipeline located within the solid-state drive controller SoC chip to ensure that its processing does not become a bottleneck for refactoring performance. Its core hardware components include:

[0096] 1. Internal Data Buffer Unit: This is not a simple borrowing of general-purpose DRAM, but rather implemented using a high-speed, low-latency embedded static random access memory (SRAM) specifically designed as a pack buffer. The use of SRAM ensures that recovered data blocks can be written and read at extremely high rates, avoiding contention for DRAM bandwidth with host I / O.

[0097] 2. Monitoring and Integration Controller: This is a control unit implemented using a hardware state machine and a series of counters. It is responsible for monitoring the state of the SRAM buffer in real time and triggering the data integration process according to a preset aggregation strategy, achieving efficient hardware offloading without frequent intervention from the main CPU.

[0098] 3. Parity Generation Unit: This is a dedicated hardware XOR engine separate from the main data path. Its task is to quickly calculate the corresponding parity data for the new data stripes after data integration is completed.

[0099] The detailed workflow and aggregation strategy of this module can be broken down into the following key stages:

[0100] Phase 1: Data is fed into the buffer

[0101] Each time the scheduling and refactoring module successfully recovers a valid data block (e.g., a 4KB sector), it immediately encapsulates the data block with its original Logical Block Address (LBA) information to form a structured data packet, for example, in the format {LBA: uint64_t, Data: uint8_t

[4096] }. This LBA information is the sole credential for subsequent address remapping. Subsequently, this data packet is rapidly pushed to the tail of the queue in the SRAM packing buffer of the dynamic aggregation module.

[0102] Phase Two: Multi-Dimensional Triggering Mechanism

[0103] The monitoring and integration controller determines when to initiate data integration based on a sophisticated and efficient triggering strategy, rather than a single condition.

[0104] 1. Capacity Threshold Trigger: This is the most common triggering method. This threshold is not arbitrarily set but is closely related to the physical characteristics of NAND flash memory. It is typically set to the size of a superblock or multi-plane write unit, such as 16MB. The reason for setting this threshold is that performing such large-size, aligned sequential writes to NAND flash memory maximizes the utilization of the flash memory's multi-plane parallel write capability, achieving the highest write throughput and the lowest write latency.

[0105] 2. Time Threshold Trigger: This is an auxiliary triggering method to ensure the continuous progress of the refactoring process. The controller has a hardware timer, for example, set to 5 milliseconds. If the amount of data in the SRAM buffer fails to reach the capacity threshold within the timer period (possibly because valid data in the faulty area is very sparse), the timer will time out and force the integration process to be triggered. This effectively avoids the problem of a small amount of recovered data being suspended in the buffer for an extended period, causing the refactoring task to appear to be stalled.

[0106] 3. High-priority refresh trigger: This is the highest priority triggering method to ensure data security and system state synchronization. For example, when the firmware receives a FLUSH CACHE command from the host, or when the system is preparing to enter a low-power state, the integration process will be triggered immediately, regardless of the amount of data in the current buffer, to persist all recovered data to the NAND medium.

[0107] Phase 3: Data Integration and Reordering

[0108] Once any trigger condition is met, the monitoring and integration controller initiates the integration process.

[0109] 1. Logical Address Reordering: The controller retrieves all data packets to be processed from the SRAM buffer. It does not process the packets according to their arrival order, but instead reads the LBA information of each packet and performs a quick logical address reordering. For example, packets that originally arrived discretely and belonged to LBA-100, LBA-500, and LBA-101 will be rearranged into logically consecutive LBA-100, LBA-101, and LBA-500.

[0110] 2. Compact Data Filling: After sorting, the controller compactly and seamlessly fills this valid data into a new, clean sequence of physical pages. This process is essentially identical to background garbage collection (GC): it picks out only the valid, recoverable data from a source space containing a large amount of invalid data (in this case, logically old RAID stripes) and tightly sets them onto new physical blocks.

[0111] Phase 4: New Verification Generation and Packaging

[0112] After this new, highly dense dataset is formed, it is sent to the parity generation unit. The hardware XOR engine calculates a completely new parity data set that precisely matches the original data. This new parity data is completely unrelated to the parity data of the old stripes, as it only reflects the parity status of the current 100% valid dataset.

[0113] Ultimately, this new, complete data stripe, consisting of the integrated data and the newly generated checksum data, will be submitted to the FTL's write path as a high-priority internal write task. The FTL's physical space allocator will allocate an appropriate free superblock for it, and then, through the backend NAND channel controller, persist it to the spare physical space using the most efficient multi-plane sequential write method.

[0114] Phase 5: Atomic Update of Metadata

[0115] After the new stripe has been successfully written to the NAND media, a crucial final step is to atomically update the FTL's mapping table in batches. The FTL will update the LBA of all packets written in this consolidation, along with their corresponding PBA in the main mapping table, to their new physical addresses in the spare space all at once and indivisibly. This ensures that the system's metadata and physical data remain absolutely consistent at all times.

[0116] In a specific implementation, the RAID-5 array in this embodiment is a 7D+1P structure consisting of 8 dies, with each physical page being 16KB in size and containing four 4KB sectors. Consider a specific RAID stripe that spans 8 dies, occupying one physical page on each die, denoted as follows: and verification page The formula for generating the original verification data is:

[0117] (Formula 1)

[0118] in, Represents the XOR operation. This represents 7 data pages in the old RAID-5 stripe; This indicates the parity check page corresponding to the old stripe.

[0119] Now, suppose The target die malfunctioned, and after a period of writing, it was determined from the bitmap index that... and The data on this page has been marked as invalid.

[0120] The processing method of the present invention:

[0121] 1. Recovery and Buffering: The scheduling and refactoring module uses a skip-read approach, if... If valid, then read all healthy member pages and old check pages required to restore the old check relationship. After restoration, only Still valid user data is sent as a recovery data packet to the dynamic aggregation buffer.

[0122] 2. Accumulation and Integration: The dynamic aggregation module continuously receives valid recovery pages from different fault stripes. Assuming that after several rounds of recovery, 7 valid data pages have accumulated in the SRAM, they are marked as follows: (These may come from completely different logical addresses). At this point, the controller decides to construct a new, complete 7D+1P data stripe.

[0123] 3. New Verification Generation: The verification generation unit will start at this time, but the calculations it performs are not based on the old ones. It will calculate a new parity page based on the seven new, fully valid data pages currently in the SRAM using the following formula. :

[0124] (Formula 2)

[0125] 4. Packaging and Writing: Finally, the controller packages these 7 valid data pages and 1 newly calculated checksum page. A total of 8 pages are written to the spare physical space in one go, in the optimal order, as a complete superblock.

[0126] Quantitative Analysis: In this operation, the system wrote a total of 8 pages, and these 8 pages (7 data pages and 1 check page) together protected 7 real and valid user data pages. Therefore, the write amplification (WA) for valid user data is: total number of pages written / number of real and valid data pages = 8 / 7 ≈ 1.14. More importantly, in actual continuous operation, since a full stripe of valid data is always written, in terms of the internal array redundancy loss metric of write amplification, it abandons the amplification penalty brought back by blindly substituting dirty data from the original stripe for reconstruction, and instead perfectly reduces and locks at the excellent lower limit limit of the multi-link redundancy physical theory, i.e., (N+1) / N (which converges to 1.14 in this example).

[0127] Finally, after the new data stripe is generated, the controller assigns a new Stripe_ID to the new stripe and records the LBA, PBA, member sequence number, and checksum page PBA for each data page in the new stripe. Once the valid data in the old stripe has been migrated, the FTL master mapping table and bitmap index are updated simultaneously, marking the old PBA as invalid and the new PBA as valid. The checksum data of the new stripe is only used to protect the currently aggregated valid data set within the new stripe and has no inheritance relationship with the checksum data of the old stripe. Figure 4The dynamic aggregation shown does not copy each page from the old stripe to the spare space in its original position. Instead, it temporarily stores the recovered and still valid data pages as data packets. When the capacity threshold, time threshold, or refresh trigger condition is met, aggregation is performed according to LBA or write order, new physical stripe positions are allocated, P_new is recalculated, and the FTL mapping table and bitmap index are atomically updated after a successful write. Therefore, members of the new stripe can come from multiple old stripes, and its parity data P_new corresponds only to the currently valid data set in the new stripe.

[0128] This in-depth analysis of the dynamic aggregation module in this embodiment reveals that it is not merely a simple buffer and forwarding unit, but an advanced data processing engine integrating hardware acceleration, intelligent scheduling, data reorganization, and garbage collection concepts. Its beneficial effects are multifaceted: it not only directly reduces write amplification (WA) by merging fragmented writes into efficient sequential writes, but also improves the long-term performance stability of solid-state drives and significantly extends the effective lifespan of NAND flash memory by actively eliminating storage fragmentation.

[0129] Example 5

[0130] This embodiment further illustrates a method for local dynamic reconstruction of cross-die RAID stripes based on logical-physical mapping bitmap indexes. This method is applied to enterprise-level solid-state drive (SSD) controllers, where the SSD includes multiple NAND flash memory chips, a flash translation layer (FTL), a cross-die RAID protection unit, an internal data buffer unit, and spare physical space. This embodiment uses a 7D+1P RAID-5 stripe structure as an example, where 7 chips are used to store data pages and 1 chip is used to store parity pages. Those skilled in the art will understand that this method can also be applied to RAID-5 stripes with other numbers of data members, or to internal RAID protection structures with similar XOR parity relationships.

[0131] I. Logical-Physical Mapping Bitmap Index and RAID Striping Mapping Relationship

[0132] During normal operation of the solid-state drive (SSD), the Filesystem Layer (FTL) maintains the mapping relationship between logical addresses and physical addresses, and simultaneously maintains the logical-physical mapping bitmap index. The logical-physical mapping bitmap index records whether the corresponding physical address unit currently stores valid user data, using physical pages, subpages, data sectors, or ECC codewords as its granularity.

[0133] In one implementation, a bit value of 1 in the bitmap index indicates that the data stored in the corresponding physical address unit is still referenced by the FTL mapping table and is considered valid user data; a bit value of 0 indicates that the data stored in the corresponding physical address unit has been overwritten by new data, discarded by TRIM or garbage collection processes, and is considered invalid data.

[0134] For a physical address PBA, the controller can calculate its bit index in the independent bitmap as follows:

[0135] Bit_Index = Die_Offset + Block_ID × Pages_Per_Block × Sectors_Per_Page + Page_ID × Sectors_Per_Page + Sector_ID

[0136] Wherein, Die_Offset represents the starting bit offset of the target die in the bitmap; Block_ID represents the target physical block number; Pages_Per_Block represents the number of physical pages contained in each physical block; Sectors_Per_Page represents the number of data sectors contained in each physical page; Page_ID represents the page number within the target physical block; and Sector_ID represents the sector number within the target physical page. When the physical address also includes Channel_ID, LUN_ID, or Plane_ID, Die_Offset can be determined jointly by Channel_ID, LUN_ID, Die_ID, and Plane_ID.

[0137] Simultaneously, the controller maintains a RAID stripe mapping table, Stripe_Map. For a target physical address PBA_f in the target die, Stripe_Map(PBA_f) returns the stripe number Stripe_ID, member number Member_ID, stripe offset Stripe_Offset of the old RAID stripe containing that target physical address, as well as the set of physical addresses of other healthy members within the same old RAID stripe. The scheduling and reconfiguration module generates reconfiguration read instructions based on this RAID stripe mapping table, rather than mechanically generating read instructions based solely on the same page number.

[0138] II. Fault Detection and Target Address Filtering

[0139] When the controller detects a fault in the target die, such as a Die Link Down, a persistent uncorrectable ECC error, the target die being inaccessible, or the target die being marked as faulty by the firmware, the fault management module isolates the target die from the available resource pool and triggers a refactoring process.

[0140] The fault analysis module begins traversing the physical address space of the target die. For each target physical address PBA_f in the target die, the fault analysis module first queries the logical-physical mapping bitmap index to determine whether the data corresponding to the target physical address is valid user data.

[0141] If the target physical address PBA_f is marked as invalid in the bitmap index, it means that even if data was previously stored at that location, its data content is no longer referenced by the upper-level logical address. In this case, the scheduling and reconstruction module will no longer generate any same-strip reconstruction read instructions for that target physical address, nor will it read the corresponding data pages or parity pages of other healthy dies in the same old RAID stripe. In other words, "skip read" in this embodiment means that when the target physical address on the faulty die is invalid, the recovery operation of the entire old RAID stripe corresponding to that target physical address is skipped.

[0142] If the target physical address PBA_f is marked as valid in the bitmap index, it means that the data stored at that target physical address is still referenced by the FTL mapping table and needs to be recovered. At this time, the scheduling reconstruction module determines the physical address of the healthy member in the same old RAID stripe based on Stripe_Map(PBA_f) and generates reconstruction read instructions for the healthy data pages and / or old parity pages that participate in the old parity relationship.

[0143] III. Recovery of Valid Target Pages in Old RAID Stripes

[0144] In a specific example, the old RAID stripe has a 7D+1P structure, and the data pages in the old stripe are represented as follows: The old parity page is represented as The old parity check relation is:

[0145] (Formula 1)

[0146] in, This represents 7 data pages in the old RAID stripe; This indicates the old parity page corresponding to the old RAID stripe; ⊕ indicates a bitwise XOR operation.

[0147] Assumption The target die has failed. If the fault analysis module confirms, after querying the bitmap index, that the target physical address corresponding to D_3 has been marked as invalid, the controller will not recover. It does not read as well as This scenario demonstrates the technical effectiveness of this invention in reducing internal reconstruction read amplification through bitmap indexing.

[0148] If the fault analysis module confirms after querying the bitmap index... If the corresponding target physical address is still marked as valid, the controller needs to restore it based on the old checksum. At this point, even and These pages, already marked as invalid in the FTL bitmap index, still participate in the old parity check relationship represented by Equation 1. Therefore, when utilizing old parity pages... recover At that time, the scheduling reconfiguration module still reads and The old physical content is used as the XOR input. The recovery formula is:

[0149] = ⊕ D0 ⊕ D1 ⊕ D2 ⊕ D4 ⊕ D5 ⊕ D6 (Formula 1-1)

[0150] Therefore, this embodiment does not arbitrarily skip invalid pages in healthy RAID dies when recovering valid faulty pages. Instead, it only skips the entire reconstruction read operation corresponding to the target address when the target address corresponding to the faulty RAID die is invalid. For valid target addresses on faulty RAID dies, the controller still reads the old stripe member data necessary for recovery according to the old RAID stripe checksum relationship, thereby ensuring the correctness of the recovery result.

[0151] IV. Secondary validity verification before data submission

[0152] After the scheduling and refactoring module recovers D_3 using Formula 1-1, it does not immediately write it to the backup physical space. Instead, it first performs a secondary verification before committing. Specifically, the scheduling and refactoring module queries the logical-physical mapping bitmap index again, or reads the mapping version number Map_Ver and validity version number Valid_Ver of the corresponding logical address.

[0153] If in During the recovery period, the host has been targeted A new write request is initiated for the corresponding logical address. FTL has already remapped this logical address to a new physical address and will... If the corresponding old physical address is marked as invalid, the scheduling reconstruction module detects that the bitmap is marked as invalid or the version number has changed, and discards the newly recovered bitmap. It does not submit it to the dynamic aggregation buffer.

[0154] If the second verification confirms If the data is still valid, the scheduling reconfiguration module will... The corresponding logical address, old physical address, mapping version number, data length, and stripe number are encapsulated into a recovery packet. The recovery packet can have the following structure: Recover_Packet = {LBA, Data, Old_PBA, Length, Stripe_ID, Map_Ver, Valid_Ver}

[0155] Wherein, LBA represents the logical address corresponding to the recovered data; Data represents the recovered user data; Old_PBA represents the old physical address in the faulty die; Length represents the data length; Stripe_ID represents the old stripe number; Map_Ver represents the FTL mapping version number; and Valid_Ver represents the validity version number.

[0156] V. Dynamic Aggregation and New Band Generation

[0157] The dynamic aggregation module receives multiple recovery data packets and temporarily stores them in an internal data buffer unit. This internal data buffer unit can be either the controller's on-chip SRAM or a DRAM area protected by a power-down protection mechanism.

[0158] The dynamic aggregation module initiates the integration process according to preset trigger conditions. The preset trigger conditions include at least one of the following:

[0159] 1. The amount of data to be recovered in the internal data buffer unit reaches a capacity threshold, such as the data capacity of a superblock or a complete RAID stripe;

[0160] 2. The data packet's residence time in the buffer reaches the time threshold;

[0161] 3. The controller receives the host's FLUSH CACHE command;

[0162] 4. The solid-state drive is preparing to enter a low-power state;

[0163] 5. The reconstruction task is about to end, and the remaining recovery data needs to be persisted.

[0164] Once the preset trigger conditions are met, the dynamic aggregation module integrates the recovery data packets in the buffer. During integration, the controller can arrange them according to LBA order, write arrival order, hot / cold data attributes, or physical space allocation strategy. Subsequently, the FTL physical space allocator allocates new spare physical addresses for these recovery data packets and fills multiple recovery data pages into a new data stripe.

[0165] In a new 7D+1P stripe, the dynamic aggregation module can select 7 still valid recovery data pages as new data pages, denoted as follows: The parity generation unit recalculates a new parity check page for this new valid data set. :

[0166] (Formula 2)

[0167] in, This represents the 7 valid data pages in the new strip formed after dynamic aggregation; This refers to the parity check page recalculated for the new stripe. It only corresponds to the currently valid data set in the new strip, and the data set in the old strip. There is no inheritance relationship.

[0168] It should be noted that in the new strips The data can come from different older RAID stripes or correspond to different logical address ranges. Since the FTL mapping table records the mapping relationship between each LBA and the new PBA, the new stripe does not need to maintain the physical position order of the old stripe. This method enables effective data migration and reconstruction-driven garbage collection simultaneously during the recovery process, avoiding the writing of invalid data from the old stripe to the spare space as is.

[0169] VI. New stripe writing and atomic update of metadata

[0170] After the dynamic aggregation module generates new stripes, as well as As a new complete RAID stripe, it is written to the spare physical space. After a successful write, FTL performs an atomic update of the metadata, specifically including:

[0171] 1. Map the LBA in the recovery data packet to the new physical address PBA_new;

[0172] 2. Update the flag of the old physical address Old_PBA in the logical-physical mapping bitmap index to invalid;

[0173] 3. Update the flag of the new physical address PBA_new in the logical-physical mapping bitmap index to be valid;

[0174] 4. Assign a new stripe number, New_Stripe_ID, to the new stripe;

[0175] 5. Record the member number, physical address, and new parity page of each data page in the new stripe. The physical address;

[0176] 6. Bind the above mapping table update, bitmap update, and striped metadata update into the same metadata transaction.

[0177] In a preferred embodiment, the controller utilizes power-loss protection capacitors and transaction logs to ensure the atomicity of the aforementioned metadata updates. Specifically, after confirming successful new stripe writing, the FTL first writes the transaction log, including mapping table changes, bitmap changes, and new stripe metadata changes, to a power-loss-protected log area. Only after the transaction log is confirmed to be safely persistent does the controller commit the reconstruction completion status of the batch of recovered data. In the event of an unexpected power outage, the solid-state drive recovers to a consistent state via log replay after the next power-on.

[0178] VII. Abort and Recovery Mechanism under Concurrent Host Writes

[0179] During the reconstruction process, if a host initiates a write request for a logical address that is being restored or awaiting restoration, the controller prioritizes ensuring the host's write path. The concurrent processing module allocates a new physical address for the host's write request and writes the host's data to that new physical address. After a successful write, the FTL updates the mapping relationship between the logical address and the new physical address, and simultaneously updates the mark of the original physical address in the logical-physical mapping bitmap index to invalid, and increments the corresponding Map_Ver or Valid_Ver.

[0180] Before performing recovery, after completing XOR recovery, and before submitting the recovered data to the dynamic aggregation buffer, the scheduling and reconstruction module can query the corresponding bitmap marker or version number. If it finds that the data has become invalid due to host writes, it immediately aborts the corresponding recovery task and discards the old data that has been read or recovered. This mechanism avoids the recovery process from rewriting expired data into new stripes, thus ensuring the consistency between host-written data and internal reconstruction data.

[0181] 8. Write Amplification Analysis

[0182] In a 7D+1P architecture, if the stripe write overhead is defined as "total number of physical write pages / number of valid user data pages", then a fully new stripe contains 7 valid user data pages and 1 new parity page, and its theoretical stripe write overhead is:

[0183] WA_stripe = 8 / 7 ≈ 1.14

[0184] This value represents the necessary redundancy overhead of the RAID parity page. For a fixed 7D+1P structure, the theoretical value is 8 / 7, not strictly equal to 1. Only as the number of data members N increases does (N+1) / N gradually approach 1.

[0185] In contrast, if traditional reconstruction methods write invalid data pages from the old stripe to the spare space as is, it introduces additional invalid data write overhead beyond the necessary RAID check overhead, and creates storage fragmentation in the spare space. With the dynamic aggregation method in this embodiment, the controller only writes the still valid recovery data pages to the new stripe and regenerates parity data for the new stripe, thereby reducing invalid data writes and subsequent garbage collection pressure.

[0186] Through the above embodiments, the present invention achieves the following technical effects:

[0187] First, based on the logical-physical mapping bitmap index maintained synchronously by FTL, the controller can identify the valid physical address that truly needs to be recovered in the faulty die after the target die fails, and suppress the entire group of same-strip reconstruction read instructions for invalid target addresses, thereby reducing internal read amplification from the source.

[0188] Second, for the valid target address on the faulty die, the controller still reads the healthy member data and old parity data necessary for recovery according to the old RAID stripe parity relationship, ensuring that the RAID XOR recovery result is correct.

[0189] Third, the recovered valid data will not be written back to the old stripe structure as is. Instead, it will be dynamically aggregated to form new stripes and new checksums will be regenerated, thereby reducing invalid data writing and fragmentation of spare space.

[0190] Fourth, by restoring the secondary validity check before commit, mapping version numbers, and transaction log mechanisms, the concurrent conflicts between host write requests and background reconstruction tasks during the reconstruction period can be handled, and expired data can be prevented from being written back incorrectly.

[0191] Therefore, this embodiment can simultaneously reduce internal read amplification and write amplification during cross-die RAID reconstruction, shorten the effective data recovery time, and improve the service quality stability of solid-state drives under die failure degradation conditions.

[0192] Example 6

[0193] This embodiment will use a specific application scenario with extremely stringent requirements for storage performance and reliability to provide a complete and verifiable explanation of the deployment, execution process, and actual beneficial effects of the present invention.

[0194] This embodiment is set in the high-frequency trading (HFT) back-end system of a large financial service institution. The core of this system is a server cluster running an in-memory database and a real-time risk control model. Its business characteristics are as follows:

[0195] Extreme latency sensitivity: The write latency (P99.99 Latency) of each transaction log and market snapshot must be stable at the sub-millisecond level. Any latency spike exceeding 1 millisecond may cause slippage or misjudgment in risk control, resulting in direct economic losses.

[0196] High-intensity continuous writes: The system continuously records transaction flow and updates position information, forming a typical I / O-intensive workload of 70% random small block (4KB) writes and 30% reads.

[0197] Business continuity requirements: The system must operate 24 / 7 without interruption, and data security and service continuity are the highest priorities. Any degradation or recovery operation of the storage system must have minimal impact on front-end business operations.

[0198] Under such high-intensity write conditions, the off-site update characteristic of NAND flash memory causes a large number of invalid data pages to be generated rapidly inside the solid-state drive. After several weeks of continuous operation, the proportion of outdated data marked as invalid in the physical space of the storage system usually stabilizes between 40% and 50%. At this point, if a flash memory die experiences a physical failure, the long-term performance degradation caused by the traditional full-reconstruction mechanism is completely unacceptable for the HFT system.

[0199] To address the aforementioned challenges, the HFT system deploys a specially designed enterprise-grade solid-state drive equipped with the reconstruction device of this invention. Its hardware and solution configuration are as follows:

[0200] Physical hardware platform: A 15.36TB enterprise-grade E1.L form factor solid-state drive with a PCIe Gen5 x4 interface and compliant with the NVMe 1.4 protocol.

[0201] Controller: An ASIC SoC built on a multi-core ARM Cortex-R8 processor, integrating eight independent NAND flash memory channels.

[0202] Storage medium: Internally composed of 32 enterprise-grade 3D eTLC NAND flash memory chips.

[0203] Redundant array: The controller organizes 8 different channels of dies into a 7D+1P RAID-5 array at the physical level.

[0204] DRAM cache: 16GB of LPDDR4 DRAM with ECC error correction is configured to store the FTL master mapping table and the bitmap index of this invention.

[0205] Integration and configuration of the present invention:

[0206] The controller SoC incorporates all the hardware modules described in Embodiments 3 and 4: including a DMA engine (index acquisition module) dedicated to accessing bitmap indexes, an instruction sequence generator based on a hardware state machine (part of the scheduling and refactoring module), and a dynamic aggregation module containing 2MB of embedded SRAM and an independent XOR engine.

[0207] Bitmap Index: It adopts the independent and dedicated bitmap structure described in Example 2, with a management granularity down to 4KB sectors, in order to maximize reconstruction accuracy and cope with small block writes in HFT scenarios.

[0208] Aggregation strategy: The write aggregation capacity threshold of the dynamic aggregation module is precisely set to a superblock size that best matches the NAND multi-plane write characteristics, namely 16MB.

[0209] Firmware scheduling: In the task scheduler of the controller firmware, internal refactoring tasks are given a lower priority than host I / O tasks, but a minimum internal bus bandwidth guarantee of 20% is set for them to prevent task starvation and ensure that refactoring proceeds steadily in the background.

[0210] After several months of stable operation in the HFT system, the SSD's health monitoring firmware reported that one die on its third channel was about to fail due to a continuously rising read error rate exceeding the LDPC error correction limit, and was actively put offline. The controller immediately triggered the reconstruction method of this invention:

[0211] 1. Startup and Index Loading: The fault management firmware triggers a refactoring task. The DMA engine of the index acquisition module starts immediately, and high-speed fetches a bitmap index data block of approximately 64MB associated with the faulty die from the main DRAM into the SRAM inside the controller in just a few microseconds.

[0212] 2. Precise Task Generation: The fault analysis module firmware begins traversing the bitmap indices in the SRAM. Due to the workload, approximately 40% of the data is invalid. The analysis module skips these addresses and ultimately generates only a "list of valid data reconstruction tasks" containing approximately 60% of the physical addresses, which is then submitted to the scheduling reconstruction module.

[0213] 3. Partial Skip-Based Recovery: The hardware instruction sequence generator of the scheduling and reconstruction module begins operation. Following the task list, it precisely issues parallel partial read commands only to the other seven healthy dies within the same RAID stripe for those valid physical page addresses. This read operation can be observed on the I / O bus as "pulsating," rather than the continuous full-load state of traditional reconstruction.

[0214] 4. Seamless Handling of Concurrent I / O: During the refactoring process, a front-end application on a trading server submits an urgent closing order. The LBA (Local Block Address) for its write I / O happens to map to an old physical address on the faulty die that is awaiting recovery. The concurrent processing module firmware intercepts this request at the front end of the I / O path and detects an address conflict. Instead of blocking the request, it immediately allocates a completely new physical page from the FTL (Free Block Array)'s free block pool, writes the transaction data, and atomically updates the FTL mapping table. Simultaneously, it forcibly flips the valid bits of the old physical address corresponding to the LBA in the bitmap index to "0". When the refactoring module later processes this old address, it automatically cancels the recovery operation because the bitmap marker has become invalid. The entire process is virtually identical to a regular write operation for the host.

[0215] 5. High-efficiency dynamic aggregation: The recovered valid data sectors are continuously fed into the 2MB SRAM buffer of the dynamic aggregation module. When the accumulated data volume reaches 16MB, the monitoring and integration controller triggers the integration process, reorders these logically discrete data according to LBA, fills them tightly, and calculates new check data by the inline XOR engine. Finally, a complete and healthy 16MB superblock is written to the spare die in one go.

[0216] To objectively and reproducibly verify the beneficial effects of the present invention, a rigorous laboratory testing environment was established, and comparative tests were conducted on SSDs equipped with the solution of the present invention and SSDs of the same model equipped with the traditional full reconstruction solution.

[0217] Comparison environment:

[0218] Test platform: A standard 2U server equipped with an Intel Xeon Platinum processor and 256GB DDR4 ECC memory.

[0219] Devices under test (DUT): Two identical 15.36TB enterprise-grade SSDs as described above, with completely identical hardware. One of them was flashed with firmware that activates all functions of this invention (DUT-A), while the other was flashed with firmware that only retains the traditional full reconstruction mechanism (DUT-B) as a control group.

[0220] Workload generator: It uses the industry-standard fio tool and is configured to simulate a mixed workload of 70% random 4KB writes and 30% random 4KB reads in an HFT scenario.

[0221] Data source and comparison method:

[0222] 1. Preprocessing: Before testing, both SSDs underwent two full-disk fill preprocessing processes to bring them into a steady state where wear leveling was achieved and the proportion of invalid data was stabilized at approximately 40%.

[0223] 2. Fault Simulation: Using a dedicated tool provided by the manufacturer, an unrecoverable fault is injected simultaneously into the same physical location of the dies on two SSDs to trigger the reconstruction process synchronously.

[0224] 3. Data Acquisition: Throughout the reconstruction process, fio continuously runs and records latency data for each I / O operation. Simultaneously, the SSD controller's built-in Performance Monitoring Unit (PMU) collects real-time data on the bus bandwidth utilization and reconstruction progress of the internal NAND channels at 1-second intervals. Figure 5 The comparison chart shown is based on data collected from this comparative test. Figure 5 This is intended only to illustrate relative performance under specific test conditions and does not constitute a limitation on performance improvement for all SSD models, all invalid data ratios, or all workloads. During the test, DUT-A and DUT-B maintained the same NAND media, controller configuration, firmware version, OP ratio, and preprocessing flow, except for whether the reconstruction mechanism of this invention was enabled.

[0225] Reference Figure 5 A (Relationship between reconstruction time and invalid data percentage): The reconstruction time of DUT-B (existing technology) is a constant 52 minutes. DUT-A (this invention), in a scenario with 40% invalid data, has a reconstruction time of only 31.2 minutes, improving recovery efficiency by 40%. This is directly due to skipping the reading of invalid data regions.

[0226] Reference Figure 5 B (P99 response latency during reconstruction): DUT-B's P99 latency frequently exceeded 100 milliseconds during reconstruction, generating numerous "latency spikes" that could lead to transaction failures. In contrast, DUT-A, thanks to a significant reduction in internal I / O traffic and an efficient concurrent processing mechanism, maintained a P99 latency consistently below 15 milliseconds, fully meeting the stringent SLA requirements of HFT business.

[0227] Reference Figure 5 C (Internal bus bandwidth usage during refactoring): According to PMU monitoring data, the internal bus of DUT-B was almost continuously occupied during the refactoring period. In contrast, the bandwidth usage of DUT-A showed a pulsed pattern, with an average utilization rate about 40% lower than that of DUT-B, leaving sufficient performance redundancy for normal host I / O.

[0228] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A method for local dynamic reconstruction of cross-chip RAID stripes based on logical-physical mapping bitmap indexes, applicable to solid-state drives containing multiple flash memory chips and configured with flash translation layers, characterized in that, Includes the following steps: Obtain the logical-physical mapping bitmap index recorded in the flash conversion layer, which is used to characterize the validity of data in the multiple flash chips. The logical-physical mapping bitmap index is indexed by the physical address and is maintained synchronously with the update transactions of the FTL master mapping table. When a fault is detected in the target die, the physical address corresponding to the data marked as valid stored in the target die is parsed out based on the logical-physical mapping bitmap index. Based on the physical address corresponding to the data marked as valid, the solid-state drive is controlled to perform partial data reading from other healthy dies in the same RAID stripe as the target die to obtain the data required for reconstruction, and skips data reading from the physical addresses of the other healthy dies that correspond to invalid data in the target die. Using the data required for the reconstruction, the effective data in the target grain is recovered to obtain the recovered data; as well as The recovered data is dynamically aggregated to form a new data stripe, and this new data stripe is written to the spare physical space.

2. The method according to claim 1, characterized in that, The logical-physical mapping bitmap index is generated and maintained in real time by the flash memory translation layer during the process of performing logical address to physical address mapping and translation, tracking the data write, update or erase status of each physical storage unit at the data page or data sector level.

3. The method according to claim 1, characterized in that, The step of skipping the data reading of the physical address corresponding to invalid data in the target die in the other healthy dies specifically includes: When generating physical read instructions for the data required for the reconstruction, it is determined whether the target physical address in the target die is marked as invalid in the logical-physical mapping bitmap index; If the target physical address is marked as invalid, then the generation and sending of physical read commands to the address corresponding to the target physical address in other healthy dies within the same RAID stripe are suppressed.

4. The method according to claim 1, characterized in that, The step of dynamically aggregating the recovered data specifically includes: The recovered data is temporarily stored in an internal data buffer unit; The amount of recovery data temporarily stored in the internal data buffer unit is monitored. When the amount of data reaches the preset physical block write threshold, the temporarily stored recovery data is integrated, and new parity check data is generated for the integrated data. The integrated data, together with the new parity data, constitutes the new data stripe.

5. The method according to claim 1, characterized in that, In the process of recovering valid data from the target grain, the method further includes: If a host write request is received for a logical address on the target die, and the logical address is marked as valid in the logical-physical mapping bitmap index, then the data of the host write request is written to a new physical space, and the mapping relationship in the flash memory translation layer is updated; at the same time, the mark of the original physical address corresponding to the logical address in the logical-physical mapping bitmap index is updated to invalid, thereby terminating the recovery operation of the original physical address.

6. A cross-chip RAID stripe local dynamic reconstruction device based on logical-physical mapping bitmap index, applied to a solid-state drive containing multiple flash memory chips and configured with a flash translation layer, for implementing the method according to any one of claims 1-5, characterized in that, include: The index acquisition module is used to acquire the logical-physical mapping bitmap index recorded in the flash conversion layer, which is used to characterize the validity of data in the multiple flash chips. The logical-physical mapping bitmap index is indexed by the physical address and is maintained synchronously with the update transactions of the FTL master mapping table. The fault analysis module is used to parse out the physical address corresponding to the data marked as valid stored in the target die based on the logical-physical mapping bitmap index when a fault is detected in the target die. The scheduling and reconstruction module is used to control the solid-state drive to perform partial data reading from other healthy dies in the same RAID stripe as the target die, based on the physical address corresponding to the data marked as valid, to obtain the data required for reconstruction, and to skip data reading from the other healthy dies corresponding to the physical addresses of invalid data in the target die; and to use the data required for reconstruction to recover the valid data in the target die, thereby obtaining the recovered data; as well as The dynamic aggregation module is used to dynamically aggregate the recovered data to form new data stripes and write the new data stripes into the spare physical space.

7. A method for local dynamic reconstruction of cross-die RAID stripes based on logical-physical mapping bitmap indexes, applicable to solid-state drives containing multiple flash memory dies, configured with a flash translation layer, and employing a cross-die RAID stripe protection mechanism, characterized in that... Includes the following steps: Obtain the logical-physical mapping bitmap index maintained synchronously by the flash conversion layer. The logical-physical mapping bitmap index records whether the corresponding physical address unit currently stores valid user data, with physical pages, subpages, data sectors, or ECC codewords as the granularity. When a target die failure is detected, multiple target physical addresses in the target die are determined according to the RAID stripe mapping relationship, as well as a set of healthy die physical addresses that are in the same old RAID stripe as each target physical address; For each target physical address, query the logical-physical mapping bitmap index to determine whether the target physical address is marked as valid; If the target physical address is marked as invalid, the generation of reconstruction read instructions for the set of healthy dies physical addresses within the same old RAID stripe corresponding to the target physical address is suppressed, and the recovery operation for the target physical address is skipped. If the target physical address is marked as valid, then according to the RAID stripe mapping relationship, a reconstruction read instruction is generated for the healthy granule data page and / or parity page that participates in the old parity relationship within the same old RAID stripe, and the valid user data corresponding to the target physical address is recovered using the read data and parity data to obtain the recovered data; Before submitting the recovery data to the dynamic aggregation buffer, the logical-physical mapping bitmap index or the corresponding mapping version information is queried again to confirm that the data corresponding to the target physical address is still valid; if it is confirmed that it has been updated to invalid, the recovery data is discarded and the corresponding recovery task is aborted; if it is confirmed that it is still valid, the recovery data and the corresponding logical address information are encapsulated into a recovery data packet and written to the dynamic aggregation buffer. When the dynamic aggregation buffer meets the preset aggregation triggering conditions, multiple recovery data packets are integrated into a new data stripe, and new parity data is regenerated for the new data stripe. The new data stripe and its new parity data are written to the spare physical space, and after successful writing, the logical-physical mapping relationship, the logical-physical mapping bitmap index, and the corresponding new stripe metadata in the flash conversion layer are atomically updated.

8. The method according to claim 7, characterized in that, The step of determining the set of physical addresses of healthy dies based on the RAID stripe mapping relationship includes: querying the RAID stripe mapping table to obtain the stripe number, member number, intra-strip offset, and physical addresses of other members within the same old RAID stripe where the target physical address is located.

9. The method according to claim 7, characterized in that, The preset aggregation trigger conditions include: the amount of recovery data in the dynamic aggregation buffer reaches the capacity threshold, the residence time of the recovery data in the buffer reaches the time threshold, a host refresh command is received, or the solid-state drive is preparing to enter a low-power state.

10. The method according to claim 7, characterized in that, The mapping version information includes the mapping version number or validity version number corresponding to the logical address; when a host write request causes the corresponding logical address to be remapped to a new physical address, the mapping version number or validity version number is incremented so that the reconstruction task can identify and discard expired recovery data before submitting the recovery data; the new stripe metadata includes the new stripe number, the new stripe member physical address, the logical address corresponding to the recovery data packet, the data member sequence number, and the new parity page physical address.

Images