Mitigating Data Decoding Failures Using Data Logs

This application claims priority to U.S. Provisional Patent Application No. 63/675,738 entitled “MITIGATING DATA DECODING FAILURES USING DATA LOGS,” filed Jul. 26, 2024, which is incorporated herein by reference in its entirety.

The present disclosure generally relates to reducing an uncorrectable bit error rate (UBER) of a solid state drive (SSD) and, for example, to mitigating the UBER using data tracking logs for reclaimed virtual blocks.

Solid State Drives (SSDs) have revolutionized data storage technology, offering significant improvements in speed, reliability, and energy efficiency compared to traditional hard disk drives. SSDs utilize NAND flash memory, a type of non-volatile storage technology that retains data even when power is removed. This characteristic makes NAND flash memory ideal for portable devices and data centers alike, where data integrity and quick access are paramount.

NAND flash memory is composed of memory cells arranged in a grid-like structure. These cells store data by trapping electrical charges, with the presence or absence of charge representing binary data. Modern NAND flash memory may use multiple bits per cell, such as in Single-Level Cell (SLC), Multi-Level Cell (MLC), Triple-Level Cell (TLC), or Quad-Level Cell (QLC) configurations. This multi-level approach allows for higher storage densities, albeit at the cost of increased complexity in read and write operations.

SSDs incorporate NAND flash memory chips (referred to herein as “flash memory devices”) along with a controller that manages various operations, including data read/write, wear leveling, and error correction. The controller facilitates optimizing the performance and longevity of the SSD by distributing write operations evenly across the drive, a process known as wear leveling. This helps to prevent premature failure of individual memory cells due to excessive use.

As NAND flash memory cells age or experience repeated program/erase cycles, they may become less reliable, potentially leading to data errors. To mitigate this issue, SSDs employ various error correction techniques, such as Error Correction Code (ECC) and Low-Density Parity-Check (LDPC) codes. These mechanisms help to detect and correct bit errors, ensuring data integrity. However, as the NAND flash memory ages further, more sophisticated techniques may be necessary to maintain the drive's reliability and performance.

NAND flash memory devices may be organized into hierarchical structures to facilitate efficient data management and access. At the highest level, a flash memory device may be divided into one or more planes, which are independent units that can operate in parallel to improve performance. Each plane may contain multiple blocks, which are the basic units for erase operations in NAND flash memory.

Blocks are further subdivided into wordlines (or physical wordlines), which are groups of memory cells that share a common control gate. Wordlines are typically programmed together as a unit. Each wordline may contain one or more pages, which are the smallest addressable units for read operations. The size of a page may vary depending on the specific NAND flash memory architecture, but it is often in the range of 2 to 16 kilobytes. The term “wordline” (as used herein alone or individually) may be used to refer to a physical wordline. In contrast, the term “virtual wordline” may be used to refer to a logical construct that spans multiple physical wordlines, which can contain multiple physical pages.

To enhance performance and manage data across multiple flash memory devices, SSDs may implement the concept of virtual blocks. A virtual block (VB) is a logical construct that spans multiple physical blocks across different logical unit numbers (LUNs). LUNs are individual addressable units within a NAND flash memory device, and multiple LUNs may be present in a single device. By grouping physical blocks from different LUNs into a VB, the SSD controller can perform operations such as garbage collection and wear leveling more efficiently across the entire drive.

In some cases, a VB has a size that varies according to number of bad blocks. For example, if there are no bad blocks, the size=(#Channels)×(#Targets)×(#LUNs)×(Physical Block Size). A VB may include multiple virtual pages. A virtual page is a collection of pages across all LUNs in a VB. Typically, a reliability of the SSD decreases as the age of the non-volatile memory device increases. The decrease in reliability leads to an increase in read errors.

A method comprising: detecting a failure associated with data obtained, using a first physical address, from a current physical location of a non-volatile memory device; determining, based on detecting the failure, a virtual block number based on the first physical address; determining that the virtual block number identifies a garbage collection block; determining a virtual wordline of the garbage collection block; obtaining, from the virtual wordline, a data log that identifies a second physical address for a previous physical location of the data; and obtaining, using the second physical address, the data from the previous physical location.

A system comprising: a controller to: detect a decoding failure associated with data obtained, using a first physical address, from a current physical location of a non-volatile memory device, wherein the data is obtained based on a read retry operation associated with the first physical address, and wherein the data is obtained from a block of the non-volatile memory device; determine that the block is a garbage collection block; determine a second physical address of a previous physical location of the data, wherein the second physical address is determined using information regarding the garbage collection block; and perform a read operation using the second physical address.

A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a controller, cause the controller to: detect a decoding failure associated with data obtained, using a first physical address, from a current physical location of a non-volatile memory device, wherein the data is from a block of the non-volatile memory device; determine that the block is a garbage collection block; determine a second physical address of a previous physical location of the data, wherein the second physical address is determined using information from a virtual wordline of the garbage collection block; and perform a read operation using the second physical address.

The following detailed description of example implementations refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.

A solid state drive (SSD) may provide data regarding the SSD to a host device associated with the SSD. As indicated above, an SSD may include multiple non-volatile memory devices. Blocks, of the multiple non-volatile memory devices (or dies of the multiple non-volatile memory devices), may form a virtual block (VB). The VB is a collection of blocks (e.g., memory blocks) across multiple logical unit numbers (LUNs). As used herein, a “block” is used to refer to a physical block. A physical block may be part of (or, in other words, may be included in) a virtual block.

Blocks, in the VB, may have the same program/erase (P/E) cycles. A controller of the SSD may maintain separate pools of VB for user data and system data. System data may be stored on Single-Level Cell (SLC) blocks due to the high reliability requirement for the system data whereas user data may be stored on Triple-Layer Cell (TLC) blocks. Some blocks may be reserved per die to be replacements for bad blocks. Typically, a reliability of the SSD decreases as the age of the non-volatile memory device increases. The decrease in reliability leads to an increase in read errors.

Currently an error correction code (ECC) correction rate (CR) of a low-density parity-check (LDPC) hard decoder is around 0.9%. But an uncorrectable bit error rate (UBER) for the SSD drive may be significantly higher, typically <1 sector per 10{circumflex over ( )}17 bits read. To achieve a desired correction rate, sometimes a controller (e.g., firmware) may perform operations such as read retry, threshold voltage (Vth) tracking, soft LDPC decoding, and/or a redundant array of independent disks (RAID) recovery procedure to find the correct read threshold voltage. Such operations not only increase read latency but also can cause read disturb on surrounding pages due to repetitive reads on a target page. Typically, predictable read latency is desired by end users of the SSD. The read disturb degrades the reliability of the semiconductor device.

Implementations described herein are directed to a technical solution to the technical problem of achieving predictable read latency. Additionally, implementations described herein are directed to a technical solution to the technical problem of reducing the UBER of the SSD. In this regard, the technical solution includes a method to keep track of an older location of the data and, in case of reclaimed data, to retrieve the data from the older location in the event of repetitive ECC decoding failures in a current physical location during read retry operations. In some examples, “reclaimed data” may refer to data that is deemed corrupted/unreadable after an error correction operation is performed on the data. In some examples, “reclaimed data” may include data that was cleaned up (or deleted) as part of a garbage collection operation. The garbage collection operation may have been performed because the data may have become obsolete (e.g., user data that is not frequently accessed by the host). An older version of the data may be re-used and thus reclaimed, in the event a current version of the data (requested by the host) is not readable. In some examples, “reclaimed data” may refer to data that has been recovered from a particular block considered unusable. For example, the data may be moved from the particular block to another block prior to the particular block being scheduled for a garbage collection operation.

For example, implementations described herein are directed to a method of tracking a previous location of garbage collection (GC) data and reading the data from the previous location in the event a read operation, on a current location of the data, causes ECC decoding failures which cannot be recovered using read retry operations (e.g., using read retry voltage shift values). Some implementations described herein improve read latency (QoS) by generating and storing data logs (also referred to as data tracking logs) for reclaimed virtual blocks. In some examples, the “reclaimed virtual block” may include a garbage collection virtual block with a same or older version of data in a current virtual block. In some examples, a “reclaimed virtual block” may refer to a virtual block that is being used to store data after previously being scheduled for a garbage collection operation. In some examples, one or more remedial actions may be performed on the reclaimed virtual block to enable the reclaimed virtual block to be used to store after previously being scheduled for a garbage collection operation.

The data logs may be included on garbage collection blocks containing cold data. In some examples, the data logs may be included at the end of a virtual wordline, of a garbage collection block, before parity pages of RAID. In some examples, “cold data” may refer to data that is old and has not been accessed for a threshold amount of time. A data log will record a prior physical address of a reclaimed data frame in the virtual wordline and use the prior physical address to read the data in the event of read retry attempts failing to recover the data in a current virtual block. As used herein, a “garbage collection block” may be used to refer to a block scheduled for a garbage collection operation.

A garbage collection operation is a process used to manage and optimize the storage space within the drive. In NAND flash memory, data cannot be directly overwritten; instead, it must be erased before new data can be written to the same location. Erase operations may occur on a block as a whole whereas write operations may occur on one or more wordlines. Garbage collection is the mechanism by which an SSD identifies and consolidates valid data from multiple blocks (mostly storing invalid data) into new blocks, allowing the old blocks to be erased and reused for future write operations.

The garbage collection process may involve copying valid data from multiple blocks (mostly storing invalid data) to a new block, then erasing the original blocks. In some examples, the blocks may be referred to as fragmented blocks. A fragmented block may refer to a fully filled block that includes data unused by a host. This operation frees up space and helps maintain the SSD's write performance over time. Garbage collection may be triggered when the number of free blocks falls below a certain threshold or during periods of low drive activity. By efficiently managing the available storage space and reducing fragmentation, garbage collection facilitates maintaining the overall performance and longevity of SSDs.

In some examples, during a garbage collection operation, a controller of the SSD may keep track of an older location of reclaimed data using a data log. The data log may be placed at the end of a programmed virtual wordline. In some situations, to avoid data retention issues on the reclaimed data in an older garbage collection block, a dummy refresh read may be performed on the older garbage collection block. The older garbage collection block may be in a free state. In other words, data of the older garbage collection block may be deleted because the data is unused by a host. As used herein, a “garbage collection block” may refer to a block scheduled for a garbage collection operation. In this regard, an “older garbage collection block” may refer to a block that has been scheduled for a garbage collection operation for a period of time. As used herein, a “dummy refresh read” may refer to a read operation, not initiated by a host device, that is performed to maintain data integrity. In some situations, a garbage collection operation, for a given block, may be performed multiple times. Accordingly, the SSD may include multiple copies of data with different timestamps, While the multiple copies of the data are unknown to the host, the multiple copies of the data are known to the SSD (e.g., a controller of the SSD). In this regard, as described herein, the controller may use one or more of the multiple copies of the data to recover the data requested by the host, in the event a current copy of the data has become unreadable. In some implementations, the controller may maintain, in a virtual block information table, information for different virtual blocks. For example, the information may indicate whether a virtual block is a host write block or a GC block. As used herein, a “host write block” (or “host block”) may refer to a virtual block that stores data received from a host device.

Implementations described herein reduce the overall UBER of the SSD and improve device reliability of the SSD. These implementations may reduce read latencies and improve QoS of the drive by avoiding triggering heroic data recovery procedures when another copy of data is available. Heroic data recovery procedures are used in an attempt to recover data when the level of data corruption is too great for standard data recovery techniques to be successful. As used herein, “heroic data recovery” refers to measures above and beyond standard data recovery techniques such as ECC. Heroic data recovery techniques are also typically much more time intensive than standard recovery techniques. An example of a heroic data recovery technique includes retrying a read operation one or more times using adjusted voltage reference values. Other examples of heroic data recovery techniques include Single Bit Soft Bit Error Recovery (SBSBER) methods with multiple soft-bit and hard-bit attempts. Generally, heroic data recovery techniques take longer and utilize more computational resources than standard data recovery methods and are often unsuccessful. Hence, employing heroic data recovery techniques can often be a waste of time and resources. Implementations described herein enhance drive life by reducing read disturb on a target page and neighboring pages caused by repetitive reads on erroneous pages. The repetitive reads may be from state-of-the-art heroic data recovery mechanisms.

1 FIG. 100 100 102 104 1 104 2 104 3 102 104 1 104 2 104 3 106 102 110 illustrates a block diagram of a systemfor managing data in a solid-state drive (SSD). The systemmay include an SSD controllerconnected to multiple flash memory devices-,-, and-. The SSD controllerand the multiple flash memory devices-,-, and-may be included in an SSD. The SSD controllermay also be connected to a host device, which can send read and write commands to the SSD. This configuration allows for efficient data management and improved reliability in non-volatile memory systems.

100 112 114 116 118 The systemincorporates a data tracking mechanism, shown in example. This mechanism involves three blocks representing different stages of data storage: a GC block current location, a GC block prior location, and a host block original location. These blocks illustrate the potential movement of data through the system during garbage collection operations.

114 114 The GC block current locationmay represent the most recent location where data has been stored after a garbage collection operation. In some cases, this location may be associated with a first physical address from which data is obtained. The GC block current locationmay be part of a garbage collection block, which may be a virtual block scheduled for a garbage collection operation or a virtual block that is to store data of another block scheduled for a garbage collection operation.

116 100 The GC block prior locationmay indicate a previous location of the data before it was moved during garbage collection. This location may be associated with a second physical address for a previous physical location of the data. The systemmay use this information to retrieve data from the previous location in the event of repetitive ECC decoding failures in the current physical location during read retry operations.

118 110 100 118 116 114 100 The host block original locationmay show the initial location where the data was first written by the host device. This location may represent the starting point of data movement through the system. In some implementations, the systemmay track the movement of data from the host block original locationto the GC block prior location, and then to the GC block current location, among other locations, during successive garbage collection operations. In other words, the systemmay track an entire chain of locations.

102 100 The SSD controllermay manage these data movements and maintain information about the current and previous locations of data. This allows the controller to potentially retrieve data from a previous location if a read operation fails at the current location, improving data reliability and recovery capabilities of the system. The controller may detect a failure associated with data obtained from the current physical location and determine a virtual block number based on the second physical address.

102 In some implementations, the SSD controllermay determine that the virtual block number identifies a garbage collection block. The controller may also determine that the previous location of the data in the prior garbage collection block or a host write block has not been overwritten. This determination may be crucial for ensuring that the data in the previous location is still valid and can be used for recovery purposes.

100 102 The systemmay utilize a virtual wordline structure to organize and manage data within the flash memory devices. The SSD controllermay determine a virtual wordline of the garbage collection block and obtain a data log from this virtual wordline. The data log may identify the second physical address for the previous physical location of the data. This mechanism allows the system to track the movement of data across different garbage collection cycles and facilitates efficient data recovery when needed.

100 By implementing this data tracking mechanism, the systemprovides a technical solution to the problem of achieving predictable read latency and reducing the uncorrectable bit error rate (UBER) of the SSD. The system can retrieve data from older locations in case of reclaimed data, mitigating the impact of repetitive ECC decoding failures in the current physical location during read retry operations. This approach may improve read latency and quality of service (QoS) by avoiding the need to trigger heroic data recovery procedures when another copy of data is available.

100 The systemoffers several advantages over conventional SSD systems. It may reduce overall UBER and improve device reliability by providing an additional layer of data recovery. The system may also enhance drive life by reducing read disturb on target pages and neighboring pages caused by repetitive reads on erroneous pages. These benefits contribute to the overall performance and longevity of the SSD, making it a more robust and reliable storage solution for various applications.

2 FIG. 1 FIG. 1 FIG. 1 FIG. 1 FIG. 2 FIG. 200 200 110 102 104 106 108 200 200 200 200 200 210 220 230 240 250 260 270 200 is a diagram of example components of a device, in accordance with the present disclosure. The devicemay be similar to, include, or be included in, the host deviceor the SSD controllershown in, the flash memory deviceshown in, the flash memory deviceshown in, and/or the flash memory deviceshown in, among other examples. The devicemay be used to implement any one or more aspects of the techniques, processes, and/or apparatuses described herein. In some implementations, the devicemay refer to one or more devicesand one or more components of the device. As shown in, the devicemay include a bus, a processor, a memory, a storage component(which may be an SSD), an input component, an output component, and a communication component. The devicemay be, for example, a computing device.

210 200 220 220 220 230 The busincludes a component that enables wired or wireless communication among the components of the device. The processormay be a central processing unit, a graphics processing unit, a microprocessor, a controller, a microcontroller, a digital signal processor, an FPGA, an ASIC, or another type of processing component. The processoris implemented in hardware, firmware, or a combination of hardware and software. In some implementations, the processorincludes one or more processors capable of being programmed to perform a function. The memoryincludes a random access memory, a read only memory, or another type of memory (e.g., a flash memory, a magnetic memory, or an optical memory).

240 200 240 250 200 250 260 200 270 200 270 The storage componentstores information or software related to the operation of the device. For example, the storage componentmay include a hard disk drive, a magnetic disk drive, an optical disk drive, a solid state disk drive, a compact disc, a digital versatile disc, or another type of non-transitory computer-readable medium. The input componentenables the deviceto receive input, such as user input or sensed inputs. For example, the input componentmay include a touch screen, a keyboard, a keypad, a mouse, a button, a microphone, a switch, a sensor, a global positioning system component, an accelerometer, a gyroscope, or an actuator. The output componentenables the deviceto provide output, such as via a display, a speaker, or one or more light-emitting diodes. The communication componentenables the deviceto communicate with other devices, such as via a wired connection or a wireless connection. For example, the communication componentmay include a receiver, a transmitter, a transceiver, a modem, a network interface card, or an antenna.

200 230 240 220 220 220 220 230 The devicemay perform one or more processes described herein. For example, a non-transitory computer-readable medium (e.g., the memoryor the storage component) may store a set of instructions (e.g., one or more instructions, code, software code, or program code) for execution by the processor. In some cases, a number of processorsmay perform a process in parallel. In some cases, one or more processorsmay perform one or more aspects of a process while one or more other processorsmay perform one or more other aspects of the process. Similarly, instructions may be duplicated, distributed, and/or partitioned across two or more memories. In some implementations, hardwired circuitry may be used instead of or in combination with the instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

2 FIG. 2 FIG. 200 220 230 230 200 200 The number and arrangement of components shown inare provided as an example. The devicemay include additional components, fewer components, different components, or differently arranged components than those shown in. For example, the processormay refer to two or more processors and the memorymay refer to two or more memories. Additionally, or alternatively, a set of components (e.g., one or more components) of the devicemay perform one or more functions described as being performed by another set of components of the device.

3 3 FIGS.A andB 3 FIG.A 3 FIG. 3 FIG.A 300 300 are diagrams of an example of a virtual wordlinewith a data tracking log as described herein. As shown in, the virtual wordlinemay include a data tracking log (also referred to as “data log”). For example, as shown in, one or more data frames may include the data tracking log. As shown in, “DF” may be used to refer to a data frame and “DTL” may be used to refer to a data tracking log.

300 302 304 306 308 The virtual wordlinemay be composed of multiple flash pages, including flash page 0, flash page 1, flash page 2, and flash page 3. Each flash page may contain multiple components organized in a specific layout to facilitate efficient data storage, error correction, and data tracking.

302 In some implementations, a flash page may refer to a minimum addressable unit for read and write operations in a NAND flash memory device. The size of a flash page may vary depending on the specific NAND flash memory architecture, but it is often in the range of 2 to 16 kilobytes. For example, flash page 0may have a size of 8 kilobytes and may include multiple data frames and ECC chunks.

300 302 310 312 314 316 304 318 320 322 324 Each flash page in the virtual wordlinemay be divided into multiple ECC chunks and data frames. An ECC chunk may refer to a portion of data associated with error correction code information. For instance, flash page 0includes ECC chunk 0and data frame 0, followed by ECC chunk 1and data frame 1. This pattern may be repeated in subsequent flash pages, such as flash page 1, which contains ECC chunk 0and data frame 2, along with ECC chunk 1and data frame 3.

312 316 320 324 312 The data frames (e.g., data frame 0, data frame 1, data frame 2, data frame 3) may store user data or system data. In some aspects, a data frame may refer to a logical unit of data that is managed by the SSD controller. The size of a data frame may vary depending on the specific implementation, but it may typically range from 512 bytes to 4 kilobytes. For example, data frame 0may have a size of 2 kilobytes and may contain user data written by a host device.

310 314 318 322 310 312 The ECC chunks (e.g., ECC chunk 0, ECC chunk 1, ECC chunk 0, ECC chunk 1) may contain error correction code information for the corresponding data frames. In some implementations, an ECC chunk may refer to a portion of data that includes parity bits or other error correction information. The ECC chunks may be used by the SSD controller to detect and correct errors that may occur during read operations. For instance, ECC chunk 0may contain error correction information for data frame 0, allowing the controller to correct a certain number of bit errors that may occur in the data frame.

306 326 328 330 332 308 300 308 334 336 338 340 Flash page 2follows a similar pattern to the previous flash pages, with ECC chunk 0and data frame 4, as well as ECC chunk 1and data frame 5. However, the structure of flash page 3differs slightly from the other flash pages in the virtual wordline. Flash page 3contains ECC chunk 0followed by a data tracking log, and ECC chunk 1paired with another data tracking log.

336 340 336 The data tracking logs (e.g., data tracking log, data tracking log) may store information about previous physical locations of data. In some aspects, a data tracking log may refer to a data structure that contains metadata about the history of data movement within the SSD. For example, data tracking logmay include information such as a previous physical address, a timestamp, and a virtual block number associated with a particular data frame. This information can be used for data recovery purposes, especially in cases where a read operation fails at the current physical location of the data.

3 FIG.A 3 FIG.B 308 336 340 342 In some implementations, as shown in, the data tracking logs may be placed at the end of a programmed virtual wordline, as shown in flash page 3. This placement may allow for efficient access to the tracking information without interfering with the regular data storage pattern of the other flash pages. For instance, when a controller detects a failure associated with data obtained from a current physical location, it may access the data tracking logorto determine a previous physical location of the data. In some implementations, as shown in, the data tracking log may be placed at the end of a programmed virtual wordline prior to parity bits.

300 336 340 The virtual wordlinestructure may support various data management operations, including garbage collection. During a garbage collection operation, valid data from multiple blocks (mostly storing invalid or stale data) may be consolidated into new blocks, allowing the old blocks to be erased and reused. The data tracking logsandmay play a crucial role in this process by maintaining a record of the data's previous locations, which can be used for data recovery if needed.

300 In alternative embodiments, the layout of the virtual wordlinemay be modified to accommodate different storage requirements or error correction schemes. For example, the number of flash pages per virtual wordline may be increased or decreased, or the size and arrangement of ECC chunks and data frames may be adjusted. Additionally, the placement of data tracking logs within the virtual wordline may be altered, such as distributing them across multiple flash pages instead of concentrating them in the last flash page.

300 The structure of the virtual wordlineas described in this disclosure may provide several advantages for non-volatile memory systems. It may allow for efficient data storage and error correction while also incorporating a mechanism for tracking data movement history. This combination may enhance the overall reliability and performance of the storage system by enabling advanced data recovery techniques and optimizing garbage collection operations.

4 FIG. 4 FIG. 400 400 400 402 404 406 408 is a diagram of an example of a configurationwith multiple garbage collection blocks as described herein.illustrates the configurationof a storage system that utilizes data tracking logs for managing garbage collection blocks in a non-volatile memory device, such as an SSD. The configurationcomprises multiple channels, represented by channeland channel, which may facilitate parallel data transfer operations. Each channel is connected to multiple targets, which in turn are connected to multiple logical unit numbers (LUNs), forming a hierarchical structure that allows for efficient data management and access.

410 410 412 420 426 412 420 426 The system is organized into blocks, which are arranged in a matrix across the channels, targets, and LUNs. In some implementations, a block may refer to a basic unit of erase operations in NAND flash memory. For example, a block may typically contain 128 or 256 pages, with each page capable of storing several kilobytes of data. The blocksinclude different types of blocks, such as the latest GC block, prior GC block, and host write block, each serving specific purposes in the data management process. GC block, prior GC block, and/or host write blockmay be virtual blocks.

4 FIG. 4 FIG. 3 FIG.B 416 416 416 416 As shown in, virtual block 1 (or garbage collection virtual block 1) and virtual block 3 (or garbage collection virtual block 3) may be in a free state. A latest virtual block (or latest garbage collection virtual block) may be in a ready state or a used state. A “latest virtual block” may refer to a virtual block that has recently been scheduled for garbage collection. For example, a “latest virtual block” may refer to a most recent virtual block scheduled for garbage collection. As shown in, the latest virtual block may include a first data tracking logthat identifies a first previous location of data. For example, the first data tracking logmay indicate that the data is stored on virtual block 3. The first data tracking logmay identify a physical location of the data on a wordline of a block included in virtual block 3. In some examples, the first data tracking logmay be included on a virtual wordline prior to parity bits (as shown in, for example).

4 FIG. 3 FIG.B 422 422 422 422 As shown in, virtual block 3 may include a second data tracking logthat identifies a second previous location of the data. For example, the second data tracking logmay indicate that the data is stored on virtual block 1. The second data tracking logmay identify a physical location of the data on a wordline of a block included in virtual block 1. In some examples, the second data tracking logmay be included on a virtual wordline prior to parity bits (as shown in, for example).

412 416 416 420 The latest GC block(which is a virtual block) contains a data tracking log, which stores information about the previous location of data. As used herein, a “data tracking log” may refer to a data structure that maintains metadata about the movement history of data within the storage system. The data tracking logpoints to a location in the prior GC block, as indicated by the arrow. This mechanism allows the system to trace the history of data movement across different garbage collection cycles.

420 422 426 412 416 420 426 The prior GC blockalso contains a data tracking log, which in turn points to a location in the host write block. This creates a chain of data tracking logs that can be used to trace the history of data movement across different blocks. For instance, if a read operation fails at the current location in the latest GC block, the system can use the data tracking logto locate the data in the prior GC block, and if necessary, follow the chain further back via one or more intervening blocks to the host write block. In other words, the system may track an entirety of the chain.

418 424 418 424 Blockand blockrepresent intermediate blocks in the system, which may contain user data. Blockand blockmay be data blocks subjected to the garbage collection process multiple times, resulting in multiple copies of the same user data. Locations of the multiple copies of the same user data may be tracked, using the data tracking logs, to enable a copy of the user data to be returned to the host when the host requests a current copy of the data that is unreadable. These blocks illustrate the dynamic nature of data storage in the system, where blocks may transition between different states (e.g., active, garbage collection, free) based on the ongoing data management operations.

400 The configurationalso includes parity information for each block, as shown in the rightmost column. This parity data provides error correction capabilities for the stored information. In some aspects, “parity information” may refer to additional data generated from the original data, which can be used to detect and correct errors that may occur during data storage or retrieval. For example, the parity information may be used in conjunction with RAID (Redundant Array of Independent Disks) techniques to enhance data reliability.

400 At the bottom of the diagram, a block labeled P−1 is shown to indicate the presence of additional blocks in the system beyond what is explicitly depicted. Accordingly, the configurationis scalable and can accommodate a large number of blocks to meet various storage capacity requirements.

The use of data tracking logs in this configuration allows the system to efficiently manage data through multiple garbage collection cycles. Garbage collection, in the context of this disclosure, may refer to the process of identifying and consolidating valid data from multiple blocks (mostly storing invalid or stale data) into new blocks, allowing the old blocks to be erased and reused. This process is essential for maintaining the performance and longevity of the storage system.

412 416 420 In some implementations, the system may use the data tracking logs to optimize read operations. For example, if a read operation fails at the current location in the latest GC block, the controller may consult the data tracking logto retrieve the data from its previous location in the prior GC block. This approach can potentially improve read latency and reduce the need for complex error recovery procedures.

400 Alternative embodiments of the configurationmay include variations in the structure and organization of the blocks. For instance, the number of channels, targets, or LUNs may be adjusted based on specific performance requirements or hardware constraints. Additionally, the system may implement different strategies for placing and managing data tracking logs, such as storing them in dedicated blocks or distributing them across multiple blocks for redundancy.

400 The configurationmay also support advanced features such as wear leveling and bad block management. Wear leveling may involve distributing write operations evenly across all blocks to prevent premature failure of frequently used blocks. Bad block management may include identifying and marking faulty blocks, and remapping their data to spare blocks to maintain data integrity and system reliability.

400 4 FIG. In summary, the configurationillustrated indemonstrates a sophisticated approach to data management in non-volatile memory systems. By incorporating data tracking logs and organizing blocks across multiple channels, targets, and LUNs, this configuration enables efficient garbage collection, improved data recovery capabilities, and enhanced overall system reliability. These features collectively contribute to the performance and longevity of the storage system, making it suitable for a wide range of applications that require high-performance and reliable data storage.

Table 1 shows an example of a data tracking log as described herein. In some implementations, the data tracking log may be stored in a virtual wordline of a garbage collection block. As shown in Table 1, the data tracking log may include metadata that includes information identifying the data tracking log. The data tracking log may include information identifying a physical address of the data.

TABLE 1 A diagram of an example of a data tracking log DT log FW metadata (contains (511 0xFFFFFFF8 as special signature for DT entries) Reserved log in place of LBA) 4096 bytes 64 bytes 16 bytes

The data tracking log may be used to determine a previous location of data requested by a host device. For example, when a read command is issued from the host device, a controller may read a current physical location (from logical to physical (L2P) table) and data may be obtained from the current physical location. The L2P mapping table may identify a physical address of the current physical location.

The data may be decoded. If the data encounters ECC decoding failures and if the decoding failures cannot be recovered using read retries, a controller may obtain a data tracking log from a current block storing the data and use the data tracking log to identify a garbage collection block for the data. If the controller identifies the GC block, then the controller may calculate a virtual wordline and read a data tracking log written towards the end of the virtual wordline before RAID parity information (e.g., RAID parity bits).

From the data tracking log, the controller may obtain a previous location of the data. If the previous location belongs to a prior GC block in a free state, the controller may determine that the prior GC block is in a free pool and may not have been recycled. In other words, the controller may determine that the prior GC block may not have been overwritten. Based on determining the prior GC block has not been overwritten, the controller may read a data frame from the previous location and compare a logical block address (LBA) from the metadata of the data frame and an LBA associated with the current physical location to ensure that the previous location has not been overwritten.

If the LBA from the metadata matches the LBA associated with the current physical location, the controller may read data from the previous location. If ECC decoding for the previous location fails, the controller may check if an earlier location (prior to the previous location) is a GC block and if so, the controller may repeat the prior operations until reaching good data or an original location (e.g., a host write block), or until the controller finds that the prior location is overwritten.

If the controller reaches an older GC block that is overwritten or reaches a host write block without success in recovering good data, the controller may proceed with initiating a heroic recovery process in the latest location of the data as pointed by L2P table.

5 FIG. 5 FIG. 5 FIG. 500 102 110 500 505 500 510 is a diagram of an example processassociated with a read operation as described herein. In some examples, the read operation may be performed by a controller (e.g., SSD controller). The read operation may be performed based on a host device (e.g., host device) initiating a read operation. As shown in, processmay include detecting a request to read an LBA (block). For example, a host device may initiate the read operation to read the LBA. As shown in, processmay include determining if the read operation passes (block). For example, a controller may determine whether decoding of data, obtained based on the read operation, is successful.

5 FIG. 5 FIG. 500 515 500 520 As shown in, processmay include sending the data to the host device (block). For example, the data may be sent to the host device if the read operation passes. As shown in, processmay include determining if a read retry operation passes (block). The read retry operation may be performed if the read operation does not pass. If the read retry operation passes, the data may be sent to the host device.

5 FIG. 500 525 As shown in, processmay include determining if a virtual block is a GC block (block). For example, if the read retry operation does not pass, the controller may determine if the virtual block, in which the data is included, is a GC block.

5 FIG. 5 FIG. 500 530 500 535 As shown in, processmay include starting a heroic data recovery operation (block). The heroic data recover operation may be initiated if the virtual block is not a GC block. As shown in, processmay include determining whether the heroic data recovery operation passes (block). If the heroic data recovery operation is successful, the data may be sent to the host device.

5 FIG. 500 540 As shown in, processmay include reporting uncorrectable error to the host device (block). The uncorrectable error may be reported if the heroic data recovery operation is not successful.

5 FIG. 500 545 As shown in, processmay include determining whether an older location has been overwritten (block). For example, if the controller determine that the virtual block is a GC block, the controller may determine whether an older location, identified by the GC block, has been overwritten. If the older location has been overwritten, the controller may initiate the heroic data recovery operation.

5 FIG. 5 FIG. 5 FIG. 500 550 500 555 500 515 As shown in, processmay include reading from the older location (block). For example, the controller may read from the older location, if the older location has not been overwritten. As shown in, processmay include determining whether reading from the older location has passed (block). As shown in, processmay include sending the data to the host device (block). For example, the controller may send the data to the host device if reading from the older location has passed. If reading from the older location has not passed, the controller may identify a prior GC block that includes the data. As used herein, “reading” may refer to an entire read error handling process, which includes a read retry. In some implementations, a read retry may be performed prior to the controller identifying the prior GC block.

5 FIG. 5 FIG. 500 500 500 Althoughshows example blocks of the process, in some implementations, the processmay include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in. Additionally, or alternatively, two or more of the blocks of the processmay be performed in parallel.

6 FIG. 1 4 FIGS.- 6 FIG. 600 600 605 605 610 610 605 610 615 610 615 620 625 630 635 640 is a diagram of example components of a storage device, which may correspond to one or more element of. As shown in, the storage devicemay include a controller(e.g., an SSD controller). The controllermay include a system on chip (SOC). The SOCmay perform computing or processing operations for the controller. The SOCmay include one or more processorsthat control, command, or observe operations at one or more other components of the SOC. The one or more processorsmay be communicably coupled to one or more of a host interface, a data processing unit (DPU), a data buffer, a storage medium interface, or a memory interface.

610 655 625 625 630 630 640 610 645 640 The host interfacemay be configured to communicate with a host device (e.g., host devicedescribed below). The DPUmay include a functional block that is responsible for managing data operations, such as reading, writing, error correction, or formatting (e.g., data flow between a host interface and a storage medium). The DPUmay perform tasks such as page and block management (e.g., organization of data within storage media), bad block management, garbage collection, error correction and detection (e.g., using error correction codes or soft bit processing), data transformation (e.g., address mapping from host addresses to physical addresses, compression and decompression, or scrambling, among other examples), encryption and decryption, or power management associated with data operations, among other examples. The data buffermay include a temporary storage area used to transfer or process data between the storage media and a host system. The data bufferis a pipeline data buffer for the data transition. The memory interfacemay provide an interface between the SOCand the DRAMto facilitate transfers of information. For example, the memory interface(e.g., an interface between the controller and an external DDR or DRAM to temporarily hold the data) may support requests to access a logical to physical (L2P) mapping table to identify a physical location of data requested by the host device, or to provide mapping information for storage in the L2P mapping table.

605 645 645 605 605 645 650 605 The controllermay further include DRAM. The DRAMmay locally store information that is available on demand at the controllerfor operations of the controller. For example, the DRAMmay store an L2P mapping tablethat maps logical locations of data and physical locations of data on connected storage media. In this way, the controllermay have access to mapping information for locating data on the connected storage media based at least in part on an indication associated with host data when written.

620 655 620 620 The host interfacemay provide an interface for communicating with a host. For example, the host interfacemay receive an access request or data for storage on connected storage media. In some aspects, the host interfacemay provide data to the host after reading the data on from the connected storage media.

635 660 660 660 665 665 665 605 665 The storage media interfacemay communicate via one or more channels(e.g.,A andB) with one or more connected storage media(e.g.,A andB). For example, the controllermay perform or initiate a read or write operation at a physical location of a storage media.

6 FIG. The number and arrangement of components shown inare provided as an example.

7 FIG. 7 FIG. 700 is a flowchart of an example processassociated with mitigating data decoding failures. In some implementations, one or more process blocks ofmay be performed by a controller of an SSD.

7 FIG. 700 710 520 As shown in, processmay include detecting a failure associated with data obtained, using a first physical address, from a current physical location of a non-volatile memory device (block). For example, the controller may detect a failure associated with data obtained, using a first physical address, from a current physical location of a non-volatile memory device, as described above in connection with block.

7 FIG. 1 FIG. 700 720 As shown in, processmay include determining, based on detecting the failure, a virtual block number based on the first physical address (block). For example, the controller may determine, based on detecting the failure, a virtual block number based on the first physical address, as described above in connection with.

7 FIG. 700 730 525 545 As shown in, processmay include determining that the virtual block number identifies a garbage collection block (block). For example, the controller may determine that the virtual block number identifies a garbage collection block, as described above in connection with blocksand.

7 FIG. 1 FIG. 700 740 As shown in, processmay include determining a virtual wordline of the garbage collection block (block). For example, the controller may determine a virtual wordline of the garbage collection block, as described above in connection with.

7 FIG. 1 4 FIGS.and 700 750 As shown in, processmay include obtaining, from the virtual wordline, a data log that identifies a second physical address for a previous physical location of the data (block). For example, the controller may obtain, from the virtual wordline, a data log that identifies a second physical address for a previous physical location of the data, as described above in connection with.

7 FIG. 1 FIG. 700 760 550 As shown in, processmay include obtaining, using the second physical address, the data from the previous physical location (block). For example, the controller may obtain, using the second physical address, the data from the previous physical location, as described above in connection withand block.

In some implementations, detecting the failure comprises detecting a first decoding failure associated with performing a read operation using the physical address, and detecting a second decoding failure associated with performing a read retry operation using the physical address.

In some implementations, determining the virtual wordline comprises determining the virtual wordline using a logical unit number, a block number, and a page number, wherein the logical unit number, the block number, and the page number are identified by the first physical address.

In some implementations, the previous physical location is included in an additional block, and wherein obtaining the data from the previous physical location comprises determining whether the additional block has been overwritten, and obtaining, using the second physical address, the data from the previous physical location based on determining whether the block has been overwritten.

In some implementations, obtaining the data from the previous physical location comprises reading a data frame from the previous physical location, determining a logical block address (LBA) based on the data frame, determining whether the block has been overwritten based on the LBA, and obtaining, using the second physical address, the data from the previous physical location based on determining whether the block has been overwritten.

In some implementations, obtaining the data from the previous physical location comprises performing a comparison using the LBA to determine that the block has not been overwritten based on performing the comparison using the LBA, and obtaining, using the second physical address, the data from the previous physical location based on determining that the block has not been overwritten.

700 In some implementations, the processincludes storing the data log, in the virtual wordline, to identify the previous physical location of the data.

700 In some implementations, the processincludes performing a read refresh operation on the previous physical location after storing the data log in the virtual wordline, to identify the previous physical location of the data.

7 FIG. 7 FIG. 700 700 700 Althoughshows example blocks of the process, in some implementations, the processmay include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in. Additionally, or alternatively, two or more of the blocks of the processmay be performed in parallel.

In some implementations, a method comprises detecting a failure associated with data obtained, using a first physical address, from a current physical location of a non-volatile memory device; determining, based on detecting the failure, a virtual block number based on the first physical address; determining that the virtual block number identifies a garbage collection block; determining a virtual wordline of the garbage collection block; obtaining, from the virtual wordline, a data log that identifies a second physical address for a previous physical location of the data; and obtaining, using the second physical address, the data from the previous physical location.

In some implementations, a system comprises a controller to: detect a decoding failure associated with data obtained, using a first physical address, from a current physical location of a non-volatile memory device, wherein the data is obtained based on a read retry operation associated with the first physical address, and wherein the data is obtained from a block of the non-volatile memory device; determine that the block is a garbage collection block; determine a second physical address of a previous physical location of the data, wherein the second physical address is determined using information regarding the garbage collection block; determine that the second physical address is not overwritten; and perform a read operation using the second physical address.

In some implementations, a non-transitory computer-readable medium storing a set of instructions includes one or more instructions that, when executed by one or more processors of a controller, cause the controller to: detect a decoding failure associated with data obtained, using a first physical address, from a current physical location of a non-volatile memory device, wherein the data is from a block of the non-volatile memory device; determine that the block is a garbage collection block; determine a second physical address of a previous physical location of the data, wherein the second physical address is determined using information from a virtual wordline of the garbage collection block; determine that the second physical address is not overwritten; and perform a read operation using the second physical address.

The descriptions of the various embodiments of the present disclosure have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

As used herein, the term “component” is intended to be broadly construed as hardware, firmware, or a combination of hardware and software. It will be apparent that systems or methods described herein may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual control hardware or software code used to implement these systems or methods is not limiting of the implementations. Thus, the operation and behavior of the systems or methods are described herein without reference to specific software code—it being understood that software and hardware can be used to implement the systems or methods based on the description herein.

As used herein, satisfying a threshold may, depending on the context, refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, or the like.

Although particular combinations of features are recited in the claims or disclosed in the specification, these combinations are not intended to limit the disclosure of various implementations. In fact, many of these features may be combined in ways not specifically recited in the claims or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of various implementations includes each dependent claim in combination with every other claim in the claim set. As used herein, a phrase referring to “at least one of” a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiple of the same item.

No element, act, or instruction used herein is to be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Further, as used herein, the article “the” is intended to include one or more items referenced in connection with the article “the” and may be used interchangeably with “the one or more.” Furthermore, as used herein, the term “set” is intended to include one or more items (e.g., related items, unrelated items, or a combination of related and unrelated items), and may be used interchangeably with “one or more.” Where only one item is intended, the phrase “only one” or similar language is used. Also, as used herein, the terms “has,” “have,” “having,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Also, as used herein, the term “or” is intended to be inclusive when used in a series and may be used interchangeably with “or,” unless explicitly stated otherwise (e.g., if used in combination with “either” or “only one of”).