Method for accessing coded history information and computer-readable storage medium and device

Abstract

The present invention relates to a method for accessing encoded history information, a computer-readable storage medium, and a device. The method comprises writing the encoded history information into the metadata section of a specified first page of a specified superpage line in a flash memory module. The encoded history information comprises a history profile and a history record. The history profile includes the number of blocks covered by a superblock and the number of history records. Each history record contains information indicating that a specified second page in a specified superpage line in a specified block has not been engine-encoded to generate a parity check code. The encoded history information allows for restoration of a damaged page in a specified superpage line in a specified block based on the damaged page.

Description

Technical Field

[0001] The present invention relates to a storage device, and in particular to a method for accessing coded history information, a computer-readable storage medium and a device. Background Art

[0002] Flash memory is generally classified as NOR flash memory and NAND flash memory. NOR flash memory is a random access device. The central processing unit (CPU) can provide any address to access NOR flash memory through the address pins and promptly retrieve the data stored at that address from the NOR flash memory's data pins. In contrast, NAND flash memory is not random access, but serial access. Unlike NOR flash memory, NAND flash memory cannot access any random address. Instead, the CPU needs to write serial byte values to the NAND flash memory to define the type of command requested (e.g., read, write, erase, etc.) and the address used for the command. The address can point to a page (the smallest data block for write operations in flash memory) or a block (the smallest data block for erase operations in flash memory). Improving the protection capabilities of data stored in flash memory modules has always been a major issue affecting the data security of flash memory controllers. Therefore, the present invention provides a method for accessing encoded history information, a computer-readable storage medium, and a device for improving data security. Summary of the Invention

[0003] In view of this, how to alleviate or eliminate the deficiencies in the above-mentioned related fields is indeed a problem to be solved.

[0004] The present invention relates to a method for accessing encoded history information, comprising: providing a super block formed by the storage space of multiple flash memory units; writing the encoded history information into the metadata section of a specified first page of a specified super page line in a flash memory module, wherein the encoded history information includes a history profile and a history record, the history profile includes the number of areas covered in the super block and the history records, and each history record includes information that a specified second page in a specified super page line of a specified area has not been encoded by an engine to generate a parity code.

[0005] The present invention also relates to a computer-readable storage medium containing a computer program. When a processing unit loads and executes the computer program, the method for accessing the encoded history information shown above is implemented.

[0006] The present invention also relates to a device for accessing encoding history information, comprising: a flash memory interface; and a processing unit. The processing unit is configured to provide a superblock formed by the storage space of multiple flash memory units; and to drive the flash memory units to write the encoding history information into a metadata section of a specified first page of a specified superpage line in a flash memory module.

[0007] One of the advantages of the above embodiment is that, by encoding history information, when a damaged page appears in a designated super page line of a designated area, the damaged page can be restored according to the encoded history information.

[0008] Other advantages of the present invention will be explained in more detail with reference to the following description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The drawings described herein are used to provide further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application.

[0010] Figure 1 FIG. 4 is a system architecture diagram of an electronic device according to an embodiment of the present invention.

[0011] Figure 2 FIG. 1 is a schematic diagram of a flash memory module according to an embodiment of the present invention.

[0012] Figure 3 FIG. 1 is a schematic diagram of a logical super block according to an embodiment of the present invention.

[0013] Figure 4 FIG. 1 is a schematic diagram of logical super blocks and zone division according to an embodiment of the present invention.

[0014] Figure 5 FIG. 4 is a flow chart of a data writing method according to an embodiment of the present invention.

[0015] Figure 6 FIG. 1 is a schematic diagram of an example of data writing according to an embodiment of the present invention.

[0016] Figure 7 FIG. 4 is a flow chart of a read error correction method according to an embodiment of the present invention.

[0017] Wherein, the reference numerals:

[0018] 10 Electronic devices

[0019] 110 Host side

[0020] 130 Flash Memory Controller

[0021] 131 Host Interface

[0022] 134 processing units

[0023] 135 RAID Engine

[0024] 136 Random Access Memory

[0025] 139 Flash memory interface

[0026] 150 Flash Memory Module

[0027] 151 Interface

[0028] 153#0~153#15 NAND flash memory units

[0029] CH#0~CH#3 channels

[0030] CE#0~CE#3 start signal

[0031] D#0~D#7 NAND flash memory cells

[0032] SP#0~SP#47 super page

[0033] 310 pages

[0034] STR#0~STR#7 super page line

[0035] Zones Z#0 to Z#5

[0036] S510~S582 Method Steps

[0037] 610~640 Fake pages

[0038] S710~S770 Method Steps DETAILED DESCRIPTION

[0039] The embodiments of the present invention will be described below with reference to the accompanying drawings. In these drawings, the same reference numerals represent the same or similar components or method flows.

[0040] It must be understood that the words "comprise", "include" and the like used in this specification are used to indicate the existence of specific technical features, values, method steps, work processes, elements and / or components, but do not exclude the addition of more technical features, values, method steps, work processes, elements, components, or any combination thereof.

[0041] The terms "first", "second", "third", etc. used in the present invention are used to modify the components in the claims and are not used to indicate a priority order, a precedence relationship, or that one component precedes another, or a temporal sequence in executing method steps. They are only used to distinguish components with the same name.

[0042] It should be understood that when a component is described as being "connected" or "coupled" to another component, it can be directly connected or coupled to the other component, and intervening components may be present. Conversely, when a component is described as being "directly connected" or "directly coupled" to another component, there are no intervening components. Other words used to describe the relationship between components should be interpreted in a similar manner, such as "between" versus "directly between," or "adjacent" versus "directly adjacent," etc.

[0043] refer to Figure 1. The electronic device 10 includes: a host side (Host Side) 110, a flash memory controller 130 and a flash memory module 150, and the flash memory controller 130 and the flash memory module 150 can be collectively referred to as the device side (Device Side). The electronic device 10 can be implemented in electronic products such as personal computers, laptop computers (Laptop PC), tablet computers, mobile phones, digital cameras, digital video cameras, etc. The host side 110 and the host interface (Host Interface) 131 of the flash memory controller 130 can communicate with each other using communication protocols such as Universal Serial Bus (USB), Advanced Technology Attachment (ATA), Serial Advanced Technology Attachment (SATA), Peripheral Component Interconnect Express (PCI-E), Universal Flash Storage (UFS), and Embedded Multi-Media Card (eMMC). The flash memory interface (Flash Interface) 139 of the flash memory controller 130 and the flash memory module 150 can communicate with each other using a double data rate (DDR) communication protocol, such as an open NAND flash interface (ONFI), a double data rate switch (DDR Toggle), or other communication protocols. The flash memory controller 130 includes a processing unit 134, which can be implemented in a variety of ways, such as using general-purpose hardware (e.g., a single processor, a multi-processor with parallel processing capabilities, a graphics processor, or other processor with computing capabilities), and provides the functions described below when executing software and / or firmware instructions. The processing unit 134 receives host commands, such as read commands, write commands, erase commands, etc., through the host interface 131, and schedules and executes these commands.Flash controller 130 also includes random access memory (RAM) 136, which can be implemented as dynamic random access memory (DRAM), static random access memory (SRAM), or a combination of the two. This RAM is used to configure space as a data buffer for storing user data (also referred to as host data) read from host 110 and to be written to flash memory module 150, as well as user data read from flash memory module 150 and to be output to host 110. RAM 136 can also store data required during execution, such as variables, data tables, host-to-flash (H2F) tables, and flash-to-host (F2H) tables. The flash memory interface 139 includes a NAND Flash Controller (NFC) that provides functions required for accessing the flash memory module 150 , such as a command serializer (CSerializer) and a low-density parity check (LDPC).

[0044] Flash controller 130 may be configured with a shared bus architecture to couple components to each other for data, address, and control signal transmission. These components include host interface 131, processing unit 134, redundant array of independent disks (RAIDEngine) 135, RAM 136, and flash interface 139. A bus consists of parallel physical lines that connect two or more components within flash controller 130. A shared bus is a shared transmission medium; at any given time, only two devices can use these lines to communicate with each other and transfer data. Data and control signals can travel bidirectionally between components along the data and control lines, respectively, while address signals can only travel unidirectionally along the address lines. For example, when processing unit 134 wants to read data at a specific address in RAM 136, it transmits the address to RAM 136 via the address line. The data at that address is then returned to processing unit 134 via the data line. To complete the data read operation, control signals are transmitted using the control lines.

[0045] Flash memory module 150 provides a large amount of storage space, typically hundreds of gigabytes (GB) or even multiple terabytes (TB), for storing large amounts of user data, such as high-resolution images and videos. Flash memory module 150 includes control circuitry and a memory array. The memory cells in the memory array can be configured as single-level cells (SLCs), multiple-level cells (MLCs), triple-level cells (TLCs), quad-level cells (QLCs), or any combination thereof after erasure. Processing unit 134 writes user data to a specified address (destination address) in flash memory module 150 and reads user data from a specified address (source address) in flash memory module 150 via flash memory interface 139. Flash memory interface 139 coordinates the transfer of data and commands between flash memory controller 130 and flash memory module 150 using multiple electronic signals, including data lines, clock signals, and control signals. The data lines can be used to transmit commands, addresses, read and write data; the control signal lines can be used to transmit control signals such as chip enable (CE), address latch enable (ALE), command latch enable (CLE), and write enable (WE).

[0046] refer to Figure 2The interface 151 in the flash memory module 150 may include four input / output channels (I / O channels, hereinafter referred to as channels) CH#0 to CH#3, each of which connects to four NAND flash memory cells. For example, channel CH#0 connects to NAND flash memory cells 153#0, 153#4, 153#8, and 153#12, and so on. Each NAND flash memory cell may be packaged as an independent chip (die). The flash memory interface 139 may activate NAND flash memory cells 153#0 to 153#3, 153#4 to 153#7, 153#8 to 153#11, or 153#12 to 153#15 by sending one of the activation signals CE#0 to CE#3 via the interface 151, and then read user data from or write user data to the activated NAND flash memory cells in parallel. Those skilled in the art may change the design of the flash memory module 150 according to system requirements, configure more or fewer channels in the flash memory module 150, and / or connect more or fewer NAND flash memory cells to each channel, and the present invention is not limited thereto.

[0047] The RAID engine 135 can perform functions such as clear and encode, encode, terminate encode, terminate, and resume based on commands issued by the processing unit 134. Upon receiving a clear and encode command, the controller in the RAID engine 135 reads data from multiple main pages (e.g., 32 main pages) from a specified address (referred to as a source address) in the RAM 136 via a shared bus and overwrites the data stored in the SRAM in the RAID engine 135 with the read data. Upon receiving an encode command, the controller in the RAID engine 135 reads data from multiple main pages from a specified address in the RAM 136 via a shared bus, performs an exclusive-OR operation on the read data and the data stored in the SRAM in the RAID engine 135, and overwrites the data stored in the SRAM in the RAID engine 135 with the result of the operation. When the end encoding instruction is received, the controller in the RAID engine 135 reads data of multiple main pages from the specified address of RAM 136 through the shared bus, performs an exclusive-OR calculation on the read data and the data stored in the SRAM in the RAID engine 135, overwrites the data stored in the SRAM in the RAID engine 135 with the calculation result, and stores the calculation result to the specified address (which may be called the destination address) of RAM 136 through the shared bus.

[0048] refer to Figure 3Schematic diagram of a logical super-block shown. For example, eight NAND flash memory cells D#0 to D#7 may be provided in the flash memory module 150. Each NAND flash memory cell provides storage space for multiple physical blocks. Each physical block may contain a default number of pages (e.g., 384). Each page may contain a data section and a metadata section. The data section of each page may store 4KB of data, and the metadata section in this page may store information describing the storage content in the data section. In each of the NAND flash memory cells D#0 to D#7, a physical block may contain 48 super pages, numbered sequentially as SP#0 to SP#47. Each super page contains 2 data planes, and each data plane contains 4 pages. In other words, a super page contains 8 pages. The same super-pages in NAND flash memory cells D#0 to D#7 may form a super-page string, and the pages in the super-page string may be sequentially numbered from P#0 to P#63.

[0049] RAID engine 135 can encode (e.g., perform an exclusive OR operation) the 63 pages in each superpage line to generate parity codes and store them in designated pages within the superpage line. For example, RAID engine 135 can encode Page 0 of Data Plane 0 of NAND flash memory cell D#0 to Page 2 of Data Plane 1 of NAND flash memory cell D#7 within a superpage line and store the encoded result in Page 3 of Data Plane 1 of NAND flash memory cell D#7 (referred to as a parity page). This encoding can be performed during a normal write process or during a sudden power-off recovery (SPOR) process. During a normal write process, some pages may be filled with useless dummy values that are not required for encoding by RAID engine 135. Pages storing dummy values are referred to as dummy pages. During a sudden power-off recovery process, RAID engine 135 does not use data from uncorrectable error correction code (UECC) pages for encoding.

[0050] When a phantom page is generated or a UECC page is detected, processing unit 134 may mark these pages and write the marking information (which may be referred to as encoding history information) to a designated location in a superblock. Later, when RAID engine 135 needs to restore a page that has experienced an error, processing unit 134 may first read the marking information from a designated location in flash memory module 150 to avoid mistakenly using data from phantom and UECC pages for decoding (or error correction). In some embodiments, a bitmap may be used to represent the marking information, where each bit indicates whether the corresponding page has been encoded by RAID engine 135, with "1" indicating encoding and "0" indicating non-encoding. For example, bit 0 in the bitmap represents page 0 of data plane 0 of NAND flash cell D#0; bit 1 represents page 1 of data plane 0 of NAND flash cell D#0, and so on. For each phantom page and UECC page, the corresponding bit in the bitmap is "0." The processing unit 134 can drive the flash memory interface 139 to write the bitmap into the metadata section of the last page (as shown by the backslash section 310) in the super pages SP#40 to SP#47. However, the space available for storing the bitmap in the metadata section is limited. Assuming that each metadata section in the backslash section 310 can provide 40 bytes of storage space, that is, all metadata sections in the backslash section 310 can represent 40x8x8=2560 pages. This space is not enough to represent the following: Figure 3 The configuration of the super block shown is because a super block contains a total of 384x8=3072 pages.

[0051] In order to solve the above problems, the embodiment of the present invention further divides the logical super block. For example, refer to Figure 4The diagram shows a logical superblock. A superblock may contain 6 zones, numbered sequentially from Z#0 to Z#5, and each zone contains 8 superpage lines, numbered sequentially from Str#0 to Str#7. The pages on each superpage line may be numbered sequentially from P#0 to P#63. The encoded history information may include a history profile and multiple history records. The history profile may be represented as the following data structure: {z_begin, z_end, h_qty, history[]}, where z_begin and z_end represent the start and end zone numbers, respectively, to indicate the zone range where one or more history records are located; h_qty represents the number of history records; and history[] is an array of history records. The maximum number of history records may be determined based on the available space in a metadata segment. Each history record can be represented as the following data structure: {w,x,y,z}, where w represents the zone number where the history record is located; x represents the super page line number where the history record is located; y represents the starting page number associated with the history record; and z represents the number of consecutive pages.

[0052] Each physical block in a NAND flash memory cell can be divided into a data block, a current block, or a system block according to its function. The processing unit 134 can select an empty physical block for each NAND flash memory cell as the current block, in preparation for writing the user data received from the host end 110. In order to improve the efficiency of data writing, the user data provided by the host end 110 can be written in parallel to specific pages in the current blocks of multiple NAND flash memory cells. The super block described above can include all or part of the current blocks of multiple NAND flash memory cells. After all pages in a current block are filled with user data, or after the remaining pages in a current block are filled with false values, the current block is changed to a data block. In other words, the user data stored therein will no longer change. Then, the processing unit 134 can select another empty physical block as the new current block. In addition, the processing unit 134 can set a specific physical block as a system block for storing management information, such as a flash identifier (ID), a bad block table (BadBlock Table), a bad column table (Bad Column Table), a host-to-flash table (H2FTable), etc.

[0053] If a sudden power outage (SPO) occurs during data writing to a super-block, the previously written page data may be damaged. Therefore, after power is restored, the processing unit 134 needs to execute the data writing procedure again in the SPOR procedure to first find the interruption point (i.e., the UECC page), mark it, and then continue writing.

[0054] To address the aforementioned issues, an embodiment of the present invention provides a method for accessing encoding history information. The method is implemented by the processing unit 134 when loading and executing program code of a firmware translation layer (FTL). The method comprises: providing a superblock formed by the storage space of a plurality of flash memory cells (e.g., NAND flash memory cells D#0 to D#7); writing encoding history information to the metadata section of a specified first page of a specified superpage line in the flash memory module 150, wherein the encoding history information includes a history profile and history records. The history profile includes the number of blocks and history records included in the superblock, and each history record includes information that a specified second page in a specified superpage line in the specified block has not been encoded by the engine to generate a parity code. When a damaged page appears in a specified superpage line in the specified block, the encoding history information is read from the metadata section of the specified first page of the specified superpage line in the flash memory module 150; the specified second page is discarded based on the encoding history information; and the remaining page contents in the specified superpage line in the specified block are fed page by page into the engine to restore the damaged page.

[0055] refer to Figure 5 The flowchart of the data writing method executed by the processing unit 134 when loading the relevant program code is shown. This method includes an outer loop (steps S510 to S582) and an inner loop (steps S522 to S582) that are repeatedly executed. The outer loop is used to write data, metadata, parity code, and encoding history information to a super block, while the inner loop is used to write data, metadata, parity code, and encoding history information to a super page line in the super block. The details are as follows:

[0056] Step S510: Initialize the variables used during execution: ZB = 0; ZE = 0; Zcur = 0; STRcur = 0; Npre = 0; Ncur = 0. ZB is used to record the starting block number of the history record set, ZE is used to record the ending block number of the history record set, Zcur is used to record the current block number, STRcur is used to record the current superpage line number, Npre is used to record the number of previously accumulated history records, and Ncur is used to record the number of history records on the current superpage line.

[0057] Step S522: Prepare data, metadata, and parity codes for multiple pages of the super page line #Zcur.

[0058] During a general data writing process, the processing unit 134 may temporarily store the collected data and metadata of the super page line #Zcur in the RAM 136 and feed them page by page to the RAID engine 135 for generating parity codes.

[0059] During the SPOR process, if a breakpoint has not been found, processing unit 134 reads the contents of superpage line #Zcur and checks whether a UECC page exists. If a breakpoint is found in superpage line #Zcur, processing unit 134 temporarily stores the collected data and metadata after the breakpoint in RAM 136 and feeds the data and metadata before and after the breakpoint to RAID engine 135 page by page for parity code generation.

[0060] In the SPOR process, if a breakpoint is found before the super page line #Zcur, the processing unit 134 may temporarily store the collected data and metadata of the super page line #Zcur in the RAM 136 and feed them page by page to the RAID engine 135 for generating parity codes.

[0061] Step S524: Determine whether these pages include a false page or a UECC page. If so, the process proceeds to step S532. Otherwise, the process proceeds to step S526.

[0062] Step S526: Ncur is set to 0, indicating that these pages do not include false pages or UECC pages.

[0063] Step S532: Generate one or more history records based on the locations of the pseudo pages and / or UECC pages. For example, if the 15th page and the 34th to 35th pages in the 0th superpage line of the 0th block are pseudo pages, the processing unit 134 generates two history records: {0, 0, 15, 1} and {0, 0, 34, 2}.

[0064] Step S534: Obtain the number of history records Ncur. For example, if two history records are generated in step S532, then Ncur=2.

[0065] Step S540: Determine whether the sum of Npre and Ncur is greater than MAXn, where MAXn is a default constant that limits the number of history records. If so, the currently generated history profile and history record need to be written to the metadata section of a page in this superpage line, and the process continues with step S552. Otherwise, the currently generated history profile and history record do not need to be written yet and can continue to be accumulated, and the process continues with step S562.

[0066] Step S552: Drive the flash memory interface 139 to write the collected data, metadata, parity code, and encoding history information to the physical address corresponding to the super page line #Zcur. For example, the data and the associated metadata are written to the physical addresses corresponding to pages P#0 to P#62 in the super page line #Zcur, and the parity code and encoding history information are written to the physical address corresponding to page P#63 in the super page line #Zcur. It is understood that after the encoding history information is written to the flash memory module 150, the processing unit 134 can clear the encoding history information temporarily stored in the RAM 136. It should be noted here that if the SPOR program is in progress and no interruption point has been found, there is no need to drive the flash memory interface 139 to actually write the data, metadata, parity code, and encoding history information.

[0067] Step S554: Set both Npre and Ncur to 0.

[0068] Step S556: If STRcurr is less than MAXstr, indicating that the data in this zone has not been written yet, ZB is set to Zcur (i.e., the number of the current zone). If STRcurr is equal to MAXstr, indicating that the data in this zone has been written, ZB is set to Zcur plus 1 (i.e., the number of the next zone).

[0069] Step S562: If the last super page line of this super block is not currently being processed, the flash memory interface 139 is driven to write the collected data, metadata, and parity code to the physical address corresponding to the super page line #Zcur. For example, the data and the associated metadata are written to the physical addresses corresponding to pages P#0 to P#62 in the super page line #Zcur, and the parity code is written to the physical address corresponding to page P#63 in the super page line #Zcur. If the last super page line of this super block is currently being processed, the flash memory interface 139 is driven to write the collected data, metadata, parity code, and encoding history information to the physical address corresponding to the super page line #Zcur. It should be noted that if the SPOR process is in progress and no interruption point has been found, the flash memory interface 139 does not need to be driven to actually write the data, metadata, parity code, and encoding history information.

[0070] Step S564: Set NE to Ncur.

[0071] Step S566 : Npre is set to Ncur plus Npre to calculate the number of history records that have not been written into the flash memory module 150 .

[0072] Step S570: Determine whether STRcur is equal to MAXstr, where MAXstr is a default constant indicating the maximum superpage line number within a zone. If so, it indicates that the next zone is about to be entered, and the process proceeds to step S580. Otherwise, it indicates that the next zone is still within the same zone, and the process proceeds to step S572.

[0073] Step S572: Add 1 to STRcur.

[0074] Step S580: Determine whether Zcur is equal to MAXz, where MAXz is a default constant indicating the maximum extent number within a super-block. If so, the next super-block is about to be entered, and the process proceeds to step S510. Otherwise, the process remains within the same super-block, and the process proceeds to step S582.

[0075] Step S582: Add 1 to Zcur, then set ZE to Zcur and set STRcur to 0.

[0076] refer to Figure 6 Assume MAXn is set to 1:

[0077] In the loop of the super page line STR#0 in the processing zone Z#0, the processing unit 134 finds that the 15th page 610 and the 34th to 35th pages 620 are false pages (the "yes" path in step S524), and then generates two history records: {0,15,1} and {0,34,2} (step S532). Since the processing unit 134 detects that Npre+Ncur=2 is greater than MAXn=1 (the "yes" path in step S540), the data and the corresponding metadata are written to the physical addresses of pages P#0 to P#62 in the super page line STR#0 corresponding to zone Z#0, and the parity code and encoding history information (including z_begin=0, z_end=0, h_qty=2, history[]={0,0,0,15,1},{0,0,34,2}) are written to the physical address of page P#63 in the super page line STR#0 corresponding to zone Z#0.

[0078] In the loop processing superpage line STR#7 of zone Z#0, processing unit 134 discovers that pages 50 to 51 630 are false pages (the "Yes" path in step S524). Subsequently, processing unit 134 generates a history record: {0, 7, 50, 2} (step S532). Since processing unit 134 detects that Npre + Ncur = 1 is not greater than MAXn = 1 (the "No" path in step S540), data and associated metadata are written to the physical addresses of pages P#0 to P#62 in superpage line STR#7 corresponding to zone Z#0, and parity code is written to the physical address of page P#63 in superpage line STR#7 corresponding to zone Z#0.

[0079] In the loop processing superpage line STR#7 in zone Z#1, processing unit 134 discovers that page 640, number 55, is a false page (the "yes" path in step S524). Subsequently, processing unit 134 generates a history record: {1, 7, 55, 1} (step S532). Since processing unit 134 detects that Npre + Ncur = 2 is greater than MAXn = 1 (the "yes" path in step S540), data and associated metadata are written to the physical addresses corresponding to pages P#0 through P#62 in superpage line STR#7 in zone Z#1. Furthermore, parity and encoded history information (including z_begin = 0, z_end = 1, h_qty = 2, history[] = {0, 7, 50, 2}, {1, 7, 55, 1}) are written to the physical address corresponding to page P#63 in superpage line STR#0 in zone Z#0.

[0080] In the loop of processing the super page line STR#7 of zone Z#5, since the processing unit 134 does not find a false page (the "No" path in step S524), the data and the corresponding metadata are written to the physical addresses of pages P#0 to P#62 in the super page line STR#7 corresponding to zone Z#5, and the parity code and encoding history information (including z_begin=2, z_end=5, h_qty=0, history[]=NULL) are written to the physical address of page P#63 in the super page line STR#7 corresponding to zone Z#5.

[0081] Although the above embodiment describes that the encoding history information is stored in the metadata segment of the last page of a super page line, and the data segment of the last page of this super page line stores the parity code, those skilled in the art may change the encoding history information to be stored in other locations of this super page line.

[0082] In other embodiments, the processing unit 134 may store the encoding history information in a page containing the parity code of a superpage line instead of the last page of the superpage line. For example, the processing unit 134 may store the parity code of a superpage line in the data section of page P#0 of the superpage line and store the encoding history information in the metadata section of page P#0 of the superpage line.

[0083] In other embodiments, the processing unit 134 may store the encoding history information in the last page of a superpage line, but may not store the parity code of the superpage line in the last page of the superpage line. For example, the processing unit 134 may store the parity code of a superpage line in the data section of page P#0 of the superpage line, and store the encoding history information in the metadata section of page P#63 of the superpage line.

[0084] refer to Figure 7 The flowchart of the read error correction method executed by the processing unit 134 when loading the relevant program code is described as follows:

[0085] Step S710: A damaged page P#v is detected in the super page line STR#u of zone Z#t, where t is any integer from 0 to MAXz, MAXz represents the maximum zone number in a super block; u is any integer from 0 to MAXu, MAXu represents the maximum super page line number in a zone; v is any integer from 0 to MAXv, MAXv represents the maximum page number in a super page line.

[0086] Step S720: Read the encoding history information from the metadata section in the last page of the last superpage line of the last block.

[0087] Step S730: Determine whether a history record of the super page line STR#u of zone Z#t is found in the encoded history information. If so, the process continues with step S750; otherwise, the process continues with step S740.

[0088] Step S740: Obtain the previous encoding history information. The processing unit 134 can scan the specified position of the metadata segment in the last page of each super page line starting from the last super page line in the starting area z_begin through the flash memory interface 139, and check whether the encoding history information can be found. The earliest encoding history information found is the previous encoding history information. If none is found, the processing unit 134 can scan the specified position of the metadata segment in the last page of each super page line starting from the last super page line in the area before the starting area z_begin through the flash memory interface 139 until the encoding history information is found.

[0089] Step S750: Obtain the encoding history associated with the super page line STR#u from the encoding history information.

[0090] Step S760: Discard unnecessary pages (i.e., pseudo pages and UECC pages) according to the encoding process, and feed the remaining page contents to the RAID engine 135 page by page to restore the damaged page P#v, and generate a new parity code based on the restored superpage line STR#u content.

[0091] Step S770: Drive the flash memory interface 139 to write the restored data, metadata, and parity check code of the super page line STR#u into the super page line in the current block.

[0092] Continue as Figure 6 In the example shown, it is assumed that a corrupted page P#0 is detected in super page line STR#7 of zone Z#0:

[0093] The processing unit 134 reads the encoding history information (including z_begin=2, z_end=5, h_qty=0, history[]=NULL) from the metadata segment in the last page P#63 of the last superpage line STR#7 of the last zone Z#5 (step S720). Next, the processing unit 134 scans the specified position of the metadata segment in the last page of each superpage line starting from the last superpage line in zone Z#2, but no encoding history information is found. The processing unit 134 continues to scan zone Z#1 and finds the encoding history information (including z_begin=0, z_end=1, h_qty=2, history[]={0,7,50,2},{1,7,55,1}) in the metadata segment in the last page P#63 of the last superpage line STR#7 of zone Z#1 (step S740). Since the history record {0,7,50,2} of the super page line STR#7 of zone Z#0 is found in the encoded history information (the "Yes" path in step S730), the processing unit 134 discards the unnecessary pages P#50 and P#51 according to the history record, and feeds the remaining page contents to the RAID engine 135 page by page to restore the damaged page P#0, generates a new parity code based on the content of the restored super page line STR#u (step S760), and writes the data, metadata and parity code of the restored super page line STR#u to the super page line in the current block (step S770).

[0094] All or part of the steps in the method described in the present invention can be implemented by a computer program, such as a firmware translation layer (FTL) in a storage device, a driver for specific hardware, etc. In addition, it can also be implemented in other types of programs as shown above. A person skilled in the art can write the method of the embodiment of the present invention into program code, which will not be described again for the sake of simplicity. The computer program implemented according to the method of the embodiment of the present invention can be stored in an appropriate computer-readable storage medium, such as a DVD, CD-ROM, USB flash drive, hard disk, or can be placed on a network server that can be accessed through a network (e.g., the Internet, or other appropriate media).

[0095] Although Figure 1 、 Figure 2 The components described above are included in the invention, but it does not exclude the use of more additional components to achieve better technical effects without violating the spirit of the invention. Figure 5 、 Figure 7 The flowchart is executed in the specified order. However, those skilled in the art may modify the order of these steps without violating the spirit of the invention, provided that the same effect is achieved. Therefore, the present invention is not limited to the above-described order. In addition, those skilled in the art may also combine several steps into one step, or perform more steps sequentially or in parallel in addition to these steps, and the present invention should not be limited thereby.

[0096] The above description is only a preferred embodiment of the present invention, but it is not intended to limit the scope of the present invention. Any person skilled in the art may make further improvements and changes on this basis without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention shall be based on the scope defined by the claims of this application.

Claims

1. A method for accessing coded history information, executed by a processing unit, characterized in that: The access method of the coding history information includes: Providing a superblock formed by storage spaces of a plurality of flash memory cells, wherein the superblock comprises a plurality of regions, each of the regions comprises a plurality of super page lines, and each of the super page lines comprises a plurality of pages spanning across a plurality of the flash memory cells; Writing encoding history information to the metadata section of a specified first page of a specified superpage line, wherein the encoding history information includes a history profile and a history record, the history profile includes the areas covered by the superblock and the number of history records, and each history record includes information that a specified second page in the specified superpage line of the specified area has not been encoded by the engine to generate a parity check code, so that when a damaged page appears in the specified superpage line of the specified area, the damaged page can be restored according to the encoding history information; When the damaged page appears in the designated super page line of the designated area, reading the encoding history information from the metadata section of the designated first page of the super page line; discarding the designated second page according to the encoding history information; and The page contents remaining in the designated super page line of the designated area are fed into the engine page by page to restore the damaged page.

2. The method for accessing code history information according to claim 1, wherein: The designated second page is a dummy page or an unerror-correctable page, wherein the dummy page is filled with dummy values.

3. The method for accessing code history information according to claim 1, wherein: The data sector of the designated first page stores parity codes of a plurality of the pages in the designated superpage line.

4. The method for accessing encoding history information according to claim 1, wherein: The designated first page is the last page in the designated superpage line.

5. The method for accessing encoding history information according to claim 1, wherein: The designated first page is the last page in the designated superpage line, and the data section of the designated first page stores parity codes of the multiple pages in the designated superpage line.

6. A computer-readable storage medium for storing a computer program executable by a processing unit, characterized in that: When the computer program is executed by the processing unit, the method for accessing encoding history information according to any one of claims 1 to 5 is implemented.

7. A device for storing and accessing coded history information, characterized in that: include: A flash memory interface coupled to a plurality of flash memory units; as well as A processing unit coupled to the flash memory interface, configured to provide a superblock formed by the storage space of a plurality of the flash memory cells, wherein the superblock comprises a plurality of regions, each of the regions comprises a plurality of superpage lines, and each of the superpage lines comprises a plurality of pages spanning a plurality of the flash memory cells; and driving the flash memory interface to write encoded history information to a metadata section of a specified first page of a specified superpage line, wherein the encoded history information comprises a history profile and a history record, the history profile comprising the regions covered in the superblock and the number of the history records, and each of the history records comprising the number of the specified superpage lines in the specified region. The designated second page has not been encoded by the engine to generate information of the parity code, so that when a damaged page appears in the designated super page line of the designated area, the damaged page is restored according to the encoding history information; when the damaged page appears in the designated super page line of the designated area, the flash memory interface is driven to read the encoding history information from the metadata segment of the designated first page of the super page line; the designated second page is discarded according to the encoding history information; and the page contents remaining in the designated super page line of the designated area are fed into the engine page by page to restore the damaged page.

8. The device for accessing coded history information according to claim 7, wherein: The designated second page is a dummy page or an unerror-correctable page, wherein the dummy page is filled with dummy values.

9. The device for accessing coded history information according to claim 7, wherein: The data sector of the designated first page stores parity codes of a plurality of the pages in the designated superpage line.

10. The device for accessing coded history information according to claim 7, wherein: The designated first page is the last page in the designated superpage line.

11. The device for accessing coded history information according to claim 7, wherein: The designated first page is the last page in the designated superpage line, and the data section of the designated first page stores parity codes of the multiple pages in the designated superpage line.

Images