MIRRORING DATA IN WRITE CACHES OF A CONTROLLER OF A NON-VOID STORAGE

Abstract

Method in a data storage system (120) which provides storage in a non-volatile mass storage device (150), wherein the method comprises: a controller of the data storage system (120) that receives a host write command and buffers associated host write data both in a first write cache (146a) in the non-volatile memory and in a mirrored second write cache (146b) in the volatile memory (806, 808); the controller that swaps the host write data from the second write cache (146b), but not from the first write cache (146a), to the non-volatile mass storage (150) (814); the controller that serves repositioning write commands that request a data repositioning in the non-volatile mass storage (150) by referencing the second write cache (146b), wherein serving includes buffering repositioning write data, which are associated with the repositioning write commands in the second write cache (146b) but not in the first write cache (146a), and swapping (1006) the repositioning write data from the second write cache (146b) to the non-volatile mass storage (150); the controller, which records in an entry of a logic-physical translation data structure a first storage location of host write data in the first write cache (146a) and a second storage location of host write data in the second write cache (146b); and the controller, which, based on the offloading of the host write data to the non-volatile storage (150), updates the entry to specify a different third storage location in the non-volatile storage (150).

Description

BACKGROUND OF THE INVENTION

[0001] The present disclosure relates generally to data storage and, in particular, to non-volatile storage systems. Specifically, the present disclosure relates to non-volatile storage systems comprising mirrored write caches that buffer host write data in both volatile and non-volatile memory.

[0002] NAND flash memory is an electrically programmable and erasable non-volatile memory technology that stores one or more data bits per memory cell as a charge on the floating gate of a transistor or similar charge-trap structure. In a typical implementation, an array of NAND flash memory is organized into physical blocks (also called "erase blocks") of memory, each of which comprises multiple physical pages, which in turn contain a multitude of memory cells. Due to the arrangement of the word and bit lines used to access memory cells, arrays of flash memory can generally be programmed on a page-by-page basis but are erased on a block-by-block basis.

[0003] As is known in the prior art, NAND flash memory blocks must be erased before being programmed with new data. A block of NAND flash memory cells is erased by applying a high positive erase voltage pulse to the global p-well region of the selected block and by biasing to ground all word lines of the memory cells to be erased. The application of the erase pulse promotes tunneling of electrons away from the floating gates of the memory cells, which are biased to ground, to impart a net positive charge to them and thus allow the voltage thresholds of the memory cells to transition to the erased state.Each erase pulse is generally followed by an erase check operation that reads the erase block to determine whether the erase operation was successful, for example by verifying that fewer than a threshold number of memory cells in the erase block were not successfully erased. Generally, erase pulses continue to be applied to the erase block until the erase check operation is successful or until a predetermined number of erase pulses have been used (i.e., the erase pulse budget is exhausted).

[0004] A NAND flash memory cell can be programmed by applying a high positive programming voltage to the word line of the cell to be programmed and a medium pass voltage to the cells in the same string where programming is to be prevented. Applying the programming voltage causes electrons to tunnel onto 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 checking that fewer than a threshold number of memory cells in the programmed page contain bit errors.In general, 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 logical pages, each containing, for example, 4 kB or 16 kB of data. A given physical memory page can store one or more logical pages of data. When data is updated, logical pages containing outdated data become invalid, leaving physical blocks with a mixture of physical pages containing valid and invalid data. Eventually, a NAND flash memory controller reclaims the storage capacity occupied by the physical pages containing invalid data through a process called garbage collection. Garbage collection involves writing any remaining valid data from an initial physical block back into one or more previously erased physical blocks. The initial physical block can then be erased in preparation for reprogramming.

[0006] In enterprise-class NAND flash storage systems, preventing data loss, for example in the event of a power outage, is of paramount importance. Therefore, in such data storage systems, the flash controller can only acknowledge a host write command after the host write data associated with that command has been permanently stored in non-volatile memory. In an initial state-of-the-art implementation, the flash controller first buffers incoming host write data in a write cache implemented in a cost-effective volatile memory technology, such as dynamic random-access memory (DRAM). The flash controller then moves 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 permanently stored in the NAND flash memory (and thus protected from data loss in the event of a power failure), the flash controller sends an acknowledgment to the host, releasing resources in the host that had been allocated to track the completion of the host write command. Repositioning writes associated with garbage collection in the NAND flash memory are similarly buffered in the DRAM write cache before being swapped back to the NAND flash memory. This first architecture has the advantage of a simple, relatively inexpensive design, but the disadvantage of relatively weak write performance because the acknowledgment to the host is delayed until the host write data is permanently stored in the NAND flash memory.

[0007] To provide improved write performance compared to this first state-of-the-art design, a second state-of-the-art design implements a non-volatile write cache, for example, in battery-backed DRAM, magnetoresistive RAM (MRAM), ferroresistive RAM (FRAM), phase-change memory (PCM), or another non-volatile memory technology. With this design, write performance improves significantly because the flash controller can send an acknowledgment of the host write command to the host as soon as the associated host write data has been written to the write cache, and thus before the host write data has been completely swapped from the non-volatile write cache to the NAND flash memory.Repositioning writes performed in conjunction with memory cleanup are similarly buffered in the non-volatile write cache before being swapped back to the NAND flash memory. This second state-of-the-art architecture provides significantly better write performance compared to the first state-of-the-art architecture, but at the cost of increased complexity and higher costs due to the price difference between implementing the write cache in volatile memory (e.g., DRAM) versus non-volatile memory (e.g., MRAM).

[0008] In view of the state of the art, the present application acknowledges that it would be useful and desirable to provide an improved data storage system that implements a non-volatile write cache, allowing acknowledgment of host write commands before offloading the associated host write data to a NAND flash memory, while also reducing the cost of the memory used to implement the non-volatile write cache for a given level of write performance.

[0009] US 10,180,792 B1 describes a method for storing selected data from a data source. This data is first stored in a buffer and then saved in non-volatile memory for sequential storage. Afterward, it can be transferred to semiconductor memory, such as dynamic random-access memory (DRAM), and finally copied to main memory, such as a magnetic hard drive. If the data is not present in the semiconductor memory, it can be loaded from the non-volatile memory into main memory.

[0010] US 2020 / 0089609A1 describes a data storage system comprising a host and a storage subsystem, including a controller. Write-back data generated by the host is initially stored in an allocated cache of the storage subsystem and simultaneously written to a non-volatile destination address. Upon a secondary event, the controller releases the cache memory for new data.

[0011] US 2008 / 0071999A1 describes a method, system, and manufactured unit in which a controller receives a request from a host and verifies whether the primary storage control unit is operational. If it is operational, the request is processed through it; otherwise, access is provided through a secondary storage control unit that is replicated synchronously with the primary unit.

[0012] EP 2 988 222 A1 describes a method for transferring write data from a storage controller to storage media. This method determines whether a cache element should be swapped out from the write cache, particularly if a defined pollution level is exceeded. An identified cache element is then transferred to memory while the number of active swaps is counted. The process is repeated as long as the maximum number of active swaps has not been reached. SUMMARY

[0013] The invention is described by the features of the independent claims. Embodiments are specified in the dependent claims.

[0014] In at least one embodiment, a method for managing a data storage system is provided that offers persistent storage in non-volatile mass storage. A controller of the data storage system receives a host write command and buffers the 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 moves the host write data from the second write cache, but not from the first write cache, to the non-volatile mass storage. The controller executes repositioning write commands that request data repositioning in the non-volatile mass storage by referencing the second write cache.Executing the repositioning write commands involves buffering repositioning write data in the second write cache, but not in the first write cache, and offloading the repositioning write data from the second write cache to non-volatile mass storage.

[0015] In at least one embodiment, a data storage system comprises a controller of a non-volatile mass storage device. The controller is configured to receive a host write command and buffer the 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 swaps the host write data from the second write cache, but not from the first write cache, to the non-volatile mass storage device. The controller handles repositioning write commands that request data repositioning in the non-volatile mass storage device by referencing the second write cache.Executing the repositioning write commands involves buffering repositioning write data in the second write cache, but not in the first write cache, and offloading the repositioning write data from the second write cache to non-volatile mass storage.

[0016] In at least one embodiment, a program product comprises a memory unit and program code stored in the memory unit, which is executable by a controller of a non-volatile storage device. When executed, the program code causes the controller to receive a host write command and buffer the 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 swaps the host write data from the second write cache, but not from the first write cache, to the non-volatile storage device. The controller handles repositioning write commands that request data repositioning in the non-volatile storage device by referencing the second write cache.Executing the repositioning write commands involves buffering repositioning write data in the second write cache, but not in the first write cache, and offloading the repositioning write data from the second write cache to non-volatile mass storage.

[0017] In at least one embodiment, before completing the outsourcing of the host write data to the non-volatile mass storage, the controller sends an acknowledgment of the host write command to the host based on the host write data buffered in the first write cache.

[0018] In at least one embodiment, the non-volatile mass storage device comprises a flash memory, and the controller generates at least some of the repositioning write commands during memory cleanup in the flash memory.

[0019] 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 swapping of the host write data to the non-volatile mass storage.

[0020] In at least one embodiment, the controller records at least one first storage location of host write data in the first write cache in an entry of a logic-physical translation data structure. Based on the host write data being moved to non-volatile mass storage, the controller updates the entry to specify a different second storage location in the non-volatile mass storage.

[0021] In at least one embodiment, the controller additionally records a third storage location for host write data in the second write cache in the entry of the logic-physical translation data structure.

[0022] In at least one embodiment, the non-volatile mass storage device comprises the first write cache.

[0023] In at least one embodiment, the controller manages a plurality of buffers in the first write cache and in the second write cache, each of which corresponds to a plurality of different write heaps. Brief description of the multiple views of the drawings Fig. 1A is an overview block diagram of a data processing environment according to one embodiment; Fig. Figure 1B is a more detailed block diagram of an example flash card of the data storage system of Fig. 1A according to a first embodiment; Fig. Figures 2 to 5 illustrate an exemplary arrangement of a physical memory in a NAND flash memory system according to the present disclosure; Fig. 6A represents an exemplary implementation of a block-level stripe according to the present disclosure; Fig. 6B represents an exemplary implementation of a page-level stripe according to the present disclosure; Fig. Figure 7 is an overview data flow diagram of the flash management functions and data structures used by a flash controller according to one embodiment; Fig. Figure 8 is a logical overview flowchart of an exemplary procedure by which a controller serves a host write command in a non-volatile memory system according to one embodiment; Fig. Figure 9 illustrates an exemplary data structure in which a controller supports both a separation of host write data and repositioning write data into different write streams and a separation of read heaps in the write streams according to one embodiment; Fig. Figure 10 is a logical overview flowchart of an exemplary procedure by which a controller executes a repositioning write command in a non-volatile memory system according to one embodiment; and Fig. Figure 11 is a block diagram of an example flash card of the data storage system of Fig. 1A according to a second embodiment. DETAILED DESCRIPTION

[0024] With reference to the characters and with particular reference to Fig. Figure 1A illustrates an overview block diagram of an exemplary data processing environment 100 with a data storage system 120 with a mirrored write cache, as further described herein. As shown, the data processing environment 100 comprises one or more hosts, such as a processor system 102 with one or more processors 104 that process instructions and data. The processor system 102 may additionally include local memory 106 (e.g., DRAM or disks) that can store program code, operands, and / or execution results of the processing performed by the processor(s) 104. In various embodiments, the processor system 102 may, for example, be a mobile data processing unit (such as a smartphone or tablet), a laptop or desktop PC system, or a server computer system (such as one from the POWER ®-series, available from International Business Machines Corporation), or a mainframe computer system. The Processor System 102 can also be an embedded processor system using various processors, such as ARM. ® , POWER, Intel x86 or any other processor in combination with memory caches, memory controllers, local storage, I / O bus hubs, etc.

[0025] Each processor system 102 further comprises an input / output (I / O) adapter 108, which is connected directly (i.e., without any intermediary unit) or indirectly (i.e., via at least one intermediary unit) to a data storage system 120 via an I / O channel 110. In various embodiments, an I / O channel 110 can use any or a combination of known or future communication protocols, including, for example, Fibre Channel (FC), FC over Ethernet (FCoE), Internet Small Computer System Interface (iSCSI), InfiniBand, Transport Control Protocol / Internet Protocol (TCP / IP), Peripheral Component Interconnect Express (PCIe), Non-volatile Memory Express (NVMe), NVMe over Fabrics (NVMe-oF), etc.I / O instructions transmitted over I / O channel 110 include host read instructions, by which a processor system 102 requests data from a data storage system 120, and host write instructions, by which a processor system 102 requests that data be stored in the data storage system 120.

[0026] In the illustrated embodiment, the data storage system 120 comprises several interface nodes 122 through which the data storage system 120 receives I / O commands and responds to them via I / O channels 110. Each interface node 122 is connected to each of several Redundant Array of Inexpensive Disks (RAID) controllers 124 to provide fault tolerance and load balancing. Each of the RAID controllers 124 is in turn connected to each of several flash cards 126 (e.g., via a PCIe bus), including, in this example, NAND flash memory media. In other embodiments, other lossy storage media can be used.

[0027] Fig. Figure 1B shows a more detailed block diagram of a flash card 126 of the data storage system 120. Fig. 1A according to a first embodiment. In this embodiment, the flash card 126 comprises a gateway 130, which serves as an interface between the flash card 126 and the RAID controllers 124. The gateway 130 is connected to a general-purpose processor (GPP) 132, which can be configured (e.g., by program code) to perform various management functions, such as preprocessing I / O commands received by the gateway 130, scheduling the execution of the I / O commands by the flash card 126, and / or performing other management functions. The GPP 132 is connected to a GPP memory 134 (e.g., DRAM), which can conveniently buffer data created, referenced, and / or modified during its processing by the GPP 132.

[0028] The gateway 130 is further connected to at least one flash controller 140, which controls a non-volatile mass storage system, such as a NAND flash memory system 150. The flash controller (FC) 140 handles I / O commands, for example, by accessing the NAND flash memory systems 150 to read the requested data from or write it to the NAND flash memory systems 150, as discussed in more detail below. In various embodiments, the flash controller 140 can be implemented, for example, by an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). In embodiments where the flash controller 140 is implemented by an FPGA, the gateway 132 can program and configure the flash controller 140 when the data storage system 120 is powered on.

[0029] The flash controller 140 is connected to the flash controller memory, which in this embodiment comprises both a non-volatile flash controller memory 142 and a volatile flash controller memory 144. The non-volatile flash controller memory 142 can be implemented, for example, with MRAM, FRAM, PCM, battery-backed DRAM, or another non-volatile memory technology, and the volatile flash controller memory 144 can be implemented with a relatively inexpensive volatile memory technology such as DRAM. As further described in Fig. As specified in Figure 1B, the non-volatile flash controller memory 142 comprises a first host write cache 146a for buffering host write data associated with host write instructions received from hosts, such as the processor systems 102. The contents of the host write cache 146a are mirrored by the flash controller 140 into a second host write cache 146b, which is implemented in the volatile flash controller memory 144. The host write caches 146a and 146b can furthermore be connected to the same memory bus to allow mirrored data to be written to both write caches 146a and 146b with a single instruction, as should be clear to a person skilled in the art upon reading this description.

[0030] The Flash Controller 140 implements a Flash Translation Layer (FTL) that provides logical-physical address translation to enable access to specific memory locations in the NAND flash memory systems 150. Generally, an I / O command received by a Flash Controller 140 from a host unit, such as a Processor System 102, contains the logical block address (LBA) at which the data is to be accessed (read or written), and, in the case of a host write command, the host write data to be written to the data storage system 120. The I / O command may also specify the amount (or size) of data to be accessed. Other information may also be transmitted, depending on the protocol and functions supported by the data storage system 120.As is known to those skilled in the art, in some implementations of NAND flash memory, the smallest data grain accessible by a host read or write command is fixed to the size of a single physical page, for example, 16 kilobytes (kB). The LBA provided by the host unit corresponds to a logical page in a logical address space, which may have a size of, for example, 4 kB or 16 kB. The logical page can further be compressed by the flash controller 140, so that each physical page can store one or more logical pages. The FTL translates the LBA into a physical address, which is assigned to a corresponding physical memory location in the NAND flash memory system 150.The Flash Controller 140 can store mappings between logical and physical addresses in a logic-physical translation data structure, such as a logic-physical translation (LPT) table 152, which can be conveniently stored in the volatile Flash Controller memory 144.

[0031] As further in Fig. As shown in Figure 1B, the volatile flash controller memory 144 additionally includes a repositioning write buffer 148 for buffering data collected by the garbage collection process that needs to be repositioned in the NAND flash memory system 150. Furthermore, the volatile flash controller memory 144 can optionally include a read cache 156 for buffering data from the NAND flash memory system 150 that has been recently and / or frequently requested by host read commands. The flash controller 140 can also store threshold voltage (Vth) displacement data 154 in the volatile flash controller memory 144, which is used to calibrate the read threshold voltages of the various subgroups (e.g., page groups) of the NAND flash memory system 150, as well as other management data structures 158, which store management data such as bit error rate (BER) and other statistics, program / erase (P / E) cycle counters, entry information, etc.

[0032] NAND flash memory systems 150 can take many forms in various configurations. With reference to the following: Fig. Figures 2 to 5 illustrate an exemplary arrangement of physical memory in a NAND flash memory system 150 according to one embodiment.

[0033] As in Fig. As shown in Figure 2, the NAND flash memory system 150 can be formed from forty (40) individually addressable memory units of a NAND flash memory. In the illustrated example, each of the flash memory units M0a to M19b takes the form of a flash memory module mounted on a circuit board, capable of storing two or more bits per cell. In one particular embodiment, the memory modules are implemented with quad-level cell (QLC) NAND flash memory configured to operate in a hybrid stepped arrangement comprising a first pool of physical blocks operating in QLC mode and a second pool of physical blocks operating in single-level cell (SLC) mode. The forty NAND flash memory modules are arranged in twenty pairs, (M0a, M0b) to (M19a, M19b).For the purposes of the physical addressing plan, each group of two modules forms a "path" ("lane"), sometimes also called a "channel", so that the NAND flash memory system contains 150 twenty channels or paths (Lane0 to Lane19).

[0034] In a preferred embodiment, each of the individual paths has a corresponding bus that connects it to the associated flash controller 140. Thus, the flash controller 140 can forward its transmissions to one of the memory module paths by routing them to one of the specific data transmission buses. Since each data transmission bus for a given path is independent of the data transmission buses for the other paths, the flash controller 140 can issue commands and simultaneously send or receive data over the different data transmission buses, thereby enabling the flash controller 140 to access the flash memory modules corresponding to the individual paths simultaneously or at least nearly simultaneously.

[0035] With the following reference to Fig. Figure 3 illustrates an exemplary embodiment of a flash memory module 300, which can be used to implement any of the flash memory modules M0a to M19b from Fig. 2 can be used. As in Fig. As shown in Figure 3, the physical memory locations provided by the Flash Memory Module 300 are further subdivided into physical memory locations that can be addressed and / or identified via Chip Enables (CEs). In the example of Fig. 3. The physical memory of each flash memory chip 300 is divided into four chip enables (CE0, CE1, CE2, and CE3), each with its own CE line. These CEs are activated by the flash controller 140 to allow access to or from the physical memory locations within the corresponding CE. Each CE is further subdivided into multiple chips (e.g., Die0 and Die1), each with two or four levels (e.g., Plane0 and Plane1). Each level represents a collection of physical blocks that are physically related to one another due to the physical layout of the flash memory chips and share a common circuit (e.g., I / O buffer) for performing various operations, such as read and write operations.

[0036] As further in Fig. As shown in Figures 4 to 5, an example level 400 is included, which is used to implement any of the levels in the flash memory module 300. Fig. 3 can be used, 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 early due to manufacturing defects. Generally, a block is a collection of physical pages that are usually physically mapped to one another. This mapping is such that a block is defined as the smallest granularity of physical memory locations that can be erased in the NAND flash memory system 150. In the embodiment of Fig. In this system, each block contains several hundred or thousand pages, for example, 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 this example system, each physical data page has a general capacity (e.g., 16 kB) for data storage plus additional storage for page metadata. Thus, 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.

[0037] Since the FTL implemented by the data storage system 120 isolates the logical address space made available to host units by the physical memory in the NAND flash memory system 150, the size of the NAND flash memory system 150 need not be equal to the size of the logical address space allocated to host units. In most embodiments, it is advantageous to allocate a logical address space smaller than the total available physical memory (i.e., it is advantageous to overprovision the NAND flash memory system 150). Overprovisioning in this way ensures that physical memory resources are available when the logical address space is fully utilized, even if a certain amount of invalid data is present, as described above.In addition to invalid data that has not yet been reclaimed, the overprovisioned space can be used to ensure that sufficient logical space is available, even in the presence of memory errors and the memory overhead resulting from the use of data protection measures such as error correction code (ECC), cyclic redundancy checks (CRC), and parity.

[0038] In some embodiments, data is written to the NAND flash memory system 150 one physical page at a time. In other embodiments, where more robust error handling is desired, data is written to groups of associated physical pages of the NAND flash memory system 150, referred to herein as "page-level stripes." In one embodiment, all pages of a page-level stripe belong to different paths to achieve high write bandwidth. Since in many implementations the smallest erase unit is a block, multiple page-level stripes can be grouped into a block-level stripe, as shown in Fig. Figure 6A shows that each block in the block-level stripe belongs to a different path. When constructing a block-level stripe, any free block of a path can be chosen, but preferably all blocks in the same block-level stripe have the same or a similar degree of integrity. It should be noted that the block selection can be further restricted to originating from the same layer, chip, or chip activation. The lengths of the block-level stripes can vary, but in an embodiment where the NAND flash memory system contains 150 to 20 paths, each block-level stripe contains between two and twenty blocks, each block originating from a different path.

[0039] When a block has been selected from each path and a block-level stripe has been formed, page-level stripes are preferentially formed from physical pages with the same page number from all blocks in the block-level stripe. While the lengths of the various page-level stripes stored in the NAND Flash Memory System 150 can vary, in one embodiment each page-level stripe comprises one to twenty data pages of write data (typically provided by a host unit). In another embodiment, a page-level stripe comprises one to nineteen data pages of write data and an additional page (a "data backup page") used to store data backup information for the write data. For example, illustrates Fig. Figure 6B shows an example page-level stripe 610 with N data pages (i.e., Dpage00 to DpageN-1) and a privacy page (i.e., PpageN). The privacy page can be positioned on any path of the page-level stripe that contains a non-decommissioned page, but it is typically located on the same path for all page-level stripes of the same block-level stripe to minimize metadata information. Adding a privacy page as illustrated requires garbage collection to be performed concurrently on all page-level stripes of the same block-level stripe. After garbage collection of the block-level stripe is complete, the block-level stripe can be resolved, and each block can be placed in the relevant Ready-to-Use (RTU) queue, as explained below.

[0040] Following the description of the general physical structure and operation of exemplary embodiments of a data storage system 120, certain operational aspects of the data storage system 120 are discussed below with reference to Fig. 7 described, which is an overview data flow diagram illustrating the flash management functions and data structures used by the GPP 132 and / or the Flash Controller 140 according to one embodiment.

[0041] As noted above, the Data Storage System 120 generally does not allow external units (e.g., hosts) to directly address and / or directly access physical storage locations in NAND Flash Memory Systems 150. Instead, the Data Storage System 120 is generally configured to represent one or more logical volumes to host units, each with a contiguous logical address space. This allows host units to read from and write data to logical block addresses (LBAs) within the logical address space, while allowing one or more of the various levels of controllers (e.g., the RAID controllers 124, the flash controllers 140, and the GPP 132) to control where the data belonging to the various LBAs is actually located within the physical storage locations provided by the NAND Flash Memory Systems 150.In this way, the performance and longevity of NAND flash memory systems 150 can be intelligently managed and optimized. In the illustrated embodiment, each flash controller 140 performs a logic-physical address translation for an associated group of LBAs by using a logic-physical address translation data structure (LPT) table 152, which can be stored in the associated volatile flash controller memory 144. It should be noted that the logical address provided to the flash controllers 140 may differ from the logical address originally provided to the data storage system 120, since various components in the data storage system 120 can perform address translation operations between the external units and the flash controllers 140.

[0042] As should be clear, implementing a mirrored host write cache 146b in the volatile flash controller memory 144 reduces the available capacity in the volatile flash controller memory 144 for other metadata, such as an LPT 152. In at least some embodiments, the space required for the LPT 152 in the volatile flash controller memory 144 can be reduced by the flash controller 140 through the implementation of a swapping mechanism. In such embodiments, a backup memory of LPT entries is managed in the NAND flash memory system 150, and the flash controller 140 swaps LPT entries into or out of the backup memory as needed.

[0043] A flash management code running on the GPP 132 tracks erased blocks of the NAND flash memory system 150 that are ready for use in ready-to-use (RTU) queues 700, which can be stored, for example, in a GPP memory 134. In the illustrated embodiment, the flash management code running on the GPP 132 preferentially manages one or more RTU queues 700 per level or channel, and an identifier for each erased block to be reused is placed in one of the RTU queues 700 corresponding to its channel. For example, in one embodiment, the RTU queues 700 for each channel contain a separate RTU queue 700 for each of a plurality of block integrity levels. In various implementations, it has been found that between 2 and 8 RTU queues of 700 per level (and a corresponding number of block integrity levels) are sufficient.

[0044] A block-level stripe build function (executed, for example, by the Flash management code running on GPP 132) builds new block-level stripes from the deleted blocks placed in the RTU queue 700. As described above with reference to... Fig. As noted in 6A, block-level stripes are preferably formed from blocks of the same or similar integrity level (i.e., expected remaining useful lifetime) located in different channels. This means that block-level stripes can be conveniently constructed by the Block-Level Stripe Build Function 702 by taking each block of the new block-level stripe from corresponding RTU queues 700 of levels or different channels. The new block-level stripe is then queued for data placement by the Flash Controller 140 using a Data Placement Function 704.

[0045] The data placement function 704 includes open block queues 706 that track identifiers of incompletely programmed blocks in the block-level stripes constructed by a block-level stripe build function 702. As further described in Fig. As illustrated in Figure 7, the data placement function 704 additionally includes a caching engine 714 to write host write data to mirrored host write caches 146a and 146b, and to write repositioning write data to the repositioning write buffer 148. The data placement function 704 also includes a swap engine 716 to write data from the host write cache 146b and the repositioning write buffer 148 to open blocks of the NAND flash memory system 150 that have been identified in the open block queues 706.

[0046] In response to a host write command received from a host such as a processor system 102, the data placement function 704 of the flash controller 140 determines, by reference to the LPT table 152, whether the one or more target LBAs specified in the host write command currently belong to one or more physical memory pages in the NAND flash memory system 150, and if so, changes the state of each data page currently belonging to a target LBA to indicate that it is no longer valid. The caching engine 714 additionally writes the host write data of the host write command to both host write caches 146a and 146b, preferably in parallel, using a single operation (e.g., the host write data traverses the memory bus only once).Once the update for host write cache 146a is complete, caching engine 714 can immediately provide an acknowledgment message ("Ack") to the issuing host via I / O channel 110. Caching engine 714 also updates the entry in LPT 704 for the LBA specified by the host write command to indicate the location of the host write data in host write cache 146a and / or host write cache 146b.

[0047] To serve a host write command, the 702 data placement function also allocates a page-level stripe, if necessary, to store the write data of the host write command and any unupdated data (i.e., in the case where the write request is smaller than a logical page, there is still valid data that needs to be processed in a read-modify-write form) from an existing page-level stripe, if one exists, specified as a target by the host write command, and / or to store the write data of the host write command and any unupdated (i.e., still valid) data from an existing page-level stripe, if one exists, specified as a target by the host write command, on an already allocated page-level stripe that has available space.The page-level stripe can be assigned either from a block-level stripe already allocated for data storage or from a new block-level stripe. In a preferred embodiment, the page-level stripe assignment can be based on the integrity of the blocks available for allocation and the heap (i.e., the estimated or measured write access frequency) of the LBA (Logical Block Access) of the write data. The swap engine 716 of the data placement function 704 writes the host write data and associated metadata (e.g., CRC and ECC values) for each codeword from the host write cache 146b to pages of the allocated page-level stripe identified in the open block queues 706, and additionally writes parity information to the data backup page of the allocated page-level stripe, if required.The swap engine 716 also updates LPT table 152 to map one or more LBAs of the host write data addresses to the physical page(s) in the NAND flash memory 150 used to store the write data. Afterward, the flash controller 140 can access the data from the NAND flash memory 150 to serve host read commands by referencing LPT table 152.

[0048] Once all pages have been written to a block-level stripe, or the block-level stripe has otherwise been closed, the flash controller 140 places an identifier of the block-level stripe in one of occupied block queues 708. This identifier is used by flash management code running in GPP 132 to track blocks for garbage collection or other management functions. As noted above, pages are invalidated by the write process, and therefore sections of the NAND flash memory system 150 are not used.The associated Flash Controller 140 (and / or the GPP 132) must eventually reclaim this space through garbage collection performed by a Garbage Collector 720. The Garbage Collector 720 selects specific block-level stripes for garbage collection based on a number of factors, including, for example, the integrity of the blocks in the block-level stripes and how much of the data in the physical blocks is invalid. In at least one embodiment, garbage collection is performed on entire block-level stripes, and the Garbage Collector 720 issues repositioning write commands to the caching engine 714 of the data placement function 704 to reposition the still-valid data in one garbage-collected block-level stripe to another block-level stripe.In NAND flash memory systems, implementing a hybrid tiered arrangement is desirable. This arrangement comprises a first pool of physical blocks operating in a higher-density mode (e.g., QLC mode) and a second pool of physical blocks operating in a lower-density mode (e.g., SLC mode). This allows for the repositioning of data from older blocks operating in both modes to be written to new blocks operating in both modes. Thus, the repositioning write commands issued by the garbage collector can specify the desired operating mode of the target block's stripe, for example, to support QLC-to-QLC, SLC-to-QLC, SLC-to-SLC, or QLC-to-SLC repositioning.

[0049] As further in Fig. As specified in 7, the flash management functions performed by the GPP 132 and / or the flash controller 140 additionally include a wear-leveling device 722, which requests a repositioning of data in block-level stripes in occupied block queues 708 to compensate for cross-block wear, and a pool-leveling function 724, which requests the repositioning of data stored in certain block-level stripes to allow some or all of the constituent blocks to be reconfigured to operate in a different mode of operation (e.g., QLC or SLC).

[0050] Based on the repositioning write commands received from the garbage collector 720, the wear leveling device 722, and the pool balancing function 724, the caching engine 714 stores repositioning write data from the old stripes at the block level in the repositioning write buffer 148 in the volatile flash controller memory 144. Additionally, the caching engine 714 can update the LPT table 152 to further indicate the memory location in the repositioning write buffer 148.Once all still valid data from the old block-level stripe has been moved and written to new pages of the assigned page-level stripes identified in the open block queues 706, the swap engine 716 updates the LPT table 152 to break the current mapping between the logical and physical addresses of the data and assign the LBA(s) to the newly positioned data addresses of the physical page(s) in the NAND flash memory 150 used to store the repositioned data. The old block-level stripe is then resolved, breaking the block mapping, and the block identifiers are placed in delete queues 710, of which there can be one delete queue 710 per channel.A block erase function 712 of the flash controller 140 then erases each of the blocks that previously formed the resolved block-level stripes and increments an associated program / erase (P / E) cycle count for the block in the management data structures 158. Based on the integrity indices of each erased block, each erased block is either decommissioned (i.e., no longer used to store user data) or, alternatively, prepared for reuse by placing the block's identifier in the appropriate ready-to-use (RTU) queue 700 in the associated GPP memory 134.

[0051] With the following reference to Fig. Figure 8 presents a logical flowchart of an exemplary procedure by which a controller serves a host write command in a non-volatile storage system according to one embodiment. The illustrated process can be performed, for example, by a controller (e.g., the GPP 132 and / or the Flash Controller 140) in hardware, firmware, software, or a combination thereof during the operation of a data storage system 120. Unless otherwise specified, operations are presented in logical rather than strictly chronological order, and in some embodiments, operations may be performed in a different order than shown or concurrently.

[0052] The process of Fig. Process 8 begins at block 800 and then proceeds to block 802, which illustrates the controller receiving a host write command from a host, such as a processor system 102. The host write command includes an LBA (Location Block Array) to be written and host write data. In response to the detection of a host write command, the controller invalidates the entry, if present, for the LBA in LPT 152. The process then proceeds from block 804, preferably in parallel, to blocks 806 and 808. Block 806 illustrates the controller that buffers the host write data of the host write operation in the host write cache 146a in the non-volatile flash controller memory 142. Block 808 represents the controller that additionally mirrors the host write data of the host write operation in the host write cache 146b in the volatile flash controller memory 144.

[0053] The minimum size of the host write caches 146a, 146b, required to buffer host write data, increases with internal parallelism, the number of supported write streams, the supported write bandwidth, and the average write latency. For a controller with specific write bandwidth and latency characteristics, the minimum size can be calculated based on the physical page size, the number of paths and levels, the maximum number of pending stripes at the page level, and the number of supported write streams and stores. For example, the minimum size of host write caches 146a, 146b for a NAND flash memory system 150 implementing pages of 16 kB, 20 paths of 4 levels grouped into a stripe, and 4 pending word lines (i.e., 16 stripes at page level) can be determined as 16 kB × 20 × 4 × 16 = 20 MB per stream / storage.

[0054] With reference to Fig. Figure 9 illustrates an exemplary data structure in which a controller supports both the separation of host write data and repositioning write data into different write streams, as well as the separation of read heaps within the write streams, according to one embodiment. In this exemplary embodiment, the flash controller 140 implements one write stream of host write data and two write streams of repositioning write data. Each write stream comprises five write stores, including one write store for SLC data and four write stores for QLC data. The four QLC data write stores each include one store for each QLC page type: bottom pages (LP), top pages (UP), extra pages (XP), and top pages (TP).The Flash Controller 140 routes data to the various QLC write stores based on relative read heap size. For example, the coldest QLC write data is buffered in the QLC-TP buffer, the next warmest QLC write data in the QLC-XP buffer, the next warmest QLC write data in the QLC-UP buffer, and the warmest QLC write data in the QLC-LP buffer. While implementing different heap stores increases the minimum size of the host write caches 146a and 146b, reducing the number of write streams and / or heap stores to reduce the footprint of the host write caches 146a and 146b is not preferred because it would increase overall write gain or significantly decrease the efficiency of read heap separation.

[0055] Referring again to block 806 of Fig. 8. Based on the host write data of the host write command buffered in host write cache 146a, the controller sends an acknowledgment of the host write command to the initiating host via I / O channel 110 (in block 810). As noted above, the acknowledgment message signifies permanent storage of the host write data, thus signaling to the host that resources allocated to the host write command can be released for reuse. The process of Fig. 8 continues from blocks 810 and 808 and rejoins at block 812, which represents the controller that updates the entry in LPT 152 for the LBA of 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, the controller can, at least in some embodiments, begin servicing host read commands that request host write data from write cache 146b.

[0056] At block 814, the controller initiates the swapping of host write data from write cache 146b (and not from write cache 146a) to the NAND flash memory system 150 according to the data allocation to buffers in host write cache 146b. By foregoing swapping host write data from write cache 146a, accesses to the non-volatile flash controller memory 142 are normally limited to a single write operation per host write command. In a preferred embodiment, the swapping of host write data is performed "in the background" when the controller is not busy servicing other host I / O commands or performing other management functions. The controller monitors the completion of the swapping of host write data from write cache 146b to the NAND flash memory system 150 (in block 816).Upon detecting that the host write data swap is complete, the controller can release (invalidate) the copy of the host write data located in host write cache 146a, since the host write data is permanently stored in the NAND flash memory system 150 (in block 818). It should be noted that the copy of the host write data in host write cache 146b can be retained for future host read operations of the data. This is advantageous, for example, if the size of host write cache 146b is larger than that of host write cache 146a. Alternatively, the host write data in host write cache 146b could also be released at the same time as the copy in host write cache 146a.The decision to release or retain the host write data in host write cache 146b can depend, for example, on the implemented caching policy, the probability that the host write data will be read in the future, and / or the available size of host write cache 146b. The process then ends. Fig. 8 on a block of 820.

[0057] Although in Fig. Although not explicitly shown in Figure 8, it will be clear to those skilled in the art that in the event of a power failure to a flash card 126 or the data storage system 120 while a host write command is being executed, data loss is avoided. In this case, the host write data can be recovered either by the host from a host queue or by the controller from the permanent copy buffered in the write cache 146a. However, in the case of normal operation in the absence of a power failure, the disclosed process comprises the following four internal data movements in a flash card 126: 1. a write operation to the non-volatile write cache 146a; 2. a write operation into the mirrored volatile write cache 146b; 3. a read operation from the mirrored volatile write cache 146b; and 4. a write operation to the NAND flash memory system 150.

[0058] As should be clear, limiting accesses to the non-volatile write cache 146a to one write access per host write command reduces the bandwidth required for the non-volatile write cache 146a compared to state-of-the-art solutions, thus reducing the minimum required size (and cost) of the non-volatile write cache 146a. Alternatively, the space saved in the non-volatile write cache could also be used to increase the number of write streams and thus improve heap separation.

[0059] With the following reference to Fig. Figure 10 presents a logical overview flowchart of an exemplary procedure by which a controller executes a repositioning write command in a non-volatile memory system according to one embodiment. The illustrated process can be performed, for example, by a controller (e.g., the GPP 132 and / or the Flash Controller 140) in hardware, firmware, software, or a combination thereof during the operation of a data storage system 120. Again, operations are presented in a logical rather than a strictly chronological order, and in some embodiments, operations may be performed in a different order than shown or concurrently.

[0060] The process of Fig. Section 10 begins at block 1000 and then proceeds to block 1002, which illustrates the controller monitoring for the receipt of a repositioning write command, for example, from a garbage collector 720, a wear-leveling device 722, or a pool balancing function 724. The repositioning write command specifies one or more physical blocks (e.g., a block-level stripe) in the NAND flash memory 150 from which repositioning write data needs to be repositioned. In response to the detection of a repositioning write command, the controller reads one or more valid data pages from the physical blocks (referred to herein as "repositioning write data") from the NAND flash memory 150 into the repositioning write buffer 148 in the volatile flash controller memory 144 (in block 1004) at block 1004.It should be noted that the controller refrains from buffering any of the repositioning write data in the non-volatile flash controller memory 142.

[0061] At block 1006, the controller initiates the swapping of repositioning write data from the repositioning write buffer 148 to a block-level stripe in the NAND flash memory system 150, which was identified in the open block queues 706. In a preferred embodiment, the swapping of the repositioning write data is performed in the background when the controller is not busy servicing other host I / O commands or performing other management functions. The controller monitors the completion of the swapping of the repositioning write data from the repositioning write cache 148 to the NAND flash memory system 150 (at block 1008). Upon detecting that the swapping of the repositioning write data is complete, the controller checks whether all still-valid pages from the block or the repositioned block-level stripe have been repositioned (at block 1010).If more pages need to be repositioned, the controller returns to block 1004 to read the next valid page(s) as described above. When no valid pages remain, the controller places identifiers of the source blocks from which the repositioning write data was read into the delete queue 710 and can then release (invalidate) the copy of the repositioning write data located in the repositioning write buffer 148 (in block 1012). In block 1012, the controller also updates the relevant entries in LPT 152 to indicate the new location in the NAND flash memory 150. The process then terminates. Fig. 10 on a block 1014.

[0062] In the case of a normal operation (i.e., without power failure), the disclosed process for handling repositioning write commands includes the following four internal data movements in a flash card 126. 1. a read operation from the NAND flash memory system 150; 2. a write operation to the repositioning write buffer 148 in the volatile flash controller memory 148; 3. a read operation from the repositioning write buffer 148; 4. a write operation to the NAND flash memory system 150.

[0063] As should be clear, excluding any access to the non-volatile write cache 146a while repositioning write commands are being served greatly reduces the bandwidth required for the non-volatile write cache 146a compared to prior art solutions, thus reducing the minimum required size (and cost) of the non-volatile write cache 146a. Alternatively, the space saved in the non-volatile write cache could also be used to increase the number of write streams and thus improve heap separation.

[0064] With the following reference to Fig. Figure 11 shows a block diagram of an example flash card of the data storage system of Fig. 1A according to a second embodiment illustrated. As indicated by similar reference numerals, the illustrated flash card 126' comprises mirrored host write caches 146a, 146b, which, as before, are referenced to Fig. 8 and Fig. The flash card 126' omits a separate non-volatile flash controller memory 142 and instead implements the host write cache 146a in the non-volatile mass storage in the NAND flash memory 150. This second embodiment can be provided at a lower cost due to the elimination of the non-volatile flash controller memory, but typically exhibits lower write performance due to the longer latency of write operations to the NAND flash memory system 150. This longer write latency can be partially mitigated by implementing the host write cache 146a exclusively in the faster SLC storage stage (i.e., either QLC blocks configured to operate in an SLC mode or in dedicated SLC flash memory).

[0065] As described in at least one embodiment, a data storage system provides persistent storage in non-volatile mass storage. A controller of the data storage system receives a host write command and buffers the associated host write data in both a first write cache in non-volatile memory and a mirrored second write cache in non-volatile memory. The controller moves the host write data from the second write cache, but not from the first write cache, to the non-volatile mass storage. The controller executes repositioning write commands that request data repositioning in the non-volatile mass storage by referencing the second write cache.Executing the repositioning write commands involves buffering repositioning write data in the second write cache, but not in the first write cache, and offloading the repositioning write data from the second write cache to non-volatile mass storage.

[0066] In at least one embodiment, before completing the outsourcing of the host write data to the non-volatile mass storage, the controller sends an acknowledgment of the host write command to the host based on the host write data buffered in the first write cache.

[0067] In at least one embodiment, the non-volatile mass storage device comprises a flash memory, and the controller generates at least some of the repositioning write commands during memory cleanup in the flash memory.

[0068] 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 swapping of the host write data to the non-volatile mass storage.

[0069] In at least one embodiment, the controller records at least one first storage location of host write data in the first write cache in an entry of a logic-physical translation data structure. Based on the host write data being moved to non-volatile mass storage, the controller updates the entry to specify a different second storage location in the non-volatile mass storage.

[0070] In at least one embodiment, the controller additionally records a third storage location for host write data in the second write cache in the entry of the logic-physical translation data structure.

[0071] In at least one embodiment, the non-volatile mass storage device comprises the first write cache.

[0072] In at least one embodiment, the controller manages a plurality of buffers in the first write cache and in the second write cache, each of which corresponds to a plurality of different write heaps.

[0073] By reducing the bandwidth requirements on the non-volatile write cache to a single write operation per host write command under normal circumstances, the disclosed embodiments improve the design trade-off between the size of the non-volatile flash controller memory and its contribution to the cost of the data storage system. In particular, in some embodiments, the disclosed embodiments allow a certain number of write streams and sufficient write bandwidth to be maintained while reducing the size (and therefore the cost) of the non-volatile write cache. Alternatively, in other embodiments, additional write streams, which achieve higher performance, can be implemented at the same cost by using a certain size of non-volatile write cache.In other embodiments, a cost reduction can be achieved by implementing a larger number of write streams with the same total write bandwidth.

[0074] 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 media) containing computer-readable program instructions to induce a processor to execute aspects of the present invention.

[0075] A computer-readable storage medium can be a physical unit capable of retaining and storing instructions for use by an executing unit. For example, a computer-readable storage medium can be, but is not limited to, an electronic storage unit, a magnetic storage unit, an optical storage unit, an electromagnetic storage unit, a semiconductor storage unit, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, random-access memory (RAM), read-only memory (ROM), and erasable programmable read-only memory (EPROM).Flash memory), static random-access memory (SRAM), a portable CD-ROM, a DVD, a memory stick, a floppy disk, a mechanically encoded unit such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, shall not be understood as volatile signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses guided by an optical fiber cable), or electrical signals transmitted by a wire.

[0076] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to individual data processing units or, via a network such as the internet, a local area network, a wide area network, and / or a wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission lines, wireless transmission, routing computers, firewalls, switching units, gateway computers, and / or edge servers. A network adapter card or network interface in each data processing unit receives computer-readable program instructions from the network and forwards them for storage on a computer-readable storage medium within the respective data processing unit.

[0077] Computer-readable program instructions for executing work steps of the present invention may be assembly instructions, ISA (Instruction Set Architecture) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., as well as conventional procedural programming languages ​​such as the programming language "C" or similar programming languages.The computer-readable program instructions can be executed 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 the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, via the internet using an internet service provider).In some embodiments, electronic circuits, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), can execute the computer-readable program instructions by using state information from the computer-readable program instructions to personalize the electronic circuits to implement aspects of the present invention.

[0078] Aspects of the present invention are described herein with reference to illustrations of flowcharts and / or block diagrams of processes, devices (systems), and computer program products according to embodiments of the invention. It should be clear that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by means of computer-readable program instructions.

[0079] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or any other programmable data processing device to create a machine such that the instructions executed by the processor of the computer or other programmable data processing device will produce a means of implementing the functions / steps specified in the block(s) of the flowcharts and / or block diagrams.These computer-readable program instructions may also be stored on a computer-readable storage medium capable of controlling a computer, programmable data processing device and / or other units to function in a particular manner, such that the computer-readable storage medium on which instructions are stored has a manufactured product, including instructions that implement aspects of the function / step specified in the block(s) of the flowchart and / or block diagrams.

[0080] The computer-readable program instructions can also be loaded onto a computer, other programmable data processing device or other unit to cause a series of operations to be performed on the computer or other programmable device or other unit in order to produce a computer-implemented process such that the instructions executed on the computer, other programmable device or other unit implement the functions / steps specified in the block(s) of the flowcharts and / or block diagrams.

[0081] 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 context, each block in the flowcharts or block diagrams can represent a module, segment, or part of instructions that includes one or more executable instructions for implementing the specific logical function(s). In some alternative implementations, the functions specified in the block may occur in a different order than shown in the figures. For example, two blocks shown consecutively may actually be executed essentially in parallel, or the blocks may sometimes be executed in reverse order, depending on the functionality involved.It should also be noted that each block of the block diagrams and / or flowcharts, as well as combinations of blocks in the block diagrams and / or flowcharts, can be implemented by special hardware-based systems that perform the specified functions or actions, or execute combinations of special hardware and computer instructions.

[0082] Although the invention has been shown and described in particular with reference to one or more preferred embodiments, it will be clear to a person skilled in the art that various changes in form and detail can be made to it without deviating from the inventive concept and the scope of protection of the claims in the appendix. For example, although aspects relating to a data storage system comprising a flash controller that controls certain functions have been described, it should be clear that the present invention can alternatively be implemented as a program product comprising a storage unit that stores program code which can be processed by a processor to perform such functions or to cause such functions to be performed.As used herein, a “storage unit” is specifically defined to include only prescribed manufactured articles and to exclude transmission media per se, transitory propagation signals per se and forms of energy per se.

[0083] Although embodiments have been described which include the use of a NAND flash memory, it should also be clear 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.

[0084] The figures described above and the following written description of certain structures and functions are not provided to limit the scope of protection of what the applicants have invented or the scope of protection of the claims in the annex. Instead, the figures and the written description are provided to instruct any person skilled in the art in implementing and using the inventions for which patent protection is sought. It will be clear to the person skilled in the art that, for the sake of clarity and better understanding, not all features of an industrial embodiment of the inventions have been described or shown. It will also be clear to the person skilled in the art that the development of a current industrial embodiment incorporating aspects of the present inventions will require numerous implementation-specific decisions in order to achieve the developer's ultimate goal for the industrial embodiment.Such implementation-specific decisions may involve, and are likely not limited to, compliance with system-related, business-related, regulatory, and other constraints, which may vary depending on the specific implementation, location, and from time to time. While a developer's work may be complex and time-consuming in an absolute sense, such work would nevertheless be a routine procedure for a person skilled in the art who has the benefit of this disclosure. It must be clear that the inventions disclosed and taught herein are applicable to numerous and varied modifications and alternative forms. Finally, the use of a term in the singular, such as "a / an," is not intended to limit the number of elements.

Claims

[1] Method in a data storage system (120) which provides storage in a non-volatile mass storage device (150), wherein the method comprises: a controller of the data storage system (120) that receives a host write command and buffers associated host write data both in a first write cache (146a) in the non-volatile memory and in a mirrored second write cache (146b) in the volatile memory (806, 808); the controller that swaps the host write data from the second write cache (146b), but not from the first write cache (146a), to the non-volatile mass storage (150) (814); the controller that serves repositioning write commands that request a data repositioning in the non-volatile mass storage (150) by referencing the second write cache (146b), wherein serving includes buffering repositioning write data associated with the repositioning write commands in the second write cache (146b), but not in the first write cache (146a), and swapping (1006) the repositioning write data from the second write cache (146b) to the non-volatile mass storage (150); the controller, which records in an entry of a logic-physical translation data structure a first storage location of host write data in the first write cache (146a) and a second storage location of host write data in the second write cache (146b); and the controller, which, based on the offloading of the host write data to the non-volatile storage (150), updates the entry to specify a different third storage location in the non-volatile storage (150). [2] The method of claim 1, further comprising: prior to completion of the offloading of the host write data to the non-volatile mass storage (150), sending, by the controller, an acknowledgment of the host write command to a host based on the host write data buffered in the first write cache (146a). [3] Method according to claim 1, wherein: the non-volatile mass storage includes flash memory; and The procedure includes the controller that generates at least some of the repositioning write commands during a memory cleanup in the flash memory. [4] The method of claim 1, further comprising: the controller which releases the host write data of the host write command in the first write cache (146a) based on the completion of swapping the host write data to the non-volatile mass storage (150). [5] Method according to claim 1, wherein the non-volatile mass storage comprises the first write cache (146a). [6] The method of claim 1, further comprising: the controller which manages a plurality of buffers in each of the first write cache (146a) and the second write cache (146b), each of which corresponds to a respective of a plurality of different heaps. [7] Data storage system (120) which features: a controller of a non-volatile mass storage device (150)s, wherein the controller is configured to perform: a receiving (802) of a host write command and a buffering (806, 808) of associated host write data both in a first write cache (146a) in non-volatile memory and in a mirrored second write cache (146b) in volatile memory; of offloading (814) the host write data from the second write cache (146b), but not from the first write cache (146a), to the non-volatile mass storage (150); of servicing repositioning write commands that request a data repositioning in the non-volatile mass storage (150) by referencing the second write cache (146b), wherein the servicing includes buffering repositioning write data associated with the repositioning write commands in the second write cache (146b), but not in the first write cache (146a), and swapping (1006) the repositioning write data from the second write cache (146b) to the non-volatile mass storage (150); a recording, in an entry of a logic-physical translation data structure, a first storage location of host write data in the first write cache (146a) and a second storage location of host write data in the second write cache (146b); and Based on the offloading of host write data to non-volatile storage (150), update the entry to specify a different third storage location in the non-volatile storage (150). [8] Data storage system (120) according to claim 7, wherein the controller is further configured to perform: a sending, prior to completion of swapping the host write data to the non-volatile mass storage (150), an acknowledgment of the host write command to a host based on the host write data buffered in the first write cache (146a). [9] Data storage system (120) according to claim 7, wherein: the non-volatile mass storage includes flash memory; and The controller is further configured to generate at least some of the repositioning write commands during a memory cleanup in the flash memory. [10] Data storage system (120) according to claim 7, wherein the controller is further configured to perform: of a release, in the first write cache (146a), the host write data of the host write command based on the completion of the swapping of the host write data to the non-volatile mass storage (150). [11] Data storage system (120) according to claim 7, further comprising the non-volatile mass storage device (150), wherein the non-volatile mass storage device comprises the first write cache (146a). [12] Data storage system (120) according to claim 7, wherein the controller is further configured to perform: of managing, in each of the first write cache (146a) and the second write cache (146b), a plurality of buffers, each of which corresponds to a respective of a plurality of different heaps. [13] Program product that features: a storage unit; and Program code that is stored in the memory unit and can be executed by a controller of a non-volatile mass storage device (150) to cause the controller to perform: a receiving (802) of a host write command and a buffering (806, 808) of associated host write data both in a first write cache (146a) in non-volatile memory and in a mirrored second write cache (146b) in volatile memory; of offloading (814) the host write data from the second write cache (146b), but not from the first write cache (146a), to the non-volatile mass storage (150); of servicing repositioning write commands that request a data repositioning in the non-volatile mass storage (150) by referencing the second write cache (146b), wherein the servicing includes buffering repositioning write data associated with the repositioning write commands in the second write cache (146b), but not in the first write cache (146a), and swapping (1006) the repositioning write data from the second write cache (146b) to the non-volatile mass allocation storage; a recording, in an entry of a logic-physical translation data structure, a first storage location of host write data in the first write cache (146a) and a second storage location of host write data in the second write cache (146b); and Based on the offloading of host write data to non-volatile storage (150), update the entry to specify a different third storage location in the non-volatile storage (150). [14] Program product according to claim 13, wherein the program code causes the controller to perform: a sending, prior to completion of swapping the host write data to the non-volatile mass storage (150), an acknowledgment of the host write command to a host based on the host write data buffered in the first write cache (146a). [15] Program product according to claim 13, wherein: the non-volatile mass storage includes flash memory; and The program code causes the controller to generate at least some of the repositioning write commands during a memory cleanup in the flash memory. [16] Program product according to claim 13, wherein the program code causes the controller to perform: a release, in the first write cache (146a), the host write data of the host write command based on the completion of a swap of the host write data to the non-volatile mass storage (150). [17] Program product according to claim 13, wherein the non-volatile mass storage comprises the first write cache (146a). [18] Program product according to claim 13, wherein the program code causes the controller to perform: of managing, in each of the first write cache (146a) and the second write cache (146b), a plurality of buffers, each of which corresponds to a respective of a plurality of different heaps.

Images