Read failure processing method of solid state disk and solid state disk
By introducing a reread mechanism and comprehensively evaluating the status of physical blocks in DRAM-less solid-state drives, the problems of data loss and resource waste caused by uncorrectable errors are solved, achieving a balance between efficient resource utilization and reliability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- MAXIO TECHNOLOGY (HANGZHOU) CO LTD
- Filing Date
- 2025-10-29
- Publication Date
- 2026-07-28
AI Technical Summary
In DRAM-less solid-state drives, the permanent loss of data due to uncorrectable errors and the long-term locking of physical blocks lead to resource waste and decreased reliability.
A reread mechanism is introduced to reread data at logical addresses and invalidate physical addresses when the number of read failures exceeds a threshold, triggering garbage collection and moving valid data. Whether to remap is determined by combining the number of programming/erasing operations, the number of reads, and the data retention time.
It solves the problems of permanent data loss and long-term physical block locking caused by transient interference, and achieves a balance between efficient resource utilization and reliability.
Smart Images
Figure CN121560217B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of memory, and more specifically to a method for handling read failures of a solid-state drive and a solid-state drive. Background Technology
[0002] With the widespread adoption of solid-state drives (SSDs), DRAM-less SSDs have gained popularity in personal computers, industrial control, and data center caching layers due to their cost and power efficiency advantages from eliminating external caches. However, because this approach requires storing mapping tables, garbage collection information, and user data within on-chip cache units, its tolerable over-provisioning (OP) space is lower than that of DRAM-based cache architectures. Therefore, in DRAM-less SSDs, when the controller executes a read command for a logical address and detects an uncorrectable error (UNC), it marks the data as UNC and adds it to the uncorrectable error pool (unc pool), while simultaneously marking the physical block carrying the page as "merge done," preventing erasure. Subsequently, when the controller receives a read command for that logical address, it first checks if the data exists in the uncorrectable error pool. If it does, it directly reports the UNC to the host and does not continue reading from the flash memory chip.
[0003] While the above approach can quickly isolate bad blocks, it has two side effects: First, if the error originates from accidental factors such as transient noise or read voltage drift, the real data can still be recovered by rereading, while direct discarding results in permanent loss of user data; Second, locked physical blocks often still contain other valid fragments, and because the VFC (ValidFragment Count) cannot be zeroed, garbage collection (GC) cannot reclaim them into the free pool, resulting in wasted space on the solid-state drive. Summary of the Invention
[0004] In view of this, the present disclosure provides a method for handling read failures of a solid-state drive and a solid-state drive.
[0005] In a first aspect, embodiments of this disclosure provide a method for handling read failures in a solid-state drive, characterized in that it includes:
[0006] When a read command is received and the corresponding logical address has been recorded in the non-correctable table, if the corresponding record originates from a previous read failure, the data in the physical address corresponding to that logical address will be reread.
[0007] When the reread is successful, the corresponding record is removed from the uncorrectable table and garbage collection is triggered to move the valid data in the physical block where the physical address is located to the new physical block;
[0008] When a reread fails, the read failure count in the corresponding record is incremented;
[0009] When the read failure count of the corresponding record reaches the threshold, the physical address is set to invalid, and the number of valid segments of the physical block where the physical address is located is reduced by the number of corresponding logical addresses, so that the valid segment count of the physical block where the physical address is located can be reduced to zero and erasure is allowed.
[0010] In some embodiments, the method further includes: when the valid fragment count of the physical block where the physical address is located is 0, determining whether to remap based on the programming / erase count, read count, and data retention time of the physical block where the physical address is located.
[0011] In some embodiments, determining whether to remap based on the number of programming / erasing operations, read counts, and data retention time of the physical block where the physical address is located includes comparing the number of programming / erasing operations, read counts, and data retention time of the physical block where the physical address is located with multiple thresholds to determine whether the physical block needs to be remapped due to a sudden change in reliability.
[0012] In some embodiments, when the number of programming / erasing operations is less than a first lifetime threshold and the number of read operations is less than a first read threshold, or the data retention time is less than a first retention threshold, it is determined that the physical block is remapped due to a reliability mutation.
[0013] In some embodiments, during firmware idle periods, it is checked whether there are records in the uncorrectable error table where the read failure count has reached a threshold, or whether the valid segment count of the physical block containing the physical address corresponding to each logical address in the uncorrectable error table is 0.
[0014] In some embodiments, each record in the uncorrectable table includes a start logical address, an end logical address, a number of read failures, and a failure type flag, wherein the failure type flag includes programming failure and read failure.
[0015] In some embodiments, when a programming failure UNC is received from a flash memory chip, a programming failure record is added to the non-correctable error table; when a read failure UNC is received from a flash memory chip, a read failure record is added to the non-correctable error table.
[0016] In some embodiments, the solid-state drive is a DRAM-less solid-state drive.
[0017] Secondly, embodiments of this disclosure provide a solid-state drive, including a controller and a storage medium, wherein the controller executes the read failure handling method described above.
[0018] Thirdly, embodiments of this disclosure provide a computer-readable storage medium for storing one or more computer instructions, wherein when the computer instructions are executed, the read failure handling method described above is implemented.
[0019] In summary, the read failure handling method provided in this embodiment introduces a reread mechanism for uncorrectable errors and subtracts the number of corresponding logical addresses from the VFC when the number of read failures exceeds a threshold. This solves the problems of permanent data loss due to uncorrectable errors caused by transient interference or environmental noise, and the physical block being locked for a long time because the VFC of the physical block cannot be cleared due to the presence of data units with uncorrectable errors.
[0020] In a further embodiment, the physical block containing the uncorrectable error data unit is comprehensively evaluated and judged to decide whether to continue to retain it or remap it, thereby avoiding the complete abandonment of still usable physical blocks and the continued use of truly degraded bad blocks, thus achieving a balance between efficient resource utilization and reliability of the solid-state drive. Attached Figure Description
[0021] Figure 1 This is a flowchart of a solid-state drive read failure handling method provided in this embodiment of the disclosure;
[0022] Figure 2 A flowchart of updating the uncorrectable table according to an embodiment of this disclosure is provided;
[0023] Figure 3 Given Figure 1 A flowchart of a more specific implementation of steps S106 to S107 in the process;
[0024] Figure 4 Given Figure 1 A flowchart of a further embodiment of a read failure handling method;
[0025] Figure 5 A flowchart is provided to compare the number of programming / erasing operations, the number of read operations, and the data retention time of the physical block containing the uncorrectable data unit with multiple thresholds to complete the comprehensive evaluation and judgment of the corresponding physical block;
[0026] Figure 6 A schematic block diagram of a computing system containing a DRAM-less solid-state drive is provided. Detailed Implementation
[0027] The following description of embodiments of the present disclosure is based on examples, but the embodiments of the present disclosure are not limited to these embodiments. In the detailed description of the embodiments of the present disclosure below, certain specific details are described in detail. Those skilled in the art can fully understand the embodiments of the present disclosure even without these detailed descriptions. To avoid obscuring the essence of the embodiments of the present disclosure, well-known methods, processes, and flows are not described in detail. Furthermore, the accompanying drawings are not necessarily drawn to scale.
[0028] The flowcharts and block diagrams in the accompanying drawings illustrate possible system frameworks, functions, and operations of the systems, methods, and apparatuses according to embodiments of this disclosure. The blocks in the flowcharts and block diagrams may represent a module, program segment, or simply a piece of code. These modules, program segments, and code are all executable instructions used to implement a specified logical function. It should also be noted that the executable instructions implementing the specified logical function can be recombined to generate new modules and program segments. Therefore, the blocks and their order in the accompanying drawings are only used to better illustrate the processes and steps of the embodiments and should not be construed as limiting the invention itself.
[0029] Figure 1 This is a flowchart of a read failure handling method for a solid-state drive provided in this embodiment of the present disclosure. The read failure handling method can be formed into a computer program and exists in the solid-state drive in the form of firmware or software, including the following steps.
[0030] In step S101, a read command is received.
[0031] In step S102, it is determined whether the corresponding logical address has been recorded in the uncorrectable table and whether the corresponding record originated from a previous read failure. If so, step S103 is executed; otherwise, the conventional procedure is followed.
[0032] In step S103, the corresponding data is read again.
[0033] In step S104, it is determined whether the reading was successful. If successful, step S108 is executed; otherwise, step S105 is executed.
[0034] In step S105, the read failure count is accumulated in the corresponding record.
[0035] In step S106, it is determined whether the failure count of the corresponding record has reached the threshold. If so, step S107 is executed.
[0036] In step S107, the corresponding physical address is set to invalid, and its valid segment count is reduced by the number of corresponding logical addresses.
[0037] In step S108, the corresponding record is removed from the uncorrectable table and garbage collection is triggered to move the valid data to the new physical block.
[0038] In this embodiment, a read command can indicate one or more logical addresses, each logical address pointing to a data unit on the flash memory chip. This data unit can be a physical page or smaller than a physical page (for example, a 16K physical page contains four 4K data units). The address mapping table records the mapping relationship between the logical address and the physical address of the data unit. When a read command is received, the logical address in the read command is first used to search the uncorrectable error table to see if the logical address in the read command is already recorded and if the corresponding record was added because of a previous read failure. If so, the physical address is obtained by searching the address mapping table according to the logical address in the read command, and the data is reread from the flash memory chip according to the physical address. If the reread is successful, the corresponding record is removed from the uncorrectable error table and garbage collection is triggered to move the valid data in the physical block where the physical address is located to a new physical block. If the reread fails, the read failure count is incremented in the corresponding record. When the read failure count of the corresponding record reaches a threshold, the physical address is set to invalid, and the number of valid segments in the physical block where the physical address is located is reduced by the number of corresponding logical addresses.
[0039] In this case, invalidating a physical address can be achieved by replacing the corresponding physical address with NULL in the address mapping table.
[0040] The valid fragment count is a dynamic count designed for each physical block. This count accumulates or decreases with each host write, garbage collection relocation, and invalidation operation. When the controller first allocates user data to a free physical block, it sets the initial VFC of that physical block to zero. Subsequently, when new data is written to one of its data units, the VFC of that physical block is incremented by 1. When valid data from one of its data units is moved to a new physical block, the VFC of that physical block is decremented by 1, and the VFC of the new physical block is incremented by 1. In this embodiment, the number of data units whose read failure count exceeds the threshold is subtracted from the valid fragment count of the physical block containing the data unit whose read failure count exceeds the threshold. This is to avoid the problem that garbage collection cannot erase the physical block because the valid fragment count cannot be zeroed.
[0041] In summary, the read failure handling method provided in this embodiment introduces a reread mechanism for uncorrectable errors and subtracts the number of data units with read failure counts exceeding the threshold from the VFC of the physical block when the number of read failures exceeds the threshold. This solves the problems of permanent data loss due to uncorrectable errors caused by transient interference or environmental noise, and the problem of physical blocks being locked for a long time because the VFC of the physical block cannot be cleared due to the presence of uncorrectable data units.
[0042] In the above embodiments, the data structure of the non-error-correctable table can be, for example, Table 1.
[0043] Table 1
[0044] Starting logical address End logical address Read failure count (i.e., the number of times UNC is reported) Failure type flags (programming failure / read failure)
[0045] According to Table 1, Figure 2 A flowchart of the update process for the uncorrectable error table according to an embodiment of this disclosure is provided. As shown in the figure, when an uncorrectable error of programming failure is received from the flash memory chip, a record is added to the uncorrectable error table. The start and end logical addresses of this record are set to the start and end logical addresses of the data unit where the uncorrectable error occurred, the failure type flag is set to programming failure, and the read failure count is set to zero (i.e., step S202). When an uncorrectable error of read failure is received from the flash memory chip, if a corresponding record already exists in the uncorrectable error table, the read count is increased by the count value obtained based on the start and end logical addresses; if no corresponding record exists, a record of uncorrectable error of read failure is added (i.e., step S201).
[0046] According to Table 1, Figure 3 Given Figure 1 A flowchart of a more specific implementation of steps S106 to S107 in the above example is provided. This embodiment is implemented by firmware and specifically includes the following steps.
[0047] In step S301, it is determined whether the firmware is in an idle state. If it is, step S302 is executed; otherwise, the process ends.
[0048] In step S302, it is determined whether the uncorrectable table is empty. If not, step S303 is executed; if yes, the process ends.
[0049] In step S303, each record in the uncorrectable table is read sequentially.
[0050] In step S304, it is determined whether the number of read failures is greater than 3. If so, step S305 is executed; otherwise, the process ends.
[0051] In step S305, the start logical address and end logical address are read from the current record.
[0052] In step S306, the address mapping table is retrieved based on the start and end logical addresses in the current record, and the physical address in the matched record is set to NULL.
[0053] In step S307, the VFC in the physical block containing the start logical address and the end logical address is subtracted.
[0054] According to this embodiment, during firmware idle time, the uncorrectable error table is polled. If the uncorrectable error table is not empty, for records with more than 3 read failures, the starting logical address and ending logical address of the record are used to search the address mapping table. The physical address in the record in the searched address mapping table is set to NULL (i.e., the address is invalid). The corresponding physical block is found according to the starting logical address and ending logical address of the search, and the number of corresponding logical addresses is subtracted from the VFC of the corresponding physical block.
[0055] Figure 4 yes Figure 1 A flowchart of a further embodiment of a read failure handling method. Compared to Figure 1 Steps S109 and S110 have been added to the flowchart.
[0056] Steps S109 and S110 refer to... Figure 1 Based on the implementation examples, the system periodically or irregularly checks whether the valid fragment count of the physical block containing each uncorrectable data unit is 0. For physical blocks with a valid fragment count of 0, it determines whether to remap or continue to retain them based on the number of programming / erasing operations, the number of read operations, and the data retention time. Typically, when the system determines that a physical block can no longer be used, it is remapped to replace it with another physical block.
[0057] Therefore, this embodiment enables a comprehensive evaluation and judgment of each physical block containing an uncorrectable data unit to decide whether to retain it or remap it. This avoids completely abandoning still usable physical blocks and also avoids continuing to use truly degraded bad blocks, thereby achieving a balance between efficient resource utilization and reliability of the solid-state drive.
[0058] In some embodiments, the number of programming / erasing operations, the number of reads, and the data retention time of the physical block containing the uncorrectable data unit are compared with multiple thresholds to perform a comprehensive evaluation and judgment of the corresponding physical block, and to determine whether the corresponding physical block should be remapped or retained. Figure 5 A flowchart of this comprehensive evaluation and judgment is provided. This embodiment can be implemented by a single firmware.
[0059] refer to Figure 5As shown, after the VFC of the corresponding physical block is cleared, the firmware checks the programming / erasing write count, read count, and data retention time of the corresponding physical block. Taking the first level THR0 as an example, when the programming / erasing write count is less than PE_THR0, the physical block will be remapped if the read count is less than READ_THR0 or the data retention time is less than data_retention_thr0. The reason is that PE_thr0 corresponds to the BOL stage of the flash memory chip. At this time, the state of the flash memory chip is relatively good and should not have uncorrectable errors unless the flash memory chip undergoes a sudden change, thus requiring remapping. Otherwise, it is considered that the flash memory chip itself has no problem and does not need to be remapped. In the figure, PE_THR0, PE_THR1, PE_THR2, DATA_REN_THR0, DATA_REN_THR1, DATA_REN_THR2, READ_THR0, READ_THR1, and READ_THR2 are all determined by the DSP after conducting reliability experiments on the flash memory chip.
[0060] This strategy can prevent physical blocks from being released or remapped due to environmental factors in extreme scenarios, thus reducing the available space and lifespan of the solid-state drive.
[0061] Figure 6 A schematic block diagram of a computing system containing a DRAM-less solid-state drive is provided. The computer system 600 includes a host 610, a controller 620, and a memory 630. The controller 620 and the memory 630 constitute the solid-state drive.
[0062] The host interface 621 of the controller 620 is connected to the host 610. The host interface 621 is, for example, a SATA, M.2, mSATA, or PCI-E interface. The processor 623 is connected to the host interface 621, the cache controller 624, and the storage media interface 628. The cache chip in the controller 620 stores a mapping table of logical addresses to physical addresses and an FTL (Flash Translation Layer) composed of software programs. The processor 623 executes the software programs in the FTL so that the operating system and file system of the host 610 can access the solid-state drive. The FTL also supports multi-level storage units, bad block management, wear leveling, garbage collection, power-off recovery, and write balancing technologies. The FTL is also used to maintain a mapping table from logical addresses to physical addresses. It updates the mapping table based on the read / write operations performed by the host 610 on the solid-state drive. Specifically, when the host 610 performs a write operation, the FTL of the controller 620 receives a host command from the host 610, maps the logical address in the command to a physical address, which represents the location in the memory 630, organizes the data to be written into physical pages, and writes them one by one into the memory 630, updating the mapping table. During a read operation, the controller 620 controls the FTL to map the logical address in the command to a physical address, reading data from the corresponding location in physical pages.
[0063] The cache chip of the controller 620 is an internal SRAM chip 625. Because SRAM chips are expensive and limited by the internal space of the controller 620, software programs are typically used to improve their efficiency.
[0064] The memory 630 is composed of flash memory chips. The storage medium interface 628 of the controller 620 connects to multiple flash memory chips via multiple channels (CH0 and CH1). Flash memory chips connected to the same channel form a logical unit (LU), and each logical unit has a logical unit number (LUN). Each flash memory chip can be divided into multiple physical blocks, each physical block can be divided into multiple physical pages, and each physical page is composed of storage cells such as SLC, MLC, and QLC.
[0065] In computer system 600, the read failure handling method provided in the above embodiments can be formed as a computer program in controller 620 (e.g., as part of FTL). Controller 620 receives read commands from host 610. When an uncorrectable error occurs in a read command for a certain logical address, when a read command for that logical address is received again, the corresponding processing is performed according to the above embodiments.
[0066] Accordingly, this disclosure also provides a computer-readable storage medium that stores one or more computer instructions, which, when executed, implement the steps of the methods described in the above embodiments.
[0067] The above description is merely a preferred embodiment of this disclosure and is not intended to limit the scope of this disclosure. For those skilled in the art, various modifications and variations can be made to this disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the protection scope of this disclosure.
[0068] The embodiments of this disclosure are as described above. These embodiments do not exhaustively describe all details, nor do they limit the invention to the specific embodiments described. Obviously, many modifications and variations can be made based on the above description. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the embodiments of this disclosure, thereby enabling those skilled in the art to make good use of the embodiments of this disclosure and modifications based on them. The embodiments of this disclosure are limited only by the claims and their full scope and equivalents.
Claims
1. A method for handling read failures of a solid-state drive, characterized in that, include: When a read command is received and the corresponding logical address has been recorded in the non-correctable table, if the corresponding record originates from a previous read failure, the data in the physical address corresponding to the logical address will be read again. When the reread is successful, the corresponding record is removed from the non-correctable table and garbage collection is triggered to move the valid data in the physical block where the physical address is located to the new physical block; When a reread fails, the read failure count in the corresponding record is incremented; When the read failure count of the corresponding record reaches the threshold, the physical address is set to invalid, and the number of valid segments of the physical block where the physical address is located is reduced by the number of corresponding logical addresses, so that the valid segment count of the physical block where the physical address is located can be reduced to zero and erasure is allowed.
2. The read failure handling method according to claim 1, characterized in that, Also includes: When the valid fragment count of the physical block containing the physical address is 0, a decision is made on whether to remap based on the number of programming / erasing operations, read count, and data retention time of the physical block containing the physical address.
3. The read failure handling method according to claim 2, characterized in that, The step of determining whether to remap based on the number of programming / erasing operations, read counts, and data retention time of the physical block where the physical address is located includes comparing the number of programming / erasing operations, read counts, and data retention time of the physical block where the physical address is located with multiple thresholds to determine whether the physical block where the physical address is located needs to be remapped.
4. The read failure handling method according to claim 3, characterized in that, When the number of programming / erasing operations is lower than the first lifetime threshold and the number of reads is lower than the first read threshold, or the data retention time is lower than the first retention threshold, it is determined that the physical block where the physical address is located needs to be remapped due to a sudden change in reliability.
5. The read failure handling method according to claim 2, characterized in that, During firmware idle periods, check whether there are records in the uncorrectable error table where the read failure count has reached a threshold, or check whether the valid segment count of the physical block containing the physical address corresponding to the logical address in the uncorrectable error table is 0.
6. The read failure handling method according to claim 1, characterized in that, Each record in the uncorrectable error table contains a start logical address, an end logical address, the number of read failures, and a failure type flag, whereby the failure type flag includes programming failure and read failure.
7. The read failure handling method according to claim 6, characterized in that, When a programming failure UNC is received from the flash memory chip, a programming failure record is added to the non-correctable error table. When a read failure UNC is received from the flash memory chip, a read failure record is added to the non-correctable error table.
8. The read failure handling method according to any one of claims 1 to 7, characterized in that, The solid-state drive is a DRAM-less solid-state drive.
9. A solid-state drive, comprising a controller and a storage medium, wherein the controller performs the read failure handling method as described in any one of claims 1 to 7.
10. A computer-readable storage medium for storing one or more computer instructions, wherein when executed, the computer instructions implement the read failure handling method as described in any one of claims 1 to 7.