Deferred die data rebuilding upon die failure detection
By deferring data rebuilding on failed memory dies and utilizing RAIN parity protection, the solution addresses performance degradation issues in memory sub-systems, ensuring consistent operation and resource preservation.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-08-29
- Publication Date
- 2026-03-05
AI Technical Summary
Conventional memory sub-systems face performance degradation during urgent die rebuild processes due to substantial processing bandwidth consumption when a memory die fails, which is particularly problematic in data center environments requiring consistent high-performance operations.
Deferring the rebuilding of data on a failed memory die by marking valid blocks as staged bad blocks during foreground processes and performing data recovery during background operations, utilizing RAIN parity protection and folding operations to maintain system performance and preserve processing resources.
Preserves processing resources and maintains consistent memory system performance by deferring die rebuilds, balancing data recovery urgency with system efficiency.
Smart Images

Figure CN2024115553_05032026_PF_FP_ABST
Abstract
Description
DEFERRED DIE DATA REBUILDING UPON DIE FAILURE DETECTIONTECHNICAL FIELD
[0001] Embodiments of the disclosure relate generally to memory devices and, more specifically, to deferring rebuilding (or recreating) of data stored on a memory die of a memory system upon detecting that the memory die is bad (or failed) .BACKGROUND
[0002] A memory sub-system can include one or more memory devices that store data. The memory devices can be, for example, non-volatile memory devices and volatile memory devices. In general, a host system can utilize a memory sub-system to store data at the memory devices and to retrieve data from the memory devices.BRIEF DESCRIPTION OF THE DRAWINGS
[0003] The disclosure will be understood more fully from the detailed description given below and from the accompanying drawings of various example embodiments of the disclosure. The drawings, however, should not be taken to limit the disclosure to the specific example embodiments, but are for explanation and understanding only.
[0004] FIG. 1 is a block diagram illustrating an example computing system that includes a memory sub-system, in accordance with some example embodiments of the present disclosure.
[0005] FIG. 2 and FIG. 3 are flow diagrams of example methods for deferred rebuilding data stored on a memory die of a memory system upon detecting that the memory die is bad, in accordance with some example embodiments of the present disclosure.
[0006] FIG. 4 shows diagrams illustrating an example use of RAIN data error correction to recreate data stored on one or more blocks on a bad memory die of a memory device, in accordance with some example embodiments of the present disclosure.
[0007] FIG. 5 illustrates an example of performing folding operations on multiple superblocks of a memory device, in accordance with some example embodiments of the present disclosure.
[0008] FIG. 6 is a block diagram of an example computer system in which example embodiments of the present disclosure may operate.DETAILED DESCRIPTION
[0009] Aspects of the present disclosure are directed to deferring rebuilding (or recreating) of data stored on a memory die of a memory system (e.g., memory sub-system) upon detecting that the memory die is bad. Various embodiments described herein can be used in a memory sub-system that uses a RAIN (redundant array of independent NAND-type memory devices) technique for data error correction. A memory sub-system can be a storage device, a memory module, or a hybrid of a storage device and memory module. Examples of storage devices and memory modules are described below in conjunction with FIG. 1. In general, a host system can utilize a memory sub-system that includes one or more components, such as memory devices that store data. The host system can send access requests to the memory sub-system, such as to store data at the memory sub-system and to read data from the memory sub-system.
[0010] The host system can send access requests (e.g., write command, read command) to the memory sub-system, such as to store data on a memory device at the memory sub-system, read data from the memory device on the memory sub-system, or write / read constructs (e.g., such as submission and completion queues) with respect to a memory device on the memory sub-system. The data to be read or written, as specified by a host request, is hereinafter referred to as “host data” or “user data. ”
[0011] Conventional memory sub-systems can employ error-correction techniques, such as using a redundant array of independent NAND-type memory devices (hereafter, referred to as a RAIN technique) , to protect data (e.g., host or user data) stored on the memory sub-systems. Error-correction techniques can comprise calculating parity (e.g., exclusive OR (XOR) parity) across some collection of data (e.g., host / user data) being error-protected. By such error-correction techniques, if a data member of the collection is lost (e.g., corrupted) for any reason, the parity calculation can be re-performed and the lost data recreated. With a RAIN technique (or RAIN protection scheme) , data is striped (e.g., split) so that different portions of the data are stored across different pages or blocks of different memory die devices of one or more NAND-type memory devices. The pages or blocks of the different memory die that store the split data are collectively referred to as a stripe. When the split data is completely written across a given stripe of pages or blocks of a specified set of memory die of one or more NAND-type memory devices, the RAIN parity calculation is performed and stored in a parity page or block associated with the given stripe. An individual RAIN stripe can comprise the individual stripe (of pages or blocks) storing split data and the parity page or block for the individual stripe. In certain instances, a RAIN stripe comprises a single superblock.
[0012] A host request can include logical address information (e.g., logical block address (LBA) , namespace) for the host data, which is the location the host system associates with the host data and a particular zone in which to store or access the host data. The logical address information (e.g., LBA, namespace) can be part of metadata for the host data. Metadata can also include error handling data (e.g., error-correcting code (ECC) code word, parity code) , data version (e.g., used to distinguish age of data written) , valid bitmap (which LBAs or logical transfer units contain valid data) , and so forth.
[0013] The memory sub-system can initiate media management operations, such as a write operation, on host data that is stored on a memory device. For example, firmware of the memory sub-system may re-write previously written host data from a location of a memory device to a new location as part of garbage collection management operations. The data that is re-written, for example as initiated by the firmware, is hereinafter referred to as “garbage collection data. ”
[0014] “User data” hereinafter generally refers to host data and garbage collection data. “System data” hereinafter refers to data that is created and / or maintained by the memory sub-system for performing operations in response to host requests and for media management. Examples of system data include, and are not limited to, system tables (e.g., logical-to-physical memory address mapping table (also referred to herein as an L2P table) , data from logging, scratch pad data, and so forth) .
[0015] A memory device can be a non-volatile memory device. A non-volatile memory device is a package of one or more die. Each die can be comprised of one or more planes. For some types of non-volatile memory devices (e.g., AND-type devices) , each plane is comprised of a set of physical blocks. For some memory devices, blocks are the smallest area that can be erased. Each block is comprised of a set of pages. Each page is comprised of a set of memory cells, which store bits of data. The memory devices can be raw memory devices (e.g., NAND) , which are managed externally, for example, by an external controller. The memory devices can be managed memory devices (e.g., managed NAND) , which are a raw memory device combined with a local embedded controller for memory management within the same memory device package. The memory device can be divided into one or more zones where each zone is associated with a different set of host data or user data or application.
[0016] Generally, writing data to NAND-type memory devices involves programming (by way of a program operation) the NAND-type memory devices at the page level of a block, and erasing data from such memory devices involves erasing the memory devices at the block level (e.g., page level erasure of data is not possible) . Certain memory devices, such as NAND-type memory devices, comprise one or more blocks, (e.g., multiple blocks) with each of those blocks comprising multiple pages, where each page comprises a subset of memory cells of the block, and where a single wordline of a block (which connects a group of memory cells of the block together) defines one or more pages of a block (depending on the type of memory cell) . Depending on the embodiment, different blocks can comprise different types of memory cells. For instance, a block (a single-level cell (SLC) block) can comprise multiple SLCs, a block (a multi-level cell (MLC) block) can comprise multiple MLCs, a block (atriple-level cell (TLC) block) can comprise multiple TLCs, and a block (a quad-level cell (QLC) block) can comprise QLCs. Other blocks comprising other types of memory cells (e.g., higher-level memory cells, having higher bit storage-per-cell) are also possible.
[0017] Garbage collection (GC) operations are common to memory management of NAND-type memory devices and are important for maintaining the performance of the memory sub-systems that include one or more NAND-type memory devices. A GC operation usually involves the reclamation of blocks on one or more NAND-type memory devices that are no longer in use (e.g., storing invalid data) so that data can be written in those reclaimed blocks. Generally, a GC operation can comprise reading valid data from a block and rewriting it to a new block, and then erasing (now invalid) data stored in the old block so that the old block can be available for reuse in its entirety. The operation of reading valid data from a block (or a superblock) and rewriting it to a new block (or a new superblock) can be referred to as folding the block (or the superblock) , and the valid data read by the folding operation can be referred to as data (of the block / superblock) to be folded. The efficiency of GC operation can directly impact write amplification on a NAND-type memory device and, as such, the lifespan and performance of the NAND-type memory device.
[0018] Although NAND-type memory devices permit write and read addressing at a page level and erasure addressing at a block level, there are some practical difficulties in such fine-grained resolution. These difficulties can include addressing overhead for a variety of tasks and operations, including maintenance of one or more tables that enable a flash translate layer (FTL) comprising a hardware / software layer in a controller of a memory sub-system that manages one or more operations on the memory sub-system. The FTL can, for example, perform logical-to-physical address translation, garbage collection, wear-leveling, error correction code (ECC) , and bad block management.
[0019] To address these issues, blocks can be aggregated into a single logical entity or unit to which data is written, where each single logical entity / unit can be referred to as a logical superblock (hereafter, superblock) . This arrangement provides some benefits, such as parallel execution of a write command across one or more memory circuit die (or memory die) or mitigating the impact of bad blocks on overall device performance. Superblocks can enable tracking fewer storage units, relieving pressure on FTL tables and management. This can be important in resource-limited memory sub-systems, where available working memory (e.g., random access memory (RAM) holding system state) can be limited. Using superblocks as a basic operational unit in the memory device can provide efficient resource management, while permitting more efficient maintenance operations (e.g., reduced latency and time to perform the operations) and effective device operation.
[0020] As used herein, a superblock comprises a plurality of blocks across one or more (e.g., all) of planes of one or more (e.g., all) memory die (e.g., NAND-type memory die) of a memory device. Each individual block of a superblock of a memory die can be associated with an index value (e.g., intra-die index value) that indicates a logical or physical position of the individual block within the individual block's respective plane of the memory die. A superblock can, for example, be formed by blocks in a same position across multiple planes (e.g., a same logical or physical position on each plane of multiple planes) of a single memory circuit die (or single memory die) or of multiple memory die (e.g., that form a memory array) . Where a memory system implements a RAIN technique, an individual superblock can be formed by a single block from each of multiple planes of each of multiple memory die of a memory device.
[0021] While memory sub-systems, such as Solid-state drives (SSDs) have superior performance and reliability compared to traditional hard disk drives, they are not immune to failures, and one critical issue that can arise is the failure of individual memory die (e.g., NAND-type memory die) within a memory device of the memory sub-system. When a memory die fails or goes bad, the memory sub-system recovers the data from the failed / bad memory die (e.g., using parity data in RAIN stripes) to maintain data integrity and memory sub-system functionality. The process of recovering data from a failed / bad memory die can be referred to as a die data rebuild (or die rebuild) . Memory devices protected by a memory die-level RAIN scheme can have the capability to perform die rebuild by using the data from other (working / good) memory die to recover the data stored on the failed / bad memory die.
[0022] At present, conventional memory sub-systems implement an urgent die rebuild process where when a memory die failure is detected (or is detected as bad) , the memory sub-system triggers an urgent folding operation to move the data from the failed / bad memory die as quickly as possible. While this approach aims to minimize data loss risk, the urgent die rebuild process consumes substantial internal processing bandwidth (e.g., the bandwidth of the memory sub-system controller) . As a result, the conventional memory sub-system cannot sustain operational performance during the urgent die rebuild process, and this performance degradation can be impactful / problematic, especially in data center environments where consistent, high-performance operation of memory sub-systems can be critical.
[0023] To mitigate the performance impact of die rebuild operations, some conventional memory sub-systems can attempt to limit processing resources (e.g., memory sub-system controller) used by the die rebuild process. Unfortunately, this approach presents its own challenges. For example, it can be difficult to determine the optimal amount of processing resources to allocate for die rebuild, as the resource requirements can vary depending on the workload running during the rebuild process.
[0024] Various example embodiments described herein provide for deferred rebuilding (or recreating) of data stored on a memory die of a memory system upon detecting that the memory die is bad (or failed) . By deferring (or relaxing) rebuilding of data of bad / failed memory die (and avoiding the triggering of urgent die rebuilding upon detection of a bad / failed memory die) , various embodiments can help preserve processing resources / bandwidth of a memory system (e.g., during foreground processes) and help maintain consistent memory system performance, while balancing the urgency of data recovery from bad / failed memory die. According to various example embodiments, when an individual memory die of a memory system is detected as being bad (or failed) during a foreground process (e.g., a host read operation, a wear leveling operation, a garbage collection operation, or the like) , rather than triggering an urgent die rebuild of the (bad) individual memory die, at least one valid block of the individual memory die (e.g., each valid block of the individual memory die) is marked (e.g., flagged) as being a failed-memory-die bad block (e.g., staged bad block) . Eventually, during a background process, such as a media scan (or scan) operation performed on the memory device, the failed-memory-die bad block of at least one of the valid blocks of the individual memory die can be detected and, in response, an example embodiment can move data from the individual memory die. For example, a memory system (e.g., memory sub-system) can use a RAIN technique for data error correction. The memory device can comprise a plurality of superblocks across the plurality of memory die of the memory device, where each individual superblock comprises a plurality of blocks (e.g., to store user data) and a parity block (e.g., to store parity data of the individual superblock) for the plurality of block, and where the parity block can implement RAIN parity protection. For some example embodiments, moving data from the (bad) individual memory die, a folding operation can be performed on each individual superblock of the plurality of superblocks. During the folding operation, data stored on the (bad) individual memory die can be rebuilt (e.g., recreated or recovered) using a RAIN recovery technique, and the rebuilt data and remaining data of each superblock can be moved to one or more available superblocks of the memory device.
[0025] As used herein, a folding operation can comprise reading valid data from a block (or a superblock) and rewriting it to a new block (or a new superblock) , and can be referred to as folding the block (or the superblock) . The valid data read by a folding operation can be referred to as data (of the block / superblock) to be folded.
[0026] As used herein, a memory die that is bad (e.g., bad memory die) can also be referred to as a memory die that has failed (e.g., failed memory die) .
[0027] Disclosed herein are some examples of deferring rebuilding (or recreating) of data stored on a memory die of a memory system upon detecting that the memory die is bad (or failed) , as described herein.
[0028] FIG. 1 illustrates an example computing system 100 that includes a memory sub-system 110, in accordance with some example embodiments of the present disclosure. The memory sub-system 110 can include media, such as one or more volatile memory devices (e.g., memory device 140) , one or more non-volatile memory devices (e.g., memory device 130) , or a combination of such.
[0029] A memory sub-system 110 can be a storage device, a memory module, or a hybrid of a storage device and memory module. Examples of a storage device include a solid-state drive (SSD) , a flash drive, a universal serial bus (USB) flash drive, a secure digital (SD) card, an embedded Multi-Media Controller (eMMC) drive, a Universal Flash Storage (UFS) drive, and a hard disk drive (HDD) . Examples of memory modules include a dual in-line memory module (DIMM) , a small outline DIMM (SO-DIMM) , and various types of non-volatile dual in-line memory module (NVDIMM) .
[0030] The computing system 100 can be a computing device such as a desktop computer, laptop computer, network server, mobile device, a vehicle (e.g., airplane, drone, train, automobile, or other conveyance) , Internet of Things (IoT) enabled device, embedded computer (e.g., one included in a vehicle, industrial equipment, or a networked commercial device) , or such computing device that includes memory and a processing device. The computing system 100 can be used to support or implement various types of applications, including those relating to artificial intelligence (AI) .
[0031] The computing system 100 can include a host system 120 that is coupled to one or more memory sub-systems 110. In some example embodiments, the host system 120 is coupled to different types of memory sub-systems 110. FIG. 1 illustrates one example of a host system 120 coupled to one memory sub-system 110. As used herein, “coupled to” or “coupled with” generally refers to a connection between components, which can be an indirect communicative connection or direct communicative connection (e.g., without intervening components) , whether wired or wireless, including connections such as electrical, optical, magnetic, and the like.
[0032] The host system 120 can include a processor chipset and a software stack executed by the processor chipset. The processor chipset can include one or more cores, one or more caches, a memory controller (e.g., NVDIMM controller) , and a storage protocol controller (e.g., a peripheral component interconnect express (PCIe) controller, serial advanced technology attachment (SATA) controller) . The host system 120 uses the memory sub-system 110, for example, to write data to the memory sub-system 110 and read data from the memory sub-system 110.
[0033] The host system 120 can include or be coupled to the memory sub-system 110 so that the host system 120 can read data from or write data to the memory sub-system 110. The host system 120 can be coupled to the memory sub-system 110 via a physical host interface. Examples of a physical host interface include, but are not limited to, a serial advanced technology attachment (SATA) interface, a peripheral component interconnect express (PCIe) interface, a compute express link (CXL) interface, a universal serial bus (USB) interface, a Fibre Channel interface, a Serial Attached SCSI (SAS) interface, etc. The physical host interface can be used to transmit data between the host system 120 and the memory sub-system 110. The host system 120 can further utilize an NVM Express (NVMe) interface to access the memory devices 130, 140 when the memory sub-system 110 is coupled with the host system 120 by the PCIe or CXL interface. The physical host interface can provide an interface for passing control, address, data, and other signals between the memory sub-system 110 and the host system 120.
[0034] The memory devices 130, 140 can include any combination of the different types of non-volatile memory devices and / or volatile memory devices. The volatile memory devices (e.g., memory device 140) can be, but are not limited to, random access memory (RAM) , such as dynamic random access memory (DRAM) and synchronous dynamic random access memory (SDRAM) .
[0035] Some examples of non-volatile memory devices (e.g., memory device 130) include a NAND type flash memory and write-in-place memory, such as a three-dimensional (3D) cross-point memory device, which is a cross-point array of non-volatile memory cells. A cross-point array of non-volatile memory can perform bit storage based on a change of bulk resistance, in conjunction with a stackable cross-gridded data access array. Additionally, in contrast to many flash-based memories, cross-point non-volatile memory can perform a write in-place operation, where a non-volatile memory cell can be programmed without the non-volatile memory cell being previously erased. NAND type flash memory includes, for example, two-dimensional (2D) NAND and 3D NAND.
[0036] Each of the memory devices 130, 140 can include one or more arrays of memory cells. One type of memory cell, for example, SLCs, can store one bit per cell. Other types of memory cells, such as MLCs, TLCs, QLCs, and penta-level cells (PLCs) , can store multiple bits per cell. In some example embodiments, each of the memory devices 130, 140 can include one or more arrays of memory cells such as SLCs, MLCs, TLCs, QLCs, or any combination of such. In some example embodiments, a particular memory device can include an SLC portion, and an MLC portion, a TLC portion, or a QLC portion of memory cells. The memory cells of the memory devices 130, 140 can be grouped as pages that can refer to a logical unit of the memory device used to store data. With some types of memory (e.g., NAND) , pages can be grouped to form blocks. As used herein, a block comprising SLCs can be referred to as a SLC block, a block comprising MLCs can be referred to as an MLC block, a block comprising TLCs can be referred to as a TLC block, and a block comprising QLCs can be referred to as a QLC block.
[0037] Although non-volatile memory components such as NAND type flash memory (e.g., 2D NAND, 3D NAND) and 3D cross-point array of non-volatile memory cells are described, the memory device 130 can be based on any other type of non-volatile memory, such as read-only memory (ROM) , phase change memory (PCM) , self-selecting memory, other chalcogenide-based memories, ferroelectric transistor random-access memory (FeTRAM) , ferroelectric random access memory (FeRAM) , magneto random access memory (MRAM) , Spin Transfer Torque (STT) -MRAM, conductive bridging RAM (CBRAM) , resistive random access memory (RRAM) , oxide-based RRAM (OxRAM) , negative-or (NOR) flash memory, and electrically erasable programmable read-only memory (EEPROM) .
[0038] A memory sub-system controller 115 (or controller 115 for simplicity) can communicate with the memory devices 130, 140 to perform operations such as reading data, writing data, or erasing data at the memory devices 130, 140 and other such operations. The memory sub-system controller 115 can include hardware such as one or more integrated circuits and / or discrete components, a buffer memory, or a combination thereof. The hardware can include digital circuitry with dedicated (i.e., hard-coded) logic to perform the operations described herein. The memory sub-system controller 115 can be a microcontroller, special purpose logic circuitry (e.g., a field programmable gate array (FPGA) , an application specific integrated circuit (ASIC) , etc. ) , or other suitable processor.
[0039] The memory sub-system controller 115 can include a processor (processing device) 117 configured to execute instructions stored in local memory 119. In the illustrated example, the local memory 119 of the memory sub-system controller 115 includes an embedded memory configured to store instructions for performing various processes, operations, logic flows, and routines that control operation of the memory sub-system 110, including handling communications between the memory sub-system 110 and the host system 120.
[0040] In some example embodiments, the local memory 119 can include memory registers storing memory pointers, fetched data, and so forth. The local memory 119 can also include ROM for storing micro-code. While the example memory sub-system 110 in FIG. 1 has been illustrated as including the memory sub-system controller 115, in another example embodiment of the present disclosure, a memory sub-system 110 does not include a memory sub-system controller 115, and can instead rely upon external control (e.g., provided by an external host, or by a processor or controller separate from the memory sub-system) .
[0041] In general, the memory sub-system controller 115 can receive commands or operations from the host system 120 and can convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory device 130 and / or the memory device 140. The memory sub-system controller 115 can be responsible for other operations such as wear leveling operations, garbage collection operations, error detection and ECC operations, encryption operations, caching operations, and address translations between a logical address (e.g., LBA, namespace) and a physical memory address (e.g., physical block address) that are associated with the memory devices 130, 140. The memory sub-system controller 115 can further include host interface circuitry to communicate with the host system 120 via the physical host interface. The host interface circuitry can convert the commands received from the host system 120 into command instructions to access the memory device 130 and / or the memory device 140 as well as convert responses associated with the memory device 130 and / or the memory device 140 into information for the host system 120.
[0042] The memory sub-system 110 can also include additional circuitry or components that are not illustrated. In some example embodiments, the memory sub-system 110 can include a cache or buffer (e.g., DRAM) and address circuitry (e.g., a row decoder and a column decoder) that can receive an address from the memory sub-system controller 115 and decode the address to access the memory devices 130, 140.
[0043] In some example embodiments, the memory device 130 includes local media controller 135 that operates in conjunction with memory sub-system controller 115 to execute operations on one or more memory cells of the memory device 130. An external controller (e.g., memory sub-system controller 115) can externally manage the memory device 130 (e.g., perform media management operations on the memory device 130) . In some example embodiments, a memory device 130 is a managed memory device, which is a raw memory device combined with a local controller (e.g., local media controller 135) for media management within the same memory device package. An example of a managed memory device is a managed NAND (MNAND) device.
[0044] The memory sub-system controller 115 includes a deferred die rebuilder 113 that enables or facilitates the memory sub-system controller 115 to defer rebuilding (or recreating) of data stored on a memory die (e.g., of the memory device 130 or 140) of the memory sub-system 110 upon detecting that the memory die is bad (or failed) in accordance with various example embodiments described herein. Alternatively, some or all of the deferred die rebuilder 113 is included by the local media controller 135, thereby enabling the local media controller 135 to enable or facilitate deferred rebuilding (or recreating) of data stored on a bad / failed memory die of the memory sub-system 110.
[0045] FIG. 2 and FIG. 3 are flow diagrams of example methods 200, 300 for rebuilding (or recreating) of data stored on a memory die of a memory system upon detecting that the memory die is bad (or failed) , in accordance with some example embodiments of the present disclosure. Any of methods 200, 300 can be performed by processing logic that can include hardware (e.g., processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuit, etc. ) , software (e.g., instructions run or executed on a processing device) , or a combination thereof. In some example embodiments, either method 200 or method 300 is performed by the memory sub-system controller 115 of FIG. 1 based on the deferred die rebuilder 113. Additionally, or alternatively, for some example embodiments, either method 200 or method 300 is performed, at least in part, by the local media controller 135 of the memory device 130 of FIG. 1. Although shown in a particular sequence or order, unless otherwise specified, the order of the processes can be modified. Thus, the illustrated example embodiments should be understood only as examples, and the illustrated processes can be performed in a different order, and some processes can be performed in parallel. Additionally, one or more processes can be omitted in various example embodiments. Thus, not all processes are used in every example embodiment. Other process flows are possible.
[0046] Referring now to method 200 of FIG. 2, at operation 204 a processing device (e.g., the processor 117 of the memory sub-system controller 115) determines whether any memory die of a plurality of memory die of a memory device is bad, where the memory device (e.g., 130, 140) is part of a memory system (e.g., memory sub-system 110) . For some example embodiments, the memory device comprises a plurality of superblocks formed across the plurality of memory die, where each individual superblock comprises an individual plurality of blocks and an individual parity block for the individual plurality of blocks. According to some example embodiments, an individual parity block of an individual superblock (e.g., parity block of each superblock) implements RAIN parity protection (e.g., the individual parity block comprises RAIN parity data) . For instance, each individual superblock of the plurality of superblocks can form an individual RAIN stripe. For some example embodiments, operation 204 is performed during a foreground process, such as during a host read operation performed on the memory device, during a wear leveling operation performed on the memory device (e.g., where data is moved from one superblock to another superblock to level wear on blocks or memory die) , or during a garbage collection operation performed on the memory device.
[0047] To determine whether the individual memory die is bad during operation 204, the processing device can determine whether the individual memory die has become non-response to one or more commands issued to the individual memory die and, in response to determining that the individual memory die has become non-responsive to the one or more commands, the processing device can determine that the individual memory die is bad. Alternatively, or additionally, the processing device can determine whether the individual memory die is bad based on a number of bad blocks of the individual memory die. This can cover situations where the individual memory die remains responsive to commands issued to the individual memory die, but the individual memory die has a lot of bad blocks (e.g., of different superblocks) based on a threshold number of bad blocks. More regarding determining whether the individual memory die is bad based on a number of bad blocks of the individual memory die is illustrated and described with respect to method 300 of FIG. 3.
[0048] At decision block 206, in response to determining that the individual memory die is not bad (or has not failed) , method 200 proceeds returns to operation 204, where the processing device can re-determine whether any memory die (of the plurality of memory die) is bad (or has failed) . Alternatively, at decision block 206, in response to determining that an individual memory die of the plurality of memory die is bad (or has failed) , method 200 proceeds to operation 208, where the processing device marks (e.g., flags) at least one valid block of the individual memory die as a failed-memory-die bad block (e.g., marked as a staged bad block) . The marking can be implemented by a special flag or the like, and the marking can be stored in metadata associated with the one valid block (which can be stored at a memory location not on the individual memory die) . By marking the one valid block, various example embodiments flag the individual memory die for a die rebuild during a background process, thereby deferring the die rebuild of the individual memory die for a later time when the die rebuild will have less of a performance impact on the memory system (e.g., less impact on the performance of the memory sub-system controller 115) , such as when a media scan (or scan) operation is performed on the memory device. For some example embodiments, the processing device marks each valid block of the (bad) individual memory die as a failed-memory-die bad block. This can increase the chances of a background process, such as a scan operation, detecting that the individual memory die is bad and triggering a die rebuild of the individual memory die (e.g., by performing a fold operation on one or more superblocks) .
[0049] Eventually, at operation 210, the processing device performs a scan operation on the memory device. Depending on the example embodiment, the scan operation can be performed periodically on the memory device. Additionally, depending on the example embodiment, the scan operation can be performed as a background process on the memory system (e.g., memory sub-system 110) . In general, the scan operation can check the data integrity of one or more blocks of the memory device, determine the status of each of the one or more blocks (e.g., good or bad blocks) , and perform a folding operation on certain ones of those blocks (e.g., those blocks marked as bad
[0050] For various example embodiments, the scan operation is configured to detect when a block is marked (e.g., flagged) as a failed-memory-die bad block. At operation 212, the processing device determines whether the scan operation detects that at least one valid block is marked as a failed-memory-die bad block. At decision block 214, in response to the scan operation not detecting any valid blocks as being marked as a failed-memory-die bad block, method 200 returns to operation 210, where the processing device can reperform (e.g., periodically reperform) the scan operation on the memory device or continue to perform the scan operation on the memory device. Alternatively, at decision block 214, in response to the scan operation detecting that at least one valid block is marked as a failed-memory-die bad block, method 200 proceeds to operation 216, where the processing device moves data from each select superblock of the plurality of superblocks to an available superblock on the memory device. For some example embodiments, the moving of data from a select superblock (of the plurality of superblocks of the memory device) comprises performing a parity-based operation on the select superblock that uses a select parity block of the select superblock to recreate data stored in a particular block of the select superblock on the individual memory die. For example, where the select superblock implements RAIN parity protection, the processing device can recreate (e.g., recover) data stored by performing an exclusive-OR (XOR) operation of all blocks of the superblock the select parity block (of the select superblock) and all remaining blocks of the select superblock except the particular block (which is on the individual memory die) . Each of the select parity block and the remaining blocks can be on different memory die that are not bad. More regarding this recovery process is described with respect to FIG. 4. For various example embodiments, in response to the scan operation detecting that at least one valid block is marked as a failed-memory-die bad block, the scan operation skips performing data checks on all blocks (e.g., all valid blocks) of the individual memory die. According to some example embodiments, the move of data from each select superblock of the plurality of superblocks to an available superblock on the memory device (and the recreation of the data stored on the bad individual memory die of the plurality of superblocks) is performed as part of a folding operation performed on each select superblock.
[0051] After operation 216 (e.g., the moving of data from each superblock is completed / finished) , at operation 218, the processing device causes the individual memory die to be retired. For some example embodiments, after the individual memory die is retired, the individual memory die is no longer available for use (e.g., reading data from the individual memory die or writing data to the individual memory die) by the memory system (e.g., memory sub-system 110) .
[0052] Referring now to FIG. 3, method 300 of FIG. 3 represents a variation of method 200 illustrated and described with respect to FIG. 2. At operation 302, a processing device (e.g., the processor 117 of the memory sub-system controller 115) monitors an individual number of bad blocks detected for each individual memory die of a plurality of memory die of the memory device (e.g., 130, 140) . Depending on the example embodiment, a number of bad blocks for each memory die (of the plurality of memory die) can be adjusted or updated by a scan operation performed on the memory device, which can determine (e.g., identify) bad blocks (of one or more superblocks) on each memory die of the plurality of memory die. Then, at operation 304, the processing device determines whether any memory die of the plurality of memory die is bad based on respective number of bad blocks. For example, in response to the processing device determining that a number of bad blocks of the individual memory die (of the plurality of memory die) surpasses a threshold value number of bad blocks, the processing device can determine the individual memory die to be bad (or failed) .
[0053] At decision block 306, in response to the processing device determining that an individual memory die (of the plurality of memory die) is bad based on a number of bad blocks of the individual memory die, method 300 proceeds to operation 308. Alternatively, at decision block 306, in response to the processing device determining that no memory die of the plurality of memory die is bad based on a number of bad blocks of the individual memory die, method 300 returns to operation 302, where the processing device continues to monitor an individual number of bad blocks detected for each individual memory die of a plurality of memory die of the memory device (e.g., 130, 140) .
[0054] Operations 308, 310, 312, 314, 316, and 318 are respectively similar to operations 208, 210, 212, 216, and 218 of method 200 of FIG. 2.
[0055] FIG. 4 shows diagrams illustrating an example use of RAIN data error correction to recreate (or recover) data stored on one or more blocks on a bad (or failed) memory die of a memory device, in accordance with some example embodiments of the present disclosure. Referring now to diagram 400, the memory device comprises N memory die designated as memory die 0 (406) through N-1 (414) (represented by memory die 0 406, memory die 1 408, memory die 2 410, memory die n-2 412, and memory die n-1 414) . With implementation of RAIN data error correction, for some example embodiments, each superblock of the memory device comprises a plurality of blocks formed across memory die 0 (406) through N-2 (412) (for storing data, such as user data) and a parity block (storing RAIN parity data / information) on memory die n-1 414 to facilitate recreation (or recovery) of data stored in a block of any one of memory die 0 (406) through N-2 (412) using a RAIN-based technique. For instance, as shown in diagram 402, if a processing device of the memory system determines that memory die 1 408 is bad (or has failed) , the processing device can mark each valid block on the memory die 1 408 as a failed-memory-die bad block. Eventually, when the processing device performs a folding operation on an individual superblock across the memory die 0 (406) through N-1 (414) , data stored on the (bad / failed) memory die 1 408 is recovered using an XOR operation as illustrated by diagram 404. In particular, the block of the superblock on memory die 0 406, the blocks of the superblock on each of memory die 2 410 through memory die n-2 412, and the parity block of the superblock on memory die n-1 414 are XOR′d together to generate recovered data of die 1 416, which represents a recreated / recovered version of data stored on the block of the superblock on the (bad / failed) memory die 1 408.
[0056] FIG. 5 illustrates an example of performing folding operations 512 on superblocks SB 0 through SB K of a memory device, in accordance with some example embodiments of the present disclosure. As shown, the memory device comprises N memory die designated as memory die 0 (502) through N-1 (508) (represented by memory die 0 502, memory die 1 504, memory die 2 506, and memory die N-1 508) . As also shown, the memory device comprises superblocks SB 0 through SB K, where each superblock is formed across memory die 0 (502) through N-1 (508) and implements RAIN data error correction (with RAIN parity data / information being stored on memory die N-1 508) . For illustrative purposes, superblocks SB 0 through SB K represent superblocks currently storing data (e.g., user data) . According to various example embodiments, in response to a processing device of a memory system (e.g., memory sub-system 110) determining that memory die 2 506, the processing device marks all valid blocks on the memory die 2 506 as a failed-memory-die bad block, thereby deferring rebuilding of data stored on the memory die 2 506. Eventually, during a scan operation performed on the memory device, the scan operation will detect at least one valid block on the memory die 2 506 as being a failed- memory-die bad block and trigger folding operations 512 to move data from each of superblocks SB 0 through SB K to available superblocks SB J through SB J+L on the memory device, where each of superblocks SB J through SB J+L is formed across memory die 0 (502) , memory die 1 (504) , and memory die 3 (510) through N-1 (508) (without use of memory die 2 506) and implements RAIN data error correction (with new RAIN parity data / information being stored on memory die N-1 508) . According to various example embodiments, after the folding operations 512 are completed, the memory die 2 506 can be retired to prevent its use by the memory system going forward.
[0057] FIG. 6 illustrates an example machine in the form of a computer system 600 within which a set of instructions can be executed for causing the machine to perform any one or more of the methodologies discussed herein. In some example embodiments, the computer system 600 can correspond to a host system (e.g., the host system 120 of FIG. 1) that includes, is coupled to, or utilizes a memory sub-system (e.g., the memory sub-system 110 of FIG. 1) or can be used to perform the operations described herein. In alternative example embodiments, the machine can be connected (e.g., networked) to other machines in a local area network (LAN) , an intranet, an extranet, and / or the Internet. The machine can operate in the capacity of a server or a client machine in a client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or a client machine in a cloud computing infrastructure or environment.
[0058] The machine can be a personal computer (PC) , a tablet PC, a set-top box (STB) , a Personal Digital Assistant (PDA) , a cellular telephone, a web appliance, a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
[0059] The example computer system 600 includes a processing device 602, a main memory 604 (e.g., ROM, flash memory, DRAM such as SDRAM or Rambus DRAM (RDRAM) , etc. ) , a static memory 606 (e.g., flash memory, static random access memory (SRAM) , etc. ) , and a data storage device 610, which communicate with each other via a bus 618.
[0060] The processing device 602 represents one or more general-purpose processing devices such as a microprocessor, a central processing unit, or the like. More particularly, the processing device 602 can be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor implementing other instruction sets, or processors implementing a combination of instruction sets. The processing device 602 can also be one or more special-purpose processing devices such as an application-specific integrated circuit (ASIC) , a field programmable gate array (FPGA) , a digital signal processor (DSP) , a network processor, or the like. The processing device 602 is configured to execute instructions 616 for performing the operations and steps discussed herein. The computer system 600 can further include a network interface device 608 to communicate over a network 612.
[0061] The data storage device 610 can include a machine-readable storage medium 614 (also known as a computer-readable medium) on which is stored one or more sets of instructions 616 or software embodying any one or more of the methodologies or functions described herein. The instructions 616 can also reside, completely or at least partially, within the main memory 604 and / or within the processing device 602 during execution thereof by the computer system 600, the main memory 604 and the processing device 602 also constituting machine-readable storage media. The machine-readable storage medium 614, data storage device 610, and / or main memory 604 can correspond to the memory sub-system 110 of FIG. 1.
[0062] In one example embodiment, the instructions 616 include instructions to implement functionality corresponding to defer rebuilding (or recreating) of data stored on a memory die of a memory system upon detecting that the memory die is bad (or failed) on a memory sub-system as described herein (e.g., the deferred die rebuilder 113 of FIG. 1) . While the machine-readable storage medium 614 is shown in an example embodiment to be a single medium, the term “machine-readable storage medium” should be taken to include a single medium or multiple media that store the one or more sets of instructions. The term “machine-readable storage medium” shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term “machine-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.
[0063] Described implementations of the subject matter can include one or more features, alone or in combination as illustrated below by way of examples.
[0064] Example 1 is a system comprising: a memory device comprising a plurality of superblocks formed across a plurality of memory die of the memory device, each individual superblock comprising an individual plurality of blocks and an individual parity block for the individual plurality of blocks; memory die; and a processing device, operatively coupled to the memory device, configured to perform operations comprising: determining whether an individual memory die of the plurality of memory die is bad; in response to determining that the individual memory die is bad, marking at least one valid block of the individual memory die as a failed-memory-die bad block; performing a scan operation on the memory device; and in response to the scan operation detecting that the at least one valid block is marked as a failed-memory-die bad block: moving data from each select superblock of the plurality of superblocks to an available superblock on the memory device, the moving of data from the select superblock comprising performing a parity-based operation on the select superblock that uses a select parity block of the select superblock to recreate data stored in a particular block of the select superblock on the individual memory die; and after the moving is complete, causing the individual memory die to be retired.
[0065] In Example 2, the subject matter of Example 1 includes, wherein the marking of the at least one valid block of the individual memory die as a failed die bad block comprises: marking each valid block of the individual memory die as a failed die bad block.
[0066] In Example 3, the subject matter of Examples 1-2 includes, wherein the moving is performed as a part of a folding operation performed on each select superblock of the plurality of superblocks.
[0067] In Example 4, the subject matter of Examples 1-3 includes, wherein the determining of whether the individual memory die is bad comprises: determining that the individual memory die in response to the individual memory die being non-responsive to one or more commands issued to the individual memory die.
[0068] In Example 5, the subject matter of Examples 1-4 includes, wherein the determining of whether the individual memory die is bad comprises: determining whether the individual memory die is bad based on a number of bad blocks of the individual memory die.
[0069] In Example 6, the subject matter of Example 5 includes, wherein the operations comprise: monitoring an individual number of bad blocks detected for each individual memory die of the plurality of memory die.
[0070] In Example 7, the subject matter of Examples 1-6 includes, wherein the individual memory die is determined to be bad during a host read operation performed on the memory device.
[0071] In Example 8, the subject matter of Examples 1-7 includes, wherein the individual memory die is determined to be bad during a wear leveling operation performed on the memory device.
[0072] In Example 9, the subject matter of Examples 1-8 includes, wherein the individual memory die is determined to be bad during a garbage collection operation performed on the memory device.
[0073] In Example 10, the subject matter of Examples 1-9 includes, wherein in response to the scan operation detecting that the at least one valid block is marked as a failed-memory-die bad block, the scan operation skips performing data checks on all blocks of the individual memory die.
[0074] In Example 11, the subject matter of Examples 1-10 includes, wherein the operations comprise: determining whether the scan operation detects that the at least one valid block is marked as a failed-memory-die bad block.
[0075] In Example 12, the subject matter of Examples 1-11 includes, wherein an individual parity block of the individual superblock implements a redundant array of independent NAND-type memory devices (RAIN) parity protection.
[0076] Example 13 is a method to implement any of Examples 1-12.
[0077] Example 14 is at least one machine-readable medium comprising instructions that, when executed by a processing device, cause the processing device to perform operations to implement any of Examples 1-12.
[0078] Some portions of the preceding detailed descriptions have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
[0079] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. The present disclosure can refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system′sregisters and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage systems.
[0080] The present disclosure also relates to an apparatus for performing the operations herein. This apparatus can be specially constructed for the intended purposes, or it can include a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can be stored in a computer-readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.
[0081] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems can be used with programs in accordance with the teachings herein, or it can prove convenient to construct a more specialized apparatus to perform the method. The structure for a variety of these systems will appear as set forth in the description below. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages can be used to implement the teachings of the disclosure as described herein.
[0082] The present disclosure can be provided as a computer program product, or software, that can include a machine-readable medium (such as a non-transitory machine-readable medium) having stored thereon instructions, which can be used to program a computer system (or other electronic devices) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer) . In some example embodiments, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., a computer) readable storage medium such as a ROM, RAM, magnetic disk storage media, optical storage media, flash memory components, and so forth. A machine-readable storage medium can be non-transitory (in other words, not having any transitory signals) in that it does not embody a propagating signal. However, labeling a machine-readable storage medium “non-transitory” should not be construed to mean that the machine-readable storage medium is incapable of movement; the machine-readable storage medium should be considered as being transportable from one physical location to another.
[0083] In the foregoing specification, example embodiments of the disclosure have been described with reference to specific example embodiments thereof. It will be evident that various modifications can be made thereto without departing from the broader spirit and scope of example embodiments of the disclosure as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
Claims
1.A system comprising:a memory device comprising a plurality of superblocks formed across a plurality of memory die of the memory device, each individual superblock comprising an individual plurality of blocks and an individual parity block for the individual plurality of blocks;memory die; anda processing device, operatively coupled to the memory device, configured to perform operations comprising:determining whether an individual memory die of the plurality of memory die is bad;in response to determining that the individual memory die is bad, marking at least one valid block of the individual memory die as a failed-memory-die bad block;performing a scan operation on the memory device; andin response to the scan operation detecting that the at least one valid block is marked as a failed-memory-die bad block:moving data from each select superblock of the plurality of superblocks to an available superblock on the memory device, the moving of data from the select superblock comprising performing a parity-based operation on the select superblock that uses a select parity block of the select superblock to recreate data stored in a particular block of the select superblock on the individual memory die; andafter the moving is complete, causing the individual memory die to be retired.2.The system of claim 1, wherein the marking of the at least one valid block of the individual memory die as a failed die bad block comprises:marking each valid block of the individual memory die as a failed die bad block.3.The system of claim 1, wherein the moving is performed as a part of a folding operation performed on each select superblock of the plurality of superblocks.4.The system of claim 1, wherein the determining of whether the individual memory die is bad comprises:determining that the individual memory die in response to the individual memory die being non-responsive to one or more commands issued to the individual memory die.5.The system of claim 1, wherein the determining of whether the individual memory die is bad comprises:determining whether the individual memory die is bad based on a number of bad blocks of the individual memory die.6.The system of claim 5, wherein the operations comprise:monitoring an individual number of bad blocks detected for each individual memory die of the plurality of memory die.7.The system of claim 1, wherein the individual memory die is determined to be bad during a host read operation performed on the memory device.8.The system of claim 1, wherein the individual memory die is determined to be bad during a wear leveling operation performed on the memory device.9.The system of claim 1, wherein the individual memory die is determined to be bad during a garbage collection operation performed on the memory device.10.The system of claim 1, wherein in response to the scan operation detecting that the at least one valid block is marked as a failed-memory-die bad block, the scan operation skips performing data checks on all blocks of the individual memory die.11.The system of claim 1, wherein the operations comprise:determining whether the scan operation detects that the at least one valid block is marked as a failed-memory-die bad block.12.The system of claim 1, wherein an individual parity block of the individual superblock implements a redundant array of independent NAND-type memory devices (RAIN) parity protection.13.At least one non-transitory machine-readable storage medium comprising instructions that, when executed by a processing device, cause the processing device to perform operations comprising:determining whether an individual memory die of a plurality of memory die of a memory device is bad;in response to determining that the individual memory die is bad, marking at least one valid block of the individual memory die as a failed-memory-die bad block;performing a scan operation on the memory device; andin response to the scan operation detecting that the at least one valid block is marked as a failed-memory-die bad block:moving data from each select superblock of the plurality of superblocks to an available superblock on the memory device, the moving of data from the select superblock comprising performing a parity-based operation on the select superblock that uses a select parity block of the select superblock to recreate data stored in a particular block of the select superblock on the individual memory die; andafter the moving is complete, causing the individual memory die to be retired.14.The at least one non-transitory machine-readable storage medium of claim 13, wherein the marking of the at least one valid block of the individual memory die as a failed die bad block comprises:marking each valid block of the individual memory die as a failed die bad block.15.The at least one non-transitory machine-readable storage medium of claim 13, wherein the moving is performed as a part of a folding operation performed on each select superblock of the plurality of superblocks.16.The at least one non-transitory machine-readable storage medium of claim 13, wherein the determining of whether the individual memory die is bad comprises:determining that the individual memory die in response to the individual memory die being non-responsive to one or more commands issued to the individual memory die.17.The at least one non-transitory machine-readable storage medium of claim 13, wherein the determining of whether the individual memory die is bad comprises:determining whether the individual memory die is bad based on a number of bad blocks of the individual memory die.18.The at least one non-transitory machine-readable storage medium of claim 17, wherein the operations comprise:monitoring an individual number of bad blocks detected for each individual memory die of the plurality of memory die.19.The at least one non-transitory machine-readable storage medium of claim 13, wherein the operations comprise:determining whether the scan operation detects that the at least one valid block is marked as a failed-memory-die bad block.20.A method comprising:determining, by a processing device, that an individual memory die of a plurality of memory die of a memory device is bad, the memory device comprising a plurality of superblocks formed across the plurality of memory die, each individual superblock comprising an individual plurality of blocks and an individual parity block for the individual plurality of blocks;in response to determining that the individual memory die is bad, marking at least one valid block of the individual memory die as a failed-memory-die bad block;performing a scan operation on the memory device; andin response to the scan operation detecting that the at least one valid block is marked as a failed-memory-die bad block:moving data from each select superblock of the plurality of superblocks to an available superblock on the memory device, the moving of data from the select superblock comprising performing a parity-based operation on the select superblock that uses a select parity block of the select superblock to recreate data stored in a particular block of the select superblock on the individual memory die; andafter the moving is complete, causing the individual memory die to be retired.
Citation Information
Patent Citations
Method, apparatus and computer program product for managing an independent redundant disk array
CN112148204A
Redundant array of disk reconstruction method and system oriented to server non-perceptual computing
CN116149576A
Storage control system with data management mechanism of parity and method of operation thereof
US20140156966A1
Reducing rebuild time in a computing storage environment
US20200310914A1
Semiconductor die failure recovery in a data storage device
US20220138065A1