Multi-state prison for media management of memory subsystems

Abstract

The invention relates to a multi-state prison for media management of a memory subsystem. A processing device may determine a valid data count for a data block of a memory subsystem. In some cases, the valid data count may indicate that the data block contains invalid data. The processing device may assign the data blocks to a first jail state based on the valid data count, and may verify that one or more read operations of the data blocks in the first jail state have been completed based on the first jail state. In some examples, the processing device may assign the data block to a second prison state based on the verification.

Description

[0001] Information about divisional applications

[0002] This case is a divisional application. The parent case of the divisional application is an invention patent application with an application date of February 2, 2021, application number 202110143420.5, and invention name “Multi-state purgatory for media management of memory subsystem”.

[0003] Cross-references

[0004] This patent application claims priority to U.S. patent application No. 16 / 786,910, filed by Bianco on February 2, 2020, entitled "MULTI STATE PURGATORY FOR MEDIA MANAGEMENT FOR AMEMORY SUB-SYSTEM," which has been assigned to the assignee of this application and is expressly incorporated herein by reference in its entirety.

[0005] The technical field relates to multi-state purgatory for media management of memory subsystems. Background Art

[0006] The memory subsystem may include one or more memory devices that store data. The memory devices may be, for example, non-volatile memory devices and volatile memory devices. Generally speaking, the host system may utilize the memory subsystem to store data at the memory devices and retrieve data from the memory devices. Summary of the invention

[0007] A method is described. The method may include: determining a valid data count of a data block of a memory subsystem, wherein the valid data count indicates that the data block contains invalid data; assigning the data block to a first hell state based at least in part on the valid data count; verifying that one or more read operations to the data block in the first hell state have completed based at least in part on the first hell state; and assigning the data block to a second hell state based at least in part on the verifying.

[0008] A system is described. The system may include a plurality of memory components and a processing device operably coupled to the plurality of memory components to implement the following operations: determining that the amount of valid data of a data block of the plurality of memory components falls below a threshold; allocating the data block to a first infernal pool based at least in part on the determination that the amount of valid data of the data block of the plurality of memory components falls below the threshold; and allocating the data block to a second infernal pool based at least in part on completing one or more read operations on the data block in the first infernal pool.

[0009] A non-transitory computer-readable storage medium is described. The non-transitory computer-readable storage medium includes instructions that, when executed by a processing device, cause the processing device to perform the following operations: determining a valid data count of a data block of a memory subsystem, wherein the valid data count indicates that the data block contains invalid data; assigning the data block to a first hell state based at least in part on the valid data count; verifying that one or more read operations on the data block in the first hell state have been completed based at least in part on the first hell state; and assigning the data block to a second hell state based at least in part on the verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The present disclosure will be more fully understood through the detailed description given below and the accompanying drawings of various embodiments of the present disclosure. However, the accompanying drawings should not be considered to limit the present disclosure to specific embodiments, but are only for explanation and description.

[0011] Figure 1 An example of a computing system including a memory subsystem according to some examples of the present disclosure is illustrated.

[0012] Figure 2 is a method diagram of an example method for multi-state purgatory for media management according to some examples of the present disclosure.

[0013] Figure 3 is a block diagram of an example system in which Multi-State Purgatory for media management can operate.

[0014] Figure 4 is a block diagram of an example computer system in which examples of the present disclosure may operate. DETAILED DESCRIPTION

[0015] Various aspects of the present disclosure relate to a multi-state purgatory for media management of a memory subsystem. The memory subsystem may be a storage device, a memory module, or a combination of a storage device and a memory module. Figure 1Examples of storage devices and memory modules are described. In general, a host system can utilize a memory subsystem that includes one or more components, such as a memory device that stores data. The host system can provide data to be stored in the memory subsystem and can request to retrieve data from the memory subsystem.

[0016] The memory device may be a non-volatile memory device. The non-volatile memory device is one or more die blocks of a package. Each die may be composed of one or more planes. For some types of non-volatile memory devices (e.g., NAND devices), each plane is composed of a set of physical blocks. Each block is composed of a set of pages. Each page is composed of a set of memory cells storing data bits. For some memory devices (such as NAND devices), a block is the smallest area that can be erased and pages within a block cannot be erased individually. For such devices, an erase operation is performed one block at a time.

[0017] The pages of a block may contain valid data, invalid data, or no data. Invalid data is data that is marked as obsolete due to a new version of the data being stored on the memory device. Invalid data includes data that was previously written but is no longer associated with a valid logical address (such as a logical address referenced by the host system in a physical to logical (P2L) mapping table). Valid data is the latest version of such data stored on the memory device. The memory subsystem may mark data as invalid based on information received from the operating system, for example. Pages that do not contain data include pages that were previously erased but not yet written.

[0018] The memory subsystem controller may perform operations of media management algorithms such as wear leveling, refresh, garbage collection, scrubbing, etc. A block may have some pages with valid data and some pages with invalid data. To avoid waiting for all pages in a block to have invalid data in order to erase and reuse the block, an algorithm referred to below as "garbage collection" may be invoked, allowing the block to be erased and released as a free block for subsequent write operations. Garbage collection is a set of media management operations that includes, for example, selecting blocks with valid and invalid data, selecting pages in a block with valid data, copying the valid data to a new location (e.g., a free page in another block), marking the data in a previously selected page as invalid, and erasing the selected block.

[0019] "Garbage collection" hereinafter refers to selecting a block, rewriting valid data from the selected block to another block, and erasing all invalid data and valid data stored at the selected block. Valid data from a plurality of selected blocks may be copied to a smaller number of other blocks, and then the selected block may be erased. As a result, the number of erased blocks may be increased, making more blocks available for storing subsequent data from the host system.

[0020] During garbage collection, first, based on one or more read commands issued by the memory device controller, valid data of the block to be erased is read into and stored by the buffer, and the corresponding page (e.g., a page containing valid data thereon) is erased. Then, the valid data can be written (e.g., rewritten) to the memory device (e.g., a different page of the memory device). In order to write valid data to a certain location (e.g., a different page of the memory device), a write command is issued by the memory subsystem controller, each write command indicating a memory address (e.g., a target memory address) to which the valid data is to be written. In some garbage collection programs, a write command is issued once the corresponding read command is completed. That is, a read command for data at a source memory address (e.g., a memory address on a page to be erased).

[0021] In some cases, there may be a delay between rewriting valid data to the memory device and updating a table indicating the location of the rewritten valid data. In some instances, the data block (e.g., containing the address of the rewritten valid data) may be erased before updating the table indicating the location of the rewritten valid data. Such techniques (e.g., erasing data before updating the memory address) may cause the memory device to incur a performance loss during a garbage collection procedure due to the loss of the memory address location of the rewritten valid data, which may increase the latency of future read operations to be performed on the data block.

[0022] In some instances, data blocks may be saved in a temporary saving pool such as a purgatory state. In conventional systems, a memory subsystem may include a single purgatory state. The single purgatory state may be used for data blocks that are undergoing a garbage collection procedure or for all data blocks to ensure that host read operations on the data blocks have been completed. In such cases, the single purgatory state may cycle between saving data blocks that are undergoing a garbage collection procedure and then saving all data blocks to ensure that host read operations on the data blocks have been completed. Because host read commands and garbage collection read commands may be issued to the data blocks as long as the data blocks remain in the single purgatory state, a memory subsystem that includes a single purgatory state may reduce the overall performance of the memory subsystem, which may result in increased erase times and processing times associated with updating the addresses of the data blocks to new locations.

[0023] Aspects of the present disclosure address these and other issues by using a multi-state purgatory for media management (such as garbage collection). Throughout this document, garbage collection is used as an example of a media management operation. For example, data blocks can be assigned to different purgatory states in order to save the data blocks, check the operation of the memory subsystem, and avoid premature deletion of the data blocks (e.g., before erasing the data blocks without updating the memory address). That is, when a data block no longer contains any valid data, the data block may not be safely erased, so such data blocks can be moved to a purgatory state until safety can be ensured. In some instances, one purgatory state can be for data blocks that are subject to a garbage collection procedure to ensure that all garbage collection read operations on the data blocks have been completed. Another purgatory state can be for all data blocks to ensure that host read operations on the data blocks have been completed. By assigning data blocks to more than one purgatory state, the overall performance of the memory subsystem can be increased. For example, multi-state purgatory garbage collection can improve the overall efficiency of the memory subsystem (e.g., delays caused by memory addresses of lost data blocks), which can increase the read, write, and erase speeds of the memory subsystem, reduce its power consumption, shorten its processing time, etc.

[0024] First, in reference Figure 1 Features of the present disclosure are described in the context of the described computing environment. Figure 2 and 3 Features of the present disclosure are described in the context of the methods and block diagrams described herein. Further, reference is made to Figure 4 The described computer system for a multi-state purgatory for garbage collection illustrates and describes these and other features of the present disclosure.

[0025] Figure 1 An example computing system 100 including a memory subsystem 110 is illustrated according to some embodiments of the present disclosure. Memory subsystem 110 may include media such as one or more non-volatile memory devices (e.g., memory device 130), one or more volatile memory devices (e.g., memory device 140), or a combination of both.

[0026] The memory subsystem 110 may be a storage device, a memory module, or a combination of a storage device and a memory module. Examples of storage devices include solid-state drives (SSDs), flash drives, universal serial bus (USB) flash drives, embedded multimedia controllers (eMMC) drives, universal flash storage (UFS) drives, secure digital (SD) cards, and hard disk drives (HDDs). Examples of memory modules include dual in-line memory modules (DIMMs), small outline DIMMs (SO-DIMMs), and various types of non-volatile DIMMs (NVDIMMs).

[0027] The computing system 100 may be a computing device such as a desktop computer, a laptop computer, a network server, a mobile device, a vehicle (e.g., an airplane, a drone, a train, a car, or other means of transportation), an Internet of Things (IoT) enabled device, an embedded computer (e.g., a computer included in a vehicle, industrial equipment, or a networked commercial device), or those computing devices that include a memory and a processing device.

[0028] Computing system 100 can include a host system 105 coupled to one or more memory subsystems 110. In some examples, host system 105 is coupled to memory subsystems 110 of different types. Figure 1 An example of a host system 105 coupled to a memory subsystem 110 is shown. As used herein, "coupled to" or "coupled with" generally refers to a connection between components, which can be an indirect communication connection, wired or wireless, or a direct communication connection (e.g., without intermediate components), including connections such as electrical connections, optical connections, magnetic connections, and the like.

[0029] The host system 105 may include a processor chipset and a software stack executed by the processor chipset. The processor chipset may include one or more cores, one or more caches, a memory controller (e.g., an NVDIMM controller), and a storage protocol controller (e.g., a PCIe controller, a SATA controller). The host system 105 uses the memory subsystem 110, for example, to write data to the memory subsystem 110 and read data from the memory subsystem 110.

[0030] The host system 105 may be coupled to the memory subsystem 110 using a physical host interface. Examples of the physical host interface include, but are not limited to, a Serial Advanced Technology Attachment (SATA) interface, a Peripheral Component Interconnect Express (PCIe) interface, a Universal Serial Bus (USB) interface, a Fibre Channel, a Serial Attached SCSI (SAS), a Small Computer System Interface (SCSI), a Double Data Rate (DDR) memory bus, a Dual In-line Memory Module (DIMM) interface (e.g., a DIMM socket interface supporting Double Data Rate (DDR)), an Open NAND Flash Interface (ONFI), Double Data Rate (DDR), Low Power Double Data Rate (LPDDR), or any other interface. The physical host interface may be used to transfer data between the host system 105 and the memory subsystem 110. When the memory subsystem 110 is coupled to the host system 105 via a PCIe interface, the host system 105 may further utilize a Non-Volatile Memory Express (NVMe) interface to access components (e.g., the memory device 130). The physical host interface may provide an interface for passing control, address, data, and other signals between the memory subsystem 110 and the host system 105 . Figure 1 The memory subsystem 110 is illustrated by way of example. In general, the host system 105 can access multiple memory subsystems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

[0031] Memory devices 130, 140 may include any combination of different types of non-volatile memory devices and / or volatile memory devices. Volatile memory devices (e.g., memory device 140) may be, but are not limited to, random access memory (RAM) such as dynamic RAM (DRAM) and synchronous DRAM (SDRAM).

[0032] Some examples of non-volatile memory devices (e.g., memory device 130) include NAND-type flash memory and write-in-place memory, such as a three-dimensional cross-point ("3D cross-point") memory device, which is a cross-point array of non-volatile memory cells. The cross-point array of non-volatile memory can be combined with a stackable cross-grid data access array to perform bit storage based on changes in body resistance. In addition, compared to many flash-based memories, cross-point non-volatile memory can perform write-in-place operations, where non-volatile memory cells can be programmed without first erasing the non-volatile memory cells. NAND-type flash memory includes, for example, two-dimensional NAND (2D NAND) and three-dimensional NAND (3D NAND).

[0033] Each memory device 130 may include one or more memory cell arrays. For one type of memory cell, for example, a single-level cell (SLC), one bit may be stored in each cell. For other types of memory cells, such as multi-level cells (MLC), triple-level cells (TLC), and quad-level cells (QLC), multiple bits may be stored in each cell. In some embodiments, each memory device 130 may include one or more memory cell arrays, such as SLC, MLC, TLC, QLC, or any combination of the like. In some embodiments, a particular memory device may include an SLC portion, and an MLC portion, a TLC portion, or a QLC portion of a memory cell. The memory cells of the memory device 130 may be grouped into pages, which may refer to logical units of a memory device for storing data. With some types of memory (e.g., NAND), pages may be grouped to form blocks.

[0034] Although nonvolatile memory components such as NAND-type flash memory (e.g., 2D NAND, 3D NAND) and 3D cross-point arrays of nonvolatile memory cells are described, the memory device 130 can be based on any other type of nonvolatile memory, such as read-only memory (ROM), phase change memory (PCM), self-selected memory, other chalcogenide-based memories, ferroelectric transistor random access memory (FeTRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), spin-transfer torque (STT)-MRAM, conductor bridge RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), non-OR (NOR) flash memory, and electrically erasable programmable ROM (EEPROM).

[0035] The memory subsystem controller 115 (or controller 115 for brevity) can communicate with the memory device 130 to perform operations such as reading data, writing data, or erasing data, and other such operations at the memory device 130. The memory subsystem controller 115 can include hardware such as one or more integrated circuits and / or discrete components, buffer memory, or a combination thereof. The hardware can include digital circuitry with dedicated (i.e., hard-coded) logic for performing the operations described herein. The memory subsystem controller 115 can be a microcontroller, dedicated logic circuitry (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a digital signal processor (DSP)), or other suitable processor.

[0036] The memory subsystem controller 115 may include a processor 120 (e.g., a processing device) configured to execute instructions stored in a local memory 125. In the illustrated example, the local memory 125 of the memory subsystem controller 115 includes an embedded memory configured to store instructions for performing various processes, operations, logic flows, and routines for controlling the operation of the memory subsystem 110, including handling communications between the memory subsystem 110 and the host system 105.

[0037] In some examples, local memory 125 may include memory registers for storing memory pointers, retrieved data, etc. Local memory 125 may also include ROM for storing microcode. Figure 1 The example memory subsystem 110 is illustrated as including a memory subsystem controller 115, but in another example of the present disclosure, the memory subsystem 110 does not include a memory subsystem controller 115, but may rely on external control (e.g., provided by an external host, or by a processor or controller separate from the memory subsystem).

[0038] In general, the memory subsystem controller 115 may receive commands or operations from the host system 105, and may 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 subsystem controller 115 may be responsible for other operations such as wear leveling operations, garbage collection operations, error detection and correction code (ECC) operations, encryption operations, cache operations, and address conversion between logical addresses (e.g., logical block addresses (LBA), namespaces) and physical addresses (e.g., physical block addresses) associated with the memory device 130. The memory subsystem controller 115 may further include a host interface circuit system for communicating with the host system 105 via a physical host interface. The host interface circuit system may convert commands received from the host system into command instructions for accessing the memory device 130 and / or the memory device 140, and convert responses associated with the memory device 130 and / or the memory device 140 into information for the host system 105.

[0039] The memory subsystem 110 may also include additional circuitry or components not shown. In some examples, the memory subsystem 110 may include a cache or buffer (e.g., DRAM) and address circuitry (e.g., row decoders and column decoders) that may receive an address from the memory subsystem controller 115 and decode the address to access the memory device 130.

[0040] In some examples, memory device 130 includes a local media controller 135 that operates in conjunction with memory subsystem controller 115 to perform operations on one or more memory cells of memory device 130. An external controller (e.g., memory subsystem controller 115) can externally manage memory device 130 (e.g., perform media management operations on memory device 130). In some embodiments, memory device 130 is a managed memory device, which is a bare memory device that is 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.

[0041] The memory subsystem 110 includes a hell manager 150 that can assign data blocks to more than one hell pool (e.g., hell state). If a data block becomes invalid through an operation performed by a host system or due to a garbage collection program, the data block can be assigned to a hell pool. For example, one hell pool can be for data blocks that are subject to a garbage collection program to ensure that all garbage collection read operations on the data block are completed (e.g., commands are read to a memory address associated with the data block). In other instances, another hell pool can be for data blocks to ensure that host read operations on the data block are completed (e.g., commands are read from the host system to a memory address associated with the data block). Data blocks in a hell pool that are waiting for garbage collection reads to complete can be assigned to the hell pool later to ensure that there are no outstanding host reads before being indicated as ready for erasure.

[0042] In some cases, the valid data count of a data block may be zero due to a garbage collection routine, host system activity, or both. In such cases, the hell manager 150 may assign the data block to a first state (e.g., a first hell pool). Once assigned to the first hell pool, the data block may be checked to determine if any garbage collection reads are pending or scheduled to be performed on the data block. After checking that the data block will not be subjected to garbage collection reads, the hell manager 150 may assign the data block to a second state (e.g., a second hell pool). In the second hell pool, the data block is checked by the hell manager 150 to ensure that no host reads are pending or scheduled to be performed. After confirming that no host read commands are pending or scheduled for the data block, the data block is indicated as ready for erasure.

[0043] In some examples, the memory subsystem controller 115 includes at least a portion of the purgatory manager 150. For example, the memory subsystem controller 115 may include a processor 120 (e.g., a processing device) configured to execute instructions stored in the local memory 125 to perform the operations described herein. In some examples, the purgatory manager 150 is part of the host system 105, an application, or an operating system.

[0044] The purgatory manager 150 can recognize that the read command has completed (e.g., by receiving a message from the backend manager that the data block can be erased because the read command issued to the backend manager has completed). Once the data block is indicated as read and erasable according to the backend manager, the purgatory manager 150 can modify the state of the data block (e.g., by assigning the data block to a purgatory pool). In such cases, when the purgatory manager 150 receives the read response, the purgatory manager 150 can update the purgatory pool for the data block. More details about the operation of the purgatory manager 150 are described below.

[0045] Figure 2 is a method diagram of an example method 200 for a multi-state purgatory for garbage collection according to some examples of the present disclosure. The method 200 may be performed by processing logic, which may include hardware (e.g., a processing device, a circuit system, a dedicated logic, a programmable logic, a microcode, a device hardware, an integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some examples, the method 200 is performed by Figure 1 The purgatory manager 150 of the embodiment of the present invention is executed. Although shown in a specific order or sequence, the order of the processes can be modified unless otherwise stated. Therefore, the illustrated examples should be understood as examples only, and the illustrated processes can be performed in a different order, and some processes can be performed in parallel. In addition, one or more processes can be omitted in each example. Therefore, not all processes are required for each example. Other process flows are also possible.

[0046] In operation 205, the processing device may determine a valid data count of a data block of the memory subsystem, wherein the valid data count indicates that the data block contains invalid data. In some instances, the valid data count may indicate that the data block contains invalid data as a whole. In some instances, the valid data count may indicate that the data block contains an amount of invalid data that exceeds a threshold amount. In some instances, the method 200 may include: determining that the amount of valid data of the data block of the memory component group falls below a threshold. In some instances, the data block may contain no valid data.

[0047] In operation 210, the processing device may allocate the data block to a first hell state based at least in part on the valid data count. In some examples, the method 200 may include: allocating the data block to the first hell pool based at least in part on determining that the amount of valid data of the data block of the memory component group falls below a threshold. For example, the threshold may be that the amount of valid data of the data block is less than the amount of invalid data of the data block. The threshold may be determined based on the enablement of a garbage collector, which enables the threshold to be defined differently if the garbage collector is enabled than when garbage collection is disabled or not performed. In other examples, the threshold may be set based on the number of read operations to the data block.

[0048] In operation 215, the processing device may verify that one or more read operations on the data block in the first hell state have been completed based at least in part on the first hell state. In some examples, verifying that the one or more read operations on the data block in the first hell state have been completed may include: verifying that all read operations on the data block by the garbage collector have been completed. In some examples, verifying that the one or more read operations on the data block in the first hell state have been completed may include: verifying that all host read operations on the data block from the host system have been completed.

[0049] In operation 220, the processing device may assign the data block to the second hell state based at least in part on the verification. In some instances, the method 200 may include: after assigning the data block to the second hell state, verifying that all host read operations to the data block in the second hell state have been completed. In some instances, the method 200 may include: after verifying that all read operations to the data block by the garbage collector have been completed and all host read operations to the data block in the second hell state have been completed, erasing the data block. In some instances, the method 200 may include: before erasing the data block, refreshing a host cursor associated with the data block and a garbage collection cursor associated with the data block.

[0050] In some instances, method 200 may include: allocating a data block to a second hell pool based at least in part on completing one or more read operations to the data block in the first hell pool. In some instances, the one or more read operations may be associated with a garbage collector for the data block. In some instances, method 200 may include: determining that all host read operations from a host system to the data block in the second hell pool have been completed. In some instances, method 200 may include: allocating the data block to an erase pool after determining that all host read operations from a host system to the data block in the second hell pool have been completed. In some instances, method 200 may include: erasing the data block after allocating the data block to the erase pool.

[0051] Figure 3 3 is a block diagram of an example system in which a multi-state purgatory for garbage collection may operate. The block diagram 300 may include a memory subsystem 305. The memory subsystem 305 may include a data block manager 310, a purgatory manager 315, an erase manager 330, a garbage collection read manager 335, and a write manager 360. The block diagram 300 also includes a host system 325 and a backend manager 355.

[0052] In some instances, the data block manager 310 can identify data blocks that have not been subjected to a garbage collection procedure. In some cases, invalid data may exist in the data block. For example, the invalid data may exceed a threshold amount of invalid data, or the data block as a whole may contain invalid data. In such cases, the purgatory manager 315 can communicate with the data block manager 310 to modify the data block, which can modify the data block or assign a state to the data block. The purgatory manager 315 can assign the data block to one of the purgatory pool 320-a and the purgatory pool 320-b, although in some cases, the purgatory manager 315 may include more than two purgatory pools.

[0053] If the data block manager 310 identifies that the data block is not undergoing garbage collection and that invalid data exists in the data block, the data block may stop being allocated to the purgatory pool 320-a and may instead be allocated to the purgatory pool 320-b. In such a case, the data block may be allocated to the purgatory pool 320-b included in the purgatory manager 315. Once the data block is allocated to the purgatory pool 320-b, the data block is checked to ensure that the data block does not have a pending or scheduled read command from the host system 325.

[0054] The purgatory manager 315 may communicate with the host system 325. In order to confirm that the data block cannot receive the read command, the purgatory manager 315 may check the read command of the data block to the host system 325. If there is no read command from the host system 325, the purgatory manager 315 may release the data block from the purgatory pool 320-b and instruct the erase manager 330 to erase the data block. In such a case, the purgatory manager 315 may communicate with the erase manager 330.

[0055] According to some aspects, the data block manager 310 may select one or more data blocks for a garbage collection procedure. The data block manager 310 may send an indication of the selected one or more data blocks to the garbage collection read manager 335. The data block manager 310 may communicate with the garbage collection read manager 335. The garbage collection read manager 335 may include a phase 1 read process 340, a phase 2 read process 345, and a phase 3 read process 350. The phase 1 read process 340 may check the scoreboard of the garbage collection read manager 335 to ensure that there is an empty entry. The phase 2 read process 345 may check the scoreboard of the garbage collection read manager 335 for the next entry marked as valid. The phase 3 read process 350 may check the scoreboard of the garbage collection read manager 335 for the next entry marked as valid.

[0056] In some examples, the garbage collection read manager 335 may receive a read response from the backend manager 355, which is a response to a read command issued by the garbage collection read manager 335. In such cases, the garbage collection read manager 335 may process the read command and store the value to be read. The garbage collection read manager 335 may communicate with the write manager 360. The write manager 360 may write the value to a target location (e.g., a memory cell within the memory subsystem 305).

[0057] When a data block undergoes a garbage collection procedure, the data block manager 310 can identify that the data block contains invalid data. For example, when the data block is read in its entirety, the data block can contain invalid data. In such cases, the backend manager 355 can send a message indicating that the entire data block has been read and the invalid data can be erased. In some examples, the backend manager 355 can communicate with the data block manager 310 to communicate that invalid data exists on the data block.

[0058] After a data block is selected for garbage collection, or when a data block undergoing garbage collection contains invalid data (e.g., a threshold amount of invalid data), the data block can be assigned to the purgatory pool 320-a while the data block is undergoing garbage collection. After the backend manager 355 sends the value read from the data block to the garbage collection read manager 335 and the garbage collection read operation stops, the data block can be assigned to the purgatory pool 320-b. In such a case, the data block manager 310 can identify that the data block contains invalid data and can send the data block to the purgatory pool 320-b. The purgatory manager 315 can then check the host system 325 for read commands on the data block to confirm that there are no pending read commands for the data block. If there are no pending or scheduled read commands by the host system 325, the purgatory manager 315 can instruct the erase manager 330 to erase the data block.

[0059] In some cases, the host cursor and garbage collection cursor may be refreshed before the erase manager 330 erases the data block. In such cases, the cursors for read operations or erase operations after the initial data block is erased may be refreshed. If there is invalid data on the data block and there are no outstanding valid reads for the data block, the refresh of the host cursor and garbage collection cursor may be omitted.

[0060] Figure 4 400 is a block diagram of an example computer system in which examples of the present disclosure may operate. Computer system 400 may include an instruction set for causing a machine to perform any one or more of the techniques described herein. In some examples, computer system 400 may correspond to a host system (e.g., a computer system such as ... Figure 1 The host system 105 includes, is coupled to, or utilizes a memory subsystem (e.g., referring to Figure 1 The memory subsystem 110 described above may be used to perform controller operations (eg, to execute an operating system to perform operations with reference to the memory subsystem 110). Figure 1 In some embodiments, the machine may be connected (e.g., connected to a network) with other machines in a Local Area Network (LAN), an intranet, an extranet, and / or the Internet. The machine may 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.

[0061] The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile phone, a network appliance, a server, a network router, a switch or a bridge, or any machine capable of (in sequence or otherwise) executing a set of instructions that specify actions to be taken by the machine. Further, while one machine is illustrated, the term "machine" may also include a collection of any machines that individually or jointly execute one (or more) sets of instructions to implement any one or more of the methodologies discussed herein.

[0062] The example computer system 400 may include a processing device 405, a main memory 410 (e.g., ROM, flash memory, DRAM such as SDRAM or random access memory bus DRAM (RDRAM), etc.), a static memory 415 (e.g., flash memory, static RAM (SRAM), etc.), and a data storage system 425, all of which communicate with each other via a bus 445.

[0063] Processing device 405 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, etc. More specifically, the processing device can be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor that implements other instruction sets or a processor that implements a combination of instruction sets. Processing device 405 can also be one or more special-purpose processing devices, such as ASIC, FPGA, DSP, network processor, etc. Processing device 405 is configured to execute instructions 435 for performing the operations and steps discussed herein. Computer system 400 can further include a network interface device 420 to communicate via a network 440.

[0064] The data storage system 425 may include a machine-readable storage medium 430 (also referred to as a computer-readable medium) having stored thereon one or more sets of instructions 435 or software implementing any one or more of the methods or functions described herein. During execution of the instructions 435 by the computer system 400, the instructions may also reside, in whole or in part, within the main memory 410 and / or within the processing device 405, which also constitute machine-readable storage media. The machine-readable storage medium 430, the data storage system 425, and / or the main memory 410 may correspond to a memory subsystem.

[0065] In one example, instructions 435 include instructions for implementing communication with a purgatory manager 450 (e.g., referring to Figure 1The machine-readable storage medium 430 is shown as a single medium, but the term "machine-readable storage medium" may include a single medium or multiple media storing one or more sets of instructions. The term "machine-readable storage medium" may also include any medium capable of storing or encoding a set of instructions for execution by a machine and causing the machine to perform any one or more methods of the present disclosure. The term "machine-readable storage medium" may include, but is not limited to, solid-state memory, optical media, and magnetic media.

[0066] Some portions of the foregoing detailed description 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 means used by those skilled in the art of data processing to most effectively convey the essence of their work to others skilled in the art. An algorithm is here and generally considered to be a self-consistent sequence of operations for obtaining a desired result. The operations are those requiring physical manipulation of physical quantities. Although not necessary, these quantities typically take the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. Mainly due to common usage, it has proven convenient from time to time to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0067] It should be kept in mind, however, that all of these and similar terms should be associated with the corresponding physical quantities and are merely convenient labels applied to these quantities. The present disclosure may involve the actions and processes of computer systems or similar electronic computing devices that manipulate and transform data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other such information storage systems.

[0068] The present disclosure also relates to an apparatus for performing the operations described herein. The apparatus may be specially constructed for the intended purpose, or may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may 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 magneto-optical disks), ROM, RAM, EPROM, EEPROM, magnetic or optical cards, or any type of medium suitable for storing electronic instructions, each of which is coupled to a computer system bus.

[0069] The algorithm and display proposed herein are not inherently related to any particular computer or other device. Various general purpose systems can be used together with the program according to the teachings of this article, or it can prove convenient to construct more specialized equipment to perform the method. The structure of various these systems will be presented as described in the following description. In addition, the present disclosure is not described with reference to any specific programming language. It will be understood that various programming languages ​​can be used to implement the enlightenment of the present disclosure as described herein.

[0070] The present disclosure may be provided as a computer program product or software that may include a machine-readable medium having instructions stored thereon, which instructions may be used to program a computer system (or other electronic device) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a machine (e.g., computer) readable form. In some instances, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., computer) readable storage medium, such as ROM, RAM, disk storage media, optical storage media, flash memory components, etc.

[0071] In the foregoing description, examples of the present disclosure have been described with reference to specific exemplary examples of the present disclosure. Obviously, various modifications may be made to these examples without departing from the broader spirit and scope of the examples of the present disclosure as set forth in the appended claims. Therefore, the description and drawings should be regarded as illustrative rather than restrictive.

Claims

1. A system comprising: multiple memory components; as well as One or more processing devices coupled to the plurality of memory components and configured to cause the system to implement the following operations: allocating the data block to a first temporary holding pool based at least in part on an amount of valid data of the data block of the plurality of memory components being below a threshold; as well as The data block is erased based at least in part on allocating the data block to a second temporary holding pool and verifying that one or more read operations to the data block in the first temporary holding pool have completed.

2. The system of claim 1, wherein the one or more read operations are associated with a garbage collection procedure for the data block.

3. The system of claim 1, wherein the one or more processing devices are further configured to cause the system to: It is determined that all host read operations from a host system to the data blocks in the second temporary holding pool have completed.

4. The system of claim 3, wherein the one or more processing devices are further configured to cause the system to: After determining that all of the host read operations from the host system to the data block in the second temporary saving pool have completed, assigning the data block to an erase pool; and After allocating the data block to the erase pool, the data block is erased.

5. The system of claim 4, wherein the one or more processing devices are further configured to cause the system to: Prior to erasing the data block, a host cursor associated with the data block and a garbage collection cursor associated with the data block are flushed. The system of claim 1 , wherein the data block does not contain valid data.

7. A method comprising: allocating the data block to a first temporary holding pool based at least in part on a valid data count of the data block, the valid data count indicating that the data block contains invalid data; verifying, based at least in part on the first temporary saving pool, that one or more read operations on the data blocks in the first temporary saving pool have completed; as well as The data block is erased based at least in part on allocating the data block to a second temporary holding pool and verifying that the one or more read operations have completed.

8. The method of claim 7, wherein verifying that the one or more read operations on the data blocks in the first temporary holding pool have completed comprises: Verify that all read operations by the garbage collector on the data block have completed.

9. The method according to claim 8, further comprising: After allocating the data block to the second temporary saving pool, verifying that all host read operations on the data block in the second temporary saving pool have been completed.

10. The method according to claim 9, further comprising: after verifying that all read operations of the garbage collector on the data block have been completed and all host read operations on the data block in the second temporary holding pool have been completed, erasing the data block; as well as Prior to erasing the data block, a host cursor associated with the data block and a garbage collection cursor associated with the data block are flushed.

11. The method of claim 7, wherein verifying that the one or more read operations on the data blocks in the first temporary holding pool have completed comprises: Verify that all host read operations from the host system for the data block have completed.

12. The method of claim 7, wherein the valid data count indicates that the data block as a whole contains invalid data.

13. The method of claim 7, wherein the valid data count indicates that the data block contains an amount of invalid data exceeding a threshold amount.

14. A non-transitory computer-readable storage medium comprising instructions, which when executed by one or more processing devices, cause the one or more processing devices to perform the following operations: allocating the data block to a first temporary holding pool based at least in part on a valid data count of the data block, the valid data count indicating that the data block contains invalid data; verifying, based at least in part on the first temporary saving pool, that one or more read operations on the data blocks in the first temporary saving pool have completed; as well as The data block is erased based at least in part on allocating the data block to a second temporary holding pool and verifying that the one or more read operations have completed.

15. The non-transitory computer-readable storage medium of claim 14, wherein the instructions, when executed by the one or more processing devices, further cause the one or more processing devices to implement the following operations: Verify that all host read operations from the host system for the data block have completed.

16. The non-transitory computer-readable storage medium of claim 14, wherein the instructions, when executed by the one or more processing devices, further cause the one or more processing devices to implement the following operations: Verify that all read operations by the garbage collector on the data block have completed.

17. The non-transitory computer-readable storage medium of claim 16, wherein the instructions, when executed by the one or more processing devices, further cause the one or more processing devices to implement the following operations: After allocating the data block to the second temporary saving pool, verifying that all host read operations on the data block in the second temporary saving pool have been completed; and After verifying that all read operations of the data block by the garbage collector have completed and all the host read operations of the data block in the second temporary holding pool have completed, the data block is erased.

18. The non-transitory computer-readable storage medium of claim 17, wherein the instructions, when executed by the one or more processing devices, further cause the one or more processing devices to implement the following operations: Prior to erasing the data block, a host cursor associated with the data block and a garbage collection cursor associated with the data block are flushed.

19. The non-transitory computer-readable storage medium of claim 14, wherein the valid data count indicates that the data block in its entirety contains invalid data.

20. The non-transitory computer-readable storage medium of claim 14, wherein the valid data count indicates that the data block contains an amount of invalid data exceeding a threshold amount.

Images