Wear-aware block mode switching in nonvolatile memories

Abstract

A non-volatile memory includes a plurality of physical storage blocks, each physical storage block including a corresponding plurality of cells, wherein each cell in the plurality of cells is capable of individually storing multiple bits of data. A controller allocates physical blocks among the plurality of physical blocks to a first pool containing physical blocks operating in a first (e.g., QLC) mode for storing a larger number of bits per cell, and allocates other physical blocks among the plurality of physical blocks to a second pool containing physical blocks operating in a second (e.g., SLC) mode for storing a smaller number of bits per cell. The controller transfers the physical blocks between the first pool and the second pool based at least on a bit error rate measured for the transferred physical blocks.

Description

Technical Field

[0001] The present invention relates to data processing and data storage, and more particularly to a non-volatile memory system in which blocks are capable of operating in multiple block modes providing different storage capacities per bit per cell. More particularly, the present invention relates to wear-aware switching of physically stored blocks in a non-volatile memory system between different block modes. Background Art

[0002] NAND flash memory is an electrically programmable and erasable non-volatile memory technology that stores one or more data bits for each memory cell as a charge on a floating gate of a transistor or similar charge trap structure. The amount of charge on the floating gate modulates the threshold voltage of the transistor. By applying an appropriate read voltage and measuring the amount of current, the programming threshold voltage of the memory cell can be determined, and the stored information can be detected. In a typical implementation, a NAND flash array is organized in blocks of physical memory (also called "erase blocks"), each block includes multiple physical pages, and each physical page in turn contains multiple memory cells. With the arrangement of words and bit lines used to access memory cells, flash arrays are usually programmed on a page basis, but erased on a block basis.

[0003] Over the past decade, there has been a phenomenal increase in the bit storage density of flash storage technology, driven by the goal of reducing the price per gigabyte of flash memory. One of the key drivers of this trend has been the steady increase in the number of bits stored per flash cell. For example, the number of bits that can be stored per flash cell has steadily increased from one (single-level cell (SLC)) to two (multi-level cell (MLC)) to three (triple-level cell (TLC)) and most recently to four (quadruple-level cell (QLC)). The increase in the number of bits that can be stored per flash cell comes at the expense of reduced endurance and performance as the number of bits per cell increases.

[0004] Enterprise-class flash memory controllers employ various techniques to improve the endurance and performance limits of new generation NAND flash memory. For example, a flash memory controller may employ one or more flash memory management techniques, including implementing advanced error correction codes, adjusting voltage levels to reduce bit error rates, reducing internal garbage collection overhead by isolating data based on write heat, managing blocks on a block basis (i.e., health grading), and performing health-aware wear leveling and data placement. Although these advanced flash memory management techniques extend life and improve performance, as bit density continues to grow, existing flash memory management techniques alone cannot guarantee acceptable device life (e.g., a 7-year or longer warranty for enterprise-class SSDs under heavy write workloads). For example, QLC NAND flash memory technology has a 33% increase in storage density compared to TLC NAND flash memory technology, but its rated life is several times shorter than TLC NAND flash memory (e.g., only thousands of program / erase (P / E) cycles per block).

[0005] One promising approach to improving device endurance is to exploit the ability of NAND flash to operate in multiple modes. For example, some TLC NAND flash memories support SLC mode, in which certain selected blocks store only a single bit per cell, thereby improving the performance and endurance of selected blocks at the expense of storage density. Blocks configured in SLC mode can sustain one to two orders of magnitude more P / E cycles, but only provide one-third of the storage capacity of blocks configured in TLC mode. In such a system, frequently written data can be stored in SLC blocks, while infrequently written data can be stored on blocks operating in native TLC mode.

[0006] Existing flash memory controllers that support multiple modes of operation typically employ a tiered architecture in which incoming user writes are first stored in blocks in a lower storage density tier (e.g., an SLC tier). When storage in the lower storage density tier is exhausted (or reaches some other threshold fill level), the flash memory controller initiates a dump process to free up space in the lower storage density tier by transferring data from the lower storage density tier to a higher storage density tier (e.g., a TLC tier)—preferably starting with data that is most likely to be overwritten in the future. The flash memory controller then manages the data residing in the higher storage density tier in a conventional manner, such as by periodically relocating valid data in blocks selected for garbage collection, erasing the garbage collected blocks, and then writing the erased blocks again with data dumped from the lower storage density tier. Typically, in this type of conventional tiered storage architecture, blocks are statically assigned to either a lower density storage tier or a higher storage density tier. Summary of the invention

[0007] The present invention recognizes that a completely static assignment of blocks to various tiers of a multi-tier memory storage system employing blocks of different bit storage densities may cause a given tier to prematurely exhaust its storage capacity or reach its endurance limit. To address this problem, blocks of non-volatile memory may be selectively transitioned between operating modes.

[0008] In one aspect of the present invention, a method for operating a non-volatile memory including a plurality of physical storage blocks each including a corresponding plurality of cells is provided, wherein each of the plurality of cells is capable of individually storing multi-bit data, the method comprising: a controller allocating physical blocks among the plurality of physical blocks to a first pool, the first pool containing physical blocks operating in a first mode (e.g., QLC mode) for storing a larger number of bits per cell, and allocating other physical blocks among the plurality of physical blocks to a second pool, the second pool containing physical blocks operating in a second mode (e.g., SLC mode) for storing a smaller number of bits per cell.

[0009] In at least one embodiment, the controller transfers physical blocks with higher bit error rates from the first pool to the second pool, and transfers physical blocks with lower bit error rates from the second pool to the first pool.

[0010] In at least one embodiment, for each of the first and second pools, the controller tracks the number of physical blocks allocated to store data for each of a plurality of write streams of different write temperatures and the number of program / erase (P / E) cycles in each of the plurality of write streams. Additionally, for each of the plurality of write streams, the controller calculates a corresponding stream wear metric based on the number of physical blocks allocated to the write stream and the total number of P / E cycles for the physical blocks allocated to the write stream. The controller may then select a physical block for transfer based on: (1) a selected write stream of the plurality of write streams, (2) a stream wear metric for the selected write stream, and (3) a block health of the physical blocks allocated to store data for the selected write stream. For example, the block health of the physical blocks in all of the plurality of write streams may be determined based on a bit error rate measured shortly after the physical blocks are programmed.

[0011] In at least one embodiment, the controller selects the physical block for transfer such that if the selected write stream has a stream wear metric that reflects the maximum wear among all write streams of the multiple write streams, the controller selects the healthiest physical block from among the physical blocks assigned to the selected write stream for transfer, and if the selected write stream has a stream wear metric that reflects the minimum wear among all write streams of the multiple write streams, the controller selects the unhealthiest physical block from among the physical blocks assigned to the selected write stream for transfer.

[0012] In at least one embodiment, the controller transfers physical blocks between the first pool and the second pool based on an available number of unprogrammed physical blocks in a given pool of the first pool and the second pool not satisfying a threshold. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0014] Figure 1B yes Figure 1A A more detailed block diagram of a flash memory card of a data storage system;

[0015] Figure 2 An exemplary NAND flash memory module according to one embodiment is shown;

[0016] Figure 3 is a high-level flow chart of flash management functions and data structures employed in flash management according to one embodiment;

[0017] Figure 4 An exemplary tiered storage architecture is shown in which a pool of physical blocks is configured to operate in different modes, thereby storing different numbers of bits per cell;

[0018] Figure 5 is a graph of write amplification versus device utilization for an exemplary tiered storage architecture;

[0019] Figure 6 is a high-level logic flow diagram of an exemplary process for configuring non-volatile memory according to one embodiment; and

[0020] Figure 7 is a high-level logical flow diagram of an exemplary process for dynamically transferring chunks between chunk pools, according to one embodiment. DETAILED DESCRIPTION

[0021] With reference to the accompanying drawings, in particular Figure 1A, shows a high-level block diagram of an exemplary data processing environment 100, which includes a data storage system 120 having a non-volatile memory array 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 that process instructions and data. The processor system 102 may additionally include a local storage 106 (e.g., a dynamic random access memory (DRAM) or a disk), which may store program code, operands, and / or execution results of the processing performed by the processor 104. In various embodiments, the processor system 102 may be, for example, a mobile computing device (such as a smart phone or tablet computer), a laptop or desktop personal computer system, a server computer system (such as one of the POWER series servers available from International Business Machines Corporation), or a mainframe computer system. The processor system 102 may also be an embedded processor system using a different processor (such as ARM, POWER, Intel x86), or any other processor in any combination with a memory cache, a memory controller, a local storage, an I / O bus hub, etc.

[0022] Each processor system 102 further includes an input / output (I / O) adapter 108 coupled to a data storage system 120 via an I / O channel 110, directly (i.e., without any intermediary device) or indirectly (i.e., through at least one intermediary device). In some embodiments, the data storage system 120 may be integrated into the processor system 102. In various embodiments, the I / O channel 110 may employ any one or a combination of known or future developed communication protocols, including, for example, Fibre Channel (FC), FC over Ethernet (FCoE), Internet Small Computer System Interface (iSCSI), InfiniBand, Transfer Control Protocol / Internet Protocol (TCP / IP), Peripheral Component Interconnect Express (PCIe), etc. I / O requests communicated via the I / O channel 110 include read requests by the processor system 102 requesting data from the data storage system 120 and write requests by the processor system 102 requesting data to be stored in the data storage system 120.

[0023] Although not required, in the illustrated embodiment, the data storage system 120 includes a plurality of interface cards 122 through which the data storage system 120 receives and responds to I / O requests from the host via the I / O channel 110. Each interface card 122 is coupled to each of a plurality of redundant array of inexpensive disks (RAID) controllers 124 to facilitate fault tolerance and load balancing. Each RAID controller 124 is in turn coupled (e.g., via a PCIe bus) to a non-volatile storage medium that includes a plurality of flash memory cards 126 carrying NAND flash memory in the illustrated example. In other embodiments, alternative and / or additional non-volatile storage devices may be employed.

[0024] In the illustrated embodiment, operation of data storage system 120 is managed by a redundant system management controller (SMC) 123 coupled to interface card 122 and RAID controller 124. In various embodiments, system management controller 123 may be implemented using hardware or hardware executing firmware and / or software.

[0025] Figure 1B Show Figure 1A 1. A more detailed block diagram of an exemplary embodiment of a flash memory card 126 of a data storage system 120 of FIG. 1. The flash memory card 126 includes a gateway 130 that acts as an interface between the flash memory 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 program code) to perform pre-processing of requests received by the gateway 130 and / or schedule the servicing of the requests by the flash card 126. The GPP 132 is coupled to a GPP memory 134 (e.g., dynamic random access memory (DRAM)), which can conveniently buffer data created, referenced, and / or modified by the GPP 132 during its processing or data flowing through the gateway 130 to one or more of the flash controllers 140.

[0026] The gateway 130 is also coupled to a plurality of flash controllers 140, each of which controls a respective NAND flash memory system 150. The flash controllers 140 may be implemented, for example, by an application specific integrated circuit (ASIC) and / or a field programmable gate array (FPGA) and / or a microprocessor, and each has an associated flash controller memory 142 (e.g., DRAM). In an embodiment where the flash controllers 140 are implemented using FPGAs, the GPP 132 may program and configure the flash controllers 140 during boot-up of the data storage system 120. After boot-up, in general, the flash controllers 140 receive read and write requests from the gateway 130 requesting to read data stored in the NAND flash memory system 150 and / or to store data in the NAND flash memory system 150. The flash controllers 140 service these requests, for example, by accessing the NAND flash memory system 150 to read the requested data from the NAND flash memory system 150 or to write the requested data to the NAND flash memory system 150 or by accessing a memory cache (not shown) associated with the NAND flash memory system 150.

[0027] Flash controller 140 implements a flash translation layer (FTL) that provides logical to physical address translation to enable access to specific memory locations within NAND flash memory system 150. Typically, a request received by flash controller 140 from a host device (such as processor system 102) contains a logical block address (LBA) of data to be accessed (read or written) and, if a write request, contains write data to be stored in data storage system 120. The request may also specify the amount (or size) of data to be accessed. Other information may also be transmitted depending on the protocols and features supported by data storage system 120. The flash translation layer converts the LBA received from RAID controller 124 into a physical address assigned to a corresponding physical location in NAND flash memory system 150. Flash controller 140 may perform address translation and / or store the mapping between logical addresses and physical addresses in a logical to physical translation data structure (such as a logical to physical translation table (LPT)), which may be conveniently stored in flash controller memory 142.

[0028] In various embodiments, NAND flash memory system 150 may take many forms. Figure 1BIn the illustrated embodiment, each NAND flash memory system 150 includes a plurality (e.g., 32) of individually addressable NAND flash memory storage devices 152. In the illustrated example, the flash memory storage devices 152 take the form of on-board flash memory modules, such as multi-level cell (MLC), triple-level cell (TLC), or quad-level cell (QLC) NAND flash memory modules. The effective storage capacity provided by the flash memory storage devices 152 can be increased by, for example, implementing data compression by the flash memory controller 140 and / or a higher-level controller (such as GPP 132, RAID controller 124, or SMC 123).

[0029] See now Figure 2 , depicting the Figure 1B 1 is a block diagram of an exemplary flash memory module 200 for any one of the NAND flash memory storage devices 152 of FIG. The flash memory module 200 includes one or more memory chips, each memory chip implementing at least one memory array 202 formed by a two-dimensional or three-dimensional array of NAND flash memory cells. Figure 2 As shown, the memory cells within the memory array 202 are physically arranged in a plurality of physical blocks 204, each of which in turn includes a plurality of physical pages 206. These pages can be managed in page groups, which can each be formed, for example, by all pages coupled to a common word line, by all pages in one or more layers in a 3D NAND flash memory, by a group of pages in one or more layers, or generally by pages having similar characteristics.

[0030] As is known to those skilled in the art, NAND flash memory, such as that employed in memory array 202, must be erased before being programmed. Further, NAND flash memory may (but need not) be constrained by its construction such that the smallest storage granularity that can be erased is block 204, and the smallest storage granularity that can be accessed by a read or write request is fixed at the size of a single physical page 206. In this regard, it should be understood that the LBA provided by the host device corresponds to a logical page within a logical address space, where each logical page typically has a size of 4 kilobytes (kB). In contrast, physical page 206 typically has a larger size, such as 16kB, and can therefore host multiple logical pages.

[0031] The flash memory module 200 also includes a row decoder 210 and a column decoder 212, through which the word lines of the memory array 202 can be addressed, and through which the bit lines of the memory array 202 can be addressed. In addition, the flash memory module 200 includes a read / write circuit 214 that enables the memory cells of the physical page 206 to be programmed or read in parallel. The flash memory controller 200 also includes a control circuit 205, which provides chip-level control of the operation of the memory array 202, including read and write access to the physical pages 206 in the memory array 202, erasure of the blocks 204, and the magnitude, duration, and polarity of the associated voltages applied to the memory array 202.

[0032] Having described the general physical structure of an exemplary embodiment of data storage system 120, now refer to Figure 3 describe certain operational aspects of data storage system 120, Figure 3 is a high-level flow diagram of flash management functions and data structures employed by GPP 132 and / or flash controller 140 according to one embodiment.

[0033] The data storage system 120 generally does not allow external devices (e.g., a host) to directly address and / or access physical memory locations within the NAND flash memory system 150. Instead, the data storage system 120 is typically configured to present one or more logical volumes to a host device, each logical volume having a contiguous logical address space, thereby allowing the host device to read data to and write data from logical block addresses (LBAs) within the logical address space, while allowing one or more of the different levels of controllers (e.g., the system management controller 123, the RAID controller 124, the flash controller 140, and the GPP 132) to control where data associated with different LBAs actually resides in the physical memory locations comprising the NAND flash memory system 150. In this way, the performance and life of the NAND flash memory system 150 can be intelligently managed and optimized.

[0034] In the illustrated embodiment, each flash controller 140 performs logical to physical address translation for an associated set of LBAs using a logical to physical address translation data structure, such as a logical to physical translation (LPT) table 300, which may be stored, for example, in an associated flash controller memory 142. It should be noted that the logical addresses provided to the flash controller 140 may be different than the logical addresses originally provided to the data storage system 120, as various components within the data storage system 120 may perform address translation operations between external devices and the flash controller 140.

[0035] The flash management code running on the GPP 132 keeps track of the erased blocks of the NAND flash system 150 that are ready to be used in a ready-to-use (RTU) queue 306, which may be stored, for example, in the GPP memory 134. In the illustrated embodiment, the flash management code running on the GPP 132 maintains one RTU queue 306 per channel or plane (i.e., per data bus), and the identifier of each erased block to be reused is queued in the RTU queue 306 corresponding to its channel or plane. In addition, separate RTU queues 306 may be maintained for different health levels, hot bins / write streams, or block operation modes (i.e., SLC or QLC operation modes). The build block stripe function 320 performed by the flash management code running on the GPP 132 builds a new block stripe for storing data and associated parity information from the erased blocks queued in the RTU queue 306. The new block stripe is then queued in the flash controller 140 for data placement. Block stripes are preferably formed from blocks residing in different channels, which means that the build block stripe function 320 can conveniently build a block stripe by pulling each block of the new block stripe from a different RTU queue 306. In general, the build block stripe function 320 attempts to build stripes with blocks of approximately equal health (i.e., expected remaining useful life).

[0036] In response to a write request received from a host such as the processor system 102, the data placement function 310 of the flash controller 140 determines, by reference to the LPT table 300, whether the target LBA indicated in the write request is currently mapped to a physical memory page in the NAND flash memory system 150, and, if so, changes the state of each data page currently associated with the target LBA to indicate that the associated data is no longer valid. In addition, if necessary, the data placement function 310 also allocates a page stripe to store the write data of the write request and, if any, any unupdated data of the existing page stripe that is the target of the write request (i.e., for write requests smaller than a logical page, the remaining valid data from a previous write to the same logical address that has not been overwritten and must be processed in a read-modify-write manner), and / or stores the write data of the write request and, if any, any unupdated (i.e., still valid) data of the existing page stripe that is the target of the write request to the remaining allocated page stripe with free space. The page stripe may be allocated from a block stripe that has already been allocated to store data or from a new block stripe built by the build block stripe function 320. In a preferred embodiment, the page stripe allocation may be based on the health of the blocks available for allocation and the "hotness" of the LBAs to which the data is written (i.e., the estimated or measured write access frequency). The data placement function 310 then writes the write data, associated metadata (e.g., cyclic redundancy code (CRC) and error correction code (ECC) values), and parity information for the page stripe to the allocated page stripe. The flash controller 140 also updates the LPT table 300 to associate the physical page used to store the write data with the LBA indicated by the host device. Thereafter, the flash controller 140 may access the data by referencing the LPT table 300 to service a host read request, such as Figure 3 As further shown in .

[0037] Once all pages in a block stripe have been written, the flash controller 140 places the block stripe into one of the occupied block queues 302, which the flash management code running on the GPP 132 uses to facilitate garbage collection. As described above, through the write process, pages are invalidated, and therefore portions of the NAND flash memory system 150 become unused. The associated flash controller 140 (and / or GPP 132) will eventually need to reclaim this space through garbage collection performed by the garbage collector 312. The garbage collector 312 selects a particular block stripe for garbage collection based on a number of factors, including, for example, the health of the blocks 204 within the block stripe, and how much data within the erase block 204 is invalid. In the example shown, garbage collection is performed on the entire block stripe, and the flash management code running on the GPP 132 records the block stripes that are ready to be recycled in the relocation queue 304, which can be conveniently implemented in the associated flash controller memory 142 or GPP memory 134.

[0038] The flash management functions performed by the GPP 132 or flash controller 140 additionally include a relocation function 314 that relocates data stored in block stripes queued in the relocation queue 304. To relocate such data, the relocation function 314 issues a relocation write request to the data placement function 310 to request that valid data of the old block stripe be written to a new block stripe in the NAND flash memory system 150. In addition, the relocation function 314 updates the LPT table 300 to disassociate the current association between the logical address and the physical address of the data. Once all remaining valid data has been transferred from the old block stripe, the old block stripe is passed to the decompose block stripe function 316, which decomposes the old block stripe into its constituent blocks 204, thereby disassociating the blocks 204. Each of the blocks 204 that previously formed the resolved block stripe is then erased, under the direction of the flash controller 140 and / or control circuitry 205 of the associated flash module 200, and a corresponding program / erase (P / E) cycle count 334 is incremented for each erased block. Based on a health metric 332 of each erased block 204 (e.g., a bit error rate (BER) metric, uncorrectable errors, P / E cycle count, etc.), each erased block 204 is either retired (i.e., retired from use) by a block retirement function 318 among the flash management functions executed on the GPP 132, or alternatively, is prepared for reuse by placing an identifier of the block 204 on an appropriate ready-to-use (RTU) queue 306 in the associated GPP memory 134.

[0039] like Figure 3As further shown in FIG. 1 , the flash management functions executed on the GPP 132 and / or the flash controller 140 additionally include a background health checker 330. The background health checker 330, which operates independently of read and write requests from a host (such as the processor system 102), continuously determines one or more block health metrics 332 for blocks belonging to the block stripes recorded in the occupied block queue 302. Based on one or more of the block health metrics 332, the background health checker 330 places the block stripes on the relocation queue 304 for processing by the relocation function 314. The key block health metrics 332, preferably monitored and recorded by the background health checker, relate to bit error rate (BER) metrics observed for valid blocks and physical pages, and may include, for example, the worst page BER per block, the average page BER per block, the rate of change of the worst page BER and the average page BER per block, etc. In order to obtain the most accurate health estimate possible, health may be determined by analyzing both valid and invalid data, thereby ensuring that blocks containing substantially all invalid data are fully analyzed to determine overall block health.

[0040] One function of GPP 132 and / or flash controller 140 that may be incorporated into background health checker 330 or may be implemented separately is the periodic adaptation (calibration) of read voltage thresholds 336 used to decode data bits stored in memory cells of memory array 202. These read voltage thresholds 336 may be individually defined to any desired level of granularity (e.g., per page, per group of pages within a block, per block, etc.), preferably selected to improve one or more bit error rate metrics. As described in Figure 3 As further described in , GPP 132 and / or flash controller 140 preferably tracks additional statistics to facilitate intelligent adaptation of read voltage thresholds 336. These additional statistics may include, for example, a P / E cycle count 334 identifying the number of program / erase cycles each block has undergone, and a read count 338 indicating the number of times a given memory cell (e.g., page, page group, and / or block) has been read since being programmed. In addition, these statistics may include calibration triggers 340, such as a per-memory cell counter indicating the amount of time that has passed since the read voltage threshold for that memory cell was adapted and / or a per-block counter indicating the number of program / erase cycles each block has undergone since the read voltage threshold for that block was last adapted.

[0041] See now Figure 4, illustrates an exemplary storage architecture that may be implemented in a non-volatile memory device. In this example, the GPP 132 and / or the flash controller 140 (collectively referred to herein as the "controller") configure some or all of the flash storage devices 152 in the NAND flash memory system 150 to implement multiple pools of physical blocks 204, wherein the physical blocks 204 in different block pools are configured to operate in different modes storing different numbers of bits per cell. Thus, in this example, although the entirety of the memory array 202 includes, for example, QLC flash memory capable of storing four bits per cell, the controller assigns some of the physical blocks 204 in the memory array 202 of the flash memory device 152 to a QLC pool 400 in which fully programmed blocks store four bits per cell, and assigns other physical blocks 204 of the memory array 202 to an SLC pool 402 in which fully programmed blocks store only a single bit per cell. For example, pool membership information may be stored in the GPP memory 124 and / or the flash controller memory 142 as block mode metadata 335. As described above, if frequently written LBAs are mapped to physical blocks 204 within the SLC pool 402, operating the blocks in a variety of different modes in this manner may provide improved performance and / or endurance.

[0042] Although not required, in some embodiments, the controller organizes the QLC pool 400 and the SLC pool 402 in a hierarchical arrangement, wherein data contained in a host write request is first written to a physical block 204 selected from the SLC pool 402, as indicated by arrow 404. As the SLC pool 402 fills through usage and more capacity is needed and / or desired in the SLC pool 402, the controller dumps the data from the SLC pool 402 to the QLC pool 400 via relocation writes, as indicated by arrow 406. In order to ensure an adequate supply of physical blocks 204 in both block pools 400 and 402 as the blocks experience wear, the controller additionally transfers (reallocates) blocks 204 between pools 400 and 402 as needed and / or desired to provide storage capacity and / or endurance. The transfer of physical blocks 204 (as opposed to data) between block pools 400 and 402 is performed in a hierarchical manner. Figure 4 4 is depicted by arrow 408.

[0043] The present disclosure recognizes that the process of transferring blocks between block pools 400 and 402, if not carefully designed, may adversely result in reduced performance (due to increased error recovery activity), or even data loss in the event of an unsuccessful error recovery (e.g., if a block with a high bit error rate is transferred from block pool 402 to block pool 400). Generally speaking, the controller transfers blocks between block pools 400 and 402 by selecting less healthy / least healthy blocks from block pool 400 to transfer to block pool 402 and by selecting healthier / healthiest blocks from block pool 402 to transfer to block pool 400.

[0044] The present disclosure recognizes that this mode switching strategy, while suitable for some systems, is suboptimal in systems that employ thermal isolation or have very high device utilization, which can directly lead to accelerated wear and even premature device retirement. One reason for these negative effects is that the wear of blocks 204 in the QLC pool 400 (e.g., measured in average P / E cycles) can be generally much higher than the wear of blocks 204 in the SLC pool 402 under certain conditions, which is due in part to write amplification. Figure 5 Yes Figure 4 . As shown in the figure, at high device utilization (e.g., when more than 90% of the flash memory devices are written to data), the write amplification of the QLC pool 400 will increase exponentially, resulting in faster and faster wear of the blocks in the QLC pool 400. As discussed in more detail below, therefore, the mode transition strategy preferably takes block wear into account when selecting blocks to transfer between block pools.

[0045] See now Figure 6 , depicts a high-level logic flow diagram of an exemplary process for configuring non-volatile memory according to one embodiment. The process shown may be performed, for example, by a controller (e.g., GPP 132 and / or flash controller 140) in hardware, firmware, software, or a combination thereof, at startup of data storage system 120. As with other logic flow diagrams presented herein, the operations are presented in a logical rather than a strict chronological order, and in some embodiments, the operations may be performed in a different order than presented or simultaneously.

[0046] Figure 6 The configuration process begins at block 600 and then proceeds to block 602, which shows the controller of the flash device 152 configuring the desired number of block pools. Figure 4 In the example of FIG. 6 , the controller implements two block pools at block 602, namely, the QLC block pool 400 and the SLC block pool 402. In other embodiments, a larger number of block pools and / or block pools operating in different block modes (e.g., TLC or MLC) may be implemented. The controller also allocates an initial number of physical blocks 204 to each block pool and records the corresponding block mode of each physical block 204 in the block mode metadata 335 based on the block pool membership of each physical block 204.

[0047] The process proceeds from block 602 to block 604, which illustrates the controller processing a processing loop for each block pool implemented at block 602. If the controller determines at block 604 that not all block pools have been processed, the process passes to block 610, which illustrates the controller selecting the next block pool to be processed (e.g., QLC pool 400 or SLC pool 402). At block 612, the controller then configures the desired number of health levels for the blocks 204 belonging to the selected block pool. In various embodiments, the number of health levels may vary, but a number of health levels between two and eight (inclusive) has been experimentally found to be effective. For example, in Figure 4 In one embodiment depicted in FIG, the controller configures four health levels 410a-410d or 412a-412d at box 612. The health levels employed herein are specifically defined as being based on at least one criterion other than just the number of program / erase (P / E) cycles, e.g., one or more bit error rate metrics for each block of physical memory (and / or physical pages within each block). For example, in one embodiment, the different health levels are defined by corresponding ranges of worst page BERs determined within a small number of read accesses after programming, because this bit error rate metric accurately reflects the permanent effects of wear on the block. Based on the measured worst page BER, the healthiest block is the block with the lowest worst page BER shortly after programming, and the unhealthiest block is the block with the highest worst page BER shortly after programming.

[0048] At box 614, the controller also configures the desired number of hot bins for the LBAs served by the flash storage device 152. Each hot bin corresponds to a corresponding range of write heat (i.e., write frequency) of the LBA. In various embodiments, the number of hot bins can vary, but it has been experimentally found that the number of hot bins is between two and eight (inclusive) to be effective. For example, in one embodiment, the controller configures four hot bins at box 614, corresponding to the hot LBAs that are written most frequently, the warm LBAs that are written less frequently, the cool LBAs that are written even less frequently, and the cold LBAs that are written least frequently. A group of host write requests targeting LBAs within a given hot bin is referred to herein as a "write stream." The number of hot bins (and therefore write streams) configured at box 614 can be equal to, but need not be equal to, the number of health levels configured at box 612.

[0049] At box 616, the controller establishes a mapping between the hot bins configured at box 612 and the health levels configured at box 614. In a particularly preferred embodiment, heat and health are directly related, where the hottest LBAs are mapped to the healthiest levels and the coldest LBAs are mapped to the less healthy levels. Of course, in other embodiments, other mappings between write heat and health levels may be used. For example, in an embodiment that employs digital write heat and health levels, the mapping established at box 616 is determined by a mathematical function selected to produce an approximately constant result (e.g., C≈f(hot, healthy)) from the health level and write heat mapped to each other. In another embodiment, the mapping from write heat to health level maps each hot bin to a sorted priority list of health levels. When creating a block stripe from blocks in the RTU queues 306, there may be no blocks with a given health level in the preferred RTU queue 306. The sorted priority list allows allocation of blocks from another RTU queue 306 with a health level as close as possible to the preferred RTU queue.

[0050] After block 616, Figure 6 The configuration process given in returns to block 604. If a negative determination is made at block 604, indicating that there are still one or more other block pools to be processed, the process returns to blocks 610-616, which have been described. However, if it is determined at block 604 that all block pools configured at block 602 have been processed, then Figure 6 The configuration process ends at box 606.

[0051] See now Figure 7 , shows a high-level logic flow diagram of an exemplary process for dynamically transferring blocks between block pools according to one embodiment. The process shown can be performed by a controller (e.g., GPP 132 and / or flash controller 140) in hardware, firmware, software, or a combination thereof when the data storage system 120 is started.

[0052] Figure 7The process begins at 700 and then proceeds to block 702, which shows the controller determining whether to resize one of the block pools 400 and 402. For example, the controller may determine whether to resize a given block pool based on one or more criteria, including: a fill level of blocks belonging to a given block pool within one or more RTU queues 306 failing to meet a threshold; a fill level of blocks belonging to another block pool within one or more RTU queues 306; a P / E cycle count of blocks within a given block pool; a number of blocks within a given block pool that are assigned one or more health levels, etc. The determination made at block 702 may be triggered, for example, by one or more of the background health checker 330, the garbage collector 312, the block retirement function 318, and / or the building block stripe function 320. In response to the controller determining at block 702 not to resize the block pool, the process repeats at block 702. In response to determining at block 702 that the block pool is to be resized, the process proceeds to block 704.

[0053] Box 704 shows the controller selecting a block pool to which the physical block 204 will be transferred. Additionally, at box 706, the controller selects a hot bin or write stream (e.g., hot, warm, cool, or cold) to which the physical block 204 will be added to a given block pool. The controller then determines, at box 708, a stream wear metric for the blocks 204 currently allocated to store data associated with the LBAs in the selected hot bin. In a preferred embodiment, the controller tracks the blocks 204 allocated to each hot bin / write stream and determines (e.g., from the P / E cycle count 334) the total number of P / E cycles those blocks 204 have experienced. Based on these numbers, the controller can calculate the stream wear metric for the selected hot bin as the total number of blocks 204 storing data in the hot bin divided by the total number of P / E cycles those blocks 204 have experienced.

[0054] Based on the stream wear metric determined at box 708, the controller then selects at least one unprogrammed block 204 from the other block pools to be transferred to the selected block pool that has a single block health suitable for the selected hot bin (box 710). This selection ensures that the healthiest blocks 204 will experience the highest number of future P / E cycles and the least healthy blocks 204 will experience the fewest number of future P / E cycles. As a result, device endurance is improved for all types of workloads and all device utilization points. At box 712, the controller transfers the block 204 selected at box 710 to the selected block pool, updates the block mode metadata 335 with the new operating mode (e.g., QLC or SLC), and, if necessary, updates the block health level. Thereafter, Figure 7 The process returns to block 702, which has already been described.

[0055] As has been described, in at least one embodiment, a non-volatile memory includes a plurality of physical storage blocks, each physical storage block including a corresponding plurality of cells, wherein each of the plurality of cells is capable of storing multiple bits of data individually. A controller allocates physical blocks among the plurality of physical blocks to a first pool containing physical blocks operating in a first (e.g., QLC) mode for storing a larger number of bits per cell, and allocates other physical blocks among the plurality of physical blocks to a second pool containing physical blocks operating in a second (e.g., SLC) mode for storing a smaller number of bits per cell. The controller transfers the physical blocks between the first pool and the second pool based at least on a bit error rate measured for the transferred physical blocks.

[0056] The present invention may be a system, method and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions thereon for causing a processor to execute various aspects of the present invention.

[0057] Computer readable storage medium can be a tangible device that can retain and store instructions for use by instruction execution devices. Computer readable storage medium can be, for example but not limited to, electronic storage device, magnetic storage device, optical storage device, electromagnetic storage device, semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer readable storage medium includes the following: portable computer disk, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanical encoding device such as a protruding structure in a punch card or a groove with instructions recorded thereon, and any suitable combination of the above. Computer readable storage medium as used herein should not be interpreted as a temporary signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated by a waveguide or other transfer medium (e.g., a light pulse passing through a fiber optic cable) or an electrical signal emitted by a wire.

[0058] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or downloaded to an external computer or external storage device. The network can include copper transfer cables, optical transfer fibers, wireless transfers, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium within the corresponding computing / processing device.

[0059] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related 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++, etc.) and conventional procedural programming languages ​​(such as "C" programming languages ​​or similar programming languages). The computer-readable program instructions can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer, partially on the remote computer, or completely on the remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network (including local area network (LAN) or wide area network (WAN)), or can be connected to an external computer (for example, using an Internet service provider through the Internet). In some embodiments, the electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA) or a programmable logic array (PLA) can perform computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit so as to perform various aspects of the present invention.

[0060] The present invention is described with reference to the flowchart and / or block diagram of the method, device (system) and computer program product according to the embodiment of the present invention. It should be understood that each box of the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer readable program instructions.

[0061] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more boxes of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which causes the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable storage medium in which the instructions are stored includes a manufactured product containing instructions for implementing aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0062] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, so that a series of operational steps are performed on the computer, other programmable apparatus, or other device to produce computer-implemented processing, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in or in multiple boxes in the flowchart and / or block diagram.

[0063] The flow chart and block diagram in the accompanying drawings show the architecture, function and operation of the possible implementation of the system, method and computer program product according to different embodiments of the present invention. To this end, each box in the flow chart or block diagram may represent a module, segment or part of an instruction, which includes one or more executable instructions for realizing a specified logical function. In some alternative implementations, the function marked in the box may not occur in the order marked in the figure. For example, depending on the function involved, the two boxes shown in succession can actually be executed substantially at the same time, or these boxes can sometimes be executed in the opposite order. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or action or performs a combination of special hardware and computer instructions.

[0064] Although the present invention has been specifically illustrated with reference to one or more preferred embodiments, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the invention as defined by the appended claims. For example, although various aspects have been described with respect to a data storage system including a flash memory controller that directs certain functions, it will be understood that the present invention may alternatively be implemented as a program product including a storage device storing program code that may be processed by a processor to perform such functions or cause such functions to be performed. As used herein, "storage device" is specifically defined to include only legal articles and excludes signal media per se, transient propagating signals per se, and energy per se.

[0065] Furthermore, while embodiments have been described that include the use of NAND flash memory, it should be understood that embodiments of the present invention may also be used with any other type of non-volatile random access memory (NVRAM).

[0066] The above drawings and written descriptions of specific structures and functions are not intended to limit the scope of the applicant's invention or the scope of the appended claims. On the contrary, the drawings and written descriptions provided are to teach those skilled in the art to make and use the invention for which patent protection is requested. Those skilled in the art will understand that, for the sake of clarity and understanding, not all features of the commercial embodiments of the present invention are described or shown. Those skilled in the art will also recognize that the development of actual commercial embodiments in combination with various aspects of the present invention will require many specific implementation decisions to achieve the developer's ultimate goal for the commercial embodiment. Such specific implementation decisions may include and may not be limited to compliance with system-related, business-related, government-related and other constraints, which may vary with specific implementation, location and time. Although the developer's efforts may be complex and time-consuming in an absolute sense, such efforts are still routine tasks for those skilled in the art who benefit from the present disclosure. It must be understood that the invention disclosed and taught herein is susceptible to numerous and various modifications and alternative forms. Finally, the use of singular terms (such as but not limited to "one") does not mean to limit the number of items.

Claims

1. A method of operating a non-volatile memory comprising a plurality of physical blocks for storage each comprising a corresponding plurality of cells, wherein: Each cell of the plurality of cells is capable of individually storing multiple bits of data, the method comprising: The controller allocates physical blocks among the plurality of physical blocks to a first pool, the first pool including physical blocks operated in a first mode for storing a larger number of bits per cell, and allocates other physical blocks among the plurality of physical blocks to a second pool, the second pool including physical blocks operated in a second mode for storing a smaller number of bits per cell; For each of the first and second pools: tracking a number of physical blocks allocated to store data for each of a plurality of write streams of different write temperatures and a number of program / erase (P / E) cycles in each of the plurality of write streams; and For each write stream of the plurality of write streams, calculating a corresponding stream wear metric based on a number of physical blocks allocated to the write stream and a total number of P / E cycles of the physical blocks allocated to the write stream; and A controller transfers a physical block between a first pool and a second pool, wherein the transferring includes selecting a physical block for transfer based on: (1) a selected write stream from among the plurality of write streams, (2) a stream wear metric of the selected write stream, and (3) a block health of a physical block allocated to store data of the selected write stream.

2. The method according to claim 1, wherein: The transfer includes: transferring physical blocks having a higher bit error rate from the first pool to the second pool; and Physical blocks with lower bit error rates are transferred from the second pool to the first pool.

3. The method of claim 1, and further comprising a controller that determines block health of physical blocks in all of the plurality of write streams based on a bit error rate measured shortly after programming the physical blocks.

4. The method according to claim 1, wherein: The options include: selecting a healthiest physical block for transfer from among the physical blocks assigned to the selected write stream based on the selected write stream having a stream wear metric reflecting the greatest wear among all write streams of the plurality of write streams; and Based on the selected write stream having a stream wear metric reflecting the least wear among all write streams of the plurality of write streams, a least healthy physical block is selected for transfer from among the physical blocks assigned to the selected write stream.

5. The method according to claim 1, wherein: The first mode is a quad-level cell (QLC) mode; and The second mode is a single level cell (SLC) mode.

6. The method according to claim 1, wherein: The transferring includes transferring the physical blocks based on an available number of unprogrammed physical blocks in a given pool among the first pool and the second pool not satisfying a threshold value.

7. A data storage system, comprising: A controller for a non-volatile memory, the non-volatile memory comprising a plurality of physical blocks for storage each comprising a respective plurality of cells, wherein each of the plurality of cells is capable of individually storing a plurality of bits of data, wherein the controller is configured to perform: allocating physical blocks among the plurality of physical blocks to a first pool, the first pool comprising physical blocks operated in a first mode for storing a larger number of bits per cell, and allocating other physical blocks among the plurality of physical blocks to a second pool, the second pool comprising physical blocks operated in a second mode for storing a smaller number of bits per cell; For each of the first and second pools: tracking a number of physical blocks allocated to store data for each of a plurality of write streams of different write temperatures and a number of program / erase (P / E) cycles in each of the plurality of write streams; and For each write stream of the plurality of write streams, calculating a corresponding stream wear metric based on a number of physical blocks allocated to the write stream and a total number of P / E cycles of the physical blocks allocated to the write stream; and A physical block is transferred between a first pool and a second pool, wherein the transferring includes selecting a physical block for transfer based on: (1) a selected write stream from among the plurality of write streams, (2) a stream wear metric of the selected write stream, and (3) a block health of a physical block allocated to store data of the selected write stream.

8. The data storage system according to claim 7, wherein: The transfer includes: transferring physical blocks having a higher bit error rate from the first pool to the second pool; and Physical blocks with lower bit error rates are transferred from the second pool to the first pool.

9. The data storage system according to claim 7, wherein: The controller is further configured to perform: Block health of physical blocks in all write streams of the plurality of write streams is determined based on a bit error rate measured shortly after programming the physical block.

10. The data storage system according to claim 7, wherein: The options include: selecting a healthiest physical block for transfer from among the physical blocks assigned to the selected write stream based on the selected write stream having a stream wear metric reflecting the greatest wear among all write streams of the plurality of write streams; and Based on the selected write stream having a stream wear metric reflecting the least wear among all write streams of the plurality of write streams, a least healthy physical block is selected for transfer from among the physical blocks assigned to the selected write stream.

11. The data storage system according to claim 7, wherein: The first mode is a quad-level cell (QLC) mode; and The second mode is a single level cell (SLC) mode.

12. The data storage system according to claim 7, wherein: The transferring includes transferring the physical blocks based on an available number of unprogrammed physical blocks in a given pool among the first pool and the second pool not satisfying a threshold value.

13. A computer program product comprising a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a controller comprising a non-volatile memory comprising a plurality of physical blocks for storage each comprising a respective plurality of cells, wherein: When the program instructions are executed, the controller executes: allocating physical blocks among the plurality of physical blocks to a first pool, the first pool comprising physical blocks operated in a first mode for storing a larger number of bits per cell, and allocating other physical blocks among the plurality of physical blocks to a second pool, the second pool comprising physical blocks operated in a second mode for storing a smaller number of bits per cell; For each of the first and second pools: tracking a number of physical blocks allocated to store data for each of a plurality of write streams of different write temperatures and a number of program / erase (P / E) cycles in each of the plurality of write streams; and For each write stream of the plurality of write streams, calculating a corresponding stream wear metric based on the number of physical blocks allocated to the write stream and a total number of P / E cycles of the physical blocks allocated to the write stream; and A physical block is transferred between a first pool and a second pool, wherein the transferring includes selecting a physical block for transfer based on: (1) a selected write stream from among the plurality of write streams, (2) a stream wear metric of the selected write stream, and (3) a block health of a physical block allocated to store data of the selected write stream.

14. The program product according to claim 13, wherein: The transfer includes: transferring physical blocks having a higher bit error rate from the first pool to the second pool; and Physical blocks with lower bit error rates are transferred from the second pool to the first pool.

15. The program product according to claim 13, wherein: The program instructions further cause the controller to execute: Block health of physical blocks in all write streams of the plurality of write streams is determined based on a bit error rate measured shortly after programming the physical block.

16. The program product according to claim 13, wherein: The options include: selecting a healthiest physical block for transfer from among the physical blocks assigned to the selected write stream based on the selected write stream having a stream wear metric reflecting the greatest wear among all write streams of the plurality of write streams; and Based on the selected write stream having a stream wear metric reflecting the least wear among all write streams of the plurality of write streams, a least healthy physical block is selected for transfer from among the physical blocks assigned to the selected write stream.

17. The program product according to claim 13, wherein: The transferring includes transferring the physical blocks based on an available number of unprogrammed physical blocks in a given pool among the first pool and the second pool not satisfying a threshold value.

Images