Data integrity protection for zns requirements

Abstract

The present disclosure generally relates to methods of operating a storage device. The storage device includes a controller that includes a first random access memory (RAM1), a second random access memory (RAM2), and a storage unit divided into a plurality of partitions. When a write command to write data to a partition is received, change log data is generated and stored in the RAM1, previous incremental data for the partition is copied from the RAM2 to the RAM1 to be updated with the change log data, and the updated incremental data is copied to the RAM2. The incremental data stored in the RAM2 is periodically copied to the storage unit. The controller tracks which incremental data has been copied to the RAM2 and the storage unit. During a power failure, the incremental data and the change log data are copied from the RAM1 or the RAM2 to the storage unit.

Description

[0001] Cross-references to related applications Technical Field

[0002] This patent application claims priority to U.S. Application 16 / 883,916, filed May 26, 2020, the entire contents of which are incorporated herein by reference. Background Technology Technical Field

[0004] The embodiments disclosed herein relate generally to storage devices, such as solid-state drives (SSDs).

[0005] Description of related fields

[0006] Storage devices such as SSDs are used in computers for applications requiring relatively low latency and high-capacity storage. For example, SSDs can exhibit lower latency than hard disk drives (HDDs), especially for random reads and writes. Typically, the SSD controller receives commands to read data from the host device or write data to the storage device. Data is read and written to one or more erase blocks in the storage device. Each of these erase blocks is associated with a logical block address, allowing the SSD and / or the host device to know the storage location of data such as user data, parity data, metadata, and other applicable data. A logical-to-physical address (L2P) table stored in the SSD's volatile memory associates the data's LBA with the physical address in the SSD where the data is stored at the time of writing. One or more erase blocks can be grouped together by their respective logical block addresses to form multiple partitions.

[0007] Typically, a die or a plane of a die within each partition is dedicated to storing parity data for that partition. When the storage device receives a command to write data to a specific partition, the data associated with that command is written to the storage device, and parity data is simultaneously generated for that data to protect it. Additionally, in-flight data (such as data not yet written to the storage device) can also be stored in a dedicated die or a dedicated plane of a die within each partition. The parity data and in-flight data are then stored in random access memory (RAM) within the storage device.

[0008] However, storage devices typically include a very limited amount of RAM because RAM is expensive from a cost and overall system design perspective. Since parity data is generated for each received write command, this parity data consumes a significant amount of valuable RAM space, which can reduce the amount of RAM available for other data or may require a larger amount of RAM to be included in the storage device. Furthermore, in-flight data can accumulate to a considerable volume, necessitating even more RAM in the storage device. Because RAM is volatile, data is lost when the device is powered off. Therefore, the reliability of data storage can be compromised, and valuable information may be lost.

[0009] Therefore, a new method is needed to protect data in storage devices from power failures. Summary of the Invention

[0010] This disclosure relates throughout to a method of operating a storage device. The storage device includes a controller comprising a first random access memory (RAM1), a second random access memory (RAM2), and storage cells divided into multiple partitions. When a write command is received to write data to a partition, change log data is generated and stored in RAM1. Previous incremental data for that partition is copied from RAM2 to RAM1 for updating using the change log data, and the updated incremental data is copied to RAM2. The incremental data stored in RAM2 is periodically copied to the storage cells. The controller tracks which incremental data has been copied to RAM2 and the storage cells. During a power outage, the incremental data and the change log data are copied from RAM1 or RAM2 to the storage cells.

[0011] In one embodiment, a storage device includes: a non-volatile storage cell, wherein the capacity of the non-volatile storage cell is divided into multiple partitions, and wherein the non-volatile storage cell includes multiple dies. Each of the multiple dies includes multiple erase blocks. The storage device also includes a first volatile storage cell, a controller coupled to the non-volatile storage cell and the first volatile storage cell, and a second volatile storage cell. The controller is configured to receive one or more commands to write data to the first partition of the multiple partitions, generate change log data of the first partition in a temporary location in the second volatile storage cell, and copy the change log data of the first partition to the non-volatile storage cell in the event of a power failure.

[0012] In another embodiment, a storage device includes: a non-volatile memory cell, wherein the capacity of the non-volatile memory cell is divided into multiple partitions, and wherein the non-volatile memory cell includes multiple dies. Each of the multiple dies includes multiple erase blocks. The storage device also includes a first volatile memory cell, the first volatile memory cell including multiple memory groups, wherein the multiple memory groups are divided into one or more segments. The storage device further includes a controller coupled to the non-volatile memory cell and the first volatile memory cell. The controller includes a second volatile memory cell. The controller is configured to: receive one or more write commands to write data to one or more of the plurality of partitions; update incremental data associated with at least one of the partitions in the second volatile storage unit for each of the received write commands, wherein the incremental data is updated for the specific partition whenever a command to write data to the specific partition is received; copy the updated incremental data associated with the at least one partition from the second volatile storage unit to the plurality of storage groups of the first volatile storage unit; and copy one or more segments in the plurality of storage groups of the first volatile storage unit to the non-volatile storage unit, wherein one of the one or more segments is copied to the non-volatile storage unit after a predetermined amount of time has elapsed.

[0013] In another embodiment, a storage device includes: a non-volatile memory cell, wherein the capacity of the non-volatile memory cell is divided into multiple partitions, and wherein the non-volatile memory cell includes multiple dies. Each of the multiple dies includes multiple erase blocks. The storage device also includes a first volatile memory cell, the first volatile memory cell including multiple memory groups, wherein the multiple memory groups are divided into one or more segments. The storage device further includes a controller coupled to the non-volatile memory cell and the first volatile memory cell. The controller includes a second volatile memory cell. The controller is configured to: receive one or more write commands to write data to one or more of the plurality of partitions; update incremental data associated with at least one of the partitions in the second volatile storage unit for each of the received one or more write commands, wherein the incremental data is updated for the specific partition whenever a command to write data to the specific partition is received; copy the incremental data associated with the at least one partition from the second volatile storage unit to the plurality of storage groups in the first volatile storage unit; determine when a majority of the storage groups in each of the one or more segments has been updated or written; and when it has been determined that a majority of the storage groups in at least one of the one or more segments has been updated or written, copy the at least one segment to the non-volatile storage unit. Attached Figure Description

[0014] Therefore, a detailed understanding of the foregoing features of this disclosure, a more specific description of this disclosure, and the foregoing brief overview can be obtained by referring to the embodiments, some of which are shown in the accompanying drawings. However, it should be noted that the drawings only illustrate typical embodiments of this disclosure and should therefore not be considered as limiting its scope, as this disclosure allows for other equally effective embodiments.

[0015] Figure 1 This is a schematic block diagram illustrating a storage system according to one implementation scheme.

[0016] Figure 2A The illustration shows a partition namespace used in a storage device according to one implementation scheme.

[0017] Figure 2B An example of an implementation scheme is shown. Figure 2A A state diagram of the partition namespace of the storage device.

[0018] Figure 3 This is a schematic block diagram illustrating a data storage device according to one embodiment.

[0019] Figures 4A to 4C This is a flowchart illustrating methods for power failure protection of data in a storage device according to various implementation schemes.

[0020] For ease of understanding, the same reference numerals are used where possible to denote the same elements common in the accompanying drawings. It is conceivable that elements disclosed in one embodiment may be advantageously used in other embodiments without specific description. Detailed Implementation

[0021] In the following text, reference is made to embodiments of this disclosure. However, it should be understood that this disclosure is not limited to the specifically described embodiments. Rather, consider any combination of the following features and elements (whether or not related to different embodiments) to achieve and practice this disclosure. Furthermore, while embodiments of this disclosure may achieve advantages over other possible solutions and / or over the prior art, achieving a particular advantage through a given embodiment is not a limitation of this disclosure. Therefore, the following aspects, features, embodiments, and advantages are illustrative only and should not be considered elements or limitations of the appended claims unless expressly stated in the claims. Similarly, reference to “this disclosure” should not be construed as a generalization of any inventive subject matter disclosed herein and should not be considered elements or limitations of the appended claims unless expressly stated in the claims.

[0022] This disclosure relates throughout to a method of operating a storage device. The storage device includes a controller comprising a first random access memory (RAM1), a second random access memory (RAM2), and storage cells divided into multiple partitions. When a write command is received to write data to a partition, change log data is generated and stored in RAM1. Previous incremental data for that partition is copied from RAM2 to RAM1 for updating using the change log data, and the updated incremental data is copied to RAM2. The incremental data stored in RAM2 is periodically copied to the storage cells. The controller tracks which incremental data has been copied to RAM2 and the storage cells. During a power outage, the incremental data and the change log data are copied from RAM1 or RAM2 to the storage cells.

[0023] Figure 1 This is a schematic block diagram illustrating a storage system 100 according to one or more technologies of the present disclosure, wherein storage device 106 can be used as a storage device for host device 104. For example, host device 104 can utilize non-volatile storage cells 110 (such as non-volatile memory (NVM)) included in storage device 106 to store and retrieve data. For example, non-volatile storage cells 110 can be any type of non-volatile memory, such as MRAM, NAND, NOR, or HDD. In the following description, for simplicity and illustrative purposes, non-volatile storage cell 110 is referred to as non-volatile memory (NVM) 110. Host device 104 includes host DRAM 138. In some examples, storage system 100 may include multiple storage devices, such as storage device 106, that can operate as a storage array. For example, storage system 100 may include multiple storage devices 106 configured as a low-cost / independent disk (RAID) redundant array that collectively serves as a high-capacity storage device for host device 104.

[0024] Storage system 100 includes host device 104, which can store data to and / or retrieve data from one or more storage devices, such as storage device 106. Figure 1 As shown, host device 104 can communicate with storage device 106 via interface 114. Host device 104 can include any of a variety of devices, including computer servers, network attached storage (NAS) units, desktop computers, laptops, tablets, set-top boxes, mobile phones such as so-called "smart" phones, so-called "smart" tablets, televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, etc.

[0025] Storage device 106 includes a controller 108, an NVM 110, a power supply 111, a first random access memory (RAM) or volatile memory 112 (such as dynamic random access memory (DRAM)), and an interface 114. The controller 108 may include an XOR engine 124 and a second RAM or volatile memory 118, such as static random access memory (SRAM). In the following description, for simplicity and illustrative purposes, the first RAM or volatile memory 112 is referred to as DRAM, and the second RAM or volatile memory 118 is referred to as SRAM. In some examples, for clarity, storage device 106 may include... Figure 1 Additional components not shown. For example, storage device 106 may include a printed circuit board (PCB) to which components of storage device 106 are mechanically attached, and the PCB includes conductive traces for electrically interconnecting components of storage device 106, etc. In some examples, the physical dimensions and connector configuration of storage device 106 may conform to one or more standard form factors. Some exemplary standard form factors include, but are not limited to, 2.5” data storage devices (e.g., HDDs or SSDs), 1.8” data storage devices, peripheral component interconnects (PCI), PCI expansion (PCI-X), PCI Express (PCIe) (e.g., PCIe x1, x4, x8, x16, PCIe Mini cards, MiniPCI, etc.). In some examples, storage device 106 may be directly coupled (e.g., directly soldered) to the motherboard of host device 104.

[0026] The interface 114 of storage device 106 may include one or both of a data bus for exchanging data with host device 104 and a control bus for exchanging commands with host device 104. Interface 114 may operate according to any suitable protocol. For example, 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, PCIe, Non-Volatile Memory Standard (NVMe), OpenCAPI, GenZ, Cache Coherent Interface Accelerator (CCIX), Compute Fast Link (CXL), Open Channel SSD (OCSSD), etc. Electrical connections (e.g., data bus, control bus, or both) of interface 114 are electrically connected to controller 108, thereby providing an electrical connection between host device 104 and controller 108, allowing data exchange between host device 104 and controller 108. In some examples, the electrical connection of interface 114 can also allow storage device 106 to receive power from host device 104. For example, as Figure 1As shown, power supply 111 can receive power from host device 104 via interface 114.

[0027] Storage device 106 includes NVM 110, which may include multiple memory devices or storage cells. NVM 110 can be configured to store and / or retrieve data. For example, a storage cell of NVM 110 can receive data and receive messages from controller 108 instructing the storage cell to store data. Similarly, a storage cell of NVM 110 can receive messages from controller 108 instructing the storage cell to retrieve data. In some examples, each storage cell in the storage unit 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.).

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

[0029] NVM 110 may include multiple flash memory devices or memory cells. The flash memory devices may include NAND-based or NOR-based flash memory devices and may store data based on the charge contained in the floating gate of the transistors 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 of the multiple blocks within a particular memory device may include multiple NAND cells. Rows of NAND cells may be electrically connected using word lines to define pages within the multiple pages. A corresponding cell in each of the multiple pages may be electrically connected to a corresponding bit line. Furthermore, the NAND flash memory device may be a 2D or 3D device and may be a single-level cell (SLC), multi-level cell (MLC), three-level cell (TLC), or four-level cell (QLC). 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.

[0030] Storage device 106 includes a power supply 111 that can provide power to one or more components of storage device 106. When operating in standard mode, power supply 111 can use power provided by an external device such as host device 104 to power one or more components. For example, power supply 111 can use power received from host device 104 via interface 114 to power one or more components. In some examples, power supply 111 may include one or more power storage components configured to power one or more components when operating in a shutdown mode, such as when power is stopped from receiving power from external devices. In this way, power supply 111 can be used as an onboard backup power source. Some examples of one or more power storage components include, but are not limited to, capacitors, supercapacitors, batteries, etc. In some examples, the amount of electricity 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 one or more power storage components. In other words, as the amount of electricity stored by one or more power storage components increases, the cost and / or size of one or more power storage components also increases.

[0031] Storage device 106 also includes volatile memory that can be used by controller 108 to store information. The volatile memory may include one or more volatile storage devices. In some examples, controller 108 may use the volatile memory as a cache. For example, controller 108 may store cached information in the volatile memory until the cached information is written to NVM 110. Examples of volatile memory 112 include, but are not limited to, RAM, DRAM 112, SRAM 118, and synchronous dynamic RAM (SDRAM (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, LPDDR4, DDR5, LPDDR5, etc.)). Figure 1 As shown, the volatile memory can consume power received from power supply 111.

[0032] Various types of volatile memory can be used for different access attributes. For example, DRAM can be arranged for longer burst accesses to allow for improved bandwidth (BW) of the same access bus. Alternatively, DRAM can be used with smaller accesses, making random small accesses potentially have better latency. Controller 108 includes additional optional SRAM and / or embedded MRAM 126. Embedded MRAM 126 is another alternative memory that can be used in another implementation. Similarly, access to MRAM 126 can be optimized for different design purposes, but the number of embedded MRAM 126 in an SSD controller can be cost-sensitive. Therefore, the selection of how much data and which data goes into advanced non-volatile memory and advanced volatile memory will be subject to system trade-offs.

[0033] Storage device 106 includes a controller 108 that can manage one or more operations of storage device 106. For example, controller 108 can manage reading data from and / or writing data to NVM 110 via a switching mode (TM) bus 128. In some embodiments, when storage device 106 receives a write command from host device 104, controller 108 can initiate a data storage command to store data to NVM 110 and monitor the progress of the data storage command. Controller 108 can determine at least one operating characteristic of storage system 100 and store at least one operating characteristic to NVM 110. In some embodiments, when storage device 106 receives a write command from host device 104, controller 108 temporarily stores data associated with the write command in internal memory or a buffer (not shown) before sending the data to NVM 110.

[0034] Controller 108 may include an XOR engine 124 having logical and / or features for generating parity information. The XOR parity information can be used to improve the reliability of storage device 106, such as enabling data recovery in the event of a data write failure or data read failure to and from the NVM, or data recovery in the event of a power outage. Reliability can be provided by using parity information generated or computed based on data stored in storage device 106. Data may be written to NVM 110 via XOR engine 124. XOR engine 124 may generate a parity stream to be written to SRAM 118. SRAM 118 and DRAM 112 may each contain multiple locations where data can be written. Data may be transferred from an SRAM region (not shown) in SRAM 118 to a DRAM region (not shown) in DRAM 112, and vice versa.

[0035] Figure 2A A partition namespace (ZNS) 202 view used in storage device 200 according to one embodiment is shown. Storage device 200 can present the ZNS 202 view to a host device. Figure 2B A state diagram 250 of the ZNS 202 of a storage device 200 according to one embodiment is shown. The storage device 200 may be... Figure 1The storage device 106 of the storage system 100. The storage device 200 may have one or more ZNS 202, and each ZNS 202 may have a different size. In addition to the one or more partition namespaces 202, the storage device 200 may also include one or more general namespaces. Furthermore, the ZNS 202 may be a partition block command (ZBC) for SAS and / or a partition device ATA command set (ZAC) for SATA. Due to the possible relationship between logical and physical activities, host-side partitioning activities may be more directly related to media activities in the partition drive.

[0036] In storage device 200, ZNS 202 is the number of NVMs that can be formatted into logical blocks so that the capacity is divided into multiple partitions 206a-206n (collectively referred to as partition 206). NVMs can be... Figure 1 The storage cells or NVM 110. Each partition in partition 206 includes multiple physical blocks or erase blocks (not shown) of storage cells or NVM 204, and each of these erase blocks is associated with multiple logical blocks (not shown). Each partition in partition 206 may have a size aligned with the capacity of one or more erase blocks of an NVM or NAND device. When controller 208 receives a command from a host device (not shown) or a host device's submission queue, controller 208 may read data from and write data to the multiple logical blocks associated with the multiple erase blocks (EB) of ZNS 202. Each logical block is associated with a unique LBA or sector.

[0037] In one implementation, NVM 204 is a NAND device. The NAND device includes one or more dies. Each of the one or more dies includes one or more planes. Each of the one or more planes includes one or more erase blocks. Each of the one or more erase blocks includes one or more word lines (e.g., 256 word lines). Each of the one or more word lines can be addressed in one or more pages. For example, an MLC NAND die can use the top and bottom pages to reach two bits in each cell of the entire word line (e.g., 16 KiB per page). Furthermore, each page can be accessed at a granularity equal to or smaller than a full page. The controller can frequently access the NAND with a user data granularity logical block address (LBA) size of 512 bytes. Therefore, as mentioned in the description below, the NAND location is equal to a granularity of 512 bytes. Thus, the LBA size is 512 bytes and the page size of the two pages of the MLC NAND is 16 KiB, resulting in 32 LBAs per word line. However, the NAND location size is not intended to be limiting and is only used as an example.

[0038] When data is written to an erase block, one or more logical blocks within partition 206 are updated accordingly to track the data's location within NVM 204. Data can be written to one partition 206 at a time until partition 206 is full, or to multiple partitions 206 such that multiple partitions 206 may become partially full. Similarly, when data is written to a specific partition 206, data can be written to multiple erase blocks one at a time, page-by-page or word-by-word, in NAND position order, until moving to an adjacent block (i.e., writing to the first erase block until the first erase block becomes full before moving to the second erase block), or multiple erase blocks can be written to multiple blocks one at a time, page-by-page or word-by-word, in NAND position order to partially fill each block in parallel (i.e., writing to the first NAND position or page of each erase block before writing to the second NAND position or page of each erase block). This sequential programming of each NAND position is a typical non-restrictive requirement for many NAND EBs.

[0039] When controller 208 selects an erase block to store data for each partition, it can select the erase block during the partition's open time, or it can select the erase block when the first word line of that particular erase block needs to be filled. This can be even more significant when using the method described above, which involves fully filling an erase block before starting the next erase block. Controller 208 can use this time difference to select a more optimized erase block on an on-the-fly basis. The decision of which erase block to allocate and assign to each partition and its consecutive LBAs can occur continuously within controller 208 for zero or more concurrent partitions.

[0040] Each partition in partition 206 is associated with a partition start logical block address (ZSLBA) or a partition start sector. The ZSLBA is the first available LBA in partition 206. For example, the first partition 206a is associated with ZSLBA. a SLBA is associated with the second partition 206b and Z. b SLBA is associated with the third partition 206c and Z. c SLBA is associated with the fourth partition 206d and Z. d SLBA is associated, and the nth partition 206n (i.e., the last partition) is associated with Z. n SLBAs are associated. Each partition 206 is identified by its ZSLBA and is configured to receive sequential writes (i.e., to write data to the NVM 110 in the order in which write commands are received).

[0041] When data is written to partition 206, the write pointer 210 is advanced or updated to point to or indicate the next available block in partition 206 for writing data, in order to track the next write start point (i.e., the completion point of a previous write is equal to the start point of a subsequent write). Therefore, the write pointer 210 indicates where subsequent writes to partition 206 will begin. A subsequent write command is a "partition append" command, where the data associated with the subsequent write command is appended to partition 206 at the location indicated by the write pointer 210 as the next start point. A sorted list of LBAs within partition 206 can be stored for write ordering. Each partition 206 may have its own write pointer 210. Therefore, when a write command is received, the partition is identified by its ZSLBA, and the write pointer 210 determines the position within the identified partition where data writing begins.

[0042] Figure 2B Showing the target Figure 2A State diagram 250 of ZNS 202. In state diagram 250, each partition can be in different states, such as empty, active, full, or offline. When a partition is empty, it contains no data (i.e., any erase blocks in the partition do not currently store data), and the write pointer is at ZSLBA (i.e., WP = 0). Once a write is made to the partition scheduler or a partition open command 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 partitions between the partition open and partition closed states (both active states). If a partition is active, it includes writable open blocks and can provide the host with a description of the recommended time in the active state. Controller 208 includes the ZM. Partition metadata can be stored in the ZM and / or controller 208.

[0043] The term "write" includes programming user data in zero or more NAND locations within an erase block and / or in a portion of the fill NAND locations within an erase block before all available NAND locations have been filled. The term "write" may also include moving a partition to full due to: internal drive processing needs (due to open block data retention issues caused by error bits accumulating faster on open erase blocks), storage device 200 shutting down or filling a partition due to resource constraints (such as too many open partitions to trace or a discovered defective state), or host device shutting down a partition due to issues such as no more data to send to the drive, computer shutdown, error handling on the host, limited host resources for tracing, etc.

[0044] Active partitions can be open or closed. An open partition is an empty or partially filled partition that is ready to be written to and has currently allocated resources. Data received from the host device using write commands or partition append commands can be programmed into an open erase block that is not currently filled with previously filled data. A closed partition is an empty or partially filled partition that is not currently receiving continuous writes from the host. Moving a partition from an open state to a closed state allows the controller 208 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 tasks required by the controller.

[0045] In open and closed partitions, the write pointer points to a position within the partition between the end of the ZSLBA and the end of the partition's last LBA (i.e., WP > 0). The active partition can switch between open and closed states as specified by ZM, or this switching occurs when writes are scheduled to the partition. Additionally, ZM can reset the active partition to clear or erase the data stored in it, causing the partition to switch back to an empty partition. Once the active partition is full, it switches to a full state. A full partition is one completely filled with data, and there are no more available sectors or LBAs for writing data (i.e., WP = partition capacity (ZCAP)). In a full partition, the write pointer points to the end of the partition's writable capacity. Read commands for data stored in a full partition can still be executed.

[0046] A partition can have any total capacity, such as 256 MiB or 512 MiB. However, a small portion of each partition may be inaccessible for writing data but still readable, such as the storage parity data for each partition and portions of one or more excluded erase blocks. For example, if the total capacity of partition 206 is 512 MiB, then the ZCAP could be 470 MiB, which is the capacity available for writing data, while 42 MiB is unavailable for writing data. The writable capacity (ZCAP) of a partition is equal to or less than the total partition storage capacity. Storage device 200 can determine the ZCAP of each partition when a partition is reset. For example, controller 208 or ZM can determine the ZCAP of each partition. When a partition is reset, storage device 200 can determine the ZCAP of that partition.

[0047] ZM can reset a full partition, thereby scheduling the erasure of data stored in that partition and causing it to switch back to an empty partition. When resetting a full partition, although the partition may be marked as an empty partition available for writing, the data on that partition may not be immediately erased. However, the reset partition must be erased before switching to open and active partitions. Partitions can be erased at any time between a ZM reset and a ZM open. When resetting a partition, storage device 200 can determine the new ZCAP of the reset partition and update the writable ZCAP attribute in the partition metadata. An offline partition is a partition in which data cannot be written. An offline partition can be full, empty, or partially full but not active.

[0048] Since resetting a partition erases all data stored in that partition or schedules the erasure of all data stored in that partition, the need for garbage collection of individual erase blocks is eliminated, thus improving the overall garbage collection process of storage device 200. Storage device 200 may mark one or more erase blocks for erasure. When a new partition is about to be formed and storage device 200 anticipates ZM opening, one or more erase blocks marked for erasure may be erased. Storage device 200 may also determine and create the physical backing for the partition when erasing the erase block. Therefore, once a new partition is opened and an erase block is selected to form the partition, that erase block will be erased. Furthermore, each time a partition is reset, a new order of LBA and write pointer 210 for partition 206 can be selected, allowing partition 206 to tolerate out-of-order command reception. Write pointer 210 may optionally be turned off, allowing commands to be written to any starting LBA indicated by the command.

[0049] Re-reference Figure 2A When the host sends a write command to write data to partition 206, controller 208 pulls the write command in and identifies it as a write to the newly opened partition 206. Controller 208 selects a set of exponents (EBs) to store the data associated with the write command to the newly opened partition 206, and the newly opened partition 206 becomes the active partition 206. The write command can be a command to write new data or a command to move valid data to another partition for garbage collection purposes. Controller 208 is configured to read new commands from a commit queue filled by the host device via DMA.

[0050] In the empty partition 206 that has just been switched to active partition 206, data is assigned to partition 206 and a set of associated sequential LBAs starting from the ZSLBA of partition 206, as the write pointer 210 indicates the logical block associated with the ZSLBA as the first available logical block. This data can be written to one or more erase blocks or NAND locations already allocated for the physical location of partition 206. After the data associated with the write command is written to partition 206, the write pointer 210 is updated to point to the next LBA available for host writes (i.e., the completion point of the first write). The write data from this host write command is sequentially programmed into the next available NAND location in the erase block selected for partitioning based on the physical support.

[0051] For example, controller 208 may receive a first write command or a first partition append command to third partition 206c. The host sequentially identifies which logical block of partition 206 is used to write the data associated with the first command. The data associated with the first command is then written to the first or next one or more available LBAs in third partition 206c as indicated by write pointer 210, and write pointer 210 is advanced or updated to point to the next available LBA available for host write (i.e., WP > 0). If controller 208 receives a second write command or a second partition append command to third partition 206c, the data associated with the second write command is written to the next available LBA in third partition 206c identified by write pointer 210. Once the data associated with the second command has been written to third partition 206c, write pointer 210 is again advanced or updated to point to the next available LBA available for host write. Resetting third partition 206c moves write pointer 210 back to Z. c SLBA (i.e., WP=0), and the third partition 206c is switched to an empty partition.

[0052] Figure 3 This is a schematic block diagram illustrating a data storage device 300 according to one embodiment. Figure 1 The aspects of system 100 may be similar to data storage device 300. In the following description, for simplicity and illustrative purposes, non-volatile memory cell 306 is referred to as NVM, the first RAM or volatile memory 312 (i.e., first RAM1) is referred to as DRAM, and the second RAM or volatile memory 308 (i.e., second RAM2) is referred to as SRAM. In storage device 300, power supply 320 is coupled to one or more energy storage devices 318 (such as one or more capacitors) and controller 302.

[0053] Data storage device 300 can be Figure 1 Data storage device 106 or Figure 2AThe storage device 200. The controller 302 may be... Figure 1 The controller 108, parity check or XOR engine 304 can be Figure 1 The XOR engine 124, and the second volatile memory 308 can be Figure 1 The second volatile memory 118, and the first volatile memory 312 may be Figure 1 The first volatile memory 112. Similarly, the power supply 320 can be Figure 1 The power supply 111, and one or more energy storage devices 318 may be Figure 1 One or more capacitors 120, and the non-volatile memory cell 306 may be Figure 1 The non-volatile memory unit 110.

[0054] The NVM 306 may include one or more multilevel cells, such as SLC, MLC, TLC, QLC, or any other iteration of multilevel cells not listed. The NVM 306 may include the same one or more multilevel cells or a mixture of different one or more multilevel cells. The NVM 306 can store relatively large amounts of data (e.g., 128MB, 256MB, 512MB, 1GB, 2GB, 4GB, 8GB, 16GB, 32GB, 64GB, 128GB, 256GB, 512GB, 1TB, etc.), such as user data, parity data, metadata, and any other suitable data not listed to be stored in the NVM 306. The total capacity of the NVM 306 can be divided into multiple partitions, such as... Figure 1 , Figure 2A and Figure 2B The partitions described in the text.

[0055] The phrases “parity data,” “incremental data,” and “change log data” are used throughout as examples of in-flight data and are not intended to be limiting, as other forms of in-flight data may be relevant. In other words, the incremental data discussed in the following examples is in-flight data and may include unwritten host data. Unwritten user or host data may include small lengths or amounts of data (e.g., less than the size of one or more word lines) that are stored in a resident location or buffer (such as SRAM area 310m) until the aggregate size of the data reaches a minimum size (e.g., the size of one or more word lines), in which case the unwritten user data is written to NVM 110. Furthermore, in-flight data may also include tracking information such as the current location of the stored data, the location where the data will be stored, the size of the currently stored data, and the size of the data to be stored. Change log data is new incremental or in-flight data (e.g., new parity data) that has not yet been used to update previous incremental data and / or written to DRAM areas 314a-314n or NVM 306. This change log data is tracked using an L2P table, as discussed further below.

[0056] Parity data, considered as in-flight data, is considered a parity buffer and protects against data loss due to data corruption, faulty bit transmission, power outages, and other causes of data loss. Incremental data or portions of incremental data can be generated or updated in SRAM 308 and are temporarily stored in SRAM 308 and / or DRAM 312, for example, before being copied to NVM 306. Incremental data is stored in a suitable location within NVM 306 dedicated to data power failure protection, such as residence location 316. In the event of a power failure, data (such as incremental data or parity data) stored in the first volatile memory 312 and / or the second volatile memory 308, which has the appropriate electrical charge to program incremental data from the first volatile memory 312 and / or the second volatile memory 308 to residence location 316 of NVM 306, may be lost unless the storage device includes one or more energy storage devices 318. The incremental data in the resident location 316 can be used to reconstruct relevant data lost in volatile memories 308 and 312 due to a power outage event.

[0057] Residency location 316 includes one or more erase blocks in NVM 306 dedicated to data residency. These erase blocks are determined at the beginning of the drive's lifetime and can be changed during the drive's lifetime based on erase block characteristics. The one or more erase blocks in residency location 316 are written sequentially. Data stored in residency location 316 may include in-flight data, incremental data, parity data, and tracking data. Following a power outage event, controller 302 can use the relevant data in residency location 316 to reconstruct lost data. This relevant data can be determined through some type of tracking, such as a header (i.e., the expected starting point).

[0058] Furthermore, for example, in the event of a power failure, one or more energy storage devices 318 located within storage device 300 (such as batteries, capacitors, or vendor-approved system-level power supplies after the host issues an alarm for a power failure event) can store sufficient energy to program data from DRAM 312 to NVM 306 to help prevent data loss. In one embodiment, the storage device has a "hot-swap" capability, allowing the storage device to sense and detect the loss of incoming power and provide the necessary resources (such as energy storage devices) to achieve power failure safety. In another embodiment, the host issues an impending power failure alarm to the storage device, notifying the storage device to proactively enter a power failure safe state.

[0059] NVM 306 includes one or more dedicated data residency segments for residing in-flight data or incremental data, which can be any suitable multilevel cell memory (not shown). As used herein, the term "residency" refers to the exchange of storage locations for active partition information. For example, data or information stored in SRAM 308 can reside in DRAM 312, and data or information stored in DRAM 312 can reside in NVM 306. The one or more dedicated data residency segments can be SLC, MLC, TLC, QLC, etc., and are examples of various implementations for data residency segments. The one or more dedicated data residency segments of NVM 306 include multiple residency locations. Such terminology is not intended to be limiting, but rather to provide examples of possible implementations for reference.

[0060] SRAM device 308 and DRAM device 312 each individually include one or more dies. Each of these one or more dies includes one or more memory groups, which in turn include one or more repositories. These repositories consist of rows and pages. SRAM 308 in controller 302 may be logically or physically divided into different SRAM regions or areas 310a-310n for use by controller 302. Similarly, DRAM 312 may be logically or physically divided into different DRAM regions or areas 314a-314n for use by controller 302. MRAM cells (not shown) within controller 302 may be logically or physically divided into different MRAM regions or areas. External accessories for MRAM typically have vendor-specific architectures and access permissions, which are not described here. For illustrative purposes, volatile repositories (such as SRAM repositories or DRAM repositories) may be referred to throughout as volatile memory regions, such as SRAM regions or DRAM regions.

[0061] Data storage device 300 includes a first volatile memory 312 (e.g., DRAM or RAM1), which includes one or more first volatile memory regions 314a-314n (e.g., DRAM regions or RAM1 regions). The term "n" refers to the last position in the sequence and is not limited to a maximum value. Furthermore, DRAM regions 314a-314n may be collectively referred to as DRAM region 314. DRAM region 314 may be divided into multiple segments 324a-324c (collectively referred to as "segments 324"), where each segment 324 is of equal size. In another embodiment, DRAM region 314 may be divided into multiple segments 324, where each segment 324 is of different size. Segment 324 may include one or more DRAM regions 314, such as a number of DRAM regions 314, where "x" refers to an integer. For example, first segment 324a includes first DRAM region 314a, second DRAM region 314b, and third DRAM region 314c. Similarly, the second segment 324b includes the fourth DRAM region 314d, the fifth DRAM region 314e, and the sixth DRAM region 314f. The third segment 324c includes the seventh DRAM region 314g, the eighth DRAM region 314h, and the ninth DRAM region 314i. The number of DRAM regions in the segments and the number of segments listed are not intended to be limiting, but rather to provide examples of possible implementations. Furthermore, although only three DRAM segments 324 are shown, any number of segments 324 may be included.

[0062] Each segment of DRAM 312 or SRAM regions 310a-310m (i.e., segment 1324a, segment 2324b, segment 3324c, etc.) can be programmed into resident location 316 after one or more criteria are met. For example, one criterion could be that when one or more regions 310 of SRAM 308 are storing change log data (e.g., new parity data) that has not yet been copied to DRAM 312, controller 302 can program one or more regions 310 of SRAM 308 storing change log data into resident location 316, as described below. Figure 4A This will be discussed further below. In one implementation, segment 324 of DRAM 312 is periodically copied to NVM 306 after a predetermined amount of time has elapsed, as described below. Figure 4B Further discussion follows. In another implementation, one or more DRAM regions 314 storing the updated incremental data may be most of the DRAM regions 314a-314n within segment 324 (e.g., two of the three DRAM regions 314a-314c of the first segment 324a), in which case segment 324 is copied to NVM 306, as described below. Figure 4C Further discussion is needed.

[0063] Furthermore, each DRAM region 314 can be associated with a partition, such that a segment 324 comprising three DRAM regions 314 stores data for three partitions. In one embodiment, each of the one or more segments stores data for approximately one to approximately eight partitions. For example, a first segment 324a can store data for three partitions, with the data for each partition stored in a separate DRAM region 314.

[0064] Another criterion could be that after a predetermined amount of time has elapsed, the controller 302 can program segments of DRAM 312 to residency location 316. In one embodiment, this predetermined amount of time could be approximately 20 seconds (e.g., each segment 324 is programmed to NVM 306 once per minute). In another embodiment, this predetermined amount of time could be approximately one minute (e.g., each segment 324 is programmed to NVM 306 once every three minutes). The predetermined amounts of time listed are not intended to be limiting, but rather to provide examples of possible implementations.

[0065] In one embodiment, each segment of DRAM 312 (such as segment 1324a, segment 2324b, and segment 3324c) may be sequentially programmed into residence location 316 after a predetermined amount of time has elapsed. In another embodiment, each segment of DRAM 312 may be randomly programmed into residence location 316 after a predetermined amount of time has elapsed. In yet another embodiment, each segment of DRAM 312 may be simultaneously programmed into residence location 316 after a predetermined amount of time has elapsed. In yet another embodiment, each segment of DRAM 312 may be sequentially programmed into residence location 316 after a predetermined amount of time has elapsed.

[0066] DRAM 312 may include a first logic-to-physical (L2P) table (not shown) including pointers indicating or pointing to each physical location of the LBAs of parity data in DRAM 312, each physical location of the LBAs of updated parity data or incremental data in the second volatile memory 308 (e.g., SRAM or RAM2), and each physical location of the LBAs of data stored in NVM 306. Controller 302 may utilize the L2P table to track the location of relevant data, such as incremental data or change log data, that has not yet been programmed into resident location 316. NVM 306 may include a second L2P table (not shown), wherein the second L2P table of NVM 306 is periodically updated to match the first L2P table of DRAM 312. The second L2P table to match the first L2P table may be updated based on a predetermined amount of time, the number of updates to the first L2P table, or any other suitable criterion used to update the second L2P table to match the first L2P table.

[0067] During a power failure event, incremental data backup can be optimized by transferring incremental data from second volatile memory regions 310a-310n (e.g., SRAM regions or RAM2 regions) that have not yet been programmed to residency location 316. Change log data in SRAM 308 or host data that has not yet been written to NVM 306 is tracked in the L2P table as "Change Log Data," where "Change Log Data" refers to new incremental data (e.g., new parity data) that has not yet been used to update previous incremental data and subsequently written to DRAM regions 314a-314n, or host data that has not yet been written to NVM 306. Programming incremental data that has not yet been written from SRAM regions 310a-310n to residency location 316 may be faster than programming incremental data from SRAM regions 310a-310n to DRAM regions 314a-314n and / or from DRAM regions 314a-314n to residency location 316. In addition, incremental data can be programmed as a whole into residence location 316 or divided into multiple segments and programmed into residence location 316 as individual segments.

[0068] By tracking change log data in the L2P table, updated incremental data or updated parity data in SRAM 308 and DRAM 312 can be programmed into residency location 316, instead of programming all incremental data in SRAM 308 and DRAM 312 into residency location 316. This allows more overall data to be programmed into NVM 306, as described below. Figure 4B Further discussion follows. Incremental data and / or change log data can be stored in temporary SRAM areas, such as SRAM areas 310n and / or 310m, where data is stored for a short period. In contrast, the remaining SRAM areas 310a-310n-1 can be non-temporary SRAM areas 310a-310n-1, where data can be stored for a long period. SRAM 308 may include one or more temporary SRAM areas 310an, 310m and multiple non-temporary SRAM areas 310a-310n-1.

[0069] Figures 4A to 4C This is a flowchart illustrating methods for power fault protection of data in a device based on storage according to various implementation schemes. It can be combined with... Figures 4A to 4C The implementation scheme described herein can be used or referenced. Figure 1 Storage system 100 Figure 2A and Figure 2B The use of ZNS storage devices 200 Figure 3 Storage devices 300 and / or Figure 3 The data storage device 300. Figures 4A to 4C Methods 400, 425, and 450 should be referred to as applicable. Figure 3 The preceding figures have been described. Although reference to the preceding figures may not be made in each aspect of methods 400, 425, and 450, embodiments of the preceding figures are applicable. Figures 4A to 4C Methods 400, 425, and 450 are described herein. Furthermore, one or more aspects of methods 400, 425, and 450 may be used in combination with each other, or methods 400, 425, and 450 may be implemented individually.

[0070] In addition, power failure events can Figures 4A to 4C This occurs during any operation (i.e., a frame) of the flowchart. Storage devices (such as those previously mentioned) include energy storage devices (e.g., batteries, capacitors, or vendor-approved system-level power supplies after the host issues an alarm for a power failure event), such as... Figure 3 One or more energy storage devices 318, the one or more energy storage devices storing energy for controllers (such as...) Figure 3 The controller 302) has sufficient power to reach Figures 4A to 4C The command and / or operation queue is completed before the power failure determination operation in the flowchart. In one embodiment, the storage device has a "hot-swap" capability, allowing the storage device to sense and detect the loss of incoming power and provide the necessary resources (such as energy storage devices) to achieve power failure safety. In another embodiment, the host sends an alert to the storage device about an impending power failure, notifying the storage device to proactively enter a power failure safe state. Although the term "first partition" is used in the description herein, "first partition" can refer to one or more partitions with host read / write operations occurring on the partition.

[0071] Figure 4A This is a flowchart illustrating a method 400 for power failure protection of data in a storage device according to one embodiment. One or more operations or blocks of method 400 may be performed simultaneously. At block 402, controller 302 receives one or more commands to write data to a first partition (such as first partition 206a of FIG. 2) of a plurality of partitions. For example, the first write command includes writing data to the first partition where data is already stored. At block 404, previous incremental data of the first partition is copied from DRAM regions 314a-314n to SRAM regions 310a-310n. For example, when controller 302 receives a first write command to write data to the first partition, first incremental data stored in the first DRAM region 314a is copied to the first SRAM region 310a.

[0072] At block 406, for each of the received one or more write commands, the parity or XOR engine 304 generates change log data (i.e., new incremental data or new parity data) associated with a first partition in temporary region 310m of SRAM 308. For example, for a first write command, the parity or XOR engine 304 generates first change log data and writes this first change log data to temporary SRAM region 310m. At block 408, the first change log data generated at block 406 is used to update the previous first incremental data associated with the first partition, such as the previous incremental data of the region copied to SRAM 308 at block 404. In other words, the first change log data in temporary SRAM region 310m updates the previous first incremental data copied from first DRAM region 314a to first SRAM region 310a to form the updated first incremental data. The operations at blocks 404 and 406 can occur simultaneously.

[0073] At block 410, the updated first incremental data (or a portion of the updated first incremental data) is copied from SRAM region 310a to a DRAM region, such as the eighth DRAM region 314h. At block 412, the controller utilizes the L2P table of DRAM 312 to track when the previous first incremental data was updated with the first change log data and to track the location of the updated first incremental data (or a portion of the updated first incremental data). However, the L2P table is not limited to tracking only the updated incremental data. The L2P table may have pointers to track the locations of old or previous incremental data, change log data, user data, metadata, empty data, etc. The location of change log data may be stored in a separate L2P table, such as an incremental change log L2P table. In various embodiments, a first L2P table tracks the location of host data written to the NVM 306, and a second L2P table tracks the location of change log data and / or incremental data stored in SRAM regions 310a-310n or DRAM regions 314a-314n.

[0074] If a power failure event occurs during any of the preceding steps of method 400, such as during one of blocks 402-412, controller 302 determines or confirms the power failure event at block 414. Then, at block 416, controller 302 uses power stored in one or more energy storage devices 318 to program potentially lost data (such as incremental data and / or change log data) to a location in NVM 306. The controller uses the L2P table of DRAM 312 to determine the location of change log data (such as first change log data) in volatile memory, such as in SRAM and / or DRAM, and copies any change log data to NVM 306 if previous incremental data has not yet been updated using this change log data. For example, if the first change log data and / or the updated first incremental data located in SRAM region 310a have not yet been written to DRAM regions 314a-314n in the event of a power failure, the controller 302 uses power provided by one or more energy storage devices 318 to program the first change log data and / or the updated first incremental data from SRAM region 310a to a location in NVM 306, such as resident location 316.

[0075] However, if no power failure event occurs before block 414, after tracking at block 412 whether the previous first incremental data has been updated using the first change log data, at block 402, controller 302 waits to receive one or more commands to write data to one or more partitions and repeats method 400. Controller 302 can use any of the multiple partitions to repeat method 400, and method 400 can operate simultaneously with multiple commands to multiple different partitions.

[0076] Figure 4B This is a flowchart illustrating a method 425 for power failure protection of data in a storage device according to another embodiment. One or more operations or blocks of method 425 may be performed simultaneously. Figure 3 The aspect used to illustrate method 425. At block 426, controller 302 receives one or more commands to write data to a first partition (such as first partition 206a of FIG. 2) among a plurality of partitions. For example, it may receive a first write command to write data to the first partition where data is stored, and it may receive a second write command to write data to a second partition where data is stored.

[0077] At box 428, previous incremental data of the first partition is copied from DRAM regions 314a-314n or from resident location 316 to SRAM regions 310a-310n. For example, previous first incremental data associated with the first partition stored in the first DRAM region 314a (or resident location 316) is copied to the first SRAM region 310a. Similarly, previous second incremental data associated with the second partition stored in the second DRAM region 314b (or resident location 316) is copied to the second SRAM region 310b.

[0078] At box 430, for each of the received one or more write commands, parity or XOR engine 304 generates change log data associated with at least one of the one or more partitions. For example, parity or XOR engine 304 generates first change log data for a first partition and writes the first change log data to an SRAM area, such as temporary SRAM area 310n. Similarly, parity or XOR engine 304 generates second change log data for a second partition and writes the second change log data to an SRAM area, such as fifth SRAM area 310e.

[0079] At box 432, then for each of the one or more write commands, the change log data is used to update the previous incremental data associated with at least one partition currently stored in SRAM regions 310a-310n. For example, the previous incremental data stored in the first SRAM region 310a is updated using the first change log data stored in the temporary SRAM region 310n, and the second previous incremental data stored in the second SRAM region 310b is updated using the second change log data stored in the fifth SRAM region 310e, to form updated first incremental data associated with the first partition and updated second incremental data associated with the second partition.

[0080] At box 434, updated incremental data (or portions of updated incremental data) associated with the at least one partition stored in SRAM 308 is copied from SRAM 308 to one or more segments of a region in DRAM 312. For example, updated first incremental data (or portions of updated first incremental data) stored in a first SRAM region 310a is written to a DRAM region (such as first DRAM region 314a) located in a first segment 324a of DRAM 312, and updated second incremental data (or portions of updated second incremental data) stored in a second SRAM region 310b is written to a DRAM region (such as fourth DRAM region 314d) located in a second segment 324b of DRAM 312.

[0081] At box 436, after a first predetermined amount of time (such as about 20 seconds or about 1 minute) has expired, controller 302 copies one segment of one or more segments 324 from first volatile memory cell 312 to NVM 306 at a time. For example, after a predetermined amount of time has expired, controller 302 copies the first segment 324a of DRAM 312 to residency location 316 in NVM 306.

[0082] At block 438, controller 302 uses an L2P table stored in DRAM 312 to track which segments of one or more segments 324 have been copied to NVM 306. In various embodiments, a first L2P table tracks the location of host data written to NVM 306, and a second L2P table tracks whether segments 324 of DRAM 312 have been copied to NVM 306. If a power failure event occurs during any prior step of method 425, such as during one of blocks 426-438, controller 302 determines or confirms the occurrence of a power failure event at block 440.

[0083] At block 442, controller 302 copies any segments of segment 324 that have not yet been copied to NVM 306 since a second predetermined amount of time has elapsed. For example, first segment 324a of DRAM 312 has been copied to NVM 306, but second segment 324b and third segment 324c have not yet been copied to NVM 306. Controller 302 uses power supplied by one or more energy storage devices 318 to program second segment 324b and third segment 324c to residency location 316 during a power outage event. Controller 302 utilizes power stored in one or more energy storage devices 318 to program potentially lost data (such as incremental data or parity data) to locations in NVM 306. However, if no power outage event occurs, method 425 repeats blocks 426-438 once or more after updating and tracking the L2P table at block 438. The controller 302 can use any of the multiple partitions to repeat method 425, and method 425 can operate simultaneously with multiple commands on multiple different partitions.

[0084] Figure 4C This is a flowchart illustrating a method 450 for power failure protection of data in a storage device according to another embodiment. One or more operations or blocks of method 450 may be performed simultaneously. Figure 3The aspect used to illustrate method 450. At block 452, controller 302 receives one or more commands to write data to one or more partitions. For example, it may receive a first write command to write data to a first partition where data is stored, and it may receive a second write command to write data to a second partition where data is already stored.

[0085] At box 454, previous incremental data for each of the one or more partitions is copied from DRAM regions 314a-314n or from resident location 316 to SRAM regions 310a-310n. For example, previous first incremental data associated with a first partition stored in first DRAM region 314a (or resident location 316) is copied to first SRAM region 310a. Similarly, previous second incremental data associated with a second partition stored in second DRAM region 314b (or resident location 316) is copied to second SRAM region 310b.

[0086] At box 456, for each of the received one or more write commands, parity or XOR engine 304 generates change log data associated with at least one of the one or more partitions (e.g., a first partition and a second partition). For example, parity or XOR engine 304 generates first change log data for the first partition and writes the first change log data to an SRAM region, such as temporary SRAM region 310n. Similarly, parity or XOR engine 304 generates second change log data for the second partition and writes the second change log data to an SRAM region, such as a fifth SRAM region 310e.

[0087] At box 458, then for each of the one or more write commands, the change log data is used to update the previous incremental data associated with at least one partition (e.g., the first partition and the second partition) currently stored in SRAM regions 310a-310n. For example, the previous incremental data stored in the first SRAM region 310a is updated using the first change log data stored in the temporary SRAM region 310n, and the second previous incremental data stored in the second SRAM region 310b is updated using the second change log data stored in the fifth SRAM region 310e, to form updated first incremental data associated with the first partition and updated second incremental data associated with the second partition.

[0088] At box 460, updated incremental data (or portions of updated incremental data) associated with the at least one partition stored in SRAM 308 is copied from SRAM 308 to one or more segments of a region in DRAM 312. For example, updated first incremental data (or portions of updated first incremental data) stored in a first SRAM region 310a is written to a DRAM region (such as first DRAM region 314a) located in a first segment 324a of DRAM 312, and updated second incremental data (or portions of updated second incremental data) stored in a second SRAM region 310b is written to a DRAM region (such as second DRAM region 314b) located in the first segment 324a of DRAM 312.

[0089] At block 462, controller 302 determines when a majority of regions 314a-314n within each of one or more segments 324 has been updated or written. In various embodiments, a first L2P table tracks the location of host data written to NVM 306, and a second L2P table tracks when a majority of regions 314a-314n within each of one or more segments 324 has been updated or written. At block 464, after the determination at block 462, controller 302 copies at least one segment 324a of one or more segments 324 to NVM 306. For example, the first segment 324a includes three DRAM regions 314a, 314b, and 314c. The first DRAM region 314a includes first updated incremental data associated with a first partition, and the second DRAM region 314b includes second updated incremental data associated with a second partition. Therefore, controller 302 determines that two DRAM regions 314a and 314b of the first segment 324a have been updated or written. Since the criteria for most areas within the segment are met (i.e., at least 2 of the 3 areas), the controller 302 programs the first segment 324a to the dwell position 316 of the NVM 306.

[0090] Therefore, any segment 324 of DRAM 312 that includes change log data or updated incremental data that has not yet been copied to NVM 306 takes precedence over other segments 324 of DRAM 312 that store potentially old or obsolete data that may have been copied to NVM 306 (e.g., if segment 324 is copied to NVM 306 after a predetermined amount of time has elapsed, as discussed in method 425).

[0091] If a power failure event occurs during any of the preceding steps of method 450, such as during one of blocks 452-464, controller 302 determines or confirms the occurrence of a power failure event at block 466. Then, at block 468, controller 302 copies any segments of DRAM 312 that have not yet been copied to NVM 306. For example, at block 464, a first segment 324a of DRAM 312 was recently programmed into dwell location 316 of NVM 306. When a power failure event occurs, controller 302 determines that a second segment 324b and a third segment 324c of DRAM 312 have not recently been written to NVM 306. Controller 302 then programs the second segment 324b and the third segment 324c into dwell location 316 of NVM 306. Controller 302 uses power stored in one or more energy storage devices 318 to program potentially lost data (such as parity data) to a location in NVM 306. However, if no power outage event occurs at box 466, method 450 repeats boxes 452-464 once or more. Controller 302 can use any of these multiple partitions to repeat method 450, and method 450 can operate simultaneously with multiple commands to multiple different partitions.

[0092] Data stored in volatile storage units is susceptible to loss during power outages. However, the storage device may include one or more energy storage devices that store power to program data from volatile storage units to non-volatile storage units. By combining various criteria, such as tracking change log data or incremental data that has not yet been programmed into non-volatile storage units, determining a predetermined amount of time before programming segments of volatile storage units to non-volatile storage units, and / or determining that segments of volatile storage units comprise a majority of the change log or updated incremental data (e.g., a large portion of the segment containing the change log or updated incremental data), the power usage of the storage device may be more efficient during power outages, thereby allowing more data to be programmed into non-volatile storage units and ensuring that data loss is minimized or prevented.

[0093] In one embodiment, a storage device includes: a non-volatile storage cell, wherein the capacity of the non-volatile storage cell is divided into multiple partitions, and wherein the non-volatile storage cell includes multiple dies. Each of the multiple dies includes multiple erase blocks. The storage device also includes a first volatile storage cell, a controller coupled to the non-volatile storage cell and the first volatile storage cell, and a second volatile storage cell. The controller is configured to receive one or more commands to write data to the first partition of the multiple partitions, generate change log data of the first partition in a temporary location in the second volatile storage cell, and copy the change log data of the first partition to the non-volatile storage cell in the event of a power failure.

[0094] The controller is further configured to: upon receiving one or more commands to write data to the first partition, copy previous incremental data of the first partition from the first volatile storage unit to the second volatile storage unit; update the previous incremental data using change log data in the second volatile storage unit; copy the updated incremental data from the second volatile storage unit to the first volatile storage unit; copy the updated incremental data from the second volatile storage unit to the non-volatile storage unit; track when the previous incremental data has been updated using the change log data; and copy the change log data to the non-volatile storage unit when the previous incremental data has not yet been updated using the change log data. The storage device also includes one or more energy storage devices configured to provide power to the controller, wherein the controller is configured to use the power provided by the one or more energy storage devices to copy the change log data of the first partition to the non-volatile storage unit in the event of a power failure. The first volatile memory cell stores a first logical-to-physical address table that associates the logical block address of data with the physical address of the data stored in the non-volatile memory cell. The controller is further configured to divide the first logical-to-physical address table into multiple segments and to update a second logical-to-physical address table stored in the non-volatile memory cell, wherein the second logical-to-physical address table is updated according to the size of the divided segments.

[0095] In another embodiment, a storage device includes: a non-volatile memory cell, wherein the capacity of the non-volatile memory cell is divided into multiple partitions, and wherein the non-volatile memory cell includes multiple dies. Each of the multiple dies includes multiple erase blocks. The storage device also includes a first volatile memory cell, the first volatile memory cell including multiple memory groups, wherein the multiple memory groups are divided into one or more segments. The storage device further includes a controller coupled to the non-volatile memory cell and the first volatile memory cell. The controller includes a second volatile memory cell. The controller is configured to: receive one or more write commands to write data to one or more of the plurality of partitions; update incremental data associated with at least one of the partitions in the second volatile storage unit for each of the received write commands, wherein the incremental data is updated for the specific partition whenever a command to write data to the specific partition is received; copy the updated incremental data associated with the at least one partition from the second volatile storage unit to the plurality of storage groups of the first volatile storage unit; and copy one or more segments in the plurality of storage groups of the first volatile storage unit to the non-volatile storage unit, wherein one of the one or more segments is copied to the non-volatile storage unit after a predetermined amount of time has elapsed.

[0096] The controller is further configured to copy updated incremental data from a first volatile memory cell to a resident segment in a non-volatile memory cell. The predetermined time interval is approximately 20 seconds. Each of the one or more segments is copied to the non-volatile memory approximately once per minute. The storage device also includes one or more power storage devices configured to provide power to the controller, wherein the controller is configured to use the power provided by the one or more power storage devices to copy the one or more segments from multiple memory groups of the first volatile memory cell to the non-volatile memory cell in the event of a power failure. The controller is further configured to, upon receiving one or more commands, copy previous incremental data associated with the at least one partition from the first volatile memory cell to the second volatile memory cell, and, for each of the one or more received write commands, generate change log data associated with the at least one partition in the second volatile memory cell, wherein updating the incremental data associated with the at least one partition includes updating the previous incremental data using the change log data. The first volatile memory cell is DRAM or MRAM.

[0097] In another embodiment, a storage device includes: a non-volatile memory cell, wherein the capacity of the non-volatile memory cell is divided into multiple partitions, and wherein the non-volatile memory cell includes multiple dies. Each of the multiple dies includes multiple erase blocks. The storage device also includes a first volatile memory cell, the first volatile memory cell including multiple memory groups, wherein the multiple memory groups are divided into one or more segments. The storage device further includes a controller coupled to the non-volatile memory cell and the first volatile memory cell. The controller includes a second volatile memory cell. The controller is configured to: receive one or more write commands to write data to one or more of the plurality of partitions; update incremental data associated with at least one of the partitions in the second volatile storage unit for each of the received one or more write commands, wherein the incremental data is updated for the specific partition whenever a command to write data to the specific partition is received; copy the incremental data associated with the at least one partition from the second volatile storage unit to the plurality of storage groups in the first volatile storage unit; determine when a majority of the storage groups in each of the one or more segments has been updated or written; and when it has been determined that a majority of the storage groups in at least one of the one or more segments has been updated or written, copy the at least one segment to the non-volatile storage unit.

[0098] Each of the one or more segments stores data from approximately one partition to approximately five partitions. The storage device also includes one or more energy storage devices configured to supply power to a controller, wherein the controller is configured to use the power supplied by the one or more energy storage devices to copy all data stored in the first volatile memory cell to a non-volatile memory cell in the event of a power failure. Each of the one or more segments includes approximately one memory group to approximately ten memory groups. The second volatile memory cell is SRAM, wherein the first volatile memory cell is DRAM, and wherein the non-volatile memory cell is NAND flash memory. The first volatile memory cell is MRAM.

[0099] While the foregoing describes embodiments of this disclosure, other and additional embodiments of this disclosure may be contemplated without departing from the basic scope of this disclosure, the scope of which is defined by the appended claims.

Claims

1. A storage device, the storage device comprising: A non-volatile memory cell, wherein the capacity of the non-volatile memory cell is divided into multiple partitions, and wherein the non-volatile memory cell includes multiple dies, each of the multiple dies includes multiple erase blocks, and wherein each of the multiple partitions includes multiple erase blocks; First volatile memory unit; and A controller coupled to the non-volatile memory unit and the first volatile memory unit, the controller including a second volatile memory unit, wherein the second volatile memory unit includes one or more temporary storage areas and multiple non-temporary storage areas, and wherein the controller is configured to: Receive one or more commands to write data to the first partition of the plurality of partitions; Change log data for the first partition is generated in the first temporary storage area of ​​the one or more temporary storage areas in the second volatile storage unit; Upon receiving one or more commands to write data to the first partition, the previously written incremental data of the first partition is copied from the first volatile storage unit to the first non-temporary storage area of ​​the plurality of non-temporary storage areas of the second volatile storage unit. The previously written incremental data is updated using the change log data in the first non-temporary storage area; as well as When a power failure event occurs while updating previously written incremental data using the change log data, the change log data of the first partition is copied to the non-volatile storage unit.

2. The storage device of claim 1, wherein the controller is further configured to: The updated incremental data is copied from the second volatile storage unit to the first volatile storage unit; and The updated incremental data is copied from the second volatile storage unit to the non-volatile storage unit.

3. The storage device of claim 2, wherein the controller is further configured to: Track whether the previously written incremental data has been updated using the change log data; and In response to the fact that the previously written incremental data has not yet been updated using the change log data, the change log data is copied to the non-volatile storage unit.

4. The storage device of claim 1, further comprising one or more energy storage devices configured to provide power to the controller, wherein the controller is further configured to use the power provided by the one or more energy storage devices to copy the change log data of the first partition to the non-volatile storage unit in the event of a power failure.

5. The storage device of claim 1, wherein the first volatile storage unit is configured to store a first logical-to-physical address table, the first logical-to-physical address table associating logical block addresses of data with physical addresses of the data stored in the non-volatile storage unit.

6. The storage device of claim 5, wherein the controller is further configured to: Divide the first logical-to-physical address table into multiple segments of the specified segment size; and The second logical-to-physical address table stored in the non-volatile memory cell is updated, wherein the second logical-to-physical address table is updated according to the segment size.

7. A storage device, the storage device comprising: A non-volatile memory cell, wherein the capacity of the non-volatile memory cell is divided into multiple partitions, and wherein the non-volatile memory cell includes multiple dies, each of the multiple dies includes multiple erase blocks, and wherein each of the multiple partitions includes multiple erase blocks; The first volatile storage unit includes multiple storage groups, wherein the multiple storage groups are divided into one or more segments; and A controller coupled to the non-volatile memory unit and the first volatile memory unit, the controller including a second volatile memory unit, wherein the second volatile memory unit includes one or more temporary storage areas and multiple non-temporary storage areas, and wherein the controller is configured to: Receive one or more write commands to write data to one or more of the plurality of partitions; For each of the received one or more write commands, incremental data associated with at least one of the one or more partitions is updated in the temporary storage area of ​​the one or more temporary storage areas in the second volatile storage unit, wherein incremental data is updated for the first partition whenever a command to write data to the first partition is received; The updated incremental data associated with the at least one partition is copied from the temporary storage area of ​​the second volatile storage unit to the plurality of storage groups of the first volatile storage unit; as well as One or more segments from the plurality of storage groups of the first volatile storage unit are copied to the non-volatile storage unit, wherein one of the one or more segments is copied to the non-volatile storage unit when a predetermined amount of time expires.

8. The storage device of claim 7, wherein the controller is further configured to copy the updated incremental data from the first volatile storage unit to a resident segment in the non-volatile storage unit.

9. The storage device according to claim 7, wherein the predetermined time is 20 seconds.

10. The storage device of claim 7, wherein each of the one or more segments is copied to the non-volatile storage cell once per minute.

11. The storage device of claim 7, further comprising one or more energy storage devices configured to provide power to the controller, wherein the controller is further configured to use the power provided by the one or more energy storage devices to copy one or more segments of the plurality of storage groups of the first volatile storage cell to the non-volatile storage cell in the event of a power failure.

12. The storage device of claim 7, wherein the controller is further configured to: Upon receiving one or more commands, previously written incremental data associated with the at least one partition is copied from the first volatile storage unit to the non-temporary storage area of ​​the plurality of non-temporary storage areas of the second volatile storage unit; and For each of the received one or more write commands, change log data associated with the at least one partition is generated in a temporary storage area of ​​the one or more temporary storage areas of the second volatile storage unit, wherein updating the incremental data associated with the at least one partition includes updating the previously written incremental data in the non-temporary storage area using the change log data.

13. The storage device of claim 7, wherein the first volatile storage cell is a dynamic random access memory (DRAM) or a magnetoresistive random access memory (MRAM).

14. A storage device, the storage device comprising: A non-volatile memory cell, wherein the capacity of the non-volatile memory cell is divided into multiple partitions, and wherein the non-volatile memory cell includes multiple dies, each of the multiple dies includes multiple erase blocks, and wherein each of the multiple partitions includes multiple erase blocks; The first volatile storage unit includes multiple storage groups, wherein the multiple storage groups are divided into one or more segments; and A controller coupled to the non-volatile memory unit and the first volatile memory unit, the controller including a second volatile memory unit, wherein the second volatile memory unit includes one or more temporary storage areas and multiple non-temporary storage areas, and wherein the controller is configured to: Receive one or more write commands to write data to one or more of the plurality of partitions; For each of the received one or more write commands, incremental data associated with at least one of the one or more partitions is updated in the temporary storage area of ​​the one or more temporary storage areas in the second volatile storage unit, wherein incremental data is updated for the first partition whenever a command to write data to the first partition is received; The incremental data associated with the at least one partition is copied from the temporary storage area of ​​the second volatile storage unit to the plurality of storage groups of the first volatile storage unit; Determine whether more than half of the storage groups within each of the one or more segments have been updated or written; as well as In response to the determination that more than half of the storage group in at least one of the one or more segments has been updated or written, the at least one segment is copied to the non-volatile storage unit.

15. The storage device of claim 14, wherein each of the one or more segments stores data from one to five partitions.

16. The storage device of claim 14, further comprising one or more energy storage devices configured to provide power to the controller, wherein the controller is further configured to use the power provided by the one or more energy storage devices to copy all data stored in the first volatile storage unit to the non-volatile storage unit in the event of a power failure.

17. The storage device of claim 14, wherein each of the one or more segments comprises one to ten storage groups.

18. The storage device according to claim 14, wherein: The second volatile memory cell is a static random access memory (SRAM). The first volatile memory cell is a dynamic random access memory (DRAM); and The non-volatile storage unit is a NAND flash memory.

19. The storage device of claim 14, wherein the first volatile storage cell is a magnetoresistive random access memory (MRAM).

Images