Zone-based garbage collection in ZNS SSD

Abstract

Aspects of a storage device, including a region-based GC in a ZNS, are provided. The storage device includes an NVM and a controller. The NVM includes a first block, a second block, and a third block. The controller creates a first hyper-block including the first block, a second hyper-block including the second block, and a third hyper-block including the third block. The controller allocates a first sub-driver including the first super block for storing data rewrites and a second sub-driver including the second super block and the third super block for storing contiguous data in the NVM. During GC of superblocks respectively including data of a particular region, the controller repositions write data of the region from the first superblock and the third superblock to the second superblock while avoiding repositioning data associated with other regions from the first superblock to the second superblock. Accordingly, storage device cost, overconfiguration, and WAF may be reduced.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. non-provisional application No. 18 / 349,088, filed with the U.S. Patent and Trademark Office on July 7, 2023, entitled “Zone-Based Garbage Collection in ZNS SSDs,” and is incorporated herein by reference in its entirety for all purposes, which U.S. non-provisional application claims priority to U.S. Provisional Application No. 63 / 383,232, filed on November 10, 2022. Background Art Technical Field

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

[0004] introduction

[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 may 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, etc.

[0006] Zoned Namespace (ZNS) is an SSD namespace architecture in which a range of logical addresses in non-volatile memory (e.g., a zoned namespace) is divided into fixed-size groups of logical addresses or zones. Each zone within a zoned namespace can be used for a specific application. For example, a host can write data associated with different applications to different zones in a zoned namespace. Summary of the invention

[0007] An aspect of a storage device is disclosed herein. The storage device includes a non-volatile memory, the non-volatile memory including a plurality of first blocks and a plurality of second blocks. The storage device also includes a controller, the controller being configured to create a first super block including the first block and a second super block including the second block; and during garbage collection of a plurality of super blocks including data associated with a first zone, relocating first data associated with the first zone from the first super block to the second super block, the first zone including a first range of logical addresses. The controller is further configured to avoid relocating second data associated with a second zone from the first super block to the second super block during the garbage collection, the second zone including a second range of logical addresses different from the first range of logical addresses.

[0008] Another aspect of a storage device is disclosed herein. The storage device includes a nonvolatile memory including a plurality of first blocks and a plurality of second blocks. The storage device also includes a controller configured to create a first super block including the first block and a second super block including the second block; and write first data associated with a first zone to the first super block, and write second data associated with a second zone to the first super block, the first zone including a first range of logical addresses, and the second zone including a second range of logical addresses. The controller is further configured to add the first super block to a super block list that includes data associated with the first zone respectively; during garbage collection of multiple super blocks in the super block list, relocate the first data from the first super block to the second super block; and during the garbage collection, avoid relocating the second data from the first super block to the second super block.

[0009] Another aspect of a storage device is disclosed herein. The storage device includes a nonvolatile memory, the nonvolatile memory including a plurality of first blocks, a plurality of second blocks, and a plurality of third blocks. The storage device also includes a controller configured to create a first super block including the first block, a second super block including the second block, and a third super block including the third block; and a first sub-driver and a second sub-driver are allocated in the nonvolatile memory, the first sub-driver including a first plurality of super blocks for storing data rewrites, and the second sub-driver including a second plurality of super blocks for storing continuous data. The first plurality of super blocks includes the first super block, and the second plurality of super blocks includes the second super block and the third super block. The controller is further configured to write first data associated with a first zone to the first super block, write second data associated with a second zone to the first super block, and write third data associated with the first zone to the third super block, the first zone including a first range of logical addresses, and the second zone including a second range of logical addresses. The controller is also configured to, during garbage collection of multiple super blocks that respectively include data associated with the first zone, relocate the first data from the first super block to the second super block, and relocate the third data from the third super block to the second super block; and during the garbage collection, avoid relocating the second data associated with the second zone from the first super block to the second super block.

[0010] It will be appreciated 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 illustrated and described by way of illustration. As will be appreciated, these aspects may be implemented in other different forms, and several details thereof may be modified in various other aspects. Therefore, the drawings and detailed description are to be considered illustrative rather than restrictive in nature. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] 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:

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

[0013] Figure 2 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.

[0014] Figure 3 is an example Figure 1 A conceptual diagram of an example of a storage device in FIG.

[0015] Figure 4 is an example of Figure 1 A conceptual diagram of an example of a zone random write area (ZRWA) associated with a corresponding zone in a storage device.

[0016] Figure 5 is exemplified in Figure 1 A conceptual diagram of an example of zone-based garbage collection in superblocks allocated in different sub-drives of a non-volatile memory in a storage device.

[0017] Figure 6 is an example such as Figure 1 A flowchart of an example of a method for performing region-based garbage collection performed by a storage device.

[0018] Figure 7 is an example as Figure 1 A flowchart of an example of another method for performing region-based garbage collection performed by a storage device.

[0019] Figure 8 is exemplified in Figure 1 A conceptual diagram of an example of a controller that performs zone-based garbage collection in a storage device. DETAILED DESCRIPTION

[0020] The specific embodiments described below in conjunction with the accompanying drawings are intended to be a description of various exemplary embodiments of the present invention, and are not intended to represent the only embodiment that can practice the present invention. In order to provide a thorough understanding of the present invention, the specific embodiments include specific details. 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 the form of block diagrams to avoid making the concept of the present invention obscure. 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.

[0021] 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 components, structures, features, functions, processes, advantages, benefits, or modes of operation.

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

[0023] In the following detailed description, various aspects of a storage device that communicates with a host device will be presented. These aspects are well suited for flash 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 a specific device or method 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 the present disclosure.

[0024] In a zoned namespace (ZNS) architecture, a flash storage device may determine definitions of zones or logical address groups for data storage. For example, a flash storage device may determine that a set of logical pages or a logical block is associated with a first zone, another set of logical pages or another logical block is associated with a second zone, and so on. The flash storage device may then map each logical block to one or more physical blocks in the flash memory. For example, the flash storage device may map logical pages associated with a first zone to physical pages in a first set of physical blocks, map logical pages associated with a second zone to physical pages in a second set of physical blocks, and so on. The flash storage device may maintain these mappings of logical pages to physical pages in the flash memory in a logical-to-physical (L2P) mapping table in a volatile memory (e.g., a dynamic random access memory (DRAM) or a static random access memory (SRAM)).

[0025] In ZNS, host data is written to zones strictly sequentially. For example, each time the host issues a zone write command in which the host sends data to the flash storage device to be written to a logical page of flash memory located at a given logical address, the flash storage device moves the write pointer to the next logical address in the zone, and when a subsequent zone write command is issued, the host is expected to send data for the next logical page. If the host does not follow this order (for example, if the next write command from the host includes logical addresses that are out of order in sequence, such as the same logical address in the attempted data overwrite), the flash storage device may issue an error and abort the zone write. Therefore, the host is generally unable to overwrite data at a given logical address in a zone until after the zone is completely written.

[0026] However, ZNS may be extended to support rewriting of data within a zone random write area (ZRWA) associated with the zone in a zone. For example, a host may send a zone open command to open a zone in ZRWA mode, and the mode may remain associated with the zone until the zone is completed. For a zone opened in ZRWA mode, the flash storage device may define a predefined zone size (e.g., 1MB) including a sub-range of logical addresses in the zone, which the flash storage device may expose to the host for rewriting. In response to a commit operation from the host or the flash storage device, the flash storage device may move the predefined zone size (ZRWA window) to the next sub-range of logical addresses in the zone.

[0027] The flash storage device may create super blocks from erase block groups or combinations within the non-volatile memory, respectively. These super blocks are configured to be exactly the same size as the zone. For example, if the zone size includes X MB of data, the super block may similarly store only X MB of data. However, when data rewrites occur in ZRWA mode, the host may have written more than X MB of data in a given zone, and this additional data may not be stored in the super block. Therefore, the flash storage device may write data to different super blocks in the non-volatile memory.

[0028] As an example, when a host issues a zone write command including contiguous data or random data of a logical page to a zone supporting ZRWA, the flash storage device may initially store the logical page in a super block allocated for the initial write to the zone in the non-volatile memory, and the flash storage device may move the write pointer to the next logical address within the ZRWA window in the zone. The flash storage device may also create an associated L2P entry in the L2P mapping table for the zone data for the initial write. If the host issues a zone write command indicating the same logical address as a previously issued zone write command (e.g., data rewrite) within the ZRWA window, the flash storage device may store the next logical page in a default super block allocated for rewriting multiple zones in the non-volatile memory, rather than aborting the write command as previously described. For example, although most of the host data written to a zone is contiguous in nature, a small portion of the host writes (e.g., 2% to 5% of the host writes) may be random in nature, and therefore the host may issue a zone write command including such random data to rewrite the previously written contiguous data. Therefore, over time, the default super block in non-volatile memory may be filled up by being overwritten with data from multiple zones.

[0029] In order to reclaim the memory used to be rewritten by the corresponding zone, the controller of the flash storage device may apply a zone-based garbage collection process (referred to as "GC cleaning" throughout this disclosure). For example, if more than 2% to 3% of the memory capacity of the flash storage device includes data rewrites to one or more zones, the controller may trigger a GC cleanup in response to determining that a default super block (e.g., a super block allocated for rewriting multiple zones in a non-volatile memory) has been rewritten a certain number of times. During the GC cleanup, the controller may reclaim the corresponding zone data from the default super block to the super block allocated for the corresponding zone. For example, the controller may perform a compression or garbage collection process that allows valid (e.g., initially written) zone data in one super block to be merged into a single super block together with the rewritten zone data in the default super block. The controller may perform this GC cleanup on multiple zones, thereby achieving compression of valid zone data in the super block allocated for the corresponding zone. As a result of zone-based garbage collection, the write amplification factor (WAF) of the flash storage device may be reduced.

[0030] In one example of this zone-based garbage collection or GC clearing, the controller of the flash storage device initially selects the zone that is overwritten and includes data to be recycled back into a single super block, and the controller identifies the logical range of the zone. Using a hardware accelerator in the controller (one of which can be a data processor), the controller takes out the L2P entry of the physical address of the logical range of the zone from the L2P mapping table of the logical to physical address of the storage zone data. From the mapping table, the controller can take out all physical addresses in the non-volatile memory where the zone data resides. Thereafter, the controller maps those physical addresses to the super blocks they contain. For example, the controller may have grouped the combination of erase blocks into corresponding super blocks, and the controller can therefore identify the super blocks associated with those physical addresses. Once the controller identifies those super blocks, the controller recycles the zone data from those super blocks to specific empty destination super blocks. The controller recycles the super blocks one by one.

[0031] During the reclamation process, the flash storage device may utilize a reclaim reader module and a reclaim writer module of the controller. An empty destination Super Block into which the controller intends to merge data may be assigned to the reclaim writer module, and a list of Super Blocks that the controller has identified that contain zone data may be assigned to the reclaim reader module. The reclaim reader module processes the list of Super Blocks, one Super Block at a time. When the reclaim reader module processes a given Super Block (source Super Block), the reclaim reader module reads a manifest inside the Super Block that provides information about what data is written to where in the Super Block. Using this manifest, the controller may filter out the zone data in the Super Block. Once the controller identifies the portion of the entire Super Block where the specific zone data of interest resides, the controller reads the specific data and the reclaim writer module writes the data to the destination Super Block. This exercise may be performed for all source Super Blocks in the list that the controller has identified, and continues until the list of source Super Blocks is completely processed (exhausted). Finally, the destination Super Block is compressed along with the zone data. At this point, the zone data is no longer scattered across different Super Blocks, but is merged into a single Super Block. Thus, as a result of the garbage collection process, the region data is effectively cleared from multiple Super Blocks and placed into one Super Block for the corresponding region.

[0032] Figure 1 An exemplary block diagram 100 of a storage device 102 in communication with a host device 104 (also referred to as a "host") is shown 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, a desktop, a mobile / laptop computer, a tablet computer, a smart phone, 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 entirely distributed across multiple remote entities, or alternatively have certain functions in the storage device 102.

[0033] 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 process 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.

[0034] The host device 104 may store data to the storage device 102 and / or retrieve data from the storage device. The 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 smart phone, a television, a camera, a display device, a digital media player, a video game console, a video streaming device, etc. The host device 104 may include at least one processor 101 and a host memory 103. 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)), dedicated 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 by software instructions, firmware, etc. The host memory 103 may be used by the host device 104 to store data or instructions processed by the host or data received from the storage device 102. In some examples, host 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, host 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.). Host memory 103 may also include both non-volatile memory and volatile memory, whether integrated together or as discrete units.

[0035] The host 104 may also include a host memory buffer (HMB 105). The HMB 105 is a portion of the host memory (e.g., the host memory 103 or a different memory in the host 104) that the host 104 may allocate to the storage device 102 for the storage device's own purposes. For example, the storage device 102 may utilize the HMB 105 as an address mapping table cache or a data cache. In some examples, the HMB 105 may include volatile memory, such as RAM, DRAM, or SDRAM (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, etc.). In other examples, the HMB 105 may include non-volatile memory.

[0036] 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 can be wireless and can 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.

[0037] The storage device 102 includes a memory. For example, Figure 1In 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 penta-level cell (PLC) memory, or any combination thereof), or a NOR memory. The NVM 110 may include a plurality of NVM 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 NVM memory locations 112, where m and n are predefined according to the size of the NVM. Figure 1 In an exemplary embodiment, each NVM memory location 112 can be a die 114 including multiple planes, each plane including multiple blocks of multiple cells 116. Alternatively, each NVM memory location 112 can be a plane including multiple blocks of cells 116. Cells 116 can be, for example, single-level cells, multi-level cells, three-level cells, four-level cells, and / or five-level cells. Other examples of NVM memory locations 112 are also possible; for example, each NVM memory location can be a block or a group of blocks. Each NVM memory location can include one or more blocks in a 3-D NAND array. Each NVM memory location 112 can include one or more logical blocks mapped to one or more physical blocks. Alternatively, the memory and each NVM memory location can be implemented in other ways known to those skilled in the art.

[0038] The storage device 102 also includes one or more volatile memories 117, 118, which may include, for example, dynamic random access memory (DRAM) or static random access memory (SRAM). Figure 1As illustrated, the volatile memory 117 may be an SRAM inside (or integrated into) the controller 123 of the storage device 102, and the volatile memory 118 may be a DRAM outside (or remote from) the controller 123 of the storage device 102. However, in other examples, the volatile memory 117 may be a DRAM outside the controller 123, and the volatile memory 118 may be an SRAM inside the controller 123, both of the volatile memories 117, 118 may be located inside the controller 123 or both may be located outside the controller 123, or alternatively, the storage device 102 may include only one of the volatile memories 117, 118. The data stored in the volatile memories 117, 118 may include data read from the NVM 110 or data to be written to the NVM 110. In this regard, the volatile memories 117, 118 may include a write buffer or a read buffer for temporarily storing data.

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

[0040] Each of the data 119 may be associated with a logical address. For example, the volatile memory 118 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 indicating the location of each of the data. This 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 physical address associated with each memory location 112 of the storage data in the NVM. Although Figure 1A single L2P mapping table 120 stored in the volatile memory 118 is illustrated, but in other examples, the L2P mapping table 120 may include multiple tables stored in the volatile memory 118. Mappings in the L2P mapping table 120 may be updated individually in response to host writes, and the L2P mapping table 120 may be periodically refreshed from the volatile memory 118 to one or more of the NVM memory locations 112 of the NVM 110 so that the mappings are persistent across power cycles. In the event of a power failure to the storage device 102, the L2P mapping table 120 in the volatile memory 118 may be restored from L2P entries previously stored in the NVM 110 during initialization.

[0041] Figure 2 is stored in volatile memory (e.g. Figure 1 A conceptual diagram 200 of an example of an L2P mapping table 205 in a volatile memory 118 of a host device, the conceptual diagram illustrating data 202 received from a host device to an NVM 201 (e.g., Figure 1 The data 202 can be mapped to the logical address and physical address in the NVM 110. Figure 1 The L2P mapping table 205 corresponds to the data 119 in Figure 1 205. In one example, data 202 may be stored in one or more pages 204 (e.g., physical pages) in NVM 201. Each page 204 may be associated with a mapping set, which includes one or more entries 206 of L2P mapping table 205, which respectively identify physical addresses 208 mapped to logical addresses (e.g., logical block addresses (LBAs)) associated with data written to the NVM. A logical page may include one or more entries in entries 206. An LBA may be a logical address specified in a write command for data received from a host device. Physical address 208 may indicate a block and offset to which data associated with the LBA is physically written, as well as a length or size (e.g., 4KB or some other size) of the written data. In the illustrated example, a page 204 covering 32KB of data 202 may be associated with a mapping set including 8192 4KB entries. However, in other examples, page 204 may cover a different amount of host data (e.g., other than 32KB of host data) or may include a different number of entries 206 (e.g., other than 8192 entries), or entries 206 may each include different host data lengths (e.g., other than 4KB each).

[0042] Return to reference Figure 1, NVM 110 includes a sense amplifier 124 and a data latch 126 connected to each NVM memory location 112. For example, NVM memory location 112 may be a block including cells 116 on a plurality of bit lines, and NVM 110 may include a sense amplifier 124 on each bit line. In addition, one or more data latches 126 may be connected to the bit lines and / or the sense amplifier. The data latch may be, for example, a shift register. When data is read from a cell 116 of NVM 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 transferred from data latch 126 to controller 123, after which the data is stored in volatile memory 118 until it is transferred to host device 104. When data is written to cell 116 of NVM memory location 112 , controller 123 stores the program data in data latch 126 and then transfers the data from data latch 126 to cell 116 .

[0043] The storage device 102 includes a controller 123, which includes circuit systems 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 system on a chip (SoC), a field programmable gate array (FPGA), hardwired logic, analog circuit systems, and / or combinations thereof.

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

[0045] 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, 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 may be accessed by the controller 123 for execution by one or more processors of the controller 123. Alternatively, the functions and components of the controller may be implemented using hardware in the controller 123, or may be implemented using a combination of the aforementioned hardware and software.

[0046] In operation, host device 104 stores data in storage device 102 by sending a write command to storage device 102 that specifies 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 controller allocates NVM memory location 112 in NVM 110 of storage device 102 for storing the data. Controller 123 stores an L2P mapping in L2P mapping table 120 to map the logical address associated with the data to the physical address of the NVM memory location 112 allocated for the data. Controller 123 then stores the data in NVM memory location 112 by sending the data to one or more data latches 126 connected to the allocated NVM memory location, from which the data is programmed to cell 116.

[0047] 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 mapping in the L2P mapping table 120 to convert the logical address specified in the read command to a physical address indicating the location of the data. The controller 123 then reads the requested data from the NVM memory location 112 specified by the physical address by using the sense amplifier 124 to read the data and store the data in the data latch 126 until the read data is returned to the host 104 via the host interface 106.

[0048] Figure 3 A conceptual diagram 300 illustrating an example of a zone 302 is illustrated. Each zone 302 is of a fixed size and includes a contiguous range of consecutive logical addresses 304 in the NVM 110. For example, as illustrated, the NVM 110, 201 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-1 represents the last LBA in the same zone. Each zone can be used separately by the host to store data associated with one or more applications run by the host. The controller 123 can calculate the number of zones based on the fixed zone size and the capacity of the storage device 102, thereby determining different ranges of consecutive logical addresses 304 in each zone. For example, if the capacity of the storage device is 8TB and the fixed zone size is 1GB, the controller 123 can determine the number of zones to be 8000 in response to dividing the storage device capacity by the fixed zone size (8TB / 1GB=8000).

[0049] Controller 123 may determine the definition of zones 302 (e.g., logical address groups 304) in storage device 102. For example, controller 123 may determine that one set of LBAs or logical blocks is associated with a first zone, another set of LBAs or logical blocks is associated with a second zone, and so on. Controller 123 may then map each logical block to one or more physical blocks in NVM 110. For example, controller 123 may map LBAs associated with a first zone to a first super block (e.g., one or more NVM memory locations in NVM memory locations 112), map LBAs associated with a second zone to a second super block (e.g., a different one or more NVM memory locations in NVM memory locations 112), and so on. Controller 123 may then write and read data 119 in the physical blocks associated with zones 302. For example, when writing data to a zone, the controller 123 may create an associated L2P entry for the zone data in the L2P mapping table 120, 205 in the volatile memory 118, and the data associated with the corresponding logical address may be written to any available location in one or more super blocks associated with the zone.

[0050] Typically, in ZNS, host data (e.g., data 119, 202) is written to zones consecutively. For example, each time the host 104 issues a zone write command in which the host sends to the controller 123 data to be written to the logical page of the NVM 110, 201 located at a given logical address, the controller 123 moves the write pointer to the next logical address in the zone 302, and when a subsequent zone write command is issued, the host 104 is expected to send data for the next logical page. If the host does not follow this order (e.g., if the next write command from the host includes logical addresses that are out of order, such as the same logical address in the attempted data overwrite), the controller 123 may issue an error and abort the zone write. For example, referring to Figure 3 , if the host 104 initially writes data in LBA 0 of zone 0, and subsequently sends a write command to rewrite data in LBA 0 of zone 0, the controller 123 may generate an error because it did not receive a command to write in the expected LBA 1. Therefore, the host 104 is generally unable to rewrite consecutive data at a given logical address in a zone until after the zone is completely written.

[0051] However, ZNS may be extended to support data rewrites within a zone random write area (ZRWA) associated with the zone in a zone. In one possible application of ZRWA, the controller 123 may initially store data rewrites for the corresponding zone in volatile memory 118 (e.g., in SRAM), and the controller may later flush these data rewrites from the volatile memory 118 to the NVM 110, 201 in response to a commit operation. However, storage devices typically have a limited amount of volatile memory 118, and thus this approach may not be sufficient to handle the potentially large number of data rewrites that the controller 123 may receive for the corresponding zone. Therefore, in another application of ZRWA, the controller 123 may write the data rewrites for the corresponding zone directly to the NVM 110, 201, rather than maintaining these data rewrites in the volatile memory 118. For example, in addition to writing valid data for zone 302 in NVM 110, 201 to the super blocks respectively allocated for the zone, controller 123 may also rewrite data for zone 302 and other zones to the default super blocks allocated for this purpose in NVM 110, 201. This approach can reduce the cost that would otherwise be incurred by using SRAM for ZRWA.

[0052] Figure 4A conceptual diagram 400 illustrates an example of zones 402 each associated with a ZRWA 404. Initially, the host 104 may send a zone open command to the controller 123 to open the zone 402 in ZRWA mode, and the mode may remain associated with the zone 402 until the zone is completed. For a zone 402 opened in ZRWA mode, the controller 123 may define a ZRWA window 406 of a predefined region size (e.g., 1MB) including a sub-range of logical addresses in the zone, which the controller 123 may expose to the host 104 for rewriting. In response to a commit operation from the host 104 or the controller 123, the controller may move the ZRWA window 406 to the next sub-range of logical addresses in the zone 402. As an example, when the host 104 issues a zone write command including sequential data or random data of a logical page to a zone 402 supporting ZRWA 404, the controller 123 may initially store the logical page in a super block allocated for the initial write to the zone in the NVM 110, 201, and the controller 123 may move the write pointer 407 to the next logical address within the ZRWA window 406 in the zone 402. The controller may also create an associated L2P entry 206 for the initially written zone data in the L2P mapping table 120, 205. If the host 104 issues a zone write command indicating the same logical address as a previously issued zone write command (e.g., data rewrite) within the ZRWA window 406, the controller 123 may store the next logical page in a default super block allocated for rewriting multiple zones in the non-volatile memory, rather than aborting the write command as previously described. The controller 123 may similarly create an associated L2P entry 206 in the L2P mapping table 120 , 205 for the rewrite region data.

[0053] On the other hand, if the host 104 issues a zone write command indicating the next logical address in sequence corresponding to the current position of the write pointer 407, the controller 123 may store the next logical page in the super block allocated for the initial write to the zone 402 and again move the write pointer 407 to the next logical address within the ZRWA window 406 in the zone. Thus, data may continue to be written or rewritten, L2P entries 206 created, and the write pointer 407 moved within the ZRWA window 406 until the host 104 issues an explicit commit command 408, or until the ZRWA window 406 becomes full (e.g., the entire sub-range of logical addresses in the ZRWA window has been written, thereby triggering an implicit commit command 410 from the controller 123). In response to the commit operation, the controller 123 may move the ZRWA window 406 to the next sub-range of logical addresses in the region 402 (e.g., the next 1MB, a predefined region size), which starts after the last committed logical address (e.g., starts at the current position of the write pointer), and the writing or rewriting of data within the new ZRWA window may continue in a manner similar to that previously described. Similarly, the controller 123 may continue to create associated L2P entries in the L2P mapping table 120, 205 for the region data.

[0054] However, if the controller 123 stores data rewrites for a zone in a superblock of the NVM 110, 201 (e.g., in ZRWA mode), such storage may complicate the ZNS practice of mapping separate superblocks to separate zones, respectively. A superblock refers to a logical block that includes (e.g., is mapped to) multiple physical blocks in different memory dies, respectively, of the storage device 102. Typically, in a storage device that applies ZNS, the controller 123 allocates a single superblock that is sized to store the same amount of data as a separate zone. For example, if a zone stores X MB of data, the superblock is allocated from physical blocks across different memory dies that store a total of X MB of data. Therefore, if a zone does not support data rewrites (e.g., if the zone 302, 402 is not opened in ZRWA mode and therefore only allows sequential data writes), a separate superblock itself may be sufficient to store the data for the zone. However, if the Zone supports data overwrites in non-volatile memory (e.g., if the Zone 302, 402 is opened in ZRWA mode), then the individual Super Blocks themselves may no longer be sufficient to store the Zone data because the Super Block may include invalid data due to these data overwrites and thus become fully programmed before the Zone is fully written. Therefore, the controller may end up writing these data overwrites to at least one default, over-provisioned Super Block allocated for this purpose in NVM 110, 201, but these over-provisioned Super Blocks may store data overwrites for multiple Zones, as opposed to separate Super Blocks that each store data associated with a separate Zone. For example, referring to Figure 4 , if the Super Block of Zone 0 is filled with valid data and invalid data for Zone 0, and if the Super Block of Zone 1 is likewise filled with valid data and invalid data for Zone 1, the controller may write the data rewrite for Zone 0 and the data rewrite for Zone 1 to the same, over-provisioned Super Block allocated for this purpose in NVM 110, 201. As a result of this over-provisioning, the write amplification factor (WAF) of the storage device 102 may be significantly affected.

[0055] To address this complexity in the ZNS device, the controller 123 may apply a zone-based garbage collection process (e.g., a reclaim or recycling process for a zone) in which the controller 123 obtains valid zone data from the Super Block associated with the zone, as well as rewritten zone data from over-allocated Super Blocks associated with multiple zones, and merges or compresses the zone data into a single Super Block for the zone. To achieve this result, the controller 123 may obtain a zone identifier, and the controller 123 (e.g., a data processor or hardware accelerator of the controller) may use the zone identifier to identify L2P entries associated with the logical addresses of the zone. From these L2P entries, the controller 123 may identify the physical addresses associated with the zone, and based on these physical addresses, the controller 123 may identify the logical addresses of the Super Blocks that include the initial written contiguous data for the zone and the logical addresses of the over-allocated Super Blocks that include the data rewrites for the zone. The controller 123 may then add the Super Blocks associated with these logical Super Block addresses to a Super Block list for memory reclamation, and the controller 123 may perform garbage collection on the zone individually using each Super Block in the list.

[0056] For example, when performing garbage collection on a given zone, the controller 123 may read the zone data stored in the corresponding Super Block (i.e., the source Super Block or the reclaim reader Super Block) in the list, and the controller may reclaim the zone data from the corresponding Super Block into a single Super Block (i.e., the destination Super Block or the reclaim writer Super Block). The controller 123 may repeat this process (e.g., in a loop) for each Super Block associated with the given zone by replacing each Source Super Block that has been reclaimed with another Super Block in the list until the zone data from each Source Super Block in the list has been transferred to the destination Super Block. Thus, the corresponding zone valid data may be merged into the destination Super Block from at least two Source Super Blocks, including a Super Block that stores the initial continuous write data for the corresponding zone (the original Super Block before rewriting) and at least one other over-allocated Super Block that stores subsequent rewrite data for the corresponding zone and other zones. Depending on the amount of data rewrites that occur in the corresponding zone, there may be more than one over-allocated Super Block. In addition, to ensure that the controller 123 only transfers corresponding region data in the over-allocated Super Block during the garbage collection process (e.g., rewriting the data of Region 0 instead of rewriting the data of Region 1), the controller can utilize a manifest associated with the Super Block. The manifest can be, for example, metadata stored in the Super Block, which indicates logical pages or other information (e.g., in the header of the physical page, etc.), which the controller can use to determine the correct region data to transfer and the region data to skip during the garbage collection process. At the end of the garbage collection process, a merged Super Block with all valid region data (including overwritten data) can be formed.

[0057] The controller 123 may form a superblock in one of the multiple subdrivers of the storage device 102. Here, a subdriver refers to a logical group or combination of superblocks. The controller may assign a superblock to one of the two subdrivers (referred to as subdriver 0 and subdriver 1 throughout this disclosure), depending on the state of the superblocks individually associated with the zone. For example, when the controller initially writes data to a zone, the controller may form a superblock for the zone and assign the superblock to subdriver 1, and the controller may write the data and subsequent host data to the superblock in a sequential order of the logical addresses associated with the zone. In response to zone write commands for these other zones, respectively, the controller may similarly form and assign separate superblocks for these other zones, respectively, thereby creating a one-to-one mapping of superblocks to zones. Later, if the controller receives a command to rewrite data in the corresponding zone (e.g., a zone write command including a previously written logical address for the zone), the controller may form a different superblock and assign the superblock to subdrive 0, and the controller may rewrite the data to the superblock for the corresponding zone, and rewrite subsequent data for the zone and other zones to the same superblock. Similarly, if the superblock associated with the corresponding zone in subdrive 1 is completely written with valid data and invalid data (e.g., due to data rewriting), but the controller subsequently receives a write command for the zone from the host, the controller may also write the continuous data to the superblock in subdrive 0. Therefore, the controller may write the data for the corresponding zone to the superblock specifically associated with the zone in subdrive 1, and store the rewritten or initially written data for the corresponding zone in an over-configured superblock, which may store data for multiple zones in subdrive 0.

[0058] Thus, for zone data in the ZNS, subdrive 1 may have 0% over-provisioning, while subdrive 0 may have 100% over-provisioning. For example, in subdrive 1, the controller may form only one superblock for the corresponding zone (there is a strict one-to-one mapping between superblocks and zones in subdrive 1), and therefore, if the superblock becomes full due to invalid data from data rewrites before the associated zone is completely written, the controller may not write valid data to the zone in another superblock in subdrive 1. Instead, the controller may write the valid data to the superblock in subdrive 0, including the data rewrites and the initial written data after the superblock in subdrive 1 is full. In contrast, if the superblock associated with the zone in subdrive 1 is not completely written, the controller may not write the initial zone data to subdrive 0 (as opposed to data rewrites). Therefore, subdrive 1 can be considered to not include any over-provisioning for zone data, while subdrive 0 can be considered to have only over-provisioning for zone data (i.e., the controller may write to the superblock in subdrive 0 whenever there is zone data overflow in the superblock in subdrive 1). The controller may write this overflow data for multiple zones to the same Super Block in Subdrive 0.

[0059] Therefore, the controller 123 may perform zone-based garbage collection (e.g., reclaim writes or GC sweeps) to merge zone data stored in different sub-drives of the NVM 110, 201. When determining whether to initiate zone-based garbage collection for any zone, the controller 123 may maintain a total number of data rewrites of over-provisioned blocks of the storage device 102 that have been written to sub-drive 0, and the controller 123 may determine whether the amount of memory occupied by these data rewrites in sub-drive 0 in total exceeds a certain threshold or percentage (e.g., 3% to 4% or other threshold percentage) of the total capacity of the NVM 110, 201 including sub-drive 0 and sub-drive 1. In this case, the controller may perform GC sweeps on the corresponding zone. Therefore, the threshold may serve as a trigger point for GC sweeps.

[0060] Additionally, when determining which zone to reclaim in sub-drive 1 (e.g., where the controller may store zone-compressed superblocks or initially written zone data), the controller may identify which superblock in sub-drive 1 has a minimum valid page count (VPC) or otherwise a minimum amount of valid zone data (minimum validity), determine the zone associated with that superblock as a victim zone, and perform the aforementioned reclaim write process on that victim zone. For example, after the controller has written continuation data and rewrite data to various zones (but has not yet performed zone-based garbage collection on those various zones), the superblocks individually associated with those respective zones in sub-drive 1 may include different numbers of invalid pages, depending on the amount of data rewrite that has occurred in the respective zones. Thus, in order to maximize the amount of zone reclaim that may occur from zone-based garbage collection, the controller may select any zone with the minimum validity (e.g., the maximum amount of data rewrite) as the target zone for GC cleanup. The controller may also perform the region-based garbage collection on other corresponding regions (e.g., in ascending order of VPC or otherwise in order from least significant to most significant) until the total amount of memory occupied by these data rewrites drops below the aforementioned threshold percentage (e.g., drops to 2%). At this point, the triggering condition for GC cleaning may no longer be met, and the region-based garbage collection may therefore stop.

[0061] Figure 5An example 500 of zone-based garbage collection (GC sweep) performed in superblocks allocated in different sub-drives 502 of NVM 504 is illustrated. In this example, sub-drive 1 may include superblocks 506 associated with different zones, respectively, while sub-drive 0 may include superblocks 508 including data rewrites of multiple zones. Each superblock 506 in sub-drive 1 may include multiple blocks 510 storing data at different logical addresses in a single zone. For example, in the case where NVM 504 includes N zones, sub-drive 1 may include N superblocks, each of which includes physical blocks storing continuous data for initial writes to a single zone (e.g., in a continuous order of logical addresses for the corresponding zone). On the other hand, superblocks 508 in sub-drive 0 may include blocks 510 storing data at different logical addresses in a single zone, respectively. For example, in the case where NVM 504 includes N zones, sub-drive 0 may include superblocks including physical blocks storing rewrite data (e.g., data overflowing from sub-drive 1) in up to N zones. Subdrive 0 may also include an over-provisioning 512 (e.g., one or more additional Super Blocks) that may also store data rewrites for multiple zones (e.g., in the event that Super Block 508 becomes full). In addition, NVM 504 may include a spare Super Block 514 (e.g., the N+1th Super Block) that may remain available and unallocated to a zone until the controller designates the spare Super Block as a destination Super Block for a target zone in a zone-based GC. For example, in Figure 5 In the example of FIG. 5 , the controller may determine to perform GC 516 on Zone 1 using Super Block 1 as the source Super Block, and the controller may allocate Free Super Block 514 as the destination Super Block for this GC 516 for Zone 1 in Sub Drive 1 (in Figure 5 is called super block 1').

[0062] To perform zone-based GC, in one example, controller 123 may determine which of the N superblocks in subdrive 1 has the least amount of validity (e.g., lowest VPC), and the controller applies that superblock 506 for GC cleaning. Figure 5In the example of , the controller 123 may determine that Super Block 1 (associated with Zone 1) has 94% validity (e.g., 94 valid pages out of every 100 pages), while the other N-1 Super Blocks in Subdrive 1 have 95% or greater validity, and therefore the controller may determine to apply a GC purge to Zone 1. This process by which the controller selects the zone or Super Block associated with the least validity for a GC purge is referred to throughout this disclosure as victim selection (or victim zone selection). Through victim selection, the controller may select any zone that has the least valid data in Subdrive 1 and therefore has the most valid data in Subdrive 0, and therefore the controller may release or reclaim any zone that occupies the most space in Subdrive 0 during a GC purge. For example, if Super Block 1 has the least validity of all Super Blocks in Subdrive 1 (e.g., 94% validity), the data for Zone 1 in the over-provisioned Super Block in Subdrive 0 may include the largest amount of valid data of all zones available for zone-based GC (e.g., 6 valid pages out of every 100 pages, which here is the maximum number of valid pages that can be reclaimed in response to a GC purge of a single zone). Therefore, in Figure 5 In the example of , the controller may select Region 1 as the victim region because applying GC 516 to this region will cause the largest amount of memory in Super Block 508 to be released or reclaimed for later use (compared to applying GC to other regions).

[0063] However, before the controller 123 even performs victim selection to determine a particular zone for zone-based GC, the controller may determine whether a trigger for a GC purge in general (for any zone) has occurred. For example, the controller may determine whether the total amount of memory occupied by data stored in the superblock 508 of subdrive 0 exceeds a threshold percentage of the total available physical capacity of NVM 110, 201, 504. For example, referring to Figure 5 In an example of, the controller may identify the total amount of memory currently used by zone data in subdrive 0, including zone data stored in block 510 of superblock 508 for all zones 1-N, and any other zone data that may be stored in overprovisioning 512 (e.g., other superblocks including zone data in subdrive 0). The controller may then determine whether this total amount of memory used in subdrive 0 exceeds a configured threshold percentage (e.g., 3% or other percentage) of the total memory capacity combined in subdrive 0 and subdrive 1, in which case the controller may trigger a GC purge and identify the victim zone. For example, if the total capacity of NVM 504 including its two subdrives is 100GB, then if the controller determines that the total amount of memory used by valid zone data in subdrive 0 is at least 3GB, the controller may determine to perform a zone-based GC on any zone that currently has the smallest VPC among all zones in subdrive 1. For example, in Figure 5In the example of , the controller may perform GC 516 on region 1 in response to determining that a general GC cleanup trigger has been satisfied and further in response to determining that region 1 has a minimum validity.

[0064] GC sweeps differ from non-region-based GCs, such as Figure 5 GC 518 in the example of . For example, when the controller performs GC 518 on Super Block 508 in Sub Drive 0, the controller typically compresses the valid data of Super Block 508 in Over Provisioning 512 (e.g., in the Destination Super Block in Sub Drive 0), and the controller may reclaim the source Super Block in Sub Drive 0 for subsequent zone data use. This compression is independent of zones because the controller may transfer (read and write) valid data associated with multiple zones in Super Block 508 to the same Destination Super Block in Sub Drive 0. However, if there is insufficient over provisioning for compression, the controller may not perform GC 518. For example, in Figure 5 In the example of , if there is an under-over-provisioning, the controller 123 may not perform GC 518 in Sub-Drive 0, which may be indicated by the occurrence of a general GC cleanup trigger. Therefore, to address this under-over-provisioning situation, the controller may perform a zone-based GC or GC cleanup (such as GC 516), in which the controller compresses the valid data of Super Block 508 into Super Block 506 associated with the victim zone in Sub-Drive 1. This compression is zone-dependent because the controller may avoid transferring (reading and writing) valid data associated with other zones in Super Block 508 other than the victim zone to a free Super Block 514 or destination Super Block in Sub-Drive 1.

[0065] Thus, the general GC clear trigger allows the controller to determine whether there is sufficient over-provisioning of the GC 518 in sub-drive 0, and therefore whether the controller can perform GC 518 (non-region-based GC that remains within the same sub-drive) to reclaim memory in the super-block 508, or whether the controller can perform GC 516 (region-based GC between sub-drives) to reclaim memory in the super-block 508. If there is insufficient over-provisioning of the GC 518 in sub-drive 0, the controller can be triggered to perform GC 516. For example, NVM 504 can typically include a limited number of super-blocks in sub-drive 0, and therefore the amount of data rewrite that sub-drive 0 can typically tolerate can be very small (e.g., 2% of the total capacity of NVM 504 including sub-drive 0 and sub-drive 1). This tolerance level corresponds to a threshold percentage that the controller can consider when determining whether a trigger has occurred, and therefore the controller can set the threshold percentage based on the amount of over-provisioning available in sub-drive 0.

[0066] For example, in one example, assume that the controller 123 has allocated 4% of the total capacity of NVM 504 for data rewrites in subdrive 0 (including 2% of the capacity in superblock 508 and a matching 2% of the capacity in overprovisioning 512). In this case, even if the amount of data rewrites completely fills superblock 508 (2% of the capacity), the 2% overprovisioning is still sufficient to accommodate GC 518 because the total capacity is not exceeded by 4%. Therefore, as long as the amount used to store data rewrites in superblock 508 does not exceed the 2% of the capacity, a non-zone-based GC can be performed. In other words, the controller can perform a non-zone-based GC to reclaim storage in superblock 508 as long as the total capacity of NVM 504 used for zone data rewrites does not exceed the allowable level or threshold percentage (e.g., 2%) of the storage device. In this case, sacrifice zone selection cannot be performed for GC 518 because in a non-zone-based GC, all zone data can be compressed into the same destination superblock in overprovisioning 512.

[0067] However, if the total amount of data rewrites exceeds the 2% capacity of the superblock 508, there may not be enough over-provisioning in sub-drive 0 to accommodate GC 518 within the same sub-drive (e.g., it would exceed 4% of the total capacity). Therefore, in this case, the controller may not be able to perform a non-zone-based GC. For example, continuing with the 2% capacity example above, if the storage device 102 can only tolerate 2% rewrites to each of 1000 zones that each occupy 1GB of memory, the storage device can only tolerate a maximum of 20GB of rewrites in sub-drive 0 in total across all 1000 zones. Therefore, if more than that amount of data is written to sub-drive 0, there may not be enough remaining capacity in sub-drive 0 (the remaining 2% over-provisioning) to perform a non-zone-based GC within the same sub-drive 0. Therefore, in this case, the controller may instead determine to perform GC 516 from sub-drive 0 to sub-drive 1 in order to reclaim memory in the superblock 508. In other words, if the total capacity of NVM 504 used for data rewriting eventually exceeds a tolerance level or threshold percentage (e.g., 3% or more), the controller may be triggered to perform a GC 516. Furthermore, since this GC is between a superblock including multiple zone data in subdrive 0 and a superblock including a single zone data in subdrive 1, the controller cannot perform a zone-independent GC, as it might have previously performed if the threshold percentage had not been exceeded. Instead, the controller may determine to perform a zone-dependent GC (GC sweep) to reclaim the zone data from the single zone as described above, for example, using a sacrifice selection to obtain maximum eviction efficiency.

[0068] Thus, in response to the GC clear trigger and the victim area selection for Zone 1, the controller may rewrite transfer (i.e., read and write) the Zone 1 contiguous data from the source Super Block 1 in Subdrive 1 and the Zone 1 data in the Super Block 508 in Subdrive 0 to the destination Super Block 1′ in Subdrive 1. During GC 516, the controller may merge the valid data for Zone 1 in Super Block 1 of Subdrive 1 with the valid data for Zone 1 in the over-allocated Super Block of Subdrive 0, while leaving the invalid data for Zone 1 in Super Block 1 of Subdrive 1. For example, the controller may determine the logical addresses of the Super Blocks in Subdrives 0 and 1 that include the data for Zone 1 based on the L2P mapping tables 120, 205 in the volatile memory 118, and the controller may read the Zone 1 data from these Super Blocks and write the Zone 1 data to a different Super Block that is solely associated with a Zone in Subdrive 1. Additionally, during GC 516 (zone-based GC), the controller may prohibit the transfer (i.e., reading and writing) of valid data of other zones from Super Block 508 in Subdrive 0 to Destination Super Block 1' in Subdrive 1, so that the destination Super Block for GC cleanup may include only valid data of the victim zone (Zone 1 in this example). Figure 5 In the illustrated example, when performing GC 516 on Zone 1, the controller may avoid transferring Zone 2 data up to Zone N data and avoid including Zone N data in Free Super Block 514. The controller may then erase blocks of Super Block 1 in Subdrive 1 and later maintain that Super Block as a new Free Super Block 514 until the controller later designates that Super Block as a new destination Super Block for the target zone in a subsequent GC clear.

[0069] Figure 6 An example flowchart 600 of a method for performing a region-based GC is illustrated. 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) as described below, or by a component or module of the controller, or by some other suitable means.

[0070] As shown in box 602, the controller may download the zone L2P entry from the L2P mapping table. For example, during a GC purge (e.g., GC516), the controller may access a mapping of zone IDs to logical ranges (e.g., ZNS), and the controller may identify the logical range of the zone ID selected for the GC purge. In one example, the zone ID may correspond to a victim zone with the lowest VPC among all other zones, and the controller may select the zone ID after a GC purge trigger occurs (e.g., based on the total capacity of NVM110, 201 for zone data rewrite). Alternatively, the controller may select a zone ID different from the victim zone (such as an arbitrary zone) for the GC purge. The controller (e.g., a data processor component of the controller) may retrieve the L2P entry associated with the zone corresponding to the zone ID from the L2P mapping table 120, 205, for example, an entry 206 including a logical address 304 associated with the zone 302, 402 selected for the GC purge.

[0071] As shown in block 604, the controller may prepare a list of Super Blocks containing region data. For example, after retrieving an L2P entry (e.g., entry 206), the controller may identify from the L2P mapping table 120, 205 the physical addresses 208 of the blocks 510 storing data associated with the victim region. The controller may then determine the Super Blocks 506, 508 that include the blocks 510 associated with these physical addresses 208. For example, the controller may maintain a mapping of the Super Blocks 506, 508 to the regions 302, 402, the logical addresses 304 associated with the regions 302, 402, and / or the physical addresses 208 of the blocks 510 associated with these logical addresses 304 separate from the L2P mapping table 120, 205, and the controller may determine the logical identifiers of these Super Blocks 506, 508 based on the Super Block mapping table. After obtaining the Super Block identifiers, the controller may add these identifiers of the Super Blocks of the selected region to a list or other data structure of source Super Blocks for GC cleanup (e.g., GC 516).

[0072] As shown in block 606, the controller may feed individual superblocks in the list as source superblocks for garbage collection. For example, after adding the identifiers of the superblocks of the selected zone (superblocks 506, 508) to a list or other data structure of source superblocks for GC cleanup (e.g., GC516), the controller may perform a zone-based GC. During the GC, the controller (e.g., a reclaim read module of the controller) may obtain the next source superblock ID in the list and obtain the fetched physical address 208 associated with the superblock 506, 508 currently being processed in the list. Thereafter, as shown in block 608, the controller may perform a zone validity check in addition to the L2P validity check of the logical addresses associated with these fetched physical addresses. For example, in addition to performing an L2P validity check in which the controller may determine valid logical pages (e.g., logical pages storing valid data) at those fetched physical addresses based on a manifest (e.g., metadata) of the current Super Block, the controller may also perform a region validity check in which the controller may determine which of those valid logical pages are specifically associated with the selected region being reclaimed (e.g., based on comparing the logical pages with a mapping of the region 302, 402 to logical addresses, which the controller maintains separate from the L2P mapping table 120, 205). After determining the valid logical pages associated with the selected region for GC cleanup, the controller (e.g., a reclaim reader module of the controller) reads the valid region data from the current source Super Block at those determined logical pages (thereby ignoring logical addresses / physical addresses or region data outside the LBA range of the selected region), and the controller (e.g., a reclaim write module of the controller) writes the valid region data to the new destination Super Block. For example, referring to Figure 5 In GC 516, the controller can transfer zone 1 data from super block 508 in subdrive 0 to new super block 1' in subdrive 1, while avoiding transferring other zone data from the super block in subdrive 0 to super block 1' in subdrive 1.

[0073] The controller may similarly repeat the above process for each super block in the list until the list is exhausted. Figure 5 GC 516 in, before or after processing Superblock 508 in Subdrive 0, the controller may transfer Region 1 data from Superblock 506, referred to as Superblock 1 in Subdrive 1, to a free Superblock 514, referred to as New Superblock 1', in Subdrive 1. Thus, Superblock 1' in Subdrive 1 may be merged with valid Region 1 data from both Subdrive 1 and Subdrive 0, and any invalid Region 1 data in either Superblock 1 or the Superblock of Subdrive 0 may then be erased and the corresponding storage reclaimed or reclaimed.

[0074] Finally, as shown in box 608, the controller can return the superblocks in the source superblock list to the flash array manager (FAM). The FAM is a module of the controller that can record the status of all superblocks (e.g., whether a given superblock is partially written or fully written, which subdrive the superblock belongs to, the corresponding blocks of the superblock, or other metadata of the superblock). The FAM can be responsible for creating / allocating superblocks, deallocating superblocks, or performing other block management layer functions. If the controller receives a host write command for a superblock, the FAM can temporarily provide an empty superblock to the controller's host writer module to write the superblock, after which the host writer module can return the completely written superblock to the FAM. Similarly, with respect to GC clearing, after the controller identifies the source superblock list for zone-based GC, the FAM can provide the superblocks in the list to the controller's recycling reader module for processing GC 516. After the source superblocks are processed, the recycling reader module can return these superblocks to the FAM.

[0075] Figure 7 An example flowchart 700 illustrates another method for performing region-based GC. 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) as described below, or by a component or module of the controller, or by some other suitable means.

[0076] As shown in block 702, the controller may allocate a first sub-drive (e.g., sub-drive 0) and a second sub-drive (e.g., sub-drive 1) in a non-volatile memory (e.g., NVM 110, 201, 504). The first sub-drive may include a first plurality of super-blocks (e.g., super-block 508 in sub-drive 0) for storing data overwrites, and the second sub-drive may include a second plurality of super-blocks (e.g., super-block 506 in sub-drive 1) for storing contiguous data. The first sub-drive (e.g., sub-drive 0) may also include an over-provisioning (e.g., over-provisioning 512) of the first plurality of super-blocks (100% over-provisioning), while the second sub-drive (e.g., sub-drive 1) may lack an over-provisioning of the second plurality of super-blocks (0% over-provisioning).

[0077] As shown in block 704, the controller may create a first Super Block including a first block in nonvolatile memory (e.g., Super Block 508 including block 510 in subdrive 0 of NVM 504), a second Super Block including a second block in nonvolatile memory (e.g., Free Super Block 514 including block 510 in subdrive 1 of NVM 504), and a third Super Block including a third block in nonvolatile memory (e.g., Super Block 506 including block 510 in subdrive 1 of NVM 504). The first plurality of Super Blocks in the first subdrive may include the first Super Block (e.g., Super Block 508 in subdrive 0), and the second plurality of Super Blocks in the second subdrive may include the second Super Block and the third Super Block (e.g., Super Blocks 506, 514 in subdrive 1).

[0078] As shown in block 706, the controller may write first data associated with the first zone to the first Super Block (e.g., write data 119, 202 associated with Zone 1 to Super Block 508), write second data associated with the second zone to the first Super Block (e.g., write data 119, 202 associated with Zone 2 to Super Block 508), and write third data associated with the first zone to the third Super Block (e.g., write data 119, 202 associated with Zone 1 to Super Block 506). The first zone may include a first range of logical addresses (e.g., logical address 304 in Zone 1), and the second zone may include a second range of logical addresses different from the first range of logical addresses (e.g., different logical addresses 304 in Zone 2). The first data and the second data may be data overwrites (e.g., stored in block 510 of Super Block 508), while the third data may be sequential data (e.g., stored in a block such as Figure 5 In block 510 of super block 506, etc.).

[0079] As shown in block 708, the controller may determine whether the total amount of data rewrites in the first sub-drive (e.g., sub-drive 0) exceeds a threshold percentage of the capacity of the non-volatile memory (e.g., NVM 110, 201, 504). If the general GC clear trigger is met, the controller may perform a zone-based GC. For example, referring to Figure 5 In the example of FIG. 5 , the controller may identify the total amount of memory currently used by the zone data in subdrive 0, including the zone data stored in block 510 of superblock 508 for all zones 1-N, and any other zone data that may be stored in overprovisioning 512 (e.g., other superblocks including the zone data in subdrive 0). The controller may then determine whether this total amount of memory used for the zone data in subdrive 0 exceeds a configured threshold percentage (e.g., 3% or other percentage) of the total memory capacity of subdrive 0 and subdrive 1 combined, in which case the controller may trigger a GC purge of the victim zone.

[0080] As shown in block 710, the controller may add the first Super Block (e.g., Super Block 508) to a list of Super Blocks (e.g., data structures) that each include data associated with a first zone (e.g., Zone 1). In addition, the controller may add a third Super Block (e.g., Super Block 506 referred to as Super Block 1) to a list of Super Blocks that each include data associated with the first zone. To locate these Super Blocks to add to the list, the controller may perform the steps described above with respect to Figure 6 6 and 604 of FIG. 1 . For example, the controller may first identify a range of logical addresses associated with the first zone (e.g., logical address 304 of zone 1). Then, the controller may obtain an L2P mapping (e.g., entry 206) of a physical address (e.g., physical address 208) in the non-volatile memory to a logical address in the first range of logical addresses (e.g., logical address 304 of zone 1) from an L2P mapping table (e.g., L2P mapping table 120, 205). Next, the controller may use the L2P mapping (e.g., entry 206) to determine the Super Blocks (e.g., Super Blocks 506, 508) that respectively include data associated with the first zone (e.g., zone 1). Finally, in response to the determination, the controller may add the Super Blocks including the first Super Block (e.g., Super Block 508) and the third Super Block (e.g., Super Block 506) to the Super Block List.

[0081] As shown in block 712, during garbage collection of multiple Super Blocks in the Super Block List (e.g., GC 516 of Super Blocks 506, 508), the controller may relocate first data associated with a first zone (e.g., Zone 1) from a first Super Block in a first sub-drive (e.g., Super Block 508 in Sub Drive 0) to a second Super Block in a second sub-drive (e.g., Free Super Block 514 in Sub Drive 1). Similarly, the controller may relocate third data associated with the first zone (e.g., Zone 1) from a third Super Block in a second sub-drive (e.g., Super Block 1 in Sub Drive 1) to a second Super Block in a second sub-drive (e.g., Free Super Block 514 in Sub Drive 1). For example, the controller may perform the above-described garbage collection of multiple Super Blocks in the Super Block List. Figure 6The controller may perform these relocations in response to the total amount of data rewrites determined at block 708 exceeding a threshold percentage (e.g., in response to determining that the aforementioned general GC cleanup trigger has occurred). In addition, as shown in block 714, in response to the third super block (e.g., super block 1 in sub-drive 1) including the smallest VPC among the VPCs of the third super block and other super blocks in the second sub-drive (e.g., super block 506 in sub-drive 1), the controller may relocate the first data and the third data to a second super block in the second sub-drive during garbage collection (e.g., to super block 1' in sub-drive 1 during GC 516). This sacrifice area selection maximizes the efficiency of GC 516. In addition, as shown in block 716, during garbage collection (e.g., GC 516), the controller may avoid relocating second data associated with the second zone (e.g., zone 2) from the first super block (e.g., super block 508) to the second super block (e.g., free super block 514).

[0082] Figure 8 800 is a conceptual diagram showing an example of a controller 802 coupled to a memory 804 in a storage device. For example, the controller 802 may correspond to the controller 123, and the memory 804 may correspond to Figure 1 The controller may be implemented in software, hardware, or a combination of hardware and software. In an exemplary embodiment, the controller is implemented using several software modules executed on one or more processors, but as will be appreciated by those skilled in the art, the controller may be implemented in different ways. A skilled person will readily appreciate how to best implement the controller based on the specific design parameters of the system.

[0083] In one example, the controller 802 includes a zone-based GC module 806, which may provide a device for creating a first super block including the first block, a second super block including the second block, and a third super block including the third block; a device for allocating a first sub-drive and a second sub-drive in the non-volatile memory, the first sub-drive including a first plurality of super blocks for storing data rewrites, and the second sub-drive including a second plurality of super blocks for storing continuous data, the first plurality of super blocks including the first super block, and the second plurality of super blocks including the second super block and the third super block; and a device for writing first data associated with the first zone into the non-volatile memory. The first superblock includes a device for writing second data associated with the second zone to the first superblock, and writing third data associated with the first zone to the third superblock, the first zone includes a first range of logical addresses, and the second zone includes a second range of logical addresses; a device for relocating the first data from the first superblock to the second superblock and relocating the third data from the third superblock to the second superblock during garbage collection of multiple superblocks that respectively include data associated with the first zone; and a device for avoiding relocating the second data associated with the second zone from the first superblock to the second superblock during the garbage collection. For example, the zone-based GC module 806 may perform the above-mentioned Figure 6 or Figure 7 Describe the process.

[0084] Typically, a ZNS device has some level of rewrites that can be accommodated in SRAM (in ZRWA), and once a commit operation occurs, the rewrites are written from SRAM to NAND (in NVM). However, caching rewrites in SRAM can result in a high cost to implement ZNS with ZRWA. To reduce costs, the controller can write these rewrites to NAND (rather than SRAM) in a non-ZNS namespace in subdrive 0, and these rewrites can be moved to the ZNS namespace in subdrive 1 during eviction / reclaim. In particular, the controller can apply a reclamation method that reclaims data within an LBA range located in a particular zone in response to specific triggers (e.g., general GC clear triggers and victim zone selection). For example, the controller can use a data processor to download zone L2P entries from an L2P mapping table, prepare a list of superblocks containing zone data that the controller determines to be reclaimed, feed the source superblocks to a reclaim reader module, and then perform GC via its reclaim reader and reclaim writer modules, including data reads, L2P validity checks, and data writes. In addition, the controller can also check zone validity to confirm that the correct zone is being reclaimed. Therefore, one zone can be reclaimed at a time.

[0085] Therefore, based on the metadata indicating the area associated with the relocated data, the controller can relocate the data from the first sub-driver or logical super block group to the second sub-driver or logical super block group. For example, the controller can be configured to relocate the data from one set of super blocks in one sub-driver to another set of super blocks in another sub-driver based on the indication of the area associated with the data. In particular, when relocating across sub-drivers, the controller can filter out the data of the sacrifice area and create a super block list for recycling containing the data. For example, the controller can prepare or identify a super block list for recycling, rather than just selecting an arbitrary super block to recycle, and the controller can filter out the memory containing the data of a specific area as the memory in the super block to be recycled, rather than just reclaiming all the memory in those super blocks, regardless of the area. Although the area can be arbitrarily selected for recycling, the sacrifice area selection can maximize the amount of space recovered in sub-driver 0.

[0086] Additionally, because subdrive 1 has 0% overprovisioning and subdrive 0 has 100% overprovisioning, overprovisioning in the storage device may be significantly reduced compared to a non-ZNS device where the subdrives may all have overprovisioning. Thus, because subdrive 1 does not include overprovisioning, the controller may be configured to perform memory claims only on subdrive 0 to improve GC efficiency. Additionally, if the controller determines that the average number of rewrites per zone is greater than the storage device can tolerate (e.g., 2% to 3% of the total NVM capacity), the controller may move zone data from subdrive 0 to subdrive 1 in a GC purge to maintain the overprovisioning of subdrive 0. The small amount of overprovisioning in subdrive 0 may be reclaimed and used more efficiently.

[0087] Therefore, the storage device can use less SRAM because the rewrites can be stored directly in the NAND instead of in the cache, thereby reducing the cost of the storage device. The controller can write the rewrites to the NAND and later compress these rewrites with other data related to the specific area in the corresponding super block through GC purge. In addition, GC purge allows the storage device to have a reduced WAF for ZNS devices with specific workloads. As a result of GC purge, the controller can reclaim space in the ZNS device with reduced over-provisioning and thus reduced cost.

[0088] Various aspects of the present disclosure are provided to enable a person of ordinary skill in the art to practice the present invention. Various modifications to the exemplary embodiments presented throughout the present disclosure will be apparent to those skilled in the art, and the concepts disclosed herein can be extended to all types of storage devices capable of storing data. Therefore, the claims are not intended to be limited to various aspects of the present disclosure, but are intended to be given a full range consistent with the language of the claims. All structural equivalents and functional equivalents of various components of the exemplary embodiments described in the entire present disclosure known to or to be known by a person 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 stated in the claims, the contents disclosed herein are not intended to contribute to the general public. According to the provisions of 35 U.S.C. § 112 (f) of the United States, or similar regulations or rule of law in another jurisdiction, no claim element will be interpreted unless the phrase "device for..." is used to explicitly state the element, or the phrase "step for..." is used to state the element in the case of a method claim.

Claims

1. A storage device, comprising: a non-volatile memory, the non-volatile memory comprising a plurality of first blocks and a plurality of second blocks; and A controller, the controller being configured to: Creating a first super block including the first block and a second super block including the second block; During garbage collection of a plurality of Super Blocks including data associated with a first Region including a first range of logical addresses, relocating first data associated with the first Region from the first Super Block to the second Super Block; and During the garbage collection, second data associated with a second region including a second range of logical addresses different from the first range of logical addresses is avoided from being relocated from the first Super Block to the second Super Block.

2. The storage device according to claim 1, wherein the controller is further configured to: The first super block is added to a super block list that respectively includes the data associated with the first area, and the garbage collection is for the super blocks in the super block list.

3. The storage device according to claim 2, wherein the controller is further configured to: identifying a range of logical addresses associated with the first region; Obtaining, from a logical-to-physical (L2P) mapping table, a physical address in the nonvolatile memory to a logical address in the first range of logical addresses; The Super Blocks that respectively include the data associated with the first region are determined using the L2P map, wherein the first Super Block is one of the Super Blocks.

4. The storage device according to claim 1, wherein the controller is further configured to: A first sub-driver and a second sub-driver are allocated in the non-volatile memory, the first sub-driver including a first plurality of super blocks for storing data rewrites, and the second sub-driver including a second plurality of super blocks for storing continuous data, the first plurality of super blocks including the first super block, and the second plurality of super blocks including the second super block.

5. The storage device according to claim 4, wherein the controller is further configured to: The first data is relocated from the first superblock in the first sub-drive to the second superblock in the second sub-drive.

6. The storage device of claim 4, wherein the first sub-driver includes an over-allocation of the first plurality of super blocks and the second sub-driver lacks an over-allocation of the second plurality of super blocks.

7. The storage device according to claim 4, wherein the controller is further configured to: determining whether a total amount of rewriting of the data in the first sub-drive exceeds a threshold percentage of a capacity of the nonvolatile memory; and In response to the total amount exceeding the threshold percentage, the first data is relocated from the first super block in the first sub-drive to the second super block in the second sub-drive.

8. The storage device according to claim 4, wherein the non-volatile memory further comprises a plurality of third blocks; and The controller is further configured to: creating a third super block including the third block, the second plurality of super blocks of the second sub-drive including the third super block; and During the garbage collection, third data associated with the first zone is relocated from the third super block in the second sub-drive to the second super block in the second sub-drive.

9. The storage device according to claim 8, wherein the controller is further configured to: determining whether a total amount of rewriting of the data in the first sub-drive exceeds a threshold percentage of a capacity of the nonvolatile memory; and In response to the total amount exceeding the threshold percentage, the third data is relocated from the third super block in the second sub-drive to the second super block in the second sub-drive.

10. The storage device according to claim 9, wherein the controller is further configured to: In response to the third super block including a minimum valid page count (VPC) of the third super block and other super blocks in the second sub-drive, the first data and the third data are relocated to the second super block in the second sub-drive.

11. The storage device according to claim 1, wherein the first data and the second data are data rewrites.

12. A storage device, comprising: a non-volatile memory, the non-volatile memory comprising a plurality of first blocks and a plurality of second blocks; and A controller, the controller being configured to: Creating a first super block including the first block and a second super block including the second block; Writing first data associated with a first zone to the first Super Block and writing second data associated with a second zone to the first Super Block, the first zone comprising a first range of logical addresses and the second zone comprising a second range of logical addresses; adding the first Super Block to a list of Super Blocks that respectively include data associated with the first zone; relocating the first data from the first superblock to the second superblock during garbage collection of a plurality of superblocks in the superblock list; as well as During the garbage collection, relocation of the second data from the first super block to the second super block is avoided.

13. The storage device according to claim 12, wherein the controller is further configured to: identifying a range of logical addresses associated with the first region; Obtaining, from a logical-to-physical (L2P) mapping table, a physical address in the nonvolatile memory to a logical address in the first range of logical addresses; determining, using the L2P map, the super blocks that respectively include the data associated with the first regions; and In response to the determination, the Super Block including the first Super Block is added to the Super Block List.

14. The storage device according to claim 12, wherein the controller is further configured to: allocating a first sub-driver and a second sub-driver in the non-volatile memory, the first sub-driver comprising a first plurality of super blocks for storing data overwrites, and the second sub-driver comprising a second plurality of super blocks for storing contiguous data, the first plurality of super blocks comprising the first super block, and the second plurality of super blocks comprising the second super block; as well as relocating the first data from the first superblock in the first sub-drive to the second superblock in the second sub-drive; Wherein the first sub-driver includes an over-allocation of the first plurality of super blocks, and the second sub-driver lacks an over-allocation of the second plurality of super blocks.

15. The storage device according to claim 14, wherein the non-volatile memory further comprises a plurality of third blocks; and The controller is further configured to: determining whether a total amount of rewriting of the data in the first sub-drive exceeds a threshold percentage of a capacity of the nonvolatile memory; and Relocating third data associated with the first zone from a third super block to the second super block in the second sub-drive, the second plurality of super blocks of the second sub-drive including the third super block, and the third super block including the third block, wherein the third data is relocated in response to the determination and in response to the third super block including a minimum valid page count (VPC) of the third super block and other super blocks in the second sub-drive. 16 . The storage device according to claim 15 , wherein the first data and the second data are data overwrites, and the third data is continuous data.

17. A storage device, comprising: a non-volatile memory, the non-volatile memory comprising a plurality of first blocks, a plurality of second blocks, and a plurality of third blocks; and A controller, the controller being configured to: Creating a first super block including the first block, a second super block including the second block, and a third super block including the third block; allocating a first sub-driver and a second sub-driver in the non-volatile memory, the first sub-driver comprising a first plurality of super blocks for storing data rewrites, and the second sub-driver comprising a second plurality of super blocks for storing contiguous data, the first plurality of super blocks comprising the first super block, and the second plurality of super blocks comprising the second super block and the third super block; writing first data associated with a first zone to the first Super Block, writing second data associated with a second zone to the first Super Block, and writing third data associated with the first zone to the third Super Block, the first zone including a first range of logical addresses and the second zone including a second range of logical addresses; During garbage collection of a plurality of Super Blocks that respectively include data associated with the first region, relocating the first data from the first Super Block to the second Super Block, and relocating the third data from the third Super Block to the second Super Block; as well as During the garbage collection, relocation of the second data associated with the second region from the first Super Block to the second Super Block is avoided.

18. The storage device according to claim 17, wherein the controller is further configured to: identifying a range of logical addresses associated with the first region; Obtaining, from a logical-to-physical (L2P) mapping table, a physical address in the nonvolatile memory to a logical address in the first range of logical addresses; determining, using the L2P map, the super blocks that respectively include the data associated with the first regions; and In response to the determination, the Super Block including the first Super Block and the third Super Block is added to a Super Block List that respectively includes data associated with the first region, and the garbage collection is for the Super Block in the Super Block List.

19. The storage device according to claim 17, wherein the controller is further configured to: determining whether a total amount of data rewrites in the first sub-drive exceeds a threshold percentage of the capacity of the nonvolatile memory; and In response to the determination and in response to the third super block including a minimum VPC of the valid page count (VPC) of the third super block and other super blocks in the second sub-drive, the first data in the first sub-drive and the third data in the second sub-drive are relocated to the second super block in the second sub-drive.

20. The storage device according to claim 17, wherein the first data and the second data are data overwrites, and the third data is continuous data.

Images