Data protection method for solid state disk and solid state disk

Abstract

The invention relates to the technical field of hard disks, in particular to a data protection method of a solid state disk and the solid state disk, the method comprises the steps that a flash memory medium is divided into a data block area, a log block area and a metadata area, and the metadata area comprises a mapping directory, a mapping block and a check point block; a block mapping table and a log page mapping table are established in a volatile memory, and dbMSN and lbMSN are stored. Adding write-in data to a log block page, updating a log page mapping table, and generating check points according to full writing of a log area. When no free page exists, the damaged log blocks are selected in a rotating mode to be combined, new data block migration pages are distributed, mapping is updated, the MSN is progressively increased, changes are written into the mapping blocks, and the mapping catalogue is updated when the mapping blocks are addressed. After restarting, positioning a mapping block by a mapping directory to recover block mapping, reading check points in a reverse order, and traversing an uncovered log area to reconstruct log page mapping; and comparing the dbMSN with the lbMSN, setting inconsistent log pages to be invalid, establishing consistent access and shielding invalid pages. According to the method and the device, the problems of data consistency and availability caused by metadata loss, uncertain merging state and low recovery efficiency of the hybrid mapping FTL in a crash scene can be solved.

Description

Technical Field

[0001] This invention relates to the field of hard disk technology, and in particular to a data protection method for solid-state drives (SSDs) and a solid-state drive. Background Technology

[0002] Solid-state drives (SSDs) typically use flash memory as the storage medium and manage the mapping from logical addresses to physical addresses through a flash translation layer (FTL). To balance random write performance and mapping overhead, hybrid mapping FTLs generally employ a data block plus log block structure: newly written data is first appended to the log block, and then a merge operation migrates the latest data page to the data block and reclaims the log block. This type of mechanism is prone to two problems during abnormal power outages or system crashes: First, critical metadata such as the block mapping table and log page mapping table are often partially located in volatile memory, and their loss after a crash makes it impossible to directly recover the logical page to physical page relationship; second, the merge and reclamation may be in an intermediate state before and after the crash, resulting in log page records that have been merged but still remain in the log block. If the recovery strategy is inappropriate, it can lead to inconsistent metadata, reading old data, or excessively long recovery times.

[0003] Existing data protection and recovery solutions often rely on full disk scanning, frequent write checkpoints, or the introduction of additional writes / merges during the recovery phase. These solutions are prone to drawbacks such as long recovery times, high runtime overhead, or instability under secondary crashes, making it difficult to simultaneously meet consistency and efficiency requirements in hybrid mapping scenarios. Summary of the Invention

[0004] In view of the above technical problems, the present invention provides a data protection method and solid-state drive (SSD) for solid-state drives (SSDs). Applied to the flash media management layer of the SSD, it establishes a persistent metadata structure of mapping directories, mapping blocks, and checkpoint blocks, and performs consistency verification based on the comparison of data block merge sequence numbers and log block merge sequence numbers. This enables rapid recovery of block mapping relationships and log page mapping relationships after abnormal power loss or crash restart, avoiding the exposure of inconsistent or merged log pages. This solves the data consistency and availability problems caused by metadata loss, uncertain merge status, and low recovery efficiency in hybrid mapping FTLs during crash scenarios.

[0005] Other features and advantages of the invention will become apparent from the following detailed description, or may be learned in part by practice of the invention.

[0006] According to one aspect of the present invention, a data protection method for a solid-state drive (SSD) is proposed, applied to the flash memory media management layer of the SSD, the method comprising: The flash memory of the solid-state drive is divided into a data block area, a log block area, and a metadata area. The metadata area includes a mapping directory, mapping blocks, and checkpoint blocks. A block mapping table and a log page mapping table are established in the volatile memory of the solid-state drive. The block mapping table is used to record the correspondence between logical block numbers and physical block numbers and includes the data block merge sequence number. The log page mapping table is used to record the correspondence between logical page numbers and log block physical page addresses and includes the log block merge sequence number. The system receives write requests from the host and writes the write data to the free pages of the log block area to update the log page mapping table. When the log block area is full, the current global merge sequence number is recorded as the log block merge sequence number. The log block area is divided into multiple log regions. When any log region is full, the corresponding mapping information is written to the checkpoint block to form a checkpoint. When there are no free pages in the log block area, the victim log block is selected in a round-robin fashion and merged. A new data block is allocated and the latest page is copied. The block mapping table and the log page mapping table are updated. The current global merge sequence number is incremented. The current global merge sequence number when the merge is completed is recorded as the data block merge sequence number of the target data block. The changes in the block mapping table are written to the mapping block. When the physical block number of the mapping block changes, the mapping directory is updated and written. After the solid-state drive crashes and restarts, the latest mapped block is read through the mapped directory to restore the block mapping table; The checkpoint blocks are read in reverse order, and the log regions not covered by the most recent checkpoint are parsed at the page level to construct a temporary log page mapping table. The victim log block is determined by the smallest log block merge sequence number, and a consistency check is performed on the temporary log page mapping table: the log page records are traversed in reverse order of log blocks to obtain the data block merge sequence number of the data block corresponding to each log page and compared with the log block merge sequence number of the log block where the log page is located. When the data block merge sequence number is greater than the log block merge sequence number, the log page is set to invalid, and a consistent log page mapping table is obtained. Based on the consistent log page mapping table and block mapping table, accessibility protection processing is performed on the user data in the solid-state drive. The physical page corresponding to the log page that is determined to be invalid is marked as unreadable and cannot participate in host read requests. The physical page corresponding to the log page that is determined to be valid establishes a consistent logical page to physical page access relationship with the latest physical page in its corresponding data block, so that the solid-state drive can only provide user data in a consistent state after abnormal power failure or crash.

[0007] Furthermore, each log region in which the log block area is divided consists of a predetermined number of log blocks. The predetermined number is determined such that the logical page number information for the log region in the log page mapping table and the log block merging sequence number can be encapsulated and written into a single physical page. The checkpoint block uses a sequential append-writing method to write checkpoints, so that the checkpoint block can be read in reverse order.

[0008] Furthermore, changes to the block mapping table include at least one of the following triggering conditions: The merging process causes a change in the mapping from logical block number to physical block number of the target data block; After the victim log blocks are merged, new log blocks are allocated from the free block list, which causes a change in the mapping from the logical block number to the physical block number of the log blocks. When the checkpoint block is full, a new checkpoint block is allocated from the free block list, causing the corresponding physical block number to change; and when the block mapping table change is detected, the relevant entries containing the data block merge sequence number are written to the mapping block on a page-by-page basis.

[0009] Furthermore, when the mapping information for the data block area in the block mapping table cannot be completely stored within a physical page, the data block area is divided into multiple data regions, and a corresponding mapping block logical area is allocated to each data region. When the mapping of any data block changes, only the block mapping information corresponding to the data region containing that data block is written to the next free page of the mapping block associated with the data region, so as to avoid a full refresh write of the entire block mapping table.

[0010] Furthermore, the mapping directory is located at a predetermined fixed physical location on the flash memory medium of the solid-state drive, and is used to store the physical block number allocation information of the mapping block; when the mapping block is full and a new physical block needs to be allocated to the mapping block, the allocation information is first updated in the mapping directory and written to the mapping directory in units of pages, and then the block mapping table change is written in the new mapping block; and the mapping directory reserves at least one redundant physical block for bad block replacement.

[0011] Furthermore, when writing the write data to the free page of the log block area, the corresponding logical page number is also written to the spare area of ​​the physical page; when traversing and parsing the log area that was not covered by the most recent checkpoint, the entries of the log area that was not covered by the most recent checkpoint in the temporary log page mapping table are reconstructed by reading the logical page number in the spare area.

[0012] Furthermore, the log block with the smallest log block merge sequence number is selected from the temporary log page mapping table as the victim log block; the temporary log page mapping table is scanned in reverse order of log block rotation, and consecutive logical page numbers belonging to the same data block are grouped together to perform a block mapping table query to obtain the data block merge sequence number of the corresponding data block; when the data block merge sequence number is greater than the log block merge sequence number of the log block carrying the group of log pages, the logical page number corresponding to the group of log pages is uniformly rewritten to a predetermined invalid flag to indicate that it has been merged, wherein the predetermined invalid flag is -1.

[0013] Furthermore, the metadata writing of the checkpoint block, the mapping block, and the mapping directory is all done with a single flash physical page as the atomic write unit, and verification information is recorded in each physical page to determine whether the metadata page of the metadata area has been completely written after power failure or crash; and during the recovery process, metadata update writing is not performed on the flash media of the solid-state drive.

[0014] According to another aspect of the present invention, a solid-state drive is provided, which stores a computer program that, when executed by a processor, implements the data protection method for the solid-state drive as described above.

[0015] The technical solution of the present invention has the following beneficial effects: By dividing the log block area into log regions and generating checkpoints when the log regions are full, the recovery phase only needs to read the checkpoints in reverse order and perform page-level traversal and parsing of the log regions not covered by the most recent checkpoint, thereby significantly reducing the scan range and reducing the recovery time. By maintaining the current global merge sequence number during the merge process and recording it as the data block merge sequence number and the log block merge sequence number respectively, the merged residual log pages are determined and invalidated by the comparison rules of the two during recovery, thus eliminating the risk of metadata inconsistency caused by merge interruption from a mechanism perspective. By mapping block carrying block mapping table changes and mapping directory only updating when the physical block number of the mapping block changes, metadata write amplification is reduced and persistence reliability is improved; at the same time, metadata update writing is not performed on the flash media during the recovery process, making the recovery process read-only and re-executable, reducing the risk of secondary crashes, and ultimately ensuring that the solid-state drive only provides a consistent state of user data access relationship to the outside world, achieving a balance between data protection and system availability. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a data protection method for a solid-state drive as described in the embodiments of this specification; Figure 2 This specification describes a solid-state drive (SSD) that stores a data protection method for SSDs, as exemplified in this embodiment. Detailed Implementation

[0017] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided to make the invention more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a full understanding of embodiments of the invention. However, those skilled in the art will recognize that the technical solutions of the invention may be practiced with one or more of these specific details omitted, or other methods, components, systems, steps, etc., may be employed. In other instances, well-known technical solutions are not shown or described in detail to avoid obscuring various aspects of the invention.

[0018] Furthermore, the accompanying drawings are merely illustrative of the invention. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor systems and / or microcontroller systems.

[0019] This invention provides a data protection method for solid-state drives (SSDs). (Refer to...) Figure 1 The diagram shown is a flowchart illustrating a data protection method for a solid-state drive (SSD) according to an embodiment of the present invention. This method can be applied to electronic devices such as personal computers and servers. The method can be executed by a system, which can be implemented by software and / or hardware. The method is applied to the flash memory media management layer of the SSD, and specifically includes the following steps S101-S107: In step S101, the flash memory medium of the solid-state drive is divided into a data block area, a log block area, and a metadata area. The metadata area includes a mapping directory, mapping blocks, and checkpoint blocks. A block mapping table and a log page mapping table are established in the volatile memory of the solid-state drive. The block mapping table is used to record the correspondence between logical block numbers and physical block numbers and includes the data block merge sequence number. The log page mapping table is used to record the correspondence between logical page numbers and log block physical page addresses and includes the log block merge sequence number.

[0020] The flash memory medium is logically divided into a data block area, a log block area, and a metadata area. User data is primarily stored in the data block area, while the log block area serves as a buffer for sequential appending of newly written data. System information, especially address mapping information, is stored in the metadata area. The metadata area is further divided into a mapping directory, mapping blocks, and checkpoint blocks: mapping blocks record updated block-level mapping information into the flash memory when mapping change events occur, preventing data loss after power failure due to reliance on volatile memory; the mapping directory stores the block-level mapping information of mapping blocks, allowing the tracking of physical location changes of mapping blocks when they become full and require allocation; and checkpoint blocks periodically record partial information from the log page mapping table in a checkpoint manner, facilitating priority recovery of the most recent log page mapping state after a failure and reducing the scan range and time during recovery.

[0021] To support address translation using hybrid mapping, a block mapping table and a log page mapping table are established in volatile memory. The block mapping table performs the mapping conversion from logical block number to physical block number; for example, the logical block number LBN can be mapped to the physical block number PBN, thereby locating the data block in the data block area. The log page mapping table is used to store page-level mapping information, recording the correspondence between logical page numbers and log block physical page addresses, so as to quickly locate the most recently written updated page in the log block area. Considering that the block mapping table may be large and the mapping update has locality, the data block area can be organized by data region. This way, when the data block mapping in a certain data region changes, only the block mapping information corresponding to that data region needs to be output and written to the mapping block associated with that data region, thereby reducing metadata write overhead and reducing flash write amplification.

[0022] These two mapping tables introduce the data block merge sequence number (dbMSN) and the log block merge sequence number (lbMSN) respectively, used to determine whether log pages are still valid during subsequent recovery and consistency checks. The lbMSN is attached to the log block level, semantically similar to a timestamp, used to characterize the time when the log block was created or began carrying new writes; the dbMSN is attached to the data block level, allowing us to know the time when the data block was created and when the pages within that data block were merged. Based on these two sequence numbers, log page validity can be determined; a log page can be considered valid if the following relationship is satisfied: The meaning of this relationship is that when the data block corresponding to a certain log page is generated or updated at a later time through merging (with a larger dbMSN), the log page is likely to belong to the old state before the merge. It needs to be identified and processed as invalid during the recovery phase to avoid providing inconsistent data to the outside world.

[0023] The settings of mapping blocks and checkpoint blocks are also closely coordinated with the subsequent recovery path: mapping changes are recorded in the mapping blocks to ensure that the block mapping information is persistent; checkpoint blocks periodically record part of the log page mapping table information, and because log data is written sequentially in the log block area and the affected objects are selected in a round-robin manner when the log blocks are merged, the log page mapping state before the failure can be restored by reading the mapping records appended sequentially in the checkpoint blocks in reverse order after the failure, and then the uncovered parts can be traversed, parsed and filled in.

[0024] In step S102, a host write request is received and the write data is written to the free page of the log block area to update the log page mapping table. When the log block area is full, the current global merge sequence number is recorded as the log block merge sequence number. The log block area is divided into multiple log regions. When any log region is full, the corresponding mapping information is written to the checkpoint block to form a checkpoint.

[0025] Each log region, into which the log block area is divided, consists of a predetermined number of log blocks. The predetermined number is determined such that the logical page number information for the log region in the log page mapping table and the log block merging sequence number can be encapsulated and written into a single physical page. Subsequently, the checkpoint block uses a sequential append-writing method to write checkpoints, enabling the checkpoint block to be read in reverse order.

[0026] Here, step S102 sequentially appends data to the log block area along the host write path and synchronously updates the log page mapping table in memory. After the host initiates a write request, the write data is directed to the currently available free physical page in the log block area, and the write follows an append method to achieve continuous write characteristics. Each time a new write is placed on a log block, the corresponding logical page number is added to the logical page number list of that log block in the log page mapping table, thus forming a page-level mapping relationship between logical page numbers and log block physical page addresses. To facilitate subsequent traversal, parsing, and recovery of the mapping relationship, the logical page number can also be recorded along with the page address information in the spare area of ​​the physical page when writing data pages. This allows the logical page number information associated with the page to be quickly reconstructed by reading the page content or the spare area even if memory information is lost under abnormal circumstances. The log block merge sequence number is provided by the global merge sequence number, which is semantically similar to a timestamp: the global merge sequence number is a global variable representing the total count of merges that have been performed, and it monotonically increases with each merge operation; when the last page of a log block is written to flash memory, the global merge sequence number at that time is written to the log block as the log block merge sequence number, and the log block merge sequence number is saved in the log page mapping table residing in memory, so that the write boundary and generation time of the log block are traceable, and provide guidance for determining whether the log pages are in a consistent state during subsequent fault recovery.

[0027] To reduce write amplification in log page mapping table persistence and shorten recovery time after anomalies, log blocks are logically further divided into multiple log regions, with checkpoints generated at the log region level. The size of a log region is determined by the ability to package log page mapping table information into a single physical page: when all pages of log blocks within a certain log region have been continuously written and exhausted by the upper layer, the portion of the log page mapping table information corresponding to that log region is output to the checkpoint block region, forming a checkpoint; the same action is then repeated for subsequent log regions. This approach differs from the strategy of flushing the entire table to flash memory every time the log page mapping table is updated, as the latter is too costly and lacks scalability in high-capacity storage systems. The unit of checkpoint is equivalent to the log region size. The configuration goal is to ensure that the logical page number information related to the log region, along with the log block merge sequence number, can be encapsulated and written in a single physical page, thus ensuring the atomicity of metadata writing with pages as the atomic write unit; in the event of a system failure, page-level atomicity can be determined by the controller-side verification mechanism to determine whether the page has been completely written. For example, when the physical page size is 4 KB, the block size is 512 KB, and a single logical page number in the log page mapping table occupies 4 B, a single physical page can hold approximately 1024 logical page numbers. Therefore, a log region can consist of 8 log blocks, each containing 128 pages. The mapping updates added between two checkpoints are only retained in memory and will be lost in the event of a failure, but can be quickly recovered during the recovery phase through traversal resolution.

[0028] Checkpoint blocks are written sequentially, with the mapping result corresponding to the log region being packaged and written to the next free page of the checkpoint block each time a checkpoint is formed, ensuring that the checkpoint information is physically contiguous. Because log block writing is sequential, and subsequent merging and reclamation selects affected log blocks in a round-robin manner, after a failure, the sequentially written checkpoint information can be read in reverse order to prioritize obtaining the most recent mapping state. This, combined with the log region boundary information, allows for the completion of updates after the most recent checkpoint. This approach balances runtime overhead and the need for rapid recovery after a failure without introducing frequent full table refreshes.

[0029] In step S103, when there are no free pages in the log block area, victim log blocks are selected in a round-robin fashion and merged. New data blocks are allocated and the latest pages are copied. The block mapping table and the log page mapping table are updated. The current global merge sequence number is incremented, and the current global merge sequence number when the merge is completed is recorded as the data block merge sequence number of the target data block. The changes in the block mapping table are written to the mapping block. When the physical block number of the mapping block changes, the mapping directory is updated and written.

[0030] As an explanation, the scenario triggered when there are no more free pages available in the log block area is explained. In this case, to reclaim writable space, the controller selects a victim log block from the log block set in a round-robin fashion and performs a merge around that victim log block. The merge is not performed on a single data block, because the valid pages within the victim log block may belong to multiple different logical data blocks. Therefore, multiple merge operations need to be performed consecutively on the same victim object. Each merge is performed on a target data block basis. First, the latest version of the corresponding logical pages of the target data block is collected from the victim log block, other log blocks, and the target data block itself. Then, these latest pages are copied to the newly allocated data block. After a merge is completed, the old data block becomes a useless block because its content has been migrated, and is ultimately reclaimed to the free block list along with the victim log block. Simultaneously, to maintain the consistency of page-level mapping, during the merge process, the corresponding records of log pages that have been migrated to the new data block in the log page mapping table are marked as invalid. A typical approach is to mark the corresponding logical page number entry as invalid. 1. This prevents the affected log block from being hit by subsequent address translations. After the affected log block is merged and reclaimed, a clean block is allocated from the free block list to supplement the log block pool and continue to carry subsequent writes. This will trigger the update of the relevant mapping entries for the log block.

[0031] The changes to the block mapping table include at least one of the following triggering conditions: The merging process changes the mapping from logical block number to physical block number of the target data block; after the victim log block is merged, a new log block is allocated from the free block list, causing the mapping from logical block number to physical block number of the log block to change; after the checkpoint block is full, a new checkpoint block is allocated from the free block list, causing the corresponding physical block number to change; and when the block mapping table is detected to change, the relevant entries containing the data block merging sequence number are written to the mapping block on a page-by-page basis.

[0032] When the mapping information for the data block area in the block mapping table cannot be completely stored in a single physical page, the data block area is divided into multiple data regions, and a corresponding mapping block logical area is allocated to each data region. When the mapping of any data block changes, only the block mapping information corresponding to the data region containing that data block is written to the next free page of the mapping block associated with that data region, so as to avoid a complete refresh of the entire block mapping table.

[0033] After the merge is completed, the block mapping table and log page mapping table need to be updated. The block mapping table includes at least the update of the correspondence between logical block numbers and physical block numbers. For example, the mapping changes when the target data block is migrated from an old physical block to a new physical block; the replacement of a victim log block with a newly allocated free block also changes the physical block number entry corresponding to the log block; in addition, when a checkpoint block region is exhausted due to continuous writing and needs to be swapped with a new free block, the physical block number corresponding to the checkpoint block also changes, which is also a situation where the block mapping table needs to be updated. To ensure the time-order traceability of the merge process and support subsequent consistency determination, the current global merge sequence number MSN is introduced as a monotonically increasing global variable, which increments once with each merge operation. When the merge of a target data block is completed, the MSN at that time is written to the corresponding entry of the target data block as the data block merge sequence number dbMSN, and the block mapping table information containing dbMSN is stored in the memory-resident block mapping table. In determining the validity of log block merge sequence number lbMSN and data block merge sequence number dbMSN, log pages that satisfy the following formula can be considered to be still valid at the point of failure: ; Conversely, if the conditions are met ; If the log page has already been merged and overwritten at a later time, it can be considered invalid. The above formula ensures that the merge sequence number not only records the merge progress but also provides a direct comparison basis for subsequent recovery phases. Therefore, persisting the dbMSN along with the block mapping information at the end of the merge is crucial.

[0034] The persistence of the block mapping table is achieved through mapping blocks: whenever any of the aforementioned mapping changes occur, the changed relevant block mapping information is output and written to the mapping block. The block mapping table is split into parts and placed into pages within the mapping blocks, ensuring the atomicity of metadata writing and reducing runtime overhead. Considering that the block mapping information for the data block portion of large-capacity flash memory may not fit into a single physical page, the data block area can be further divided into multiple data regions of the same size, and a corresponding mapping block logical area is allocated to each data region. When the mapping of a data block changes, only the block mapping information corresponding to the data region containing that data block is output to the next free page of the mapping block bound to that data region, avoiding refreshing the entire block mapping table with every change and reducing write amplification. The mapping directory stores the block-level location information of mapped blocks and is located in a fixed location. When a mapped block is full and a new physical block needs to be allocated to continue the mapping block's function, the physical block number of the mapped block changes. At this time, the mapping directory is updated and written to flash memory, so that the system can access the mapping directory to locate the mapping block where the latest block mapping information is located during subsequent startup or fault recovery, thereby completing the reliable connection and tracking of block mapping information. In step S104, after the solid-state drive crashes and restarts, the latest mapping block is read through the mapping directory to restore the block mapping table.

[0035] The mapping directory is located at a predetermined fixed physical location on the flash memory medium of the solid-state drive and is used to store the physical block number allocation information of the mapping block. When the mapping block is full and a new physical block needs to be allocated to the mapping block, the allocation information is first updated in the mapping directory and written to the mapping directory in units of pages, and then the block mapping table change is written in the new mapping block. The mapping directory also reserves at least one redundant physical block for bad block replacement.

[0036] Step S104 occurs in the early stages of power-on restart after a crash. At this time, the block mapping table in the volatile memory has been lost, and the controller cannot rely on any logical-to-physical mapping information for addressing. Therefore, it can only directly access the mapping directory from a pre-agreed fixed physical location. During startup, the allocation information stored in the mapping directory is first read to determine which physical blocks the current mapping block used to store the block mapping information resides on. During the reading process, directory page content is retrieved in units of physical pages, and the CRC / ECC check on the controller side is used to determine whether the directory page is a valid page that has been completely written. If multiple pages exist, the most recently written and verified directory page is used as the valid directory information, thus obtaining the set of available mapping block physical block numbers. When a bad block is encountered, it is replaced according to the reserved redundant physical blocks to ensure that the directory can be read stably.

[0037] After obtaining the physical block number of the mapped block, the block mapping information in the mapped block is read according to the physical location given in the directory to restore the block mapping table. The mapped block records the block mapping data output to flash memory due to mapping changes during runtime. It is a persistent carrier of the updated content of the block mapping table. Therefore, during restoration, by reading the valid pages that have been written in the mapped block, the correspondence between logical block numbers and physical block numbers can be reconstructed, and the merge sequence number (dbMSN) field related to the data block can be restored synchronously, so that the block mapping table returns to the most recently persisted state. Since mapping changes occur after merging, after log blocks are reclaimed and reallocated, and after checkpoint blocks are full and new physical blocks are allocated, the corresponding records in the mapped block are usually written page by page in an append-only manner. Therefore, during restoration, the mapped block can be reloaded into the memory structure in the order of writing. When the mapping information is split and output by data region, only the mapping records of the data region containing the target data block need to be loaded to complete the block mapping restoration of that data region, avoiding the unnecessary overhead of loading the entire block mapping table at once.

[0038] To ensure unambiguous pointer relationships between directories and mapping blocks before and after a crash, when a mapping block is full and a new physical block needs to be allocated to continue its mapping function, a directory-first, mapping block-later write order is adopted: first, the allocation information of the new mapping block's physical block number is written to the mapping directory and persisted to disk in pages; then, subsequent block mapping table changes are written to the new mapping block. This way, even if a crash occurs during the switchover process, the latest mapping block location can still be directly located through the directory after startup, avoiding the broken state where the directory still points to the old mapping block while the new mapping block has already begun carrying update records. Simultaneously, redundant physical blocks reserved in the directory are used for bad block replacement, ensuring that the directory at a fixed location remains readable throughout its lifespan, thus guaranteeing a stable entry point for the block mapping table recovery process.

[0039] In step S105, the checkpoint block is read in reverse order, and the log area not covered by the most recent checkpoint is parsed at the page level to construct a temporary log page mapping table.

[0040] Specifically, when writing the write data to the free page of the log block area, the corresponding logical page number is also written to the spare area of ​​the physical page; when traversing and parsing the log area that was not covered by the most recent checkpoint, the entries of the log area that was not covered by the most recent checkpoint in the temporary log page mapping table are reconstructed by reading the logical page number in the spare area.

[0041] Step S105 is used to restore the page-level mapping information in the log block area after a crash and restart. First, the most recently written log page mapping information is retrieved from the checkpoint block. Then, any new writes added after that checkpoint are parsed and completed. The checkpoint block uses sequential append writing, so newer checkpoints are closer to the end of the checkpoint block. Reverse reading starts from the last written physical page in the checkpoint block and reads page by page backwards. Page checksums are used to determine if a page is a complete and valid checkpoint record. Once the most recent valid checkpoint is located, the log area range contained in that checkpoint, the set of logical page numbers associated with these log areas, the corresponding log block physical page address information, and the merge sequence number associated with the log block are obtained. Based on this most recent valid checkpoint, the entries recorded in the checkpoint can be directly loaded into volatile memory, forming the basic part of a temporary log page mapping table, allowing the system to quickly recover to a near-latest page-level mapping state before the crash without performing a full disk scan.

[0042] Even after the most recent valid checkpoint, there may still be log regions whose data has not yet been written to the checkpoint block. These are log regions not covered by the most recent checkpoint and require page-level traversal parsing to complete the mapping information. Traversal parsing is performed on a log region-by-region basis: starting from the first log region after the boundary indicated by the most recent valid checkpoint, each written physical page of the log block within that log region is read page by page in the actual writing order, resolving to obtain the logical page number. Simultaneously, the physical block number and page number of the current physical page are combined to form the log block physical page address, and the correspondence between the logical page number and the log block physical page address is written to the temporary log page mapping table. Since the same logical page number may be updated multiple times in the log block region, traversal parsing should be based on the writing order, with later encounters of the same logical page number overwriting previous entries, thus ensuring that the temporary log page mapping table always points to the latest written version page. When the current write pointer position or the end of the log region is reached, the parsing of that log region ends, and the parsing of the next log region continues until all valid writes to all uncovered log regions are included in the temporary log page mapping table.

[0043] To ensure that traversal parsing does not rely on volatile information and can rebuild entries after a crash, the write path writes the data to the free pages of the log block area while simultaneously writing the corresponding logical page number to the spare area of ​​the physical page. This way, during the recovery phase, only the spare area needs to be read to obtain the logical page number, eliminating the need to parse the main data area content, resulting in lower read overhead and a more direct implementation. Furthermore, the logical page number and physical page address are naturally bound in the spare area, facilitating the rapid construction or updating of temporary log page mapping table entries during page-level traversal parsing. By combining reverse reading of checkpoint blocks with page-level traversal parsing of uncovered log areas, it is possible to maintain a relatively coarse-grained checkpoint write while still completing the logical-to-physical page relationship of the last segment written before the crash into the temporary log page mapping table, providing complete input for subsequent consistency checks and access relationship protection processing.

[0044] In step S106, the victim log block is determined by the smallest log block merge sequence number, and a consistency check is performed on the temporary log page mapping table: the log page records are traversed in reverse order of log blocks to obtain the data block merge sequence number of the data block corresponding to each log page and compared with the log block merge sequence number of the log block where the log page is located. When the data block merge sequence number is greater than the log block merge sequence number, the log page is set to invalid, and a consistent log page mapping table is obtained.

[0045] Specifically, the log block with the smallest merge sequence number is selected from the temporary log page mapping table as the victim log block; the temporary log page mapping table is scanned in reverse order of log block rotation, and consecutive logical page numbers belonging to the same data block are grouped together to perform a block mapping table query to obtain the data block merge sequence number of the corresponding data block; when the data block merge sequence number is greater than the log block merge sequence number of the log block carrying the group of log pages, the logical page number corresponding to the group of log pages is uniformly rewritten to a predetermined invalid flag to indicate that it has been merged, wherein the predetermined invalid flag is -1.

[0046] The purpose of step S106 is to correct the temporary log page mapping table to a state consistent with the time of the crash, ensuring that log pages already merged into new data blocks are not considered valid data after recovery. To achieve this, the victim log block at the time of the crash is first located from the temporary log page mapping table. Specifically, the log block with the smallest merge sequence number (lbMSN) is identified as the victim. The reason for using the smallest lbMSN is that log block reclamation and selection follow a round-robin method; a smaller lbMSN indicates an earlier creation time, corresponding to the oldest log block in the round-robin context, thus aligning with the log block that should have been selected as the victim at that time. When further determining how many merges have occurred within the victim log block, an auxiliary query can be performed using the largest dbMSN in the block mapping table to infer which logical pages within the victim log block have triggered merges and completed migration, thus providing a boundary reference for subsequent reverse-order scanning in the round-robin manner.

[0047] Consistency checks employ a validity criterion based on merge sequence numbers. Each log page record is compared, and those that do not meet the criteria are invalidated. The validity determination uses the formula described above. The temporary log page mapping table is scanned in reverse order of log block rotation, and within each log block, it is traversed in reverse order of log page records. For each record, its corresponding data block is first determined, and the dbMSN is obtained from the block mapping table. Then, it is compared with the lbMSN of the log block containing the record. When the conditions are met... When this occurs, it indicates that the log page was written after the most recent merge of the corresponding data block, but has not yet been merged into the data block, and the record remains valid; when this occurs... If this happens, it means that the corresponding data block has already absorbed the log page or its updated version in a later merge. At the time of the crash, this log page should be considered a merged remnant, and the log page record needs to be invalidated. Invalidation is achieved by uniformly rewriting the logical page number corresponding to the log page record with a predefined invalidation flag. 1. This ensures that subsequent address translations will not hit these merged records, thus resulting in a consistent log page mapping table.

[0048] Since querying the dbMSN from the block mapping table for each log page record incurs high overhead, a grouping optimization is introduced during the consistency check process: When scanning the temporary log page mapping table in reverse order, consecutive logical page numbers belonging to the same data block are grouped together. Only one block mapping table query is performed on this group to obtain the dbMSN. Then, the same dbMSN is reused to compare each log page record within the group with the lbMSN of its corresponding log block. If the group's dbMSN is not greater than the lbMSN, the records in the group remain unchanged; if the dbMSN is greater than the lbMSN of the log block containing the log pages in this group, the entries corresponding to the logical page numbers in this group are rewritten all at once. 1. By grouping data by blocks and reducing the number of table lookups, the random access cost of the block mapping table during the consistency check phase can be reduced without changing the decision rules and scan order, while ensuring that the output log page mapping table is consistent with the merged state at the time of the crash.

[0049] In step S107, based on the consistent log page mapping table and the block mapping table, accessibility protection processing is performed on the user data in the solid-state drive. The physical pages corresponding to the log pages that are determined to be invalid are marked as unreadable and cannot participate in host read requests. The physical pages corresponding to the log pages that are determined to be valid establish a consistent logical page to physical page access relationship with the latest physical page in their corresponding data blocks, so that the solid-state drive can only provide consistent user data to the outside world after abnormal power failure or crash.

[0050] Step S107 is executed after the consistent log page mapping table has been obtained. Its goal is to convert the recovered mapping information into read access relationships that the host can directly use, and to shield log pages deemed invalid during consistency checks, preventing the host from reading old versions or data in an intermediate state. The accessibility protection process starts from the logical page number, assigning a unique readable physical page address to each logical page number. It prioritizes checking the consistent log page mapping table to determine if a valid log page record exists for that logical page: if the entry corresponding to that logical page number in the log page mapping table has a predetermined invalid identifier... If a logical page is marked as invalid, it will no longer provide a readable source in the log block area. If the entry is a valid log block physical page address, the physical page will be identified as the latest version page of the logical page number and included in the externally accessible set. For the physical page corresponding to an invalid log page, the controller establishes an unreadable mark, filtering the physical page on the address translation path and preventing it from being selected as a candidate page for returning data when processing host read requests, thereby achieving external consistency masking.

[0051] While determining valid log pages, it's necessary to construct a closed-loop system for logical page-to-physical page access relationships using the block mapping table. For logical page numbers without valid entries in the consistent log page mapping table, the physical data block containing the logical page is first located using the block mapping table, and then the corresponding physical page address within the data block is determined by the logical page's offset within the block. This physical page, together with the valid log pages from the consistent log page mapping table, forms a unified external access view. For logical page numbers with valid entries in the consistent log page mapping table, the access view directly points to the log block physical page address given by the log page mapping table and is considered to overwrite the old physical page corresponding to the same logical page offset within the data block. For logical page numbers without valid log page entries, the access view points to the physical page address within the data block. This ensures that each logical page number has only one definite physical page source in the recovered read path, preventing ambiguity that the same logical page can be read from both the log block and the data block simultaneously.

[0052] To ensure a consistent external state, validity needs to be converged during the establishment of access relationships: when multiple write versions of the same logical page number exist in the log block area, the log page mapping table after consistency checks ensures that only the latest valid version page is retained, and the access relationship only references this latest version page; when a log page is determined to be invalid and set to... At point 1, even if the physical page content is still stored in flash memory, it is masked by an unreadable mark, preventing the host from accessing the old version page through the normal read path. Through this process, the solid-state drive (SSD) can restore the mapping from logical pages to physical pages to a consistent state during the boot phase after an abnormal power outage or crash, and only provide user data in this consistent state when processing subsequent host read requests, thus achieving both data protection and availability.

[0053] In one embodiment, the metadata writing of the checkpoint block, the mapping block, and the mapping directory is all done using a single flash physical page as the atomic write unit, and verification information is recorded in each physical page to determine whether the metadata page of the metadata area has been completely written after a power failure or crash; and during the recovery process, metadata update writing is not performed on the flash media of the solid-state drive.

[0054] In this design, management information such as mapping directories, mapping blocks, and checkpoint blocks are uniformly placed in a dedicated metadata area, and the writing of this management information to disk is organized with flash physical pages as the smallest unit of writing. The core of this design is to leverage the natural granularity of flash page programming to completely encapsulate a metadata update into a single physical page, avoiding the partial update state that would occur during power failure due to splitting the same metadata across multiple physical pages. To ensure the atomicity of metadata writing, a complete write operation is required to be completed on a page-by-page basis. In the event of a system failure, it is only necessary to check whether a certain metadata page has been written to determine whether the content of that page can be used, thereby converging consistency determination to the page level and reducing complex cross-page error correction and rollback processing.

[0055] To ensure integrity after power outages or crashes, each metadata page records verification information. The controller can use CRC / ECC mechanisms to verify the metadata page, thus identifying whether it is a valid page from a complete write operation. In actual processing, after reading the metadata page during the recovery phase, verification is performed first: a successful verification indicates that the page can be used as a valid metadata source; a failed verification indicates that there may have been partial programming, bit flipping, or transmission errors due to power outages, and the page is discarded without participating in the mapping recovery. Since metadata is usually appended, newer metadata pages are closer to the end. Therefore, when locating the latest valid metadata page, it can be read from newest to oldest and verified page by page. Once the latest and verified page is found, backtracking can stop, thus quickly determining the latest version of available metadata and avoiding unnecessary full reads of the metadata area.

[0056] During recovery, no metadata updates are written to the flash memory; the metadata area remains read-only; and all repair actions are performed solely within volatile memory. The significance of this read-only recovery is that it avoids additional write overhead during the recovery phase, preventing the introduction of new write amplification and wear; the recovery process does not rely on rewriting metadata after a crash to achieve consistency, thus reducing the disturbance to the flash memory state caused by the recovery path; even if another anomaly occurs during recovery, the state will not become more complex due to the writing of some new metadata, and after power-on, the same read-only process can be used to read and verify the metadata pages again, restoring a consistent memory state mapping result. By combining page-level atomic writes with verification checks, and in conjunction with the read-only recovery strategy, metadata reliability and recovery stability can be unified into a verifiable and repeatable process.

[0057] As can be seen from the above embodiments, the present invention divides the log block area into log regions and generates checkpoints when the log regions are filled, so that the recovery phase only needs to read the checkpoints in reverse order and perform page-level traversal and parsing of the log regions not covered by the most recent checkpoint, thereby significantly reducing the scanning range and reducing the recovery time; by maintaining the current global merge sequence number during the merging process and recording it as the data block merge sequence number and the log block merge sequence number respectively, the merged residual log pages are determined and invalidated by the comparison rules of the two during recovery, thereby eliminating the risk of metadata inconsistency caused by the merging interruption from a mechanism perspective; By mapping block carrying block mapping table changes and mapping directory only updating when the physical block number of the mapping block changes, metadata write amplification is reduced and persistence reliability is improved; at the same time, metadata update writing is not performed on the flash media during the recovery process, making the recovery process read-only and re-executable, reducing the risk of secondary crashes, and ultimately ensuring that the solid-state drive only provides a consistent state of user data access relationship to the outside world, achieving a balance between data protection and system availability.

[0058] refer to Figure 2 As shown, a program 400 for implementing the above-described method according to an exemplary embodiment of the present invention is described. This program may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. A solid-state drive (SSD) may also be used and include program code. However, the program product of the present invention is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, system, or device.

[0059] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections with one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0060] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, system, or device.

[0061] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, CSS, and HTML, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0062] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions of the embodiments of the present invention can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, portable hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal system, or network device, etc.) to execute the method according to the exemplary embodiments of the present invention.

[0063] Furthermore, the above figures are merely illustrative representations of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0064] It should be noted that although several modules or units of the device for performing actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to exemplary embodiments of the present invention, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0065] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the claims.

[0066] It should be understood that the present invention is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A data protection method for a solid-state drive, characterized in that, The method, applied to the flash media management layer of a solid-state drive, includes: The flash memory of the solid-state drive is divided into a data block area, a log block area, and a metadata area. The metadata area includes a mapping directory, mapping blocks, and checkpoint blocks. A block mapping table and a log page mapping table are established in the volatile memory of the solid-state drive. The block mapping table is used to record the correspondence between logical block numbers and physical block numbers and includes the data block merge sequence number. The log page mapping table is used to record the correspondence between logical page numbers and log block physical page addresses and includes the log block merge sequence number. The system receives write requests from the host and writes the write data to the free pages of the log block area to update the log page mapping table. When the log block area is full, the current global merge sequence number is recorded as the log block merge sequence number. The log block area is divided into multiple log regions. When any log region is full, the corresponding mapping information is written to the checkpoint block to form a checkpoint. When there are no free pages in the log block area, the victim log block is selected in a round-robin fashion and merged. A new data block is allocated and the latest page is copied. The block mapping table and the log page mapping table are updated. The current global merge sequence number is incremented. The current global merge sequence number when the merge is completed is recorded as the data block merge sequence number of the target data block. The changes in the block mapping table are written to the mapping block. When the physical block number of the mapping block changes, the mapping directory is updated and written. After the solid-state drive crashes and restarts, the latest mapping block is read through the mapping directory to restore the block mapping table; The checkpoint blocks are read in reverse order, and the log regions not covered by the most recent checkpoint are parsed at the page level to construct a temporary log page mapping table. The victim log block is determined by the smallest log block merge sequence number, and a consistency check is performed on the temporary log page mapping table: the log page records are traversed in reverse order of log blocks to obtain the data block merge sequence number of the data block corresponding to each log page and compared with the log block merge sequence number of the log block where the log page is located. When the data block merge sequence number is greater than the log block merge sequence number, the log page is set to invalid, and a consistent log page mapping table is obtained. Based on the consistent log page mapping table and block mapping table, accessibility protection processing is performed on the user data in the solid-state drive. The physical page corresponding to the log page that is determined to be invalid is marked as unreadable and cannot participate in host read requests. The physical page corresponding to the log page that is determined to be valid establishes a consistent logical page to physical page access relationship with the latest physical page in its corresponding data block, so that the solid-state drive can only provide user data in a consistent state after abnormal power failure or crash.

2. The data protection method for a solid-state drive according to claim 1, characterized in that, Each log region, into which the log block area is divided, consists of a predetermined number of log blocks. The predetermined number is determined such that the logical page number information for the log region in the log page mapping table and the log block merging sequence number can be encapsulated and written into a single physical page. The checkpoint block uses a sequential append-only writing method to write checkpoints, enabling the checkpoint block to be read in reverse order.

3. The data protection method for a solid-state drive according to claim 1, characterized in that, The changes to the block mapping table include at least one of the following triggering conditions: The merging process causes a change in the mapping from logical block number to physical block number of the target data block; After the victim log blocks are merged, new log blocks are allocated from the free block list, which causes a change in the mapping from the logical block number to the physical block number of the log blocks. When the checkpoint block is full, a new checkpoint block is allocated from the free block list, causing the corresponding physical block number to change; and when the block mapping table change is detected, the relevant entries containing the data block merge sequence number are written to the mapping block on a page-by-page basis.

4. The data protection method for a solid-state drive according to claim 3, characterized in that, When the mapping information for the data block area in the block mapping table cannot be completely stored in a physical page, the data block area is divided into multiple data areas, and a corresponding mapping block logical area is allocated to each data area. When the mapping of any data block changes, only the block mapping information corresponding to the data region containing that data block is written to the next free page of the mapping block associated with the data region, so as to avoid a full refresh write of the entire block mapping table.

5. The data protection method for a solid-state drive according to claim 1, characterized in that, The mapping directory is located at a predetermined fixed physical location on the flash memory medium of the solid-state drive and is used to store the physical block number allocation information of the mapping block. When the mapping block is full and a new physical block needs to be allocated to the mapping block, the allocation information is first updated in the mapping directory and written to the mapping directory in units of pages, and then the block mapping table change is written in the new mapping block. The mapping directory also reserves at least one redundant physical block for bad block replacement.

6. The data protection method for a solid-state drive according to claim 1, characterized in that, When writing the write data to the free page of the log block area, the corresponding logical page number is also written to the spare area of ​​the physical page; when traversing and parsing the log area that was not covered by the most recent checkpoint, the entries of the log area that was not covered by the most recent checkpoint in the temporary log page mapping table are reconstructed by reading the logical page number in the spare area.

7. The data protection method for a solid-state drive according to claim 1, characterized in that, Select the log block with the smallest merge sequence number from the temporary log page mapping table as the victim log block; scan the temporary log page mapping table in reverse order of log block rotation, and perform a block mapping table query once for consecutive logical page numbers belonging to the same data block to obtain the data block merge sequence number of the corresponding data block in the group; When the data block merge sequence number is greater than the log block merge sequence number of the log block carrying the group of log pages, the logical page number corresponding to the group of log pages is uniformly rewritten to a predetermined invalid flag to indicate that it has been merged, wherein the predetermined invalid flag is -1.

8. The data protection method for a solid-state drive according to claim 1, characterized in that, The metadata writing of the checkpoint block, the mapping block, and the mapping directory is all done with a single flash physical page as the atomic write unit, and verification information is recorded in each physical page to determine whether the metadata page of the metadata area has been completely written after power failure or crash; and during the recovery process, metadata update writing is not performed on the flash media of the solid-state drive.

9. A solid-state drive (SSD) storing computer programs, characterized in that, When the computer program is executed by the processor, it implements the data protection method for solid-state drives as described in any one of claims 1 to 8.

Images