Namespace-level efficient conversion unit count

Abstract

A system component, such as a memory subsystem controller, is provided to track the number of translation units stored for each of a plurality of namespaces on an individual namespace basis. To format a given one of the plurality of namespaces, a number of individual tracked conversion units may be deducted from a global number tracked for each respective block of the memory subsystem.

Description

Technical Field

[0001] Embodiments of the present disclosure relate generally to memory subsystems, and more particularly, to tracking valid translation unit counts (VTCs) at a namespace level in a memory subsystem. Background Art

[0002] The memory subsystem may be a memory system such as a solid state drive (SSD) and may include one or more memory components that store data. The memory components may be, for example, non-volatile memory components and volatile memory components. In general, the host system may utilize the memory subsystem to store data at the memory components and retrieve data from the memory components. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The present disclosure will be more fully understood from the detailed description given below and from the accompanying drawings of various embodiments of the present disclosure.

[0004] Figure 1 is a block diagram illustrating an example computing environment including a memory subsystem according to some embodiments of the present disclosure.

[0005] Figure 2 is a block diagram of an example namespace-level valid translation unit count (VTC) manager according to some embodiments of the present disclosure.

[0006] Figure 3 and 4 is a flow chart of an example method for performing VTC table management according to some embodiments of the present disclosure.

[0007] Figure 5 A table illustrating an example VTC table according to some embodiments of the present disclosure is presented.

[0008] Figure 6 An interaction diagram is provided that illustrates interactions between components of a computing environment in the context of some embodiments of methods of VTC table management are performed.

[0009] Figure 7 is a block diagram illustrating a diagram of a machine in the form of a computer system within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0010] Aspects of the present disclosure configure system components (e.g., a memory subsystem controller) to track VTCs at the namespace level in a memory subsystem, which can be performed by managing a VTC table at the namespace level. A VTC table can be generated to store conversion unit counts at the block level and the namespace level. That is, the block-level count represents the total number of conversion units (TUs) occupied on an individual block or allocated to multiple namespaces on an individual block. The namespace-level count represents the total number of TUs occupied on an individual block or allocated to an individual namespace on an individual block. This enables the VTC table to be quickly updated when a given namespace is formatted or deleted, which improves the overall efficiency of operating the memory subsystem.

[0011] The memory subsystem may be a memory device, a memory module, or a combination of a memory device and a memory module. Figure 1 Examples of storage devices and memory modules are described. In general, a host system may utilize a memory subsystem that includes one or more memory components, such as a memory device that stores data. The host system may send access requests (e.g., write commands, read commands) to the memory subsystem, such as to store data at the memory subsystem and read data from the memory subsystem. Data specified by the host is hereinafter referred to as "host data" or "user data". Data may be stored in the memory subsystem according to a namespace.

[0012] Specifically, the physical memory elements of the storage device may be arranged as logical memory blocks that are addressed via logical block addressing (LBA). A logical memory block is the smallest LBA addressable memory unit, and each LBA address identifies a single logical memory block that can be mapped to a specific physical address of a memory unit in the storage device. A conversion unit (TU) represents the smallest unit transferred from the LBA of the storage drive to a flash storage address. This conversion is typically stored in a TU mapping table (L2P table).

[0013] The concept of a namespace for a storage device is similar to the concept of partitions used to create logical storage in a hard drive. Different portions of a storage device may be assigned to different namespaces and may therefore have independently configured LBA addresses within their respective namespaces. Each namespace identifies a certain amount of memory of the storage device that is addressable via the LBA. The same LBA address may be used in different namespaces to identify different memory units in different portions of the storage device. For example, a first namespace allocated on a first portion of a storage device having n memory units may have an LBA address ranging from 0 to n-1; and a second namespace allocated on a second portion of a storage device having m memory units may have an LBA address ranging from 0 to m-1.

[0014] The host request may include logical address information (e.g., logical block address (LBA), namespace) of the host data, which is the location that the host system associates with the host data and the specific namespace in which the host data is stored or accessed. The logical address information (e.g., LBA, namespace) may be part of the metadata of the host data. The metadata may also include error handling data (e.g., ECC codeword, parity code), data version (e.g., used to distinguish the age of written data), valid bitmap (which LBAs or logical transfer units contain valid data), etc. The host computer of the storage device may send a request to create, delete, or reserve a namespace to the storage device. After a portion of the storage capacity of the storage device is allocated to the namespace, the LBA address in the corresponding namespace logically represents a specific memory unit in the storage medium, but the specific memory unit logically represented by the LBA address in the namespace may physically correspond to different memory units at different times (e.g., as in an SSD).

[0015] The memory subsystem may initiate media management operations, such as write operations, on host data stored on the memory device. For example, as part of a junk collection management operation, the firmware of the memory subsystem may rewrite previously written host data from a location on the memory device (e.g., a portion of a namespace) to a new location. The data of the portion of the namespace that is rewritten (e.g., as initiated by the firmware) is hereinafter referred to as "junk collection data." "User data" may include host data and junk collection data. "System data" hereinafter refers to data created and / or maintained by the memory subsystem for performing operations in response to host requests and for media management. Examples of system data include, but are not limited to, system tables (e.g., logical to physical address mapping tables), data from log records, temporary data, and the like.

[0016] The memory device may be a non-volatile memory device. A non-volatile memory device is a package of one or more dies. 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. For some memory devices, a block is the smallest area that can be erased. Each block is composed of a set of pages. Each page is composed of a set of memory cells that store data bits. The memory device may be a raw memory device (e.g., NAND), which is managed externally by an external controller, for example. The memory device may be a managed memory device (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. The memory device may be divided into one or more regions, each of which is associated with a different set of host data or user data or applications.

[0017] There are challenges in efficiently implementing the mapping of LBA addresses defined in multiple namespaces to physical memory elements in a storage device and efficiently using the storage capacity of the storage device, especially when it is desired to dynamically allocate, delete, and further allocate namespaces of different and varying sizes on the storage device. In order to track namespace consumption on physical memory elements, a VTC table is typically maintained. The VTC table identifies the number of TUs allocated across one or more namespaces for each block. In this way, when the firmware needs to perform a discarded item collection operation, the firmware can use the VTC table to select which memory blocks to rewrite (e.g., select the memory block with the least or most number of TUs allocated to the namespace).

[0018] In some instances, in order to format or delete a given namespace from a storage device, for example, during the process of performing a collection of discarded items or when a request is received from a host to delete an individual namespace, a conventional memory subsystem may need to perform operations that consume a large amount of resources and time, which causes the formatting time to increase as the drive capacity increases. That is, in order to delete or format an individual namespace, the firmware first obtains the physical addresses corresponding to the LBA range of the individual namespace from the L2P table one by one. For each physical address, a physical block in which data associated with the individual namespace is stored is determined. The TUs containing the data are counted and decremented from the VTC table so that the VTC table is updated to reflect the deletion of the namespace from the physical block. The time consumed to perform these operations depends on the size of the individual namespace. After updating the VTC table, the L2P table is also updated by writing an invalid physical address to the LBA of the individual namespace stored in the L2P table. This further consumes a certain amount of time. Taken together, the time spent performing operations to update the VTC table and deallocate the namespace from the L2P table is unacceptable. This results in a lack of efficient resource allocation and use in managing multiple namespaces on the memory subsystem.

[0019] Aspects of the present disclosure address the above and other disadvantages by configuring a system component (e.g., a memory subsystem controller of a memory subsystem) to generate separate namespace-level VTC entries or counts in addition to block-level VTC entries or counts. This reduces at least some of the time spent by conventional systems updating the VTC table to accurately track the number of TUs allocated to namespaces on individual blocks of memory. As a result, the time spent performing namespace formatting or deletion is significantly reduced and becomes independent of the size of the corresponding namespace being formatted or deleted.

[0020] Specifically, the memory subsystem controller of some embodiments described herein may generate multiple namespaces on a memory subsystem in which a set of memory components includes a block. The block may store data of a set of namespaces in the multiple namespaces in one or more conversion units. The memory subsystem controller may maintain a table describing the number of valid conversion unit counts stored on the memory subsystem, such that a first count of valid conversion units on the block may be maintained by the table together with a second count of valid conversion units of individual namespaces in the set of namespaces stored in the one or more conversion units of the block. In some embodiments, the table stores multiple namespace counts of the set of namespaces (in the multiple namespaces), and the namespace counts in the multiple namespace counts describe the number of valid conversion units of the corresponding namespaces in the set of namespaces.

[0021] For some embodiments, a memory subsystem (e.g., a memory subsystem controller) may perform a trash collection operation on an individual block. Specifically, the memory subsystem may search a plurality of valid conversion unit counts stored in a table across a plurality of blocks of the set of memory components to determine an identified count that satisfies a criterion (e.g., a count that is greater than all other counts or that is below or above a threshold). The memory subsystem may select an individual block of the plurality of blocks that is associated with the identified count and may perform a trash collection operation on the individual block in response to selecting the individual block.

[0022] For some embodiments, a memory subsystem (e.g., a memory subsystem controller) may receive a request to generate a new namespace on the memory subsystem. In response, the memory subsystem (e.g., a memory subsystem controller) may selectively add a namespace-level VTC entry for the new namespace based on the number and / or size of the namespace-level entries currently stored in the table. In some instances, the table is stored in a static random access memory (SRAM) device of the memory subsystem. That is, the memory subsystem (e.g., a memory subsystem controller) may determine the number of namespaces currently described by the table (e.g., a VTC table) and compare the number with a threshold. The threshold may represent the total number of namespaces that the VTC table can represent. In response to determining that the number is less than a threshold (e.g., the number of namespaces currently represented by the namespace-level VTC entries in the VTC table is less than a threshold, such as 10), the memory subsystem (e.g., a memory subsystem controller) may update the table by adding a new count (e.g., a new entry) describing the number of valid TUs that the new namespace has in the corresponding block to the table for each block in the memory subsystem. In some examples, when a new namespace is created, the VTC table stores a value of zero in each block of the namespace. After the namespace is created, the VTC may be incremented in response to a write operation. That is, a memory subsystem (e.g., a memory subsystem controller) may increment the total TUs described by a first count of the number of TUs occupied in the corresponding block or allocated to all namespaces stored in the corresponding block in response to a write operation to the namespace based on the number of TUs associated with the new namespace in the corresponding block.

[0023] In some instances, the creation of a namespace includes two phases. The first phase includes generating a VTC for the namespace, which describes the amount of data written in each block of the namespace. This VTC may initially be set to zero and incremented as blocks are written with data in the namespace. The second phase includes storing a total TU count for the namespace, which describes the actual size of the namespace, regardless of whether data is stored in the namespace. The total TU count may initially be set to a value indicating how many blocks of data the namespace can store.

[0024] In some embodiments, the memory subsystem (e.g., a memory subsystem controller) may determine that the number is greater than a threshold value. In response, the memory subsystem (e.g., a memory subsystem controller) may select one of the namespace-level VTC entries based on the size of the namespace represented by the namespace-level VTC entry to delete it from the VTC table. Specifically, the memory subsystem (e.g., a memory subsystem controller) may selectively add an entry for the new namespace to the VTC table based on whether the new namespace is associated with a size larger than the size of the smallest namespace entry stored in the VTC table. To this end, the memory subsystem (e.g., a memory subsystem controller) may compare the size of the new namespace (e.g., the number of TUs associated with the new namespace) with the total TU count value (indicating the actual allocated size or number of blocks) described by the namespace-level entry for each of the namespaces described by the VTC table. In response to determining that the size of the new namespace is less than the size of each of the multiple namespaces (e.g., the total TU count value), the memory subsystem (e.g., the memory subsystem controller) may increment the first count by the number of valid translation units that the new namespace has in the block, and may avoid or not add a new namespace-level entry for the new namespace in the VTC table. In some embodiments, in response to determining that the size of the new namespace is greater than the size of a selected one of the multiple namespaces (e.g., the selected count value), the memory subsystem (e.g., the memory subsystem controller) may replace the count value of the selected one of the multiple namespaces with the new count value of the valid translation units of the new namespace. The memory subsystem (e.g., the memory subsystem controller) may store tracking metadata describing the namespaces, and the individual counts of valid TUs of the namespaces are stored in the VTC table (e.g., the tracking metadata indicates which namespaces have namespace-level entries stored in the VTC table).

[0025] In some embodiments, in order to delete or format a namespace from a memory subsystem, a memory subsystem (e.g., a memory subsystem controller) may receive a request to format an individual namespace. In response to the request, the memory subsystem (e.g., a memory subsystem controller) may search the VTC tracking metadata of the VTC table to determine whether the individual namespace is associated with an individual namespace-level entry in the VTC table describing the number of TUs allocated by the individual namespace in each of a set of blocks of the memory subsystem. The memory subsystem (e.g., a memory subsystem controller) may obtain a second count associated with the individual namespace in response to determining that the VTC table stores individual namespace-level entries for individual namespaces. The memory subsystem (e.g., a memory subsystem controller) may then deduct the second count from the first count (e.g., deducting the total number of TUs allocated to individual namespaces on individual memories as described by individual namespace-level entries from the count of the number of valid TUs allocated to multiple namespaces on individual memory blocks). This significantly speeds up updating the VTC table and reduces the amount of time it takes to update the VTC table to accurately reflect the total number of TUs allocated to individual namespaces on each block of the memory subsystem. This is because the VTC table is updated in a single operation by obtaining the number of TUs allocated to individual namespaces from a separately maintained VTC table entry from a global entry representing the total number of TUs allocated for blocks across multiple namespaces, rather than accessing the L2P table and updating the VTC table for the LBA addresses stored in the L2P table of the individual namespace (which consumes multiple operations proportional to the size of the individual namespace).

[0026] Although various embodiments are described herein as being implemented with respect to a memory subsystem (eg, a controller of a memory subsystem), some or all portions of the embodiments may be implemented with respect to a host system (eg, a software application or operating system of the host system).

[0027] Figure 1An example computing environment 100 including a memory subsystem 110 according to some examples of the present disclosure is illustrated. The memory subsystem 110 may include media, such as memory components 112A-112N (hereinafter also referred to as "memory devices"). The memory components 112A-112N may be volatile memory devices, non-volatile memory devices, or a combination thereof. In some embodiments, the memory subsystem 110 is a storage system. The memory subsystem 110 may be a storage device, a memory module, or a hybrid 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 controller (eMMC) drives, universal flash storage (UFS) drives, and hard disk drives (HDDs). Examples of memory modules include dual in-line memory modules (DIMMs), small outline DIMMs (SO-DIMMs), and non-volatile dual in-line memory modules (NVDIMMs).

[0028] The computing environment 100 may include a host system 120 coupled to a memory system. The memory system may include one or more memory subsystems 110. In some embodiments, the host system 120 is coupled to memory subsystems 110 of different types. Figure 1 An example of a host system 120 coupled to one memory subsystem 110 is illustrated. The host system 120 uses the memory subsystem 110, for example, to write data to the memory subsystem 110 and read data from the memory subsystem 110. As used herein, "coupled to" generally refers to a connection between components, which can be an indirect communication connection or a direct communication connection (e.g., without intervening components), whether wired or wireless, including connections such as electrical connections, optical connections, magnetic connections, and the like.

[0029] The host system 120 may be a computing device such as a desktop computer, a laptop computer, a network server, a mobile device, an embedded computer (e.g., a computer included in a vehicle, industrial equipment, or a networked commercial device), or such computing devices that include a memory and a processing device. The host system 120 may include or be coupled to the memory subsystem 110 so that the host system 120 can read data from the memory subsystem 110 or write data to the memory subsystem 110. The host system 120 may be coupled to the memory subsystem 110 via 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 interface, a Serial Attached SCSI (SAS) interface, and the like. The physical host interface may be used to transfer data between the host system 120 and the memory subsystem 110. When the memory subsystem 110 is coupled to the host system 120 through a PCIe interface, the host system 120 may further utilize an NVM Express (NVMe) interface to access the memory components 112A to 112N. 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 120 .

[0030] Memory components 112A-112N may include any combination of different types of non-volatile memory components and / or volatile memory components. Examples of non-volatile memory components include NAND-type flash memory. Each of memory components 112A-112N may include one or more arrays of memory cells, such as single-level cells (SLC) or multi-level cells (MLC) (e.g., TLC or QLC). In some embodiments, a particular memory component 112 may include both an SLC portion and an MLC portion of memory cells. Each of the memory cells may store one or more data bits (e.g., blocks) used by a host system 120. Although non-volatile memory components such as NAND-type flash memory are described, memory components 112A-112N may be based on any other type of memory, such as volatile memory. In some embodiments, memory components 112A to 112N may 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), or non-NOR flash memory, electrically erasable programmable read-only memory (EEPROM), and a cross-point array of non-volatile memory cells. The cross-point array of non-volatile memory cells may be combined with a stackable cross-grid data access array to perform bit storage based on changes in bulk resistance. In addition, in contrast to many flash-based memories, cross-point non-volatile memories may perform write-in-place operations, where non-volatile memory cells may be programmed without first erasing the non-volatile memory cells. Furthermore, the memory cells of memory components 112A to 112N may be grouped into memory pages or blocks, which may refer to a unit of memory component 112 used to store data. In some examples, the memory cells of memory components 112A to 112N may be grouped into a set of different regions of equal or unequal size used to store data for corresponding applications. In such cases, each application may store data in an associated region in the set of different regions.

[0031] The memory subsystem controller 115 may communicate with the memory components 112A to 112N to perform operations such as reading data, writing data, or erasing data and other such operations at the memory components 112A to 112N. The memory subsystem controller 115 may include hardware, such as one or more integrated circuits and / or discrete components, buffer memory, or a combination thereof. The memory subsystem controller 115 may be a microcontroller, a dedicated logic circuit system (e.g., a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), or another suitable processor. The memory subsystem controller 115 may include a processor (processing device) 117 configured to execute instructions stored in a local memory 119. In the illustrated example, the local memory 119 of the memory subsystem controller 115 includes an embedded memory configured to store instructions for executing 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 120. In some embodiments, the local memory 119 may include memory registers that store memory pointers, fetched data, and the like. Local memory 119 may also include read-only memory (ROM) for storing microcode. Figure 1 The example memory subsystem 110 in FIG. 1 has been described as including a memory subsystem controller 115, but in another embodiment of the present disclosure, the memory subsystem 110 may not include the memory subsystem controller 115, but may rely on external control (for example, provided by an external host, or provided by a processor 117 or controller separate from the memory subsystem 110).

[0032] In general, the memory subsystem controller 115 may receive commands or operations from the host system 120 and may convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory components 112A to 112N. The memory subsystem controller 115 may be responsible for other operations such as wear leveling operations, garbage collection operations, error detection and error correction coding (ECC) operations, encryption operations, cache operations, address translation between logical block addresses and physical block addresses associated with the memory components 112A to 112N, and address translation between application identifiers received from the host system 120 and corresponding regions in a set of regions of the memory components 112A to 112N. This may be used to restrict an application to read data only to and write data only from a corresponding namespace in a set of namespaces associated with the respective application. In such cases, a given application may only read / write data to / from an associated namespace, e.g., by erasing data stored in the namespace and writing new data to the namespace, even though there may be free space elsewhere on the memory components 112A-112N. The memory subsystem controller 115 may further include host interface circuitry to communicate with the host system 120 via a physical host interface. The host interface circuitry may convert commands received from the host system 120 into command instructions to access the memory components 112A-112N, and convert responses associated with the memory components 112A-112N into information for the host system 120.

[0033] The memory subsystem 110 may also include additional circuitry or components not illustrated. In some embodiments, the memory subsystem 110 may include a cache or buffer (e.g., a DRAM or other temporary storage location or device) and address circuitry (e.g., a row decoder and a column decoder) that may receive addresses from the memory subsystem controller 115 and decode the addresses to access the memory components 112A-112N.

[0034] The memory device may be a raw memory device (e.g., NAND) that is externally managed by an external controller (e.g., memory subsystem controller 115). The memory device may be a managed memory device (e.g., managed NAND), which is a raw memory device combined with a local embedded controller (e.g., a local media controller) within the same memory device package for memory management. Any of the memory components 112A-112N may include a media controller (e.g., media controller 113A and media controller 113N) to manage the memory cells of the memory component, communicate with the memory subsystem controller 115, and execute memory requests (e.g., reads or writes) received from the memory subsystem controller 115.

[0035] According to some embodiments described herein, the memory subsystem 110 includes a namespace-level VTC manager 122 that performs or facilitates VTC table management. In some embodiments, the controller 115 includes at least a portion of the namespace-level VTC manager 122. For example, the controller 115 may include a processor 117 (processing device) configured to execute instructions stored in the local memory 119 for performing the operations described herein. In some embodiments, the namespace-level VTC manager 122 is part of the host system 120, such as a software application or operating system on the host system 120.

[0036] The namespace-level VTC manager 122 may store a VTC table that describes the number of valid TUs that each namespace has in each block of the memory components 112A to 112N. For example, the VTC table may store two sets of entries including count values ​​for each block of the memory components 112A to 112N. The first count stored in the first entry on the VTC table may be associated with the first block and may represent the total number of valid TUs stored across one or more namespaces on the first block (global count). A second entry may be stored for each or a subset of one or more namespaces stored on the first block. The second entry may include a first count value representing the number of valid TUs stored for the first of the one or more namespaces on the first block. The second entry may also include a second count value representing the number of valid TUs stored for the second of the one or more namespaces on the first block. The total number of count values ​​stored by the second entry may be predetermined and set by a threshold. In some examples, the VTC table may be configured to store only a maximum of 10 count values ​​in the second entry (eg, the VTC table may be configured to store only individual namespace-level VTC count values ​​for 10 namespaces).

[0037] Similarly, a third count stored in a third entry on the VTC table may be associated with the second block and may represent the total number of valid TUs stored across one or more namespaces on the second block. A fourth entry may be stored for each or a subset of the one or more namespaces stored on the second block. The fourth entry may include a fourth count value representing the number of valid TUs stored for the first of the one or more namespaces on the second block. The fourth entry may also include a fifth count value representing the number of valid TUs stored for the second of the one or more namespaces on the second block.

[0038] In some embodiments, the namespace-level VTC manager 122 manages updates to the VTC table when new namespaces are added and old namespaces are deleted or formatted from the memory components 112A to 112N. For example, to speed up VTC table updates when old namespaces are deleted or removed, the VTC manager 122 uses the namespace-level entries stored for the old namespaces in the VTC table to update the global or block-level counts of the individual blocks of the memory component.

[0039] For example, in some embodiments, the VTC manager 122 may receive a request to delete a first namespace. In response to receiving a request to delete a first namespace, the VTC manager 122 may access the tracking metadata to determine whether the first namespace has a corresponding namespace-level VTC entry stored in the VTC table. If so, the VTC manager 122 accesses the VTC table, such as a second entry containing a first count value, which is represented by the number of valid TUs stored in the first namespace on the first block. The VTC manager 122 then deducts the first count value from the first count in the first entry associated with the first block stored in the VTC table to represent the total number of valid TUs stored across one or more namespaces on the first block (global count). The VTC manager 122 then determines whether the additional block stores a valid TU of the first namespace. The VTC manager 122 similarly accesses the VTC table, such as a fourth entry containing a fourth count value, which is represented by the number of valid TUs stored in the first namespace on the second block. The VTC manager 122 then deducts a fourth count value from a third count stored in a third entry associated with the second block on the VTC table to represent a total number of valid TUs stored across one or more namespaces on the second block (a global count). The VTC manager 122 then performs an operation to deallocate the first namespace from the L2P table, such as by writing an invalid physical address to a logical-to-physical (L2P) mapping table of logical block addresses to physical addresses associated with the first namespace.

[0040] For example, in some embodiments, VTC manager 122 may receive a request to add a new namespace to memory components 112A-112N. In response, VTC manager 122 may selectively add a namespace-level VTC entry for the new namespace based on whether the total number of namespaces that include corresponding entries in the VTC table exceeds a threshold (e.g., 10) and / or based on whether the size of the new namespace is greater than the number or size of allocated TUs of any of the namespaces described by the VTC table.

[0041] Specifically, VTC manager 122 may determine that the total number of namespaces including corresponding entries in the VTC table fails to exceed or exceed a threshold value. In such cases, VTC manager 122 determines the number of TUs stored in the first block of the new namespace and generates a new count value of the namespace-level entry associated with the first block. The new count value includes or describes the number of TUs stored in the first block of the new namespace. The new count value is stored in the VTC table together with other count values, and the other count values ​​are described as the number of TUs stored in other namespaces on the first block. Similarly, VTC manager 122 determines the number of TUs stored in the second block of the new namespace and generates a second new count value of the namespace-level entry associated with the second block. The second new count value includes or describes the number of TUs stored in the second block of the new namespace.

[0042] In some embodiments, the VTC manager 122 may determine that the total number of namespaces including corresponding entries in the VTC table exceeds or exceeds a threshold value (e.g., 10 namespaces are currently represented by individual namespace-level VTC entries in the VTC table). In such cases, the VTC manager 122 may determine the size of the new namespace (e.g., how many TUs are associated with the new namespace). The VTC manager 122 may obtain a count value of the TUs stored for each of the namespaces currently described by the corresponding namespace-level VTC entries in the VTC table. For example, the VTC manager 122 accesses the tracking metadata and accumulates all count values ​​in the namespace-level VTC entries of the first namespace stored on all blocks. This represents the total amount of TUs allocated to the first namespace. The VTC manager 122 may compare the total amount of TUs allocated to the first namespace with the number of TUs associated with the new namespace. In response to determining that the total amount of TUs allocated to the first namespace is greater than the number of TUs associated with the new namespace, the VTC manager 122 may select the second namespace for analysis.

[0043] VTC manager 122 can access tracking metadata and accumulate all count values ​​in the namespace-level VTC entries of the second namespace stored on all blocks. This represents the total amount of TUs allocated for the second namespace. VTC manager 122 can compare the total amount of TUs allocated for the second namespace with the number of TUs associated with the new namespace. In response to determining that the total amount of TUs allocated for the second namespace is greater than the number of TUs associated with the new namespace, VTC manager 122 can select a third namespace for analysis. VTC manager 122 repeats these operations until all namespaces described by the VTC table are analyzed. In response to determining that the total amount of TUs allocated for each of the namespaces is greater than the number of TUs associated with the new namespace, VTC manager 122 can avoid generating new entries specific to the new namespace in the VTC table.

[0044] In some embodiments, VTC manager 122 may determine that the total amount of TUs allocated to the third namespace is less than the number of TUs associated with the new namespace. In such cases, VTC manager 122 may exchange the namespace-level entry for the third namespace in the VTC table with the count value associated with the new namespace. To this end, VTC manager 122 deletes all count values ​​associated with the third namespace from the VTC table and removes the third namespace from the tracking metadata. VTC manager 122 repeats this process for each block in the memory subsystem. VTC manager 122 also adds an identifier of the new namespace to the tracking metadata, which indicates that the VTC table stores count values ​​specific to the new namespace.

[0045] Depending on the embodiment, the namespace level VTC manager 122 may include logic (e.g., a set of transient or non-transient machine instructions, such as firmware) or one or more components that enable the memory subsystem 110 (e.g., the memory subsystem controller 115) to perform the operations described herein with respect to the namespace level VTC manager 122. The namespace level VTC manager 122 may include a tangible or intangible unit capable of performing the operations described herein. Further details regarding the operation of the namespace level VTC manager 122 are described below.

[0046] Figure 2 2 is a block diagram of an example namespace level VTC manager 200 according to some embodiments of the present disclosure. As illustrated, the namespace level VTC manager 200 includes a namespace tracker 220, a namespace VTC table 230, and a namespace format module 240. For some embodiments, the namespace level VTC manager 200 may be configured in a component or arrangement (e.g., fewer or more components) with the same Figure 2 This is different from the namespace-level VTC manager described in .

[0047] The namespace tracker 220 stores tracking metadata that identifies which namespaces are associated with namespace-level entries in the VTC table. Specifically, if a namespace count value representing the total number of valid TUs is stored for an individual namespace in the VTC table (in addition to a global count value representing the valid TUs for each of a set of blocks across the memory subsystem), the tracking metadata specifies an identifier for the individual namespace. When a namespace is added or deleted, the tracking metadata is similarly updated to add or remove the namespace identifier, respectively.

[0048] The namespace VTC table 230 stores multiple entries describing a global count for each block, which indicates the total number of valid TUs (across multiple namespaces stored in the corresponding block). Multiple entries also store individual count values ​​for each namespace of each block separately. For example, a first count describing the total number of valid TUs assigned to or stored in the first block by the first namespace may be stored for the first block, and a second count describing the total number of valid TUs assigned to or stored in the first block by the second namespace may be stored for the first block. In addition to storing the global count for the first block, these first and second counts are also stored.

[0049] The namespace formatting module 240 performs operations for adding and deleting namespaces according to descriptions in the VTC table. Specifically, the namespace formatting module 240 may perform operations including generating a plurality of namespaces on a memory subsystem including a set of memory components including a block that stores data of a set of namespaces in a plurality of namespaces in one or more translation units. The namespace formatting module 240 may communicate with the namespace VTC table 230 and the namespace tracker 220 to maintain a table describing the number of valid translation unit counts stored on the memory subsystem.

[0050] Figure 3 and 4 400 for performing VTC table management according to some embodiments of the present disclosure. Any of the methods 300, 400 may be performed by processing logic, which may include hardware (e.g., a processing device, a circuit system, dedicated logic, programmable logic, microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, the method 300 is performed by Figure 1 15. In these embodiments, method 300 or method 400 may be performed at least in part by namespace-level VTC manager 122. Although the processes are shown in a particular order or sequence, the order of the processes may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood to be merely examples, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. In addition, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are possible.

[0051] Reference Figure 3, the method (or process) 300 begins at operation 305, where a processing device of the memory subsystem (e.g., a processor of the memory subsystem controller 115) generates a plurality of namespaces on a memory component (e.g., memory components 112A to 112N) of the memory subsystem including one or several blocks. Each block stores data of a group of namespaces in the plurality of namespaces in one or more translation units. For some embodiments, the request comes from a host system (e.g., host system 120) communicatively coupled to the memory subsystem.

[0052] At operation 310, a processing device of the memory subsystem maintains a table (eg, a VTC table) describing the number of VTCs stored on memory components (eg, memory components 112A-112N) of the memory subsystem.

[0053] Thereafter, at operation 315, the table provides a first count of valid conversion units for individual blocks of a plurality of blocks of a memory component (eg, memory components 112A-112N) of the memory subsystem.

[0054] At operation 320, the table provides a second count of valid translation units for individual namespaces in the set of namespaces stored in the one or more translation units of the block.

[0055] Reference now Figure 4 , the method (or process) 400 begins at operation 405, where a processing device of a memory subsystem receives a request to create a new namespace.

[0056] At operation 410, the processing device may determine the number of namespaces currently described by the VTC table. Thereafter, at operation 415, the processing device may compare the number to a threshold. At operation 420, the processing device may determine whether the number exceeds the threshold. In response to determining that the number exceeds the threshold, the process proceeds to operation 435. In response to determining that the number does not exceed the threshold, the process proceeds to operation 430. Next, at operation 430, the processing device may, for each block in the memory subsystem, add a new count describing the number of valid translation units associated with the new namespace to the VTC table.

[0057] At operation 435, the processing device may compare the size of the new namespace with the count value of valid conversion units that each of the namespaces has in the corresponding block. Then, at operation 440, the processing device may selectively replace the count value of the selected one of the plurality of namespaces with the new count value of the valid conversion units of the new namespace based on the result of comparing the size of the new namespace with the count value.

[0058] Figure 5Table 500 is presented that illustrates an example of a VTC table according to some embodiments. Figure 5 , table 500 includes an entry for each block in the memory subsystem. Specifically, a first block 510 (e.g., block 0) may include an entry in a global VTC column 520 and one or more individual entries in namespace-level VTC columns 530, 532, and 534. In some examples, the global VTC column 520 includes a count value representing the total number of valid TUs allocated to each of the namespaces stored in the first block 510. The entry in the namespace-level VTC column 530 includes a first count value for the total number of valid TUs allocated to a first namespace stored in the first block 510; the entry in the namespace-level VTC column 532 includes a second count value for the total number of valid TUs allocated to a second namespace stored in the first block 510; and the entry in the namespace-level VTC column 534 includes a third count value for the total number of valid TUs allocated to a third namespace stored in the first block 510.

[0059] Similarly, a second block (e.g., block 1) may include a second entry in the global VTC column 520 and one or more individual entries in the namespace-level VTC columns 530, 532, and 534. For example, the entry of the global VTC column 520 includes a count value representing the total number of valid TUs allocated to each of the namespaces stored in the second block. The entry in the namespace-level VTC column 530 includes a fourth count value representing the total number of valid TUs allocated to the first namespace stored in the second block; the entry in the namespace-level VTC column 532 includes a fifth count value representing the total number of valid TUs allocated to the second namespace stored in the second block; and the entry in the namespace-level VTC column 534 includes a sixth count value representing the total number of valid TUs allocated to the third namespace stored in the second block.

[0060] In some examples, to delete the second namespace from the memory subsystem, the namespace-level VTC manager 122 may access the tracking metadata to identify the count value of the second namespace stored in the VTC table (table 500). For example, the namespace-level VTC manager 122 may determine that the first block 510 stores the count value 300 in the entry of the namespace-level VTC column 532 of the second namespace. In order to delete or format the second namespace, the namespace-level VTC manager 122 reduces the corresponding entry (e.g., 1000) in the global VTC column 520 to the count value 300 in the entry in the namespace-level VTC column 532 in a single operation. In this case, the corresponding entry in the global VTC column 520 is reduced to a value of 700 valid TUs in a single operation. This process is repeated across all memory blocks, and then the second namespace is removed from the tracking metadata. Next, the second namespace is deallocated from the L2P table.

[0061] Figure 6 An interaction diagram illustrating the interactions between components of a computing environment 100 in the context of some embodiments of a method for performing VTC table management is provided. The operation of the method may be performed by a processing logic, which may include hardware (e.g., a processing device, a circuit system, a dedicated logic, a programmable logic, a microcode, hardware of a device, an integrated circuit, etc.), software (e.g., an instruction running or executing on a processing device), or a combination thereof. In some embodiments, the method is performed by a memory subsystem controller 115. Although the operations are shown in a particular order or sequence, the order of the process may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood to be examples only, and the illustrated processes may be performed in different orders, and some processes may be performed in parallel. In addition, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment.

[0062] exist Figure 6 In the context of the example illustrated in , the host system may include host system 120, the processor of the memory subsystem controller may include processor 117 of memory subsystem 110, and the one or more memory components may include at least one of memory components 112A-112N.

[0063] like Figure 6 , at operation 602, a host system (e.g., via a processor of host system 120) generates a request to create a new namespace on memory component(s), and at operation 612, a processor of a memory subsystem controller receives a request to create a new namespace from the host system. At operation 630, the memory component receives user data and stores it on the block(s) of the new namespace.

[0064] At operation 614, the processor of the memory subsystem controller determines the number of namespaces currently represented by the VTC table.

[0065] At operation 618, the processor of the memory subsystem controller updates the VTC table to describe the new namespace based on the size of the new namespace.

[0066] Figure 7 An example machine in the form of a computer system 700 is illustrated within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed. In some embodiments, the computer system 700 may correspond to a host system (e.g., Figure 1 1) a host system 120 that includes, is coupled to, or utilizes a memory subsystem (e.g., Figure 1The memory subsystem 110 of the controller may be used to execute the operation of the controller (for example, to execute the operating system to execute the corresponding Figure 1 In some embodiments, the machine may be connected (e.g., using a network) to 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.

[0067] The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a network appliance, a server, a network router, a network switch, a network bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Furthermore, while a single machine is described, 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.

[0068] The example computer system 700 includes a processing device 702, a main memory 704 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) (e.g., synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM)), etc.), a static memory 706 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage system 718, which communicate with each other via a bus 730.

[0069] The processing device 702 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, or the like. More specifically, the processing device 702 may 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. The processing device 702 may 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 702 is configured to execute instructions 726 for performing the operations and steps discussed herein. The computer system 700 may further include a network interface device 708 for communicating over a network 720.

[0070] The data storage system 718 may include a machine-readable storage medium 724 (also referred to as a computer-readable medium) having stored thereon one or more sets of instructions 726 or software embodying any one or more of the methodologies or functions described herein. The instructions 726 may also reside, completely or at least partially, within the main memory 704 and / or within the processing device 702 during execution by the computer system 700, wherein the main memory 704 and the processing device 702 also constitute machine-readable storage media. The machine-readable storage medium 724, the data storage system 718, and / or the main memory 704 may correspond to Figure 1 Memory subsystem 110.

[0071] In one embodiment, instructions 726 include instructions for implementing a method corresponding to a namespace-level VTC manager (e.g., Figure 1 The term "machine-readable storage medium" should also be considered to 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 methodologies of the present disclosure. Therefore, the term "machine-readable storage medium" should be considered to include, but not limited to, solid-state memory, optical media, and magnetic media.

[0072] 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 data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is herein and generally conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulation of physical quantities. Typically, but 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, primarily for common usage reasons, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0073] It should be remembered, however, that all of these and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. The present disclosure may be directed to the actions 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'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.

[0074] The present disclosure also relates to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the intended purpose, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. This 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; read-only memory (ROM); random access memory (RAM); erasable programmable read-only memory (EPROM); EEPROM; magnetic or optical cards; or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus.

[0075] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general purpose systems may be used with programs according to the teachings herein, or it may prove convenient to build more specialized equipment to perform the methods. The structures of a variety of these systems will appear as described in the above description. 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 ​​may be used to implement the teachings of the present disclosure as described herein.

[0076] 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 form readable by a machine (e.g., a computer). In some embodiments, a machine-readable (e.g., computer-readable) medium includes a machine-readable (e.g., computer-readable) storage medium, such as a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage medium, an optical storage medium, a flash memory component, and the like.

[0077] In the foregoing description, embodiments of the present disclosure have been described with reference to specific example embodiments thereof. It will be apparent that various modifications may be made to the present disclosure without departing from the broader spirit and scope of the embodiments of the present disclosure as set forth in the appended claims. Accordingly, the description and drawings should be regarded in an illustrative rather than a restrictive sense.

Claims

1. A system comprising: A set of memory components of a memory subsystem; and a processing device operably coupled to the set of memory components, the processing device configured to perform operations comprising: generating a plurality of namespaces on the memory subsystem, the set of memory components comprising blocks for storing data of a set of namespaces among the plurality of namespaces in one or more translation units; and maintaining a table describing the number of valid conversion unit counts stored on the memory subsystem, the table comprising: a first count of valid conversion units on the block; and A second count of valid translation units for individual namespaces in the set of namespaces in the one or more translation units of the block is stored.

2. The system of claim 1, wherein the operations include: searching a plurality of valid conversion unit counts across a plurality of blocks of the set of memory components to determine an identified count that satisfies a criterion; selecting an individual block of the plurality of blocks associated with the identified count; and A trash collection operation is performed on the individual block in response to selecting the individual block. 3 . The system of claim 1 , wherein the second count represents a number of translation units that the individual namespace has in the block. 4 . The system of claim 1 , wherein the table stores a plurality of namespace counts of the set of namespaces, a namespace count in the plurality of namespace counts describing a number of valid translation units of a corresponding namespace in the set of namespaces.

5. The system of claim 1, wherein the operations include: receiving a request to create a new namespace on the memory subsystem; and In response to receiving the request: determining the number of namespaces currently described by the table; comparing the number to a threshold value; and The table is updated based on a result of the comparison of the number to the threshold.

6. The system of claim 5, wherein the operations include: determining whether the number is less than the threshold; and In response to determining that the number is less than the threshold: for each block in the memory subsystem, adding to the table a new count describing the size of the new namespace; and The first count is incremented by the number of valid translation units that the new namespace has in the block.

7. The system of claim 5, wherein the operations include: determining whether the number is greater than or equal to the threshold; and In response to determining that the number is greater than or equal to the threshold: comparing the size of the new namespace to the size of each of the plurality of namespaces; and In response to determining that the size of the new namespace is less than the size of the plurality of namespaces, the first count is incremented by a number of valid translation units that the new namespace has in the block.

8. The system of claim 5, wherein the operations include: determining whether the number is greater than or equal to the threshold; and In response to determining that the number is greater than or equal to the threshold: comparing the size of the new namespace to the size of each of the plurality of namespaces; and In response to determining that the size of the new namespace is greater than the size of the selected one of the plurality of namespaces, replacing the count value of the selected one of the plurality of namespaces with a new count value of valid conversion units of the new namespace.

9. The system of claim 1, wherein the operations include: receiving a request to format the individual namespace; and In response to receiving the request: obtaining the second count associated with the individual namespace; and The second count is subtracted from the first count.

10. The system of claim 9, wherein the operations include: The second count is removed from the table.

11. The system of claim 9, wherein the operations include: Stores tracking metadata describing a namespace whose individual counts of valid translation units are stored in the table.

12. The system of claim 11, wherein the operations include: A determination is made that the individual namespace is included in the tracing metadata, the second count is obtained in response to a determination that the individual namespace is included in the tracing metadata and the second count is subtracted from the first count.

13. The system of claim 9, wherein the operations include: Each of a plurality of logical block addresses associated with the individual namespace is deallocated, the deallocation comprising writing an invalid physical address to a logical-to-physical (L2P) mapping table of logical block addresses to physical addresses associated with the individual namespace.

14. The system of claim 1, wherein the table is stored on a static random access memory (SRAM) device of the memory subsystem.

15. A method comprising: generating a plurality of namespaces on a memory subsystem including a set of memory components, the set of memory components including blocks for storing data of a set of namespaces in the plurality of namespaces in one or more translation units; and maintaining a table describing the number of valid conversion unit counts stored on the memory subsystem, the table comprising: a first count of valid conversion units on the block; and A second count of valid translation units for individual namespaces in the set of namespaces in the one or more translation units of the block is stored.

16. The method according to claim 15, further comprising: searching a plurality of valid conversion unit counts across a plurality of blocks of the set of memory components to determine an identified count that satisfies a criterion; selecting an individual block of the plurality of blocks associated with the identified count; and A trash collection operation is performed on the individual block in response to selecting the individual block.

17. The method of claim 15, wherein the second count represents the number of translation units that the individual namespace has in the block.

18. The method of claim 15, wherein the table stores a plurality of namespace counts of the set of namespaces, a namespace count in the plurality of namespace counts representing a number of valid translation units of a corresponding namespace in the set of namespaces.

19. A non-transitory computer-readable storage medium comprising instructions that, when executed by a processing device, cause the processing device to perform operations comprising: generating a plurality of namespaces on a memory subsystem including a set of memory components, the set of memory components including blocks for storing data of a set of namespaces in the plurality of namespaces in one or more translation units; and maintaining a table describing the number of valid conversion unit counts stored on the memory subsystem, the table comprising: a first count of valid conversion units on the block; and A second count of valid translation units for individual namespaces in the set of namespaces in the one or more translation units of the block is stored.

20. The non-transitory computer-readable storage medium of claim 19, the operations comprising: searching a plurality of valid conversion unit counts across a plurality of blocks of the set of memory components to determine an identified count that satisfies a criterion; selecting an individual block of the plurality of blocks associated with the identified count; and A trash collection operation is performed on the individual block in response to selecting the individual block.

Images