Namespace management for the memory subsystem

Abstract

The present application relates to namespace management for a memory subsystem. A memory subsystem may generate a namespace mapping table having a set of namespace blocks associated with the memory subsystem. The namespace block may include one or more logical block addresses associated with the memory subsystem. One namespace block in the set of namespace blocks may include an indication indicating that the namespace block and each namespace block following the namespace block are available for mapping. The memory subsystem may receive a request to create a namespace and sequentially map one or more available namespace blocks to the namespace according to an order in the namespace mapping table, including the namespace block with the indication.

Description

[0001] Cross Reference

[0002] This patent application claims priority to U.S. patent application No. 16 / 914,939, filed by Frolikov et al. on June 29, 2020, entitled “NAMESPACE MANAGEMENT FOR MEMORY SUB-SYSTEMS,” which is assigned to its assignee and is expressly incorporated herein by reference in its entirety. Technical Field

[0003] The technical field relates to namespace management for memory subsystems. Background Art

[0004] 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

[0005] A method is described. The method may include: generating a namespace mapping table having a set of namespace blocks associated with a memory subsystem, wherein a namespace block in the set of namespace blocks indicates that the namespace block and each namespace block following the namespace block are available for mapping according to an ordering of the namespace mapping table, and wherein each namespace block includes one or more logical block addresses associated with the memory subsystem; receiving a request to create a namespace using the namespace mapping table; and in response to the request, sequentially mapping one or more available namespace blocks to the namespace according to the ordering of the namespace mapping table, wherein the one or more available namespace blocks include at least the namespace block.

[0006] 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: generate a namespace mapping table including a plurality of namespace blocks associated with the plurality of memory components, wherein a namespace block in the plurality of namespace blocks indicates that each namespace block following the namespace block in the namespace mapping table is available for namespace mapping based on an ordering of the namespace mapping table; and sequentially map one or more available namespace blocks in the plurality of namespace blocks to a namespace based on the order of the namespace mapping table, wherein the one or more available namespace blocks include the namespace block, one or more namespace blocks following the namespace block, or a combination thereof.

[0007] A non-transitory computer-readable storage medium is described. The non-transitory computer-readable storage medium may include instructions that, when executed by a processing device, cause the processing device to: generate a namespace mapping table having a set of namespace blocks associated with a memory subsystem, wherein a namespace block in the set of namespace blocks indicates that the namespace block and each namespace block following the namespace block are available for mapping according to an ordering of the namespace mapping table, and wherein each namespace block includes one or more logical block addresses associated with the memory subsystem; receive a request to create a namespace using the namespace mapping table; and in response to the request, sequentially map one or more available namespace blocks to the namespace according to the ordering of the namespace mapping table, wherein the one or more available namespace blocks include at least the namespace block. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] 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. However, the drawings should not be construed as limiting the present disclosure to specific embodiments, but are for explanation and understanding only.

[0009] Figure 1 is an example of a computing environment according to some embodiments of the present disclosure.

[0010] Figure 2A and 2B is a flowchart of an example method of managing a namespace according to some embodiments of the present disclosure.

[0011] Figure 3 An example namespace management operation according to some embodiments of the present disclosure is described.

[0012] Figure 4 An example namespace management operation according to some embodiments of the present disclosure is described.

[0013] Figure 5 A machine is an example of a computer system in which embodiments of the present disclosure may operate. DETAILED DESCRIPTION

[0014] Aspects of the present disclosure relate to sequential prefetching via a linked array. The memory subsystem may be a storage device, a memory module, or a mixture of a storage device and a memory module. Figure 1 Examples of storage devices and memory modules are described. Generally speaking, a host system may utilize a memory subsystem that includes one or more memory components (also referred to below as "memory devices"). The host system may provide data to be stored at the memory subsystem and may request data to be retrieved from the memory subsystem.

[0015] The memory device may be a nonvolatile memory device. A nonvolatile memory device is a package of one or more dies. Each die may consist of one or more planes. For some types of nonvolatile memory devices, such as NAND devices, each plane consists of a set of physical blocks. Each block consists of a set of pages. Each page consists of a group of memory cells that store data bits. For some memory devices, such as NAND devices, a block is the smallest erasable area, and pages within a block cannot be erased individually. For such devices, erase operations are performed one block at a time.

[0016] Pages of a block may contain valid data, invalid data, or no data. Invalid data is data that is marked as obsolete as new versions of data are stored on the memory device. Invalid data includes data that was previously written but is no longer associated with a valid logical address (e.g., 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 contain no data include pages that have been previously erased and have not yet been written to.

[0017] A memory subsystem may contain multiple memory cells, and each memory cell may be associated with a logical block address (LBA) within the memory subsystem's firmware. The LBAs may be stored in the memory subsystem's firmware and used by the firmware when performing access operations (e.g., when reading, writing, erasing, and rewriting data to a memory cell). In some cases, the LBAs may be organized into groups of LBAs. For example, the LBAs may be sequentially ordered and organized into groups of LBA blocks. In some cases, the LBA blocks may be referred to as namespace blocks. For example, a memory subsystem may contain 8 terabytes (TB) of memory cells, and the LBAs may be grouped into 2 gigabyte (GB) namespace blocks, where each namespace block contains 2 GB of sequentially ordered LBAs. In this case, 64,000 different namespace blocks are used to organize the LBAs within the firmware (e.g., 8 TB of memory divided by 2 GB per block yields 64,000 LBA blocks).

[0018] The memory subsystem can utilize a namespace mapping table to manage namespace blocks within the firmware. In some cases, the namespace mapping table can be organized into different sections. In the case of the Non-Volatile Memory Express (NVMe) protocol, sections can be referred to as namespaces. The firmware can partition the namespace mapping table into multiple namespaces, and namespace blocks can be allocated to each namespace. The firmware can allocate all namespace blocks to a namespace until all namespace blocks are fully allocated, or the firmware can allocate only some namespace blocks to a namespace.

[0019] When allocating different namespace blocks into a namespace, the firmware may utilize a free list. Initially, all namespace blocks may be assigned to a free list so that the free list contains all namespace blocks available for allocation into the namespace. The firmware may allocate namespace blocks to a namespace by reassigning a namespace block from the free list to a given namespace (e.g., moving it from the free list to the namespace). In some cases, the firmware may continue to allocate free namespace blocks to the namespace until no free namespace blocks in the free list are available.

[0020] When a free list is utilized, the size of the free list is configured to be large enough to contain all available namespace blocks (e.g., when all namespace blocks are available for namespace allocation). Additionally, the namespace mapping table may be configured to be large enough to contain all namespace blocks (e.g., when all namespace blocks have been allocated to the namespace). In these cases, there may be redundancy in the amount of firmware memory dedicated to managing the namespace because both the free list and the namespace mapping table are large enough to contain all namespace blocks. For example, in a scenario where 8TB of memory is available and the namespace block size is 2GB, both the free list and the namespace mapping table may each contain enough memory to store 64,000 entries for the namespace blocks. This redundancy may take up memory that the firmware could otherwise use to improve efficiency and latency in the functionality of the memory subsystem.

[0021] Aspects of the present disclosure address the above and other shortcomings by providing a memory subsystem that does not include or utilize a separate free list for namespace management. Instead of utilizing and managing both the free list and the namespace mapping table individually, the firmware can utilize a namespace mapping table that specifies information about namespace blocks (e.g., whether a given namespace block is available for mapping) without having a separate free list containing such information. For example, an indicator within the namespace mapping table or stored as a private variable accessible to the firmware can be used to distinguish between allocated (e.g., mapped) and unallocated (e.g., unmapped) namespaces, rather than using a free list that includes unmapped LBAs that can be used for namespace mapping and a namespace mapping table that only has LBAs mapped to the namespace. By using the namespace mapping table without using a free list, redundancy of the namespace mapping table and the free list can be avoided, and the firmware can function more efficiently than if a free list were used. Such techniques can free up memory used by the memory subsystem.

[0022] First, in reference Figure 1Features of the present disclosure are described in the context of the computing environment described. Features of the present disclosure are described in the context of example methods for managing namespaces without using free lists and flowcharts of example namespace management operations without using free lists, as described with reference to Figures 2 to 4. These and other features of the present disclosure are described by reference to the referenced Figure 5 The described computer system for namespace management of a memory subsystem is further illustrated and described.

[0023] Figure 1 An example computing system 100 is illustrated that includes a memory subsystem 110 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 thereof.

[0024] The memory subsystem 110 can be a storage device, a memory module, or a combination of both. 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, secure digital (SD) cards, and hard disk drives (HDDs). Examples of memory modules include dual inline memory modules (DIMMs), small outline DIMMs (SO-DIMMs), and non-volatile DIMMs (NVDIMMs).

[0025] 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 (such as an airplane, drone, train, car, or other transportation vehicle), an Internet of Things (IoT) enabled device, an embedded computer (such as an embedded computer included in a vehicle, industrial equipment, or a networked commercial device), or such a computing device that includes a memory and a processing device.

[0026] Computing system 100 can include a host system 105 coupled with one or more memory subsystems 110. In some examples, host system 105 is coupled with memory subsystems 110 of different types. Figure 1 An example of a host system 105 coupled to a memory subsystem 110 is illustrated. As used herein, "coupled to" or "coupled with" 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, optical, magnetic, etc.

[0027] 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.

[0028] The host system 105 can be coupled to the memory subsystem 110 using a physical host interface. Examples of a physical host interface include, but are not limited to, a Serial Advanced Technology Attachment (SATA) interface, a Peripheral Component Interconnect Express (PCIe) interface, a USB interface, Fibre Channel, a Small Computer System Interface (SCSI), a Serial Attached SCSI (SAS), 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 can 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 can further utilize a Non-Volatile Memory Express (NVMe) interface to access memory components (e.g., 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 .

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

[0030] Some examples of nonvolatile 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 nonvolatile memory cells. A cross-point nonvolatile memory array can perform bit storage based on bulk resistance changes in conjunction with a stackable cross-gate data access array. In addition, in contrast to many flash-based memories, cross-point nonvolatile memory can perform write-in-place operations, where nonvolatile memory cells can be programmed without previously erasing them. NAND-type flash memory includes, for example, two-dimensional NAND (2D NAND) and three-dimensional NAND (3D NAND).

[0031] Each of the memory devices 130 may include one or more memory cell arrays. One type of memory cell, such as a single-level cell (SLC), may store one bit per cell. Other types of memory cells, such as a multi-level cell (MLC), a three-level cell (TLC), and a four-level cell (QLC), may store multiple bits per cell. In some embodiments, each of the memory devices 130 may include one or more memory cell arrays, such as SLC, MLC, TLC, QLC, or any combination thereof. In some embodiments, a particular memory device may include an SLC portion and an MLC portion, a TLC portion, or a QLC portion of memory cells. The memory cells of the memory devices 130 may be grouped into pages, which may refer to a logical unit of a memory device for storing data. For some types of memory, such as NAND, pages may be grouped to form blocks.

[0032] Although a nonvolatile memory device such as NAND-type flash memory is described, the memory device 130 may be based on any other type of nonvolatile memory, such as read-only memory (ROM), phase-change memory (PCM), self-select memory, other chalcogenide-based memories, ferroelectric transistor random access memory (FeTRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), NOR flash memory, spin-torque (STT)-MRAM, conductive bridging RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), and electrically erasable programmable ROM (EEPROM).

[0033] The memory subsystem controller 115 (or, for simplicity, the controller 115) can communicate with the memory device 130 to perform operations such as reading data, writing data, or erasing data at the memory device 130, and other such operations. 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.

[0034] 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 embedded memory configured to store instructions for executing various processes, operations, logic flows, and routines that control the operation of the memory subsystem 110, including handling communications between the memory subsystem 110 and the host system 105.

[0035] In some examples, local memory 125 may include memory registers that store memory pointers, fetched data, etc. Local memory 125 may also include read-only memory (ROM) for storing microcode. Figure 1 The example memory subsystem 110 in FIG. 1 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 and may instead rely on external control (e.g., provided by an external host, or provided by a processor or controller separate from the memory subsystem).

[0036] 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. The memory subsystem controller 115 may be responsible for other operations such as wear leveling operations, garbage collection operations, error detection and error correction code (ECC) operations, encryption operations, cache operations, and address translation between logical block addresses (e.g., logical block addresses (LBAs), namespaces) and physical addresses (e.g., physical block addresses) associated with the memory device 130. The memory subsystem controller 115 may further include host interface circuitry for communicating with the host system 105 via a physical host interface. The host interface circuitry may convert commands received from the host system into command instructions to access the memory device 130, and also convert responses associated with the memory device 130 into information for the host system 105.

[0037] The memory subsystem 110 may also include additional circuitry or components not illustrated. 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 can receive addresses from the memory subsystem controller 115 and decode the addresses to access the memory device 130.

[0038] 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 raw memory device combined with a local controller (e.g., local controller 135) for media management within the same memory device package. An example of a managed memory device is a managed NAND (MNAND) device.

[0039] The memory subsystem 110 includes a namespace manager 150 that can manage namespaces and LBA blocks that are available or mapped to the namespaces (which can be referred to as namespace blocks) within the firmware of the memory subsystem 110. The namespace manager 150 can contain all namespace blocks associated with the memory subsystem 110 and can manage the namespace blocks by mapping the namespace blocks to namespaces within the namespace manager 150. In some cases, indicators can be used to determine which namespace blocks are assigned to a namespace, and the indicators can allow namespace blocks to be mapped to a namespace without using free lists.

[0040] In some examples, the memory subsystem controller 115 includes at least a portion of a namespace 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 for performing the operations described herein. In some examples, the namespace manager 150 is part of the host system 105, an application, or an operating system.

[0041] The namespace manager 150 may map namespace blocks to namespaces without using a free list independent of the namespace manager 150. In some cases, a namespace mapping table may contain indicators associated with namespace blocks within a namespace. The indicators may indicate the division between mapped namespace blocks and namespace blocks available for mapping (e.g., unmapped namespace blocks). In this case, when a new namespace is mapped by the firmware, the firmware may sequentially map the new namespace using the available namespace blocks, starting with the namespace block associated with the indicator (e.g., where the indicator specifies the first namespace block available for mapping). After mapping the new namespace, the indicator may be disassociated from the previous first available namespace block and associated with a new available namespace block, which may be the first available namespace block for namespace mapping. In some cases, the indicator may be a private variable stored in a memory accessible by the firmware and may be or may convey an index to the first available namespace block. In the event that a namespace is deleted, the indicator can be disassociated from the previous first available namespace block and, after a reordering of the available namespace blocks, associated with the new (i.e., updated due to the namespace mapping) first available namespace block. In these cases, the namespace manager 150 can be managed (e.g., namespaces can be added and deleted) without using a free list. Further details regarding the operation of the namespace manager 150 are described below.

[0042] Figure 2A is a flow chart of an example method 200-a for managing a namespace of a memory subsystem according to some embodiments of the present disclosure. The method 200-a 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 executing on a processing device), or a combination thereof. In some examples, the method 200-a is performed by Figure 1The processes are executed by the namespace manager 150. Although shown in a particular order or sequence, the order of the processes is modifiable unless otherwise specified. Therefore, the illustrated examples should be understood as examples only, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. In addition, in various examples, one or more processes may be omitted. Therefore, not all processes are required in every example. Other process flows are possible.

[0043] In operation 205, the processing device generates a namespace mapping table. In some embodiments, the namespace mapping table is generated once during the life of the memory subsystem. For example, one or more default namespace mapping tables are generated when the memory subsystem is manufactured or at first boot. In other cases, the namespace mapping table is generated more than once during the life of the memory subsystem. For example, if the memory subsystem undergoes formatting (e.g., a low-level format used to reset the drive to its manufactured state) during its life. The namespace mapping table may contain enough entries to organize each namespace block within the namespace mapping table. As discussed above, each namespace block may contain a group of consecutively ordered LBAs (e.g., sequentially ordered LBAs) associated with memory cells within the memory subsystem. In this case, the size of the namespace mapping table may be based on the number of namespace blocks in the memory subsystem and, therefore, the number of LBAs that can be grouped into each namespace block. For example, the firmware may organize the LBAs into 2GB namespace blocks. In this case, the namespace mapping table may contain enough entries for each 2GB namespace block, and the namespace mapping table size is based on this number of entries. In some cases, the firmware can change the namespace block size, and the namespace mapping table size can adapt to the change. For example, the firmware can reduce the namespace block size to 1GB. In this case, the namespace mapping table entry size can be doubled to accommodate twice as many namespace blocks.

[0044] In operation 210, the processing device receives a request to create a namespace. The request may be from a host system (e.g., a reference Figure 1In some cases, the request is received by the host system 105 (as discussed above) for namespace management. In some cases, the request may be received immediately after the memory subsystem is booted or when the host system 105 requests a new namespace. In some embodiments, the request is an opcode, such as a namespace management opcode. Within the opcode, a select instruction specifies a namespace creation instruction that the processing device recognizes and uses to generate the namespace. In some cases, the request may include the size of the namespace. The size of the namespace may determine the number of namespace blocks assigned to the namespace. For example, the memory subsystem may receive a request to create a 24GB namespace. In the case where the namespace block size is set to 2GB, 12 namespace blocks may be allocated to the namespace (e.g., 12 namespace blocks of 2GB each produce a 24GB namespace).

[0045] In some cases, the namespace mapping table can be organized according to index. For example, an index number can be associated with each entry in the namespace mapping table to which a namespace block is assigned. In this case, each namespace can therefore be associated with a group of consecutive index numbers. Then, namespace blocks can be assigned to namespaces, and the namespaces can be associated with index numbers. In this case, the index numbers can be used to manage the assignment of namespace blocks to namespaces. In other cases, the namespace mapping table may not be sorted according to index and may instead be in random order.

[0046] In operation 215, the processing device identifies a first available namespace block. For example, an indicator (e.g., a set of bits of a variable) may be associated with a namespace block of a namespace mapping table that is available for namespace allocation. In some cases, the namespace block may be the first available namespace block for namespace allocation (e.g., the first namespace block that is not allocated to a namespace (e.g., according to an ascending namespace index)). In some embodiments, the variable may be a private variable associated with the namespace mapping table and accessible to the firmware of the memory subsystem (e.g., the variable may be stored on a memory of the memory subsystem that is accessible to the firmware). The firmware may then reference this variable when determining an available namespace block to map to the namespace. The indicator may be used to specify the division between available namespace blocks and unavailable namespace blocks in the namespace mapping table. For example, all namespace blocks that are arranged before the indicator (e.g., have an index number less than the indicator) may be unavailable namespace blocks, and all namespace blocks that are arranged after the indicator (e.g., have an index number greater than the indicator) may be available namespace blocks.

[0047] In operation 220, the processing device maps the available namespace blocks. For example, the available namespace blocks can be sequentially mapped (e.g., allocated) to the namespace. As discussed above, the first available namespace block can be allocated to the namespace. Additional namespace blocks can be allocated to the namespace until the size of the namespace is fully allocated. For example, a 24GB namespace can be requested, and based on a namespace block size of 2GB, 12 namespace blocks can be allocated to the namespace to fill the namespace. In this case, the first available namespace block and the 11 additional namespace blocks are mapped to the namespace. The additional namespace blocks mapped to the namespace can sequentially follow the first available namespace block according to the index of the namespace block. For example, in the case where the index number of the first available namespace is 32, namespace blocks 33 to 43 are also mapped to the namespace.

[0048] At operation 225, the processing device removes the association of the variable or indicator with the first available namespace block of operation 215 (i.e., the processing device disassociates the indicator from the previous first available namespace block). The indicator is disassociated from the namespace block because the namespace block is no longer the first available namespace block nor is it a namespace block available for namespace allocation. In this case, the index number associated with the block is no longer associated with the first available namespace block for namespace allocation.

[0049] In operation 230, the processing device reorders the available namespace blocks. As discussed in operation 220, previously available namespace blocks have been allocated to the namespace. In this case, the index numbers associated with the available and unavailable namespace blocks may no longer correspond to namespace blocks available for namespace allocation. In this case, the firmware can reorder the available namespace blocks by assigning the most recently available namespace blocks to the index numbers corresponding to the available namespace blocks. In some cases, this can reorder all available namespace blocks to the new index numbers in the namespace mapping table. For example, in a case where a new namespace has been mapped to occupy index numbers 32 to 43, all available namespace blocks (e.g., namespace blocks associated with index numbers greater than 43) can be reordered.

[0050] In operation 235, the processing device updates the first available namespace block available for namespace mapping. As previously discussed, in operation 225, the variable indicating the first available namespace block may be removed from its association with the previous first available namespace, and in operation 230, the available namespace blocks may be reordered. In this case, the variable or indicator may be written to a storage device or memory of a memory subsystem accessible by the firmware and may be associated with or updated with a set of bits corresponding to the index of a new (e.g., second) namespace block available for namespace allocation. The new namespace block may be the current first available namespace block for namespace allocation (e.g., the first namespace block that was not allocated to a namespace after a namespace was already allocated). The firmware may then allocate this first available namespace block and the additional available namespace blocks to another namespace.

[0051] In some cases, operations 210 to 235 may be performed iteratively to map multiple namespaces in situations where multiple requests to create namespaces are received at the memory subsystem. For example, a request to create an additional namespace may be received by the memory subsystem (e.g., similar to operation 210). The memory subsystem may then sequentially allocate multiple available namespace blocks to the namespace based on a variable indicating a first available namespace block for mapping (e.g., similar to operation 220), remove associations with currently mapped namespace blocks (e.g., similar to operation 225), reorder the available namespace blocks (e.g., similar to operation 230), and associate another namespace block available for namespace mapping (e.g., similar to operation 235) with the indicator or variable. These steps may be repeated to map multiple namespaces in the namespace mapping table.

[0052] Figure 2B is a flow chart of an example method 200-b for managing a namespace of a memory subsystem according to some embodiments of the present disclosure. The method 200-b 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 examples, the method 200-b is performed by Figure 1 The processes are executed by the namespace manager 150. Although shown in a particular order or sequence, the order of the processes is modifiable unless otherwise specified. Therefore, the illustrated examples should be understood as examples only, and the illustrated processes may be performed in a different order, and some processes may be performed in parallel. In addition, in various examples, one or more processes may be omitted. Therefore, not all processes are required in every example. Other process flows are possible.

[0053] In some cases, a previously mapped namespace may be deleted from the namespace mapping table. Deletion of a namespace may occur after one or more namespaces have been allocated in the namespace mapping table. For example, at operation 240, the memory subsystem may receive a request to delete a namespace that has been mapped to the namespace mapping table. The mapping of the namespace may have already occurred during operations 210 through 235 (e.g., mapping the first namespace) or in a similar manner as in Figure 2A The operations 210 to 235 described in occur during the operation (eg, mapping the latter namespace).

[0054] The request may be from a host system (e.g., reference Figure 1 In some embodiments, the host system 105 receives a host request for namespace management. In some embodiments, the request is an opcode, such as a namespace management opcode. Within the opcode, a select instruction specifies a namespace delete that the processing device recognizes and uses to delete the namespace. In some cases, the request may include the size of the namespace. The size of the namespace may indicate the number of namespace blocks assigned to the namespace. For example, the memory subsystem may receive a request to delete a 24GB namespace. In the case where the namespace block size is set to 2GB, 12 namespace blocks are allocated to the namespace (e.g., 12 namespace blocks of 2GB each yield a 24GB namespace).

[0055] In operation 245, the processing device unmaps the previously allocated namespace. Unmapping the namespace may include disassociating each mapped namespace block from the namespace and associating the now-disassociated namespace blocks with namespace blocks available for mapping. In this example, the unmapped namespace blocks may be associated with index numbers available for mapping. For example, in a scenario where a namespace includes namespace blocks associated with index numbers 32-43 (e.g., namespace blocks 32-43 were mapped to the namespace) and the namespace is deleted, the index numbers previously associated with the namespace (e.g., index numbers 32-43) may then be associated with free namespace blocks available for namespace mapping.

[0056] In operation 250, the processing device cancels the association of the indicator (e.g., variable) previously associated with the first available namespace block. In some cases, the association of the indicator with this namespace block is removed because the namespace block is no longer the first available namespace block for namespace mapping. For example, in a case where a namespace that was once associated with index numbers 32 to 43 is deleted, the index number associated with the first available namespace block may change from 44 (e.g., the first available namespace block before the namespace deletion) to index number 32 (e.g., the new first available namespace block index number after the namespace deletion). In this case, the indicator previously indicating the namespace block associated with index 44 may be removed because the namespace block associated with index number 32 is now the first available namespace block for namespace mapping. However, in some cases, after the namespace is unmapped, the first available namespace block for mapping is the same as before the namespace was mapped, and the removal of the indicator from the first available namespace block is not performed.

[0057] In operation 255, the processing device reorders the available namespace blocks in the namespace mapping table. Similar to operation 235, previously mapped namespace blocks may have been unmapped from the namespace. In this case, the index numbers associated with the available namespace blocks and the unavailable namespace blocks may no longer correspond to namespace blocks available for namespace allocation. In this case, the firmware can reorder the available namespace blocks by assigning the unmapped namespace blocks to the index numbers corresponding to the available namespace blocks. In some cases, this can reorder all available namespace blocks to the new index numbers in the namespace mapping table. For example, after deleting the namespaces previously associated with index numbers 32 to 43, all now available namespace blocks (e.g., namespace blocks associated with index numbers greater than 31) can be reordered.

[0058] At operation 260, the processing device updates the first available namespace block. As previously discussed, at operation 250, the indication may be disassociated from the previous first available namespace block, and at operation 255, the namespace mapping table may be reordered. After deleting the namespace and reordering the available namespace blocks, the indication may be associated with a different namespace block. This namespace block may be the new first available namespace block in the namespace mapping table. For example, as previously discussed, the namespaces associated with index numbers 32 to 43 may be deleted, and the available namespace blocks may be reordered so that the namespace associated with index number 32 is now the first available namespace block. In this case, the indication is updated to be associated with the namespace block associated with index number 32.

[0059] In some cases, operations similar to operations 240 through 260 may be performed iteratively to delete (e.g., unmap) multiple namespaces. For example, a request to delete a second namespace may be received by the memory subsystem (e.g., similar to operation 240). The memory subsystem may then unmap the namespace block from the namespace (e.g., similar to operation 245), remove the association of the indicator with the previously available first namespace block (e.g., similar to operation 250), reorder the available namespace blocks (e.g., similar to operation 255), and update the indication of the first available namespace block to the new namespace block available for namespace mapping (e.g., similar to operation 260). These steps may be repeated to unmap multiple namespaces in the namespace mapping table.

[0060] Figure 3 An example namespace management operation 300 is illustrated in which a namespace has been deleted without using a free list. In some cases, the namespace management operation 300 may include Figure 1 Some processing steps of method 200-a performed by the namespace manager 150 are described in detail.

[0061] Namespace management operations 300 may include adding a namespace to a namespace mapping table. Namespace mapping table 305-a and namespace mapping table 305-b illustrate two examples of namespace mapping tables, showing changes to the namespace mapping table before namespace creation (as indicated by namespace mapping table 305-a) and after namespace creation (as indicated by namespace mapping table 305-b).

[0062] Namespace mapping table 305-a illustrates an example namespace mapping table before the mapping of a new namespace. Namespace mapping table 305-a may include four mapped namespaces. A first namespace may include five namespace blocks, starting at namespace block 310-a (e.g., index number 0) and including all sequentially ordered namespace blocks up to and including namespace block 315-a (e.g., index number 4). A second namespace may include fifteen namespace blocks, starting at namespace block 320-a (e.g., index number 5) and including all sequentially ordered namespace blocks up to and including namespace block 325-a (e.g., index number 19). A third namespace may include ten namespace blocks, starting at namespace block 330-a (e.g., associated with index number 20) and including all sequentially ordered namespace blocks up to and including namespace block 335-a (e.g., associated with index number 29). A fourth namespace may include two namespace blocks, starting at namespace block 340-a (e.g., associated with index number 30) and including all sequentially ordered namespace blocks up to and including namespace block 345-a (e.g., associated with index number 31). In this case, namespace block 350 may be the first available unmapped namespace block (e.g., associated with index number 32), and all namespace blocks sequentially ordered after namespace block 350 up to and including namespace block 360-a (e.g., associated with index number 59) may be namespace blocks available for namespace mapping.

[0063] In the case of the namespace mapping table 305-a, the indication 355 may be a variable (e.g., a private variable written to a storage device accessible by the firmware) and may be associated with the namespace block 350 (e.g., as described with reference to operation 215 of method 200-a). In some cases, the indication 355 is a set of bits representing the index of the namespace block associated with the indication 355. The indication 355 indicates that the namespace block 350 is the first available namespace block for namespace mapping. The indication 355 may indicate that all namespace blocks associated with index numbers greater than the namespace block 350 are available for namespace mapping (e.g., associated with index numbers greater than or equal to 32). Although the namespace blocks with index numbers between 32 and 59 are shown in ascending order in the namespace mapping table 305-a, this order is not limiting, and any ordering of the namespace blocks (e.g., random order) may be considered without departing from the scope of the present disclosure.

[0064] As discussed with respect to operation 205 of method 200-a, the memory subsystem may receive a request to create a new namespace. The request may include the size of the namespace, and the memory subsystem may determine the number of namespace blocks to allocate to the namespace. For example, a request may be received for a 24GB namespace. In a scenario where each namespace block includes 2GB of contiguously ordered LBAs, twelve namespace blocks will be allocated to the requested namespace. In this scenario, twelve available namespace blocks will be mapped to the requested namespace. As discussed with respect to operation 220 of method 200-a, the twelve namespace blocks may be mapped to the new namespace according to the ordering of the namespace mapping table 305-a.

[0065] Namespace mapping table 305-b illustrates the example namespace mapping table after the mapping of the new namespace. As with namespace mapping table 305-a, the first four namespaces may have already been mapped (e.g., mapped to blocks 310-b through 315-b, namespace blocks 320-b through 325-b, namespace blocks 330-b through 335-b, and namespace blocks 340-b through 345-b, respectively) and include namespaces associated with index numbers 0 through 31. The newly mapped fifth namespace may include twelve namespace blocks, starting at namespace block 365 (e.g., associated with index number 32) and including all sequentially ordered namespace blocks up to and including namespace block 370 (e.g., associated with index number 29). As discussed with reference to operation 225 of method 200-a, after the new namespace is mapped to namespace mapping table 305-b, indication 355 may be disassociated from the previously first available namespace block. As illustrated in namespace mapping table 305-a, indication 355 may have previously been associated with namespace block 350, indicating that namespace block 350 was once the first available namespace block. After the new namespace (fifth namespace) is mapped, namespace block 350 is now associated with the new namespace and is no longer available for namespace mapping.

[0066] In response to allocating the available namespace blocks to the new namespace (e.g., the namespace blocks associated with index numbers 32-43), and as discussed with reference to operation 230 of method 200-a, the available namespace blocks may be reordered. As discussed with reference to operation 235 of method 200-a, after the reordering of the available namespace blocks, indication 355 may be updated to be associated with the new first available namespace block. For example, after the reordering of the available namespace blocks (e.g., as associated with index numbers 44-59), the new first available namespace block may be namespace block 375 (e.g., associated with index number 44). In this case, indication 355 may be associated with namespace block 375. Indication 355 may indicate that namespace block 375 is now the first available namespace block for namespace mapping, and that namespace block 375 may be used to indicate the namespace blocks available for mapping (e.g., all namespace blocks after namespace block 375 up to and including namespace block 360-b) if a second new namespace is mapped to the memory subsystem.

[0067] Figure 4 An example namespace management operation 400 is illustrated in which a namespace has been deleted without using a free list. In some cases, the namespace management operation 400 may include Figure 1 Some processing steps of method 200-b performed by the namespace manager 150 are described in detail.

[0068] Namespace management operation 400 may include deleting a namespace from a namespace mapping table. Namespace mapping table 405-a and namespace mapping table 405-b illustrate two instances of a namespace mapping table, showing changes to the namespace mapping table before the namespace is deleted (as indicated by namespace mapping table 405-a) and after the namespace is deleted (as indicated by namespace mapping table 405-b).

[0069] Namespace mapping table 405-a illustrates an instance namespace mapping table before a namespace is deleted from the namespace mapping table. Namespace mapping table 405-a may include five previously mapped namespaces. A first namespace may include five namespace blocks, starting at namespace block 410-a (e.g., index number 0) and including all sequentially ordered namespace blocks up to and including namespace block 415-a (e.g., index number 4). A second namespace may include fifteen namespace blocks, starting at namespace block 420-a (e.g., index number 5) and including all sequentially ordered namespace blocks up to and including namespace block 425-a (e.g., index number 19). A third namespace may include ten namespace blocks, starting at namespace block 430-a (e.g., associated with index number 20) and including all sequentially ordered namespace blocks up to and including namespace block 435-a (e.g., associated with index number 29). A fourth namespace may include two namespace blocks, starting at namespace block 440-a (e.g., associated with index number 30) and including all sequentially ordered namespace blocks up to and including namespace block 445-a (e.g., associated with index number 31). A fifth namespace may include twelve namespace blocks, starting at namespace block 450 (e.g., associated with index number 32) and including all sequentially ordered namespace blocks up to and including namespace block 455 (e.g., associated with index number 43). In this case, namespace block 460 may be the first available unmapped namespace block (e.g., associated with index number 44), and all namespace blocks sequentially ordered after namespace block 460 up to and including namespace block 470-a (e.g., associated with index number 59) may be namespace blocks available for namespace mapping. Although namespace blocks having index numbers between 44 and 59 are shown in consecutive ascending order in namespace mapping table 405-a, this order is not limiting, and any ordering of the namespace blocks (e.g., random order) may be considered without departing from the scope of the present disclosure.

[0070] In the case of namespace mapping table 405-a, indication 465 may be a variable (e.g., a private variable written to a storage device accessible by the firmware) and may be associated with namespace block 460 (e.g., as described with reference to operation 235 of method 200-a). In some cases, indication 465 is a set of bits representing the index of the namespace block to which indication 465 is associated. Indication 465 indicates that namespace block 460 is the first available namespace block for namespace mapping. Indication 465 may indicate that all namespace blocks associated with index numbers greater than namespace block 460 are available for namespace mapping (e.g., associated with index numbers greater than 44).

[0071] As discussed with respect to operation 240 of method 200 - b , the memory subsystem may receive a request to delete (e.g., unmap) a namespace. For example, the memory subsystem may receive a request to delete a fifth namespace (e.g., a fifth namespace that begins at namespace block 450 associated with index number 32 and includes all sequentially ordered namespace blocks up to and including namespace block 455 associated with index number 43).

[0072] As discussed with respect to operation 245 of method 200-b, a namespace may be unmapped. In this case, the namespace blocks previously associated with the newly deleted namespace may be unmapped in the namespace mapping table. For example, in response to the deletion of the fifth namespace, the namespace blocks associated with index numbers 32-43 may be unmapped from the fifth namespace (e.g., disassociated from the fifth namespace) and associated with unmapped (e.g., available) namespace blocks. Namespace mapping table 405-b illustrates four mapped namespaces after the deletion of the fifth namespace (e.g., four namespaces mapped to namespace blocks 410-b through 415-b, namespace blocks 420-b through 425-b, namespace blocks 430-b through 435-b, and namespace blocks 440-b through 445-b, respectively).

[0073] As discussed with reference to operation 250 of method 200-b, after unmapping the namespace block from the deleted namespace, indication 465 may be disassociated from the previously first available namespace block. As illustrated in namespace mapping table 405-a, indication 465 may have previously been written to namespace block 460, indicating that namespace block 460 was the first available namespace block. Upon deletion of the fifth namespace, indication 465 may be disassociated from namespace block 460 because namespace block 460 is no longer the first namespace block available for namespace mapping. In response to unmapping the fifth namespace (e.g., namespace blocks associated with index numbers 32 through 43 are now available for namespace mapping), and as discussed with reference to operation 255 of method 200-b, the available namespace blocks may be reordered. As discussed with reference to operation 260 of method 200-b, after the reordering of the available namespace blocks, indication 465 may be updated to be associated with the new first available namespace block. For example, after reordering the available namespace chunks (e.g., as associated with index numbers 32 through 59), the new first available namespace chunk is namespace chunk 475 (e.g., associated with index number 32). In this case, indication 465 may be associated with namespace chunk 475. Indication 465 indicates that namespace chunk 475 is now the first available namespace chunk for namespace mapping.

[0074] Figure 5is an example machine of a computer system 500 in which examples of the present disclosure may operate. The computer system 500 may include a set of instructions for causing the machine to perform any one or more of the techniques described herein. In some examples, the computer system 500 may correspond to a host system (e.g., a reference Figure 1 105) that includes a memory subsystem (e.g., a host system 105 described in Figure 1 The memory subsystem 110 described above, coupled to or utilizing the memory subsystem, or operable to perform operations of the controller (e.g., executing an operating system to perform operations corresponding to the reference Figure 1 In some examples, the machine may be connected (e.g., using a network) to other machines in a LAN, an intranet, an extranet, and / or the Internet. The machine may operate in the capacity of a server or a client user 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 user machine in a cloud computing infrastructure or environment.

[0075] 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 switch or a bridge, or any machine capable of executing (sequentially or otherwise) a set of instructions that specify actions to be taken by the machine. Furthermore, while a single machine is described, the term "machine" may also include any collection of machines that individually or jointly execute one (or more) sets of instructions to perform any one or more of the methodologies discussed herein.

[0076] The example computer system 500 may include a processing device 505, a main memory 510 (e.g., read-only memory (ROM), flash memory DRAM (e.g., SDRAM or RDRAM, etc.), a static memory 515 (e.g., flash memory, static random access memory (SRAM)), etc.), and a data storage system 525, which communicate with each other via a bus 545.

[0077] Processing device 505 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, or the like. More specifically, the processing device 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 implementing another instruction set, or multiple processors implementing a combination of instruction sets. Processing device 505 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. Processing device 505 is configured to execute instructions 535 for performing the operations and steps discussed herein. Computer system 500 may further include a network interface device 520 for communicating over a network 540.

[0078] The data storage system 525 may include a machine-readable storage medium 530 (also referred to as a computer-readable medium) on which is stored one or more sets of instructions 535 or software embodying any one or more of the methodologies or functionality described herein. The instructions 535 may also reside, completely or at least partially, within the main memory 510 and / or within the processing device 505 during execution thereof by the computer system 500, with the main memory 510 and the processing device 505 also constituting machine-readable storage media. The machine-readable storage medium 530, the data storage system 525, and / or the main memory 510 may correspond to a memory subsystem.

[0079] In one example, instructions 535 include instructions for implementing a method corresponding to a namespace manager 550 (e.g., referring to Figure 1 150 ). Although machine-readable storage medium 530 is shown as a single medium, 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 that is executed by a machine and causes the machine to perform any one or more of the methodologies 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.

[0080] 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. Operations are those requiring physical manipulation of physical quantities. Typically, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. It has proven convenient, sometimes for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

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

[0082] 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), ROM, RAM, EPROM, EEPROM, magnetic or optical cards, or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus.

[0083] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general-purpose systems may be used in conjunction with programs according to the teachings herein, or it may prove convenient to construct more specialized equipment to perform the methods. The structures for various such systems will appear as set forth in the description below. Additionally, 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.

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

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

Claims

1. A method for memory operation, comprising: generating a namespace mapping table having a set of namespace blocks associated with a memory subsystem, wherein a namespace block indication in the set of namespace blocks indicates that the namespace block and each namespace block following the namespace block are available for mapping according to an ordering of the namespace mapping table, and wherein each namespace block includes one or more logical block addresses associated with the memory subsystem, wherein the indication associated with the namespace block corresponds to a partitioning of the namespace mapping table, wherein each namespace block preceding the namespace block associated with the indication is unavailable for mapping and each namespace block following the namespace block associated with the indication is available for mapping; receiving a request to create a namespace using the namespace mapping table; and One or more available namespace blocks are sequentially mapped to the namespace according to the order of the namespace mapping table in response to the request, wherein the one or more available namespace blocks include at least the namespace block. 2 . The method of claim 1 , wherein the size of the namespace block is based at least in part on the number of logical block addresses associated with the namespace block. 3 . The method of claim 1 , wherein the one or more logical block addresses associated with the namespace block are ordered sequentially within the namespace block.

4. The method of claim 1, wherein a size of the namespace mapping table is based at least in part on a number of namespace blocks associated with the namespace mapping table and a size of the memory subsystem.

5. The method according to claim 1, further comprising: receiving a second request to delete the namespace; and Each namespace block associated with the namespace is unmapped within the namespace mapping table in response to the second request.

6. The method of claim 5 , wherein unmapping each namespace block associated with the namespace comprises: disassociating each namespace block from the namespace in the namespace mapping table; and Each disassociated namespace block within the namespace mapping table is associated as a namespace block available for namespace mapping according to the ordering of the namespace mapping table.

7. The method according to claim 6, further comprising: updating a variable using an index of the namespace block before mapping the namespace block, wherein the variable indicates a first available namespace block for mapping; disassociating the namespace block from the variable in response to the second request; and The variable is updated using a second index of a second namespace block based at least in part on the unmapping of each namespace block.

8. The method according to claim 7, further comprising: The variable is stored at the memory subsystem, wherein the variable is accessible by firmware of the memory subsystem.

9. The method according to claim 5, further comprising: The one or more available namespace blocks are reordered based at least in part on the unmapping of each namespace block.

10. The method of claim 1, further comprising: associating the indication with the namespace block prior to mapping the namespace block to the namespace, wherein the indication represents a first available namespace block for mapping; disassociating the indication from the namespace block after mapping the namespace block to the namespace; and The indication is associated with a second namespace block different from the namespace block based at least in part on the mapping of the one or more available namespace blocks to the namespace, wherein the second namespace block comprises a first available namespace block of the available namespace blocks of the namespace mapping table.

11. The method according to claim 10, further comprising: All available namespace blocks of the set of namespace blocks are reordered based at least in part on the mapping of the one or more available namespace blocks.

12. The method of claim 1, wherein each of the set of namespace blocks is associated with a respective index corresponding to a group of logical block addresses, and wherein the ordering of the namespace mapping table is based at least in part on the respective index.

13. The method of claim 1, wherein the namespace mapping table includes a variable for indicating that the namespace block and each namespace block following the namespace block are available for mapping according to the ordering of the namespace mapping table.

14. The method of claim 1, wherein the mapping of the one or more available namespace blocks to the namespace is performed upon startup of the memory subsystem.

15. A system for memory operation, comprising: multiple memory components; and a processing device operatively coupled to the plurality of memory components to perform the following operations: generating a namespace mapping table including a plurality of namespace blocks associated with the plurality of memory components, wherein a namespace block in the plurality of namespace blocks indicates that each namespace block following the namespace block in the namespace mapping table is available for namespace mapping based on an ordering of the namespace mapping table, wherein the indication associated with the namespace block corresponds to a partitioning of the namespace mapping table, wherein each namespace block preceding the namespace block associated with the indication is unavailable for mapping and each namespace block following the namespace block associated with the indication is available for mapping; and One or more available namespace blocks among the plurality of namespace blocks are sequentially mapped to a namespace based on the ordering of the namespace mapping table, wherein the one or more available namespace blocks include the namespace block, one or more namespace blocks after the namespace block, or a combination thereof.

16. The system according to claim 15, wherein the processing device is further configured to: receiving a request to create the namespace; and The one or more available namespace blocks are mapped in response to the request.

17. The system of claim 15, wherein the processing device is further configured to: receiving a request to delete the namespace after mapping the one or more available namespace blocks; and The one or more available namespace blocks mapped to the namespace are unmapped in response to the request.

18. A non-transitory computer-readable storage medium comprising instructions that, when executed by a processing device, cause the processing device to: generating a namespace mapping table having a set of namespace blocks associated with a memory subsystem, wherein a namespace block indication in the set of namespace blocks indicates that the namespace block and each namespace block following the namespace block are available for mapping according to an ordering of the namespace mapping table, and wherein each namespace block includes one or more logical block addresses associated with the memory subsystem, wherein the indication associated with the namespace block corresponds to a partitioning of the namespace mapping table, wherein each namespace block preceding the namespace block associated with the indication is unavailable for mapping and each namespace block following the namespace block associated with the indication is available for mapping; receiving a request to create a namespace using the namespace mapping table; and One or more available namespace blocks are sequentially mapped to the namespace according to the order of the namespace mapping table in response to the request, wherein the one or more available namespace blocks include at least the namespace block.

19. The non-transitory computer-readable storage medium of claim 18, wherein a size of the namespace block is based at least in part on a number of logical block addresses associated with the namespace block.

Images