Data aggregation in ZNS drives

Abstract

The present invention is entitled "Data Aggregation in a ZNS Drive". The present disclosure as a whole relates to efficient data transfer management for partition append commands for a partition name space (ZNS). The ZNS storage device includes a memory device having a plurality of memory tube cores, and a controller coupled to the memory device. The controller receives a plurality of partition append commands, each partition append command being associated with a partition identifier that identifies a partition among a plurality of partitions; and extracts and aggregates data associated with each partition append command by the partition identifier in an append write buffer. When the aggregated data for each partition reaches a predetermined programming block size, the aggregated data is written to the memory device, or if the predetermined write size is not met, the aggregated data is written to a temporary buffer. When the aggregated data for programming is sent to the memory device, each partition uses a separate channel, thereby allowing multiple channels to be utilized in parallel.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application Serial No. 63 / 114,397, filed on November 16, 2020, which is incorporated herein by reference. Background Art Technical Field

[0004] Embodiments of the present disclosure generally relate to efficient data transfer management of zone attach commands for a zoned namespace (ZNS).

[0005] Description of related art

[0006] Zoned Namespaces (ZNS) is a new direction in storage where data storage devices restrict writes to sequential partitions. ZNS aims to reduce device-side write amplification and overprovisioning by aligning host write patterns with internal device geometry and reducing the need for device-side writes that are not directly linked to host writes.

[0007] ZNS offers many benefits, including: reduced cost due to minimal DRAM requirements per SSD (solid-state drive); potential savings due to reduced need to over-provision NAND media; better SSD lifespan by reducing write amplification; significantly lower latency; significantly improved throughput; and standardized interfaces that enable a robust software and hardware ecosystem.

[0008] Typically, in a ZNS environment, the data transfer size associated with each partition attach command is a block size (e.g., a NAND block size) or a multiple of a full block size (i.e., no size smaller than an entire block). Blocks (such as, for example, NAND blocks) reside in a single NAND die. Memory device parallelism involves accessing multiple NAND dies in parallel. To increase parallelism, more NAND dies need to be accessed in parallel. To effectively use memory device parallelism, many partition attach commands should be executed in parallel with interleaved data transfers. Otherwise, the write cache buffer will be significantly increased in order to utilize the memory device.

[0009] Therefore, there is a need in the art for a ZNS device with more efficient management of zone attach commands. Summary of the Invention

[0010] The present disclosure generally relates to efficient data transfer management for partition append commands for a partitioned namespace (ZNS). The ZNS storage device includes a memory device having a plurality of memory dies, and a controller coupled to the memory device. The controller receives a plurality of partition append commands, each partition append command being associated with a partition identifier that identifies a partition among a plurality of partitions; and extracts and aggregates data associated with each partition append command by the partition identifier in an append write buffer. When the aggregate data for each partition reaches a predetermined programming chunk size, the aggregate data is written to the memory device, or if the predetermined write size is not met, the aggregate data is written to a temporary buffer. When the aggregate data for programming is sent to the memory device, each partition uses a separate channel, thereby allowing multiple channels to be utilized in parallel.

[0011] In one embodiment, a data storage device includes: a memory device having a plurality of memory dies; a plurality of channels, each channel coupled to one or more memory dies from the plurality of memory dies; and a controller coupled to the memory device. The controller is configured to receive a plurality of partition append commands, each partition append command associated with a partition identifier identifying a partition from the plurality of partitions, extract data from a host device for each partition append command, aggregate the extracted data in an append write buffer using the partition identifier associated with each partition append command, the extracted data being aggregated into separate programming chunks for each identified partition, and write the aggregated data to the memory device in parallel using one or more of the plurality of channels when the aggregated data for each partition reaches a predetermined programming chunk size.

[0012] In another embodiment, a data storage device includes an interface coupled to a host device, a memory device having a plurality of memory dies, the plurality of memory dies including a plurality of blocks associated with a plurality of partitions, a plurality of channels, each channel coupled to one or more memory dies of the plurality of memory dies, and a controller coupled to the memory device and the interface, the controller including an append write buffer. The controller is configured to receive a first partition append command associated with a first partition of the plurality of partitions, receive a second partition append command associated with a second partition of the plurality of partitions, extract and aggregate one or more first chunks of first partition append command data until the first programming chunk is filled to a predetermined programming chunk size in the append write buffer, extract and aggregate one or more second chunks of second partition append command data until the second programming chunk is filled to a predetermined programming chunk size in the append write buffer, write the first programming chunk to a first block of the plurality of blocks associated with the first partition using the first channel of the plurality of channels, and write the second programming chunk to a second block of the plurality of blocks associated with the second partition using the second channel of the plurality of channels.

[0013] In another embodiment, a data storage device includes: a memory device having a plurality of memory dies, the plurality of memory dies including a plurality of blocks associated with a plurality of partitions; a plurality of channels, each channel coupled to one or more memory dies of the plurality of memory dies; a device for receiving a plurality of partition append commands, each partition append command being associated with a partition identifier identifying a partition of the plurality of partitions; a device for extracting data for each partition append command from a host device; a device for aggregating the extracted data in an append write buffer by the partition identifier associated with each partition append command, the extracted data being aggregated into separate programming blocks for each identified partition; a device for writing the aggregated data for each partition to the memory device in parallel using one or more of the plurality of channels when the aggregated data for the partition reaches a predetermined programming block size, and a device for writing the aggregated data to a temporary block of a memory die of the plurality of memory dies when the aggregated data for each partition fails to reach the predetermined programming block size. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Thus, a detailed understanding of the manner in which the above-recited features of the present disclosure are understood, a more particular description of the disclosure, the brief summary above, and the like, may be obtained by reference to the embodiments, some of which are illustrated in the accompanying drawings. It should be noted, however, that the drawings illustrate only typical embodiments of the disclosure and are therefore not to be considered limiting of its scope, as the disclosure may admit to other equally effective embodiments.

[0015] Figure 1 is a schematic block diagram illustrating a storage system having a storage device that can function as a storage device of a host device, in accordance with one or more techniques of this disclosure.

[0016] Figure 2A This is a schematic diagram of the device control of a traditional SSD.

[0017] Figure 2B is a schematic diagram of device control of a ZNS SSD according to one embodiment.

[0018] Figure 3 This is a diagram of the partition attach command.

[0019] Figure 4 is a schematic diagram of a state diagram for a ZNS SSD according to one embodiment.

[0020] Figure 5 is a schematic diagram of a partitioned namespace structure according to one embodiment.

[0021] Figure 6 It is a schematic diagram of ZNS non-interleaved data transmission.

[0022] 7A to 7B is a schematic diagram of a storage system implementing ZNS interleaving and optimized data transfer according to various embodiments.

[0023] Figure 8 is a schematic diagram of various tables utilized in ZNS interleaving and optimized data transmission according to various embodiments.

[0024] To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific recitation. DETAILED DESCRIPTION

[0025] Hereinafter, reference is made to embodiments of the present disclosure. However, it should be understood that the present disclosure is not limited to the specifically described embodiments. On the contrary, any combination of the following features and elements (whether or not related to different embodiments) is considered to implement and practice the present disclosure. In addition, although the embodiments of the present disclosure can achieve advantages over other possible solutions and / or advantages over the prior art, whether a specific advantage is achieved by a given embodiment is not a limitation of the present disclosure. Therefore, the following aspects, features, embodiments and advantages are merely illustrative and are not considered to be elements or limitations of the appended claims unless expressly stated in the claims. Similarly, reference to "the present disclosure" should not be interpreted as a summary of any inventive subject matter disclosed herein and should not be considered to be elements or limitations of the appended claims unless expressly stated in the claims.

[0026] The present disclosure generally relates to efficient data transfer management for partition append commands for a partitioned namespace (ZNS). A ZNS storage device includes a memory device having a plurality of memory dies, and a controller coupled to the memory device. The controller receives a plurality of partition append commands, each partition append command being associated with a partition identifier that identifies a partition among a plurality of partitions; and extracts and aggregates data associated with each partition append command by the partition identifier in an append write buffer. When the aggregate data for each partition reaches a predetermined programming block size, the aggregate data is written to the memory device, or if the predetermined write size is not met, the aggregate data is written to a temporary buffer. When the aggregate data for programming is sent to the memory device, each partition uses a separate channel, thereby allowing multiple channels to be utilized in parallel.

[0027] Figure 1 is a schematic block diagram illustrating a storage system 100 in accordance with one or more techniques of this disclosure, in which a data storage device 106 can be used as a storage device for a host device 104. For example, the host device 104 can utilize an NVM 110 included in the data storage device 106 to store and retrieve data. The host device 104 includes a host DRAM 138. In some examples, the storage system 100 can include multiple storage devices, such as the data storage device 106, that can operate as a storage array. For example, the storage system 100 can include multiple data storage devices 106 configured as a redundant array of inexpensive / independent disks (RAID) that can collectively function as a mass storage device for the host device 104.

[0028] The storage system 100 includes a host device 104 that can store data to and / or retrieve data from one or more storage devices, such as a data storage device 106. Figure 1 As shown, host device 104 can communicate with data storage device 106 via interface 114. Host device 104 can include any of a variety of devices, including a computer server, a network attached storage (NAS) unit, a desktop computer, a notebook (i.e., laptop) computer, a tablet computer, a set-top box, a telephone handset such as a so-called "smart" phone, a so-called "smart" tablet, a television, a camera, a display device, a digital media player, a video game console, a video streaming device, and the like.

[0029] The data storage device 106 includes a controller 108, a non-volatile memory 110 (NVM 110), a power supply 111, a volatile memory 112, an interface 114, and a write buffer 116. In some examples, for clarity, the data storage device 106 may include Figure 1Additional components not shown in the figure. For example, the data storage device 106 may include a printed circuit board (PCB) to which the components of the data storage device 106 are mechanically attached, and the printed circuit board includes conductive traces that electrically interconnect the components of the data storage device 106, etc. In some examples, the physical size and connector configuration of the data storage device 106 can conform to one or more standard form factors. Some exemplary standard form factors include, but are not limited to, a 3.5" data storage device (e.g., an HDD or SSD), a 2.5" data storage device, a 1.8" data storage device, a peripheral component interconnect (PCI), a PCI extension (PCI-X), a PCI Express (PCIe) (e.g., PCIe x1, x4, x8, x16, PCIe Mini Card, MiniPCI, etc.). In some examples, the data storage device 106 can be directly coupled (e.g., directly soldered) to a motherboard of the host device 104.

[0030] The interface 114 of the data storage device 106 may include one or both of a data bus for exchanging data with the host device 104 and a control bus for exchanging commands with the host device 104. The interface 114 may operate according to any suitable protocol. For example, the interface 114 may operate according to one or more of the following protocols: Advanced Technology Attachment (ATA) (e.g., Serial ATA (SATA) and Parallel ATA (PATA)), Fibre Channel Protocol (FCP), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), PCI and PCIe, Non-Volatile Memory Express (NVMe), OpenCAPI, GenZ, Cache Coherent Interface Accelerator (CCIX), Open Channel SSD (OCSSD), etc. The electrical connection of the interface 114 (e.g., the data bus, the control bus, or both) is electrically connected to the controller 108, thereby providing an electrical connection between the host device 104 and the controller 108, allowing data to be exchanged between the host device 104 and the controller 108. In some examples, the electrical connection of the interface 114 may also allow the data storage device 106 to receive power from the host device 104. For example, Figure 1 As shown, power supply 111 can receive power from host device 104 via interface 114 .

[0031] Data storage device 106 includes NVM 110, which may include multiple memory devices or storage cells. NVM 110 may be configured to store and / or retrieve data. For example, a storage cell of NVM 110 may receive data and receive a message from controller 108 instructing the storage cell to store data. Similarly, a storage cell of NVM 110 may receive a message from controller 108 instructing the storage cell to retrieve data. In some examples, each of the storage cells may be referred to as a die. In some examples, a single physical chip may include multiple dies (i.e., multiple storage cells). In some examples, each storage cell may be configured to store a relatively large amount of data (e.g., 128MB, 256MB, 512MB, 1GB, 2GB, 4GB, 8GB, 16GB, 32GB, 64GB, 128GB, 256GB, 512GB, 1TB, etc.).

[0032] In some examples, each memory cell of NVM 110 may include any type of nonvolatile memory device, such as a flash memory device, a phase change memory (PCM) device, a resistive random access memory (ReRAM) device, a magnetoresistive random access memory (MRAM) device, a ferroelectric random access memory (F-RAM), a holographic memory device, and any other type of nonvolatile memory device.

[0033] NVM 110 may include multiple flash memory devices or storage cells. The flash memory device may include a NAND or NOR-based flash memory device and may store data based on the charge contained in the floating gate of the transistor for each flash memory cell. In a NAND flash memory device, the flash memory device may be divided into multiple blocks, which may be divided into multiple pages. Each block in the multiple blocks within a particular memory device may include multiple NAND cells. The rows of NAND cells may be electrically connected using word lines to define pages in the multiple pages. The corresponding cells in each of the multiple pages may be electrically connected to corresponding bit lines. In addition, the NAND flash memory device may be a 2D or 3D device and may be a single-level cell (SLC), multi-level cell (MLC), triple-level cell (TLC), quad-level cell (QLC), or more. The controller 108 may write data to and read data from the NAND flash memory device at the page level, and erase data from the NAND flash memory device at the block level.

[0034] Data storage device 106 includes power supply 111, which can provide power to one or more components of data storage device 106. When operating in standard mode, power supply 111 can provide power to one or more components using power provided by an external device, such as host device 104. For example, power supply 111 can provide power to one or more components using power received from host device 104 via interface 114.

[0035] In some examples, power supply 111 may include one or more power storage components configured to supply power to one or more components when operating in a shutdown mode, such as when power is no longer being received from an external device. In this manner, power supply 111 may serve as an onboard backup power source. Some examples of one or more power storage components include, but are not limited to, capacitors, supercapacitors, batteries, and the like.

[0036] In some examples, the amount of power that can be stored by one or more power storage components can be a function of the cost and / or size (e.g., area / volume) of the one or more power storage components. In other words, as the amount of power that can be stored by the one or more power storage components increases, the cost and / or size of the one or more power storage components also increases.

[0037] The data storage device 106 also includes a volatile memory 112 that can be used by the controller 108 to store information. The volatile memory 112 can include one or more volatile memory devices. In some examples, the controller 108 can use the volatile memory 112 as a cache. For example, the controller 108 can store cached information in the volatile memory 112 until the cached information is written to the non-volatile memory 110. Figure 1 As shown, the volatile memory 112 can consume power received from the power supply 111. Examples of the volatile memory 112 include, but are not limited to, 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, LPDDR4, etc.)).

[0038] The data storage device 106 includes a controller 108 that can manage one or more operations of the data storage device 106. For example, the controller 108 can manage reading data from and / or writing data to the NVM 110. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 can initiate a data storage command to store data in the NVM 110 and monitor the progress of the data storage command. The controller 108 can determine at least one operational characteristic of the storage system 100 and store the at least one operational characteristic in the NVM 110. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 temporarily stores the data associated with the write command in an internal memory or write buffer 116 before sending the data to the NVM 110.

[0039] Figure 2A and Figure 2B is a schematic diagram of device control for an SSD according to various embodiments. In one embodiment, Figure 2A and Figure 2B The flash memory device can be Figure 1 The NVM 110 of the data storage device 106. In addition, according to various embodiments, Figure 2A and Figure 2B The flash memory devices may be multi-level cells, such as SLC, MLC, TLC, QLC, or more, including any other iterations of multi-level cells not listed. Figure 2A and Figure 2B Each square in a block storage device represents a block available for data storage. A shaded square or block indicates that the block contains data. This data can be user data, XOR or parity data, device metadata, or any other suitable data to be stored in the SSD's flash memory.

[0040] Figure 2A This is a diagram of device control in a traditional SSD. The SSD receives data from multiple applications, such as Application 1, Application 2, and Application 3. The data is stored in the SSD's flash memory. Within the SSD, the storage device controls data placement. Data is written sequentially to the flash memory, allowing data from each application to be written in the order it was received. Because the data from each application can be random throughout the sequential write process, latency can increase and throughput can be hampered.

[0041] Figure 2B This is a diagram of the device control of ZNS SSD. Figure 2A , the SSD receives data from multiple applications such as Application 1, Application 2, and Application 3. The data is stored in the flash memory of the SSD. In the SSD, the application or host (such as Figure 1 The host device 104 controls the placement of data within the partitions. The flash memory of the SSD is divided into various equal-capacity partitions. These partitions can be viewed as parallel units, where the host device 104 can direct workloads or data to specific parallel units (i.e., the host has block access to the flash memory). For example, data associated with application 1 is located in a first partition, while data associated with application 2 is located in a second partition, and data associated with application 3 is located in a third partition. Due to partition provisioning, latency is reduced relative to latency controlled by traditional SSD devices, and throughput is improved relative to throughput controlled by traditional SSD devices.

[0042] Figure 3 This is a diagram of the partition attach command. Figure 1 The host device 104 of the storage device 104 implicitly or explicitly opens the partition. The host device 104 issues several partition attach commands to the same address. Figure 1 The data storage device 106 is responsible for filling the partition with data from the host device 104 and notifying the host device 104 of the exact location within the partition where each command will write data. Figure 1 The location of the data of NVM 110) is stored in a volatile memory (such as Figure 1 The L2P table includes pointers to one or more logical block addresses (LBAs) where data, such as user data, is stored.

[0043] like Figure 3 As shown, each block in a partition is 4K in size. The term "block" is used for exemplary purposes and is not limited to a 4K size. The data storage device 106 receives three write commands (i.e., three partition append commands) in the order of 4K Write0, 8K Write1, and 16K Write2. In addition, the write pointer (WP) of the partition corresponds to the next available position for the write command. Figure 3In the example, a 4K Write0 is written to the first block, and the new write pointer position is at the beginning of the second block (i.e., at a 4K size position in the partition). After Write0 is written to the first block, an 8K Write1 is written to the next available block, occupying the next two blocks (i.e., two 4K size blocks). The write pointer is updated to reflect the 16K size position of the partition for the next write command. The final 16K Write2 command is written to the next four blocks (i.e., four 4K size blocks). The write pointer is updated to reflect the total partition size of 28K, where the next write command will be written to the 28K size position. At each position, the host updates with the exact location of the write data in the partition via the completion message associated with each partition append command. Although illustrated in the above order, the write commands received simultaneously can be written sequentially in any order (i.e., out of order), so that due to the ZNS environment, Write2 can be written to the partition before Write0.

[0044] Figure 4 is a schematic diagram of a state diagram of a ZNS SSD according to one embodiment. Figure 4 In

[15] , the various partition states (ZS) are empty (i.e., ZSE: empty), implicitly open (i.e., ZSIO: implicitly open), explicitly open (i.e., ZSEO: explicitly open), closed (i.e., ZSC: closed), full (i.e., ZSF: full), read-only (i.e., ZSRO: read-only), and offline (i.e., ZSO: offline). A general flow path for a partition can be from the empty state to the open state, which can be implicitly open or explicitly open. From the open state, the partition can be fully loaded, making the ZNS full. After the full state, the partition contents can be erased, which resets the ZNS to empty.

[0045] In controllers such as Figure 1 After a power-on or reset event of the controller 108, the initial state of each partition is determined by the partition characteristics of each partition. For example, the partition state ZSE: Empty is represented by a valid write pointer (WP) pointing to the lowest LBA in the partition (i.e., the partition start LBA). The partition state ZSC: Closed is represented by a WP that does not point to the lowest LBA in the partition. The partition state ZSF: Full is the initial state when the most recent partition condition is Full. The partition state ZSRO: Read Only is the initial state when the most recent partition condition is Read Only. The partition state ZSO: Offline is the initial state when the most recent partition condition is Offline.

[0046] The partitions can have any total capacity or total size, such as 256MiB or 512MiB. However, a small portion of each partition may not be accessible for writing data, but may still be read, such as the portion of each partition that stores XOR data, metadata, and one or more excluded erase blocks. For example, if the total capacity of the partition is 512MiB, then the partition capacity (ZCAP) may be 470MiB, which is the capacity available for writing data, while 42MiB is not available for writing data. The ZCAP of a partition is equal to or less than the total partition storage capacity or total partition storage size. Storage devices, such as Figure 1 Data storage device 106 or Figure 2B For SSDs, the ZCAP of each partition can be determined at partition reset. For example, a controller such as Figure 1 The controller 108 may determine the ZCAP of each partition. When a partition is reset, the storage device may determine the ZCAP of the partition.

[0047] When a partition is empty (i.e., ZSE: Empty), the partition contains no data (i.e., none of the erase blocks in the partition currently store data) and the write pointer (WP) is at the partition start LBA (ZSLBA) (i.e., WP=0). ZSLBA refers to the start of the partition (i.e., the first NAND location of the partition). The write pointer indicates the location in the partition of the storage device where data is written. Once a write is scheduled to the partition or a partition open command (i.e., ZSIO: Implicit Open or ZSEO: Explicit Open) is issued by the host, the empty partition will switch to an open and active partition. Partition management (ZM) commands can be used to move a partition between partition open and partition closed states (both active states). If a partition is active, the partition includes open blocks that can be written to and a description of the recommended time in the active state can be provided to the host. The controller 108 includes a ZM (not shown). Partition metadata can be stored in the ZM and / or the controller 108.

[0048] The term "write" includes programming user data on 0 or more NAND locations in an erase block and / or partially filled NAND locations in an erase block when the user data has not yet filled all available NAND locations. The NAND locations can be flash memory locations such as Figure 2A and Figure 2B The term "write" may also include moving a partition to a full (i.e., ZSF:full) state due to internal drive processing needs (open block data retention issues because error bits accumulate faster on open erase blocks), the data storage device 106 closing or filling a partition due to resource limitations (like too many open partitions to track or discover defective states, etc.), or a host device such as Figure 1The host device 104 closes the partition due to issues such as no more data to send to the drive, the computer being shut down, error handling on the host, limited host resources for tracking, etc.

[0049] Active partitions can be open (i.e., ZSIO: implicitly open or ZSEO: explicitly open) or closed (i.e., ZSC: closed). An open partition is an empty or partially filled partition that is ready for writing and has currently allocated resources. Data received from the host device using a write command or a partition append command can be programmed into an open erase block that is not currently filled with previous data. A closed partition is an empty or partially filled partition that is not currently receiving writes from the host. Moving a partition from the open state to the closed state allows the controller 108 to reallocate resources to other tasks. These tasks may include, but are not limited to, other open partitions, other regular non-partitioned areas, or other controller needs.

[0050] In open and closed partitions, the write pointer points to a location in the partition between the ZSLBA and the end of the last LBA of the partition (i.e., WP>0). The active partition can be switched between open and closed states according to the specifications made by the ZM, or when a write is scheduled to the partition. In addition, the ZM can reset the active partition to clear or erase the data stored in the partition, causing the partition to switch back to an empty partition. Once the active partition is full, the partition will switch to a full state. A full partition is a partition that is completely filled with data and has no more available blocks for writing data (i.e., WP=Partition Capacity (ZCAP)). In a full partition, the write pointer points to the end of the writable capacity of the partition. Read commands for data stored in a full partition can still be executed.

[0051] The ZM may reset a full partition (i.e., ZSF:Full), thereby scheduling the erasure of data stored in the partition so that the partition switches back to an empty partition (i.e., ZSE:Empty). When resetting a full partition, although the partition may be marked as an empty partition available for writing, the data of the partition may not be immediately cleared. However, the reset partition must be erased before switching to an open and active partition. The partition may be erased at any time between the ZM reset and the ZM open. When resetting a partition, the data storage device 106 may determine the new ZCAP for resetting the partition and update the writable ZCAP attribute in the partition metadata. An offline partition is a partition to which data cannot be written. An offline partition may be in a full state, an empty state, or in a partially full state without being in an active state.

[0052] Since resetting a partition clears the data stored in the partition or schedules the erasure of data stored in the partition, the need to perform garbage collection on individual erase blocks is eliminated, thereby improving the overall garbage collection process of the data storage device 106. The data storage device 106 can mark one or more erase blocks for erasure. When a new partition is about to be formed and the data storage device 106 anticipates that the ZM will be open, the one or more erase blocks marked for erasure can be erased. The data storage device 106 can also determine and create the physical support for the partition when erasing the erase block. Therefore, once the new partition is opened and an erase block is selected to form the partition, the erase block will be erased. In addition, each time a partition is reset, a new order of the partition's LBAs and write pointers can be selected, allowing the partition to tolerate receiving commands out of sequence. The write pointer can optionally be disabled so that commands can be written to any starting LBA indicated by the command.

[0053] If the partition activity limit is non-zero, the controller may transition a partition in any of the "ZSIO: Implicitly Open," "ZSEO: Implicitly Open," or "ZSC: Closed" states to the "ZSF: Full" state. When a partition transitions to the "ZSIO: Implicitly Open" state or the "ZSEO: Explicitly Open" state, an internal timer in seconds is started, allowing the host device 104 or data storage device 106 to identify when the ZAL value is exceeded. If the ZAL value or time limit is exceeded, the controller 108 may alert the host device 104 that the partition needs to be terminated (i.e., the partition needs to be at full capacity) or transition the partition to the "ZSF: Full" state. When the host device 104 is alerted that the partition needs to be terminated, the partition termination recommendation field is set to 1, and a partition information change event is reported to the host device 104. When the partition transitions to the "ZSF: Full" state, the partition terminated by controller field is set to 1, and a partition information change event is reported to the host device 104. Because the ZAL value is a global parameter for each partition of the storage device, a partition may be shut down prematurely, thereby allowing suboptimal storage drive operation, or it may be shut down later, thereby allowing an unacceptable amount of bit errors to accumulate, which may result in degradation of the integrity of the data storage device. An unacceptable accumulation of bit errors may also result in degradation of the performance of the data storage device. The global ZAL parameter is a static parameter and may be based on a worst-case estimate of the conditions that the host may face.

[0054] Figure 5is a schematic diagram of a partition namespace structure 500 according to one embodiment. The partition namespace structure 500 includes a plurality of NAND channels 502a-502n, wherein each NAND channel 502a-502n includes one or more die 504a-504n. Each NAND channel 502a-502n can have a dedicated hardware (HW) interface, making each NAND channel 502a-502n independent of another NAND channel 502a-502n. The NAND channels 502a-502n can be flash interface module (FIM) channels. Each of the one or more die 504a-504n includes one or more erase blocks 508a-508n. The partition namespace structure 500 also includes one or more partitions 506a-506n, wherein each partition 506a-506n includes one or more erase blocks 508a-508n from each of the plurality of die. In one embodiment, each of the plurality of partitions is of equal size. In another embodiment, each of the plurality of partitions is unequal in size. In another embodiment, one or more zones are unequal in size, and the remaining one or more zones are unequal in size.

[0055] For example, first partition 506a includes a first erase block 508a and a second erase block 508b from each die 504a-504n of each NAND channel 502a-502n. Subregion 506a-506n may include two erase blocks 508a-508n from each die 504a-504n so that when reading or writing data to die 504a-504n and / or subregion 506a-506n, two erase blocks 508a-508n increase parallelism. In one embodiment, subregion may include an even number of erase blocks from each die. In another embodiment, subregion may include an odd number of erase blocks from each die. In yet another embodiment, subregion may include one or more erase blocks from one or more die, wherein the one or more erase blocks may not be selected from one or more die.

[0056] Furthermore, the data transfer size associated with each partition append command to partitions 506a-506n may be the size of an erase block or page to take advantage of NAND parallelism and optimize the partition append command to NAND characteristics. If the data transfer size (e.g., write size) associated with the partition append command is less than a minimum transfer size (e.g., write size), such as the size of an erase block or page, the partition append command may be held in a buffer such as Figure 1The data transfer is interleaved with each partition append command to minimize the size of the write cache buffer (e.g., write buffer 116).

[0057] Figure 6 Schematic diagram of ZNS non-interleaved data transmission. The ZNS non-interleaved data transmission is shown as data transmission over a period of time. Figure 6 In the example, four partition append commands are sent to the storage device to write to a partition. The size of the data associated with each of the four partition append commands is 1 MB. For example, the size of the data associated with the first partition append command is 1 MB, the size of the data associated with the second partition append command is 1 MB, and so on.

[0058] The data for each partition attach command is transmitted via a data bus (such as a PCIe bus), where a controller (such as Figure 1 The controller 108 of the controller queues partition append commands to be written to corresponding locations in the die of the corresponding partition. Transferring 1MB of first data for the first partition append command over the data bus may take approximately 0.14 mSec. The time values ​​listed are not intended to be limiting but rather provide examples of implementations. After the transmission of the first data for the first partition append command is complete, the second data associated with the second partition append command may be transmitted, and similarly for the third data for the third partition append command, and so on.

[0059] After the data for the partition append command is transferred over the data bus, the data is transferred and programmed to the NAND interface. Programming the data to the NAND interface occurs at a NAND page granularity (such as approximately 32KB, approximately 64KB, approximately 96KB, or any other suitable size not listed). Each data programming operation can take approximately 2mSec, where writing 1MB of data can take approximately 20mSec. For example, consider that the time to write 1MB of data is much longer than the time to extract the data to be written (i.e., 0.14mSec). Before writing, all extracted data is cached internally. Since the time to extract data is much shorter than the time to write data, a large amount of data will be cached, requiring a very large cache size. In order to start executing the next command in parallel with the previously extracted command, the cache must be large enough to ensure that the cache will not become full when all data associated with the first extracted command is cached. If the cache is not full, the second command can be extracted in parallel and programmed to a different die. Since the time difference between extraction and writing is very large, a very large internal cache will be required to program the different dies in parallel.

[0060] exist Figure 6 In the embodiment of the present invention, the controller receives four partition append commands, each partition append command to a different die. For example, the first partition append command is for the first data to the first die 0, the second partition append command is for the second data to the second die 1, the third partition append command is for the third data to the third die 2, and the fourth partition append command is for the fourth data to the fourth die 3. In the current embodiment, the controller has four available write buffers so that each command can be executed after receiving the data associated with the four partition append commands. If a fifth partition append command associated with the fifth data is received, the fifth partition append command is queued in the controller buffer (e.g., a write cache buffer) until the write buffer is released. However, since the data size of each partition append command is 1MB, many partition append commands can be stored in the controller buffer, thereby increasing the size required for the write cache buffer. The additional size of the write cache buffer increases the cost and requires more power to operate.

[0061] 7A to 7B A storage system 700 is shown that implements ZNS interleaved data transmission according to various embodiments. The storage system 700 may be Figure 1 The storage system 100 includes a host device 702 coupled to a storage device 704 via a data bus 724. The storage device 704 is a ZNS storage device that includes multiple erase blocks or multiple dies grouped into partitions. The storage device 704 may be Figure 2B In some embodiments, the storage device 704 includes Figure 5 ZNS structure 500.

[0062] The host device 702 includes a host append command queue 706. The storage device 704 includes an append write buffer 708. The append write buffer 708 is a command fetch and can be Figure 1 The additional write buffer 708 may be stored within the controller 710 of the storage device 704 or may be coupled to the controller 710. The additional write buffer 708 aggregates chunks of data fetched or received from the host device 702 into programming chunks 714a-714n (collectively, programming chunks 714), as discussed in more detail below.

[0063] like Figure 7AAs shown, the host device 702 queues partition attach commands 712a-712h (collectively, partition attach commands 712) in the host attach command queue 706. Although eight partition attach commands 712a-712h are shown in the host attach command queue 706, any number of partition attach commands 712 may be stored in the host attach command queue 706 at any time, and the number of partition attach commands 712 is not intended to be limiting. The partition attach commands 712 may have various sizes, such as from several kilobytes to several megabytes. Thus, one or more partition attach commands 712 may have different sizes, such as Figure 7A shown.

[0064] Each of the partition append commands 712a-712h includes or is associated with a partition identification (ID) to inform the storage device 704 where the data of the partition append commands 712a-712h should be stored (i.e., which erase block associated with a particular partition). The partition ID may be the starting LBA of the blocks associated with the particular partition, as described below in Figure 8 . For example, the first partition append command 712a, the second partition append command 712b, the fifth partition append command 712e, and the sixth partition append command 712f have a partition ID of LBA 0 associated with the first partition 0. The third partition append command 712c and the fourth partition append command 712d have a partition ID of LBA 2000 associated with the fifth partition 4. The seventh partition append command 712g and the eighth partition append command 712h have a partition ID of LBA 1000 associated with the third partition 2. In this example, each partition size is set to 500 LBAs; however, the size of the partitions may vary, and the partition sizes are not intended to be limiting.

[0065] The controller 710 of the storage device 704 retrieves one or more portions or cartridges of data of the partition append commands 712a-712h from the host device 702 for each partition identified by the partition append commands 712a-712h. Once the data is retrieved from the host device 702, the storage device 704 sorts and aggregates the one or more chunks of data into programming chunks 714a-714n according to the partition ID associated with each chunk in the append write buffer 708. The append write buffer 708 may include multiple buffers. Thus, each partition associated with a partition ID may have a separate buffer within the append write buffer 708 in which the programming chunks 714 are aggregated.

[0066] When one or more chunks of data associated with a partition are aggregated to a predetermined programming chunk size (such as a 96K NAND page size), programming chunks 714 are sent for programming via respective channels 716a-716n (collectively referred to as channels 716) according to the partition ID of the programming chunks 714. Figure 7B Channels 716a-716n can be Figure 5 NAND or FIM channels 502a-502n are provided. Each channel 716 may have a dedicated hardware interface, making each channel 716 independent of another channel 716. Although the programming block size of the NAND page size is mentioned as 96K throughout, the programming block size may be of any size and is therefore not intended to be limiting. In some embodiments, the programming block size may be larger or smaller than the page size. When the programming block size is equal to the page size, the maximum number of partition append commands 712 that can be served in parallel by the additional write buffer 708 is the size of the additional write buffer 708 divided by the page size. In some embodiments, the maximum number of partition append commands 712 that can be served in parallel by the additional write buffer 708 exceeds the number of channels 716 to allow all channels 716 to be utilized in parallel. In addition, although three channels 716 are shown, a greater or lesser number of channels 716 may be included, and the number of channels 716 is not intended to be limiting. For example, there may be 8 channels, 16 channels, or more channels.

[0067] Programming blocks 714 aggregated to a predetermined programming block size are sent via respective channels 716 for programming to one or more blocks (not shown) included on a plurality of dies 718a-718c (collectively, die 718). Each channel 716 is coupled to a plurality of dies 718, and each die 718 includes a plurality of blocks. Each partition is associated with one or more blocks from each of the plurality of dies 718 coupled to a particular channel 716. For example, Figure 7B As shown, first partition 0 utilizes first channel 0 716a to access one or more blocks associated with first partition 0 on a plurality of first dies 718a. In other words, each partition utilizes a separate channel 716 coupled to a plurality of dies 718 to access one or more blocks associated with each partition. Because each partition utilizes a separate channel 716, one or more channels 716 can be used in parallel. Thus, when one or more partition append commands are executed or programmed in parallel, data transfers are interleaved with each partition append command to minimize the size of the append write buffer 708.

[0068] As an example, refer to Figure 7A, the chunks of the first partition append command 712a of 4K, the second partition append command 712b of 16K, the fifth partition append command 712e of 16K, and the sixth partition append command 712f of 60K are aggregated to the first partition 0 as the first programming chunk 714a in the additional write buffer 708. Since the first partition append command 712a, the second partition append command 712b, and the fifth partition append command 712e are aggregated to 36K, and the sixth partition append command 712f has a size of 128K, only the 60K chunk of the sixth partition append command 712f is extracted to satisfy the programming chunk size of 96K. In some embodiments, the controller 710 continues to process partition append commands 712 associated with other partition IDs before returning to processing the remainder of the sixth partition append command 712f.

[0069] At the same time, or when the 96K programming chunk size is reached for the first partition 0, partition append commands 712 identifying other partitions are fetched and aggregated. For example, the third partition append command 712 c and the fourth partition append command 712 d may be fetched and aggregated into the fifth partition 4 in the append write buffer 708, and the seventh partition append command 712 g and the eighth partition append command 712 h may be fetched and aggregated into the third partition 2 in the append write buffer 708.

[0070] like Figure 7B As shown, once the data associated with the first partition 0 is aggregated to a programming block size (e.g., 96K), the memory device 704 or the controller 710 of the memory device 704 sends a first programming block 714a associated with the first partition 0 to be programmed. The first programming block 714a is sent to one or more blocks associated with the first partition 0 on one or more dies 718a via a first channel 0 716a. The memory device 704 may utilize various tables to determine to which page, block, and / or die to send the programming block 714 for each partition when the programming block size is met, such as Figure 8 As shown and discussed in.

[0071] Similarly, since the data associated with the third partition 2 and the twelfth partition 11 are each individually aggregated into programming chunk sizes, the controller 710 sends the third programming chunk 714c associated with the third partition 2 and the fifth programming chunk 714n associated with the twelfth partition 11 to be programmed. The third programming chunk 714c is sent via the second channel 1 716b to one or more blocks associated with the third partition 2 on one or more die 718b. The fifth programming chunk 714n is sent via the eighth channel 7 to one or more blocks associated with the twelfth partition 11 on one or more die 718c. Thus, the first channel 0 716a, the second channel 1 716b, and the eighth channel 7 can be used in parallel. In some embodiments, eight or sixteen separate channels 716 can be serviced in parallel.

[0072] As the first, third, and fifth programming chunks 714a, 714c, and 714n are programmed, the data in the first, third, and fifth programming chunks 714a, 714c, and 714n are released or erased from the append write buffer 708, thereby allowing the append write buffer 708 to be reused. For example, as the first programming chunk 714a is released, the remaining chunks of the sixth partition append command 712f can be extracted to be aggregated with other partition append commands 712 associated with the first partition 0. Because the storage device 704 can concurrently service multiple channels 716 associated with multiple partitions, such as the first channel 0 716a, the second channel 1 716b, and the eighth channel 7 as described above, the storage device 704 is not bogged down by servicing only a few partitions that may have large data transfers (e.g., data transfers greater than a predetermined programming size) that completely fill the append write buffer 708. Serving only a few partitions with large data transfers prevents several channels 716 from being utilized simultaneously.

[0073] Because the third partition append command 712c and the fourth partition append command 712d are aggregated to 32K, the storage device 704 waits to receive more partition append commands 712 associated with the fifth partition 4 before sending the second programming chunk 714b to be programmed. Upon receiving one or more chunks of data associated with the fifth partition 4 aggregated to the programming chunk size, the controller 710 sends the second programming chunk 714b to be programmed, as described above. If no more partition append commands 712 associated with the fifth partition 4 are received after a predetermined period of time (such as approximately 10 milliseconds to approximately 100 milliseconds) and all cache buffers are occupied, the second programming chunk 714b of the aggregated data associated with the fifth partition 4 can be processed, such as by writing the second programming chunk 714b to a temporary block or a different buffer or cache. Once the second programming chunk 714b associated with the fifth partition 4 is processed, the buffer storing the second programming chunk 714b can be released from the append write buffer 708 for use with another partition.

[0074] In some embodiments, while writing the 32K second programming chunk 714b to the temporary block or buffer, the controller 710 tracks the amount of data required to fill the next programming chunk 714 associated with the fifth partition 4. Thus, the controller 710 knows that the next programming chunk 714 associated with the fifth partition 4 requires 64K of data to reach the programming chunk size. When one or more partition append commands 712 associated with the fifth partition 4 are received and aggregated to 64K within the programming chunk 714, the controller 710 aggregates the newly received 64K of data with the 32K of data stored in the temporary block or buffer to fill the next programming chunk 714 associated with the fifth partition 4. The programming chunk 714 containing the new 64K of data is then sent over the channel 716 associated with the fifth partition 4 for programming. If one or more partition append commands 712 associated with the fifth partition 4 are received but fail to aggregate into the 64K required to fill the next programming chunk 714 associated with the fifth partition 4, the newly received partition append commands 712 associated with the fifth partition 4 may be stored in a temporary block or buffer until enough partition append commands 712 are received to satisfy the programming chunk size.

[0075] Aggregating the data for the partition append commands 712 by the partition ID associated with the partition append commands 712 allows for interleaved data transfers utilizing multiple channels 716 in parallel, as each partition identified by the partition ID utilizes a different channel 716 to program the data. Being able to use multiple channels 716 in parallel eliminates the bottleneck of the storage device 704 in the append write buffer 708, as the storage device 704 is not stuck servicing only a few zones with large data transfers that completely fill the append write buffer 708.

[0076] Figure 8 Various tables 820, 830, 840 are shown for use in implementing ZNS interleaved data transmission according to various embodiments. 7A to 7B Therefore, in Figure 8 Reference in the description 7A to 7B Tables 820, 830, and 840 may each be stored in and managed by the controller 710. Controller 710 may utilize one or more of tables 820, 830, and 840 when each programming block 714 is ready to be programmed and / or when each partition attach command 712 is received or extracted from the host device 702. Controller 710 may utilize one or more of tables 820, 830, and 840 collectively or individually.

[0077] The first table shown is a partition ID to block mapping table 820. The partition ID to block mapping table 820 tracks the partition ID of a particular partition to the specific channel, die, and block associated with that partition. The controller 710 uses the partition ID to block mapping table 820 to look up which partition is associated with the partition ID of each partition attach command 712 and then determines which channel, die, and block are associated with the identified partition. A block can be identified by the block's starting LBA.

[0078] For example, when the first partition attach command 712a is extracted and has a partition ID of 0, the controller 710 uses the partition ID to block mapping table 820 to look up which partition is associated with partition ID 0. The partition ID to block mapping table 820 indicates that the first partition 0 has a partition ID of 0 and is associated with the first channel 0 716a, the fourth die 3 718a on the first channel 0, and the 56th block 55 of the fourth die 3 718a. Similarly, when the seventh partition attach command 712g is extracted and has a partition ID of 2, the controller 710 uses the partition ID to block mapping table 820 to look up which partition is associated with partition ID 2. The partition ID to block mapping table 820 indicates that the third partition 2 has a partition ID of 2 and is associated with the second channel 1 716b, the fifth die 4 718b on the second channel 1 716b, and the 121st block 120 of the fifth die 4 718b.

[0079] The second table shown is a partition ID to active resource number table 830. Since the storage device 704 supports a limited number of active partitions in the system (e.g., 4K), the storage device 704 is able to maintain many parameters for each active partition as well as global parameters. Global parameters may include the total number of active partitions and the number of blocks that are allowed to be open (i.e., able to be written to) at one time, which may be referred to as active resource numbers. Not all blocks can be written to because some blocks are closed (e.g., the blocks currently storing the maximum data capacity). Closed blocks can still be read, but no longer have the ability to be written to until they are erased. When a partition is opened and / or becomes active, the storage device 704 associates the newly opened partition with one or more open blocks (e.g., empty blocks). Therefore, the active resource number is the number of the open blocks associated with each partition ID. The controller 710 uses the partition ID to active resource number table 830 to find which active resource or open block is associated with each partition ID. For example, the active resource number associated with the first partition 0 with partition ID 0 is active resource number 4, or the fourth open block in the number of all open blocks.

[0080] The third table shown is the active resource to LBA offset table 840. The controller 710 uses the active resource to LBA offset table 840 to determine the LBA offset, or the next LBA within a block or from an active resource number associated with a particular partition to which data should be written. In a ZNS system, since blocks are typically identified only by the block's starting LBA, the LBA offset identifies the precise location within the block where data should be stored. For example, the first partition 0 with active resource number 4 has an LBA offset of 96. Therefore, the data for the first programming chunk 714a should be written to the 96th LBA of the fourth zone (i.e., block 55) associated with the first partition 0.

[0081] Controller 710 may use a partition ID to block mapping table 820, a partition ID to active resource number table 830, and an active resource to LBA offset table 840 in conjunction. For example, controller 710 may first use partition ID to block mapping table 820 to identify a specific channel, die, and block associated with a partition, then use partition ID to active resource number table 830 to determine the last active resource number for the partition, and then use active resource to LBA offset table 840 to determine the next LBA within the last active resource of the block that should be written. Tables 820, 830, and 840 may be used whenever a partition append command 712 is received or retrieved, and whenever a programming chunk is sent for programming. Furthermore, tables 820, 830, and 840 may be updated as frequently as desired. For example, each time a programming chunk is programmed, active resource to LBA offset table 840 may be updated to reflect the new LBA offset.

[0082] By interleaving the data transfers of partition append commands across data chunks equivalent to a page size rather than entire blocks, high-performance memory device utilization is achieved without increasing the write cache buffer size. Furthermore, by sorting and aggregating data chunks by partition ID, the memory device can utilize multiple channels in parallel when programming data, as different partitions utilize different channels for data programming. The ability to utilize multiple channels in parallel eliminates bottlenecks in the memory device's append write buffer, as the memory device is not bogged down servicing only a few zones with large data transfers that completely fill the append write buffer.

[0083] In one embodiment, a data storage device includes: a memory device having a plurality of memory dies; a plurality of channels, each channel coupled to one or more memory dies from the plurality of memory dies; and a controller coupled to the memory device. The controller is configured to receive a plurality of partition append commands, each partition append command associated with a partition identifier identifying a partition from the plurality of partitions, extract data from a host device for each partition append command, aggregate the extracted data in an append write buffer using the partition identifier associated with each partition append command, the extracted data being aggregated into separate programming chunks for each identified partition, and write the aggregated data to the memory device in parallel using one or more of the plurality of channels when the aggregated data for each partition reaches a predetermined programming chunk size.

[0084] The predetermined programming block size is equal to the page size. The plurality of memory dies include a plurality of blocks associated with the plurality of partitions. Each partition utilizes a separate channel from the plurality of channels to access the plurality of blocks associated with each partition. The controller is further configured to manage a mapping of partition identifiers to the plurality of blocks associated with the plurality of partitions, and to manage a mapping of partition identifiers to active resource numbers. The controller is further configured to manage a mapping of starting logical block addresses to the plurality of blocks associated with the plurality of partitions. The controller is further configured to write aggregate data for each partition to a temporary block in a memory die in the plurality of memory dies when the aggregate data fails to reach the predetermined programming block size. The controller is further configured to aggregate additional data with the aggregate data written to the temporary block to reach the predetermined programming block size.

[0085] In another embodiment, a data storage device includes an interface coupled to a host device, a memory device having a plurality of memory dies, the plurality of memory dies including a plurality of blocks associated with a plurality of partitions, a plurality of channels, each channel coupled to one or more memory dies of the plurality of memory dies, and a controller coupled to the memory device and the interface, the controller including an append write buffer. The controller is configured to receive a first partition append command associated with a first partition of the plurality of partitions, receive a second partition append command associated with a second partition of the plurality of partitions, extract and aggregate one or more first chunks of first partition append command data until the first programming chunk is filled to a predetermined programming chunk size in the append write buffer, extract and aggregate one or more second chunks of second partition append command data until the second programming chunk is filled to a predetermined programming chunk size in the append write buffer, write the first programming chunk to a first block of the plurality of blocks associated with the first partition using the first channel of the plurality of channels, and write the second programming chunk to a second block of the plurality of blocks associated with the second partition using the second channel of the plurality of channels.

[0086] The controller is further configured to extract and aggregate one or more second blocks of first partition append command data until a third programming block is filled in the append write buffer to a predetermined programming block size. The one or more second blocks of first partition append command data are aggregated after the first programming block is released from the append write buffer or when no more first partition append command data is available for extraction. The predetermined programming block size is equal to the page size or approximately 96K. The first channel and the second channel are used in parallel. The controller is further configured to associate a partition identifier with the received partition append command. The controller is further configured to manage a mapping of the partition identifier to the plurality of blocks associated with the plurality of partitions. The maximum number of partition append commands serviced in parallel by the append write buffer is equal to the size of the append write buffer divided by the page size.

[0087] The controller is further configured to receive a third partition append command associated with a third partition of the plurality of partitions, extract and aggregate one or more first chunks of the third partition append command data as a third programming chunk in an append write buffer, and write the third programming chunk to a temporary write buffer when the aggregated data fails to reach a predetermined programming chunk size. The controller is further configured to receive a fourth partition append command associated with the third partition, extract and aggregate one or more first chunks of the fourth partition append command data as a fourth programming chunk in an append write buffer, aggregate the third programming chunk with the fourth programming chunk to reach a predetermined programming chunk size, and write the aggregated third and fourth programming chunks to a third block of the plurality of blocks associated with the third partition using a third channel of the plurality of channels. The controller is further configured to release the first programming chunk from the write append buffer when writing the first programming chunk to the first block, and release the second programming chunk from the write append buffer when writing the second programming chunk to the second block.

[0088] The controller is further configured to receive a third partition append command associated with a third partition of the plurality of partitions, extract and aggregate one or more first chunks of the third partition append command data as a third programming chunk in an append write buffer, and write the third programming chunk to a temporary write buffer when the aggregated data fails to reach a predetermined programming chunk size. The controller is further configured to receive a fourth partition append command associated with the third partition, extract and aggregate one or more first chunks of the fourth partition append command data as a fourth programming chunk in the append write buffer, aggregate the third programming chunk with the fourth programming chunk to reach a predetermined programming chunk size, and write the aggregated third programming chunk and the fourth programming chunk to a third block of the plurality of blocks associated with the third partition using a third channel of the plurality of channels.

[0089] In another embodiment, a data storage device includes: a memory device having a plurality of memory dies, the plurality of memory dies including a plurality of blocks associated with a plurality of partitions; a plurality of channels, each channel coupled to one or more memory dies of the plurality of memory dies; a device for receiving a plurality of partition append commands, each partition append command being associated with a partition identifier identifying a partition of the plurality of partitions; a device for extracting data for each partition append command from a host device; a device for aggregating the extracted data in an append write buffer by the partition identifier associated with each partition append command, the extracted data being aggregated into separate programming blocks for each identified partition; a device for writing the aggregated data for each partition to the memory device in parallel using one or more of the plurality of channels when the aggregated data for the partition reaches a predetermined programming block size, and a device for writing the aggregated data to a temporary block of a memory die of the plurality of memory dies when the aggregated data for each partition fails to reach the predetermined programming block size.

[0090] The predetermined programming chunk size is approximately 96K. Each partition utilizes a separate channel from the plurality of channels. The data storage device further includes means for managing a mapping of a partition identifier to a plurality of blocks associated with the plurality of partitions. The data storage device further includes means for managing a mapping of a starting logical block address to a plurality of blocks associated with the plurality of partitions, and means for managing a mapping of a partition identifier to an active resource number. The data storage device further includes means for releasing aggregate data from an additional write buffer once the aggregate data has been written to the memory device. The data storage device further includes means for aggregating additional data with the aggregate data written to the temporary block to reach the predetermined programming chunk size.

[0091] While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the disclosure may be envisaged without departing from the basic scope thereof, and the scope of the disclosure is determined by the claims that follow.

Claims

1. A data storage device, comprising: a memory device having a plurality of memory dies; a plurality of channels, each channel coupled to one or more memory dies of the plurality of memory dies; as well as a controller coupled to the memory device, the controller including an additional write buffer, the controller configured to: receiving a plurality of partition attach commands, each partition attach command being associated with a partition identifier identifying a partition of the plurality of partitions; Additional commands for each partition are used to extract data from the host device; aggregating the extracted data in the append write buffer by the partition identification associated with each partition append command, the extracted data being aggregated into separate programming chunks for each identified partition; as well as When the aggregated data of each partition reaches a predetermined programming block size, writing the aggregated data to the memory device in parallel using one or more channels of the plurality of channels, Wherein the plurality of memory dies includes a plurality of blocks associated with the plurality of partitions, and each partition utilizes a separate channel of the plurality of channels to access the plurality of blocks associated with each partition. 2 . The data storage device of claim 1 , wherein the predetermined programming block size is equal to a page size.

3. The data storage device of claim 1 , wherein the controller is further configured to: managing a mapping of partition identifications to the plurality of blocks associated with the plurality of partitions; and Manages the mapping of partition IDs to active resource numbers. 4 . The data storage device of claim 1 , wherein the controller is further configured to manage a mapping of a starting logical block address to the plurality of blocks associated with the plurality of partitions.

5. The data storage device of claim 1 , wherein the controller is further configured to write the aggregated data of each partition to a temporary block in a memory die among the plurality of memory dies when the aggregated data fails to reach the predetermined programming block size. 6 . The data storage device of claim 5 , wherein the controller is further configured to aggregate additional data with the aggregated data written to the temporary block to reach the predetermined programming chunk size. 7 . The data storage device of claim 1 , wherein the controller is further configured to append a command for each partition to inform the host device of a location within the partition where data is written.

8. A data storage device, comprising: an interface coupled to a host device; a memory device having a plurality of memory dies including a plurality of blocks associated with a plurality of partitions; a plurality of channels, each channel coupled to one or more memory dies of the plurality of memory dies; as well as a controller coupled to the memory device and the interface, the controller comprising an additional write buffer, wherein the controller is configured to: receiving a first partition attach command associated with a first partition of the plurality of partitions; receiving a second partition append command associated with a second partition of the plurality of partitions; extracting and aggregating one or more first chunks of first partition append command data until first programming chunks are filled to a predetermined programming chunk size in the append write buffer; concurrently, extracting and aggregating one or more second chunks of the second partition additional command data until the second programming chunks are filled to the predetermined programming chunk size in the additional write buffer; writing the first programming group block to a first block of the plurality of blocks associated with the first partition using a first channel of the plurality of channels; as well as The second programming group block is written to a second block of the plurality of blocks associated with the second partition using a second channel of the plurality of channels.

9. The data storage device of claim 8, wherein the controller is further configured to extract and aggregate one or more second chunks of the first partition append command data until a third programming chunk is filled to the predetermined programming chunk size in the append write buffer.

10. The data storage device of claim 8 , wherein the one or more second chunks of the first partition append command data are aggregated after the first programming chunk is released from the append write buffer or when no further first partition append command data is available for extraction, and wherein a maximum number of partition append commands serviced in parallel by the append write buffer is equal to a size of the append write buffer divided by a page size.

11. The data storage device of claim 8, wherein the predetermined programming block size is equal to a page size or 96K, and wherein the first channel and the second channel are used in parallel.

12. The data storage device of claim 8, wherein the controller is further configured to: Associating a partition identification with the received partition attach command; and A mapping of partition identifications to the plurality of blocks associated with the plurality of partitions is managed.

13. The data storage device of claim 8, wherein the controller is further configured to: receiving a third partition append command associated with a third partition of the plurality of partitions; extracting and aggregating one or more first chunks of third partition append command data as third programming chunks in the append write buffer; and When the aggregate data fails to reach the predetermined programming block size, the third programming block is written to a temporary write buffer.

14. The data storage device of claim 13, wherein the controller is further configured to: receiving a fourth partition append command associated with the third partition; extracting and aggregating one or more first chunks of fourth partition additional command data as fourth programming chunks in the additional write buffer; aggregating the third programming block with the fourth programming block to reach the predetermined programming block size; as well as The aggregated third and fourth programming blocks are written to a third block of the plurality of blocks associated with the third partition using a third channel of the plurality of channels.

15. The data storage device of claim 8, wherein the controller is further configured to: releasing the first programming group block from the additional write buffer when the first programming group block is written to the first block; and When the second programming group block is written to the second block, the second programming group block is released from the additional write buffer.

16. A data storage device, comprising: a memory device having a plurality of memory dies including a plurality of blocks associated with a plurality of partitions; a plurality of channels, each channel coupled to one or more memory dies of the plurality of memory dies; means for receiving a plurality of partition append commands, each partition append command being associated with a partition identifier identifying a partition of the plurality of partitions; means for appending commands for each partition to extract data from the host device; means for aggregating the extracted data in an append write buffer by the partition identification associated with each partition append command, the append write buffer being stored in the controller, the extracted data being aggregated into separate programming chunks for each identified partition; means for writing the aggregated data to the memory device in parallel using one or more of the plurality of channels when the aggregated data for each partition reaches a predetermined programming block size; as well as means for writing aggregated data to a temporary block of a memory die among the plurality of memory dies when the aggregated data of each partition fails to reach the predetermined programming block size, Wherein the plurality of memory dies includes a plurality of blocks associated with the plurality of partitions, and each partition utilizes a separate channel of the plurality of channels to access the plurality of blocks associated with each partition.

17. The data storage device of claim 16, wherein the predetermined programming block size is 96K, and wherein each partition utilizes a separate channel of the plurality of channels.

18. The data storage device of claim 16, further comprising means for managing a mapping of partition identifications to the plurality of blocks associated with the plurality of partitions.

19. The data storage device of claim 16, further comprising: means for managing a mapping of starting logical block addresses to said plurality of blocks associated with said plurality of partitions; as well as Means for managing a mapping of partition identifications to active resource numbers.

20. The data storage device of claim 16, further comprising: means for releasing the aggregated data from the additional write buffer once the aggregated data has been written to the memory device; as well as Means for aggregating additional data with the aggregated data written to the temporary block to reach the predetermined programming chunk size.

Images