Mirroring data in write caches of a controller of a non-volatile memory

Abstract

A data storage system provides persistent storage in bulk non-volatile memory. A controller of the data storage system receives a host write command and buffers associated host write data in both a first write cache in non-volatile memory and a mirrored second write cache in volatile memory. The controller destages the host write data to the bulk non-volatile memory from the second write cache but not the first write cache. The controller services relocation write commands requesting data relocation within the bulk non-volatile memory by reference to the second write cache. Servicing the relocation write commands includes buffering relocation write data in the second write cache but not the first write cache and destaging the relocation write data to the bulk non-volatile memory from the second write cache.

Description

[Technical Field]

[0001] This disclosure is generally related to data storage, and more particularly to non-volatile memory systems. More particularly, this disclosure relates to non-volatile memory systems including a mirror write cache that caches host write data in both volatile and non-volatile memory. [Previous Technology]

[0002] NAND flash memory is an electrically programmable and erasable non-volatile memory technology that stores one or more data bits of each memory cell as charges on a floating gate of a transistor or a similar charge trapping structure. In a typical implementation, a NAND flash memory array is organized in physical blocks of memory (also called "erase blocks"), each of which includes multiple physical pages, each of which contains multiple memory cells. By means of the configuration of word lines and bit lines used to access memory cells, flash memory arrays can typically be programmed on a page-by-page basis but erased on a block-by-block basis.

[0003] As known in the art, blocks of NAND flash memory must be erased before being programmed with new data. Blocks of NAND flash memory cells are erased by applying a high positive erase voltage pulse to the p-well body region of the selected block and biasing all word lines of the memory cell to be erased to ground. Applying the erase pulse promotes electron tunneling away from the floating gates of the memory cell biased to ground, so that these floating gates receive a net positive charge and thus cause the voltage threshold of the memory cell to transition toward the erased state. Each erase pulse is typically followed by an erase verification operation, which reads the erased block to determine whether the erase operation was successful, for example by verifying that fewer than a threshold number of memory cells in the erased block have not been successfully erased. Generally, erase pulses continue to be applied to the erased block until the erase verification operation is successful or until a predetermined number of erase pulses have been used (i.e., the erase pulse budget is exhausted).

[0004] NAND flash memory cells can be programmed by applying a positive high programming voltage to the word line of the memory cell to be programmed and applying an intermediate pass voltage to the memory cells in the same string to be suppressed from programming. Applying the programming voltage causes electrons to tunnel to the floating gate, changing its state from an initially erased state to a programmed state with a net negative charge. After programming, the programmed page is typically read in a read verification operation to ensure the programming operation was successful, for example by verifying that fewer than a threshold number of memory cells in the programmed page contain bit errors. Generally, programming and read verification operations are applied to the page until the read verification operation is successful or until a predetermined number of programming pulses have been used (i.e., the programming pulse budget is exhausted).

[0005] Data is written to NAND flash memory in the form of logical pages, each of which includes, for example, 4 kB or 16 kB of data. A given physical page of the memory can store one or more logical pages of data. As data is updated, logical pages storing outdated data become invalid, resulting in a physical block having a mixture of physical pages containing valid and invalid data. Finally, the NAND flash memory controller recovers the storage capacity consumed by the physical pages storing invalid data via a process called scrap collection. In scrap collection, the still valid data is rewritten from the first physical block to one or more previously erased physical blocks. The first physical block can then be erased in preparation for reprogramming.

[0006] In enterprise-class storage systems based on NAND flash memory, preventing data loss is crucial, for example, in the event of a power failure. Therefore, in such data storage systems, the flash memory controller can respond to a host write command only after the host write data associated with it has been persistently stored in non-volatile memory. In a first prior art design, the flash memory controller initially caches incoming host write data in a write cache implemented using a low-cost volatile memory technology, such as Dynamic Random Access Memory (DRAM). The flash memory controller then destages the host write data from the DRAM write cache to the NAND flash memory. Once all write data associated with the host write command is persistently stored in the NAND flash memory (and thus protected from data loss in the event of a power failure), the flash memory controller sends a response to the host, thereby releasing resources in the host allocated to track the completion of host write commands. Relocation writes, which combine garbage collection in NAND flash memory, are similarly cached in the DRAM write cache before being taken off-site and returned to NAND flash memory. This first architecture has the advantages of a simple and relatively low-cost design, but has the disadvantage of relatively poor write performance because the response to the host is delayed until the host writes the data and it is persistently stored in the NAND flash memory.

[0007] To provide improved write performance compared to the first prior art design, the second prior art design implements a non-volatile write cache, such as battery-supported DRAM, magnetoresistive RAM (MRAM), ferrite-resistive RAM (FRAM), phase-change memory (PCM), or other non-volatile memory technologies. With this design, write performance is significantly improved because once the associated host write data is written to the write cache, the flash memory controller can send a response to the host write command to the host before the host write data is completely off-stage from the non-volatile write cache to the NAND flash memory. Similarly, relocation writes combined with discarded item collection are first written to the non-volatile write cache before being off-stage to the NAND flash memory. This second prior art architecture offers significantly better write performance than the first prior art architecture, but it requires a trade-off of greater complexity and higher cost due to the price difference between implementing write caching in volatile memory (e.g., DRAM) and implementing write caching in non-volatile memory (e.g., MRAM).

[0008] In view of prior art, this application understands that it would be useful and desirable to provide an improved data storage system that implements a non-volatile write cache that allows response to host write commands before the associated host write data is taken off-platform to NAND flash memory, while also reducing the cost of memory used to implement the non-volatile write cache to achieve a given level of write performance. [Summary of the Invention]

[0009] In at least one embodiment, a method is provided for managing a data storage system that provides persistent storage in mass non-volatile memory. The controller of the data storage system receives a host write command and caches the associated host write data in both a first write cache in the non-volatile memory and a mirrored second write cache in the volatile memory. The controller offloads the host write data from the second write cache, but not the first write cache, to the mass non-volatile memory. The controller serves a relocation write command requesting the relocation of data within the mass non-volatile memory by referring to the second write cache. Serving the relocation write command includes caching the relocation write data in the second write cache, but not the first write cache, and offloading the relocation write data from the second write cache to the mass non-volatile memory.

[0010] In at least one embodiment, a data storage system includes a controller for mass non-volatile memory. The controller is configured to receive host write commands and cache associated host write data in both a first write cache in the non-volatile memory and a mirrored second write cache in the volatile memory. The controller offloads the host write data from the second write cache, but not the first write cache, to the mass non-volatile memory. The controller servicing a relocation write command requesting the relocation of data within the mass non-volatile memory by referring to the second write cache. Servicing the relocation write command includes caching the relocation write data in the second write cache, but not the first write cache, and offloading the relocation write data from the second write cache to the mass non-volatile memory.

[0011] In at least one embodiment, a program product includes a storage device and program code stored in the storage device, the program code being executable by a controller of mass non-volatile memory. Upon execution, the program code causes the controller to receive a host write command and cache associated host write data in both a first write cache in the non-volatile memory and a mirrored second write cache in the volatile memory. The controller offloads the host write data from the second write cache, but not the first write cache, to the mass non-volatile memory. The controller servicing a relocation write command requesting relocation of data within the mass non-volatile memory by referring to the second write cache. Servicing the relocation write command includes caching the relocation write data in the second write cache, but not the first write cache, and offloading the relocation write data from the second write cache to the mass non-volatile memory.

[0012] In at least one embodiment, before completing the offstage writing of host data to mass non-volatile memory, the controller sends a response to the host write command to the host based on the host write data being cached in a first write cache.

[0013] In at least one embodiment, the high-capacity non-volatile memory includes flash memory, and the controller generates at least some of the relocation write commands during the collection of discarded items in the flash memory.

[0014] In at least one embodiment, the controller releases the host write data of the host write command in the first write cache based on the completion of the host write data offstage to mass non-volatile memory.

[0015] In at least one embodiment, the controller records host write data at at least one first location in the first write cache in an entry of the logic-to-entity translated data structure. Based on the off-stage host write data to mass non-volatile memory, the controller updates the entry to indicate a different second location in the mass non-volatile memory.

[0016] In at least one embodiment, the controller further records the host write data at a third location in the second write cache in an entry of the logic-to-entity translated data structure.

[0017] In at least one embodiment, the high-capacity non-volatile memory includes a first write cache.

[0018] In at least one embodiment, the controller maintains a plurality of buffers in the first write cache and the second write cache, each corresponding to one of the plurality of different write hots.

Implementation Method

[0029] Referring to the figures, and specifically to Figure 1A, a high-level block diagram of an exemplary data processing environment 100 is shown, which includes a data storage system 120 with a mirrored write cache, as further described herein. As shown, the data processing environment 100 includes one or more hosts, such as a processor system 102 having one or more processors 104 for processing instructions and data. The processor system 102 may additionally include local storage 106 (e.g., DRAM or a disk) for storing program code, operands, and / or execution results of processing performed by the processor 104. In various embodiments, the processor system 102 may be, for example, a mobile computing device (such as a smartphone or tablet), a laptop or desktop personal computer system, a server computer system (such as one of the POWER® series available from IBM), or a mainframe computer system. The processor system 102 may also be an embedded processor system using various processors such as ARM®, POWER, Intel x86, or any other processor combined with memory cache, memory controller, local storage, I / O bus, etc.

[0030] Each processor system 102 further includes an input / output (I / O) adapter 108 that is directly coupled (i.e., without any intervening device) or indirectly coupled (i.e., via at least one intermediate device) to the data storage system 120 via I / O channel 110. In various embodiments, I / O channel 110 may use any or a combination of known or future-developed communication protocols, including, for example, Fibre Channel (FC), Ethernet FC (FCoE), Internet Small Computer System Interface (iSCSI), InfiniBand, Transmission Control Protocol / Internet Protocol (TCP / IP), Peripheral Component Rapid Interconnect (PCIe), High-Speed ​​Non-Volatile Memory (NVMe), Mesh NVMe (NVMe over Fabrics; NVMe-oF), etc. The I / O commands transmitted via I / O channel 110 include host read commands by which processor system 102 requests data from data storage system 120, and host write commands by which processor system 102 requests data to be stored in data storage system 120.

[0031] In the illustrated embodiment, the data storage system 120 includes a plurality of interface nodes 122 through which the data storage system 120 receives and responds to I / O commands via I / O channels 110. Each interface node 122 is coupled to each of a plurality of redundant array of low-cost disks (RAID) controllers 124 to facilitate fault tolerance and load balancing. Each of the RAID controllers 124 is further coupled (e.g., via a PCIe bus) to each of a plurality of flash cards 126, in this example including NAND flash memory storage media. In other embodiments, other lossy storage media may be used.

[0032] FIG1B depicts a more detailed block diagram of the flash card 126 of the data storage system 120 of FIG1A according to a first embodiment. In this embodiment, the flash card 126 includes a gateway 130 that acts as an interface between the flash card 126 and the RAID controller 124. The gateway 130 is coupled to a general-purpose processor (GPP) 132, which can be configured (e.g., by code) to perform various management functions, such as preprocessing I / O commands received by the gateway 130, scheduling the flash card 126 to service I / O commands, and / or performing other management functions. The GPP 132 is coupled to a GPP memory 134 (e.g., DRAM), which can conveniently cache data created, referenced, and / or modified by the GPP 132 during its processing.

[0033] The gate 130 is further coupled to at least one flash memory controller 140, which controls a high-capacity non-volatile memory system, such as a NAND flash memory system 150. The flash memory controller (FC) 140 serves I / O commands, such as reading requested data from or writing requested data to the NAND flash memory system 150 by accessing the NAND flash memory system 150, as further discussed below. In various embodiments, the flash memory controller 140 may be implemented, for example, by an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). In embodiments where the flash memory controller 140 is implemented by an FPGA, the GPP 132 may program and configure the flash memory controller 140 during startup of the data storage system 120.

[0034] The flash memory controller 140 is coupled to a flash memory controller memory, which in this embodiment includes both a flash memory controller non-volatile memory 142 and a flash memory controller volatile memory 144. The flash memory controller non-volatile memory 142 may be implemented, for example, by MRAM, FRAM, PCM, battery-supported DRAM, or other non-volatile memory technologies, and the flash memory controller volatile memory 144 may be implemented by a relatively inexpensive volatile memory technology such as DRAM. As further indicated in FIG1B, the flash memory controller non-volatile memory 142 includes a first host write cache 146a for caching host write data associated with host write commands received from a host, such as processor system 102. The contents of host write cache 146a are mirrored by flash memory controller 140 into a second host write cache 146b implemented in flash memory controller volatile memory 144. As will be understood by those skilled in this art upon reading this specification, host write caches 146a and 146b can be further attached to the same memory bus so that mirrored data can be written to both write caches 146a and 146b using a single command.

[0035] The flash memory controller 140 implements a flash memory translation layer (FTL) that provides logic-to-physical address translation to enable access to specific memory locations within the NAND flash memory system 150. Generally, I / O commands received by the flash memory controller 140 from a host device (such as processor system 102) contain the logical block address (LBA) of the data to be accessed (read or write), and if it is a host write command, the host write data is to be written to the data storage system 120. The I / O command may also specify the amount (or size) of the data to be accessed. Depending on the protocols and features supported by the data storage system 120, other information may also be conveyed. As is known to those skilled in the art, in some implementations of NAND flash memory, the smallest data granularity that can be accessed by a host read or host write command is fixed at the size of a single physical page, such as 16 kilobits (KB). The LBA provided by the host device corresponds to a logical page within the logical address space, which may have a size of, for example, 4 kB or 16 kB. This logical page can be further compressed by the flash memory controller 140 so that each physical page can store one or more logical pages. The FTL translates the LBA into a physical address assigned to the corresponding physical location in the NAND flash memory system 150. The flash memory controller 140 can store the mapping between logical addresses and physical addresses in a logic-to-physical translation data structure, such as a logic-to-physical translation (LPT) table 152, which can be conveniently stored in the flash memory controller volatile memory 144.

[0036] As further shown in FIG1B, in the depicted embodiment, the flash memory controller volatile memory 144 further includes a relocation write buffer 148 to be relocated within the NAND flash memory system 150, which caches data collected by a discarded item collection procedure. Additionally, the flash memory controller volatile memory 144 may include a read cache 156, which caches data from the NAND flash memory system 150 that has recently been and / or frequently requested by host read commands. The flash memory controller 140 may also store threshold voltage (Vth) shift data 154 in the flash memory controller volatile memory 144. This shift data is used to calibrate the read threshold voltage of various subsets (e.g., page groups) of the NAND flash memory system 150, as well as other management data structures 158 that store management data such as bit error rate (BER) and other statistics, programmable / erase (P / E) cycle counters, log entry information, etc.

[0037] In various embodiments, the NAND flash memory system 150 may take many forms. Referring now to Figures 2 to 5, an exemplary configuration of physical memory within a NAND flash memory system 150 according to one embodiment is depicted.

[0038] As shown in Figure 2, the NAND flash memory system 150 may be formed from forty (40) individually addressable NAND flash memory storage devices. In the illustrated example, each of the flash memory storage devices M0a to M19b is in the form of a board-mounted flash memory module capable of storing two or more bits per cell. In a particular embodiment, the memory module is implemented by a four-level cell (QLC) NAND flash memory configured to operate in a hybrid layered configuration, which includes a first set of physical blocks operating in QLC mode and a second set of physical blocks operating in single-level cell (SLC) mode. The forty NAND flash memory modules are configured into twenty groups of two modules: (M0a, M0b) to (M19a, M19b). For the purpose of physical addressing scheme, each group of the two modules forms a "simplex channel" (sometimes also called a "channel"), so that the NAND flash memory system 150 includes twenty channels or simplex channels (Lane0 to Lane19).

[0039] In a preferred embodiment, each of the individual simplex channels has a separate associated bus that couples it to the associated flash memory controller 140. Therefore, by directing its communication to one of the specific communication buses, the flash memory controller 140 can direct its communication to one of the simplex channels of the memory module. Because each communication bus for a given simplex channel is independent of the communication buses for other simplex channels, the flash memory controller 140 can simultaneously issue commands and send or receive data across various communication buses, thereby enabling the flash memory controller 140 to access the flash memory module corresponding to the individual simplex channel simultaneously or nearly simultaneously.

[0040] Referring now to FIG3, an exemplary embodiment of a flash memory module 300 that can be used to implement any of the flash memory modules M0a to M19b of FIG2 is shown. As shown in FIG3, the physical storage location provided by the flash memory module 300 is further subdivided into physical locations that can be addressed and / or identified via die enable (CE). In the example of FIG3, the physical memory of each flash memory die 300 is divided into four die enable (CE0, CE1, CE2 and CE3), each die enable having a separate CE line verified by the flash memory controller 140 to enable access to or from the physical memory location within the corresponding CE. Each CE is further divided into multiple dies (e.g., Die0 and Die1) each having two or four planes (e.g., Plane0 and Plane1). Each plane represents a collection of physical blocks, which are physically associated with each other and utilize a common circuit system (e.g., I / O buffers) to perform various operations (such as read and write operations) due to the physical layout of the flash memory chip.

[0041] As further illustrated in Figures 4 and 5, an exemplary plane 400, which can be used to implement any of the planes within the flash memory module 300 of Figure 3, includes, for example, 512, 2048, or 4096 blocks of physical memory. Some manufacturers include additional blocks in this nominal block count because some blocks may fail prematurely due to manufacturing defects. Generally, a block is a collection of physical pages that are typically associated with each other in a physical manner. This association makes a block defined as the smallest granularity of physical storage location that can be erased within the NAND flash memory system 150. In the embodiment of Figure 5, each block 500 includes hundreds or thousands of pages, such as 512, 1024, or 4096 physical pages, where a physical page is defined as the smallest individually addressable unit of data for read and write access. In the exemplary system, each physical page of data has a common capacity for data storage (e.g., 16 kB) plus additional storage space for data following the page. Therefore, data is typically written to or read from the NAND flash memory system 150 on a page-by-page basis, but erased on a block-by-block basis.

[0042] Because the FTL implemented by the data storage system 120 isolates the logical address space available to the host device from the physical memory within the NAND flash memory system 150, the size of the NAND flash memory system 150 does not need to be equal to the size of the logical address space presented to the host device. In most embodiments, it is beneficial to present a logical address space smaller than the total available physical memory (i.e., it is beneficial to over-deploy the NAND flash memory system 150). Over-deployment in this manner ensures that physical memory resources are available even when a certain amount of invalid data as described above exists, while fully utilizing the logical address space. In addition to invalid data that has not yet been reclaimed, the over-deployed space can be used to ensure sufficient logical space is available even in the event of memory failures and additional memory loads caused by the use of data protection schemes (such as error correction codes (ECC), cyclic redundancy checks (CRC), and parity checks).

[0043] In some embodiments, data is written to the NAND flash memory system 150 one physical page at a time. In other embodiments requiring more robust error recovery, data is written to a group of associated physical pages of the NAND flash memory system 150, referred herein as a "page-equivalent disk area". In one embodiment, all pages of a page-equivalent disk area are associated with different simplex channels to achieve high write bandwidth. Because in many embodiments the smallest erase unit is a block, multiple page-equivalent disks can be grouped into block-equivalent disk areas 600, as shown in FIG. 6A, where each block in a block-equivalent disk area is associated with a different simplex channel. When constructing a block-equivalent disk area, any free block of a simplex channel can be selected, but preferably, all blocks within the same block-equivalent disk area have the same or similar health level. Note that block selection can be further limited to those from the same plane, die, and / or wafer enablement. The length of the block-equal disk area can vary, but in one embodiment of the NAND flash memory system 150 that includes 20 simplex channels, each block-equal disk area includes two to twenty blocks, each block coming from a different simplex channel.

[0044] Once a block has been selected from each simplex channel and a block-equal disk area has been formed, the page-equal disk area is preferably formed from physical pages with the same page number from all blocks in the block-equal disk area. Although the lengths of the various page-equal disk areas stored in the NAND flash memory system 150 can vary, in one embodiment, each page-equal disk area includes one to twenty data pages (typically provided by the host device) for writing data. In another embodiment, the page-equal disk area includes one to nineteen data pages for writing data and an additional page ("data protection page") for storing data protection information for writing data. For example, FIG6B illustrates an exemplary page-equal disk area 610 including N data pages (i.e., Dpage00 to DpageN-1) and one data protection page (i.e., PpageN). Data protection pages can be placed on any simplex channel containing page-equal partitions that are not retired pages, but they are typically placed on the same simplex channel for all page-equal partitions of the same block size to minimize post-processing data. As shown, adding a data protection page requires simultaneous scrap collection for all page-equal partitions of the same block size. After scrap collection of the block size is complete, the block size can be fragmented, and each block can be placed in the relevant Ready-to-Use (RTU) queue, as explained below.

[0045] Having described the general physical structure and operation of an exemplary embodiment of the data storage system 120, some operational states of the data storage system 120 are now described with reference to FIG7, which is a high-level data flow diagram illustrating the flash memory management functions and data structure used by GPP132 and / or flash memory controller 140 according to one embodiment.

[0046] As mentioned above, the data storage system 120 typically does not allow external devices (e.g., a host) to directly address and / or access the physical memory locations within the NAND flash memory system 150. In fact, the data storage system 120 is typically configured to present one or more logical volumes to the host device. These logical volumes each have a contiguous logical address space, thus allowing the host device to read data from and write data to logical block addresses (LBAs) within the logical address space. Simultaneously, it allows one or more controllers at various levels (e.g., RAID controller 124, flash memory controller 140, and GPP 132) to control where the data associated with the various LBAs actually resides within the physical memory locations of the NAND flash memory system 150. In this way, the performance and lifespan of the NAND flash memory system 150 can be intelligently managed and optimized. In the illustrated embodiment, each flash memory controller 140 performs logic-to-entity address translation (LPT) on the associated set of LBAs using a logic-to-entity address translation data structure, such as a logic-to-entity translation (LPT) table 152. This translated data structure can be stored in the associated flash memory controller volatile memory 144. It should be noted that the logical addresses supplied to the flash memory controller 140 may differ from the logical addresses initially supplied to the data storage system 120, because various components within the data storage system 120 can perform address translation operations between external devices and the flash memory controller 140.

[0047] As will be understood, implementing a mirrored host write cache 146b in the flash memory controller volatile memory 144 reduces the available capacity in the flash memory controller volatile memory 144 for other post-processor data such as LPT 152. In at least some embodiments, the space occupied by LPT 152 in the flash memory controller volatile memory 144 can be reduced by implementing a paging mechanism in the flash memory controller 140. In these embodiments, a backup storage for LPT entries is maintained in the NAND flash memory system 150, and the flash memory controller 140 pages LPT entries to the backup storage and to the backup storage as needed.

[0048] Flash memory management code running on GPP132 tracks erased blocks in the NAND flash memory system 150 that are ready for use (RTU) queues 700, which may be stored, for example, in GPP memory 134. In the depicted embodiment, the flash memory management code running on GPP132 preferably maintains one or more RTU queues 700 per plane or channel, and the identifier of each erased block to be reused is queued into one of the RTU queues 700 corresponding to its channel. For example, in one embodiment, for each channel, the RTU queues 700 include separate RTU queues 700 for each of a plurality of block health levels. In various implementations, it has been found that 2 to 8 RTU queues 700 per plane (and the corresponding number of block health levels) are sufficient.

[0049] The block-equals disk area construction function 702 (e.g., executed by flash memory management code running on GPP132) constructs new block-equals disk areas from erased blocks queued in RTU queues 700. As mentioned above with reference to Figure 6A, the block-equals disk area is preferably formed from blocks residing in different channels with the same or similar health status (i.e., expected remaining lifespan). This means that the block-equals disk area can be conveniently constructed by extracting each block of the new block-equals disk area from the corresponding RTU queues 700 of different planes or channels using the block-equals disk area construction function 702. The new block-equals disk area is then queued in the flash memory controller 140 for data placement by the data placement function 704.

[0050] The data placement function 704 includes an open block queue 706 that tracks identifiers of incompletely programmed blocks in the block-equal-size disk area constructed by the block-equal-size disk area construction function 702. As further shown in FIG7, the data placement function 704 also includes a cache engine 714 for writing host write data to the mirror host write cache 146a, 146b and for writing reposition write data to the reposition write buffer 148. The data placement function 704 also includes an off-line engine 716 for writing data from the host write cache 146b and the reposition write buffer 148 to the open blocks of the NAND flash memory system 150 identified in the open block queue 706.

[0051] In response to a host write command received from a host such as processor system 102, the data placement function 704 of flash memory controller 140 determines, by referring to LPT table 152, whether the target LBA indicated in the host write command is currently mapped to a physical page in NAND flash memory system 150, and if so, changes the state of each data page currently associated with the target LBA to indicate that it is no longer valid. Cache engine 714 also writes the host write data of the host write command to both host write caches 146a and 146b, preferably using a single operation in parallel (e.g., the host write data only traverses the memory bus once). Once the update of host write cache 146a is complete, cache engine 714 can immediately provide an acknowledgment message ("Ack") to the publishing host via I / O channel 110. The cache engine 714 also updates the entries in LPT704 used for LBAs indicated by host write commands to point to the location of host write data in host write cache 146a and / or host write cache 146b.

[0052] To serve host write commands, the data placement function 704 additionally allocates page-equal disk space as necessary to store the write data of the host write command and any outdated data from the existing page-equal disk space (if it exists) of the target of the host write command (i.e., if the write request is smaller than a logical page, there is still valid data that needs to be processed in a read-modify-write manner), and / or stores the write data of the host write command and any outdated (i.e., still valid) data from the existing page-equal disk space (if it exists) of the target of the host write command to the allocated page-equal disk space with remaining free space. Page-equal disk space can be allocated from a block-equal disk space itself to store data or from a new block-equal disk space. In a preferred embodiment, page-equal disk space allocation can be based on the health of the blocks available for allocation and the "hotness" (i.e., the estimated or measured write access frequency) of the LBA of the write data. The off-site engine 716 of the data placement function 704 then writes the host write data and associated post-processing data (e.g., CRC and ECC values) to a page in the allocated page-equal disk area identified in the open block queue 706 for each codeword from the host write cache 146b, and additionally writes parity information to the data protection page of the allocated page-equal disk area as needed. The off-site engine 716 also updates the LPT table 152 to associate the LBA of the host write data with the address of the physical page in the NAND flash memory 150 used to store the write data. Thereafter, the flash memory controller 140 can access the data from the NAND flash memory 150 by referring to the LPT table 152 to serve host read commands.

[0053] Once all pages in a block-equal disk area have been written or the block-equal disk area has been otherwise closed, the flash memory controller 140 places an identifier for the block-equal disk area on one of the occupied block queues 708. The flash memory management code running on GPP 132 uses this identifier to track the block for scrap collection and other management functions. As mentioned above, the pages are invalidated by the write process, and therefore a portion of the NAND flash memory system 150 becomes unused. The associated flash memory controller 140 (and / or GPP 132) ultimately needs to reclaim this space through scrap collection performed by scrap collector 720. The scrap collector 720 selects a specific block-equal disk area for scrap collection based on several factors, including, for example, the health status of the physical blocks within the block-equal disk area and how much invalid data is contained within the physical blocks. In at least one embodiment, discarded item collection is performed on an entire block-equal disk area, and the discarded item collector 720 issues a relocation write command to the cache engine 714 of the data placement function 704 to relocate the still valid data in the discarded item collection block-equal disk area to another block-equal disk area. In a NAND flash memory system 150 implementing a hybrid tiered configuration, which includes a first set of physical blocks operating in a higher storage density mode (e.g., QLC mode) and a second set of physical blocks operating in a lower storage density mode (e.g., SLC mode), it is necessary to allow discarded item collection data to be written from an old block operating in either mode to a new block operating in either mode. Therefore, the relocation write command issued by the discarded item collector 720 can specify the desired operating mode of the target block-equal disk area to support, for example, QLC to QLC, SLC to QLC, SLC to SLC, or QLC to SLC discarded item collection.

[0054] As further indicated in Figure 7, the flash memory management function performed by GPP132 and / or flash memory controller 140 further includes: a loss equalizer 722, which requests the relocation of data stored in an equivalent amount of disk space in the occupied block queue 708 to balance the loss across blocks; and a cluster equalizer 724, which requests the relocation of data stored in certain equivalent amounts of disk space to allow reconfiguration to constitute some or all of the data in the block, thereby operating in different operating modes (e.g., QLC or SLC).

[0055] Based on the relocation write command received by the self-abandoned item collector 720, wear equalizer 722, and cluster balancer 724, the cache engine 714 stores the relocation write data from the old block equivalent disk area into the relocation write buffer 148 in the flash memory controller volatile memory 144. Furthermore, the cache engine 714 can update the LPT table 152 to point to a different location in the relocation write buffer 148. Once all still valid data has been moved from the old block equivalent disk area and written to a new page in the allocated page equivalent disk area identified in the open block queue 706, the off-stage engine 716 updates the LPT table 152 to remove the current association between the logical address and physical address of the data, and associates the LBA of the relocated data with the address of the physical page in the NAND flash memory 150 used to store the relocated data. Next, the old block-equal disk area is decomposed, thus deassociating the block and reordering the block identifier into the erase queue 710, which may include one erase queue 710 per channel. The block erase function 712 of the flash memory controller 140 then erases each of the blocks that were previously formed into the decomposed block-equal disk area and increments the associated programmed / erase (P / E) cycle count of that block in the management data structure 158. Based on the health metric of each erased block, each erased block is retired (i.e., no longer used to store user data) or alternatively prepared for reuse by placing the block identifier in the appropriate ready-to-use (RTU) queue 700 in the associated GPP memory 134.

[0056] Referring now to FIG8, a high-level logic flowchart is depicted according to an embodiment of an exemplary method by which a controller serves host write commands in a non-volatile memory system. The illustrated program may be executed, for example, during operation of the data storage system 120 by a controller (e.g., GPP 132 and / or flash memory controller 140) in hardware, firmware, software, or a combination thereof. Unless otherwise specifically stated, the operations are presented in a logical order rather than a strict chronological order, and in some embodiments, the operations may be performed in a different order than presented or simultaneously.

[0057] The program in Figure 8 begins at block 800 and continues to block 802, which describes the controller monitoring the receipt of host write commands from a host, such as processor system 102. The host write command includes or has an associated LBA to be written and host write data. In response to detecting a host write command, the controller invalidates the LBA entry (if present) in LPT 152. The program continues, preferably in parallel, from block 804 to blocks 806 and 808. Block 806 describes the controller caching the host write data in the host write cache 146a in the non-volatile memory 142 of the flash memory controller. Block 808 depicts the controller further mirroring the host write data in the host write cache 146b in the volatile memory 144 of the flash memory controller.

[0058] The minimum size of the host write cache 146a and 146b required for caching host data increases with the internal parallelism, the number of supported write streams, the supported write bandwidth, and the average write latency. For a controller with a given write bandwidth and latency characteristics, the minimum size can be calculated based on the physical page size, the number of simplex channels and planes, the maximum number of unprocessed page equivalent disk areas, and the number of supported write streams and segments. For example, for a NAND flash memory system 150 implementing 16 kB pages, 20 simplex channels (where 4 planes are divided into one equivalent disk area), and 4 unprocessed word lines (i.e., 16 page equivalent disk areas), the minimum size of the host write cache 146a and 146b can be determined as 16 kB × 20 × 4 × 16 = 20 MB / stream / segment.

[0059] Referring to Figure 9, an exemplary data structure according to one embodiment is shown, wherein the controller supports separating host write data and redistribution write data into different write streams and separating read activity within each write stream. In this exemplary embodiment, the flash memory controller 140 implements one write stream for host write data and two write streams for redistribution write data. Each write stream includes five write segments, including one write segment for SLC data and four write segments for QLC data. The four write segments for QLC data include separate segments for each QLC page type, namely, bottom page (LP), top page (UP), extra page (XP), and top page (TP). The flash memory controller 140 directs data to various QLC write segments based on relative read hotness. For example, the coldest QLC write data is cached in the QLC TP buffer, the next hotter QLC write data is cached in the QLC XP buffer, the next hotter QLC write data is cached in the QLC UP buffer, and the hottest QLC write data is cached in the QLC LP buffer. Although the implementation of various hotness segments increases the minimum size of the host write caches 146a and 146b, reducing the number of write streams and / or hotness segments to reduce the space occupied by the host write caches 146a and 146b is not preferable, because the overall write amplification will increase or the read hotness separation efficiency will be significantly reduced.

[0060] Returning to block 806 of Figure 8, the host write data based on the host write command is cached in the host write cache 146a. The controller sends a response to the host write command to the originating host via I / O channel 110 (block 810). As mentioned above, the response message indicates persistent storage of the host write data, and therefore the resources allocated to the host write command can be released for reuse. The procedure in Figure 8 continues from blocks 810 and 808 and rejoins at block 812, which depicts the controller updating the LBA entry in LPT 152 for the host write command to indicate the location of the host write data in one or both of the write caches 146a and 146b. As a result, in at least some embodiments, the controller can begin servicing host read commands that request host write data from the write cache 146b.

[0061] At block 814, based on the assignment of data to the buffer in the host write cache 146b, the controller initiates offloading the host write data from write cache 146b (but not from write cache 146a) to the NAND flash memory system 150. By avoiding offloading the host write data from write cache 146a, access to the flash memory controller's non-volatile memory 142 is normally limited to a single write per host write command. In a preferred embodiment, the offloading of host write data is performed in the "background," and the controller is not busy serving other host I / O commands or performing other management functions. The controller monitors the completion of the offloading of host write data from write cache 146b to the NAND flash memory system 150 (block 816). In response to the detection of off-site completion of host write data, the controller may release (invalidate) the copy of the host write data residing in host write cache 146a, since the host write data is persistently stored in NAND flash memory system 150 (block 818). It should be noted that a copy of the host write data may be retained in host write cache 146b for future host reads. This is advantageous, for example, when the size of host write cache 146b is larger than the size of host write cache 146a. Alternatively, the host write data in host write cache 146b may also be released simultaneously with the copy in host write cache 146a. The decision to release or retain the host write data in host write cache 146b may depend on, for example, the implemented caching strategy, the likelihood of future reads of the host write data, and / or the available size of host write cache 146b. The procedure in Figure 8 then terminates at block 820.

[0062] Although not explicitly shown in Figure 8, those skilled in the art will understand that power failure on the flash card 126 or data storage system 120 during a host write command operation will prevent data loss. In that case, the host write data can be recovered by the host from the host queue or by the controller from a persistent copy cached in the write cache 146a. However, in the absence of a power failure during normal operation, the disclosed procedure includes the following four internal data movements within the flash card 126: 1. A write to the non-volatile write cache 146a; 2. A write to the mirrored volatile write cache 146b; 3. A read from the mirrored volatile write cache 146b; and 4. A write to the NAND flash memory system 150. As will be understood, compared to previous technical solutions, limiting access to the non-volatile write cache 146a to one write access per host write command significantly reduces the bandwidth required by the non-volatile write cache 146a, and thus reduces the minimum required size (and cost) of the non-volatile write cache 146a. Alternatively, the space saved in the non-volatile write cache can also be used to increase the number of write streams and thus improve thermal separation.

[0063] Referring now to FIG10, a high-level logic flowchart is depicted according to an exemplary method of one embodiment by which a controller serves a relocation write command in a non-volatile memory system. The illustrated program may be executed, for example, during operation of the data storage system 120 by a controller (e.g., GPP 132 and / or flash memory controller 140) in hardware, firmware, software, or a combination thereof. Likewise, the operations are presented in a logical order rather than a strict chronological order, and in some embodiments, the operations may be performed in a different order than presented or simultaneously.

[0064] The procedure in Figure 10 begins at block 1000 and continues to block 1002, which illustrates that the controller monitors the receipt of relocation write commands, such as from the discarded item collector 720, wear equalizer 722, or cluster balancer 724. The relocation write command specifies one or more physical blocks (e.g., block-equal disk areas) in NAND flash memory 150 from which relocation write data is to be relocated. In response to the detection of a relocation write command, the controller reads one or more still valid data pages (referred to herein as "relocation write data") from NAND flash memory 150 at block 1004 into the relocation write buffer 148 in the flash memory controller's volatile memory 144 (block 1004). It should be noted that the controller avoids caching any of the relocation write data in the flash memory controller's non-volatile memory 142.

[0065] At block 1006, the controller initiates the offloading of relocation write data from relocation write buffer 148 to a block-equal disk area in the NAND flash memory system 150 identified in open block queue 706. In a preferred embodiment, the offloading of relocation write data is performed in the "background," and the controller is not busy serving other host I / O commands or performing other management functions. The controller monitors the completion of the offloading of relocation write data from relocation write buffer 148 to NAND flash memory system 150 (block 1008). In response to detecting the completion of the offloading of relocation write data, the controller checks whether all still valid pages have been relocated from the block or block-equal disk area to be relocated (block 1010). If there are more pages to be relocated, the controller returns to block 1004 to read the next one or more still valid pages, as described above. When no valid pages remain, the controller queues the identifier of the source block from which the relocation write data is read into the erase queue 710, and may release (invalidate) the copy of the relocation write data residing in the relocation write buffer 148 (block 1012). At block 1012, the controller further updates the relevant entries in LPT 152 to point to the new storage location in NAND flash memory 150. The process in Figure 10 then terminates at block 1014.

[0066] Under normal operating conditions (i.e., without power failure), the disclosed procedure for handling relocation write commands includes the following four internal data movements within flash card 126: 1. A read from NAND flash memory system 150; 2. A write to the relocation write buffer 148 in flash memory controller volatile memory 144; 3. A read from relocation write buffer 148; and 4. A write to NAND flash memory system 150. As will be understood, compared to prior art solutions, eliminating any access to the non-volatile write cache 146a when servicing relocation write commands significantly reduces the bandwidth required for the non-volatile write cache 146a, and thus reduces the minimum required size (and cost) of the non-volatile write cache 146a. Alternatively, the space saved in the non-volatile write cache can also be used to increase the number of write streams and thus improve thermal separation.

[0067] Referring now to FIG11, a block diagram of an exemplary flash card of the data storage system of FIG1A according to a second embodiment is shown. As indicated by similar reference numerals, the flash card 126' shown includes mirrored host write caches 146a, 146b as previously described with respect to FIG8 and FIG10. However, the flash card 126' omits the separate flash memory controller non-volatile memory 142, and instead implements the host write cache 146a in a mass non-volatile memory within the NAND flash memory system 150. Due to the omission of the flash memory controller non-volatile memory, this second embodiment can be implemented at a lower cost, but generally exhibits lower write performance due to the longer write latency to the NAND flash memory system 150. This longer write latency can be partially improved by exclusively implementing host write cache 146a in a faster SLC storage layer (i.e., QLC blocks configured to operate in SLC mode or in dedicated SLC flash memory).

[0068] As described, in at least one embodiment, a data storage system provides persistent storage in mass non-volatile memory. The controller of the data storage system receives a host write command and caches the associated host write data in both a first write cache in the non-volatile memory and a mirrored second write cache in the volatile memory. The controller offloads the host write data from the second write cache, but not the first write cache, to the mass non-volatile memory. The controller servicing a relocation write command requesting the relocation of data within the mass non-volatile memory by referring to the second write cache. Servicing the relocation write command includes caching the relocation write data in the second write cache, but not the first write cache, and offloading the relocation write data from the second write cache to the mass non-volatile memory.

[0069] In at least one embodiment, before completing the offstage writing of host data to mass non-volatile memory, the controller sends a response to the host write command to the host based on the host write data being cached in a first write cache.

[0070] In at least one embodiment, the high-capacity non-volatile memory includes flash memory, and the controller generates at least some of the relocation write commands during the collection of discarded items in the flash memory.

[0071] In at least one embodiment, the controller releases the host write data of the host write command in the first write cache based on the completion of taking the host write data offstage to mass non-volatile memory.

[0072] In at least one embodiment, the controller records host write data at at least one first location in the first write cache in an entry of the logic-to-entity translated data structure. Based on the off-stage host write data to mass non-volatile memory, the controller updates the entry to indicate a different second location in the mass non-volatile memory.

[0073] In at least one embodiment, the controller further records the host write data at a third location in the second write cache in an entry of the logic-to-entity translated data structure.

[0074] In at least one embodiment, the high-capacity non-volatile memory includes a first write cache.

[0075] In at least one embodiment, the controller maintains a plurality of buffers in the first write cache and the second write cache, each corresponding to one of the plurality of different write hots.

[0076] By reducing the bandwidth requirements for the non-volatile write cache to a single write per host write command under normal conditions, the disclosed embodiments improve the design trade-off between the size of the flash memory controller's non-volatile memory and its contribution to the cost of the data storage system. Specifically, in some embodiments, the disclosed embodiments enable the maintenance of a given number of write streams and sufficient write bandwidth while reducing the size of the non-volatile write cache (and thus reducing cost). Alternatively, in other embodiments, additional write streams that produce greater performance can be implemented at the same cost using a given size of non-volatile write cache. In still other embodiments, some cost reductions can be achieved by implementing a larger number of write streams with the same total write bandwidth.

[0077] The present invention may be a system, a method, and / or a computer program product. The computer program product may include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon to cause a processor to execute the present invention.

[0078] A computer-readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punch cards or raised structures in recesses on which instructions are recorded), and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as temporary signals, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating via waveguides or other transmission media (e.g., light pulses transmitted via fiber optic cables), or electrical signals transmitted via wires.

[0079] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to individual computing / processing devices or via a network (e.g., the Internet, local area network, wide area network, and / or wireless network) to an external computer or external storage device. The network may include copper transmission cables, optical fiber transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter or network interface in each computing / processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for use in computer-readable storage media stored within the individual computing / processing device.

[0080] The computer-readable program instructions used to perform the operations of this invention may be compiler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or similar languages, and conventional procedural programming languages ​​such as "C" or similar languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuit systems, including, for example, programmable logic circuit systems, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), can execute computer-readable program instructions by personalizing the electronic circuit system with state information of computer-readable program instructions in order to perform the present invention.

[0081] The present invention is described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0082] Such computer-readable program instructions may be provided to the processor of a general-purpose computer, special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, create means for performing the functions / actions specified in one or more flowchart and / or block diagram blocks. Such computer-readable program instructions may also be stored in a computer-readable storage medium, which instructs a computer, programmable data processing device, and / or other apparatus to function in a particular manner, such that the computer-readable storage medium storing the instructions includes an article of writing comprising instructions for performing the functions / actions specified in one or more flowchart and / or block diagram blocks.

[0083] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing equipment or other device to cause a series of operational steps to be executed on the computer, other programmable equipment or other device to produce a computer-implemented program, such that the instructions executed on the computer, other programmable equipment or other device perform the functions / actions specified in one or more flowchart and / or block diagram blocks.

[0084] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions mentioned in a block may not occur in the order mentioned in the figures. For example, depending on the functionality involved, two blocks shown consecutively may actually be executed substantially simultaneously, or such blocks may sometimes be executed in reverse order. It will also be noted that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0085] Although the invention has been specifically illustrated and described with reference to one or more preferred embodiments, those skilled in the art will understand that various changes in form and detail may be made in the invention without departing from the spirit and scope of the appended claims. For example, although a data storage system including a flash memory controller that directs certain functions has been described, it should be understood that the invention may alternatively be implemented as a program product including a storage device that stores program code that can be processed by a processor to perform or cause to perform such functions. As used herein, "storage device" is specifically defined to include only legal articles and excludes the transmission medium itself, the transient propagation signal itself, and the form of energy itself.

[0086] Furthermore, although embodiments including the use of NAND flash memory have been described, it should be understood that embodiments of the present invention can also be used with other types of non-volatile random access memory (NVRAM), including, for example, phase change memory (PCM) and combinations thereof.

[0087] The figures described above and the written description of the specific structures and functions below are not intended to limit the scope of the applicant's invention or the scope of the claims attached. Rather, the figures and written description are provided to teach any person skilled in the art to make and use the invention for which patent protection is sought. Those skilled in the art will understand that, for clarity and understanding, not all features of commercial embodiments of the invention have been described or shown. Those skilled in the art will also understand that the development of actual commercial embodiments of the invention will require numerous implementation-specific decisions to achieve the developer's ultimate goals for the commercial embodiment. These implementation-specific decisions may include, and may not be limited to, compliance with system-related, enterprise-related, governmental-related constraints and other constraints, which may vary depending on the specific implementation, location, and time. While the developer's efforts may be complex and time-consuming in an absolute sense, such efforts will be routine for those skilled in the art who benefit from this disclosure. It must be understood that the invention disclosed and taught herein is susceptible to numerous and various modifications and alternatives. Finally, the use of singular terms such as, but not limited to, "one" is not intended to limit the number of items. [Simplified Explanation of the Diagram]

[0019] Figure 1A is a high-order block diagram of a data processing environment according to one embodiment;

[0020] FIG1B is a more detailed block diagram of an exemplary flash card of the data storage system of FIG1A according to the first embodiment;

[0021] Figures 2 to 5 show exemplary configurations of physical memory within a NAND flash memory system according to the present disclosure;

[0022] FIG6A depicts an exemplary embodiment of a block-equal disk area according to the present disclosure;

[0023] FIG6B depicts an exemplary embodiment of a page-equal disk area according to the present disclosure;

[0024] Figure 7 is a high-level data flow diagram of the flash memory management functions and data structure used by a flash memory controller according to an embodiment;

[0025] Figure 8 is a high-order logic flowchart of an exemplary method according to one embodiment, by which the controller serves host write commands in a non-volatile memory system;

[0026] Figure 9 shows an exemplary data structure according to one embodiment, wherein the controller supports separating host write data and redistribution write data into different write streams and separating read heat within the write streams;

[0027] Figure 10 is a high-order logic flowchart of an exemplary method according to one embodiment, by which a controller serves a relocation write command in a non-volatile memory system; and

[0028] FIG11 is a block diagram of an exemplary flash card of the data storage system of FIG1A according to the second embodiment.

Claims

1. A method in a data storage system providing storage in mass non-volatile memory, the method comprising: a controller of the data storage system receiving a host write command and caching associated host write data in both a first write cache in non-volatile memory and a mirrored second write cache in volatile memory; the controller taking the host write data off the second write cache instead of the first write cache to the mass non-volatile memory; and the controller servicing a relocation write command requesting relocation of data in the mass non-volatile memory by referring to the second write cache, the servicing including caching the relocation write data associated with the relocation write command in the second write cache instead of the first write cache and taking the relocation write data off the second write cache to the mass non-volatile memory.

2. The method of claim 1, further comprising: before completing the write operation of the host data offstage to the mass nonvolatile memory, the controller sends a response to a host write command based on the host write data being cached in the first write cache.

3. As in request item 1, where: The high-capacity non-volatile memory includes flash memory; and the method includes the controller generating at least some of the relocation write commands during the collection of discarded items in the flash memory.

4. The method of claim 1, further comprising: the controller releasing the host write data of the host write command in the first write cache based on the completion of the host write data offstage to the mass non-volatile memory.

5. The method of claim 1, further comprising: the controller recording host write data at at least one first location in the first write cache in an entry of a logic-to-entity translated data structure; and based on taking the host write data off the mass non-volatile memory, the controller updating the entry to indicate a different second location in the mass non-volatile memory.

6. The method of request item 5, wherein recording in the entry includes recording the host write data in a third location in the second write cache in the entry.

7. The method of claim 1, wherein the mass non-volatile memory includes the first write cache.

8. The method of claim 1, further comprising: the controller maintaining in the first write cache and the second write cache a plurality of buffers, each corresponding to one of a plurality of different write hotspots.

9. A data storage system comprising: a controller for a mass non-volatile memory, wherein the controller is configured to perform the following operations: receiving a host write command and caching associated host write data in both a first write cache in the non-volatile memory and a mirrored second write cache in the volatile memory; taking the host write data off the second write cache instead of the first write cache to the mass non-volatile memory; and servicing a relocation write command requesting relocation of data in the mass non-volatile memory by referring to the second write cache, the servicing including caching the relocation write data associated with the relocation write command in the second write cache instead of the first write cache and taking the relocation write data off the second write cache to the mass non-volatile memory.

10. The data storage system of claim 9, wherein the controller is further configured to perform the following operations: before completing the write operation of the host data offstage to the mass nonvolatile memory, sending one of the responses to the host write command to a host based on the host write data being cached in the first write cache.

11. The data storage system as described in request item 9, wherein: The high-capacity non-volatile memory includes flash memory; and the controller is further configured to generate at least some of the relocation write commands during the collection of discarded items in the flash memory.

12. The data storage system of claim 9, wherein the controller is further configured to perform the following operations: release the host write data of the host write command in the first write cache based on the completion of the host write data offstage to the mass non-volatile memory.

13. The data storage system of claim 9, wherein the controller is further configured to perform the following operations: record host write data at at least one first location in the first write cache in an entry of a logic-to-entity translated data structure; and update the entry to indicate a different second location in the mass non-volatile memory based on the host write data being offloaded to the mass non-volatile memory.

14. The data storage system of claim 13, wherein recording in the entry includes recording the host write data in a third location in the second write cache.

15. The data storage system of claim 9, further comprising the mass non-volatile memory, wherein the mass non-volatile memory includes the first write cache.

16. The data storage system of claim 9, wherein the controller is further configured to perform the following operations: maintaining a plurality of buffers, each corresponding to one of a plurality of different write hotspots, in the first write cache and the second write cache.

17. A program product comprising: a storage device; and program code stored in the storage device and executable by a controller of a mass non-volatile memory such that the controller performs the following operations: receiving a host write command and caching associated host write data in both a first write cache in the non-volatile memory and a mirrored second write cache in the volatile memory; offloading the host write data from the second write cache instead of the first write cache to the mass non-volatile memory; and servicing a relocation write command requesting relocation of data in the mass non-volatile memory by referring to the second write cache, the service including caching the relocation write data associated with the relocation write command in the second write cache instead of the first write cache and offloading the relocation write data from the second write cache to the mass non-volatile memory.

18. The program product of request item 17, wherein the program code causes the controller to perform the following operations: before completing the write operation of the host data offstage to the mass nonvolatile memory, sending one of the responses to the host write command to a host based on the host write data being cached in the first write cache.

19. As in request item 17, the program product, wherein: The high-capacity non-volatile memory includes flash memory; and the code causes the controller to generate at least some of the relocation write commands during the collection of discarded items in the flash memory.

20. The program product of request item 17, wherein the program code causes the controller to perform the following operations: release the host write data of the host write command in the first write cache based on the completion of the host write data offstage to the mass non-volatile memory.

21. The program product of claim 17, wherein the program code causes the controller to perform the following operations: record host write data at at least one first location in the first write cache in an entry of a logic-to-entity translated data structure; and update the entry to indicate a different second location in the mass non-volatile memory based on the host write data being offloaded to the mass non-volatile memory.

22. The program product as requested in item 21, wherein the entry includes recording the host write data in a third location in the second write cache.

23. The program product as requested in item 17, wherein the mass non-volatile memory includes the first write cache.

24. The program product of claim 17, wherein the program code causes the controller to perform the following operations: maintain a plurality of buffers in the first write cache and the second write cache, each corresponding to one of a plurality of different write hotspots.

Images