Dynamic Read Error Handling Using Memory Groups

This application claims the benefit of priority to U.S. Provisional Application Ser. No. 63/663,311, filed Jun. 24, 2024, which is incorporated herein by reference in its entirety.

Examples of the disclosure relate generally to memory sub-systems and, more specifically, to providing media management for reading data stored in a set of memory components, such as memory dies or memory blocks.

A memory sub-system can be a storage system, such as a solid-state drive (SSD), and can include one or more memory components that store data. The memory components can be, for example, non-volatile memory components and volatile memory components. In general, a host system can utilize a memory sub-system to store data on the memory components and to retrieve data from the memory components.

The present disclosure configures a system component, such as a memory sub-system controller, to dynamically perform memory management operations for reading data from different groups of memory components (e.g., memory dies, planes, word lines, word line groups (WGP), and/or memory blocks or sub-blocks). The memory sub-system controller can track what read offsets and/or read error handling (REH) operations were performed to decode data in an individual group of memory components and store that information in an ETH entry. Using the information stored in the ETH entry, the controller can selectively perform REH operations to subsequently decode and read data from the individual group of memory components. In this way, one or more REH operations can be skipped or not performed when reading data from the same group of memory components in response to subsequent requests, which improves the overall efficiency of operating the memory sub-system.

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. In general, a host system can utilize a memory sub-system that includes one or more memory components, such as memory devices (e.g., memory dies) that store data. The host system can send access requests (e.g., write command, read command) to the memory sub-system, such as to store data at the memory sub-system and to read data from the memory sub-system. The data (or set of data) specified by the host is hereinafter referred to as “host data,” “application data,” or “user data”.

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 on 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” and can be performed periodically for each block stripe (BS) that is stored in the memory sub-system. “User data” can include 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 address mapping table), data from logging, scratch pad data, etc.

Many different media management operations can be performed on the memory device. For example, the media management operations can include different scan rates, different scan frequencies, different wear leveling, different read disturb management (e.g., read disturb scan operations), different near miss error correction code (ECC), and/or different dynamic data refresh. Wear leveling ensures that all blocks in a memory component approach their defined erase-cycle budget at the same time, rather than some blocks approaching it earlier. Read disturb management counts all of the read operations to the memory component. If a certain threshold is reached, the surrounding regions are refreshed. Near-miss ECC refreshes all data read by the application that exceeds a configured threshold of errors. Dynamic data-refresh scan reads all data and identifies the error status of all blocks as a background operation. If a certain threshold of errors per block or ECC unit is exceeded in this scan-read, a refresh operation is triggered.

A memory device can be a non-volatile memory device. A non-volatile memory device is a package of one or more dice (or dies). Each die can be comprised of one or more planes. For some types of non-volatile memory devices (e.g., NAND 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 is a raw memory device combined with a local embedded controller for memory management within the same memory device package.

NAND flash memory, commonly utilized in a variety of devices from mobile phones to enterprise storage systems, faces significant challenges related to data integrity and operational efficiency as the memory ages. This technology stores data in cells that degrade over time due to repeated use, leading to errors such as bit flips. To maintain data integrity, NAND flash employs several REH and correction mechanisms. These include block family error avoidance (BFEA) bin which stores different read offsets for different block families; CFbyte and CFbit calibration, which adjust read threshold voltages or other read offsets and parameters at the byte and bit levels to enhance reading accuracy; SureARC Calibration, a refinement process that calibrates or adjusts the read offsets at the valley level; Assurance ARC, which ensures data integrity through enhanced error correction during read operations, such as by further adjusting the read offsets at the valley level; 2-bit Corrective Read (2bCR), correcting up to two bits of aggressor bits in an adjacent WL; 4-bit Corrective Read (2bCR), correcting up to four bits of aggressor bits in an adjacent WL; and Redundant Array of Independent NAND (RAIN), providing data redundancy and enhancing error recovery. Corrective Read (CR) is used in attempt to readout the correct data where a normal read operation could not recover the data within ECC limit. The CR is a NAND feature that allows cell-by-cell adjustment of read offsets based on each cell's primary aggressor, its adjacent cells in the adjacent WLs. The 2bCR and 4bCR can require different read strobes on aggressor WLs and provide different corrective capability.

Each of these REH operations consumes additional computational resources and time, leading to operational inefficiencies. Multiple read cycles are often utilized, as initial unsuccessful reads prompt the engagement of more sophisticated mechanisms like CFbit calibration or SureARC, each necessitating new read attempts. This not only increases latency, significantly impacting data access times, but also consumes additional power and processing capacity, reducing overall system efficiency.

The impact of aging on NAND flash exacerbates these issues. As NAND cells wear out, the frequency and severity of errors increase, leading to a higher reliance on error correction and handling mechanisms. This results in an increased frequency of engaging mechanisms like 2bCR and RAIN, further slowing down the system and necessitating repeated recalibrations and error checks, such as Sure Arc and CFbit calibrations. These factors collectively contribute to reduced operational efficiency and reduce the usable life of NAND flash memory.

The present disclosure addresses the above and other deficiencies by providing a memory controller that can dynamically control whether certain REH operations are performed for reading data from an individual WGP. The memory sub-system controller can track what read offsets and/or REH operations were performed to successfully decode data in an individual group of memory components and store that information in an ETH entry. Using the information stored in the ETH entry, the controller can selectively perform (or not perform) REH operations (e.g., certain REH operations can be omitted, skipped or excluded) to subsequently decode and read data from the individual group of memory components. By avoiding performing one or more REH operations when reading data from the same group of memory components in response to subsequent requests, the overall efficiency of operating the memory sub-system is improved.

For some examples, the memory sub-system (e.g., memory sub-system controller) receives a request to read data from one or more blocks of a WGP stored in the set of memory components. The controller can determine, in response to receiving the request to read the data, that a dynamic error handling (ETH) entry is associated with the WGP and can retrieve, from the ETH entry, a read offset used to previously decode one or more pages from the WGP. The controller can selectively perform a set of REH operations to decode the data from the one or more blocks of the WGP using the read offset retrieved from the ETH entry.

The controller can, prior to receiving the request, receive a prior request to read the one or more pages of data from a set of blocks of the WGP. The controller can determine, in response to receiving the prior request, that the ETH entry is unavailable for the WGP and, in response to determining that the ETH entry is unavailable for the WGP, can perform each REH operation in the set of REH operations to read the one or more pages. In some examples, the ETH entry has not been created for the WGP when the prior request is received.

In some examples, the controller can determine the read offset based on performing each of the REH operations in the set of REH operations and determines a last REH operation in the set of REH operations that resulted in successfully decoding the one or more pages of the set of blocks. In some cases, the controller generates the ETH entry to include the determined read offset and the last REH operation that resulted in successfully decoding the one or more pages of the set of blocks. The controller stores, in the ETH entry, an identifier of the WGP and an identifier of a plane storing the one or more pages of the set of blocks. The set of REH operations can include a first read offset determination based on BFEA bin, a second read offset determination based on CFbyte, a third read offset determination based on CFbit calibration, one or more read offset valley adjustments, one or more first types of bit error correction code (ECC) operations, and one or more second types of ECC operations.

The controller can search a plurality of WGPs stored in a list of ETH entries to identify the ETH entry having a WGP that corresponds to the WGP associated with the request to read the data. In some cases, the controller can perform a first REH operation in the set of REH operations including reading a first page of the one or more blocks using the read offset retrieved from the ETH entry and determining whether the first page has been successfully decoded using the first REH operation. In some examples, the controller, in response to determining that the first page has unsuccessfully been decoded, retrieves, from the ETH entry, a last REH operation in the set of REH operations that resulted in successfully previously decoding the one or more pages and performs the last REH operation retrieved from the ETH entry to decode the first page.

The controller can determine that the first page has been successfully decoded using the last REH operation. In response, the controller decodes one or more additional pages using the last REH operation. In some examples, the controller determines that the first page has been unsuccessfully decoded using the last REH operation. In such cases, in response to determining that the first page has been unsuccessfully decoded using the last REH operation, the controller can perform one or more read offset valley adjustments based on the read offset retrieved from the ETH entry to decode the first page using a new read offset.

The controller can determine that the first page has been successfully decoded using the one or more read offset valley adjustments. In such cases, the controller can, in response to determining that the first page has been successfully decoded using the one or more read offset valley adjustments, update the read offset stored in the ETH entry using the new read offset. In some cases, the one or more read offset valley adjustments include multiple types of valley adjustment operations (e.g., SureArc calibration and Assurance ARC calibration).

In some examples, the controller can determine that the first page has been unsuccessfully decoded using the one or more read offset valley adjustments. The controller can perform each REH operation in the set of REH operations to read the first page in response to determining that the first page has been unsuccessfully decoded using the one or more read offset valley adjustments. In some cases, the controller updates the ETH entry in response to performing each REH operation in the set of REH operations to read the first page.

Though various examples are described herein as being implemented with respect to a memory sub-system (e.g., a controller of the memory sub-system), some or all of the portions of an example can be implemented with respect to a host system, such as a software application or an operating system of the host system.

illustrates an example computing environmentincluding a memory sub-system, in accordance with some examples. The memory sub-systemcan include media, such as memory componentsA toN (also hereinafter referred to as “memory devices”). The memory componentsA toN can be volatile memory devices, non-volatile memory devices, or a combination of such. The memory componentsA toN can be implemented by individual dies, such that a first memory componentA can be implemented by a first memory die (or a first collection of memory dies) and a second memory componentN can be implemented by a second memory die (or a second collection of memory dies).

In some examples, the memory sub-systemis a storage system. A memory sub-systemcan 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, 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 a non-volatile dual in-line memory module (NVDIMM).

The computing environmentcan include a host systemthat is coupled to a memory system. The memory system can include one or more memory sub-systems. In some examples, the host systemis coupled to different types of memory sub-system.illustrates one example of a host systemcoupled to one memory sub-system. The host systemuses the memory sub-system, for example, to write data to the memory sub-systemand read data from the memory sub-system. As used herein, “coupled to” 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, etc.

The host systemcan be a computing device such as a desktop computer, laptop computer, network server, mobile device, embedded computer (e.g., one included in a vehicle, industrial equipment, or a networked commercial device), or such computing device that includes a memory and a processing device. The host systemcan include or be coupled to the memory sub-systemso that the host systemcan read data from or write data to the memory sub-system. The host systemcan be coupled to the memory sub-systemvia 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), 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 systemand the memory sub-system. The host systemcan further utilize an NVM Express (NVMe) interface to access the memory componentsA toN when the memory sub-systemis coupled with the host systemby 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-systemand the host system.

The memory componentsA toN can include any combination of the different types of non-volatile memory components and/or volatile memory components. An example of non-volatile memory components includes NOR- and (NAND)-type flash memory. Each of the memory componentsA toN can include one or more arrays of memory cells such as single-level cells (SLCs) or multi-level cells (MLCs) (e.g., TLCs or QLCs). In some examples, a particular memory componentcan include both an SLC portion and an MLC portion of memory cells. Each of the memory cells can store one or more bits of data (e.g., blocks) used by the host system. Although non-volatile memory components such as NAND-type flash memory are described, the memory componentsA toN can be based on any other type of memory, such as a volatile memory.

In some examples, the memory componentsA toN can be, but are not limited to, random access memory (RAM), read-only memory (ROM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), phase change memory (PCM), magnetoresistive random access memory (MRAM), (NOR) flash memory, electrically erasable programmable read-only memory (EEPROM), and a cross-point array of non-volatile memory cells. A cross-point array of non-volatile memory cells 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. Furthermore, the memory cells of the memory componentsA toN can be grouped as memory pages, WLs, WGPs, planes, blocks, or sub-blocks that can refer to a unit of the memory componentused to store data. In general, the memory pages, WLs, WGPs, sub-blocks, and/or blocks are collectively or individually referred to as memory components.

The memory sub-system controllercan communicate with the memory componentsA toN to perform operations such as reading data, writing data, or erasing data at the memory componentsA toN and other such operations. The memory sub-system controllercan communicate with the memory componentsA toN to perform various memory management operations, such as different scan rates, different scan frequencies, different wear leveling, different read disturb management operations, such as read disturb scan operations, different near miss ECC operations, folding operations, preventing folding operations from being performed, and/or different dynamic data refresh operations.

The memory sub-system controllercan include hardware such as one or more integrated circuits and/or discrete components, one or more thermometers (used to measure a current operating temperature of the memory sub-systemand/or the memory componentsA toN or ambient temperature), a buffer memory, and/or a combination thereof. In some examples, the output of the one or more thermometers can be used to determine a current write temperature to be stored in association with data on the memory componentsA toN.

The memory sub-system controllercan be a microcontroller, special-purpose logic circuitry (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), or another suitable processor. The memory sub-system controllercan include a processor (processing device)configured to execute instructions stored in local memory. In the illustrated example, the local memoryof the memory sub-system controllerincludes an embedded memory configured to store instructions for performing various processes, operations, logic flows, and routines that control operation of the memory sub-system, including handling communications between the memory sub-systemand the host system. In some examples, the local memorycan include memory registers storing memory pointers, fetched data, and so forth. The local memorycan also include read-only memory (ROM) for storing microcode. While the example memory sub-systeminhas been illustrated as including the memory sub-system controller, in another example, a memory sub-systemmay not include a memory sub-system controller, and can instead rely upon external control (e.g., provided by an external host, or by a processoror controller separate from the memory sub-system).

In general, the memory sub-system controllercan receive commands, requests, or operations from the host systemand can convert the commands, requests, or operations into instructions or appropriate commands to achieve the desired access to the memory componentsA toN. In some examples, the commands or operations received from the host systemcan specify configuration data for the memory componentsA toN. The configuration data can include a table that specifies the WGPs or other grouping information for the data stored in the set of memory componentsA toN.

The memory sub-system controllercan be responsible for other memory management operations, such as wear leveling operations, garbage collection operations, error detection and error-correcting code (ECC) operations, encryption operations, caching operations, media scans (where different block stripes are read and analyzed for errors to determine whether to refresh or fold the block stripe), data refreshing, read disturb operations, and address translations. The memory sub-system controllercan further include host interface circuitry to communicate with the host systemvia the physical host interface. The host interface circuitry can convert the commands received from the host systeminto command instructions to access the memory componentsA toN as well as convert responses associated with the memory componentsA toN into information for the host system.

The memory sub-systemcan also include additional circuitry or components that are not illustrated. In some examples, the memory sub-systemcan include a cache or buffer (e.g., DRAM or other temporary storage location or device) and address circuitry (e.g., a row decoder and a column decoder) that can receive an address from the memory sub-system controllerand decode the address to access the memory componentsA toN.

The memory devices can be raw memory devices (e.g., NAND), which are managed externally, for example, by an external controller (e.g., memory sub-system controller). The memory devices can be managed memory devices (e.g., managed NAND), which is a raw memory device combined with a local embedded controller (e.g., local media controllers) for memory management within the same memory device package. Any one of the memory componentsA toN can include a media controller (e.g., media controllerA and media controllerN) to manage the memory cells of the memory component (e.g., to perform one or more memory management operations), to communicate with the memory sub-system controller, and to execute memory requests (e.g., read or write) received from the memory sub-system controller.

The memory sub-system controllercan include a media operations manager. The media operations managercan be configured to provide adaptive read error handling operations. The media operations managerreceives a request to read data from one or more blocks of a WGP stored in a set of memory components. The media operations managerdetermines, in response to receiving the request to read the data, that a ETH entry is associated with the WGP. The media operations managerretrieves, from the ETH entry, a read offset used to previously decode one or more pages from the WGP and selectively performs a set of REH operations to decode the data from the one or more blocks of the WGP using the read offset retrieved from the ETH entry.

Depending on the examples, the media operations managercan comprise logic (e.g., a set of transitory or non-transitory machine instructions, such as firmware) or one or more components that cause the media operations managerto perform operations described herein. The media operations managercan comprise a tangible or non-tangible unit capable of performing operations described herein. Further details with regard to the operations of the media operations managerare described below.

is a block diagram of an example media operations manager(corresponding to media operations manager), in accordance with some examples. As illustrated, the media operations managerincludes configuration data, an ETH entry component, and a media operation component. For some examples, the media operations managercan differ in components or arrangement (e.g., less or fewer components) from what is illustrated in.

The configuration dataaccesses and/or stores configuration data associated with the memory componentsA toN. In some examples, the configuration datais programmed into the media operations manager. For example, the media operations managercan communicate with the memory componentsA toN to obtain the configuration data and store the configuration datalocally on the media operations manager. In some examples, the media operations managercommunicates with the host system. The host systemreceives input from an operator or user that specifies parameters including the WGPs, different bins, groups, blocks, WLs, memory dies, and/or sets of the memory componentsA toN. The media operations managerreceives the configuration data from the host systemand stores the configuration data in the configuration data.

The media operation componentcan receive a request to read a set of data that is stored in the set of memory componentsA toN, such as from the host system. In response, the media operation componentcan selectively perform one or more REH operations in the process of reading and decoding the data. Specifically, the media operation componentcan selectively exclude certain REH operations if the data is being read from a WGP that is associated with one or more ETH entries. In some examples, the media operation componentcan determine the WGP in which at least a portion of the data being requested to be read is stored or programmed. The media operation componentcan search a list of ETH entries to find or determine whether an ETH entry has previously been generated and stored for the WGP.

In some examples, the media operation componentcan search WGP identifiersof each ETH entry, shown in the diagramof. The media operation componentcan determine whether the WGP identifierof a particular ETH entrymatches or corresponds to the WGP that stores at least a portion of the data requested to be read. In response to determining that none of the ETH entriesinclude a matching WGP identifiers, the media operation componentperforms normal (default) reading/decoding operations in which each of a set of REH operations is performed to read/decode the data. Specifically, the media operation componentcan obtain a default or known read offset (e.g., threshold voltage level) corresponding to a BFEA bin associated with the storage location of the data being read. Then, the media operation componentcan perform CFbyte and/or CFbit operations to refine or adjust the read offset. The media operation componentcan then perform one or more valley adjustment operations, such as SureArc and/or Arc operations to refine the read offset. The media operation componentcan also perform 2bCR, hard bit decoding and/or 4bCR and also RAIN operations to correct the data being read. The media operation componentcan stop performing subsequent REH operations when any one of these REH operations successfully decodes the data from the storage location.

After reading and decoding the data by performing each of the REH operations or portion thereof needed to successfully decode the data, the media operation componentcan communicate with the ETH entry componentto generate and store a new ETH entry for the WGP. The media operation componentcan provide an identifier of the WGP, which is stored by the media operation componentin the WGP identifiersof the new ETH entry. The media operation componentcan also provide one or more plane identifiers representing the planes that were successfully read/decoded. These one or more plane identifiers are stored in the plane identifier fieldof the new ETH entry. The ETH entry componentcan also store in the LSRO fieldof the new ETH entry, the read offset that was used to successfully decode the data. The ETH entry componentcan also store in the LSRS fieldan identifier of the last REH operation that was performed to successfully decode the data.

Subsequently or at another time, the media operation componentcan receive a request to read an additional set of data from the set of memory componentsA toN. In response, the media operation componentcan communicate with the ETH entry componentto determine whether a WGP of the additional set of data matches any WGP identifier stored in the WGP identifiersof ETH entries. The ETH entry componentcan return the ETH entryhaving the matching WGP identifierto the media operation component. The media operation componentcan then use the information stored in the ETH entryto read and decode the additional set of data using fewer REH operations than previously read data from the same WGP.

For example, the media operation componentcan retrieve the previously used read offset level stored in the LSRO fieldfrom the ETH entry. The media operation componentcan then read or re-read a first portion (e.g., a first page of data) of the data from one or more storage locations of the additional set of data using the previously used read offset level (the read offset used to successfully read and decode data from the same WGP) stored in the LSRO field. The media operation componentcan determine whether the data is successfully decoded using the previously used read offset level. If so, the media operation componentcan then read a second portion (e.g., a second page of data) from the one or more storage locations of the additional set of data using the previously used read offset level and can continue doing so until data is unsuccessfully decoded. At that point (e.g., in response to determining that using the previously used read offset level to read one or more portions, such as a third page, of the data from the same WGP results in unsuccessful decoding or a failed REH operation), the media operation componentcan obtain an identifier of the last REH operation used to decode data from the WGP stored in the LSRS field.

For example, the media operation componentcan apply a 2bCR REH operation to decode the one or more portions of the data (e.g., a third page) using the last REH operation. The media operation componentcan determine whether the third page is successfully decoded using the last REH operation and the 2bCR REH operation. If so, the media operation componentcontinues decoding additional portions using the same REH operation and the 2bCR REH operation. If the third page is unsuccessfully decoded, the media operation componentcan perform one or more valley adjustments (e.g., an ARC valley adjustment) to the read offset level and can attempt to read the data using the adjusted read offset level. The media operation componentcan determine that the third page is successfully decoded using the adjusted read offset level. In response, the media operation componentupdates the fields (e.g., the LSRO fieldand/or the LSRS field) of the ETH entryassociated with the WGP.

The media operation componentcan determine that the decoding of the third page using the adjusted read offset level has failed. In response, the media operation componentcan perform further valley adjustments using another type of valley adjustment process along with 2bCR to re-read the third page. The media operation componentcan determine that the third page is successfully decoded using the further adjusted read offset level and the 2bCR. In response, the ETH entry componentupdates the fields (e.g., the LSRO fieldand/or the LSRS field) of the ETH entryassociated with the WGP with the new read offset level and the indication of the last REH operation performed to successfully read/decode data from the WGP.

In some cases, the media operation componentcan determine that the decoding of the third page using the adjusted read offset level and the 2bCR has failed. In such cases, the media operation componentcan read and decode the third page using default REH operations (discussed above). The media operation componentcan then communicate new parameters resulting from applying the default REH operations to the ETH entry componentto update the corresponding ETH entry.

is a flow diagram of an example methodto perform media management operations, in accordance with some examples. The methodcan be performed by processing logic that can include hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions run or executed on a processing device), or a combination thereof. In some examples, the methodis performed by the media operations managerof. Although the processes are shown in a particular sequence or order, unless otherwise specified, the order of the processes can be modified. Thus, the illustrated examples 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 examples. Thus, not all processes are required in every example. Other process flows are possible.

Referring now to, the method (or process)begins at operation, with a media operations managerof a memory sub-systemreceiving a request to read data from one or more blocks of a WGP stored in a set of memory components. At operation, the media operations managerof the memory sub-systemdetermines, in response to receiving the request to read the data, that an ETH entry is associated with the WGP. Thereafter, at operation, the media operations managerretrieves, from the ETH entry, a read offset used to previously decode one or more pages from the WGP and, at operation, selectively performing a set of REH operations to decode the data from the one or more blocks of the WGP using the read offset retrieved from the ETH entry.

is a flow diagram of an example methodto perform media management operations, in accordance with some examples. The methodcan be performed by processing logic that can include hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions run or executed on a processing device), or a combination thereof. In some examples, the methodis performed by the media operations managerof. Although the processes are shown in a particular sequence or order, unless otherwise specified, the order of the processes can be modified. Thus, the illustrated examples 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 examples. Thus, not all processes are required in every example. Other process flows are possible.

Referring now to, the method (or process)begins at operationwhere the media operations manager(e.g., the firmware of the memory sub-system) receiving a request to read a set of data from the set of memory componentsA toN (e.g., a WGP). The media operations managercan search a set of ETH entriesto determine whether an ETH exists for the WGP being read. If so, the media operations managerproceeds to operationand, if not, the media operations managerproceeds to operation. At operation, the media operations manageruses a set of default REH operations to read the data stored in the WGP of the set of memory componentsA toN. For example, the media operations managercan obtain a default or known read offset (e.g., threshold voltage level) corresponding to a BFEA bin associated with the storage location of the data being read. Then, the media operations managercan perform CFbyte and/or CFbit operations to refine or adjust the read offset. The media operations managercan then perform one or more valley adjustment operations, such as SureArc and/or Arc operations to refine the read offset. The media operations managercan also perform 2bCR, hard bit decoding and/or 4bCR and also RAIN operations to correct the data being read. The media operations managercan stop performing subsequent REH operations when any one of these REH operations successfully decodes the data from the storage location.

After performing the operation, the media operations managercan generate an ETH entryfor the WGP at operationor update an existing one. In some cases, the media operations managercan obtain the last used read offset level at operationto read the set of data from the WGP. The media operations managercan determine whether the last used read offset successfully decodes the data. If so, the media operations managercontinues decoding additional portions of the data until the decoding fails. At that point, the media operations managerperforms operationwhere a determination is made as to whether 2bCR decoding was successfully used to decode a portion of data stored in the same WGP. If so, the media operations managerperforms operationto decode the current set of data using the 2bCR decoding process of the set of REH operations. The media operations managercontinues decoding additional portions using the 2bCR decoding process until decoding fails. At that point, the media operations managerperforms operationwhere the read level offset is adjusted using a valley adjustment process.