Partitioned namespace limitation mitigation using sub-chunk mode

Abstract

The present invention is entitled "Zoned Namespace Limitation Mitigation Using Sub-Block Mode." The present invention provides aspects of a storage device including a memory and a controller that reduces or eliminates garbage collection in a zoned namespace (ZNS) architecture by mapping zones to sub-blocks of blocks of the memory. Each zone includes a plurality of logical addresses. The controller determines a number of open zones and maps the open zones to the sub-blocks in response to the number of open zones meeting a threshold. Thus, a larger number of open blocks typically present in a ZNS can be reduced, and increased block sizes due to scaling can be accommodated in the ZNS. In some aspects, the controller receives a request from a host device to write data associated with the zone to a sub-block, and in response to the request, maps each zone in the zone to at least one sub-block in the sub-blocks. The request can indicate that the zone is partially unused. Thus, a zone out condition can also be avoided.

Description

Background Art

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 074,936, filed on September 4, 2020, entitled “Zoned Namespace Limitation Mitigation Using Sub Block Mode,” which is incorporated herein by reference in its entirety as if fully set forth herein. Technical Field

[0003] The present disclosure relates generally to electronic devices and, more particularly, to storage devices. Background Art

[0005] Storage devices enable users to store and retrieve data. Examples of storage devices include non-volatile memory devices. Non-volatile memory typically retains data after power cycles. An example of non-volatile memory is flash memory, which can include an array of NAND cells on one or more dies. Flash memory can be found in solid-state devices (SSDs), secure digital (SD) cards, and the like.

[0006] Flash storage devices can store control information associated with data. For example, a flash storage device can maintain a control table that includes a mapping of logical addresses to physical addresses. This control table is used to track the physical location of logical sectors or blocks in the flash memory. The control table is stored in non-volatile memory to enable access to stored data after power cycles.

[0007] Zoned Namespace (ZNS) is an SSD namespace architecture in which nonvolatile memory is divided into fixed-size groups of logical addresses, or zones. Each zone is dedicated to a specific application. For example, a host can write data associated with different applications to different zones. Zones are spread across a single die, with each zone typically spanning 48MB or 64MB in size. The flash storage device interfaces with the host to obtain defined zones and maps them to blocks in the flash memory. Thus, the host can write data related to separate applications to separate blocks in the flash memory.

[0008] Conventionally, data in a flash storage device can be invalidated in small blocks (e.g., 4KB of data), for example, when a host overwrites data. To remove invalid data from the flash memory, the flash storage device performs a garbage collection (GC) process, in which valid data is copied to new blocks and invalid data is erased from old blocks. However, in ZNS, a zone is written sequentially before the data in the zone is invalidated, so an entire zone (e.g., 48 or 64MB of data) can be invalidated at once. This feature of ZNS reduces or eliminates GC, which in turn reduces write amplification (WA). As a result, ZNS can optimize the endurance of the flash storage device and improve the consistency of input / output (I / O) command latency. Summary of the Invention

[0009] This document discloses an aspect of a storage device. The storage device includes a memory and a controller. The memory includes a plurality of blocks, wherein each of the blocks includes a plurality of sub-blocks. The controller is configured to map a region to at least one of the sub-blocks, wherein the region includes a plurality of logical addresses.

[0010] Another aspect of a storage device is disclosed herein. The storage device includes a memory and a controller. The memory includes a plurality of blocks, each of which includes a plurality of sub-blocks. The controller is configured to determine a number of open regions and, in response to the number of open regions satisfying a threshold, map the open regions to the sub-blocks.

[0011] Another aspect of a storage device is disclosed herein. The storage device includes a memory and a controller. The memory includes a plurality of blocks, each of which includes a plurality of sub-blocks. The controller is configured to receive a request to write data associated with a region to a sub-block and, in response to the request, map each of the regions to at least one of the sub-blocks.

[0012] It should be understood that other aspects of the storage device will become apparent to those skilled in the art from the following detailed description, in which various aspects of the apparatus and method are shown and described by way of illustration. As will be appreciated, these aspects may be implemented in other and different forms, and several details thereof may be modified in various other respects. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not restrictive. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Various aspects of the invention will now be presented in detail by way of example and not limitation with reference to the accompanying drawings, in which:

[0014] Figure 1 is a block diagram illustrating an exemplary embodiment of a storage device in communication with a host device.

[0015] Figure 2This is an example Figure 1 A conceptual diagram of an example of a logical-to-physical mapping table in a non-volatile memory of a storage device.

[0016] Figure 3 It is a drawing Figure 1 A conceptual diagram of an example of a memory cell array in a storage device.

[0017] Figure 4 It is a drawing Figure 1 A conceptual diagram of an example of a block array in a storage device.

[0018] Figure 5 It shows that Figure 1 A conceptual diagram of an example of a garbage collection (GC) process implemented in a storage device.

[0019] Figure 6 Is to show the area and by Figure 1 A conceptual diagram of an example of an association of logical address groups received by a storage device.

[0020] Figure 7 is a diagram showing the writing of data to blocks mapped to different zones, Figure 1 A conceptual diagram of an example of a controller of a storage device.

[0021] Figure 8 is a diagram showing the writing of data to sub-blocks mapped to different zones, Figure 1 A conceptual diagram of an example of a controller of a storage device.

[0022] Figure 9 It is shown by Figure 1 A conceptual diagram of an exemplary mapping of regions to sub-blocks performed by a controller in a storage device.

[0023] Figure 10 It is shown by Figure 1 A conceptual diagram of another exemplary mapping of regions to sub-blocks performed by a controller in a storage device.

[0024] Figure 11 It is shown by Figure 1 A conceptual diagram of an additional exemplary mapping of regions to sub-blocks by a controller in a storage device.

[0025] Figure 12 Is shown as Figure 1 Flowchart of a method performed by a storage device for writing data to an area mapped to a sub-block. DETAILED DESCRIPTION

[0026] The specific embodiments described below in conjunction with the accompanying drawings are intended as descriptions of various exemplary embodiments of the present invention and are not intended to represent the only embodiments in which the present invention can be practiced. The specific embodiments include specific details for the purpose of providing a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention can be practiced without these specific details. In some cases, well-known structures and components are shown in block diagram form to avoid obscuring the concepts of the invention. Acronyms and other descriptive terms may be used only for convenience and clarity and are not intended to limit the scope of the present invention.

[0027] The words "exemplary" or "example" are used herein to mean serving as an example, instance, or illustration. Any exemplary embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other exemplary embodiments. Likewise, the term "exemplary embodiment" of an apparatus, method, or article does not require that all exemplary embodiments of the invention include the described component, structure, feature, function, process, advantage, benefit, or mode of operation.

[0028] As used herein, the term "coupled" is used to indicate a direct connection between two components or, where appropriate, an indirect connection to one another through intervening or intermediate components. In contrast, when a component is referred to as being "directly coupled" to another component, there are no intervening elements present.

[0029] In the following detailed description, various aspects of a storage device that communicates with a host device will be presented. These aspects are particularly applicable to flash memory storage devices, such as SSDs and SD cards. However, those skilled in the art will recognize that these aspects can be extended to all types of storage devices capable of storing data. Therefore, any reference to specific devices or methods is intended only to illustrate various aspects of the present invention, and it should be understood that these aspects can have a wide range of applications without departing from the spirit and scope of this disclosure.

[0030] Typically, in ZNS, the host provides the flash storage device with definitions of zones or groups of logical addresses. For example, the host may indicate that a set of LBAs corresponding to 48 or 64MB of data is associated with a first zone, another set of LBAs corresponding to another 48 or 64MB of data is associated with a second zone, and so on. The flash storage device then maps each zone to a single block in the flash memory. For example, the flash storage device may map the LBAs associated with the first zone to a first physical block, the LBAs associated with the second zone to a second physical block, and so on. This one-to-one mapping of each zone to a block allows for the reduction or elimination of GCs by effectively making the zones independent. For example, after sequentially writing data to blocks mapped to a zone, the host can invalidate the zone by instructing the flash storage device to erase only that block without affecting the data in other zones / blocks.

[0031] However, as a result of this zone-to-block mapping, ZNS can result in a large number of open blocks in a flash memory storage device. For example, unlike conventional flash memory storage devices that typically have a small number of open blocks (e.g., 1 or 2 open blocks for multi-level cell (MLC) such as quad-level cell (QLC)), a flash memory storage device implementing ZNS can have significantly more open blocks (e.g., between as few as 12 and as many as 4,000 open blocks), depending on the number of host applications. Since open blocks are known to have worse data retention (DR) characteristics (e.g., higher flip bit counts) than closed blocks, especially MLC open blocks such as QLC blocks, ZNS can significantly impact the data reliability or integrity of the flash memory storage device.

[0032] In addition, as flash storage devices advance toward subsequent generations, there is a trend toward increasing physical block sizes (e.g., the number of word lines and strings). For example, BICs4 flash storage devices currently have 96 word lines in a block, BICs5 flash storage devices may have 112 word lines in a block, and BICs6 flash storage devices are expected to have even more word lines in a block. However, although flash storage devices may support increasing physical block sizes, the host may not be able to support different zone sizes (i.e., zone sizes are fixed in ZNS). This may result in unused storage space in each block and, therefore, wasted storage capacity. For example, even if the capacity of each block increases from 64MB to 128MB in future generations, the host may still only be able to write at most 64MB of data to the zone mapped to each block, leaving the remaining 64MB of each block unused.

[0033] Furthermore, while in some cases a host may have a small number of applications, each associated with a large amount of data that the host can fill in a corresponding zone (e.g., 48 or 64 MB of data for some applications or zones), in other cases a host may have a large number of applications, each associated with only a small amount of data that the host can write in a corresponding zone (e.g., 24 or 32 MB of data for several applications or zones). If zones are mapped to separate physical blocks as described above, but the number of open blocks available for mapping is limited, then in the latter case, the flash storage device may run out of zones. For example, if there are only 10 open blocks available in the flash storage device, but the host requires more than 10 zones for its application data, the flash storage device may not be able to effectively support the host's requirements based on a one-zone / one-block mapping scheme, especially if each application data is small (e.g., half the size of a zone).

[0034] To mitigate the aforementioned limitations or effects of ZNS (e.g., a large number of open blocks with poor DR, insufficient adaptability to increased block sizes, and inefficient zone exhaustion for smaller data applications), the controller utilizes sub-blocks and mappings for zones. In response to receiving a zone definition (e.g., zone-to-logical address mapping) from the host or some other message indicating that ZNS will be used, the controller enables sub-block mode (SBM). In SBM, each block to be mapped to a zone is divided into multiple sub-blocks. For example, a block with 96 word lines (i.e., WL 0-95) can be divided so that the lower word lines (i.e., WL 0-47) are included in one sub-block and the upper word lines (i.e., WL 48-95) are included in another sub-block. These sub-blocks are configured to be independently programmable, readable, and erased; for example, different voltages can be applied to word lines in a selected sub-block than to word lines in unselected sub-blocks to enable reading, programming, or erasing data only in the selected sub-block. This characteristic of sub-blocks allows maintaining the independence of each zone, thus keeping GC from being reduced or eliminated from the ZNS.

[0035] To reduce the number of open blocks in the storage device and thus improve data retention, the controller can map each zone to two sub-blocks (in different blocks). For example, the controller can determine whether the number of open blocks or zones is greater than an open zone threshold, in which case the controller can enable SBM and map half of each zone to a sub-block in one block and the other half of each zone to a sub-block in another block. Thus, each physical block can be mapped to two different zones, rather than just one zone as in traditional ZNS implementations. Figure 9 An example of such a mapping is shown in Such a mapping serves to reduce the probability of having open blocks, since two partially written regions mapping to the same block may result in one closed block instead of two open blocks as in conventional ZNS.

[0036] Furthermore, to maintain ZNS compatibility with increased block sizes, the controller may map each zone to a sub-block if such increased block size is equal to the zone size. For example, if the sub-block size doubles, instead of mapping half of a zone to a sub-block as described above, the controller may map the entire zone to a sub-block. Figure 10 An example of such a mapping is shown in Such a mapping prevents unused space in each block from occurring due to increased block sizes, thus eliminating wasted storage capacity that can be incurred by traditional ZNS implementations.

[0037] Furthermore, to minimize situations where the flash storage device runs out of zones when the host manages multiple applications that only write relatively small amounts of data (e.g., half the size of a typical zone, such as 24 or 32 MB of data), the controller can activate the SBM in response to a host-issued request for an SBM indicating that one or more applications will only write a small amount of data. For example, the indication can include identifiers of which zones will not be fully written by the host, such as an indication that the host ensures that only half of each indicated zone will be filled by the corresponding application. In this case, the controller can map each indicated zone to a single sub-block. Figure 11 An example of this mapping is shown in Such a mapping effectively creates more (half-capacity) zones than in a traditional ZNS implementation by allowing more open blocks to be mapped for use with more applications.

[0038] Figure 1 An exemplary block diagram 100 illustrates a storage device 102 in communication with a host device 104 (also referred to as a "host") according to an exemplary embodiment. The host 104 and the storage device 102 may form a system, such as a computer system (e.g., a server, desktop computer, mobile / laptop computer, tablet computer, smartphone, etc.). Figure 1 The components of the storage device 102 may or may not be physically co-located. In this regard, the host 104 may be located remotely from the storage device 102. Figure 1 The host 104 is shown as being separate from the storage device 102, but in other embodiments, the host 104 may be fully or partially integrated into the storage device 102. Alternatively, the host 104 may be distributed entirely across multiple remote entities or alternatively have certain functionality within the storage device 102.

[0039] Those skilled in the art will appreciate that other exemplary embodiments may include Figure 1 More or fewer elements than those shown in the figure, and the disclosed processes can be implemented in other environments. For example, other exemplary embodiments can include a different number of hosts communicating with the storage device 102, or multiple storage devices 102 communicating with the host.

[0040] Host device 104 can store data to storage device 102 and / or retrieve data from the storage device. Host device 104 may include any computing device, including, for example, a computer server, a network-attached storage (NAS) unit, a desktop computer, a notebook (e.g., laptop) computer, a tablet computer, a mobile computing device such as a smartphone, a television, a camera, a display device, a digital media player, a video game console, a video streaming device, etc. Host device 104 may include main memory 103 and at least one processor 101. The at least one processor 101 may include any form of hardware capable of processing data and may include a general-purpose processing unit (such as a central processing unit (CPU)), specialized hardware (such as an application-specific integrated circuit (ASIC)), a digital signal processor (DSP), configurable hardware (such as a field-programmable gate array (FPGA)), or any other form of processing unit configured via software instructions, firmware, etc. Host device 104 may use main memory 103 to store data or instructions processed by the host or data received from storage device 102. In some examples, main memory 103 may include non-volatile memory, such as magnetic memory devices, optical memory devices, holographic memory devices, flash memory devices (e.g., NAND or NOR), phase change memory (PCM) devices, resistive random access memory (ReRAM) devices, magnetoresistive random access memory (MRAM) devices, ferroelectric random access memory (F-RAM), and any other type of non-volatile memory device. In other examples, main memory 103 may include volatile memory, such as random access memory (RAM), dynamic random access memory (DRAM), static RAM (SRAM), and synchronous dynamic RAM (SDRAM (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, etc.). Main memory 103 may also include both non-volatile memory and volatile memory, whether integrated together or as discrete units.

[0041] The host interface 106 is configured to interface the storage device 102 with the host 104 via a bus / network 108 and may use, for example, Ethernet or WiFi or a bus standard such as Serial Advanced Technology Attachment (SATA), PCI express (PCIe), Small Computer System Interface (SCSI), or Serial Attached SCSI (SAS), among other possible candidates. Alternatively, the host interface 106 may be wireless and may interface the storage device 102 with the host 104 using, for example, cellular communications (e.g., 5G NR, 4G LTE, 3G, 2G, GSM / UMTS, CDMA One / CDMA2000, etc.), wireless distribution methods through access points (IEEE 802.11, WiFi, HiperLAN, etc.), infrared (IR), Bluetooth, Zigbee, or other wireless wide area network (WWAN), wireless local area network (WLAN), wireless personal area network (WPAN) technology, or comparable wide area network, local area network, and personal area network technologies.

[0042] The storage device 102 includes a memory. For example, Figure 1 In an exemplary embodiment of the present invention, the storage device 102 may include a non-volatile memory (NVM) 110 for persistently storing data received from the host 104. The NVM 110 may include, for example, a flash memory integrated circuit, a NAND memory (e.g., a single-level cell (SLC) memory, a multi-level cell (MLC) memory, a triple-level cell (TLC) memory, a quad-level cell (QLC) memory, a quintuple-level cell (PLC) memory, or any combination thereof), or a NOR memory. The NVM 110 may include a plurality of memory locations 112 that may store system data for operating the storage device 102 or user data received from the host for storage in the storage device 102. For example, the NVM may have a cross-point architecture that includes a 2D NAND array having n rows and m columns of memory locations 112, where m and n are predefined according to the size of the NVM. Figure 1 In an exemplary embodiment, each memory location 112 can be a die 114 comprising a plurality of planes, each plane comprising a plurality of blocks of a plurality of cells 116. Alternatively, each memory location 112 can be a plane comprising a plurality of blocks of cells 116. Cells 116 can be, for example, single-level cells, multi-level cells, tri-level cells, quad-level cells, and / or penta-level cells. Other examples of memory locations 112 are possible; for example, each memory location can be a block or group of blocks. Each memory location can include one or more blocks in a 3-D NAND array. Each memory location 112 can include one or more logical blocks mapped to one or more physical blocks. Alternatively, the memory and each memory location can be implemented in other ways known to those skilled in the art.

[0043] The storage device 102 also includes a volatile memory 118, which may include, for example, dynamic random access memory (DRAM) or static random access memory (SRAM). The data stored in the volatile memory 118 may include data read from the NVM 110 or data to be written to the NVM 110. In this regard, the volatile memory 118 may include a write buffer or a read buffer for temporarily storing data. Although Figure 1 The volatile memory 118 is illustrated as being remote from the controller 123 of the storage device 102 , but the volatile memory 118 may be integrated into the controller 123 .

[0044] The memory (eg, NVM 110) is configured to store data 119 received from the host device 104. The data 119 may be stored in a cell 116 in any one of the memory locations 112. For example, Figure 1 The data 119 is illustrated as being stored in different memory locations 112, but the data may be stored in the same memory location. In another example, the memory locations 112 may be different dies, and the data may be stored in one or more of the different dies.

[0045] Each of the data 119 may be associated with a logical address. For example, the NVM 110 may store a logical-to-physical (L2P) mapping table 120 for the storage device 102 that associates each of the data 119 with a logical address. The L2P mapping table 120 stores a mapping of logical addresses specified for data written from the host 104 to physical addresses in the NVM 110 that indicate the location of each of the stored data. The mapping may be performed by a controller 123 of the storage device. The L2P mapping table may be a table or other data structure that includes an identifier, such as a logical block address (LBA), associated with each memory location 112 of the stored data in the NVM. Although Figure 1 A single L2P mapping table 120 is instantiated and stored in one of the NVM memory locations 112 to avoid undue ambiguity. Figure 1 Although the L2P mapping table 120 is not limited to the concept of L2P mapping, it can actually include multiple tables stored in one or more memory locations of the NVM.

[0046] Figure 2 is a conceptual diagram 200 of an example of an L2P mapping table 205 illustrating data 202 received from a host device to Figure 1 The data 202 may correspond to a mapping of logical addresses and physical addresses in the NVM 110. Figure 1 The data 119 in the L2P mapping table 205 may correspond to Figure 11 through page x, where x is the total number of pages of data being written to the NVM 110. Each page 204 can be associated with one or more entries 206 of an L2P mapping table 205 that identifies a logical block address (LBA) 208, a physical address 210 associated with the data being written to the NVM, and a length 212 of the data. The LBA 208 can be a logical address specified in a write command for data received from a host device. The physical address 210 can indicate the block and offset where the data associated with the LBA 208 is physically written. The length 212 can indicate the size of the written data (e.g., 4KB or other size).

[0047] Re-reference Figure 1 Volatile memory 118 also stores a cache 122 for storage device 102. Cache 122 includes entries that show a mapping of a logical address specified for data requested by host 104 to a physical address in NVM 110, indicating where the data is stored. This mapping may be performed by controller 123. When controller 123 receives a read command or a write command for data 119, it checks cache 122 to obtain a logical-to-physical mapping for each data item. If no mapping exists (e.g., if this is the first request for the data), the controller accesses L2P mapping table 120 and stores the mapping in cache 122. When controller 123 executes a read command or a write command, it accesses the mapping from the cache and reads or writes the data from or to NVM 110 at the specified physical address. The cache may be stored in the form of a table or other data structure that includes a logical address associated with each memory location 112 in the NVM for which data is being read.

[0048] NVM 110 includes a sense amplifier 124 and a data latch 126 connected to each memory location 112. For example, memory location 112 can be a block including cells 116 on multiple bit lines, and NVM 110 can include a sense amplifier 124 on each bit line. In addition, one or more data latches 126 can be connected to the bit lines and / or the sense amplifiers. The data latch can be, for example, a shift register. When data is read from cell 116 of memory location 112, sense amplifier 124 senses the data by amplifying the voltage on the bit line to a logic level (e.g., readable as "0" or "1"), and the sensed data is stored in data latch 126. The data is then transmitted from data latch 126 to controller 123, after which the data is stored in volatile memory 118 until it is transmitted to host device 104. When data is written to cell 116 of memory location 112 , controller 123 stores the program data in data latches 126 and then transfers the data from data latches 126 to cell 116 .

[0049] The storage device 102 includes a controller 123, which includes circuitry such as one or more processors for executing instructions and may include a microcontroller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), hardwired logic, analog circuitry, and / or combinations thereof.

[0050] Controller 123 is configured to receive data transmitted from one or more cells 116 of various memory locations 112 in response to a read command. For example, controller 123 can read data 119 by activating sense amplifier 124 to sense data from cell 116 into data latch 126, and controller 123 can receive data from data latch 126. Controller 123 is also configured to program data into one or more of cells 116 in response to a write command. For example, controller 123 can write data 119 by sending data to data latch 126 to be programmed into cell 116. Controller 123 is further configured to access L2P mapping table 120 in NVM 110 when reading or writing data to cell 116. For example, controller 123 may receive a logical-to-physical address mapping from NVM 110 in response to a read or write command from host device 104, identify a physical address mapped to the logical address identified in the command (e.g., convert the logical address to a physical address), and access or store data in cell 116 located at the mapped physical address.

[0051] The controller 123 and its components may be implemented using embedded software that performs the various functions of the controller described throughout this disclosure. Alternatively, the software for implementing each of the aforementioned functions and components may be stored in NVM 110 or in a memory external to storage device 102 or host device 104 and accessed by controller 123 for execution by one or more processors of controller 123. Alternatively, the functions and components of the controller may be implemented using hardware in controller 123, or may be implemented using a combination of the aforementioned hardware and software.

[0052] In operation, host device 104 stores data in storage device 102 by sending a write command to storage device 102 specifying one or more logical addresses (e.g., LBAs) and the length of the data to be written. Interface element 106 receives the write command, and the controller allocates a memory location 112 in NVM 110 of storage device 102 for storing the data. Controller 123 stores an L2P map in NVM (and cache 122) to map the logical address associated with the data to the physical address of the memory location 112 allocated for the data. The controller also stores the length of the L2P map data. Controller 123 then stores the data in memory location 112 by sending the data to one or more data latches 126 connected to the allocated memory location, from which the data is programmed into cell 116.

[0053] The host 104 can retrieve data from the storage device 102 by sending a read command that specifies one or more logical addresses associated with the data to be retrieved from the storage device 102 and the length of the data to be read. The interface 106 receives the read command, and the controller 123 accesses the L2P map in the cache 122 or otherwise accesses the NVM to convert the logical address specified in the read command into a physical address indicating the location of the data. The controller 123 then reads the requested data from the memory location 112 specified by the physical address by sensing the data using the sense amplifier 124 and storing the data in the data latch 126 until the read data is returned to the host 104 via the host interface 106.

[0054] Figure 3 An example of a NAND memory array 300 is shown with cell 302. Cell 302 may correspond to Figure 11. Cells 302 are coupled to word lines 304 and bit lines 306 within a block of die 114 of NVM 110. For example, memory array 300 may include n word lines and m bit lines within a block of die 114 of NVM 110, where n and m are predefined based on the size of the block. Each word line and bit line may be associated with a row address and a column address, respectively, which controller 123 may use to select a particular word line and bit line (e.g., using a row decoder and a column decoder). For example, word lines 0-n may each be associated with their own row address (e.g., word line 0 may correspond to word line address 0, word line 1 may correspond to word line address 1, and so on), and bit lines 0-m may each be associated with their own column address (e.g., bit line 0 may correspond to bit line address 0, bit line 1 may correspond to bit line address 1, and so on). A select gate source (SGS) cell 308 and a select gate drain (SGD) cell 310 are coupled to the memory cell 302 on each bit line 306. The SGS cell 308 and the SGD cell 310 connect the memory cell 302 to a source line 312 (e.g., ground) and the bit line 306, respectively. A string 314 may include a group of cells 302 (including the SGS cell and the SGD cells 308, 310) coupled to one bit line within a block, while a page 316 may include a group of cells 302 coupled to one word line within a block.

[0055] Figure 4 An example of a NAND memory array 400 is depicted that includes a block 402 of multiple strings 404. The block 402 may correspond to Figure 1 The blocks of NVM 110 in die 114, and strings 404 may each correspond to Figure 3 String 314 in. Figure 3 As in the memory array 300 of FIG. 4 , each string 404 may include a group of memory cells, each memory cell coupled to a bit line 406 and individually coupled to a corresponding word line 408. Similarly, each string may include an SGS cell 410 and an SGD cell 412, which connect the memory cells in each string 404 to a source line 414 and a bit line 406, respectively.

[0056] When the controller 123 reads data from or writes data to the page 316 of the cell 302 (i.e., on word lines 304, 408), the controller may send a command to apply a read voltage or a program voltage to the selected word line and a pass voltage to the other word lines. The read or program state of the cell (e.g., a logic "0" or a logic "1" for SLC) may then be determined based on the threshold voltage of the cell 302. For example, during an SLC read operation, if the threshold voltage of the cell 302 is less than the read voltage (i.e., current flows through the cell in response to the read voltage), the controller 123 may determine that the cell stores a logic "1," whereas if the threshold voltage of the cell 302 is greater than the read voltage (i.e., current does not flow through the cell in response to the read voltage), the controller 123 may determine that the cell stores a logic "0." Similarly, during an SLC program operation, the controller may store a logic “0” by sending a command to apply a program voltage to the cell 302 on the word lines 304, 408 until the cell reaches a threshold voltage, and during an erase operation, the controller may send a command to apply an erase voltage to the block 402 including the cell 302 (e.g., to the cell's substrate, such as a p-well) until the cell drops back below the threshold voltage (back to a logic “1”).

[0057] Figure 5 is a conceptual diagram 500 of an example of a garbage collection process in which data stored in page 504 of block 502 of an SLC cell is relocated to page 508 of block 506 of a QLC cell. The data may correspond to Figure 1 Data 119, blocks 502, 506 may correspond to Figure 4 402, and the SLC / QLC unit may correspond to Figure 1 and Figure 3 Each page 504, 508 includes data stored in multiple cells along the same row or word line of the NVM (e.g., word lines 304, 408). Thus, each page 504 may include data stored in a row of cells 116 of one block, while each page 508 may include data stored in a row of cells 116 of another block. To simplify the description, Figure 5 The example of FIG. 5 shows blocks 502, 506, each of which includes only four pages 504, 508. However, it should be appreciated that each block may include any number of pages.

[0058] exist Figure 5In the example of FIG, data represented by identifiers A, B, and C are stored in different pages 504 of block 502. In this example, initially, in response to a write command from a host device, data A, B, and C are stored in three pages of block 502, leaving one page free. When the storage device receives new or updated data, the data is stored in free page 510. For example, updated data A′ may be received from the host device and written to free page 510. Because data cannot be overwritten in flash memory, invalid data A remains stored in block 502. Due to the presence of new and invalid data, block 502 may quickly become full.

[0059] To free up space in the SLC block, the original data and updated data in block 502 can be transferred to block 506. Invalid data remains in the old block. Figure 5 In the example shown in FIG5 , the original data B and C and the updated data A′ are read from page 504 of block 502 and written to one or more pages 508 of block 506. The invalid data A remains in block 502. When block 502 is subsequently erased, the invalid data is discarded and block 502 can be reused to store new data.

[0060] However, such GC processes may cause increased write amplification of storage device 102, for example, where multiple 4KB data overwrites occur. To reduce or eliminate GC and thereby lower the storage device's write amplification, storage device 102 may implement ZNS, where groups of consecutive, non-overlapping logical addresses are divided into zones. Figure 6 A conceptual diagram 600 illustrates an example of zones 602. Each zone 602 is of fixed size and includes a contiguous range of consecutive logical addresses 604 in NVM 110. For example, as shown, NVM 110 may include a total of z LBAs divided into x zones, where each zone includes a series of nm consecutive LBAs, where z represents the total number of sectors in the flash memory, x represents the number of zones, m represents the first LBA in the zone, and n represents the last LBA in the same zone. Each zone can be used solely by the host to store data associated with one or more applications run by the host. Thus, host 104 can divide the LBAs into zones based on the number of applications run by the host.

[0061] Figure 7 An exemplary diagram 700 is shown of a controller 702 of a storage device that writes data 704 received from a host device 706 to a block 708 of a die 710 according to a zone 712. For example, the controller 702 may correspond to Figure 1 The controller 123 of the storage device 102 in the host device 706 may correspond to Figure 1 In the host 104, block 708 may correspond to Figure 4Of block 402, data 704 may correspond to Figure 1 The data 119, and area 712 may correspond to Figure 6 Zone 602. Conventionally, the host 706 may define the zone 712 (e.g., Figure 6 The L2P mapping table 714 (e.g., L2P mapping tables 120, 205) is sent to the controller 702, and the controller can create an L2P mapping table 714 (e.g., L2P mapping tables 120, 205) that maps the LBAs (e.g., logical addresses 604) of each zone 712 to a single physical block (e.g., block 402). Figure 7 In the example shown, assume that each zone spans 64MB and has a 512-byte sector size, so each zone may include 125,000 LBAs. Furthermore, assume that each block is capable of storing 64MB of data. Thus, zone 0 may be mapped to only one block (e.g., PBA 0), zone 1 may be mapped to only another block (e.g., PBA 1), and so on. Each application of the host may then write data to the corresponding zone, for example, by indicating a contiguous range of LBAs to the controller. For example, host 706 may send a write command to controller 702 to sequentially write data from LBA 0 to LBA 124999 and / or from LBA 125000 to 249999. The controller may translate the indicated LBAs into mapped physical addresses (e.g., PBA 0 or 1, respectively) and write the data to mapped blocks 708 accordingly. Thus, the host may write data from different applications to different physical blocks corresponding to different zones.

[0062] The main advantage of ZNS is that the host cannot Figure 5 Data is written and invalidated page by page (e.g., between 4KB commands) as described in . For example, when writing data to Figure 6 When writing to zone 1 in a zone, the host cannot simply write data to LBAm and then immediately write new data to LBAm while invalidating the old data at LBAm. Instead, the entire zone must be completely written (i.e., writing LBAm to LBAn-1 in one or more writes) before data can be written again to the previous LBA in that zone. Figure 7 In the example of , if the host writes data to LBA 0, the host must first continue writing data sequentially from LBA 1 to LBA 124999 (in one or more writes at various times) before the host can finally write the new data back to LBA 0. This feature of ZNS prevents blocks mapped to various extents from including partially invalid data that will require GC (such as Figure 5 ), thus reducing or eliminating GC and improving write amplification.

[0063] However, conventional implementations of ZNS can also have several disadvantages. First, ZNS can result in a greater number of open blocks (which tend to have worse data retention (DR) characteristics than closed blocks) in storage device 102 compared to implementations without ZNS. Typically, without ZNS, controller 123 maintains one or two open blocks across NVM 110. In contrast, when extents are mapped to separate physical blocks in ZNS, controller 123 may maintain at least one open block for each extent in NVM 110. Consequently, when the number of extents is large (for example, if a host has many applications, each corresponding to a extent), the number of open blocks can also be large, resulting in significantly worse overall DR for the storage device. Second, while extent sizes remain fixed in ZNS, block sizes tend to scale or increase over time. Such scaling can result in additional unused storage space when mapping fixed-size extents to separate physical blocks. Allocating this additional space to another extent negates the benefits of ZNS, as garbage collection (GC) is likely required in this scenario. For example, if one extent is fully written to a scaled block (and therefore can be invalidated) while another extent is only partially written to the remainder of the scaled block (and therefore cannot be invalidated), a GC will still be needed to protect the valid data. Third, when a host has many applications that each require one or more extents to store data in a ZNS, but the number of blocks available in the storage device is limited, an out-of-extent condition can occur when extents are mapped to separate physical blocks. Such a condition can be inefficient, especially if one or more of the host's applications do not even require the entire block to be available for the data (e.g., the applications only write a small amount of data to each block).

[0064] To alleviate these limitations of ZNS, the controller can map zones to sub-blocks rather than individual blocks. In 3-D NAND devices, wordline groups can be divided into different sub-blocks. For example, the stack of lower wordlines in one memory well layer can be separated from the stack of upper wordlines in another memory well layer by one or more dummy wordlines and / or crossover regions. Thus, assuming there are 128 wordlines in a block, the stack of lower wordlines (e.g., WL 0-63) can be considered one sub-block, and the stack of upper wordlines (e.g., WL 64-127) can be considered another sub-block. The sub-block structure allows the wordlines within each sub-block to be independently read or programmed, and allows the sub-blocks to be independently erased. The controller can perform such independent read / program / erase operations in different sub-blocks in response to a sub-block mode (SBM) enable command sent by the controller to the NAND. For example, the controller can send a command to activate SBM to the die, in response to which different voltages can be applied to the wordlines in different sub-blocks of the die to perform simultaneous read and program operations or independent erase operations. For example, to simultaneously read or write data in different sub-blocks, the controller may apply a read or program voltage to a selected word line in a sub-block and a pass voltage to unselected word lines in the sub-block when SBM is enabled. Similarly, the controller may independently erase different sub-blocks by applying a low voltage to a word line in a selected sub-block and a high voltage to word lines in unselected sub-blocks when SBM is enabled.

[0065] Figure 8 An exemplary diagram 800 is shown of a controller 802 of a storage device that writes data 804 received from a host device 806 to sub-blocks 808 of different blocks 810 of a die 812 according to zones 814. For example, the controller 802 may correspond to Figure 1 The controller 123 of the storage device 102 in the host device 806 may correspond to Figure 1 In the host device 104, block 810 may correspond to Figure 4 Of block 402, data 804 may correspond to Figure 1 The data 119, and area 814 may correspond to Figure 6808. Each block 810 may include n word lines (e.g., 128 word lines or another number n) divided into different sub-blocks 808 as described above. For example, half of the block's word lines (e.g., the lower word line stack from WL 0 to WL n / 2-1) may be included in one sub-block, while the other half of the block's word lines (e.g., the upper word line stack from WL n / 2 to WL n-1) may be included in another sub-block, where n is the number of word lines in the block. The controller 802 may read, program, and erase data in the sub-blocks 808 in response to SBM commands 816 generated by the controller and sent to the die 812 for execution. For example, when the die 812 receives the SBM commands 816, circuitry in the die may be activated or enabled to allow different voltages to be applied to the word lines in different sub-blocks to perform simultaneous reading and programming or independent erasure. The controller 802 may issue the SBM commands 816 in response to receiving the definition of the block 814 from the host 806. The controller may also issue an SBM command in response to receiving a request 818 from the host 806 to enable SBM.

[0066] In operation, the host 806 may send the definition of the zones 814 to the controller 802, which indicates to the controller that data will be written to the zones in the ZNS. The controller may then determine whether the number of open zones in the storage device is greater than or equal to an open zone threshold (e.g., 10 or some other predefined number). For example, the controller may check whether the host plans to write data to more than 10 zones, which would typically require at least 10 open blocks. If the number of open zones is less than the threshold (e.g., there is an acceptable number of open blocks that would result from mapping the zones to separate blocks, such as a total of nine blocks or less), the controller may map the LBAs of each zone 814 to a single physical block, as described above in Figure 7 Otherwise, if the number of open zones meets the threshold, the controller may map the LBAs of each zone 814 to a sub-block 808 as described below with respect to Figures 9 to 11 As described in any of the figures in

[15] ,

[16] ,

[17] ,

[18] ,

[19] ,

[20] ,

[21] ,

[22] ,

[23] ,

[24] ,

[25] ,

[26] ,

[27] ,

[28] ,

[29] ,

[30] ,

[31] ,

[32] ,

[33] ,

[34] ,

[35] ,

[36] ,

[37] ,

[38] ,

[39] ,

[40] ,

[41] ,

[42] ,

[43] ,

[44] ,

[45] ,

[46] ,

[47] ,

[48] ,

[49] ,

[50] ,

[51] ,

[52] ,

[53] ,

[54] ,

[55] ,

[56] ,

[57] ,

[58] ,

[59] ,

[60] ,

[61] ,

[62] ,

[63] ,

[64] ,

[65] ,

[66] ,

[70] ,

[71] ,

[72] ,

[73] ,

[74] ,

[75] ,

[76] ,

[77] ,

[78] ,

[79] ,

[80] ,

[81] ,

[82] ,

[83] ,

[84] ,

[85] ,

[86] ,

[87] ,

[88] ,

[89] ,

[90] ,

[91] ,

[92] ,

[93] ,

[94] ,

[95] ,

[96] ,

[97] ,

[98] ,

[99] ,

[100]

[0067] For example, if the number of open blocks resulting from a single block mapping would be too large and thus cause significant DR issues, the controller 802 may map each region to two sub-blocks 808 in different blocks 810 to reduce the number of open blocks. Figure 9 9 shows an example of an L2P mapping table 900 that a controller may create that maps each zone to two sub-blocks 904 in different blocks 902. Figure 9 In the example of , each zone spans 64MB in size and has a 512-byte sector size, so each zone can include 125,000 LBAs. In addition, each block can store 64MB of data, so each sub-block can store 32MB of data. Therefore, instead of Figure 7 , where the controller maps the first half of each zone (32MB of data) to a sub-block in one block and the second half of each zone (32MB of data) to a sub-block in another block. For example, the controller may map LBAs 0-62499 (the first half of zone 0) to sub-block 0 of block 0, the controller may map LBAs 62500-124999 (the second half of zone 0) to sub-block 0 of block 1, the controller may map LBAs 125000-187499 (the first half of zone 1) to sub-block 1 of block 0, and the controller may map LBAs 187500-249999 (the second half of zone 1) to sub-block 1 of block 1. Thus, when the host sequentially writes data to zones 0 and 1 starting from the first LBA of each zone, only block 0 is initially written. Thus, the controller will only begin writing to block 1 after the first half of zones 0 and 1 are filled and block 0 is completely written (i.e., block 0 becomes a closed block). This approach reduces the total number of open blocks that will be generated, e.g., by half. For example, even if zones 0 and 1 are half filled, only one block (block 1) will be open, rather than two blocks (both blocks 0 and 1). Figure 7 This is the case in the example above).

[0068] In another example, if the block is subsequently doubled in size due to scaling such that one sub-block now spans the extent size (instead of spanning the block as before), the controller may map the extent to one sub-block to accommodate the scaling and still maintain GC reduction or elimination. Figure 10 1000 shows an example of an L2P mapping table 1000 that a controller may create that maps each zone to a sub-block 1004 in a different block 1002. Figure 10 In the example of , each zone spans 64MB in size and has a 512-byte sector size, so each zone can include 125,000 LBAs. In addition, the size of each block has increased due to scaling, so that each block can now store 128MB of data, so each sub-block can store 64MB of data. Therefore, instead of Figure 9 As shown in , the controller maps half of each zone (62500 LBAs) to each sub-block, where the controller maps each zone to each sub-block of twice the size. For example, the controller can use the same method as described above with respect to Figure 9 Similar sub-block mapping as described maps LBAs 0-62499 (the first half of zone 0) and LBAs 62500-124999 (the second half of zone 0) to sub-block 0 of block 0. This way, even when the block doubles in size due to scaling, unused space in each block of the ZNS is avoided by mapping the entire zone to sub-blocks. This approach also maintains the reduction or elimination of GCs because sub-blocks can be erased independently even when the number of word lines in a block has increased.

[0069] In another example, if the controller receives an indication from the host (e.g., in SBM request 818) that zones will not be completely written (e.g., the application will only write a small amount of data to those zones), the controller may map those zones to separate sub-blocks to prevent a zone out condition. Figure 11 100 shows an example of an L2P mapping table 1100 that a controller may create to map two regions to one sub-block 1004 in the same block 1102. Figure 11 In the example of , each zone spans 64MB in size and has a 512-byte sector size, so each zone can include 125,000 LBAs. In addition, each block can store 64MB of data, so each sub-block can store 32MB of data. Therefore, instead of Figure 9 , where the controller maps half of each zone to a sub-block based on an indication that the other half of each zone will not be used (no data will be stored in those LBAs). For example, the controller may use the same method as described above with respect to Figure 9 A similar sub-block mapping as described maps LBAs 0-62499 (first half of zone 0) to sub-block 0 of block 0 and LBAs 125000-187499 (first half of zone 1) to sub-block 1 of block 0. However, unlike Figure 9 Unlike the example in , the controller may not map LBA 62500-124999 (the second half of zone 0) and LBA 187500-249999 (the second half of zone 1) to block 1 because these areas are indicated by the host as unused. Instead, block 1 may be mapped to other zones. This effectively increases the number of zones in the storage device. For example, instead of Figure 9In the example described in , where the sub-blocks in blocks 0 and 1 are mapped to zones 0 and 1, the controller may only map the sub-blocks in block 0 to zones 0 and 1 because half of each zone will not be written, thereby allowing the controller to map block 1 to the other two half-written zones. Thus, in response to an indication from the host (e.g., in a request to activate SBM or in some other message) that its application will only store small amounts of data in various zones, the controller may make more blocks available for mapping to additional zones.

[0070] Figure 12 An exemplary flow chart 1200 is shown for a method for writing data to a zone based on a sub-block map. For example, the method may be performed on a storage device 102 such as Figure 1 Each of the steps in the flowchart may be controlled using a controller (eg, controller 123, 802) as described below or by some other suitable means.

[0071] As represented by block 1202, the controller may receive data from the host to be written into a zone (e.g., into a ZNS). The zone may include multiple logical addresses. For example, referring to Figures 6 to 8 , the controller 702, 802 may receive data 704, 804 from the host device 706, 806 to be written to the area 602, 712, 814. The area 602 may include multiple logical addresses 604. The controller 702, 802 may receive an association of the area 602 with the logical address 604 from the host 706, 806. For example, the controller may receive a message such as Figure 6 The mapping of regions to logical addresses is shown.

[0072] As represented by block 1204, the controller may determine whether the number of open regions satisfies an open region threshold. If the number of open regions satisfies the open region threshold, then as represented by block 1206, the controller may enable sub-block mode (SBM) and map the region to a sub-block of memory, e.g., as described above with respect to Figures 8 to 11 Otherwise, if the number of open regions does not satisfy the open region threshold, the controller may map the regions to blocks, e.g., as described above with respect to Figure 7 described.

[0073] For example, reference Figure 1 and Figures 6 to 11 , a memory (e.g., NVM 110) may include a plurality of blocks 708, 810, 902, 1002, 1102, wherein each of these blocks includes a plurality of sub-blocks 808, 904, 1004, 1104, and the controller 123, 802 may map the region 602 to at least one of these sub-blocks. Each of these sub-blocks may be independently read, programmed, and erased, e.g., as described above with respect to Figure 8The controller may determine a number of open regions (e.g., the number of regions 602 that are open or correspond to open blocks) and map the open regions to at least one of the sub-blocks in response to the number of open regions satisfying a threshold (e.g., an open region threshold such as 10 or some other number).

[0074] In one example, the region may be mapped to two of the sub-blocks, the two sub-blocks of the sub-blocks being from different blocks. In this example, each of the different blocks may include another sub-block mapped to a different region. For example, referring to Figure 9 , region 0 may be mapped to subblock 0 in block 0 and subblock 0 in block 1. Furthermore, each of these blocks (e.g., blocks 0 and 1) may include another subblock (e.g., subblock 1) mapped to a different region (e.g., region 1).

[0075] In another example, the zone may be mapped to one of the subblocks in response to an indication from the host that the zone is partially unused, the one of the subblocks being located in one of the blocks. In this example, the one of the blocks may include another subblock mapped to a different zone. For example, referring to Figure 11 , zone 0 may be mapped to sub-block 0 in block 0 in response to an indication from the host 806 that zone 0 will not be completely written. Furthermore, block 0 may include another sub-block (e.g., sub-block 1) that is mapped to a different zone (e.g., zone 1). The controller may receive a request (e.g., SBM request 818) to write data 804 associated with zone 814 to sub-blocks 808 and, in response to the request, map each of the zones to at least one of the sub-blocks. The request may include an indication from the host that the zone is partially unused.

[0076] Finally, the controller may determine whether all zones have been written with data from the host, as represented by block 1208. If not, the controller writes the data to one zone (mapped to sub-blocks or blocks as described above at 1204) and repeats the above process for each zone. Otherwise, if all zones have been written with data, the process ends.

[0077] Thus, the storage device described in the present disclosure can alleviate the limitations of ZNS, including a large number of open blocks with poor DR, inflexibility with increasing block sizes, and limited available zones. By allowing each zone to be mapped to two sub-blocks in different blocks, a smaller number of open blocks can be generated in the storage device compared to traditional ZNS, resulting in higher data reliability. In addition, in the event that less data for a particular application is programmed and the storage device runs out of zones, mapping each zone to a sub-block can effectively increase the number of zones during runtime. Furthermore, even when the block size of the storage device is scaled or increased, the beneficial effects of ZNS in reducing GC and write amplification can be maintained because the mismatch between zone capacity and block size can be avoided due to sub-block mapping and the full block capacity can continue to be used.

[0078] The various aspects of this disclosure are provided to enable one of ordinary skill in the art to practice the invention. Various modifications to the exemplary embodiments presented throughout this disclosure will be apparent to one of ordinary skill in the art, and the concepts disclosed herein may be extended to other magnetic storage devices. Therefore, the claims are not intended to be limited to the various aspects of this disclosure, but are intended to be given the full scope consistent with the language of the claims. All structural equivalents and functional equivalents of the various components of the exemplary embodiments described throughout this disclosure that are already known or later known to one of ordinary skill in the art are expressly incorporated herein by reference and are intended to be covered by the claims. In addition, regardless of whether this disclosure is explicitly recited in the claims, the content disclosed herein is not intended to be contributed to the general public. No claim element will be interpreted under the provisions of 35 USC § 112, sixth paragraph, of the United States, or similar statutes or rules of law in another jurisdiction, unless the phrase "means for..." is used to expressly recite the element, or in the case of a method claim, the phrase "step for..." is used to recite the element.

Claims

1. A storage device, comprising: a memory comprising a plurality of blocks, wherein each of the blocks comprises a plurality of sub-blocks; and a controller configured to map a region to at least one of the sub-blocks, wherein the region includes a plurality of logical addresses; The controller is further configured to determine a number of open areas, and map the open areas to the at least one sub-block among the sub-blocks in response to the number of the open areas satisfying a threshold. 2 . The memory device of claim 1 , wherein each of the sub-blocks is independently programmable and erasable. 3 . The storage device of claim 1 , wherein the controller is further configured to receive an association of the region with the logical address from a host. 4 . The storage device of claim 1 , wherein the region is mapped to two of the sub-blocks, the two of the sub-blocks being from different blocks. The storage device of claim 4 , wherein each of the different blocks includes another sub-block mapped to a different zone. 6 . The storage device of claim 1 , wherein the region is mapped to one of the sub-blocks in response to an indication from a host that the region is partially unused, the one of the sub-blocks being located in one of the blocks. 7 . The storage device of claim 6 , wherein the one of the blocks includes another sub-block mapped to a different zone.

8. A storage device, comprising: a memory comprising a plurality of blocks, wherein each of the blocks comprises a plurality of sub-blocks; and A controller is configured to determine a number of open areas and map the open areas to the sub-blocks in response to the number of open areas satisfying a threshold.

9. The memory device of claim 8, wherein each of the sub-blocks is independently readable and programmable.

10. The storage device of claim 8, wherein the controller is further configured to receive, from a host, an association of each of the open areas with a plurality of logical addresses. 11 . The storage device of claim 8 , wherein each of the open areas is mapped to two of the sub-blocks, the two of the sub-blocks being from different blocks.

12. The storage device of claim 8, wherein each of the open areas is mapped to one of the sub-blocks in response to an indication from a host that the open area will not be completely written.

13. A storage device, comprising: a memory comprising a plurality of blocks, wherein each of the blocks comprises a plurality of sub-blocks; and a controller configured to receive a request to write data associated with a zone into the sub-blocks and, in response to the request, map each zone in the zone to at least one sub-block in the sub-blocks; The controller is further configured to determine a number of the regions that are open, and map the regions to the sub-blocks in response to the number of the regions that are open satisfying a threshold. The memory device of claim 13 , wherein each of the sub-blocks is independently readable and erasable.

15. The storage device of claim 13, wherein the controller is further configured to receive from a host an association of each of the zones with a plurality of logical addresses. 16 . The storage device of claim 13 , wherein each of the zones is mapped to two of the sub-blocks, the two of the sub-blocks being from different blocks.

17. The storage device of claim 13, wherein the request includes an indication from a host that the zone is partially unused.

18. The storage device of claim 17, wherein each of the zones is mapped to one of the sub-blocks in response to the indication.

Images