Data management method, electronic device, and storage medium

Abstract

The present application discloses a data management method, electronic device, and storage medium. The data management method includes: obtaining the data to be written, arranging the data to be written based on the preset size of the codeword, and obtaining multiple codeword data of the preset size; deleting the recoverable data in each codeword data to expand the blank space of each codeword data; using the blank space to manage the data, and writing each codeword data after data management to the storage device. The above scheme can expand the blank space of the codeword data, thereby effectively utilizing the blank space to achieve the adjustability of the codeword data and facilitate the realization of storage requirements.

Description

Technical Field

[0001] The present application relates to the field of storage technology, and in particular to a data management method, electronic device, and storage medium. Background Art

[0002] SSD (Solid State Disk or Solid State Drive) uses NAND flash media to store data.

[0003] When data to be written needs to be stored in the NAND flash memory of an SSD, the data is arranged in codewords based on the SSD's rules, and the codeword data structure after arrangement is fixed. During the storage process, the data to be written is often adjusted based on actual needs.

[0004] However, the fixed structure of codeword data is difficult to adjust, making it impossible to meet the corresponding storage requirements. Summary of the Invention

[0005] The main technical problem solved by the present application is to provide a data management method, an electronic device and a storage medium to solve the problem that the storage of data to be written cannot meet the additional storage requirements.

[0006] In order to solve the above problems, the present application provides a data management method, including obtaining data to be written, arranging the data to be written based on a preset size of a codeword, and obtaining codeword data of multiple preset sizes; deleting recoverable data in each codeword data to expand the blank space of each codeword data; using the blank space for data management, and writing each codeword data after data management to a storage device.

[0007] Among them, the steps of using blank space for data management and writing each code word data after data management to a storage device include: verifying each code word data separately to obtain multiple verification information, storing each verification information in the blank space of the corresponding code word data respectively to obtain multiple verified code word data; and writing the multiple verified code word data to a storage device.

[0008] Wherein, each codeword data includes user data and metadata, and each metadata includes protection information; the step of deleting recoverable data in each codeword data to expand the blank space of each codeword data includes: deleting the recoverable part of the protection data in each metadata to expand the blank space of each codeword data.

[0009] Among them, the step of obtaining the data to be written and arranging the data to be written based on the preset size of the codeword to obtain multiple codeword data of preset sizes also includes: determining the format type of recoverable data in the data to be written; the step of deleting the recoverable partial protection data in each metadata to expand the blank space of each codeword data includes: deleting the recoverable partial protection data in each metadata based on the format type of the recoverable data to expand the blank space of each codeword data.

[0010] The step of deleting the recoverable portion of protection data in each metadata to expand the blank space of each codeword data includes: verifying the metadata in each codeword data; when the metadata verification is successful, deleting the recoverable portion of protection data in each metadata to expand the blank space of each codeword data, and adjusting the positional relationship between the deleted metadata and the corresponding user data to unify the format of the codeword data.

[0011] Among them, each protection information includes verification protection data, application data and reference data; the step of deleting the recoverable part of the protection data in each metadata includes: in response to the logical block size of the data to be written being the same as the preset size, deleting the verification protection data of the protection information in each metadata; in response to the logical block size of the data to be written being different from the preset size, deleting the verification protection data of the protection information in each metadata and part of the reference data of the protection information in each metadata, so as to retain at least one reference data in multiple metadata.

[0012] Among them, the steps of verifying each code word data separately to obtain multiple verification information include: performing randomization processing and first verification processing on each code word data in turn to obtain a first verification code for each code word data; performing a second verification processing on each code word data to obtain a second verification code for each code word data; and determining the first verification code and the second verification code as verification information.

[0013] The data management method further includes: obtaining verified code word data from a storage device; and completing the verified code word data to obtain each code word data, so as to read each code word data.

[0014] Among them, the check protection data of each code word data is obtained by performing a first check processing on the user data of the corresponding code word data; the steps of completing the checked code word data to obtain each code word data and reading each code word data include: performing a first check processing on the user data of each code word data to obtain the check protection data of each code word data; and using at least one reference data from the retained multiple metadata to calculate each reference data from the multiple metadata to obtain the reference data of each metadata; using each check protection data and the reference data of each metadata to complete each checked code word data to restore each code word data and read each code word data.

[0015] To solve the above technical problems, the present invention further provides an electronic device, comprising a memory and a processor coupled to each other, wherein the processor is configured to execute program instructions stored in the memory to implement any of the above data management methods.

[0016] To solve the above technical problems, the present invention further provides a computer-readable storage medium having program instructions stored thereon, which implement any of the above data management methods when executed by a processor.

[0017] The beneficial effects of the present invention are as follows: different from the prior art, the present application arranges the data to be written based on the preset size of the codeword to obtain codeword data of multiple preset sizes; deletes the recoverable data in each codeword data to expand the blank space of each codeword data, and then uses the blank space for data management, and writes each codeword data after data management to a storage device, thereby making use of the expansion of the blank space to improve the adjustability of the codeword data, and facilitating the use of the blank space to adjust the codeword data based on storage requirements to achieve corresponding storage requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 This is a flowchart of an embodiment of the method for managing application data;

[0019] Figure 2 This is a flowchart of another embodiment of the method for managing application data;

[0020] Figure 3 This is a schematic diagram of data flow in an implementation method of data writing;

[0021] Figure 4 It is a structural diagram of an implementation method of data to be written;

[0022] Figure 5 It is a structural diagram of another implementation method of data to be written;

[0023] Figure 6 It is a structural diagram of a first implementation method for protecting data;

[0024] Figure 7 is a structural diagram of a second embodiment of protecting data;

[0025] Figure 8 is a schematic structural diagram of a third embodiment of protecting data;

[0026] Figure 9 It is a structural diagram of a codeword implementation method;

[0027] Figure 10 It is a specific structural diagram of an implementation method of codeword data;

[0028] Figure 11 is a schematic diagram of an embodiment of recoverable data deletion;

[0029] Figure 12 This is a flow chart of an embodiment of reading codeword data;

[0030] Figure 13 This is a schematic diagram of data flow in an implementation method of reading data;

[0031] Figure 14 This is a schematic diagram of the framework of an embodiment of the electronic device of the present application;

[0032] Figure 15 This is a schematic diagram of a framework of an embodiment of a computer-readable storage medium of the present application. DETAILED DESCRIPTION

[0033] The following describes the embodiments of the present application in detail with reference to the accompanying drawings.

[0034] In the following description, for the purpose of explanation rather than limitation, specific details such as specific system structures, interfaces, and technologies are provided to facilitate a thorough understanding of the present application.

[0035] The terms "system" and "network" are often used interchangeably in this document. The term "and / or" is simply a description of an association between related objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " generally indicates that the related objects are in an "or" relationship. Furthermore, "multiple" in this document refers to two or more than two.

[0036] See also Figure 1 , Figure 1 This is a flow chart of an embodiment of the data management method of the present application. The data management method in this embodiment specifically includes the following steps:

[0037] Step S11: Acquire the data to be written, arrange the data to be written based on the preset size of the codeword, and obtain a plurality of codeword data of the preset size.

[0038] This embodiment can be applied to the process of writing data to be written from a host to a storage device. The host may include a PC, a camera, a game console, a video recorder, or a mobile terminal. The storage device may include a solid-state drive or other storage device using Nand Flash as a storage medium.

[0039] After acquiring the data to be written, the data to be written is arranged based on the preset codeword size to obtain codeword data of multiple preset sizes. The preset codeword size can be determined based on the specific storage device type and / or the type of verification algorithm. For example, the data in the storage device will be arranged according to the LDPC code word size to obtain codeword data of the preset size, which can facilitate verification by the verification algorithm and storage on the storage device.

[0040] In one specific application scenario, for 16KB page size NAND, the current common code word size is 4KB+. In another specific application scenario, there are also solid-state drives that can support code words of 16KB+. The preset code word size is not limited here, but the size of the arranged code word data is the same and fixed, all of which are the preset size.

[0041] Step S12: deleting the recoverable data in each codeword data to expand the blank space of each codeword data.

[0042] In a code word data, when certain data can be calculated based on inherent rules, it means that these data can be recovered using the inherent rules, and these data are determined to be recoverable data. By deleting the recoverable data, the blank space of each code word data can be expanded.

[0043] After deleting the recoverable data in each codeword data, this step can not only expand the blank space of each codeword data, but also prevent data loss in the codeword data. Because the size of each codeword data is fixed to a preset size, the above deletion method can make more blank space for storing subsequent verification information. The more verification information in the codeword data used to store the verification algorithm, the stronger the error correction capability of the corresponding verification algorithm.

[0044] Step S13: using the blank space to perform data management, and writing each codeword data after data management into the storage device.

[0045] After the blank space of each codeword data is expanded, the blank space can be used for data management. For example, relevant data can be stored in the blank space based on actual needs to meet the needs.

[0046] In a specific application scenario, attribute information such as the unit information, type information, and generation time information of the data to be written can be written into the blank space to facilitate subsequent storage of the codeword data based on the relevant attribute information.

[0047] In a specific application scenario, the check information may also be stored in the blank space to improve the error determination capability of the codeword data and improve the reliability of data storage.

[0048] The specific utilization method of blank space can be set based on actual needs.

[0049] Through the above steps, the data management method of this embodiment arranges the data to be written based on the preset size of the codeword to obtain multiple codeword data of preset sizes; deletes the recoverable data in each codeword data to expand the blank space of each codeword data, then uses the blank space for data management, and writes each codeword data after data management to a storage device, thereby utilizing the expansion of the blank space to improve the adjustability of the codeword data, making it easier to adjust the codeword data based on storage requirements using the blank space to meet corresponding storage requirements.

[0050] In other embodiments, the step of using blank space for data management may specifically include verifying each code word data separately to obtain multiple verification information, storing each verification information in the blank space of the corresponding code word data to obtain multiple verified code word data; and writing the multiple verified code word data to a storage device.

[0051] After deleting the recoverable data in each codeword data, each codeword data is verified to obtain multiple verification information. Each codeword data corresponds to a verification information, which is used to perform error detection and data recovery on the codeword data, thereby improving the reliability of data storage.

[0052] In a specific application scenario, the verification algorithm of this step may include LDPC verification, and LDPC parity verification information is obtained by performing LDPC verification on each codeword data. In another specific application scenario, the verification algorithm of this step may include CRC verification and LDPC verification, and CRC verification is first performed on each codeword data to obtain CRC verification information, and then LDPC verification is performed on each codeword data to obtain LDPC parity verification information. The CRC verification information and LDPC parity verification information are combined to obtain verification information corresponding to each codeword data. The specific steps of verifying each codeword data separately are not limited here.

[0053] Each verification information is stored in the blank space of the corresponding code word data to obtain a plurality of verified code word data.

[0054] Since the recoverable information is deleted from the codeword data, more blank space is freed up. This allows more blank space to be used to store the check information. The more codeword data is used to store check information, the stronger the error correction capability. Therefore, the above method improves the error correction capability of the check algorithm, thereby improving data reliability.

[0055] The plurality of verified codeword data are written into the storage device to complete the writing of the data to be written.

[0056] After expanding the blank space of each codeword data, each codeword data is verified to obtain multiple verification information, and each verification information is stored in the blank space of the corresponding codeword data to obtain multiple verified codeword data. Finally, the multiple verified codeword data are written to a storage device. By deleting the recoverable data in each codeword data, there is more blank space for storing subsequent verification information, thereby utilizing the expansion of the blank space to increase the proportion of verification information in the corresponding codeword data, achieving the demand for improving the error correction capability of the verification algorithm, and thus improving the reliability of the data in the storage device. Moreover, deleting the recoverable data can not only expand the blank space of each codeword data, but also prevent the loss of other data in the codeword data, further ensuring the reliability of each codeword data.

[0057] See also Figure 2 , Figure 2 This is a flow chart of another embodiment of the data management method of the present application. The data management method in this embodiment specifically includes the following steps:

[0058] Step S21: Acquire the data to be written, and determine the format type of the recoverable data in the data to be written.

[0059] This embodiment can be applied to the process of writing data to be written from a host to a storage device. The host may include a PC, a camera, a game console, a video recorder, a mobile terminal, or other host devices. The storage device may include a solid-state drive or other storage device using Nand Flash as the storage medium.

[0060] See also Figure 3 , Figure 3 This is a schematic diagram of data flow in an implementation method of data writing.

[0061] This embodiment writes the data to be written from the host 31 to the solid-state drive 32. During the data writing process, the solid-state drive 32 utilizes a front-end interface 33, a memory 34, an adjustment module 35, an LDPC engine 36, and a NAND array 37. The LDPC engine 36 utilizes a scrambler 361, a CRC checksum 364, and an encoder 362.

[0062] The host 31 is connected to the front-end interface 33, and the front-end interface 33, memory 34, adjustment module 35, scrambler 361, encoder 362, and NAND array 37 within the solid-state drive 32 are connected in sequence. A controller (not shown) is also provided within the solid-state drive 32. The controller is connected to the front-end interface 33, memory 34, adjustment module 35, LDPC engine 36, and NAND array 37 to specifically control the operations of the front-end interface 33, memory 34, adjustment module 35, LDPC engine 36, and NAND array 37. The memory 34 may include SRAM (static random access memory) or DRAM (dynamic random access memory).

[0063] When writing data, the data to be written is obtained from the host 31, the format type of the recoverable data in the data to be written is determined through the front-end interface 33, and the front-end protocol is parsed for the data to be written. After parsing, the data is stored in the memory 34, and the data to be written is arranged based on the preset size of the codeword to obtain multiple codeword data of preset sizes. Then, the adjustment module 35 is used to delete the check protection data and reference data in the metadata of each codeword data based on the format type of the recoverable data to expand the blank space of each codeword data and improve the deletion accuracy of the check protection data and reference data. Then, the LDPC engine 36 performs randomization processing, first CRC check processing, and second LDPC check processing on each codeword data to obtain check information including a first check code and a second check code. Each check information is stored in the blank space of the corresponding codeword data to obtain multiple checked codeword data. Finally, the multiple checked codeword data are written to the NAND array 37.

[0064] The front-end interface 33 also transmits the format type of the recoverable data to the controller, so that the controller controls the adjustment module 35 and the LDPC engine 36 to perform targeted processing on the codeword data based on the format type of the recoverable data.

[0065] In this step, the data to be written is obtained from the host 31, and the format type of the recoverable data in the data to be written is determined through the front-end interface 33. The front-end interface 33 is a front end interface, which is used to parse the front-end protocol of the data to be written, such as the NVMe protocol or the Scsi protocol, to determine the format type of the recoverable data in the data to be written.

[0066] In a specific application scenario, in the definition of protocols such as the NVMe protocol or the Scsi protocol, the data to be written by the host consists of user data and metadata.

[0067] See also Figure 4 , Figure 4 It is a structural diagram of an implementation method of data to be written.

[0068] The data to be written 40 includes user data 41 and metadata 42. In this embodiment, the user data 41 and metadata 42 are arranged alternately in sequence.

[0069] See also Figure 5 , Figure 5 It is a structural diagram of another implementation method of data to be written.

[0070] The data to be written 50 includes user data 51 and metadata 52. In this embodiment, the user data 51 and metadata 52 are arranged separately.

[0071] Depending on the protocol specifications, metadata may be placed after user data or in a separate memory space. The metadata also includes Protection Information (PI), which may be located at the beginning or end of the metadata. The structure of the data to be written shown in this step is the structure of the data on host 31. Once written to SSD 32, its structure may be adjusted and changed.

[0072] Protection information can exist in at least three formats according to the protocol specification. For example, under the NVMe 2.0 protocol, there are three formats in total.

[0073] See also Figure 6 , Figure 6 It is a structural diagram of the first implementation method of protecting data.

[0074] The protection data 60 in this embodiment is in the 16-byte Guard Protection Information format, which is 8 bytes in total.

[0075] The protection data 60 consists of a 2-byte Guard field, a 2-byte Application Tag field, and a 4-byte Reference Tag field. The Guard field is used to verify the protection data, specifically the CRC (Cyclic Redundancy Check) checksum of the user data corresponding to the protection data 60, to ensure the integrity of the user data. The Application Tag field is used by the application software and is transparent to the storage controller. The Reference Tag field is reference data, such as the Logical Block Address (LBA) value or other information, to ensure that the user data is not misplaced during out-of-order transmission or routing.

[0076] LSB stands for Least Significant Bit, which is the least significant bit in binary numbers. Generally, the MSB is located on the leftmost side of a binary number, while the LSB is located on the rightmost side. MSB stands for Most Significant Bit, which is the most significant bit in a binary number. The MSB is the most heavily weighted bit, similar to the leftmost bit in a decimal number.

[0077] See also Figure 7 , Figure 7 It is a structural diagram of the second implementation method of protecting data.

[0078] The protection data 70 of this embodiment is in the format of 32-byte Guard Protection Information, which is 16 bytes in total.

[0079] Protection data 70 consists of a 4-byte Guard field, a 2-byte Application Tag field, and an 8-byte Storage and Reference Space field. The Guard field is verification protection data, specifically the CRC (Cyclic Redundancy Check) checksum corresponding to the user data in protection data 60, used to ensure the integrity of the user data. The Application Tag field is application data, used by application software and transparent to the storage controller. The Storage and Reference Space field is reference data, such as the Logical Block Address (LBA) value or other information, used to ensure that user data is not corrupted during out-of-order transmission or routing. It also provides an additional storage function compared to the Reference Tag field.

[0080] See also Figure 8 , Figure 8It is a structural diagram of the third implementation method of protecting data.

[0081] The protection data 80 of this embodiment is in the 64-byte Guard Protection Information format, which is 16 bytes in total.

[0082] Protection data 80 consists of an 8-byte Guard field, a 2-byte Application Tag field, and a 6-byte Storage and Reference Space field. The Guard field is the verification protection data, specifically the CRC (Cyclic Redundancy Check) checksum of the user data corresponding to protection data 60, used to ensure the integrity of the user data. The Application Tag field is application data, used by application software and transparent to the storage controller. The Storage and Reference Space field is reference data, such as the Logical Block Address (LBA) value or other information, used to ensure that user data is not corrupted during out-of-order transmission or routing. It also provides an additional storage function compared to the Reference Tag field.

[0083] From the three formats above, we can see that the protection information may be 8 or 16 bytes. The 16-byte format is only applicable when the logical block LBA address size of the data to be written by host 31 is greater than or equal to 4KB of codeword data. The Guard field in the recoverable data may be 2, 4, or 8 bytes. This means that in various protocols, the protection information specifications can define different sizes of Guard and Reference Tag fields for different applications. Consequently, when deleting recoverable data, the size of the data to be deleted will also vary accordingly.

[0084] In a specific application scenario, the format type of the recoverable data in the data to be written can be determined through the front-end interface 33 and then transmitted to the controller 38, so that the controller 38 controls the adjustment module 35 to delete based on the specific format of the protection information to achieve accurate deletion and avoid deleting too little or too much.

[0085] In another specific application scenario, namespaces are partitioned and formatted according to the format of the protection information. This means that different data layouts can be defined in different namespaces, thereby providing different levels of data protection for user data. Therefore, in different namespaces, the LDPC algorithm needs to use different code rates to design error correction algorithms. The LDPC engine 36 needs to support encoding and decoding methods for multiple code rates simultaneously, and the corresponding firmware must also make targeted considerations to accurately delete protection information of various formats, improving the accuracy of deleting recoverable data and ensuring the reliability of the improved error correction capabilities of the LDPC checksum algorithm.

[0086] Step S22: Arranging the data to be written based on the preset size of the codeword to obtain a plurality of codeword data of the preset size.

[0087] The data to be written is arranged based on a preset codeword size to obtain codeword data of multiple preset sizes. The preset codeword size can be determined based on the specific storage device type and the type of verification algorithm. In this embodiment, the preset codeword size is a fixed unit length required for LDPC encoding.

[0088] See also Figure 9 , Figure 9 It is a structural diagram of a codeword implementation method.

[0089] This embodiment uses a 16KB page size NAND as an example. Codeword 90 is 4KB+ in size, and its data layout includes user data 91 and additional information 92. User data 91 is 4KB, and additional information 92 includes metadata, checksums, and other supplementary information. The dummy portion is invalid information that cannot be included in codeword 90. This means that the default size in this embodiment is 4KB+.

[0090] In other embodiments, the codeword 90 may be 16KB+ in size, and the user data 91 may also be 16KB, i.e., the preset size in this embodiment is 16KB+. The preset size may be determined based on the codeword structure supported by the specific solid-state drive and is not limited here.

[0091] In this step, the data to be written is arranged based on the preset size of the codeword to obtain a plurality of codeword data of the preset size.

[0092] Step S23: deleting the recoverable portion of protection data in the metadata of each codeword data based on the format type of the recoverable data, so as to expand the blank space of each codeword data.

[0093] In a codeword data, when certain data can be calculated based on the inherent rules, it means that the data can be recovered using the inherent rules, and the data is determined to be recoverable data, and the recoverable data is deleted.

[0094] Specifically, firmware metadata cannot be compressed any more, but some fields of host metadata can be recovered through certain calculations, such as the checksum protection data in the Guard field and the reference data in the Reference Tag field.

[0095] See also Figure 10 , Figure 10 It is a specific structural diagram of an implementation method of codeword data.

[0096] The data in NAND will be arranged according to the size of LDPC Code Word. The codeword data 100 includes user data 121 and metadata 120. Metadata 120 includes host metadata 122, firmware metadata 133, a first check code position 134 (Seed & CRC) and a second check code position 135 (LDPC Parity). Host metadata 122 includes protection information 130 and Meta information 131. Protection information 130 includes check protection data 141 (Guard), application data 142 (Application Tag) and reference data 143 (Reference Tag). Among them, the first check code position 134 (Seed & CRC) and the second check code position 135 (LDPC Parity) in this diagram refer to the positions in the codeword data 100 for accommodating the corresponding check codes. When deleting recoverable data, the specific first check code and the second check code are not calculated. After they are calculated later, they are filled in the above positions accordingly.

[0097] In this step, the adjustment module 35 in the solid-state drive 32 deletes the recoverable portion of the protection data within the metadata of each codeword data 100. In a specific application scenario, the adjustment module 35 of the solid-state drive 32 includes Pichk, Stripe, and Shuffle. After each codeword data 100 is stored in the memory 34, the Pichk function of the adjustment module 35 first verifies the metadata 120 within each codeword data 100. If the metadata 120 verification succeeds, the Stripe function of the adjustment module 35 deletes the recoverable portion of the protection data within each metadata 120. The Shuffle function of the adjustment module 35 then adjusts the positional relationship between the deleted metadata 120 and the corresponding user data 121 to unify the format of the fixed codeword data 100. If the metadata 120 verification succeeds, no further processing is performed on the codeword data 100.

[0098] The recoverable portion of protection data in each metadata 120 is deleted based on the format type of the recoverable data. Specifically, the format of the protection information determined in the aforementioned step is used to determine the specific deletion location and size for deletion. This allows for targeted and precise deletion of protection information in various formats, improving the accuracy of recoverable data deletion and ensuring the reliability of the improved error correction capability of the LDPC checksum algorithm.

[0099] The step of deleting the partially restored protected data in each metadata 120 specifically includes first determining whether the logical block size of the data to be written is the same as the preset size. The logical block size of the data to be written refers to the unit data received from the host 31, which may be different from the preset size of the codeword data 100.

[0100] When the logical block size of the data to be written is the same as the preset size, it means that there is only one user data 121 in the arranged code data 100, and there is also only one corresponding reference data 143. The user data address is stored in the reference data 143. In one code data 100, at least one user data address is required for recovery calculation. Therefore, in this case, only the check protection data 141 (Guard) of the protection information 130 in each metadata 120 is deleted.

[0101] When the logical block size of the data to be written is different from the preset size, since the size of the unit data from the host 31 is the smallest, when the logical block size is different from the preset size, it means that the logical block size is smaller than the preset size, which means that the arranged codeword data 100 contains multiple user data 121, and the user data addresses within a codeword data 100 are stored continuously, that is, they can be obtained by reverse deduction through the user data addresses within a reference data 143. Therefore, in this case, the verification protection data 141 of the protection information 130 in each metadata 120 and part of the reference data 143 of the protection information in each metadata 120 can be deleted to retain at least one reference data 143 in the multiple metadata 120.

[0102] In a specific application scenario, any reference data 143 from the multiple metadata 120 can be retained, but preferably, the reference data 143 corresponding to the first user data 121 is retained so that when restoring the data, incremental calculation is sufficient, thereby improving the efficiency of data recovery.

[0103] See also Figure 11 , Figure 11 Schematic diagram of an embodiment of recoverable data deletion.

[0104] See also Figure 11 (11a), this diagram specifically reflects the specific data in the protection information (not marked in the figure) to improve the visualization of recoverable data deletion.

[0105] Codeword data 200 includes user data 210, checksum protection data 211, application data 212, reference data 213, metadata 216, a second checksum position 214, and other data 215. The second checksum position 214 is located at the end of codeword data 200. For ease of illustration, the firmware metadata and the first checksum position are both included in the other data 215. Each codeword data 200 corresponds to one copy of the other data 215 and one copy of the second checksum position 214.

[0106] This diagram illustrates deletion using a codeword data 200 including two user data 210 as an example, where one piece of user data 210 corresponds to one piece of protection information 230 and one piece of Meta data 216. Specifically, this embodiment deletes two pieces of verification protection data 211 and one piece of reference data 213, retaining at least one piece of reference data 213.

[0107] Please see further Figure 11 (11b) and (11c) respectively show two arrangements after deleting the recoverable data in the codeword data 200. (11b) arranges the data in sequence according to each user data 210 and its corresponding data. (11c) arranges the data in sequence according to the type of data. The above arrangement methods can be selected based on actual needs.

[0108] After deleting the check protection data 211 and part of the reference data 213 to retain at least one reference data 213, the blank space of each codeword data 200 is expanded, so that this part of the blank space can be used to store the second check code of LDPC, thereby increasing the storage space of the second check code of LDPC, and further improving the correction capability of LDPC.

[0109] The reason why checksum protection data 211 and part of reference data 213 can be deleted is that they can both be restored through rule-based calculations. Checksum protection data 211 is the CRC checksum information for the user data, which can be recalculated using the CRC checksum engine from the corresponding user data 210. Reference data 213 is address information. Since user data addresses within a code word are stored continuously, they can also be recalculated using a single reference data 213. Furthermore, routing errors and access path errors are prevented within a code word. Therefore, deleting these two data items does not weaken the protection of user data 210. Instead, it increases the storage space for LDPC checksum information, enhancing the LDPC error correction capability and thus improving the reliability of user data.

[0110] Step S24: performing randomization processing and first verification processing on each code word data in turn to obtain a first verification code for each code word data; performing second verification processing on each code word data to obtain a second verification code for each code word data; and determining the first verification code and the second verification code as verification information.

[0111] After the adjustment module 35 in the solid-state drive 32 deletes the recoverable portion of protected data, it inputs the deleted codeword data into the LDPC engine 36 for verification. Specifically, the codeword data is first randomized by the scrambler 361, and then the CRC check 364 performs a first check on the codeword data to obtain a first CRC check code for each codeword data. The CRC here protects the entire codeword data, while the Guard field previously described only protects user data. Because of this inclusion relationship, the first check code can also be used to ensure error correction and data restoration for user data.

[0112] The encoder 362 then performs a second check process of the LDPC check algorithm on each codeword data to obtain a second check code of each codeword data, namely, LDPC Parity; and the first check code and the second check code are determined as check information.

[0113] Among them, since the LDPC engine 36 already has the first check processing for CRC protection of the codeword data and the second check processing for LDPC protection, it can provide sufficient error correction capability for the data, and thus the deletion of the check protection information will not affect the reliability of the user data. Moreover, since the check protection information contains the CRC check code of the user data, it is included in the CRC check code of the entire codeword data processed by the first check. Therefore, the check protection information can be classified as duplicate data and can be deleted to expand the blank space. When the host reads the data subsequently, it needs to be restored and can be transmitted back to the host together with the user data after restoration so that the host can verify the correctness of the data.

[0114] Step S25: storing each verification information into the blank space of the corresponding code word data to obtain a plurality of verified code word data.

[0115] After obtaining the verification information, each verification information is stored in the blank space of the corresponding code word data to obtain multiple verified code word data. Figure 10 For example, the first check code and the second check code are stored in the corresponding first check code position 134 and the second check code position 135 respectively to obtain a plurality of checked code word data.

[0116] Among them, since the above-mentioned steps delete the deletion check protection data and part of the reference data in each codeword data, the blank space of each codeword data is expanded, so that the second check code position 135 of the LDPC in this step can have a larger space for storage, thereby increasing the storage space of the second check code of the LDPC, and further improving the correction capability of the LDPC.

[0117] Step S26: writing the plurality of verified codeword data into a storage device.

[0118] The codeword data verified by the LDPC engine 36 is written into the NAND array 37, completing the writing of the data to be written.

[0119] Through the above steps, the data management method of this embodiment obtains the data to be written, determines the format type of the recoverable data in the data to be written, arranges the data to be written based on the preset size of the codeword, obtains multiple codeword data of preset size, deletes the check protection data and reference data in the metadata of each codeword data based on the format type of the recoverable data to expand the blank space of each codeword data and improve the accurate deletion of the check protection data and reference data, then performs randomization processing, first check processing, and second check processing on each codeword data in sequence to obtain check information including a first check code and a second check code, stores each check information in the blank space of the corresponding codeword data, obtains multiple checked codeword data, and writes the multiple checked codeword data to a storage device. By deleting the check protection data and reference data in each codeword data, more blank space can be used to store subsequent LDPC check information, thereby increasing the proportion of check information in the corresponding codeword data, improving the error correction capability of the LDPC check algorithm, and thereby improving the reliability of data in the storage device. Furthermore, deleting the recoverable check protection data and reference data can not only expand the blank space of each code word data, but also prevent data loss in the code word data, thereby further ensuring the reliability of each code word data.

[0120] See also Figure 12 , Figure 12 FIG. 1 is a flow chart of an embodiment of reading codeword data.

[0121] Step S31: Obtain verified codeword data from a storage device.

[0122] Step S32: padding the verified codeword data to obtain each codeword data, so as to read each codeword data.

[0123] The check protection data of each code word data is obtained by performing a first check process on the user data of the corresponding code word data.

[0124] Specifically, a first CRC check process is performed on the user data of each codeword data to obtain check protection data of each codeword data; and each reference data in the multiple metadata is calculated and restored based on the continuity of at least one reference data in the retained multiple metadata to obtain the reference data of each metadata. Finally, each verified codeword data is padded with each check protection data and the reference data of each metadata to restore each codeword data so as to read each codeword data.

[0125] See also Figure 13 , Figure 13 This is a schematic diagram of data flow in an implementation method of reading data.

[0126] This embodiment reads codeword data from a solid-state drive 32 into a host 31. During the data reading process, the solid-state drive 32 utilizes a front-end interface 33, a memory 34, an adjustment module 35, an LDPC engine 36, and a NAND array 37. The LDPC engine 36 utilizes a CRC check 364, a descrambler 363, and a decoder 366.

[0127] The host 31 is connected to the front-end interface 33, and the front-end interface 33, memory 34, adjustment module 35, descrambler 363, CRC check 364, decoder 366, and NAND array 37 within the solid-state drive 32 are sequentially connected. A controller (not shown) is also provided within the solid-state drive 32. The controller is connected to the front-end interface 33, memory 34, adjustment module 35, LDPC engine 36, and NAND array 37 to specifically control the operations of the front-end interface 33, memory 34, adjustment module 35, CRC check 364, LDPC engine 36, and NAND array 37.

[0128] When reading data, the codeword data is obtained from the NAND array 37 and transmitted to the LDPC engine 36. The codeword data is first decoded by the decoder 366, and then the check protection information is recalculated by the CRC check 364. The codeword data is then descrambled by the descrambler 363, and the reference data is supplemented by the adjustment module 35. The check protection information and reference data are shuffled to the back of the corresponding user data, and the protection information is supplemented. Then, according to the protocol specification, it is transmitted back to the host 31 through the memory 34 and the front-end interface 33 to complete the complete reading of the data.

[0129] Through the above steps, the data deleted when writing data can be completely restored during the data reading process, thereby ensuring the smooth reading of data. The data management method of this embodiment can not only increase the storage space of the LDPC check code by deleting the recoverable data and improve the error correction capability of the LDPC, but also prevent data deletion from affecting data reading and improve data reliability.

[0130] See also Figure 14 , Figure 14 1 is a schematic diagram of a framework of an embodiment of an electronic device of the present application. Electronic device 1400 includes a memory 1401 and a processor 1402 coupled to each other. Processor 1402 is configured to execute program instructions stored in memory 1401 to implement the steps of the above-described method embodiment. In a specific implementation scenario, electronic device 1400 may include, but is not limited to, a microcomputer and a server. Furthermore, electronic device 1400 may also include a laptop, a tablet computer, a NandFlash, etc., without limitation herein.

[0131] Specifically, the processor 1402 is used to control itself and the memory 1401 to implement the steps of any of the above method embodiments. The processor 1402 can also be called a CPU (Central Processing Unit). The processor 1402 may be an integrated circuit chip with signal processing capabilities. The processor 1402 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. In addition, the processor 1402 can be implemented by an integrated circuit chip.

[0132] The above solution can improve the error correction capability of the verification algorithm, thereby improving the reliability of data in the storage device.

[0133] See also Figure 15 , Figure 15 This is a schematic diagram of a framework of an embodiment of a computer-readable storage medium of the present application. The computer-readable storage medium 1500 stores program instructions 1501 that can be executed by a processor, and the program instructions 1501 are used to implement the steps of any of the above method embodiments.

[0134] In the several embodiments provided in this application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device implementation methods described above are only schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation. For example, units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.

[0135] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0136] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0137] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute all or part of the steps of each embodiment method of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0138] The above description is only an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made by using the contents of the description and drawings of the present invention, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A data management method, characterized in that: The data management method includes: Acquire data to be written, arrange the data to be written based on a preset codeword size to obtain a plurality of codeword data of a preset size, wherein each codeword data includes user data and metadata, and each metadata includes protection information; wherein a format type of recoverable data in the data to be written is determined; Deleting the recoverable data in each of the codeword data to expand the blank space of each of the codeword data; wherein the recoverable partial protection data in each of the metadata is deleted based on the format type of the recoverable data to expand the blank space of each of the codeword data; The blank space is used for data management, and the codeword data after data management is written into a storage device.

2. The data management method according to claim 1, characterized in that: The step of deleting the recoverable portion of the protection data in each metadata to expand the blank space of each codeword data includes: Verifying metadata in each codeword data; When the metadata verification succeeds, the recoverable partial protection data in each metadata is deleted to expand the blank space of each codeword data, and the positional relationship between the deleted metadata and the corresponding user data is adjusted to unify the format of the codeword data.

3. The data management method according to claim 2, characterized in that: Each of the protection information includes verification protection data, application data and reference data; The step of deleting the recoverable portion of protected data in each metadata includes: In response to the logical block size of the data to be written being the same as the preset size, deleting the verification protection data of the protection information in each metadata; In response to the logical block size of the data to be written being different from the preset size, the verification protection data of the protection information in each metadata and part of the reference data of the protection information in each metadata are deleted to retain at least one reference data in the plurality of metadata.

4. The data management method according to claim 1, characterized in that: The step of utilizing the blank space for data management and writing each codeword data after data management into a storage device includes: Verifying each of the codeword data to obtain a plurality of verification information, and storing each of the verification information in a blank space corresponding to the codeword data to obtain a plurality of verified codeword data; Writing a plurality of verified codeword data into the storage device.

5. The data management method according to claim 4, characterized in that: The step of respectively verifying each of the codeword data to obtain a plurality of verification information comprises: performing randomization processing and first verification processing on each of the code word data in sequence to obtain a first verification code for each of the code word data; Performing a second check process on each of the code word data to obtain a second check code for each of the code word data; The first verification code and the second verification code are determined as the verification information.

6. The data management method according to claim 5, characterized in that: The data management method further includes: Obtaining verified codeword data from the storage device; The verified code word data are padded to obtain the code word data, so as to read the code word data.

7. An electronic device, characterized in that: The system comprises a memory and a processor coupled to each other, wherein the processor is used to execute program instructions stored in the memory to implement the data management method according to any one of claims 1 to 6.

8. A computer-readable storage medium having program instructions stored thereon, characterized in that: When the program instructions are executed by a processor, the data management method according to any one of claims 1 to 6 is implemented.

Images