ZONE-BASED MEMORY CLEARANCE IN CNS-SSDS

Abstract

Aspects of a storage device are provided that incorporates zone-based garbage collection in a central nervous system. The storage device includes a network VM and a controller. The NVM contains first blocks, second blocks, and third blocks. The controller creates a first superblock containing the first blocks, a second superblock containing the second blocks, and a third superblock containing the third blocks. The controller allocates a first subdrive containing the first superblock for storing data overwrites and a second subdrive containing the second and third superblocks for storing sequential data in the NVM.In superblock garbage collection, where each block contains data from a specific zone, the controller moves written data for that zone from the first and third superblocks to the second superblock, while refraining from moving data from other zones from the first to the second superblock. This reduces the costs associated with storage devices, overprovisioning, and WAF (Web Application Framework).

Description

REFERENCE TO RELATED APPLICATION(S)

[0001] This application claims the benefit of, and hereby incorporates by reference for all purposes the entire contents of, U.S. Non-Provisional Application No. 18 / 349,088, entitled "Zone-Based Garbage Collection in CNS SSDs," filed in the U.S. Patent and Trademark Office on July 7, 2023, claiming priority to U.S. Provisional Application No. 63 / 383,232, filed November 10, 2022. BACKGROUND area

[0002] This disclosure relates generally to electronic devices and, more particularly, to storage devices. Introduction

[0003] Storage devices allow users to store and retrieve data. Examples of storage devices include non-volatile storage devices. Non-volatile memory generally retains data after power is turned off. An example of non-volatile memory is flash memory, which may include one or more arrays of NAND cells on one or more dies. Flash memory is found in solid-state devices (SSDs), Secure Digital cards (SD cards), and the like.

[0004] A 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 the zoned namespace can be used for a specific application. For example, the host can write data associated with different applications to different zones of the zoned namespace. SUMMARY

[0005] One aspect of a storage device is disclosed herein. The storage device includes a non-volatile memory including a plurality of first blocks and a plurality of second blocks. The storage device further includes a controller configured to create a first superblock including the first blocks and a second superblock including the second blocks; and, during garbage collection for a plurality of superblocks including data associated with a first zone, relocate first data associated with the first zone from the first superblock to the second superblock, wherein the first zone includes a first range of logical addresses.The controller is further configured to refrain from relocating second data associated with a second zone from the first superblock to the second superblock during garbage collection, wherein the second zone includes a second range of logical addresses that is different from the first range of logical addresses.

[0006] Another aspect of a storage device is disclosed herein. The storage device includes a non-volatile memory including a plurality of first blocks and a plurality of second blocks. The storage device further includes a controller configured to create a first superblock including the first blocks and a second superblock including the second blocks; and write first data associated with a first zone to the first superblock and second data associated with a second zone to the first superblock, wherein the first zone includes a first range of logical addresses and the second zone includes a second range of logical addresses.The controller is further configured to add the first superblock to a list of superblocks each including data associated with the first zone; relocate, during garbage collection for a plurality of superblocks in the list of superblocks, the first data from the first superblock to the second superblock; and refrain from relocating the second data from the first superblock to the second superblock during garbage collection.

[0007] Another aspect of a storage device is disclosed herein. The storage device includes a non-volatile memory including a plurality of first blocks, a plurality of second blocks, and a plurality of third blocks. The storage device further includes a controller configured to create a first superblock including the first blocks, a second superblock including the second blocks, and a third superblock including the third blocks; and allocating a first subdrive and a second subdrive in the non-volatile memory, wherein the first subdrive includes a first plurality of superblocks for storing data overwrites and the second subdrive includes a second plurality of superblocks for storing sequential data.The first plurality of superblocks includes the first superblock, and the second plurality of superblocks includes the second superblock and the third superblock. The controller is further configured to write first data associated with a first zone to the first superblock, second data associated with a second zone to the first superblock, and third data associated with the first zone to the third superblock, wherein the first zone includes a first range of logical addresses and the second zone includes a second range of logical addresses.The controller is also configured to, during garbage collection for a plurality of superblocks each including data associated with the first zone, relocate the first data from the first superblock and the third data from the third superblock to the second superblock; and refrain from relocating second data associated with the second zone from the first superblock to the second superblock during garbage collection.

[0008] It should be understood that other aspects of the storage device will become readily apparent to those skilled in the art from the following detailed description, in which various aspects of devices and methods are shown and described for illustrative purposes. As will be appreciated, these aspects may be implemented in other and different forms, and their various details may be modified in various other respects. Accordingly, the drawings and detailed description are to be considered as illustrative and not restrictive. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Various aspects of the present invention will now be illustrated in the detailed description by way of example and not by way of limitation with reference to the accompanying drawings, in which: Fig. 1 is a block diagram illustrating an exemplary embodiment of a storage device in communication with a host device. Fig. 2 is a conceptual diagram showing an example of a logical-to-physical mapping table in a non-volatile memory of the storage device of Fig. 1 illustrates. Fig. 3 is a conceptual diagram showing an example of zones in the storage device of Fig. 1 illustrates. Fig. 4 is a conceptual diagram illustrating an example of a random zone write area (ZRWA) associated with respective zones in the storage device of Fig. 1 is linked. Fig. 5 is a conceptual diagram illustrating an example of zone-based garbage collection in superblocks stored in different subdrives of a non-volatile memory in the storage device of Fig. 1 are assigned. Fig. 6 is a flowchart illustrating an example of a method for performing zone-based garbage collection as implemented by the storage device of Fig. 1 is carried out. Fig. 7 is a flowchart illustrating an example of another method for performing zone-based garbage collection as implemented by the storage device of Fig. 1 is carried out. Fig. 8 is a conceptual diagram illustrating an example of a controller that performs zone-based garbage collection in the storage device of Fig. 1. DETAILED DESCRIPTION

[0010] The detailed description set forth below, taken in conjunction with the accompanying drawings, is intended as a description of various exemplary embodiments of the present disclosure and is not intended to represent the only embodiments in which the present invention may be practiced. The detailed description includes specific details in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring the concepts of the present invention. Acronyms and other descriptive terminology are used for simplicity and clarity only and are not intended to limit the scope of the invention.

[0011] The words "exemplary" and "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 of manufacture does not require that all exemplary embodiments of the invention include the described components, structure, features, functionality, processes, advantages, benefits, or modes of operation.

[0012] In the context of the present invention, the term "coupled" refers to either a direct connection between two components or, where appropriate, an indirect connection to each other through interposed or intermediate components. However, if a component is described as "directly coupled" to another component, no interposed elements are present.

[0013] The following detailed description presents various aspects of a storage device in communication with a host device. 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. Accordingly, any reference to a particular device or method is intended only to illustrate the various aspects of the present invention, with the understanding that these aspects may have a wide range of applications without departing from the scope and spirit of the present disclosure.

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

[0015] In ZNS, host data is written to a zone strictly sequentially. For example, if the host issues a zone write command, sending the flash storage device a logical page of data to be written to flash memory at a specific logical address, the flash storage device moves a write pointer to the next logical address in the zone, and the host is expected to send data for that next logical page when it issues a subsequent zone write command. If the host does not follow this sequence (e.g., if the next write command from the host includes a logical address that is out of sequence, such as the same logical address in an attempted data overwrite), the flash storage device may issue an error and abort the zone write operation.This means that a host is generally not allowed to overwrite data at a particular logical address in a zone until the zone has been completely written.

[0016] However, ZNS can be extended to support data overwrites in a zone within a Zone Random Write Area (ZRWA) associated with that zone. For example, the host can send a zone open command to open a zone in ZRWA mode, and that mode can remain associated with the zone until the zone is complete. For a zone opened in ZRWA mode, the flash storage device can define a predefined area size (e.g., 1 MB), including a subrange of logical addresses in the zone that the flash storage device can make accessible to a host for overwrites. In response to a commit operation from either the host or the flash storage device, the flash storage device can move this predefined area size (a ZRWA window) to the next subrange of logical addresses in the zone.

[0017] The flash storage device can create superblocks from groups or combinations of erase blocks in non-volatile memory. These superblocks are configured to be exactly the same size as a zone. For example, if a zone size includes X MB of data, a superblock can correspondingly only store X MB of data. However, when data overwrites occur, such as in ZRWA mode, the host may have more than X MB written to a particular zone, and this additional data may not be stored in the superblock. This may cause the flash storage device to write the data to a different superblock in non-volatile memory.

[0018] For example, if the host issues a zone write command with a logical page of sequential or random data to a zone that supports ZRWA, the flash storage device may first store that logical page in a superblock allocated for initial writes to that zone in non-volatile memory, and the flash storage device may move a write pointer to the next logical address in the zone within the ZRWA window. The flash storage device may also create a corresponding L2P entry for the originally written zone data in the L2P mapping table. If the host issues a zone write command that specifies the same logical address within the ZRWA window as a previously issued zone write command (e.g.,a data overwrite), instead of aborting the write command as previously described, the flash storage device may store this next logical page in a standard superblock allocated for multi-zone overwrites in non-volatile memory. For example, although most host data written to a zone is sequential, a small percentage of host writes (e.g., 2%-5% of host writes) may be random in nature, and the host may therefore issue a zone write command with such random data to overwrite previously written sequential data. This may cause this standard superblock in non-volatile memory to fill up over time with data overwrites in multiple zones.

[0019] To reclaim this memory used by a respective zone for overwriting, a controller of the flash storage device may apply a zone-based garbage collection process, referred to in this disclosure as a "GC sweep." The controller may trigger the GC sweep in response to determining that a certain number of overwrites have occurred to the default superblock (e.g., the superblock allocated for overwrites of multiple zones in non-volatile memory), for example, when more than 2-3% of the storage capacity of the flash storage device includes data overwrites to one or more zones. During a GC sweep, the controller may return the respective zone data from this default superblock to an allocated superblock for a respective zone. For example, the controller may perform a compaction or garbage collection process that allows valid (e.g.,Combine the (originally written) zone data in a superblock with overwritten zone data in the standard superblock into a single superblock. The controller can perform this GC sweep for multiple zones, thereby compressing valid zone data into allocated superblocks for the respective zones. Zone-based garbage collection can reduce the write amplification factor (WAF) of the flash storage device.

[0020] In one example of this zone-based garbage collection (GC sweep), the flash storage device controller first selects a zone that has been overwritten and contains data to be returned to a single superblock, and the controller identifies the logical region for that zone. Using hardware accelerators in the controller (one of which may be a data processor), the controller retrieves the L2P entries, including the physical addresses of that zone's logical region, from an L2P mapping table that stores the logical and physical addresses of the zone's data. From this mapping table, the controller can retrieve all the physical addresses in non-volatile memory where the zone's data is located. The controller then maps these physical addresses to the superblocks it contains.For example, the controller may have grouped combinations of erase blocks into corresponding superblocks, allowing the controller to identify the superblocks associated with these physical addresses. Once the controller has identified these superblocks, it maps the zone data from these superblocks to a specific, empty target superblock. The controller reuses the superblocks individually.

[0021] During the recycle process, the flash storage device can utilize a recycle read module and a recycle write module of the controller. The empty destination superblock, into which the controller wants to consolidate the data, can be assigned to the recycle write module, and the list of superblocks identified by the controller that contain the zone's data can be assigned to the recycle read module. The recycle read module processes the list of superblocks, one superblock at a time. When the recycle read module processes a specific superblock (the source superblock), the recycle read module reads a manifest within the superblock that provides information about what data is being written where in the superblock. Using the manifest, the controller can filter out the zone's data within that superblock.Once the controller has identified the portion of the entire superblock containing the data of interest to that zone, the controller reads that specific data, and the recycle write module writes that data to the destination superblock. This exercise can occur for all source superblocks in the list identified by the controller and continues until the list of source superblocks is completely processed (exhausted). Finally, a destination superblock containing the zone's data is compacted. At this point, the zone's data is no longer split across different superblocks but consolidated into a single superblock. As a result of the garbage collection process, the zone data is effectively removed from multiple superblocks and placed into one superblock for that zone.

[0022] Fig. 1 shows an exemplary block diagram 100 of a storage device 102 communicating with a host device 104 (also referred to as a "host") according to an exemplary embodiment. The host 104 and the storage device 102 may form a system, such as a computer system (e.g., server, desktop, mobile phone / laptop, tablet, smartphone, etc.). The components of Fig. 1 may or may not be physically located together. In this regard, the host 104 may be located remotely from the storage device 102. Although Fig. While Figure 1 illustrates that host 104 is shown separate from storage device 102, in other embodiments, host 104 may be fully or partially integrated into storage device 102. Alternatively, host 104 may be distributed across multiple remote units, either in its entirety or alternatively with some functionality located within storage device 102.

[0023] Those skilled in the art will recognize that other exemplary embodiments may be more or less Fig. 1, and that the disclosed processes may be implemented in other environments. For example, other exemplary embodiments may include a different number of hosts communicating with storage device 102 or multiple storage devices 102 communicating with the host(s).

[0024] The host device 104 may store data in and / or retrieve data from the storage device 102. 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 computer (e.g., a laptop computer), a tablet computer, a mobile computing device such as a smartphone, a television, a camera, a display device, a digital media player, a video game console, a video streaming device, or the like. 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, or the like. The host memory 103 may be used by the host device 104 to store data or instructions processed by the host or received from the storage device 102.In some examples, host memory 103 may include non-volatile memory, such as magnetic storage devices, optical storage devices, holographic storage devices, flash storage 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 (FRAM) devices, and any other type of non-volatile storage 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, and the like).The host memory 103 may also include both non-volatile memory and volatile memory, whether integrated with each other or as discrete units.

[0025] The host 104 may also include a host memory buffer (HMB 105). The HMB 105 is a portion of host memory (e.g., host memory 103 or other memory in the host 104) that the host 104 may allocate to the storage device 102 for use for the storage device's own purposes. For example, the storage device 102 may use the HMB 105 as an address mapping table cache or as 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, and the like). In other examples, the HMB 105 may include non-volatile memory.

[0026] The host interface 106 is configured to connect the storage device 102 to the host 104 via a bus / network 108, and may establish the connection using, for example, Ethernet or WiFi, or a bus standard such as Serial Advanced Technology Attachment (SATA), PCI Express (PCIe), Small Computer System Interface (SCSI), or Serial Attached SCSI (SAS), among other possible candidates. Alternatively, the host interface 106 may be wireless and may connect the storage device 102 using, for example, cellular communication (e.g., 5G NR, 4G LTE, 3G, 2G, GSM / UMTS, CDMA One / CDMA2000, etc.), wireless distribution methods through access points (e.g., 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), or comparable wide area network, local area network, and personal area network technologies to the host 104.

[0027] The storage device 102 includes a memory. In the exemplary embodiment of Fig. 1, the storage device 102 may include a non-volatile memory (NVM) 110 for permanently storing data received from the host 104. The NVM 110 may include, for example, flash integrated circuits, NAND memory (e.g., single-level cell (SLC) memory, multi-level cell (MLC) memory, triple-level cell (TLC) memory, quad-level cell (QLC) memory, penta-level cell (PLC) memory, or any combination thereof), or 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 include a cross-point architecture, including a 2D NAND array of NVM memory locations 112 with n rows and m columns, where m and n are predefined according to the size of the NVM. In the exemplary embodiment of FIG. Fig. 1, each NVM memory location 112 may be a die 114 including multiple levels, each including multiple blocks of multiple cells 116. Alternatively, each NVM memory location 112 may be a level including multiple blocks of cells 116. The cells 116 may be, for example, single-level cells, multi-level cells, three-level cells, four-level cells, and / or five-level cCells. Other examples of NVM memory locations 112 are possible; for example, each NVM memory location may be a block or a group of blocks. Each NVM memory location may include one or more blocks in a 3-D NAND array. Each NVM memory location 112 may include one or more logical blocks that map to one or more physical blocks. Alternatively, the memory and each NVM memory location may be implemented in other ways known to those skilled in the art.

[0028] The storage device 102 also includes one or more volatile memories 117, 118, which may include, for example, a dynamic random access memory (DRAM) or a static random access memory (SRAM). For example, as shown in Fig. 1, the volatile memory 117 may be an SRAM located within (or integrated with) the controller 123 of the storage device 102, while the volatile memory 118 may be a DRAM located external to (or remote from) the controller 123 of the storage device 102. However, in other examples, the volatile memory 117 may be a DRAM external to the controller 123 and the volatile memory 118 may be an SRAM within the controller 123, where the volatile memories 117 and 118 may both be internal to the controller 123 or both external to the controller 123, or alternatively, the storage device 102 may include only one of the volatile memories 117, 118. Data stored in the volatile memory 117, 118 may include data to be read from the NVM 110 or data to be written to the NVM 110.In this regard, the volatile memory 117, 118 may include a write buffer or a read buffer for temporarily storing data.

[0029] 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 the cells 116 of any of the NVM storage locations 112. As an example, Fig. 1, the data 119 is stored in different NVM storage locations 112, although the data may also be stored in the same NVM storage location. In another example, the NVM storage locations 112 may be different dies, and the data may be stored in one or more of the different dies.

[0030] Each data element 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 links all data 119 to a logical address. The L2P mapping table 120 stores the mapping of logical addresses specified for data written by the host 104 to physical addresses in the NVM 110, indicating the location(s) where each data element of the data is stored. This mapping may be performed by the storage device controller 123. The L2P mapping table may be a table or other data structure that includes an identifier, such as a physical address, associated with each storage location 112 in the NVM where data is stored. Fig. 1 illustrates a single L2P mapping table 120 stored in volatile memory 118. In other examples, L2P mapping table 120 may include multiple tables stored in volatile memory 118. Mappings may be updated in L2P mapping table 120 in response to host write operations, and L2P mapping table 120 may be periodically flushed from volatile memory 118 to one or more of NVM storage locations 112 of NVM 110 so that the mappings persist across power cycles. In the event of a power failure in storage device 102, L2P mapping table 120 may be restored to volatile memory 118 during initialization from the L2P entries previously stored in NVM 110.

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

[0032] With further reference to Fig. 1, the NVM 110 includes sense amplifiers 124 and data latches 126 connected to each NVM memory location 112. For example, the NVM memory location 112 may be a block including cells 116 on multiple bitlines, and the NVM 110 may include a sense amplifier 124 on each bitline. Additionally, one or more data latches 126 may be connected to the bitlines and / or sense amplifiers. The data latches may be, for example, shift registers. When data is read from the cells 116 of the NVM memory location 112, the sense amplifiers 124 sense the data by amplifying the voltages on the bitlines to a logic level (e.g., readable as a "0" or a "1"), and the sensed data is stored in the data latches 126.The data is then transferred from the data latches 126 to the controller 123, whereupon the data is stored in the volatile memory 118 until transferred to the host device 104. When data is written to the cells 116 of the NVM storage location 112, the controller 123 stores the programmed data in the data latches 126, and the data is subsequently transferred from the data latches 126 to the cells 116.

[0033] The storage device 102 includes a controller 123 that includes circuitry such as one or more processors for executing instructions, and may include a microcontroller, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a system-on-chip (SoC), a field-programmable gate array (FPGA), hard-wired logic, analog circuitry, and / or a combination thereof.

[0034] 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 amplifiers 124 to capture the data from the cells 116 into data latches 126, and the controller 123 may receive the data from the data latches 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 data to the data latches 126 to be programmed into the cells 116. The controller 123 is further configured to access the L2P mapping table 120 in the NVM 118 when reading or writing data to the cells 116.For example, in response to read or write commands from host device 104, controller 123 may receive logical-to-physical address mappings from volatile memory 118, identify the physical addresses associated with the logical addresses identified in the commands (e.g., translate the logical addresses into physical addresses), and access or store data in cells 116 located at the associated physical addresses. Controller 123 is further configured to access L2P mapping table 120 in NVM 110, for example, after a power failure during initialization, to restore or populate L2P mapping table 120 in volatile memory 118.

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

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

[0037] The host 104 can retrieve data from the storage device 102 by sending a read command specifying one or more logical addresses associated with the data to be retrieved from the storage device 102 and a 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 translate the logical addresses specified in the read command into the physical addresses that indicate the location of the data. The controller 123 then reads the requested data from the NVM storage location 112 specified by the physical addresses by sensing the data using the sense amplifiers 124 and storing it in data latches 126 until the read data is returned to the host 104 via the host interface 106.

[0038] Fig. 3 illustrates a conceptual diagram 300 of an example of zones 302. Each zone 302 has a fixed size and encloses a contiguous range of sequential 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, each zone enclosing a range of nm sequential LBAs, where z represents the total number of sectors in the flash memory, x represents the number of zones, m represents a first LBA in a zone, and n-1 represents a last LBA in the same zone. Each zone may be used separately by the host to store data associated with one or more applications executed by the host.The controller 123 can calculate the number of zones and thus determine the different ranges of sequential logical addresses 304 in the different zones based on a fixed zone size and the capacity of the storage device 102. For example, if the capacity of the storage device is 8 TB and the fixed zone size is 1 GB, the controller 123 can determine the number of zones to be 8000 by dividing the capacity of the storage device by the fixed zone size (8 TB / 1 GB = 8000).

[0039] Controller 123 may determine a definition of zones 302 (e.g., groups of logical addresses 304) in storage device 102. For example, controller 123 may determine that one group of LBAs or one logical block is associated with a first zone, that another group of LBAs or another logical block 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 the LBAs associated with the first zone to a first superblock (e.g., one or more of NVM locations 112), the LBAs associated with the second zone to a second superblock (e.g., one or more other of NVM locations 112), and so on. The controller 123 can then write and read data 119 to and from the physical block(s) associated with the zones 302.For example, when data is written to a zone, the controller 123 may create associated L2P entries for that zone data in the L2P mapping table 120, 205 in the volatile memory 118, and the data associated with the respective logical addresses may be written, if available, to one or more superblocks associated with the zone.

[0040] Typically, in ZNS, host data (e.g., data 119, 202) is written sequentially to a zone. For example, if host 104 issues a zone write command sending controller 123 a logical page of data to be written to NVM 110, 201 at a specific logical address, controller 123 moves a write pointer to the next logical address in zone 302, and host 104 is expected to send data for this next logical page when it issues a subsequent zone write command. If the host does not follow this sequence (e.g., if the next write command from the host includes a logical address that is not in the sequential order, such as the same logical address in an attempted data overwrite), controller 123 may issue an error and abort the zone write operation. For example, with reference to Fig. 3 If the host 104 first writes data to LBA 0 of zone 0 and then sends a write command to overwrite data in LBA 0 of zone 0, the controller 123 may generate an error because it has not received a command to write to the expected LBA 1. As a result, the host 104 generally does not overwrite sequential data at a given logical address in a zone until the zone is completely written.

[0041] However, the CNS can be extended to support data overwrites in a zone within a Zone Random Write Area (ZRWA) associated with that zone. In one possible application of ZRWA, the controller 123 may initially store data overwrites for respective zones in volatile memory 118 (e.g., SRAM), and the controller may later flush these data overwrites from volatile memory 118 to NVM 110, 201 in response to a commit operation. However, storage devices generally have a limited amount of volatile memory 118, and therefore, this approach may not be sufficient to handle the potentially large amount of data overwrites that the controller 123 may receive for various zones.Accordingly, in another application of ZRWA, the controller 123 may not store these data overwrites in the volatile memory 118, but instead write the data overwrites for the respective zones directly to the NVM 110, 201. For example, in addition to writing valid data for a zone 302 in the NVM 110, 201 to a superblock allocated for that zone, the controller 123 may also write data overwrites for zone 302 and other zones to a standard superblock allocated for that purpose in the NVM 110, 201. This approach may reduce the costs that would otherwise be incurred by using SRAM for ZRWA.

[0042] Fig. 4 illustrates a conceptual diagram 400 of an example of zones 402, each associated with a ZRWA 404. Initially, the host 104 may send the controller 123 an open zone 402 command to open a zone in a ZRWA mode, and that mode may remain associated with the zone 402 until the zone is complete. For a zone 402 opened in a ZRWA mode, the controller 123 may define a ZRWA window 406 of a predefined range size (e.g., 1 MB), including a subrange of logical addresses in the zone that the controller 123 may make accessible to the host 104 for overwriting. In response to a commit operation from either the host 104 or the controller 123, the controller may move the ZRWA window 406 to a next subrange of logical addresses in the zone 402.As an example, if the host 104 issues a zone write command with a logical page of sequential or random data to a zone 402 that supports the ZRWA 404, the controller 123 may initially store this logical page in a superblock allocated for initial writes to this zone in the NVM 110, 201, and the controller 123 may move a write pointer 407 to the next logical address in the zone 402 within the ZRWA window 406. The controller may also create an associated L2P entry 206 for the originally written zone data in the L2P mapping table 120, 205. If the host 104 issues a zone write command that specifies the same logical address within the ZRWA window 406 as a previously issued zone write command (e.g.,If a data overwrite occurs, instead of aborting the write command as previously described, the controller 123 may store this next logical page in a standard superblock allocated for multiple zone overwrites in non-volatile memory. The controller 123 may similarly create an associated L2P entry 206 for the overwritten zone data in the L2P mapping table 120, 205.

[0043] On the other hand, if the host 104 issues a zone write command specifying a next logical address in the sequence corresponding to the current location of the write pointer 407, the controller 123 may store this next logical page in the superblock allocated for initial writes to this zone 402 and again move the write pointer 407 to the next logical address in the zone within the ZRWA window 406. Thus, data may continue to be written or overwritten, L2P entries 206 may be created, and the write pointer 407 may be moved within the ZRWA window 406 until either the host 104 issues an explicit commit command 408 or until the ZRWA window 406 becomes full (e.g., until the entire subrange of logical addresses in the ZRWA window has been written, triggering an implicit commit command 410 by the controller 123).In response to the commit operation, the controller 123 may move the ZRWA window 406 to the next subrange of logical addresses in the zone 402 (e.g., a subsequent predefined range size of 1 MB), starting after the last committed logical address (e.g., starting at the current position of the write pointer), and data writes or overwrites within the new ZRWA window may continue in a similar manner as previously described. Similarly, the controller 123 may continue to create associated L2P entries for this zone data in the L2P mapping table 120, 205.

[0044] However, if the controller 123 stores data overwrites for a zone in a superblock in the NVM 110, 201 (e.g., in ZRWA mode), such storage may complicate the CNS practice of allocating individual superblocks to individual zones. A superblock is a logical block that includes (e.g., mapped to) multiple physical blocks in different memory dies of the storage device 102. In storage devices employing CNS, the controller 123 generally allocates a single superblock sized to store the same amount of data as a single zone. For example, if a zone stores X MB of data, the superblock of physical blocks is allocated to different memory dies that together store X MB of data. Thus, if data overwrites for a zone are not supported (e.g.,If a zone 302, 402 is not opened in a ZRWA mode and therefore only sequential data writes are permitted, the single superblock itself may be sufficient to store that zone's data. However, if overwriting data in non-volatile memory is supported for a zone (e.g., if zone 302, 402 is opened in a ZRWA mode), a single superblock itself may no longer be sufficient to store the zone data, because the superblock may include invalid data due to these data overwrites and may therefore be fully programmed before the zone is fully written.This may result in the controller writing these data overwrites to at least one standard overprovisioned superblock in NVM 110, 201 allocated for this purpose. However, whereas individual superblocks, each storing data associated with individual zones, may store data overwrites for multiple zones in these overprovisioned superblocks. For example, if, as discussed with respect to [ ]. Fig. 4, if a superblock for Zone 0 becomes full with valid and invalid data for Zone 0, and if a superblock for Zone 1 also becomes full with valid and invalid data for Zone 1, the controller may write data overwrites for Zone 0 and data overwrites for Zone 1 to the same overprovisioned superblock allocated for this purpose in the NVM 110, 201. As a result of this overprovisioning, the write amplification factor (WAF) of the storage device 102 may be significantly degraded.

[0045] To address this complication in CNS devices, controller 123 may employ a zone-based garbage collection process (e.g., a reclaim or recycle process for a zone), in which controller 123 retrieves valid zone data from a superblock associated with that zone, as well as the overwritten zone data in the overprovisioned superblocks associated with multiple zones, and consolidates or compresses this zone data into a single superblock for that zone. To achieve this result, controller 123 may obtain a zone identifier, and controller 123 (e.g., a data processor or hardware accelerator of the controller) may use this zone identifier to identify the L2P entries associated with the logical addresses for the zone.Using these L2P entries, controller 123 can identify the physical addresses associated with the zone. Based on these physical addresses, controller 123 can identify the logical addresses of the superblock, including the originally written sequential data for that zone, and the overprovisioned superblocks, including data overwrites, for that zone. Controller 123 can then add the superblocks associated with these logical superblock addresses to a memory reuse superblock list, and controller 123 can perform garbage collection for the zone individually using each superblock in the list.

[0046] For example, when performing garbage collection for a particular zone, the controller 123 may read the zone data stored in an associated superblock in the list (i.e., a source superblock or a recycle-read superblock), and the controller may recycle this zone data from the associated superblock into a single superblock (i.e., a destination superblock or a recycle-write superblock). The controller 123 may repeat this process for each superblock associated with the given zone (e.g., in a loop), replacing each reused source superblock with another superblock in the list until the zone data from each source superblock in the list has been transferred to the destination superblock.Thus, the valid data of a given zone can be consolidated into a destination superblock from at least two source superblocks, including a superblock that stores the initial, sequentially written data for the associated zone (the original superblock before overwrites) and at least one other overprovisioned superblock that stores the subsequently overwritten data for the given zone and other zones. Depending on the amount of data overwrites that have occurred for the various zones, there may be more than one overprovisioned superblock. Furthermore, to ensure that the controller 123 only transfers the data of the given zone in the overprovisioned superblock during the garbage collection process (e.g., the data overwrites for zone 0, but not the data overwrites for zone 1), the controller can utilize a manifest associated with the superblock.This manifest can be, for example, metadata stored in the superblock specifying logical pages or other information (e.g., in the header of a physical page, etc.) that the controller can use to determine the correct zone data to transfer and to determine which zone data should be skipped during the garbage collection process. At the end of the garbage collection process, a consolidated superblock containing all valid zone data (including overwrite data) can be formed.

[0047] The controller 123 can form superblocks in one of several subdrives of the storage device 102. A subdrive is defined herein as a logical group or combination of superblocks. The controller can assign superblocks to one of two subdrives, referred to in this disclosure as subdrive 0 and subdrive 1, depending on the state of a superblock individually associated with a zone. For example, the first time the controller writes data to a zone, the controller can form a superblock for that zone and assign it to subdrive 1. The controller can then write that data, as well as subsequent host data, to the superblock in the sequential order of the logical addresses associated with the zone.In response to respective zone write commands for these other zones, the controller can similarly form and allocate individual superblocks for these other zones, thus creating a one-to-one mapping of the superblocks to the zones. If the controller later receives a command to overwrite data in an associated zone (e.g., a zone write command that includes a previously written logical address for that zone), the controller can form another superblock and assign it to subdrive 0, and the controller can write this data overwrite to this superblock for the associated zone, as well as subsequent data overwrites for that zone and other zones to this same superblock. Similarly, if a superblock associated with a corresponding zone in subdrive 1 is completely written with valid and invalid data (e.g.,due to data overwrites), the controller subsequently receives a write command for that zone from the host, whereby the controller can also write that sequential data to the superblock in subdrive 0. This results in the controller being able to write data for a given zone to a superblock specifically associated with that zone in subdrive 1, as well as store overwritten or originally written data for that zone in an overprovisioned superblock that can store data for multiple zones in subdrive 0.

[0048] Thus, subdrive 1 for zone data in a CNS can have 0% overprovisioning, while subdrive 0 can have 100% overprovisioning. For example, the controller in subdrive 1 can only create one superblock for a given zone (there is a strict one-to-one mapping between superblocks and zones in subdrive 1). Therefore, if a superblock becomes full due to invalid data from data overwrites before the associated zone is full, the controller cannot write valid data to that zone in another superblock in subdrive 1. Instead, the controller can write this valid data to superblocks in subdrive 0, including data overwrites and initially written data after the superblock in subdrive 1 is full.In contrast, the controller may not write initial zone data to subdrive 0 (as opposed to overwriting data) if a superblock associated with that zone in subdrive 1 is not full. Therefore, subdrive 1 can be considered to not involve overprovisioning of zone data, while subdrive 0 only involves overprovisioning of zone data (that is, the controller can write to a superblock in subdrive 0 whenever there is an overflow of zone data in a superblock in subdrive 1). The controller can write such overflow data for multiple zones to the same superblock in subdrive 0.

[0049] Accordingly, the controller 123 may perform zone-based garbage collection (e.g., a recycle write operation or GC sweep) to consolidate zone data stored in different subdrives of the NVM 110, 201. When determining whether or not to initiate zone-based garbage collection for any zone, the controller 123 may maintain a total number of data overwrites written to the overprovisioned blocks of the storage device 102 in subdrive 0, and the controller 123 may determine whether the total amount of storage occupied by these data overwrites in subdrive 0 exceeds a certain threshold or percentage of the total capacity of the NVM 110, 201, including subdrive 0 and subdrive 1 (e.g., 3-4% or another threshold percentage). In such a case, the controller may perform the GC sweep for a respective zone.The threshold can therefore serve as a trigger point for the GC sweep.

[0050] Additionally, when determining which zone in subdrive 1 should be reused (e.g., where the controller can store zone-compressed superblocks or initially written zone data), the controller can identify which superblock in subdrive 1 has the lowest valid page count (VPC) or otherwise the smallest amount of valid zone data (the least valid), determine the zone associated with that superblock as the victim zone, and perform the above-mentioned recycle write process for that victim zone.For example, after the controller has written sequential data to and overwritten data in various zones (but has not yet performed zone-based garbage collection for these various zones), the superblocks individually associated with these respective zones in subdrive 1 may contain different numbers of invalid pages depending on the amount of data overwrites that have occurred for the respective zones. Accordingly, to maximize the amount of reclaim for a zone that can occur through zone-based garbage collection, the controller can select the zone with the least validity (e.g., the largest amount of data overwrites) as the target zone for the GC sweep. The controller can also perform this zone-based garbage collection for other associated zones (e.g.,in ascending order of VPCs, or otherwise in order from least to most valid) until the total amount of memory used by these data overwrites falls below the threshold percentage specified above (for example, to 2%). At this point, the trigger condition for a GC sweep may no longer be met, and zone-based garbage collection will terminate.

[0051] Fig. 5 illustrates an example 500 of zone-based garbage collection (GC sweep) performed on superblocks allocated in different subdrives 502 of NVM 504. In this example, subdrive 1 may include superblocks 506, each associated with different zones, while subdrive 0 may include superblocks 508 that include data overwrites of multiple zones. Each superblock 506 in subdrive 1 may include a plurality of blocks 510 that store data at different logical addresses in a single zone. For example, if NVM 504 includes N zones, subdrive 1 may include N superblocks, where each superblock includes physical blocks that store originally written, sequential data for a single zone (e.g., in a sequential order of logical addresses for the respective zone).Superblock(s) 508 in subdrive 0, on the other hand, may each include blocks 510 that store data at different logical addresses across multiple zones. For example, if NVM 504 includes N zones, subdrive 0 may include a superblock that includes physical blocks that store overwritten data in up to N zones (e.g., data overflowed from subdrive 1). Subdrive 0 may also include an overprovision 512 (e.g., one or more additional superblocks) that can also store data overwrites for multiple zones (e.g., when superblock(s) 508 become full). In addition, NVM 504 may include a free superblock 514 (e.g., an N+1 superblock), which may remain available and unassigned to a zone until the controller designates that free superblock as the target superblock for a target zone in a zone-based GC. For example, the controller in the example of . Fig. 5 to perform a GC 516 of Zone 1 using Superblock 1 as the source superblock, and the controller may use the free superblock 514 as the destination superblock for this GC 516 of Zone 1 (in Fig. 5 (referred to as Superblock 1) in subdrive 1.

[0052] To perform a zone-based GC, the controller 123 may, in one example, determine which of the N superblocks in subdrive 1 has the least validity (e.g., the lowest VPC), and apply that superblock 506 for the GC sweep. For example, in the example of Fig. 5, where NVM 504 includes N zones, the controller 123 may determine that superblock 1 (associated with zone 1) has a validity of 94% (e.g., 94 valid pages per 100 pages), while the other N-1 superblocks in subdrive 1 have a validity of 95% or more, and therefore the controller may determine to apply a GC sweep to zone 1. This process, in which the controller selects the zone or superblock with the least validity for the GC sweep, is referred to in this disclosure as victim selection (or victim zone selection). Through victim selection, the controller may select the zone that has the least valid data in subdrive 1 and thus the most valid data in subdrive 0, and therefore, during a GC sweep, the controller may free or reclaim the zone that occupies the most space in subdrive 0. For example, if superblock 1 has the least validity of all superblocks in subdrive 1 (e.g.94% validity), then the data for Zone 1 in the overprovisioned superblock in subdrive 0 can include the largest amount of valid data available for zone-based GC of all zones (e.g., 6 valid pages per 100 pages, which here represents the maximum number of valid pages that can be reclaimed in response to a GC sweep of a single zone). Thus, the controller in the example of . Fig. 5 Select Zone 1 as the victim zone because applying GC 516 to this zone would result in the largest amount of memory in Superblock 508 being freed or reclaimed for later use (compared to applying GC to other zones).

[0053] However, before the controller 123 even performs a victim selection to determine a particular zone for a zone-based GC, the controller may determine whether a trigger for a GC sweep in general (for any zone) has occurred. For example, the controller may determine whether the total amount of storage occupied by data stored in superblocks 508 of subdrive 0 exceeds a threshold percentage of the total available physical capacity of the NVM 110, 201, 504. For example, with reference to the example of Fig. 5 identify the total amount of storage currently used by zone data in subdrive 0, including the zone data stored in blocks 510 of superblock 508 for all zones 1-N and any other zone data that may be stored in overprovisioning 512 (e.g., one or more other superblocks that include zone data in subdrive 0). The controller may then determine whether the total amount of storage used in subdrive 0 exceeds a configured threshold percentage (e.g., 3% or another percentage) of the total storage capacity combined in subdrive 0 and subdrive 1, in which case the controller may trigger a GC sweep and identify a victim zone.For example, if the total capacity of the NVM 504, including its two subdrives, is 100 GB, and the controller then determines that the total amount of memory used by valid zone data in subdrive 0 is at least 3 GB, the controller can determine to perform a zone-based GC on whatever zone currently has the lowest VPC of all zones in subdrive 1. For example, in the example of . Fig. 5 Perform GC 516 for Zone 1 in response to the determination that the general GC sweep trigger has been met and further in response to the determination that Zone 1 has the least validity.

[0054] The GC sweep is different from non-zone-based GC, such as GC 518 in the example of Fig. 5. For example, if the controller performs a GC 518 of the superblock 508 in subdrive 0, the controller generally compresses the valid data of the superblock 508 in the overprovision 512 (e.g., in a destination superblock in subdrive 0), and the controller can reclaim the source superblock in subdrive 0 for subsequent zone data usage. This compression is zone-independent because the controller can transfer (read and write) valid data associated with multiple zones in the superblock 508 to the same destination superblock in subdrive 0. However, if there is not enough overprovision for compression, the controller may not perform the GC 518. For example, in the example of Fig. 5, it may happen that the controller 123 does not perform a GC 518 within subdrive 0 if there is insufficient overprovisioning, which may be indicated by the occurrence of the general GC sweep trigger. To address this situation of insufficient overprovisioning, the controller may perform a zone-based GC or a GC sweep such as GC 516, in which the controller compresses the valid data of the superblock 508 in the superblock 506 associated with a victim zone in subdrive 1. This compression is zone-dependent, as the controller may refrain from transferring (reading and writing) valid data associated with zones other than the victim zone in the superblock 508 to the free superblock 514 or target superblock in subdrive 1.

[0055] Therefore, using the general GC sweep trigger, the controller can determine whether or not there is sufficient overprovisioning for GC 518 in subdrive 0, and thus whether the controller can perform GC 518 (a non-zone-based GC that stays within the same subdrive) to reclaim memory in superblock 508, or whether the controller can perform GC 516 (a zone-based GC between subdrives) to reclaim memory in superblock 508. If there is not enough overprovisioning for GC 518 in subdrive 0, the controller can be triggered to perform GC 516. For example, NVM 504 can typically include a limited number of superblocks in subdrive 0, so the amount of data overwrites that subdrive 0 typically tolerates can be very small (e.g., 2% of the total capacity of NVM 504 including subdrive 0 and subdrive 1).This tolerance value corresponds to the threshold percentage that the controller can consider when determining whether the trigger has occurred, which is why the controller can set the threshold percentage based on the amount of overprovisioning available in subdrive 0.

[0056] For example, one example assumes that the controller 123 has allocated 4% of the total capacity of the NVM 504 for data overwrites in subdrive 0 (including 2% of the capacity in the superblock 508 and a 2% capacity match in the overprovision 512). In such a case, even if the amount of data overwrites completely fills the superblock 508 (the 2% capacity), the 2% overprovision would still be sufficient to accommodate GC 518 because the 4% total capacity has not been exceeded. Therefore, a non-zone-based GC can be performed as long as no more than this 2% capacity is used to store data overwrites in the superblock 508.In other words, the controller can perform a non-zone-based GC to reclaim storage in the superblock 508 as long as the total capacity of the NVM 504 used by the zone data overwrites does not exceed the tolerance value or threshold percentage (e.g., 2%) of the storage device. In such a case, no sacrificial zone selection can be performed for GC 518 because, with non-zone-based GC, all zone data can be compressed into the same target superblock during overprovisioning 512.

[0057] However, if the total amount of data overwrites exceeds this 2% capacity of superblock 508, there may not be enough overprovisioning in subdrive 0 to accommodate the GC 518 within the same subdrive (e.g., the 4% of total capacity would be exceeded). Therefore, under such circumstances, the controller may not be able to perform non-zone-based GC. For example, continuing the above example with the 2% capacity, if storage device 102 can only tolerate 2% overwrites for each of 1,000 zones, each occupying 1 GB of storage, the storage device can tolerate a maximum of 20 GB of overwrites in subdrive 0 across all 1,000 zones.Therefore, if more than this amount of data has been written to subdrive 0, there may not be enough capacity left in subdrive 0 (the remaining 2% overprovisioning) to perform a non-zone-based GC within the same subdrive 0. Accordingly, in such a case, the controller may instead determine to perform the GC 516 from subdrive 0 to subdrive 1 to reclaim the memory in the superblock 508. In other words, if the total capacity of the NVM 504 used by the data overwrites ends up exceeding the tolerance value or threshold percentage (e.g., 3% or more), the controller may be triggered to perform the GC 516.Furthermore, because this GC occurs between a superblock with multiple zone data in subdrive 0 and a superblock with single zone data in subdrive 1, the controller may not perform a zone-independent GC, as it may have previously done before the threshold percentage was exceeded. Instead, the controller may choose to perform a zone-dependent GC (the GC sweep) to recycle zone data from a single zone as described above, for example, using victim selection for maximum reclaim efficiency.

[0058] Thus, in response to the GC sweep trigger and Zone 1 victim zone selection, the controller can transfer (i.e., read and write) Zone 1 sequential data from the source superblock 1 in subdrive 1 and from Zone 1 data overwrites in superblock 508 in subdrive 0 to the destination superblock 1' in subdrive 1. During GC 516, the controller can consolidate the valid Zone 1 data in superblock 1 of subdrive 1 with the valid Zone 1 data in the overprovisioned superblock of subdrive 0, while leaving the invalid Zone 1 data in superblock 1 of subdrive 1.For example, the controller can determine from the L2P mapping table 120, 205 in the volatile memory 118 the logical addresses of the superblocks in subdrives 0 and 1 that include data for Zone 1, and the controller can read the Zone 1 data from these superblocks and write the Zone 1 data to another superblock that is individually linked to the zone in subdrive 1. Furthermore, during the GC 516 (the zone-based GC), the controller can refrain from transferring (i.e., reading and writing) valid data of other zones from the superblock 508 in subdrive 0 to the target superblock 1' in subdrive 1, so that the target superblock for the GC sweep can only include valid data of the victim zone (Zone 1 in this example). Therefore, in the illustrated example of . Fig. 5 refrain from transferring Zone 2 data up to and including Zone N data in order to free superblock 514 when performing GC 516 in Zone 1. The controller may then delete the blocks of superblock 1 in subdrive 1 and later retain this superblock as the new, free superblock 514 until the controller later designates this superblock as the new target superblock for a target zone in a subsequent GC sweep.

[0059] Fig. 6 illustrates an exemplary flowchart 600 of a method for performing zone-based GC. For example, the method may be implemented in a storage device 102 such as the one shown in Fig. 1. Each of the steps in the flowchart may be controlled using the controller described below (e.g., controller 123), by a component or module of the controller, or by other suitable means.

[0060] As illustrated in block 602, the controller may download zone L2P entries from an L2P mapping table. For example, during a GC sweep (e.g., GC 516), the controller may access a mapping of zone IDs to logical regions (e.g., ZNS) and identify the logical region for a zone ID selected for the GC sweep. In one example, the zone ID may correspond to a victim zone that has the lowest VPC of all other zones, and the controller may select this zone ID after the GC sweep trigger occurs (e.g., based on the total capacity of the NVM 110, 201 used to overwrite zone data). Alternatively, the controller may select a different zone ID than the victim zone for the GC sweep, for example, any zone. The controller (e.g.,a data processor component of the controller) may retrieve the L2P entries associated with the zone corresponding to the zone ID from the L2P mapping table 120, 205, for example, entries 206 that include logical addresses 304 associated with the zone 302, 402 selected for the GC sweep.

[0061] As illustrated by block 604, the controller may establish a list of superblocks containing zone data. For example, after retrieving the L2P entries (e.g., entries 206), the controller may identify the physical addresses 208 of the blocks 510 storing data associated with the victim zone from the L2P mapping table 120, 205. The controller may then determine the superblocks 506, 508, including the blocks 510, associated with these physical addresses 208. For example, the controller may manage a mapping of the superblocks 506, 508 to the zones 302, 402, the logical addresses 304 associated with the zones 302, 402, and / or the physical addresses 208 of the blocks 510 associated with these logical addresses 304 separately from the L2P mapping table 120, 205, and the controller may determine the logical identifiers of these superblocks 506, 508 from this superblock mapping table.After retrieving the superblock identifiers, the controller can add these identifiers of the superblocks of the selected zone to a list or other data structure of source superblocks for the GC sweep (e.g., GC 516).

[0062] As illustrated by block 606, the controller may provide individual superblocks in the list as source superblocks for garbage collection. For example, the controller may perform the zone-based GC 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 the GC sweep (e.g., GC 516). During the GC, the controller (e.g., a recycle reader module of the controller) may retrieve the next source superblock ID in the list and retrieve the retrieved physical addresses 208 associated with the superblock 506, 508 currently being processed in the list. Then, as illustrated in block 608, the controller may perform a zone validity check in addition to an L2P validity check of the logical addresses associated with those retrieved physical addresses.For example, in addition to performing an L2P validity check, where the controller can determine from a manifest (e.g., metadata) for the current superblock the valid logical pages at the retrieved physical addresses (e.g., the logical pages that store valid data), the controller performs a zone validity check, where the controller can determine which of these valid logical pages are specifically associated with the selected zone being reclaimed (e.g., based on a comparison of the logical pages with a mapping of zones 302, 402 to logical addresses that the controller maintains separately from the L2P mapping table 120, 205). After determining the valid logical pages associated with the selected zone for the GC sweep, the controller reads (e.g.,The controller (e.g., a controller recycle read module) reads the valid zone data from the current source superblock to those specific logical pages (ignoring any logical / physical addresses or zone data outside the LBA range of the selected zone), and the controller (e.g., a controller recycle write module) writes that valid zone data to a new destination superblock. For example, referring to GC 516 in . Fig. 5 transfer the data of zone 1 from superblock 508 in subdrive 0 to the new superblock 1' in subdrive 1, while refraining from transferring data of other zones from this superblock in subdrive 0 to superblock 1' in subdrive 1.

[0063] The controller may repeat the above process similarly for each superblock in the list until the list is exhausted. For example, referring again to the GC 516 in Fig. 5, before or after processing the superblock(s) 508 in subdrive 0, transfer the zone 1 data from the superblock 506, referred to as superblock 1 in subdrive 1, to the free superblock 514, referred to as the new superblock 1' in subdrive 1. As a result, superblock 1' in subdrive 1 can be consolidated with the valid zone 1 data from both subdrive 1 and subdrive 0, and any invalid zone 1 data in the superblock 1 or subdrive 0 superblocks can then be erased and the corresponding storage reused or reclaimed.

[0064] Finally, as illustrated in block 608, the controller may return the superblocks in the source superblock list to a Flash Array Manager (FAM). The FAM is a module of the controller that can record the state of all superblocks (e.g., whether a particular superblock is partially or fully written, which subdrive the superblock belongs to, the respective blocks of the superblock, or other metadata of the superblock). The FAM may be responsible for creating / allocating a superblock, dealing with the creation / deallocation of a superblock, or performing other block management-level functions. When the controller receives a host write command for a superblock, the FAM may temporarily provide an empty superblock to a host write module of the controller to write to the superblock, after which the host write module may return the fully written superblock to the FAM.Similarly, with respect to the GC sweep, after the controller has identified the list of source superblocks for zone-based GC, the FAM can provide the superblocks in the list to the controller's recycle reader module for GC 516 processing. After the source superblocks are processed, the recycle reader module can return these superblocks to the FAM.

[0065] Fig. Figure 7 illustrates an exemplary flowchart 700 of another method for performing zone-based GC. For example, the method may be implemented in a storage device 102 such as the one shown in Fig. 1. Each of the steps in the flowchart may be controlled using the controller described below (e.g., controller 123), by a component or module of the controller, or by other suitable means.

[0066] As represented by block 702, the controller may allocate a first subdrive (e.g., subdrive 0) and a second subdrive (e.g., subdrive 1) in the non-volatile memory (e.g., NVM 110, 201, 504). The first subdrive may include a first plurality of superblocks for storing data overwrites (e.g., superblocks 508 in subdrive 0), and the second subdrive may include a second plurality of superblocks for storing sequential data (e.g., superblocks 506 in subdrive 1). The first subdrive (e.g., subdrive 0) may also include overprovisioning (e.g., overprovisioning 512) for the first plurality of superblocks (100% overprovisioning), while the second subdrive (e.g., subdrive 1) may not have overprovisioning for the second plurality of superblocks (0% overprovisioning).

[0067] As illustrated by block 704, the controller may create a first superblock including first blocks in non-volatile memory (e.g., superblock 508 including blocks 510 in subdrive 0 of NVM 504), a second superblock including second blocks in non-volatile memory (e.g., free superblock 514 including blocks 510 in subdrive 1 of NVM 504), and a third superblock including third blocks in non-volatile memory (e.g., superblock 506 including blocks 510 in subdrive 1 of NVM 504). The first plurality of superblocks in the first subdrive may include the first superblock (e.g., superblock 508 in subdrive 0), and the second plurality of superblocks in the second subdrive may include the second superblock and the third superblock (e.g., superblocks 506, 514 in subdrive 1).

[0068] As represented by block 706, the controller may write first data associated with a first zone to the first superblock (e.g., data 119, 202 associated with zone 1 in superblock 508), second data associated with a second zone to the first superblock (e.g., data 119, 202 associated with zone 2 in superblock 508), and third data associated with the first zone to the third superblock (e.g., data 119, 202 associated with zone 1 in superblock 506). The first zone may include a first range of logical addresses (e.g., logical addresses 304 in zone 1), and the second zone may include a second range of logical addresses that is different from the first range of logical addresses (e.g., different logical addresses 304 in zone 2). The first and second data may be data overwrites (e.g.stored in blocks 510 of superblock 508), while the third data may be sequential data (e.g., stored in blocks 510 of superblock 506, such as superblock 1 in . Fig. 5).

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

[0070] As represented by block 710, the controller may add the first superblock (e.g., superblock 508) to a list (e.g., a data structure) of superblocks, each including data associated with the first zone (e.g., zone 1). In addition, the controller may add the third superblock (e.g., superblock 506, referred to as superblock 1) to the list of superblocks, each including data associated with the first zone. To locate these superblocks and add them to the list, the controller may perform the steps described above with respect to blocks 602 and 604 of Fig. 6. For example, the controller may first identify a range of logical addresses associated with the first zone (e.g., logical addresses 304 of zone 1). The controller may then retrieve from an L2P mapping table (e.g., L2P mapping table 120, 205) an L2P mapping (e.g., entry 206) of a physical address in non-volatile memory (e.g., physical address 208) to a logical address in the first range of logical addresses (e.g., logical address 304 of zone 1). Next, using the L2P mapping (e.g., entry 206), the controller may determine the superblocks (e.g., superblocks 506, 508) that each include the data associated with the first zone (e.g., zone 1). Finally, in response to this determination, the controller may select the superblocks, including the first superblock (e.g., superblock 508) and the third superblock (e.g.,Superblock 506), add to the list of superblocks.

[0071] As illustrated by block 712, during garbage collection for a plurality of superblocks in the list of superblocks (e.g., GC 516 for superblocks 506, 508), the controller may relocate first data associated with the first zone (e.g., zone 1) from the first superblock in the first subdrive (e.g., superblock 508 in subdrive 0) to the second superblock in the second subdrive (e.g., free superblock 514 in subdrive 1). Similarly, the controller may relocate third data associated with the first zone (e.g., zone 1) from the third superblock in the second subdrive (e.g., superblock 1 in subdrive 1) to the second superblock in the second subdrive (e.g., free superblock 514 in subdrive 1). For example, the controller may perform the actions described above with respect to blocks 606 and 608 of Fig. 6. The controller may perform these relocations in response to the total amount of data overwrites determined in block 708 exceeding the threshold percentage (e.g., in response to determining that the aforementioned general GC sweep trigger has occurred). Further, as represented by block 714, the controller may relocate the first data and the third data to the second superblock in the second subdrive during garbage collection (e.g., to superblock 1' in subdrive 1 during garbage collection 516) in response to the third superblock (e.g., superblock 1 in subdrive 1) including a minimum VPC from the VPCs of the third superblock and other superblocks in the second subdrive (e.g., superblocks 506 in subdrive 1). This selection of the victim zone maximizes the efficiency of GC 516.Furthermore, as represented by block 716, the controller may refrain from moving second data associated with the second zone (e.g., zone 2) from the first superblock (e.g., superblock 508) to the second superblock (e.g., free superblock 514) during garbage collection (e.g., GC 516).

[0072] Fig. 8 is a conceptual diagram illustrating an example 800 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 the NVM 110, 201, 504 of the storage device 102 of Fig. 1. The controller may be implemented in software, hardware, or a combination of hardware and software. In one exemplary embodiment, the controller is implemented with multiple software modules executing on one or more processors, but as one skilled in the art will appreciate, the controller may be implemented in other ways. One skilled in the art will readily understand how best to implement the controller based on the particular design parameters of the system.

[0073] In one example, the controller 802 includes a zone-based GC module 806 that can provide: means for creating a first superblock including the first blocks, a second superblock including the second blocks, and a third superblock including the third blocks; means for allocating a first subdrive and a second subdrive in the non-volatile memory, wherein the first subdrive includes a first plurality of superblocks for storing data overwrites and the second subdrive includes a second plurality of superblocks for storing sequential data, wherein the first plurality of superblocks includes the first superblock and the second plurality of superblocks includes the second superblock and the third superblock;means for writing first data associated with a first zone to the first superblock, second data associated with a second zone to the first superblock, and third data associated with the first zone to the third superblock, the first zone including a first range of logical addresses and the second zone including a second range of logical addresses; means for relocating, during garbage collection for a plurality of superblocks each including data associated with the first zone, the first data from the first superblock and the third data from the third superblock to the second superblock; and means for refraining from relocating second data associated with the second zone from the first superblock to the second superblock during garbage collection. For example, the zone-based GC module 806 may implement the methods described above with respect to; Fig. 6 or Fig. Carry out the processes described in section 7.

[0074] Generally, ZNS devices have specific values ​​of overwrites that can be accommodated in SRAM (in ZRWA), and once a commit process occurs, the overwrites are written from SRAM to NAND (in the NVM). However, caching overwrites in SRAM can result in high costs when implementing ZNS with ZRWA. To reduce costs, the controller can write these overwrites to NAND (instead of SRAM) in a non-ZNS namespace in subdrive 0, and these overwrites can be moved to a ZNS namespace in subdrive 1 during reclamation / reuse. In particular, the controller can employ a recycle approach that reuses the data residing in the LBA range of a given zone in response to certain triggers (e.g., a general GC sweep trigger and victim zone selection).For example, using a data processor, the controller can download L2P zone entries from an L2P mapping table, create a list of superblocks containing the zone data, the reclaim of which is determined by the controller, feed the source superblocks to a recycle read module, and then, via its recycle read and recycle write modules, perform a GC that includes data reads, an L2P validation check, and data writes. In addition, the controller can also check the validity of the zone to confirm that the correct zone is being reused. Therefore, only one zone can be reused at a time.

[0075] Thus, the controller can relocate data from a first subdrive or group of logical superblocks to a second subdrive or group of logical superblocks based on metadata specifying a zone associated with the relocated data. For example, the controller can be configured to relocate data from a group of superblocks in one subdrive to another group of superblocks in another subdrive based on an indication of a zone associated with the data. Specifically, when relocating across subdrives, the controller can filter out the data from a victim zone and create a reuse list of superblocks containing that data.For example, instead of simply selecting any superblock for reuse, the controller can create or designate a list of superblocks for reuse, and instead of simply reusing all storage in those superblocks regardless of zones, the controller can filter out storage containing the data of a specific zone as the storage in the superblocks to be reused. While the zone for reuse can be chosen arbitrarily, selecting the victim zone can maximize the amount of space reclaimed in subdrive 0.

[0076] Additionally, because subdrive 1 has 0% overprovisioning while subdrive 0 has 100% overprovisioning, overprovisioning in the storage device can be significantly reduced compared to non-CNS devices (where all subdrives can have overprovisioning). Because subdrive 1 includes overprovisioning, to improve GC efficiency, the controller can be configured to perform storage claiming only on subdrive 0. Furthermore, if the controller determines that there are more average overwrites per zone than the storage device can tolerate (e.g., 2-3% of the total NVM capacity), the controller can move zone data from subdrive 0 to subdrive 1 in a GC sweep to maintain subdrive 0's overprovisioning. The small amount of overprovisioning in subdrive 0 can be reclaimed and thus used more efficiently.

[0077] This allows the storage device to use less SRAM, as overwrites can be stored directly in NAND rather than in cache, reducing the cost of the storage device. The controller can write the overwrites to NAND memory and later compress these overwrites into a corresponding superblock using the GC sweep with other data related to a specific zone. Additionally, the GC sweep allows the storage device to have a reduced WAF, as desired for CNS devices with certain workloads. The GC sweep allows the controller to reclaim space in a CNS device with reduced overprovisioning and thus reduced cost.

[0078] The various aspects of this disclosure are provided to enable one skilled in the art to practice the present invention. Various modifications to the exemplary embodiments presented in this disclosure will be readily apparent to those skilled in the art, and the concepts disclosed herein may be extended to all types of storage devices capable of storing data. Therefore, the claims are not intended to be limited to the various aspects of this disclosure, but are to be accorded the full scope of protection consistent with the language of the claims. All structural and functional equivalents to the various components of the exemplary embodiments described in this disclosure that are known or later become known to those skilled in the art are hereby expressly incorporated by reference and are intended to be embraced by the claims.Furthermore, nothing disclosed herein is intended for public disclosure, regardless of whether such disclosure is expressly recited in the claims. No claim element shall be construed pursuant to the provisions of 35 USC §112(f) in the United States or any comparable statute or legal principle in any jurisdiction unless the element is expressly recited using the phrase "means for" or, in the case of a method claim, using the phrase "step for." QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited patent literature

[0000] US 18 / 349,088

[0001] US 63 / 383.232

[0001]

Claims

[1] Storage device comprising: a non-volatile memory including a plurality of first blocks and a plurality of second blocks; and a controller that is set up to: Creating a first superblock enclosing the first blocks and a second superblock enclosing the second blocks; Relocating, during garbage collection for a plurality of superblocks including data associated with a first zone, first data associated with the first zone from the first superblock to the second superblock, the first zone including a first range of logical addresses; and Refraining from moving second data associated with a second zone from the first superblock to the second superblock during garbage collection, wherein the second zone includes a second range of logical addresses that is different from the first range of logical addresses. [2] The storage device of claim 1, wherein the controller is further configured to: Adding the first superblock to a list of superblocks, each enclosing the data associated with the first zone, where garbage collection is for superblocks in the list of superblocks. [3] The storage device of claim 2, wherein the controller is further configured to: Identifying a range of logical addresses associated with the first zone; Obtaining, from a logical-to-physical (L2P) mapping table, an L2P mapping of a physical address in the non-volatile memory to a logical address in the first range of logical addresses; Determining each of the superblocks enclosing the data associated with the first zone using the L2P mapping, wherein the first superblock is one of the superblocks. [4] The storage device of claim 1, wherein the controller is further configured to: Assigning a first subdrive and a second subdrive in the non-volatile memory, the first subdrive including a first plurality of superblocks for storing data overwrites and the second subdrive including a second plurality of superblocks for storing sequential data, the first plurality of superblocks including the first superblock and the second plurality of superblocks including the second superblock. [5] The storage device of claim 4, wherein the controller is further configured to: Move the first data from the first superblock in the first subdrive to the second superblock in the second subdrive. [6] The storage device of claim 4, wherein the first subdrive includes overprovisioning for the first plurality of superblocks and the second subdrive does not include overprovisioning for the second plurality of superblocks. [7] The storage device of claim 4, wherein the controller is further configured to: Determining whether the total amount of data overwrites in the first subdrive exceeds a threshold percentage of a capacity of the non-volatile memory; and Moving the first data from the first superblock in the first subdrive to the second superblock in the second subdrive in response to the total amount exceeding the threshold percentage. [8] The storage device of claim 4, wherein the non-volatile memory further includes a plurality of third blocks; and wherein the controller is further configured to: Creating a third superblock enclosing the third blocks, wherein the second plurality of superblocks of the second subdrive encloses the third superblock; and Move the third data associated with the first zone from the third superblock in the second subdrive to the second superblock in the second subdrive during garbage collection. [9] The storage device of claim 8, wherein the controller is further configured to: Determining whether the total amount of data overwrites in the first subdrive exceeds a threshold percentage of a capacity of the non-volatile memory; and Moving the third data from the third superblock in the second subdrive to the second superblock in the second subdrive in response to the total amount exceeding the threshold percentage. [10] The storage device of claim 9, wherein the controller is further configured to: Relocating the first data and the third data to the second superblock in the second subdrive in response to the third superblock including a smallest valid page number (VPC) from the VPCs of the third superblock and other superblocks in the second subdrive. [11] The storage device according to claim 1, wherein the first data and the second data are data overwrites. [12] Storage device comprising: a non-volatile memory including a plurality of first blocks and a plurality of second blocks; and a controller that is set up to: Creating a first superblock enclosing the first blocks and a second superblock enclosing the second blocks; Writing first data associated with a first zone to the first superblock and second data associated with a second zone to the first superblock, the first zone including a first range of logical addresses and the second zone including a second range of logical addresses; Adding the first superblock to a list of superblocks, each containing data associated with the first zone; During garbage collection for a plurality of superblocks in the list of superblocks, moving the first data from the first superblock to the second superblock; and Avoid moving the second data from the first superblock to the second superblock during garbage collection. [13] The storage device of claim 12, wherein the controller is further configured to: Identifying a range of logical addresses associated with the first zone; Obtaining, from a logical-to-physical (L2P) mapping table, an L2P mapping of a physical address in the non-volatile memory to a logical address in the first range of logical addresses; Determining each of the superblocks that include data associated with the first zone using the L2P mapping; and Adding, in response to the determination, the superblocks that include the first superblock to the list of superblocks. [14] The storage device of claim 12, wherein the controller is further configured to: Assigning a first subdrive and a second subdrive in the non-volatile memory, the first subdrive including a first plurality of superblocks for storing data overwrites and the second subdrive including a second plurality of superblocks for storing sequential data, the first plurality of superblocks including the first superblock and the second plurality of superblocks including the second superblock; and Moving the first data from the first superblock in the first subdrive to the second superblock in the second subdrive; wherein the first subdrive includes overprovisioning for the first plurality of superblocks and the second subdrive does not include overprovisioning for the second plurality of superblocks. [15] The storage device of claim 14, wherein the non-volatile memory further includes a plurality of third blocks; and wherein the controller is further configured to: Determining whether the total amount of data overwrites in the first subdrive exceeds a threshold percentage of a capacity of the non-volatile memory; and Relocating, into the second superblock in the second subdrive, third data associated with the first zone from a third superblock, wherein the second plurality of superblocks of the second subdrive includes the third superblock and the third superblock includes the third blocks, wherein the third data is relocated in response to the determination and in response to the third superblock including a first valid page number (VPC) from the VPCs of the third superblock and from other superblocks in the second subdrive. [16] The storage device according to claim 15, wherein the first data and the second data are data overwrites and the third data is sequential data. [17] Storage device comprising: a non-volatile memory including a plurality of first blocks, a plurality of second blocks, and a plurality of third blocks; and a controller that is set up to: Creating a first superblock enclosing the first blocks, a second superblock enclosing the second blocks, and a third superblock enclosing the third blocks; Assigning a first subdrive and a second subdrive in the non-volatile memory, the first subdrive including a first plurality of superblocks for storing data overwrites and the second subdrive including a second plurality of superblocks for storing sequential data, the first plurality of superblocks including the first superblock and the second plurality of superblocks including the second superblock and the third superblock; Writing first data associated with a first zone to the first superblock, second data associated with a second zone to the first superblock, and third data associated with the first zone to the third superblock, wherein the first zone includes a first range of logical addresses and the second zone includes a second range of logical addresses; Relocating, during garbage collection for a plurality of superblocks each including data associated with the first zone, the first data from the first superblock and the third data from the third superblock to the second superblock; and Avoid moving the second data associated with the second zone from the first superblock to the second superblock during garbage collection. [18] The storage device of claim 17, wherein the controller is further configured to: Identifying a range of logical addresses associated with the first zone; Obtaining, from a logical-to-physical (L2P) mapping table, an L2P mapping of a physical address in the non-volatile memory to a logical address in the first range of logical addresses; Determining each of the superblocks that include data associated with the first zone using the L2P mapping; and Adding, in response to the determination, the superblocks that include the first superblock and the third superblock to a list of superblocks that each include the data associated with the first zone, wherein garbage collection is for the superblocks in the list of superblocks. [19] The storage device of claim 17, wherein the controller is further configured to: Determining whether the total amount of data overwrites in the first subdrive exceeds a threshold percentage of a capacity of the non-volatile memory; and In response to determining and in response to the third superblock including a smallest valid page number (VPC) from the VPCs of the third superblock and other superblocks in the second subdrive, relocating the first data in the first subdrive and the third data in the second subdrive to the second superblock in the second subdrive. [20] A storage device according to claim 17, wherein the first data and the second data are overwritten data and the third data is sequential data.

Images