WO2020073233A1

WO2020073233A1 - System and method for data recovery in parallel multi-tenancy ssd with finer granularity

Info

Publication number: WO2020073233A1
Application number: PCT/CN2018/109650
Authority: WO
Inventors: Shu Li; Ping Zhou; Yu Du
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2018-10-10
Filing date: 2018-10-10
Publication date: 2020-04-16
Anticipated expiration: 2021-04-10
Also published as: CN112823331A; CN112823331B

Abstract

A system and method for facilitating data recovery are disclosed. The system receives a request to write a first page of data to a non-volatile memory (702). The system writes the first page to a first block in a first group of blocks of the non-volatile memory, wherein a number of blocks in a respective group is less than a number of blocks in a superblock (706). The system generates, by a controller, a first incremental parity page based on the first page (708). The system writes the first incremental parity page to a second block of the first group, wherein the second block is the next sequentially available block (710). The system stores, by the controller, the first incremental parity page in a volatile memory buffer of the controller (712), thereby enhancing a garbage collection process based on a reduced granularity of a size of a group of blocks that is less than a size of a superblock (714).

Description

SYSTEM AND METHOD FOR DATA RECOVERY IN PARALLEL MULTI-TENANCY SSD WITH FINER GRANULARITY

Inventors: Shu Li, Ping Zhou, and Yu Du

BACKGROUND Field

This disclosure is generally related to the field of data storage. More specifically, this disclosure is related to a system and method for data recovery in parallel multi-tenancy SSD with finer granularity.

Related Art

The proliferation of the Internet and e-commerce continues to create a vast amount of digital content. Various storage systems and servers have been created to access and store such digital content. A storage system or server can include volatile memory (e.g., dynamic random access memory (DRAM) and multiple drives (e.g., a solid state drive (SSD) ) . A drive can include non-volatile memory for persistent storage (e.g., NAND flash) . The memory in a server plays a crucial role in the performance and capacity of a storage system.

In a conventional SSD, the system has no visibility into the data’s lifespan, nor into which data is updated and at what frequency. As a result, data received from the host is considered equal, with no distinction between “hot” and “cold” data (i.e., frequently accessed data and not frequently accessed data, respectively) . Because hot and cold data may be mixed together in read and write operations, an overhead in garbage collection may occur. When a first NAND block is recycled during garbage collection, the system copies valid pages from the first NAND block into a new block (s) . The first block is only “erased” after all valid data in the first block is copied into the new block (s) . However, because data is recycled at the granularity of a superblock (e.g., a group of 128 blocks) , the large size of the superblock can result in a decreased efficiency in garbage collection and the overall organization of the NAND flash. This can result in a high write amplification, whereby the NAND bandwidth consumed by copying data can result in a decreased Quality of Service (QoS) and an increased latency.

One solution is to separate the data by its access frequency and create separate streams based on the access frequency, e.g., separate streams for hot data and cold data, or separate multi-stream regions in an SSD. During garbage collection, hot pages in a first stream have already expired because a more recent version has been written, but cold pages in a second stream are still valid. Thus, this solution still results in a high write amplification, whereby the cold valid data must still be copied out in order to recycle a superblock during garbage collection.

Furthermore, this solution can result in an overdesign which affects the overall performance of the storage system. For example, if the system reserves a large number of blocks for future potential new streams, the free block pool becomes limited. Subsequently, if the system experiences intense random write operations, the performance of the storage system may suffer from decreased efficiency (e.g., sub-optimal performance) .

Thus, while multi-stream regions in an SSD may provide some benefits, some issues remain, including a high write amplification, an increased latency, and a decreased efficiency.

SUMMARY

One embodiment facilitates data recovery. During operation, the system receives a request to write a first page of data to a non-volatile memory. The system writes the first page to a first block in a first group of blocks of the non-volatile memory, wherein a number of blocks in a respective group is less than a number of blocks in a superblock, wherein data is written in a stripe one page at a time from a beginning block of the respective group to a last block of the respective group, wherein a stripe includes physical pages which each correspond to a sequentially ordered die of the non-volatile memory, and wherein the first block is a next sequentially available block in the first group of blocks. The system generates, by a controller, a first incremental parity page based on at least the first page. The system writes the first incremental parity page to a second block of the first group of blocks, wherein the second block is the next sequentially available block in the first group of blocks. The system stores, by the controller, the first incremental parity page in a volatile memory buffer of the controller, thereby enhancing a garbage collection process based on a reduced granularity of a size of a group of blocks that is less than a size of a superblock.

In some embodiments, the system receives a request to write a second page of data to the non-volatile memory. The system determines that the first group of blocks is full. The system writes the second page to a third block in a second group of blocks. In response to determining that the second page is written to a location associated with the first incremental parity page, the system updates the first incremental parity page based on the second page. The system stores, by the controller, the updated first incremental parity page in the volatile memory of the controller.

In some embodiments, in response to detecting a condition which triggers recycling of the first block, the system: writes the first page to a new block; updates the first incremental parity page based on at least the first page, to remove the first page from a calculation of parity in the first incremental parity page; stores the updated first incremental parity page in the volatile memory of the controller; and releases the first block to a free block pool.

In some embodiments, in response to detecting a condition which triggers recycling of the first block, the system: writes valid pages in the first block to one or more new blocks, wherein the valid pages do not include incremental parity pages; updates a set of incremental parity pages associated with the valid pages in the first block, to remove the valid pages from a respective calculation of parity in the set of incremental parity pages; stores the set of updated incremental parity pages in the volatile memory of the controller; maps, by a flash translation layer component, any incremental parity pages in the first block to new physical block addresses; and releases the first block to a free block pool.

In some embodiments, in response to detecting a condition which triggers recycling of the second block, the system maps, by a flash translation layer component, the first incremental parity page to a new physical block address.

In some embodiments, in response to detecting a loss of power or in response to determining that data in the volatile memory of the controller cannot withstand a power loss, the system performs one or more of: flushing at least the first incremental parity page from the volatile memory of the controller to the non-volatile memory; and flushing all incremental parity pages from the volatile memory of the controller to the non-volatile memory.

In some embodiments, prior to receiving the request to write the first page, the system: receives a request to write a first number of pages to the non-volatile memory, wherein the first number of pages includes the first page; and assigns, by a host, a second number of physical block addresses to the first number of pages and a third number of parity pages, wherein the second number is a sum of the first number and the third number, and wherein the third number of parity pages includes the first incremental parity page.

In some embodiments, the number of blocks in the first group or the respective group is based on one or more of: a predetermined optimal block size for data recovery; a size configured by the controller; a size configured by a host; and a size determined by a user of the storage server.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1A illustrates an exemplary environment that facilitates data recovery, in accordance with an embodiment of the present application.

FIG. 1B illustrates an exemplary storage device that facilitates data recovery, in accordance with an embodiment of the present application.

FIG. 2 illustrates an exemplary storage device which uses multiple streams based on access frequency, in accordance with the prior art.

FIG. 3 illustrates an exemplary organization of physical space in NAND based on multiple streams, in accordance with the prior art.

FIG. 4 illustrates an exemplary organization of physical space in NAND that facilitates data recovery, including incremental parity pages, in accordance with an embodiment of the present application.

FIG. 5 illustrates an exemplary storage device with power loss protection for flushing parity pages from DRAM to NAND, in accordance with an embodiment of the present application.

FIG. 6A illustrates an exemplary organization of physical space in NAND that facilitates data recovery, including updating an incremental parity page and recycling a block in a garbage collection process, in accordance with an embodiment of the present application.

FIG. 6B illustrates an exemplary environment that facilitates data recovery, including recycling a block in a garbage collection process, in accordance with an embodiment of the present application.

FIG. 7A presents a flowchart illustrating a method for facilitating data recovery, in accordance with an embodiment of the present application.

FIG. 7B presents a flowchart illustrating a method for facilitating data recovery, including updating an incremental parity page, in accordance with an embodiment of the present application.

FIG. 7C presents a flowchart illustrating a method for facilitating data recovery, including recycling a block, in accordance with an embodiment of the present application.

FIG. 7D presents a flowchart illustrating a method for facilitating data recovery, including flushing parity pages based on a power loss, in accordance with an embodiment of the present application.

FIG. 8 illustrates an exemplary computer system that facilitates data recovery, in accordance with an embodiment of the present application.

FIG. 9 illustrates an exemplary apparatus that facilitates data recovery, in accordance with an embodiment of the present application.

In the figures, like reference numerals refer to the same figure elements.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled in the art to make and use the embodiments, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present disclosure. Thus, the embodiments described herein are not limited to the embodiments shown, but are to be accorded the widest scope consistent with the principles and features disclosed herein.

Overview

The embodiments described herein provide a system which solves the inefficiency problems inherent in multi-stream SSDs by providing an incremental parity generation for groups of blocks which are smaller in granularity than a superblock.

In conventional multi-stream SSDs, data may be placed in a “stream” (e.g., a dedicated independent region of physical space in the non-volatile memory) based on access frequency, such as “hot pages” or “cold pages. ” However, while hot pages in a stream may expire due to a more recent version written to a new stream, cold pages with valid data are still retained in its respective stream. During garbage collection, the cold pages with valid data must still be copied out in order to recycle the block associated with the streams. This results in a high write amplification, and can also result in an overdesign which affects the overall performance of the storage system. For example, if the system reserves a large number of blocks for future potential new streams, the free block pool becomes limited. Subsequently, if the system experiences intense random write operations, the performance of the storage system may suffer from decreased efficiency (e.g., sub-optimal performance) .

The embodiments described herein address these issues by providing a system which supports “multi-tenancy” with independent and isolated physical regions. Multi-tenancy can refer to executing multiple independent write operations simultaneously by programming data into NAND flash. The system can place data horizontally in “stripes” into groups of blocks which are of a size smaller than a size of a superblock. That is, data is written in a stripe (horizontally) one page at a time from a beginning block of a group to a last block of the group, and, if space remains in the group and upon reaching the last block, repeats at the next available page of the beginning block. A stripe includes physical pages which each correspond to a sequentially ordered die of non-volatile memory (e.g., NAND) . The system can determine the size of a group of blocks based on throughput requirements of the system. The system can further generate incremental parity pages based on pages in blocks of the group, and can update the incremental parity pages when writing new pages to the stripe or to other blocks which are not in the group of blocks. Placing data and updating incremental parity pages is described below in relation to FIG. 4.

The embodiments of the system described herein also provide power loss protection for the incremental parity pages by storing (and updating) the incremental parity pages in a volatile memory buffer of a controller of the storage device (e.g., in the internal DRAM of an SSD controller) , as described below in relation to FIG. 5. Furthermore, the system can efficiently perform garbage collection and recycle a block A by: 1) copying out valid pages from block A to a new block; 2) re-calculating the associated parity (e.g., updating the associated incremental parity page for a respective valid page from block A, by removing the respective valid page form the calculation of parity in the associated incremental parity page) ; and 3) mapping any incremental parity pages in block A to a new physical location. Garbage collection and recycling a block is described below in relation to FIGs. 6A and 6B.

Thus, by setting the granularity of the group of blocks for updating the incremental parity to a size that is smaller than a size of superblock, the embodiments described herein can avoid the high write amplification involved with the multi-stream regions in a conventional SSD. That is, the described system does not need to reserve a large number of blocks for future new streams, which results in eliminating the limitations on the free block pool. This in turn allows the system to execute intensive write operations without suffering from a decreased efficiency. Furthermore, the described system does not need to use a data recovery group which is a stripe across all blocks in a superblock, which results in eliminating the open parts of blocks which include unused and wasted space in the superblocks.

Thus, the embodiments described herein provide a system which improves and enhance the efficiency and performance of a storage system. The system can significantly reduce both the number of reserved open blocks and the unused portions of blocks in a superblock. By implementing groups of blocks which are smaller in size than a superblock, the system can place data in a horizontal stripe fashion, and can also generate and update incremental parity pages within the smaller groups. This can result in an improved efficiency, e.g., by enhancing a garbage collection process based on a reduced granularity of a size of a group of blocks that is less than a size of a superblock.

As described above and herein, conventional multi-stream SSDs may leave many parts of blocks of a superblock open, which can result in a large amount of unused and wasted space and can also result in a high write amplification for garbage collection at the granularity of a superblock. In the embodiments described herein, the system improves the conventional SSDs by allowing for efficient multi-stream SSDs which can both efficiently use the non-volatile memory storage and perform data recovery in a parallel multi-tenancy SSD with a finer granularity, i.e., at a single block level. Thus, the system provides a technological solution (e.g., enhancing garbage collection and data recovery in multi-stream SSDs based on a finer granularity) to the technological problem in the software arts (e.g., increased write amplification, wasted space, inefficient garbage collection, and decreased overall efficiency of a storage system) .

Exemplary Environment and Storage Device

FIG. 1A illustrates an exemplary environment 100 that facilitates data recovery, in accordance with an embodiment of the present application. Environment 100 can include a computing device 102 and an associated user 104. Computing device 102 can communicate via a network 110 with

storage servers

112, 114, and 116, which can be part of a distributed storage system and accessed via client servers (not shown) . A storage server can include multiple storage drives, and each drive can include a controller and multiple physical media for data storage. For example, server 116 can include a network interface card (NIC) 122, a CPU 124, a DRAM dual in-line memory module (DIMM) 126, and

SSDs

132, 136, 140, and 144 with, respectively,

controllers

134, 138, 142, and 146.

A controller can include interfaces to a host and to a non-volatile memory. A controller can also include a buffer as well as firmware which includes instructions and/or code to execute the methods described herein. For example, SSD 140 can include SSD controller 142. SSD controller 142 can include: a host interface 150; an embedded processor 152, which includes a buffer 154 and a firmware 156; and a channel management 158. SSD controller 142 can communicate with a host (e.g., via host interface 150 and a communication to/from host 149) . SSD controller 142 can also communicate with the non-volatile memory (via channel management 158) . The non-volatile memory can be accessed via multiple channels. For example, NAND dies 162, 164, and 166 may be accessed via a channel 160, and NAND dies 172, 174, and 176 may be accessed via a channel 170.

During operation, in the embodiments described herein, firmware 156 can include instructions and/or code, which allow incoming write data from the host to be written in a “horizontal” manner in the physical pages of a page stripe across multiple blocks in a group of blocks, one page at a time from a beginning block of the group of blocks to a last block of the group of blocks, as described below in relation to FIG. 4.

FIG. 1B illustrates an exemplary storage device (e.g., SSD) 140 that facilitates data recovery, in accordance with an embodiment of the present application. During operation, SSD 140 can receive data 180 from the host (via a communication 149) . Data 180 can include k pages of data (e.g., Page_1, Page_2, Page_3, Page_21, Page_22, Page_23, Page_31, Page_32, Page_33, …, Page_4, Page_5, Page_6, …, and Page_k) . The host can manage the data placement and the physical addresses in the non-volatile memory. That is, the host can define N physical addresses, where N is comprised of the k pages (or parts) of data and N-k parity pages (or parts) .

For example, host interface 150 can receive data 180 and host-defined N physical addresses 184. Host interface 150 can send data 180 to a data recovery engine 157, which can encode and decode data. Data recovery engine 157 can be included in, e.g., firmware 156 and/or embedded processor 152 of FIG. 1A. Data recovery engine 157 can generate processed data 182, which can include N pages, e.g., Page_1, Page_2, …, Page_6, …, Page_k, Parity_k+1, Parity_k+2, …, and Parity_n) . Data recovery engine 157 can send processed data 182 to channel management 158. Host interface 150 can also send host-defined N physical addresses 184 to channel management 158. Subsequently, SSD controller 142, via channel management 158, can write processed data 182 to the locations corresponding to host-defined N physical addresses 184 (e.g., to one or more of NAND dies 162-166 and 172-176 via

channels

160 and 170, respectively) .

Exemplary Storage Device with Multiple Streams and Organization of Physical Space in the Prior Art

FIG. 2 illustrates an exemplary storage device 202 which uses multiple streams based on access frequency, in accordance with the prior art. SSD 202 can include multiple streams, where a respective stream is filled with data based on the access frequency (hot or cold) of the data. For example, in multi-stream SSD 202 at a time t1: stream 210 can include

hot data

212, 214, 216, and 218; stream 220 can include

cold data

222, 224, 226, and 228; and stream 230 can be reserved for incoming hot or cold data. In multi-stream 202 at a time t2 subsequent to time t1, because stream 210 updates frequently, the original hot data 212-218 may have already “expired, ” and new hot data can be written to stream 230, as hot_new data 212.1-218.1. By reserving the multiple independent physical regions based on access frequency for multi-stream SSDs in this manner, the system can erase the entire unit and copy fewer valid pages because of the expiration of the frequently accessed pages.

When the conventional SSD reserves multiple independent physical regions (thus attempting to serve as a general purpose drive) , the conventional SSD may attempt to provide the optimal number of streams based on, e.g., the amount of data, the reliability of data, and the capacity of the drive. However, this may lead to an overdesign which affects the overall performance of the storage system. For example, if the system reserves a large number of blocks for future potential new streams, the free block pool becomes limited. Subsequently, if the system experiences intense random write operations, the performance of the storage system may suffer from a decreased efficiency (e.g., sub-optimal performance) .

FIG. 3 illustrates an exemplary organization of physical space 300 in NAND based on multiple streams, in accordance with the prior art. Physical space 300 can include a stream 310 (which corresponds to a superblock 312) and a stream 330 (which corresponds to a superblock 332) . Stream 310 can include multiple blocks, including: a block 1 321; a block 2 322; a block 3 323; a block n-2 324; a block n-1 325; and a block n 326. Note that in the conventional SSDs, a data recovery group includes a “superpage stripe, ” which is a page stripe across all dies on the SSD, i.e., that includes one physical page from each die on the SSD, or one physical page across all blocks in a superblock. For example, in stream 310, a data recovery group 314 includes Page_1, Page_2, Page_3, …, Page_n-2, Page n-1, and Page_n across, respectively, block 1 321 to block n 326. A data recovery group 316 includes Page_n+1, Page_n+2, Page_n+3, …, Page_2n-2, Page 2n-1, and Page_2n across, respectively, block 1 321 to block n 326. Similarly, in stream 330, a data recovery group 334 includes Page_1, Page_2, Page_3, …, Page_n-2, Page n-1, and Page_n across, respectively, a block 1 341 to a block n 346. A data recovery group 336 includes Page_n+1, Page_n+2, Page_n+3, …, Page_2n-2, Page 2n-1, and Page_2n across, respectively, block 1 341 to block n 346.

Thus, each data recovery group is striped across a NAND superblock, and each data recovery strip must have n parts, where n corresponds to the number of blocks in the superblock, such as 128 blocks. The superblock must remain open until all of the data recovery groups are written. Furthermore, in order to erase the superblock, the entire superblock with n blocks must be erased together, which can significantly impact the garbage collection process. For example, in order to erase the entire superblock, the system must copy out all valid data from each data recovery group (across all the blocks of the superblock) before releasing the blocks of the superblock to the free block pool.

Furthermore, each of

streams

310 and 330 includes a significant amount of open space in the respective blocks, e.g., an open space 318 in stream 310 and an open space 338 in stream 330. Depending on the write operations, this open space may be unused or wasted while waiting for garbage collection to occur. These challenges in the conventional multi-stream SSDs may result in a decreased efficiency, including an increased latency and a high write amplification, which can result in an inefficient storage system.

Exemplary Organization of Physical Space for Facilitating Data Recovery

FIG. 4 illustrates an exemplary organization of physical space 400 in NAND that facilitates data recovery, including incremental parity pages, in accordance with an embodiment of the present application. Physical space 400 can include blocks 1-7 (e.g., block 1 421 to block 7 427) . The system can define a number of parallel blocks (e.g., sequentially ordered dies of the non-volatile memory) as an optimal size for a group of blocks. This number can be based on the throughput requirements of the system. In general, in the embodiments described herein, the system does not open all blocks in the horizontal direction (e.g., as a superblock) to be the original data recovery group. For example, in physical space 400, a first group of blocks 402 includes 4 blocks: block 1 421; block 2 422; block 3 423; and block 4 424. The system can place Page_1 in block 1 421, Page_2 in block 2 422, and Page_3 in block 3 423. The system can subsequently generate an incremental parity page based on these three pages. That is, the system can perform a function 406 by taking as input data from these three pages (via a communication 404) to generate a Parity_1 page. The system can then write the generated Parity_1 to block 4 424 (via a communication 408) . The system can store the generated Parity_1 in a volatile memory, e.g., in the internal DRAM buffer of the SSD, as in DRAM 540 depicted in FIG. 5.

Subsequently, when the system receives the next page (e.g., Page_21) to be written, the system can place the data of Page_21 in the second row in block 1 421 of the first group of blocks 402, and generate an associated incremental parity page based at least on Page_21 (e.g., Parity_2) . Note that the system can determine where and when to generate the incremental parity pages within a particular group of blocks. This is in contrast to the conventional SSD, which would place Page_21 in block 4 424 immediately after placing Page_3 in block 3 423 (e.g., in the same page stripe across all the blocks of a superblock) .

When the first group of blocks 402 is full, the system can write incoming data to a next group of blocks. For example, the system can place Page_4 in block 5 425, Page_5 in block 6 426, and Page_6 in block 7 427. The system can subsequently update an incremental parity page based on these three pages. Specifically, the system can perform function 406 by taking as input data from these three pages (via a communication 410) and the current value of Parity_1 (via a communication 412) to update the Parity_1 page. The system can then “write” the updated Parity_1 to block 4 424 (via a communication 414) by updating a corresponding value in the volatile memory of the SSD. Because the data in a block of NAND flash cannot be written to unless the entire block is erased, the system can update the previously stored Parity_1 in the internal DRAM of the SSD.

Therefore, physical space 400 depicts a system which uses a small group of blocks (i.e., smaller than a superblock) to place data in horizontal page stripes, and inserts an incremental parity page which accounts for data in the same group of blocks or another block. The system can generate this incremental parity for a first set of pages, and subsequently update the incremental parity to: 1) account for additional valid pages which are written to the same or another block, which additional valid pages are written to a location associated with that incremental parity page; and 2) account for valid pages which are to copied out from a page which is to be recycled during a garbage collection process. The system can store the generated and updated incremental parity page in a volatile memory buffer (e.g., DRAM) of the controller, which volatile memory buffer can be flushed to the non-volatile NAND memory (e.g., NAND) upon detecting a power loss or inability of data in the volatile memory to withstand a power loss.

By extending the data recovery group in a gradual manner with incremental parity generation and updates, the system can execute garbage collection on a reduced granularity, i.e., based on a single block at a time, instead of an entire superblock at a time, as in the conventional SSDs. Furthermore, the host-based management can configure the physical NAND space prior to the data being programmed into NAND. By offloading the coding engine to an application-specific integrated circuit (ASIC) , the system described herein can accelerate the overall write process and further improves the efficiency of the storage system.

Power Loss Protection for Flushing Parity Pages

FIG. 5 illustrates an exemplary storage device 500 with power loss protection for flushing parity pages from DRAM to NAND, in accordance with an embodiment of the present application. SSD 500 can include an SSD controller 502, which can include: a host interface 504; buffers 506; and a channel management 508. SSD 500 can also include a power loss protection module 530, which can include a plurality of capacitors. SSD 500 can also include a DRAM 540 corresponding to buffers 506. The system can store incremental parity pages in DRAM 540 (e.g., Parity_1 and Parity_2 from FIG. 4) .

In response to detecting a power loss 552 (via a communication to/from host 550) , the system can flush the incremental parity pages from DRAM 540 to the NAND (e.g., one of NAND dies 512-516 and 522-526, via

channels

510 and 520, respectively) . The system can also flush the incremental parity pages in response to determining that data in the volatile memory of the controller (e.g., in the DRAM) cannot withstand a power loss.

Recycling a Block During Garbage Collection

FIG. 6A illustrates an exemplary organization of physical space 600 in NAND that facilitates data recovery, including updating an incremental parity page and recycling a block in a garbage collection process, in accordance with an embodiment of the present application. Physical space 600 can include blocks and data in pages of the blocks which are similar to physical space 400 of FIG. 4. During operation, the system can determine during a garbage collection process to recycle block 1 421 (e.g., a block to be recycled 602) . The system can write the valid pages of block 1 421 to a new block. The system can update a set of incremental parity pages associated with the valid pages of block 1 421, to remove the valid pages from a calculation of parity in the set of incremental parity pages. For example, the system can write Page_1 (valid data) to a new block (not shown) , i.e., copying valid data to a new block. The system can update Parity_1 associated with Page_1 by performing a function 608 based on Page_1 (via a communication 604) and the current value of Parity_1 (via a communication 606) . Function 608 results in a Parity_1 new 610 value, which essentially removes the data from Page_1 from the calculation of parity.

The system can also determine that a valid page in block 1 421 is an incremental parity page. For these valid parity pages, the system does not need to write the valid incremental parity page to a new block. Instead, the system, via a flash translation layer (FTL) component, need only map the valid incremental parity page to a new physical block address. For example, an FTL component can map Parity_4 to a new physical block address. After handling the valid pages of data (by writing a respective valid page to a new block, and recalculating the associated incremental parity page based on the respective valid page) and re-mapping any valid incremental parity pages to new physical addresses, the system can erase the block to be recycled. Specifically, the system can erase block 1 421 by releasing block 1 421 to a free block pool, as shown below in relation to FIG. 6B.

FIG. 6B illustrates an exemplary environment 640 that facilitates data recovery, including recycling a block in a garbage collection process, in accordance with an embodiment of the present application. Environment 640 can include multiple streams, such as a stream_h 642, a stream_i 644, and a stream_n 648. Astream can include multiple blocks, and a “current stream” can be a group of blocks with a size that is less than a size of a superblock. For example, stream_i 644 can include multiple blocks (e.g., block 1 421, block 2 422, block 3 423, block 4 424, block 5 425, …, block 7 427) , and a current stream_i 646 can include 4 blocks (block 1 421 to block 4 424) .

During operation, the system can determine to recycle block 1 421, and perform the operations described above in relation to FIG. 6A. The system can assign a new block 652, to which the valid pages of block 1 421 can be copied, and perform an erase 662 function by releasing block 1 421 back to a free block pool 660. Environment 640 also depicts other new blocks (e.g., new blocks 654 and 656) being assigned or allocated to stream_i 644, to recycle blocks of the stream (e.g., block 5 425 and block 7 427) . Furthermore, the system can assign a new block 664 to handle other operations, such as a data refresh 670, a bad block management 672, and a burst write 674.

Method for Facilitating Data Recovery

FIG. 7A presents a flowchart 700 illustrating a method for facilitating data recovery, in accordance with an embodiment of the present application. During operation, the system receives a request to write a first number of pages of data to a non-volatile memory (operation 702) . The system assigns, by a host, a second number of physical block addresses to the first number of pages and a third number of parity pages, wherein the second number is a sum of the first number and the third number, wherein the first number of pages includes a first page, and wherein the third number of parity pages includes a first incremental parity page (operation 704) . Host-defined physical addresses are described above in relation to FIG. 1B.

The system writes the first page to a first block of a first group of blocks of the non-volatile memory, wherein a number of blocks in a respective group is less than a number of blocks in a superblock, wherein data is written in a stripe one page at a time from a beginning block of the respective group to a last block of the respective group, wherein a stripe includes physical pages which each correspond to a sequentially ordered die of the non-volatile memory, and wherein the first block is a next sequentially available block in the first group of blocks (operation 706) . That is, data is written in a horizontal fashion from the beginning block to the last block of a group of blocks, and, if the group of blocks has sufficient space, repeats by starting over at the next available page of the beginning block, etc. (e.g., in small horizontal page stripes) . The number of blocks in the first group of blocks or a respective group of blocks can define a data recovery group, as described above in relation to FIG. 4, and can be based on the throughput requirements of the system, e.g., as a predetermined optimal block size for data recovery. The controller, the host, or a user of the storage server can also configure the number of blocks.

The system generates, by a controller, the first incremental parity page based on at least the first page (operation 708) . The system writes the first incremental parity page to a second block of the first group of blocks, wherein the second block is the next sequentially available block in the first group of blocks (operation 710) . The system stores, by the controller, the first incremental parity page in a volatile memory buffer of the controller (operation 712) . The system enhances a garbage collection process based on a reduced granularity of a size of a group of blocks that is less than a size of a superblock (operation 714) . The operation can subsequently continue as depicted at any of Labels A, B, and C in FIGs. 7B, 7C, and 7D, respectively.

FIG. 7B presents a flowchart 720 illustrating a method for facilitating data recovery, including updating an incremental parity page, in accordance with an embodiment of the present application. During operation, the system receives a request to write a second page of data to the non-volatile memory (operation 722) . If the first group of blocks is not full (decision 724) , the operation continues as described above at operation 706 of FIG. 7A, where the second page is written to a next available page of the next sequentially ordered die in the first group of blocks. If the first group of blocks is full (decision 724) , the system writes the second page to a third block in a second group of blocks (operation 726) , as described above in relation to FIG. 4. If the second page is not written to a location associated with the first incremental parity page (decision 728) , the system updates, based on the second page, a second incremental parity page associated with the location of the second page (operation 730) , and the operation continues at operation 734. If the second page is written to a location associated with the first incremental parity page (decision 728) , the system updates the first incremental parity page based on the second page (operation 732) , as described above in relation to FIG. 4. The system stores, by the controller, the updated first (or second) incremental parity page in the volatile memory of the controller (operation 734) , and the operation returns.

FIG. 7C presents a flowchart 740 illustrating a method for facilitating data recovery, including recycling a block, in accordance with an embodiment of the present application. During operation, if the system does not detect a condition which triggers recycling of the first block (decision 742) , the operation returns. If the system does detect a condition which triggers recycling of the first block (decision 742) , the system writes the first page and valid pages in the first block to one or more new blocks (operation 744) . The system updates the first incremental parity page based on at least the first page, to remove the first page from a calculation of parity in the first incremental parity page (operation 746) . The system also updates a set of incremental parity pages associated with the valid pages in the first block, to remove the valid pages from a respective calculation of parity in the set of incremental parity pages (operation 748) . The system stores the updated first incremental parity page and the updated set of incremental parity pages in the volatile memory of the controller (operation 750) . The system maps, by a flash translation layer component, any incremental parity pages in the first block to new physical addresses (operation 752) . The system releases the first block to a free block pool (operation 754) , and the operation returns.

FIG. 7D presents a flowchart 760 illustrating a method for facilitating data recovery, including flushing parity pages based on a power loss, in accordance with an embodiment of the present application. During operation, the system detects a loss of power or determines that data in the volatile memory of the controller cannot withstand a power loss (operation 762) . The system flushes at least the first incremental parity page from the volatile memory of the controller to the non-volatile memory (operation 764) . The system flushes all incremental parity pages from the volatile memory of the controller to the non-volatile memory (operation 766) .

Exemplary Computer System and Apparatus

FIG. 8 illustrates an exemplary computer system that facilitates data recovery, in accordance with an embodiment of the present application. Computer system 800 includes a processor 802, a memory 804, and a storage device/firmware 808. Computer system 800 may be a computing device or a storage device. Volatile memory 804 can include memory (e.g., RAM) that serves as a managed memory, and can be used to store one or more memory pools. Non-volatile memory 806 can include memory (e.g., NAND flash) which is used for persistent storage. Furthermore, computer system 800 can be coupled to a display device 810, a keyboard 812, and a pointing device 814. Storage device/firmware 808 can store an operating system 816, a content-processing system 818, and data 832. Note that firmware 808 may alternatively be located in or included in other components of computer system 800.

Content-processing system 818 can include instructions, which when executed by computer system 800, can cause computer system 800 to perform methods and/or processes described in this disclosure. For example, content-processing system 818 can include instructions for receiving and transmitting data packets, including a request to write or read data, data to be encoded, decoded, stored, deleted, or access, or a block or a page of data.

Content-processing system 818 can further include instructions for receiving a request to write a first page of data to a non-volatile memory (communication module 820) . Content-processing system 818 can include instructions for writing the first page to a first block in a first group of blocks of the non-volatile memory, wherein a number of blocks in a respective group is less than a number of blocks in a superblock, wherein data is written in a stripe one page at a time from a beginning block of the respective group to a last block of the respective group, wherein a stripe includes physical pages which each correspond to a sequentially ordered die of the non-volatile memory, and wherein the first block is a next sequentially available block in the first group of blocks (block-writing module 822) . Content-processing system 818 can include instructions for generating, by a controller, a first incremental parity page based on at least the first page (incremental parity-managing module 824) . Content-processing system 818 can include instructions for writing the first incremental parity page to a second block of the first group of blocks, wherein the second block is the next sequentially available block in the first group of blocks (block-writing module 822) . Content-processing system 818 can include instructions for storing, by the controller, the first incremental parity page in a volatile memory buffer of the controller (buffer-managing module 826) . Content-processing system 818 can include instructions for enhancing a garbage collection process based on a reduced granularity of a size of a group of blocks that is less than a size of a superblock (garbage collection-processing module 832) .

Content-processing system 818 can also include instructions for receiving a request to write a second page of data to the non-volatile memory (communication module 820) . Content-processing system 818 can include instructions for determining that the first group of blocks is full (block-writing module 822) . Content-processing system 818 can include instructions for writing the second page to a third block in a second group of blocks (block-writing module 822) . Content-processing system 818 can include instructions for in response to determining that the second page is written to a location associated with the first incremental parity page (incremental parity-managing module 824) , updating the first incremental parity page based on the second page (incremental parity-managing module 824) . Content-processing system 818 can include instructions for storing, by the controller, the updated first incremental parity page in the volatile memory of the controller (buffer-managing module 826) .

Content-processing system 818 can include instructions for operations in response to detecting a condition which triggers recycling of the first or second block (garbage collection-processing module 830) . Content-processing system 818 can include instructions for operations in response to detecting a loss of power or determining that data in the volatile memory of the controller cannot withstand a power loss (power loss-protecting module 828) .

Data 832 can include any data that is required as input or that is generated as output by the methods and/or processes described in this disclosure. Specifically, data 832 can store at least: data to be stored, written, read, loaded, moved, retrieved, deleted, or copied; a logical unit of data; a physical unit of data; a physical page of data; a logical page of data; a block of data; a data stripe to which data is written in a stripe one page at a time in a horizontal manner across blocks in a group of blocks; a group of blocks of a size that is less than a superblock; indicators of sequentially ordered dies of non-volatile memory; multiple streams; an incremental parity page; an operation which generates an incremental parity page, either by including or removing a page of data from a calculation of the incremental parity; a new block; an indication that a block is to be recycled for garbage collection; a released block; a location associated with a page of data or an incremental parity page; a calculation of parity; a re-mapped incremental parity page; a new physical address for a re-mapped incremental parity page; an indicator of a loss of power; an indicator that data in the volatile memory cannot withstand a power loss; instructions to flush data from a volatile memory of the controller to the non-volatile memory; an assigned number of physical block addresses to a number of pages and a number of parity pages; a predetermined optimal block size for data recovery; a size configured by the controller or a host; and a size determined by a user of the storage server.

FIG. 9 illustrates an exemplary apparatus that facilitates data recovery, in accordance with an embodiment of the present application. Apparatus 900 can comprise a plurality of units or apparatuses which may communicate with one another via a wired, wireless, quantum light, or electrical communication channel. Apparatus 900 may be realized using one or more integrated circuits, and may include fewer or more units or apparatuses than those shown in FIG. 9. Further, apparatus 900 may be integrated in a computer system, or realized as a separate device which is capable of communicating with other computer systems and/or devices. Specifically, apparatus 900 can comprise units 902-912 which perform functions or operations similar to modules 820-830 of computer system 800 of FIG. 8, including: a communication unit 902; a block-writing unit 904; an incremental parity-managing unit 906; a buffer-managing unit 908; a power loss-protecting unit 910; and a garbage collection-processing unit 912.

The data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. The computer-readable storage medium includes, but is not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs) , DVDs (digital versatile discs or digital video discs) , or other media capable of storing computer-readable media now known or later developed.

The methods and processes described in the detailed description section can be embodied as code and/or data, which can be stored in a computer-readable storage medium as described above. When a computer system reads and executes the code and/or data stored on the computer-readable storage medium, the computer system performs the methods and processes embodied as data structures and code and stored within the computer-readable storage medium.

Furthermore, the methods and processes described above can be included in hardware modules. For example, the hardware modules can include, but are not limited to, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs) , and other programmable-logic devices now known or later developed. When the hardware modules are activated, the hardware modules perform the methods and processes included within the hardware modules.

The foregoing embodiments described herein have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the embodiments described herein to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the embodiments described herein. The scope of the embodiments described herein is defined by the appended claims.

Claims

A computer-implemented method for facilitating data recovery, the method comprising:

receiving a request to write a first page of data to a non-volatile memory;

writing the first page to a first block in a first group of blocks of the non-volatile memory, wherein a number of blocks in a respective group is less than a number of blocks in a superblock, wherein data is written in a stripe one page at a time from a beginning block of the respective group to a last block of the respective group, wherein a stripe includes physical pages which each correspond to a sequentially ordered die of the non-volatile memory, and wherein the first block is a next sequentially available block in the first group of blocks;

generating, by a controller, a first incremental parity page based on at least the first page;

writing the first incremental parity page to a second block of the first group of blocks, wherein the second block is the next sequentially available block in the first group of blocks; and

storing, by the controller, the first incremental parity page in a volatile memory buffer of the controller,

thereby enhancing a garbage collection process based on a reduced granularity of a size of a group of blocks that is less than a size of a superblock.
The method of claim 1, further comprising:

receiving a request to write a second page of data to the non-volatile memory;

determining that the first group of blocks is full;

writing the second page to a third block in a second group of blocks;

in response to determining that the second page is written to a location associated with the first incremental parity page, updating the first incremental parity page based on the second page; and

storing, by the controller, the updated first incremental parity page in the volatile memory of the controller.
The method of claim 1, wherein in response to detecting a condition which triggers recycling of the first block, the method further comprises:

writing the first page to a new block;

updating the first incremental parity page based on at least the first page, to remove the first page from a calculation of parity in the first incremental parity page;

storing the updated first incremental parity page in the volatile memory of the controller; and

releasing the first block to a free block pool.
The method of claim 1, wherein in response to detecting a condition which triggers recycling of the first block, the method further comprises:

writing valid pages in the first block to one or more new blocks, wherein the valid pages do not include incremental parity pages;

updating a set of incremental parity pages associated with the valid pages in the first block, to remove the valid pages from a respective calculation of parity in the set of incremental parity pages;

storing the set of updated incremental parity pages in the volatile memory of the controller;

mapping, by a flash translation layer component, any incremental parity pages in the first block to new physical block addresses; and

releasing the first block to a free block pool.
The method of claim 1, further comprising:

in response to detecting a condition which triggers recycling of the second block, mapping, by a flash translation layer component, the first incremental parity page to a new physical block address.
The method of claim 1, wherein in response to detecting a loss of power or in response to determining that data in the volatile memory of the controller cannot withstand a power loss, the method further comprises one or more of:

flushing at least the first incremental parity page from the volatile memory of the controller to the non-volatile memory; and

flushing all incremental parity pages from the volatile memory of the controller to the non-volatile memory.
The method of claim 1, wherein prior to receiving the request to write the first page, the method further comprises:

receiving a request to write a first number of pages to the non-volatile memory, wherein the first number of pages includes the first page; and

assigning, by a host, a second number of physical block addresses to the first number of pages and a third number of parity pages, wherein the second number is a sum of the first number and the third number, and wherein the third number of parity pages includes the first incremental parity page.
The method of claim 1, wherein the number of blocks in the first group or the respective group is based on one or more of:

a predetermined optimal block size for data recovery;

a size configured by the controller;

a size configured by a host; and

a size determined by a user of the storage server.
A computer system for facilitating data recovery, the system comprising:

a processor; and

a memory coupled to the processor and storing instructions, which when executed by the processor cause the processor to perform a method, the method comprising:

receiving a request to write a first page of data to a non-volatile memory;

writing the first page to a first block in a first group of blocks of the non-volatile memory, wherein a number of blocks in a respective group is less than a number of blocks in a superblock, wherein data is written in a stripe one page at a time from a beginning block of the respective group to a last block of the respective group, wherein a stripe includes physical pages which each correspond to a sequentially ordered die of the non-volatile memory, and wherein the first block is a next sequentially available block in the first group of blocks;

generating, by a controller, a first incremental parity page based on at least the first page;

writing the first incremental parity page to a second block of the first group of blocks, wherein the second block is the next sequentially available block in the first group of blocks; and

storing, by the controller, the first incremental parity page in a volatile memory buffer of the controller,

thereby enhancing a garbage collection process based on a reduced granularity of a size of a group of blocks that is less than a size of a superblock.
The computer system of claim 9, wherein the method further comprises:

receiving a request to write a second page of data to the non-volatile memory;

determining that the first group of blocks is full;

writing the second page to a third block in a second group of blocks;

in response to determining that the second page is written to a location associated with the first incremental parity page, updating the first incremental parity page based on the second page; and

storing, by the controller, the updated first incremental parity page in the volatile memory of the controller.
The computer system of claim 9, wherein in response to detecting a condition which triggers recycling of the first block, the method further comprises:

writing the first page to a new block;

updating the first incremental parity page based on at least the first page, to remove the first page from a calculation of parity in the first incremental parity page;

storing the updated first incremental parity page in the volatile memory of the controller; and

releasing the first block to a free block pool.
The computer system of claim 9, wherein in response to detecting a condition which triggers recycling of the first block, the method further comprises:

writing valid pages in the first block to one or more new blocks, wherein the valid pages do not include incremental parity pages;

updating a set of incremental parity pages associated with the valid pages in the first block, to remove the valid pages from a respective calculation of parity in the set of incremental parity pages;

storing the set of updated incremental parity pages in the volatile memory of the controller;

mapping, by a flash translation layer component, any incremental parity pages in the first block to new physical block addresses; and

releasing the first block to a free block pool.
The computer system of claim 9, wherein the method further comprises:

in response to detecting a condition which triggers recycling of the second block, mapping, by a flash translation layer component, the first incremental parity page to a new physical block address.
The computer system of claim 9, wherein in response to detecting a loss of power or in response to determining that data in the volatile memory of the controller cannot withstand a power loss, the method further comprises one or more of:

flushing at least the first incremental parity page from the volatile memory of the controller to the non-volatile memory; and

flushing all incremental parity pages from the volatile memory of the controller to the non-volatile memory.
The computer system of claim 9, wherein prior to receiving the request to write the first page, the method further comprises:

receiving a request to write a first number of pages to the non-volatile memory, wherein the first number of pages includes the first page; and

assigning, by a host, a second number of physical block addresses to the first number of pages and a third number of parity pages, wherein the second number is a sum of the first number and the third number, and wherein the third number of parity pages includes the first incremental parity page.
The computer system of claim 9, wherein the number of blocks in the first group or the respective group is based on one or more of:

a predetermined optimal block size for data recovery;

a size configured by the controller;

a size configured by a host; and

a size determined by a user of the storage server.
An apparatus for facilitating data recovery, the apparatus comprising:

a communication unit configured to receive a request to write a first page of data to a non-volatile memory;

a block-writing unit configured to write the first page to a first block in a first group of blocks of the non-volatile memory, wherein a number of blocks in a respective group is less than a number of blocks in a superblock, wherein data is written in a stripe one page at a time from a beginning block of the respective group to a last block of the respective group, wherein a stripe includes physical pages which each correspond to a sequentially ordered die of the non-volatile memory, and wherein the first block is a next sequentially available block in the first group of blocks;

an incremental parity-generating unit configured to generate, by a controller, a first incremental parity page based on at least the first page;

wherein the block-writing unit is further configured to write the first incremental parity page to a second block of the first group of blocks, wherein the second block is the next sequentially available block in the first group of blocks; and

a buffer-managing unit configured to store, by the controller, the first incremental parity page in a volatile memory buffer of the controller,

which causes a garbage collection-processing unit to thereby enhance a garbage collection process based on a reduced granularity of a size of a group of blocks that is less than a size of a superblock.
The apparatus of claim 17, further comprising:

wherein the communication unit is further configured to receive a request to write a second page of data to the non-volatile memory;

wherein the block-writing unit is further configured to determine that the first group of blocks is full and write the second page to a third block in a second group of blocks;

wherein the incremental parity-managing unit is further configure to, in response to determining that the second page is written to a location associated with the first incremental parity page, update the first incremental parity page based on the second page; and

wherein the buffer-managing unit is further configured to store, by the controller, the updated first incremental parity page in the volatile memory of the controller.
The apparatus of claim 17, wherein the garbage collection-processing unit is further configured to detect a condition which triggers recycling of the first block, wherein the apparatus further comprises:

in response to the garbage collection-processing unit detecting the condition, the block-writing unit is configured to write valid pages in the first block to one or more new blocks, wherein the valid pages do not include incremental parity pages;

wherein the incremental parity-managing unit is further configured to update a set of incremental parity pages associated with the valid pages in the first block, to remove the valid pages from a respective calculation of parity in the set of incremental parity pages;

wherein the buffer-managing unit is further configured to store the set of updated incremental parity pages in the volatile memory of the controller;

wherein the incremental parity-managing module is further configured to map, by a flash translation layer component, any incremental parity pages in the first block to new physical block addresses; and

wherein the garbage collection-processing unit is further configured to release the first block to a free block pool.
The apparatus of claim 17, wherein a power loss-protecting unit is configured to detect a loss of power or to determine that data in the volatile memory of the controller cannot withstand a power loss, and wherein the apparatus further comprises one or more of:

wherein the buffer-managing unit is further configured to flush at least the first incremental parity page from the volatile memory of the controller to the non-volatile memory; and

wherein the buffer-managing unit is further configured to flush all incremental parity pages from the volatile memory of the controller to the non-volatile memory.