Bad block processing method of storage device, storage device and computer program product

Abstract

Embodiments of the present application disclose a bad block processing method of a storage device, the storage device and a computer program product. The bad block processing method comprises: replacing a bad block with at least one good block for replacement, and recording replacement information in a preset index structure; wherein the preset index structure comprises a first index area for storing a first index information set and a second index area for storing a second index information set; each first index information comprises a first identification field for recording an identification of the good block for replacement; and each second index information comprises a second identification field and a positioning field, the second identification field is used for recording an identification of a super block where the replaced bad block is located, and the positioning field is used for pointing to the first identification field. The present application can effectively reduce memory overhead and improve access efficiency.

Description

Technical Field

[0001] This application relates to the field of storage technology, and in particular to a method for handling bad blocks in a storage device, a storage device, and a computer program product. Background Technology

[0002] Data storage devices (such as SSDs and embedded storage devices like eMMC / UFS) incorporate NAND flash memory as the storage medium. When using flash memory, multiple physical blocks (PBs) are typically combined into a super physical block (SPB) for management. Please refer to [reference needed]. Figure 1 Each superblock SB1-SBN contains multiple physical blocks from different planes and chip selects (CE) C01-C04.

[0003] Flash memory often contains inherent bad blocks at the factory. In existing technology, when a physical block in a superblock fails, a good physical block is usually selected from the spare pool to replace it. Each superblock records complete information about all the physical blocks it contains, regardless of whether that physical block has been replaced. As the number of DIEs and Planes increases, the bad block replacement information that needs to be recorded grows exponentially, consuming a large amount of memory or storage space. Summary of the Invention

[0004] This application provides a method for handling bad blocks in a storage device, a storage device, and a computer program product, which effectively reduces storage overhead, improves access efficiency, and optimizes the bad block replacement process.

[0005] In a first aspect, embodiments of this application provide a method for handling bad blocks in a storage device, the method comprising:

[0006] Find at least one good block to replace the bad block, and record the replacement information in the preset index structure;

[0007] The preset index structure includes a first index area for storing a first set of index information and a second index area for storing a second set of index information.

[0008] Each entry of the first index information includes a first identifier field for recording the identifier of the good block used for replacement;

[0009] Each entry of the second index information includes a second identifier field and a location field. The second identifier field is used to record the superblock identifier where the replaced bad block is located, and the location field is used to point to the first identifier field.

[0010] By implementing the embodiments of this application, a hierarchical index structure consisting of a first index area and a second index area is constructed. The identifiers of good blocks and the superblock identifiers containing bad blocks are stored separately, and a mapping relationship between the two is established through a positioning field. The first index area is updated by "appending records," and then the positioning field in the second index information is modified to "switch" to the new record. This eliminates the need to rewrite the entire index table, achieving efficient in-situ updates. Each replacement only requires adding a pair of index information, allowing the index structure to dynamically expand as needed, avoiding the storage waste caused by pre-allocating fixed arrays in traditional schemes. Simultaneously, the second index information records the superblock identifier through a second identifier field, providing a foundation for subsequent superblock-based queries and optimizations.

[0011] In at least one possible implementation, the first index area stores only the first index information corresponding to the superblock that has been replaced, and each piece of the second index information also includes a bitmap field, which is used to mark the bad blocks that have been replaced in the superblock.

[0012] By implementing the embodiments of this application, by adding a bitmap field to the second index information, the specific location of the bad block involved in the replacement within the superblock can be accurately marked, providing an accurate basis for judging the replacement status for subsequent physical block access. This allows the first index area to store only the first index information corresponding to the superblock that has been replaced, without needing to record all superblock information, thus significantly reducing storage overhead.

[0013] In at least one possible implementation, each bitmap field is provided with a number of flag bits that correspond one-to-one with the physical blocks in the superblock.

[0014] By implementing the embodiments of this application, when a new replacement occurs, the status update can be completed simply by modifying the corresponding flag bit (from 0 to 1). Its index naturally corresponds to the offset position of the physical block, and the mapping relationship of "block position ↔ replacement status" can be established without additional identification, further saving storage space.

[0015] In at least one possible implementation, the first index area and the second index area are recorded sequentially from both ends of the storage area toward the middle.

[0016] By implementing the embodiments of this application, a layout method of recording sequentially from both ends to the middle is adopted, which realizes efficient utilization of storage space and avoids space waste caused by pre-dividing fixed areas.

[0017] In at least one possible implementation, the positioning field is set as an offset address or pointer of the first identification field relative to the first index area.

[0018] In implementing the embodiments of this application, the positioning field adopts the form of offset address or pointer, which provides flexibility for dynamic positioning.

[0019] In at least one possible implementation, the address length of each second index information is fixed.

[0020] In implementing the embodiments of this application, the address length of the second index information is fixed, which can support fast access based on offset.

[0021] In at least one possible implementation, the address length of the first index region is not fixed.

[0022] In implementing the embodiments of this application, the address length of the first index area is not fixed and can be dynamically expanded according to the number of replacement blocks to adapt to the needs of dynamic growth.

[0023] In at least one possible implementation, recording the replacement information in a preset index structure specifically includes:

[0024] In the first index area, a new first index entry is added, and the identifier of the good block used for this replacement is recorded in the first index entry;

[0025] In the second index area, add a new second index information, and set a second identifier field in the second index information to record the superblock identifier where the bad block being replaced this time is located;

[0026] In this second index information, a positioning field is set to point to the newly added first index information in the first index area;

[0027] In this second index information, a bitmap field is set to mark the flag bit corresponding to the bad block that was replaced as replaced.

[0028] By implementing the embodiments of this application, a dynamic index structure is achieved by adding a pair of index information with each replacement. The newly added first index information stores the good block identifier, and the newly added second index information stores the superblock identifier and points to the corresponding first index information. At the same time, the bad block location is recorded through a bitmap field. This "one replacement, two records" mechanism ensures that the information of each replacement is complete and independent, which facilitates subsequent querying and maintenance.

[0029] In at least one possible implementation, the method further includes:

[0030] In response to a physical block access request, the system searches the second index area for the superblock identifier of the physical block to be accessed. If the identifier does not exist, the system accesses the physical block directly.

[0031] If it exists, check whether the flag bit of the physical block to be accessed in the bitmap field that records the second index information of the superblock identifier is in the replaced state. If not, access the physical block directly.

[0032] If so, the first index information where the first identifier field points to is found based on the positioning field in the second index information, and the physical block corresponding to the good block identifier used for replacement in the first index information is accessed.

[0033] By implementing the embodiments of this application, transparent processing of bad block replacement is achieved through the above access process. When the accessed physical block has not been replaced, the original physical block is accessed directly; when it has been replaced, the corresponding first index information is located through the second index information to obtain the true good block identifier for access. The entire process is transparent to the upper-layer application, ensuring the correctness and continuity of data access.

[0034] In at least one possible implementation, checking whether the flag bit of the physical block to be accessed in the bitmap field that records the second index information of the superblock identifier is in a replaced state specifically includes:

[0035] Iterate through all the second index information that records the superblock identifier, and check whether the flag bit of the physical block to be accessed in the bitmap field of each second index information is in the replaced state, until a second index information with the flag bit in the replaced state is found.

[0036] By implementing the embodiments of this application, the situation where multiple bad blocks exist within the same superblock can be correctly handled by traversing the matching second index information and combining it with the bitmap field. Each piece of second index information corresponds to an independent replacement event, and its bitmap field marks the specific location of the replacement. The traversal search ensures that the access request can accurately match the correct replacement record.

[0037] In at least one possible implementation, the second index information in the second index area is arranged in order according to the value of the second identifier field, and a binary search method is used to search in the second index area for the existence of a superblock identifier where the physical block to be accessed is located.

[0038] By implementing the embodiments of this application, since the second index information is arranged in order according to the second identifier field, efficient algorithms such as binary search can be applied, and the target entry can be quickly located in O(log2n) time complexity, which significantly improves the search efficiency.

[0039] In at least one possible implementation, finding at least one good block for replacement to replace the bad block specifically includes:

[0040] After scanning all superblocks within the preset range and obtaining the number of bad blocks in each superblock's physical blocks, repeat the following steps until all bad blocks to be replaced have been replaced:

[0041] In the currently unprocessed superblocks, search for two superblocks that meet the preset swap conditions;

[0042] Replace the good block in one superblock that is to be replaced with the bad block to be replaced in another superblock.

[0043] In at least one possible implementation, the preset exchange condition includes at least a first exchange condition, wherein the first exchange condition is: the number of bad blocks to be replaced in one superblock is within a preset first threshold range, and the number of bad blocks to be replaced in another superblock is within a preset second threshold range.

[0044] In at least one possible implementation, the preset first threshold range is the maximum number of bad blocks and at least one good block, and the preset second threshold range is the minimum number of bad blocks and at least one bad block.

[0045] By implementing the embodiments of this application, the bad block distribution of each superblock is balanced through the iterative exchange algorithm of "most and least pairing", reducing unnecessary data movement.

[0046] In at least one possible implementation, the preset exchange condition further includes a second exchange condition, which is set so that the two superblocks are located in the same plane and / or the same chip select (CE).

[0047] By implementing the embodiments of this application, strict physical exchange conditions (same as Plane and / or same as CE) are used to ensure that the replacement operation conforms to the physical characteristics of NAND, thus avoiding potential failure risks caused by cross-region replacement.

[0048] In at least one possible implementation, if the second exchange condition is not met, one of the two superblocks is masked, and the above search and replacement steps are repeated in the remaining unmasked and unprocessed superblocks until all bad blocks to be replaced have been replaced.

[0049] By implementing the embodiments of this application, a temporary shielding mechanism is used to prevent the algorithm from looping infinitely on the same non-swap superblock, ensuring the convergence of the iterative process and driving the algorithm forward.

[0050] In at least one possible implementation, the superblock is masked by a temporary bitmap.

[0051] By implementing the embodiments of this application, the superblock can be masked by a temporary bitmap, which can achieve efficient marking of memory: each bit corresponds to a superblock, and setting "1" indicates that the superblock is "masked"; subsequent searches only need to check the corresponding bit, without the need to maintain a complex linked list or list, and the time and space overhead is minimal.

[0052] In at least one possible implementation, the superblock with the larger number of bad blocks is selected for shielding.

[0053] By implementing the embodiments of this application and shielding superblocks with a greater number of bad blocks, the algorithm can be ensured to converge to all possible optimal swaps within a finite number of steps. At the same time, high-quality resources are protected, currently infeasible goals are abandoned, the algorithm is propelled forward, resource waste and infinite loops are avoided, and the algorithm can achieve local optimal decisions as much as possible.

[0054] Secondly, embodiments of this application provide a storage device including a processor and a memory, the memory being coupled to the processor, the memory being used to store computer program code, the computer program code including computer instructions, and when the processor reads the computer instructions from the memory, causing the processor to execute steps in the bad block handling method of the storage device as described in the first aspect.

[0055] Thirdly, embodiments of this application provide a computer program product comprising: computer program code, which, when executed on a computer, causes the computer to perform the steps in the bad block handling method for a storage device as described in the first aspect.

[0056] The beneficial effects of this application are:

[0057] This embodiment of the application achieves separate storage of index information and mapping data by constructing a hierarchical index structure of a first index area and a second index area. The first index area focuses on storing the address information of good blocks that actually generate replacements and can be flexibly expanded according to the number of bad blocks that are actually replaced; the second index area points to the first index area through a positioning field, which allows the index structure to be organized more compactly and supports efficient searching. This structure significantly reduces memory overhead and improves search efficiency. Attached Figure Description

[0058] To more clearly illustrate the technical solutions in the embodiments of this application 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 some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0059] Figure 1 This is a schematic diagram of the architecture distribution of the storage device according to an embodiment of this application.

[0060] Figure 2 This is a flowchart illustrating a bad block handling method for a storage device according to an embodiment of this application.

[0061] Figure 3 This is a schematic diagram of the index structure according to an embodiment of this application.

[0062] Figure 4 This is a flowchart illustrating the physical block access process according to an embodiment of this application.

[0063] Figure 5 This is a flowchart illustrating the bad block replacement process according to an embodiment of this application.

[0064] Figure 6 This is a flowchart illustrating the index structure update process according to an embodiment of this application.

[0065] Figure 7 This is a schematic diagram of the structure of a storage device according to an embodiment of this application. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be described in detail below with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0067] It should be noted that: throughout the accompanying drawings, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions; in the description of this application, the terms "center," "longitudinal," "lateral," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on the scope of protection of this application; in the description of this application, "first," "second," etc., are only used to distinguish each other, and do not indicate their degree of importance or order, etc.

[0068] In the description of this application, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linkage" should be interpreted broadly. For example, they can refer to fixed connections, movable connections, or detachable connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; they can refer to the internal communication between two components, etc. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0069] Storage devices include a controller and non-volatile memory. The controller includes a processor and memory (such as SRAM / DRAM) that execute firmware to manage the non-volatile memory. The non-volatile memory consists of multiple blocks, which are physically organized into multiple superblocks (SPBs). Each SPB contains multiple physical blocks from different planes and chip selects (CEs). Due to manufacturing limitations and wear and tear from erasing and writing during use, some blocks may suffer permanent damage, becoming bad blocks. When bad blocks appear, they need to be replaced with other good blocks to ensure reliable data storage and access.

[0070] Existing bad block management typically uses a mapping table to record the correspondence between bad blocks and replacement blocks. Each superblock needs to record information about all physical blocks it contains, including block number, offset, etc. (memory consumption is 2 × Plane × CE), regardless of whether the block is replaced. The information of each block is usually represented by a WORD (usually 16-bit or 32-bit, depending on the system architecture). This means that the information of each block occupies a relatively large amount of space. If there are a large number of blocks in the storage system, the mapping table will become very large, consuming a lot of memory or storage space; when looking up and updating block information, it may be necessary to traverse the entire table, which is relatively inefficient. Therefore, the storage overhead of this method increases exponentially with the increase of hardware dimensions (number of Planes, number of CEs), resulting in serious waste of memory resources.

[0071] Other existing solutions employ a discrete dual-table structure (such as the Bad Block Marker Table (BBT) and the Block Retention Map Table (RTT), but queries require sequential access to both tables, limiting search efficiency.

[0072] In view of the above problems, the embodiments of this application aim to provide an efficient bad block handling scheme that utilizes the memory resource problem in NAND Flash storage devices, specifically including:

[0073] Only the physical block information that is actually replaced is recorded, and the blocks that are not replaced are not recorded in memory. This way, it is not necessary to record all array elements under a complete superblock, which greatly reduces memory usage.

[0074] When elements in the middle of a multidimensional array are removed and cannot be located directly by their index, a lightweight index structure is constructed to query the physical block information that was actually replaced, avoiding traversing all records, thereby improving the search efficiency of block operations and ensuring that bad block information can be retrieved quickly.

[0075] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating a bad block handling method according to an embodiment of this application. The method includes:

[0076] In step S100, at least one good block is found to replace the bad block.

[0077] In step S200, the replacement information is recorded in a preset index structure;

[0078] The preset index structure includes a first index area for storing a first set of index information and a second index area for storing a second set of index information.

[0079] Each entry of the first index information includes a first identifier field for recording the identifier of the good block used for replacement;

[0080] Each entry of the second index information includes a second identifier field and a location field. The second identifier field is used to record the superblock identifier where the replaced bad block is located, and the location field is used to point to the first identifier field.

[0081] By implementing the embodiments of this application, a hierarchical index structure consisting of a first index area and a second index area is constructed. The identifiers of good blocks and the superblock identifiers containing bad blocks are stored separately, and a mapping relationship between the two is established through a positioning field. The first index area focuses on storing the address information of the physical blocks (i.e., good blocks) actually used for replacement, and can be flexibly expanded according to the number of good blocks to be replaced. The second index area points to the first index area through a positioning field, allowing the index structure to be organized more compactly and supporting efficient searching. This structure effectively reduces memory overhead and improves search efficiency.

[0082] In at least one possible implementation, the first index area stores only the first index information corresponding to the superblock that has been replaced, and each piece of the second index information also includes a bitmap field, which is used to mark the bad blocks that have been replaced in the superblock.

[0083] By implementing the embodiments of this application, by adding a bitmap field to the second index information, the specific location of the bad block involved in the replacement within the superblock can be accurately marked, providing an accurate basis for judging the replacement status for subsequent physical block access. This achieves the goal of storing only the first index information corresponding to the superblock that has been replaced in the first index area, without having to record all superblock information, thus significantly reducing storage overhead.

[0084] In at least one possible implementation, each bitmap field is provided with a number of flag bits that correspond one-to-one with the physical blocks in the superblock.

[0085] By implementing the embodiments of this application, when a new replacement occurs, the state update can be completed simply by modifying the corresponding flag bit (from 0 to 1). Its index naturally corresponds to the offset position of the physical block, and the mapping relationship of "block position ↔ replacement state" can be established without additional identification, which further saves storage space. Compared with the traditional integer array or linked list, the bitmap compresses the storage overhead to the minimum (only 1 / 8 of the traditional solution).

[0086] Please refer to Figure 3 , Figure 3 This is a schematic diagram of the index structure according to an embodiment of this application. The index structure includes a first index area and a second index area.

[0087] The first index area is the region that actually stores the identifiers of good blocks used for replacement. In at least one possible implementation, the first index area is organized in a dynamically expanding manner, and each first index entry (i.e., a single entry) contains at least:

[0088] The first identifier field (PhyBlk) identifies the number of the good block used for replacement. This number is the address of the good block that was actually used to replace the bad block.

[0089] When a physical block is detected as bad, it needs to be replaced with a good block. The PhyBlk field records the identifier of the good block to be used for replacement. During the replacement operation, the good block to be used for replacement can be quickly found by querying the PhyBlk field.

[0090] The second index area is a region in the storage system used for indexing and managing storage block information. In at least one possible implementation, the second index area is organized in the form of fixed-length entries, each of which contains at least three fields:

[0091] The second identifier field (Block ID, BlkID) records the superblock number where the replaced bad block was located. This field is arranged sequentially in the second index area to support fast location algorithms such as binary search.

[0092] The positioning field (Block Offset, BlkOffset) is used to point to the corresponding first index information in the first index area. This positioning field can be an offset relative to the starting address of the first index area, or it can be a pointer.

[0093] The bitmap field (Block Bitmap, BlkBitmap) is used to mark replaced bad blocks in the superblock as replaced (i.e., which physical blocks have been replaced). This is very useful for file system operations such as garbage collection and defragmentation. Each bit corresponds to a physical block, and the state of the bit (0 or 1) indicates whether the block has been replaced.

[0094] This hierarchical index structure of "first index area + second index area" significantly reduces memory overhead and improves search efficiency. The first index information in the first index area can be dynamically expanded as needed, with entries added only when actual replacements occur, effectively avoiding the waste of space caused by pre-allocation; each second index information in the second index area has a compact structure and fixed length, and can reside in a high-speed cache (such as SRAM) to support fast search.

[0095] The collaborative working mechanism between the first index area and the second index area is as follows: When it is necessary to find the replacement information of a physical block in a superblock, the corresponding second index information is first located in the second index area by binary search based on the superblock identifier; then the bitmap field in the second index information is read to confirm whether the target physical block has been replaced; if it has been replaced, the value of the location field is used to jump to the corresponding first index information in the first index area, and the first identifier field is read from it to obtain the physical block number used for replacement.

[0096] In at least one possible implementation, the first index area and the second index area are recorded sequentially from both ends of the storage area toward the middle. This "growing from both ends toward the middle" layout maximizes the use of storage space and avoids space waste caused by pre-dividing fixed areas. The second index area grows from the low address end to the high address end, and the first index area grows from the high address end to the low address end. When the two meet in the middle, it indicates that the storage space is full, making full use of memory space.

[0097] In at least one possible implementation, the address length of each second index entry is fixed. This fixed address length allows the first index area to support random access and binary search; the controller can directly calculate the position of any entry using the offset without traversal. The address length of the first index area is not fixed, but is recorded based on the actual number of replaced blocks. For example, if one bad block is replaced, its address length is one PhyBlk field; if two bad blocks are replaced, its address length is two PhyBlk fields. This pattern continues, flexibly adapting to dynamic expansion requirements.

[0098] In at least one possible implementation, the first index area and the second index area are recorded sequentially from both ends of the storage area toward the middle. For example, the second index area is recorded from the beginning of the memory location, and the first index area is recorded from the end of the memory location, leaving the middle part empty. This avoids wasting space when filling memory.

[0099] By implementing the embodiments of this application, a layout method of recording sequentially from both ends to the middle is adopted, which realizes efficient utilization of storage space and avoids space waste caused by pre-dividing fixed areas.

[0100] In at least one possible implementation, the positioning field is set as an offset address or pointer of the first identification field relative to the first index area.

[0101] In implementing the embodiments of this application, the positioning field adopts the form of offset address or pointer, which provides flexibility for dynamic positioning.

[0102] In at least one possible implementation, the address length of the first index region is not fixed.

[0103] In implementing the embodiments of this application, the address length of the first index area is not fixed and can be dynamically expanded according to the actual number of replacement blocks generated to adapt to the needs of dynamic growth.

[0104] In at least one possible implementation, the address length of each piece of the second index information is fixed.

[0105] In implementing the embodiments of this application, the address length of the second index information is fixed, which can support fast access based on offset.

[0106] Please refer to Figure 6 , Figure 6 This is a flowchart illustrating the index structure recording / updating process according to an embodiment of this application. In at least one possible implementation, recording / updating the replacement information in the preset index structure specifically includes:

[0107] In step S301, a new first index information is added to the first index area, and the good block identifier used for replacement is recorded in the first index information.

[0108] In step S302, a new second index information is added in the second index area. A second identifier field is set in the second index information to record the superblock identifier where the bad block being replaced is located.

[0109] In step S303, a positioning field is set in the second index information to point to the newly added first index information in the first index area.

[0110] In step S304, in the second index information, a bitmap field is set to mark the flag bit of the bad block that was replaced in this superblock as replaced.

[0111] By implementing the embodiments of this application, a dynamic index structure is achieved by adding a pair of index information with each replacement. The newly added first index information stores the good block identifier, and the newly added second index information stores the superblock identifier and points to the corresponding first index information. At the same time, the bad block location is recorded through a bitmap field. This "one replacement, two records" mechanism ensures that the information of each replacement is complete and independent, which facilitates subsequent querying and maintenance.

[0112] Implementing the embodiments of this application, the first index area is updated by "appending records," and then the location field in the second index information is modified to "switch" to the new record, achieving efficient in-situ updates. This update method does not require rewriting the entire index table; it only requires appending a record and modifying the pointer, greatly improving update efficiency. Each replacement only requires adding a pair of index information, allowing the index structure to be dynamically expanded as needed, avoiding the storage waste caused by pre-allocating a fixed array in traditional schemes. Simultaneously, the second index information records the superblock identifier through the second identifier field, providing a foundation for subsequent superblock-based queries and optimizations. Old records can be retained for historical tracing or recycled when space is insufficient.

[0113] Please refer to Figure 4 , Figure 4 This is a flowchart illustrating the physical block access process according to an embodiment of this application. In at least one possible implementation, the method further includes:

[0114] In step S101, in response to a physical block access request, the second index area is searched for the superblock identifier of the physical block to be accessed. If it does not exist, the physical block is accessed directly.

[0115] In step S102, if it exists, check whether the flag bit of the physical block to be accessed in the bitmap field that records the second index information of the superblock identifier is in a replaced state. If not, the physical block is accessed directly.

[0116] In step S103, if so, the first index information where the first identifier field points to is found according to the positioning field in the second index information, and the physical block corresponding to the good block identifier used for replacement in the first index information is accessed.

[0117] Implementing the embodiments of this application, the above access process achieves transparent processing of bad block replacement. When the accessed physical block has not been replaced, the original physical block is accessed directly; when it has been replaced, the corresponding first index information is located through the second index information to obtain the true good block identifier for access. The introduction of the bitmap field allows the replacement location and replacement target to be obtained simultaneously in a single lookup process, eliminating the need for multiple accesses. The entire process is transparent to upper-layer applications, ensuring the correctness and continuity of data access.

[0118] In at least one possible implementation, checking whether the flag bit of the physical block to be accessed in the bitmap field that records the second index information of the superblock identifier is in a replaced state specifically includes:

[0119] Iterate through all the second index information that records the superblock identifier, and check whether the flag bit of the physical block to be accessed in the bitmap field of each second index information is in the replaced state, until a second index information with the flag bit in the replaced state is found.

[0120] By implementing the embodiments of this application, the situation where multiple bad blocks exist within the same superblock can be correctly handled by traversing the matching second index information and combining it with the bitmap field. Each piece of second index information corresponds to an independent replacement event, and its bitmap field marks the specific location of the replacement. The traversal search ensures that the access request can accurately match the correct replacement record.

[0121] In at least one possible implementation, the second index information in the second index area is arranged in order according to the value of the second identifier field, and a binary search method is used to search in the second index area for the existence of a superblock identifier where the physical block to be accessed is located.

[0122] By implementing the embodiments of this application, since the second identifier field (superblock number) in the second index information is arranged in order, efficient algorithms such as binary search can be applied. The binary search method can quickly locate the target entry in O(log2n) time complexity, which significantly improves the search efficiency.

[0123] Please refer to Figure 5 , Figure 5 This is a flowchart illustrating the bad block replacement algorithm according to an embodiment of this application. In at least one possible implementation, finding at least one good block for replacement to replace the bad block specifically further includes an iterative exchange process based on bad block statistics:

[0124] In step S201, all superblocks within a preset range are scanned to obtain information on the number of bad blocks in each superblock's physical blocks.

[0125] In step S202, the following steps are repeated until all bad blocks to be replaced have been replaced:

[0126] In step S2021, two superblocks that meet the preset swap conditions are searched out from the currently unprocessed superblocks.

[0127] In step S2022, a good block in one superblock is replaced with a bad block in another superblock. Specifically, this may include migrating the data stored in the bad block to the good block to be replaced and performing operations such as block number exchange.

[0128] In at least one possible implementation, the preset exchange condition includes at least a first exchange condition, which is: the number of unreplaced bad blocks in one superblock is within a preset first threshold range, and the number of unreplaced bad blocks in another superblock is within a preset second threshold range. For example, the preset first threshold range is the maximum number of bad blocks and at least one good block, and the preset second threshold range is the minimum number of bad blocks and at least one bad block. That is, among the currently unprocessed superblocks, the superblock with the maximum number of bad blocks and at least one good block (denoted as spb_max) and the superblock with the minimum number of bad blocks and at least one bad block (denoted as spb_min) are searched, and an attempt is made to replace the good blocks in spb_min with the bad blocks in spb_max.

[0129] This algorithm employs a greedy strategy, aiming to obtain as many complete superblocks (i.e., all physical blocks are intact) as possible with the fewest swaps. In each iteration, the algorithm selects the superblock with the most bad blocks and at least one good block (denoted as spb_max) and the superblock with the fewest bad blocks and at least one bad block (denoted as spb_min) for pairing and swapping. This selection prioritizes handling the most extreme cases, gradually balancing the distribution of bad blocks, thereby reducing the cost of subsequent swaps.

[0130] Specifically, spb_min has fewer bad blocks, meaning it's closest to complete (e.g., it only needs one good block to become complete), while spb_max has more bad blocks (e.g., it needs seven good blocks to become complete). By transferring one good block from spb_min to spb_max in a single swap, the number of bad blocks in spb_min increases by one, but the number of bad blocks in spb_max decreases by one. This process is similar to "peak shaving and valley filling," gradually making the distribution of bad blocks more even. In this way, the superblocks that originally required a large number of good blocks gradually reduce their demand, while the superblocks that were originally close to complete, although temporarily worsening, may later become spb_min again, thus having the opportunity to eventually become complete through multiple swaps.

[0131] In essence, this greedy strategy is equivalent to first trying to use one good block to alleviate a superblock that requires seven good blocks (i.e., a 1-for-7 trade), then trying a 2-for-6 trade, and so on. Each trade consumes a second index area space to record the replacement information. By prioritizing the handling of extreme cases, some superblocks can be brought to a complete state more quickly, thus completing the bad block optimization with fewer trades overall.

[0132] In at least one possible implementation, the preset swapping condition further includes a second swapping condition, which is set so that the two superblocks are located in the same plane and / or the same ChipsEnabled (CE). Due to the physical characteristics of NAND Flash, the circuitry between different planes or different CEs may differ, and direct cross-region replacement may lead to operational failure or data errors. Therefore, when determining whether swapping is possible, the physical blocks to be swapped are checked to ensure they meet the "same-level swapping" principle: that is, the good block and the bad block must come from the same physical plane and / or the same CE.

[0133] Besides the requirement for same-level swapping due to the physical characteristics of NAND Flash, some particle physical structures differ from normal real-world counterparts. For example, when there is logical remapping of physical planes (e.g., four physical planes, but two are used logically), the preset swapping conditions further include: the physical blocks to be swapped must be located within the same physical plane to match the physical hardware structure. Specifically, if the physical structure contains four physical planes P0, P1, P2, and P3, but logically they are defined as two logical planes, P0' and P1' (P0 and P2 are mapped to P0', and P1 and P3 are mapped to P1'), then the swapping must still be performed according to physical addresses: bad blocks in physical plane P2 must be replaced with good blocks in physical plane P2, and bad blocks in physical plane P3 must be replaced with good blocks in physical plane P3. They cannot be swapped across physical planes simply because they logically belong to the same plane.

[0134] In at least one possible implementation, if the second exchange condition is not met, the superblock is masked, and the above search and replacement steps are repeated in the remaining unmasked and unprocessed superblocks until all bad blocks to be replaced have been replaced.

[0135] Specifically, when the current spb_max and spb_min cannot be swapped due to physical mismatch, the algorithm marks the current spb_max as "masked" using a temporary bitmap. Then, it continues to search for a new spb_max (i.e., the superblock with the most second-worst blocks) among the remaining unprocessed and unmasked superblocks, and attempts to pair it with the current spb_min again. This masking mechanism prevents the algorithm from looping infinitely on the same non-swapable superblock, ensuring the convergence of the iterative process.

[0136] The bad block handling method of this application embodiment is described in detail below with specific examples.

[0137] This example uses a 1TB SSD, which contains 8 CEs and 2 Planes. Each SPB consists of 16 physical blocks (from different CEs and Planes). The SSD has a total of 1024 SPBs, and the number of blocks after replacement is 128.

[0138] Step 1: Initialization of the index structure

[0139] When an SSD is powered on for the first time, the controller scans all physical blocks and identifies factory-installed bad blocks. After the scan is complete, based on the bad block situation in the system, it generates the SBT (Super Bad Block Table) and PBT (Physical Bad Block Table), establishing an initial index structure and laying the foundation for subsequent replacement operations.

[0140] The first index area is organized in a dynamically expanding manner, with each entry having a fixed size of 2 bytes, storing only PhyBlk (the physical block number used for replacement).

[0141] The second index area is organized in the form of fixed-length entries, with the following structure:

[0142] BlkID (2 bytes): Superblock ID, ordered (0, 1, 2, ..., 1023).

[0143] BlkBitmap (2 bytes): A 16-bit bitmap corresponding to 16 physical blocks within an SPB (in this example, each SPB contains 16 physical blocks). A bit value of 1 indicates that the physical block has been replaced, and a bit value of 0 indicates that it has not been replaced.

[0144] BlkOffset (2 bytes): The offset (pointer) to the first index area.

[0145] The first and second index areas grow from both ends of the storage area toward the middle: the second index area grows upwards starting from address 0x0000, and the first index area grows downwards starting from address 0xFFFF.

[0146] Initially, both the first and second index areas are empty (no replacement).

[0147] Step 2: Bad Block Statistics and Optimization Algorithm Startup

[0148] As SSDs are used, some physical blocks become bad blocks due to excessive write cycles. Assume that after a period of use, the controller detects the following bad block distribution (simplified example, only some SPBs are listed):

[0149] SPB #50: 7 bad blocks (maximum);

[0150] SPB #20: 1 bad block count (minimum);

[0151] SPB #35: Number of bad blocks: 6;

[0152] SPB #30: Number of bad blocks: 5;

[0153] SPB #78: Number of bad blocks: 2;

[0154] ... (other SPBs).

[0155] The controller initiates the bad block optimization process, first scanning all SPBs to obtain the number of bad blocks in each SPB.

[0156] Step 3: First round of iterative exchange

[0157] Among the currently unprocessed SPBs, find the SPB with the most bad blocks and at least one good block (spb_max) and the SPB with the fewest bad blocks and at least one bad block (spb_min):

[0158] spb_max = SPB #50 (7 bad blocks);

[0159] spb_min = SPB #20 (number of bad blocks 1).

[0160] Check the exchange conditions:

[0161] The first exchange condition is satisfied (maximum and minimum pairings).

[0162] The second swap condition requires checking whether the physical blocks to be swapped are located in the same Plane and the same CE. For example, if a good block in SPB#50 is located in CE0, Plane0, and a bad block in SPB#20 is also located in CE0, Plane0, then the second swap condition is met.

[0163] Perform the swap operation:

[0164] Move the good block (physical block number P100) located at CE0, Plane0 in SPB #50 to SPB #20, and replace the bad block (physical block number P50) located at CE0, Plane0.

[0165] Mark the bad block (P50) in SPB #20 as unavailable, and mark the good block (P100) in SPB #50 as used (bad block data will be received later).

[0166] Update the index structure:

[0167] In the first index area, add a new first index record, PhyBlk = P100.

[0168] In the second index area, add a new second index entry with BlkID=20.

[0169] Set the BlkOffset of this second index information to point to the newly added entry PhyBlk= P100 in the first index area.

[0170] Set the BlkBitmap of this second index information to 1 (indicating that it has been replaced).

[0171] After one round of swapping, the number of bad blocks in SPB #20 decreased to 0, and the number of bad blocks in SPB #50 increased to 8.

[0172] Step 4: Handling cases where the exchange conditions are not met

[0173] Continue with the second round of iterations. The current spb_max is updated to SPB #35 (6 bad blocks), and spb_min is updated to SPB#78 (2 bad blocks).

[0174] Check the exchange conditions:

[0175] The first exchange condition is satisfied.

[0176] Second swap condition: Assume the bad block to be replaced in SPB #78 is located at CE1, Plane1, while all good blocks in SPB #35 are located at CE0, Plane0, making a match impossible. The swap condition is not met.

[0177] At this point, the algorithm marks SPB #35 as "masked in this round" using a temporary bitmap and re-searches for spb_max among the remaining unprocessed SPBs:

[0178] The new spb_max = SPB #30 (number of bad blocks 5).

[0179] spb_min remains SPB #78 (2 bad blocks).

[0180] Check the swap condition: Assume that the bad block to be replaced in SPB #78 is located at CE1 and Plane1, while there are exactly two good blocks in SPB #30 located at CE1 and Plane1, which satisfies the swap condition.

[0181] Perform the swap and update the index structure. The number of bad blocks in SPB #78 is reduced to 0, and the number of bad blocks in SPB #30 is increased to 7.

[0182] Step 5: Formation of a complete SPB

[0183] Assume that after one or more rounds of swapping, the number of bad blocks in SPB #20 gradually decreases. When the last round of swapping is completed and the number of bad blocks in SPB #20 becomes 0, the SPB becomes a "complete SPB", meaning that all physical blocks in the SPB are good blocks.

[0184] At this point, the controller marks SPB #20 as "fully available" in the metadata. Subsequently, when the host writes data to SPB #20, the FTL automatically redirects access that was originally pointing to the bad block P50 to the replacement block (good block) P100 by querying the index structure.

[0185] The following beneficial effects were achieved through the implementation of this example:

[0186] Storage overhead is significantly reduced:

[0187] The existing technology uses a multidimensional array structure RLp

[128] [2][8] to store replacement information. The total memory requirement is: number of replacement blocks (representing good blocks used for replacement) × 1 WORD per block (block number is recorded in WORD size) × 2 (1WORD = 2 bytes) × number of Planes (unit of NAND block) × number of CEs (NAND chip select) + extra index space (assuming block number 100 is replaced, the index of 100 is the index of array 0, so an index space is also required).

[0188] The total cost is: 128×2×2×8 + 1K (1024 SPBs) = 5120 BYTE, which is approximately 5K in size.

[0189] This example uses a hierarchical index structure. The total buffer requirement becomes: the number of blocks in the first index area + the total number of entries in the second index area. Assuming 128 replacements occur, each entry and each block occupies 1 WORD space, resulting in 128 replacements. The first index area has 128 good block numbers for replacement, and the second index area has 128 BlkIDs, 128 BlkOffsets, and 128 BlkBitmaps.

[0190] First index area: 128 good blocks, occupying 128 WORD spaces;

[0191] Second index area: 128 entries for the second identifier field + 128 entries for the positioning field + 128 entries for the bitmap field, each occupying 128 WORD spaces;

[0192] The total cost is: 128 + (128 + 128 + 128) = 512 Words, which is 1K in size.

[0193] Please refer to Table 1 below. Compared with the existing multidimensional array RLp

[128] [2][8], this example saves 4k of space in total buffer. This 4k space is the RAM space on the main controller. The saved space can be used to record other memory information on the main controller, allowing more programs or functional modules to run simultaneously with limited RAM resources. More importantly, the memory consumption of this example is proportional to the actual number of replacements, and the second index area only occupies space when a replacement occurs, regardless of the number of Planes / CEs, thus avoiding the dimension explosion problem.

[0194] Table 1. Comparison of Storage Methods

[0195]

[0196] Search efficiency has been greatly improved:

[0197] Traditional methods require sequential access to a multidimensional array to find and replace blocks, and the average number of searches increases with the number of bad blocks.

[0198] This example uses a binary search to locate the target entry in the second index area, requiring only log2(128) = 7 comparisons; then, it jumps directly to the first index area via the location field, obtaining the replacement block number in constant time. The overall search time is reduced from O(n) to O(log2n), significantly improving address translation efficiency.

[0199] The replacement and optimization effects are obvious:

[0200] Traditional sequential allocation strategies may lead to some SPB good blocks being over-consumed after multiple replacements, while other SPB good blocks remain idle, resulting in uneven wear.

[0201] The iterative swapping algorithm in this example balances the distribution of bad blocks across SPBs using a "maximum and minimum pairing" strategy, reducing unnecessary data movement and extending the overall lifespan of the SSD. Test data shows that after 1000 erase / write cycles, the variance in the number of bad blocks per SPB of the SSD using this approach is reduced by approximately 35% compared to traditional approaches.

[0202] Physical compatibility guarantee:

[0203] This example strictly adheres to the "same plane, same CE" exchange condition, ensuring that the replacement operation conforms to the physical characteristics of NAND even in complex scenarios with physical plane logic remapping, thus avoiding potential failure risks caused by cross-region replacement.

[0204] Please refer to Figure 7This application embodiment also provides a storage device, including a processor 100 and a memory 200, wherein the memory 200 is coupled to the processor 100 and is used to store computer program code, the computer program code including computer instructions, wherein when the processor 100 reads the computer instructions from the memory 200, the processor 100 performs the steps of the method in any possible implementation of any of the foregoing embodiments.

[0205] This application also provides a computer program product, which includes computer program code that, when run on a computer, causes the computer to perform the steps of the method in any of the possible implementations of the foregoing embodiments.

[0206] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0207] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the appended claims.

Claims

1. A method of bad block handling for a storage device, the method comprising: The bad block handling method for the storage device includes: Find at least one good block to replace the bad block, and record the replacement information in the preset index structure; The preset index structure includes a first index area for storing a first set of index information and a second index area for storing a second set of index information. Each entry of the first index information includes a first identifier field for recording the identifier of the good block used for replacement; Each entry of the second index information includes a second identifier field and a location field. The second identifier field is used to record the superblock identifier where the replaced bad block is located, and the location field is used to point to the first identifier field. The first index area stores only the first index information corresponding to the superblock that has been replaced, and each second index information also includes a bitmap field, which is used to mark the bad block that has been replaced in the superblock.

2. The bad block handling method of a storage device according to claim 1, wherein Each bitmap field is set with several flag bits that correspond one-to-one with the physical blocks in the superblock; and / or, the first index area and the second index area are recorded sequentially from both ends of the storage area toward the middle, respectively; And / or, the positioning field is set to the offset address or pointer of the first identifier field relative to the first index area; And / or, the address length of the first index area is not fixed; and / or, the address length of each second index information is fixed.

3. The bad block handling method for a storage device as described in claim 2, characterized in that, The step of recording the replacement information in the preset index structure specifically includes: In the first index area, a new first index entry is added, and the identifier of the good block used for this replacement is recorded in the first index entry; In the second index area, add a new second index information, and set a second identifier field in the second index information to record the superblock identifier where the bad block being replaced this time is located; In this second index information, a positioning field is set to point to the newly added first index information in the first index area; In this second index information, a bitmap field is set to mark the flag bit corresponding to the bad block that was replaced as replaced.

4. The bad block handling method for a storage device according to claim 2, characterized in that, The method further includes: In response to a physical block access request, the system searches the second index area for the superblock identifier of the physical block to be accessed. If the identifier does not exist, the system accesses the physical block directly. If it exists, check whether the flag bit of the physical block to be accessed in the bitmap field that records the second index information of the superblock identifier is in the replaced state. If not, access the physical block directly. If so, the first index information where the first identifier field points to is found based on the positioning field in the second index information, and the physical block corresponding to the good block identifier used for replacement in the first index information is accessed.

5. The bad block handling method for a storage device according to claim 4, characterized in that, The check of whether the flag bit of the physical block to be accessed in the bitmap field that records the second index information of the superblock identifier is in a replaced state specifically includes: Iterate through all the second index information that records the superblock identifier, and check whether the flag bit of the physical block to be accessed in the bitmap field of each second index information is in the replaced state, until a second index information with the flag bit in the replaced state is found.

6. The bad block handling method for a storage device according to claim 4, characterized in that, The second index information in the second index area is arranged in order according to the value of the second identifier field. A binary search method is used to search in the second index area for the existence of the superblock identifier of the physical block to be accessed.

7. The bad block handling method for a storage device according to any one of claims 1-6, characterized in that, The step of finding at least one good block for replacement and replacing the bad block specifically includes: After scanning all superblocks within the preset range and obtaining the number of bad blocks in each superblock's physical blocks, repeat the following search and replace steps until all bad blocks to be replaced have been replaced: In the currently unprocessed superblocks, search for two superblocks that meet the preset swap conditions; Replace a replaceable physical block in one superblock with a bad block to be replaced in another superblock.

8. The bad block handling method for a storage device according to claim 7, characterized in that, The preset exchange conditions include at least a first exchange condition, which is: the number of bad blocks in one superblock is within a preset first threshold range, and the number of bad blocks in the other superblock is within a preset second threshold range.

9. The bad block handling method for a storage device according to claim 8, characterized in that, The preset swap condition also includes a second swap condition, which is set so that the two superblocks are located in the same Plane and / or CE; and / or The preset first threshold range is the range with the most bad blocks and at least one good block, and the preset second threshold range is the range with the fewest bad blocks and at least one bad block.

10. The bad block handling method for a storage device according to claim 9, characterized in that, If the second exchange condition is not met, one of the two superblocks will be masked, and the above search and replacement steps will be repeated in the remaining unmasked and unprocessed superblocks until all bad blocks to be replaced have been replaced.

11. The bad block handling method for a storage device according to claim 10, characterized in that, Use a temporary bitmap to mask the superblock; and / or, select the superblock with more bad blocks from the two superblocks to mask.

12. A storage device, characterized in that, The device includes a processor and a memory coupled to the processor. The memory is used to store computer program code, which includes computer instructions. When the processor reads the computer instructions from the memory, the processor performs the steps of the bad block handling method for the storage device as claimed in any one of claims 1-11.

13. A computer program product, characterized in that, The computer program product includes: computer program code, which, when run on a computer, causes the computer to perform the steps in the bad block handling method for a storage device as described in any one of claims 1-11.

Images