Nvm solid state disk garbage collection method based on block valid segment bitmap and accelerated search

Abstract

The application relates to the solid state disk storage technical field and discloses an NVM solid state disk garbage collection method based on block effective segment bitmap and accelerated retrieval, which comprises the following steps: when a covering write request is received, locating a BS block and a segment to which an old physical page belongs and accumulating segment invalidation counts, and setting a segment level bitmap corresponding bit when the counts reach a threshold value; after garbage collection is triggered, a candidate block set is screened through hardware acceleration logic by traversing the segment level bitmap; comparing a candidate block version stamp with a global submission version, performing full volume verification and migration on corresponding segment physical pages when the versions are consistent, performing sample verification when the versions are inconsistent, and determining whether to migrate according to the result. The application realizes rapid screening and directional verification of garbage collection candidate blocks, reduces the number of mapping table access times, reduces the invalid migration probability, improves the solid state disk garbage collection efficiency, and simultaneously optimizes the overall read-write performance and running stability of the solid state disk in the small block random write and hotspot address covering write scene.

Description

Technical Field

[0001] This application relates to the field of solid-state drive storage technology, specifically to an NVM solid-state drive garbage collection method based on block effective segment bitmap and accelerated retrieval. Background Technology

[0002] Non-volatile memory (NVM) solid-state drives have become an important application carrier in the storage field due to their high-speed read and write and low power consumption characteristics. Solid-state drives without dynamic random access memory are increasingly widely used in various storage scenarios due to their advantages of low hardware cost and compact structure. However, their on-chip static random access memory capacity is limited, which brings many technical challenges to garbage collection operations.

[0003] Garbage collection is a core management operation for solid-state drives (SSDs). In existing technologies, when SSDs without dynamic random access memory (DRAM) perform garbage collection, the selection of victim blocks and the identification of valid pages require frequent access to the mapping table between logical addresses and physical addresses, which can easily lead to read amplification and latency jitter issues. Segment-level bitmaps, as a common method for marking failed segments, are prone to insufficient reliability due to asynchronous disk writes and inconsistent update timing, leading to problems such as incorrect selection of victim blocks and invalid migration.

[0004] Meanwhile, frequent writes to hot addresses can lead to uneven distribution of data validity within segments. Coarse-grained bitmap filtering results in an excessively large candidate range, while fine-grained updates increase the pressure on metadata writing. Furthermore, under conditions of limited static random access memory resources, it is difficult to achieve closed-loop management of the bitmap maintenance and verification process, making it impossible to balance peak access control of the mapping table with the cost of bitmap updates, which seriously affects the overall read / write performance and garbage collection efficiency of the solid-state drive. Summary of the Invention

[0005] The purpose of this application is to provide an NVM solid-state drive garbage collection method based on block effective segment bitmap and accelerated retrieval, so as to solve the problems mentioned in the background art.

[0006] According to a first aspect of this application, a garbage collection method for NVM solid-state drives based on block effective segment bitmaps and accelerated retrieval is provided, comprising the following steps: In response to receiving an overwrite request, the BS block to which the old physical page to be overwritten belongs and the segment within that BS block are determined, and the segment failure count of the segment is incremented; when the value of the accumulated segment failure count reaches a preset bit threshold, the bit corresponding to the segment in the segment-level bitmap of the BS block is set to the first state, and the segment-level bitmap is used to mark the segment to be processed within a BS block. In response to a garbage collection trigger event, the hardware acceleration logic traverses the segment-level bitmap of all BS blocks and selects a preset number of BS blocks as a candidate block set based on the number of bits in the first state in the segment-level bitmap of each BS block. For each candidate BS block in the candidate block set, obtain its corresponding block version stamp, and compare the block version stamp with the global commit version maintained by the storage system; If the comparison results are consistent, the segment to be verified is determined according to the segment corresponding to the bit in the first state in the segment-level bitmap of the candidate BS block, and the physical pages in the determined segment are validated to perform data migration. If the comparison results are inconsistent, a portion of physical pages are extracted from the segments corresponding to the bits in the first state in the segment-level bitmap of the candidate BS block to perform sampling validity verification, and the data migration of the candidate BS block is determined based on the verification results.

[0007] Preferably, upon receiving an overwrite request, determining the BS block to which the overwritten old physical page belongs and the segment within that BS block includes: parsing the physical address of the old physical page to obtain the BS block identifier to which it belongs; and calculating the segment number to which it belongs based on the physical offset of the old physical page within the BS block and a preset segment size.

[0008] Preferably, the method further includes: maintaining a hot block table entry for each BS block, the hot block table entry containing a BS block identifier and its corresponding heat count; updating the heat count of the BS block to which the old physical page belongs each time an overwrite write request is processed; and adding the identifier of the BS block whose heat count reaches a preset heat threshold to the hot block table.

[0009] Preferably, an intra-segment sub-region summary is assigned to the BS block in the hot block table, and the intra-segment sub-region summary is used to further mark the sub-regions to be processed within a segment; When the accumulated failure count of the segment reaches a preset bit threshold, and the BS block to which the old physical page belongs exists in the hot block table, the bit corresponding to the sub-region in the sub-region summary of the segment is set to the first state according to the sub-region affiliation of the old physical page in the segment.

[0010] Preferably, selecting a preset number of BS blocks from all BS blocks as a candidate block set includes: the hardware acceleration logic sorting all BS blocks using the number of bits in the first state as the first sorting key and the sum of the segment failure counts of each BS block as the second sorting key; and selecting a preset number of BS blocks with the highest sorting order as the candidate block set.

[0011] Preferably, the method further includes: when a preset metadata submission condition is met, persistently storing the current segment-level bitmap and segment failure count of the BS block, and updating the block version stamp of the BS block; wherein the metadata submission condition includes: the number of times the mapping table associated with the BS block is updated reaches a first threshold, or the number of times the metadata of the BS block is modified reaches a second threshold; when the metadata submission condition is met and the current submission contains a mapping table update batch completion flag, performing an update operation on the global submission version.

[0012] Preferably, determining whether to perform data migration on the candidate BS block based on the verification result includes: Based on the sampling validity verification results of the extracted physical pages, the sampling validity ratio of the candidate BS block is calculated. If the sampling effective ratio is not higher than the preset effective ratio threshold, then the segment to be verified is determined according to the segment corresponding to the bit in the first state in its segment-level bitmap, and the physical pages in the determined segment are validated to perform data migration. If the effective sampling ratio is higher than the preset effective ratio threshold, the candidate BS block is added to the postponement list.

[0013] Preferably, a validity check is performed on the physical pages within the segment determined according to the segment-level bitmap for data migration, including: For a segment to be verified as determined by the segment-level bitmap, if the BS block to which the segment belongs exists in the hot block table, the sub-region to be verified is further determined based on the sub-region summary within the segment corresponding to the segment, and the physical pages within the sub-region are validated. For a physical page that is verified to be valid, its data is written to the newly allocated physical page, and the mapping table from logical address to physical address and the mapping table from physical address to logical address are atomically updated.

[0014] Preferably, the method further includes: after completing the validity verification and data migration of all physical pages to be verified within a segment, resetting the bit corresponding to the segment in the segment-level bitmap to the second state, and clearing the segment failure count of the segment to zero; if the BS block to which the segment belongs exists in the hot block table, then simultaneously resetting all sub-region summaries within the segment corresponding to the segment to the second state.

[0015] A second aspect of this application also provides an NVM solid-state drive garbage collection system based on block effective segment bitmap and accelerated retrieval, comprising: The failure evidence accumulation module is used to respond to receiving an overwrite write request, determine the BS block to which the overwritten old physical page belongs and the segment within the BS block, and perform an accumulation operation on the segment failure count of the segment; and when the value of the accumulated segment failure count reaches a preset bit threshold, set the bit corresponding to the segment in the segment-level bitmap of the BS block to the first state, the segment-level bitmap being used to mark the segment to be processed within a BS block. The candidate block filtering module includes a hardware acceleration logic unit. The hardware acceleration logic unit is used to respond to a garbage collection trigger event, traverse the segment-level bitmap of all BS blocks, and filter out a preset number of BS blocks as a candidate block set based on the number of bits in the first state in the segment-level bitmap of each BS block. The version comparison module is used to obtain the corresponding block version stamp for each candidate BS block in the candidate block set, and compare the block version stamp with the global commit version maintained by the storage system. The full verification migration module is used to determine the segment to be verified based on the segment corresponding to the bit in the first state in the segment-level bitmap of the candidate BS block when the comparison result between the block version stamp and the global commit version is consistent, and to perform validity verification on the physical pages in the determined segment in order to perform data migration. The sampling verification decision module is used to perform sampling validity verification on a portion of physical pages from the segments corresponding to the bits in the first state in the segment-level bitmap of the candidate BS block when the comparison result between the block version stamp and the global commit version is inconsistent, and to determine whether to perform data migration on the candidate BS block based on the verification result.

[0016] This application achieves accurate marking of pending segments by accumulating invalidation evidence during write request processing; it leverages hardware acceleration logic to quickly filter candidate blocks, improving garbage collection startup efficiency; it determines candidate block credibility by comparing block version stamps with global commit versions, and avoids worthless full-scale verification by combining sampling verification; it refines the verification granularity for hot blocks, adopting targeted verification and on-the-fly verification and migration methods to reduce the number of mapping table accesses and improve the efficiency of valid page migration. This invention, while achieving rapid screening, targeted verification, and efficient migration of garbage collection candidate blocks, effectively reduces peak mapping table accesses and the probability of invalid migration, improving the write performance and operational stability of SSDs in scenarios of small block random writes and frequent overwriting of hot addresses. It can also address the problem of asynchronous metadata updates caused by power failures, ensuring data consistency and metadata credibility, effectively solving the problems of garbage collection read amplification, latency jitter, and invalid migration in existing technologies. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram of an NVM solid-state drive garbage collection method based on block effective segment bitmap and accelerated retrieval, provided for an embodiment of this application.

[0019] Figure 2 This is a schematic diagram of the candidate block set screening process provided in an embodiment of this disclosure.

[0020] Figure 3 This is a schematic diagram of the data migration process provided in an embodiment of the present disclosure.

[0021] Figure 4 This is a schematic diagram of an NVM solid-state disk garbage collection system based on block effective segment bitmap and accelerated retrieval, provided for an embodiment of this application. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] The method described in this embodiment is applicable to non-volatile solid-state drive (SSD) storage systems without dynamic random access memory (DRAM). The executing entity is an SSD controller integrating firmware, on-chip static random access memory (SRAM), and hardware acceleration logic. This storage system uses flash memory and has address mapping management capabilities from logical addresses to physical addresses and from physical addresses to logical addresses. For example, this method can be implemented in scenarios involving small-block random writes and frequent overwriting of hot addresses. It can also address the problem of asynchronous metadata updates caused by power failures. Under hardware conditions with limited on-chip SRAM capacity, it can quickly screen garbage collection candidate blocks, perform targeted verification, and migrate data, effectively reducing peak mapping table accesses and the probability of invalid migrations.

[0024] In practical implementation, the storage system configures block-level metadata for each logical block unit, which is a BS block, a collection of storage units that can be independently selected as garbage collection objects. Each BS block is divided into a fixed number of segments, and a segment-level bitmap is a binary bitmap matching the number of segments, used to mark segments within the BS block that need to be processed. A first state indicates that it needs to be processed, and a second state indicates that it does not need to be processed. For example, the block-level metadata configured for each BS block includes at least a segment-level bitmap, a segment failure count, and a block version stamp. The segment failure count is a counter that counts the failure events of each segment, and the block version stamp is an identifier that represents the updated version of the block-level metadata. The storage system also maintains a global commit version to represent the overall update batch of the mapping table. The storage system also configures a hot block table to record BS blocks with high write frequency. BS blocks in the hot block table are additionally configured with intra-segment sub-region digests, which are binary digests used to mark the sub-regions within the segment that need to be processed after further dividing the segment into sub-regions.

[0025] The following detailed description, in conjunction with specific embodiments, illustrates the implementation process of the NVM solid-state drive garbage collection method based on block effective segment bitmaps and accelerated retrieval described in this application. It should be noted that this embodiment is merely for explaining this application and not for limiting the scope of protection of this application. Conventional adjustments or substitutions made by those skilled in the art to each step without departing from the concept of this application should be included within the scope of protection of this application.

[0026] like Figure 1 As shown in the figure, this application discloses a schematic diagram of an NVM solid-state drive garbage collection method based on block effective segment bitmap and accelerated retrieval, including the following method steps: S1, in response to receiving an overwrite request, determine the BS block to which the old physical page to be overwritten belongs and the segment within the BS block, and perform an accumulation operation on the segment failure count of the segment; when the value of the accumulated segment failure count reaches a preset bit threshold, set the bit corresponding to the segment in the segment-level bitmap of the BS block to the first state, the segment-level bitmap is used to mark the segment to be processed in a BS block. S2, in response to the garbage collection trigger event, the hardware acceleration logic traverses the segment-level bitmap of all BS blocks, and selects a preset number of BS blocks as a candidate block set based on the number of bits in the first state in the segment-level bitmap of each BS block. S4. For each candidate BS block in the candidate block set, obtain its corresponding block version stamp, and compare the block version stamp with the global commit version maintained by the storage system. S5. If the comparison results are consistent, the segment to be verified is determined according to the segment corresponding to the bit in the first state in the segment-level bitmap of the candidate BS block, and the physical pages in the determined segment are validated to perform data migration. S6. If the comparison results are inconsistent, a portion of physical pages are extracted from the segments corresponding to the bits in the first state in the segment-level bitmap of the candidate BS block to perform sampling validity verification. Based on the verification results, it is determined whether to perform data migration for the candidate BS block.

[0027] In some embodiments, for step S1, in response to receiving an overwrite write request, the BS block to which the overwritten old physical page belongs and the segment within the BS block are determined, and the segment failure count of the segment is incremented; when the value of the accumulated segment failure count reaches a preset bit threshold, the bit corresponding to the segment in the segment-level bitmap of the BS block is set to a first state, and the segment-level bitmap is used to mark the segment to be processed within a BS block.

[0028] Here, a BS block refers to a logical block unit defined by the SSD controller, corresponding to a set of storage units that can be independently selected as garbage collection objects, and is the smallest processing unit for garbage collection; a segment refers to the fixed number of segments into which each BS block is divided, denoted as , It can be configured to 32, and the segment number is recorded as , The range of values ​​is Segment failure count This is a 4-bit saturation counter with a value range of [value range missing]. This is used to accumulate the failure evidence strength of the corresponding segment. Once the count reaches its maximum value, it no longer increases with each failure event. The setting threshold is the segment failure count threshold triggered by setting the segment-level bitmap. In this embodiment, the value range is [value range missing]. The value is configured by the SSD controller based on the frequency of failure events in the business scenario and is a preset fixed value; it can be understood that the above value can be adjusted according to the actual situation, and this disclosure does not limit it.

[0029] Specifically, upon receiving an overwrite request, the storage system first queries the logical address-to-physical address mapping table to obtain the old physical page corresponding to the logical address to be overwritten. Then, it parses the physical address of the old physical page to obtain its BS block identifier. This parsing operation is performed by the address resolution module of the SSD controller. The physical address contains the unique identifier information of the BS block, which can be directly extracted. After obtaining the BS block identifier, the system calculates its segment number based on the physical offset of the old physical page within the BS block and the preset segment size. The segment size is the number of physical pages contained in each segment, determined by the storage system during the formatting phase based on the total number of physical pages in the BS block and the number of segments. It is a fixed value. The formula for calculating the segment number is...

[0030] in For segment numbering, This represents the physical offset of the old physical page within the BS block, measured in physical pages. For the preset segment size, To perform floor operations, the segment number calculated using this formula corresponds one-to-one with the segments within the BS block, ensuring the accuracy of segment location.

[0031] After determining the segment to which the old physical page belongs, the SSD controller reads the segment failure count corresponding to that segment and performs an accumulation operation. For example, the segment failure count is a saturation counter; the accumulated value does not exceed a preset maximum value to prevent counter overflow. This maximum value is preset by the storage system based on actual failure event statistics requirements, and its range is a non-negative integer. The initial value of the segment failure count is 0. Each time a failure event within that segment is detected, an accumulation operation is performed, thereby accumulating evidence of failure within the segment.

[0032] After the segment failure count is accumulated, the accumulated value is compared with the preset bit threshold. The bit threshold is the critical value that triggers the segment-level bitmap to be set. It is preset by the storage system based on the frequency of failure events and the expected benefits of garbage collection. The value range is non-negative integer. The method of determination is to statistically analyze the correlation between the number of failure events of each segment and the garbage collection benefits during the historical operation of the storage system, and select the number of failure events that make the garbage collection benefits reach the preset standard as the bit threshold. Among them, segment-level bitmap It is a 32-bit binary bitmap. The value can be 0 or 1. This indicates that there is strong evidence of invalidity in the corresponding segment, requiring verification, and that garbage collection is highly beneficial. This indicates that the corresponding segment does not require priority processing at this time; In one embodiment, the garbage collection benefit is defined as the number of physical pages that can be released by recycling the segment, i.e., the total number of failed pages in the segment. The correlation can be established as follows: In the system background, a low-priority task periodically samples and counts the number of failed pages in each segment of a portion of the BS block. The number of failure events experienced by each segment from the time it is first marked as failed until the number of failed pages reaches a preset benefit value, for example, 80% of the segment size, is recorded. The statistical average of these failure events is used as the preset threshold. In another embodiment, this threshold can also be directly preset as a fixed percentage of the total number of physical pages in the segment, for example, 50%, meaning that a segment is marked as pending processing only when more than half of the physical pages in it fail due to overwrite.

[0033] If the accumulated segment failure count reaches the set threshold, it means that the failure evidence in the segment has reached the preset strength and is worth further processing. At this time, the bit corresponding to the segment in the segment-level bitmap of the BS block is set to the first state, and the pending processing mark of the segment is completed. If the accumulated segment failure count does not reach the set threshold, the segment bitmap setting operation is not performed, and the segment-level bitmap remains in its original state.

[0034] During the process of processing overwrite write requests, the storage system also maintains a hot block table entry for each BS block. The hot block table entry contains the BS block identifier and its corresponding hotness count. The hotness count is a counter that counts the frequency of write and failure events within the BS block. The initial value is 0. Each time an overwrite write request is processed, the hotness count of the BS block to which the old physical page belongs is updated. For example, the update method is to increment the hotness count by 1 to represent the write activity level of the BS block.

[0035] The storage system is also configured with a preset hotness threshold, which is a threshold for determining whether a BS block is a hot block. This threshold is obtained by the storage system based on the average write frequency of BS blocks in the entire disk. The value range is a non-negative integer. It is determined by calculating the average hotness count of all BS blocks during the operation of the storage system, and using a preset multiple of this average value as the hotness threshold. If the hotness count of a certain BS block reaches the preset hotness threshold, it means that the write frequency of the BS block is significantly higher than the average level, and it is a hot BS block. At this time, the BS block identifier is added to the hot block table to mark the hot BS block.

[0036] For BS blocks in the hot block table, the storage system assigns an intra-segment sub-region summary. This summary is used to further mark unprocessed sub-regions within a segment. A sub-region is a set of storage units obtained by further dividing the segment into a fixed number of sub-regions. The number of sub-regions in each segment is preset by the storage system based on the segment size and the granularity requirements of garbage collection. When the accumulated segment failure count reaches a preset bit threshold, and the BS block to which the old physical page belongs exists in the hot block table, the bit corresponding to the sub-region in the intra-segment sub-region summary is set to the first state according to the sub-region affiliation of the old physical page within the segment. Specifically, firstly, based on the offset of the old physical page within the segment and the preset sub-region size, its sub-region number is calculated. The sub-region size is the number of physical pages contained in each sub-region, determined by the segment size and the number of sub-regions. The formula for calculating the sub-region number is as follows:

[0037] in For sub-area codes, This represents the physical offset of the old physical page within the segment. The preset sub-region size, To perform the floor function, after obtaining the sub-area number, the bit corresponding to the sub-area number in the sub-area summary within the segment corresponding to that segment is set to the first state, thus completing the marking of the sub-area to be processed within the segment.

[0038] In this context, a sub-region refers to each segment being further divided into a fixed number of sub-regions, denoted as G. G can be configured to 8. The sub-region number is denoted as gid, and the value range of gid is [0, G-1]. Sub-regions are only used for maintaining coarse-grained summaries within the segment and are not extended to page-level granularity. Summary of subareas within a segment Corresponding to each segment A binary digest of bits. The value can be 0 or 1. This indicates that the corresponding sub-region is marked as having a high probability of containing recyclable areas or areas that need to be verified. This structure is only allocated to hotspot BS blocks. In practical implementation, when the preset metadata submission conditions are met, the storage system persistently stores the current segment-level bitmap and segment failure count of the BS block, and updates the block version stamp of the BS block, thereby ensuring the persistence and version traceability of the block-level metadata. The metadata submission conditions include the number of times the mapping table related to the BS block is updated reaching a first threshold, or the number of times the metadata of the BS block is modified reaching a second threshold. Both the first and second thresholds are preset by the storage system based on the caching capacity of the on-chip static random access memory and the persistence efficiency of the metadata, and the values ​​are positive integers. The first threshold is determined by selecting the number of updates that achieve a preset standard of cache utilization based on the cache size of the mapping table from logical address to physical address and from physical address to logical address. The second threshold is determined by selecting the number of modifications that achieve a preset standard of metadata write amplification based on the modification frequency of the block-level metadata.

[0039] The block version stamp is a version identifier maintained by each BS block. Its bit width can be configured to be 8~12 bits. It is used in conjunction with the global commit version for the credibility determination of the segment-level bitmap. The update mechanism is to increment and modulo the block-level metadata as it is committed.

[0040] When any metadata submission condition is met, the solid-state drive controller writes the current segment-level bitmap and segment failure count of the BS block to the metadata reservation area of ​​the flash memory to complete persistent storage. Then, it performs an update operation on the block version stamp of the BS block. For example, the update method is to increment the block version stamp by 1 and take the modulo operation. The modulo value is the maximum value corresponding to the bit width of the block version stamp, ensuring that the block version stamp is updated cyclically within the valid range.

[0041] While updating the block version stamp, if the current metadata submission includes a mapping table update batch completion flag (meaning the submitted metadata corresponds to a complete mapping table update operation), the storage system performs an update operation on the global submission version. For example, the update method is to increment the global submission version by 1. If the global submission version has a bit width configuration, then the increment and modulo operation are performed. If the current metadata submission does not include a mapping table update batch completion flag, only the block version stamp is updated, and the global submission version update operation is not performed. This process establishes a correspondence between block-level metadata and mapping table update batches through the coordinated update of the block version stamp and the global submission version. The reliability of the block-level metadata can be directly determined by comparing version identifiers, avoiding the problem of misselecting candidate blocks due to asynchronous updates between metadata and mapping tables. The global submission version is a global version identifier maintained by the SSD controller, which is incremented only when the block-level metadata submission includes a mapping table update batch completion flag, used to determine the consistency between the block-level metadata and the mapping table. In some embodiments, for step S2, in response to a garbage collection trigger event, the hardware acceleration logic traverses the segment-level bitmaps of all BS blocks, and selects a preset number of BS blocks as a garbage collection candidate block set based on the number of bits in the first state in the segment-level bitmaps of each BS block.

[0042] When the storage system detects a garbage collection trigger event, in response, hardware-accelerated logic traverses the segment-level bitmaps of all BS blocks. Based on the number of bits in the first state in the segment-level bitmaps of each BS block, a preset number of BS blocks are selected as a candidate block set. The garbage collection trigger event is a critical condition for the storage system to initiate garbage collection. For example, this trigger event is when the number of free BS blocks in the storage system falls below a preset free threshold. The preset free threshold is preset by the storage system based on the host's write performance requirements, and its value is a positive integer. It is determined by statistically analyzing the write response speed under different numbers of free BS blocks during the operation of the storage system, and selecting the number of free BS blocks that achieve the preset standard for write response speed as the preset free threshold.

[0043] Specifically, please refer to Figure 2 , Figure 2 This is a schematic diagram illustrating the candidate block set filtering process provided in an embodiment of this disclosure. Figure 2As shown, in S201, the segment-level bitmap of each BS block is statistically analyzed, and the number of bits in the first state is calculated. The hardware acceleration logic is a dedicated hardware circuit integrated in the solid-state drive controller, which has the ability to quickly traverse, count, and sort the full block-level metadata. Its processing efficiency is much higher than the software traversal method of firmware. When responding to a garbage collection trigger event, the hardware acceleration logic first reads the segment-level bitmap of all BS blocks from the metadata reservation area of ​​the on-chip static random access memory or flash memory. Then, it statistically analyzes the segment-level bitmap of each BS block and calculates the number of bits in the first state. This number represents the number of segments to be processed in the corresponding BS block. The fewer the number of segments to be processed, the lower the processing cost of subsequent garbage collection.

[0044] In a hardware implementation example, the hardware acceleration logic can be designed as a three-stage pipeline. The first stage is a bitmap traversal and counting unit, consisting of a set of parallel counter arrays. Each clock cycle, it can read the segment-level bitmaps of multiple BS blocks and count the number of first status bits. The second stage is a key-value pair generation and buffering unit, which packages the BS block identifier output from the first stage, the first sorting key (the number of segments to be processed), and the second sorting key (the sum of segment failure counts) into a key-value pair and stores it in a dedicated high-speed buffer queue. The third stage is a hardware sorter, which can use a radix sort based on the bitmap count range or a bitonic sort network for small-scale data to sort the key-value pairs in all buffer queues. After sorting, the identifiers of the top N BS blocks are directly output to the firmware through a register interface. This hardware pipeline achieves line-speed screening of candidate blocks, with a processing efficiency far exceeding that of the software traversal method in firmware.

[0045] In S202, all BS blocks are sorted using the number of bits in the first state as the first sorting key and the sum of segment failure counts of all BS blocks as the second sorting key. After obtaining the number of bits in the first state in the segment-level bitmap of all BS blocks, the hardware acceleration logic sorts all BS blocks using this number as the first sorting key and the sum of segment failure counts of all BS blocks as the second sorting key.

[0046] The total segment failure count is the cumulative value of the segment failure counts of all segments within a certain BS block, calculated using the following formula:

[0047] in The sum of segment failure counts. The number of segments to divide each BS block. For the number The segment failure count corresponds to the segment number, which represents the overall failure evidence strength of the corresponding BS block. The larger the value, the higher the expected benefit of waste recycling. During sorting, BS blocks are first sorted in ascending order according to the first sorting key, meaning that BS blocks with fewer segments to be processed are ranked higher. For BS blocks with the same first sorting key value, they are sorted in descending order according to the second sorting key, meaning that BS blocks with higher overall failure evidence strength are ranked higher. This dual-sorting key method achieves a balance between waste recycling costs and recycling benefits.

[0048] In S203, a preset number of top-ranked BS blocks are selected as the candidate block set. After sorting all BS blocks, the hardware acceleration logic selects a preset number of top-ranked BS blocks as the candidate block set. The preset number is the maximum capacity of the candidate block set, preset by the storage system based on the retrieval efficiency of the hardware acceleration logic and the processing capability of the firmware. The value is a positive integer, determined by selecting the number of candidate blocks that ensure the overall efficiency of garbage collection reaches a preset standard based on the firmware processing speed of the SSD controller. The hardware acceleration logic outputs the BS block identifiers of the selected candidate block set to the firmware garbage collection module of the SSD controller, where the firmware performs subsequent reliability determination and verification operations. At this point, only the candidate blocks are selected; no erasure or data migration operations are performed on any BS blocks, ensuring the controllability of the garbage collection process.

[0049] By accelerating the logic with dedicated hardware, the bitmap can be traversed and counted quickly. The parallel processing capability of the hardware is used to improve the screening efficiency and avoid the technical problem of low efficiency caused by firmware traversal in traditional garbage collection.

[0050] In some embodiments, for step S3, for each candidate BS block in the candidate block set, its corresponding block version stamp is obtained, and the block version stamp is compared with the global commit version maintained by the storage system.

[0051] Step S4: If the comparison results are consistent, then the segment to be verified is determined according to the segment corresponding to the bit in the first state in the segment-level bitmap of the candidate BS block, and the physical pages in the determined segment are validated to perform data migration. Step S5: If the comparison results are inconsistent, a portion of physical pages are extracted from the segments corresponding to the bits in the first state in the segment-level bitmap of the candidate BS block to perform sampling validity verification, and the data migration of the candidate BS block is determined based on the verification results.

[0052] In practice, the storage system reads the corresponding block version stamp from the block-level metadata of the candidate BS block. The block version stamp is stored in the cache of on-chip static random access memory (SRAM) or the metadata reservation area of ​​flash memory. For active candidate BS blocks, it is read directly from SRAM to improve read efficiency. For inactive candidate BS blocks, it is read from the metadata reservation area of ​​flash memory and cached in SRAM. After obtaining the block version stamp, it is directly compared with the global commit version currently maintained by the storage system. If the two values ​​are consistent, it means that the block-level metadata and mapping table of the candidate BS block are in the same update batch, and their consistency is guaranteed. The credibility of the segment-level bitmap reaches the preset standard. At this time, no additional verification operation is required, and the system directly enters the full validity verification and data migration stage.

[0053] If the block version stamp is inconsistent with the global commit version, it indicates that the block-level metadata of the candidate BS block is out of sync with the update batch of the mapping table, and the reliability of the segment-level bitmap is insufficient. If a full verification is performed directly, the verification result may not match the actual situation. Therefore, it is necessary to extract some physical pages from the segments corresponding to the bits in the first state in the segment-level bitmap of the candidate BS block and perform sampling validity verification.

[0054] Specifically, firstly, the segments corresponding to the bits in the first state in the segment-level bitmap of the candidate BS block are determined, and these segments are used as target segments for sampling verification. Then, a portion of physical pages are extracted from each target segment. The sampling method is uniform sampling, that is, physical pages are selected within the target segment at fixed intervals to ensure that the sampling results can characterize the distribution of physical page validity in the entire target segment. The number of physical pages extracted is preset by the storage system based on the balance between verification accuracy and verification cost, and the value range is positive integer.

[0055] For each extracted physical page, a sampling validity check is performed. First, the mapping table entry from physical address to logical address corresponding to the physical page is read to obtain its corresponding logical address. If the mapping table entry is marked as invalid, it means that the physical page has no valid data and is directly determined as a failed page. If the mapping table entry is valid, the mapping table entry from logical address to physical address corresponding to the logical address is further read to obtain the identifier of the physical page currently mapped to the logical address. This identifier is compared with the extracted physical page identifier. If the two are inconsistent, it means that the data of the physical page has been overwritten and is determined as a failed page. If the two are consistent, it means that the data of the physical page is still valid and is determined as a valid page.

[0056] After verifying the sampling validity of all extracted physical pages, the sampling validity ratio of the candidate BS block is calculated based on the verification results. The sampling validity ratio is the ratio of the number of valid pages extracted from the candidate BS block to the total number of extracted physical pages. The calculation formula is as follows:

[0057] in The effective proportion of the sample. This represents the number of valid pages among the extracted physical pages. The ratio represents the total number of physical pages extracted. It indicates the overall effective page ratio of the candidate BS block. The lower the ratio, the higher the waste recycling benefit of the candidate BS block.

[0058] After calculating the effective sampling ratio, it is compared with a preset effective ratio threshold. The preset effective ratio threshold is a critical value for determining whether a candidate block has garbage collection value. It is preset by the storage system based on the expected benefits of garbage collection, and its value is a decimal between 0 and 1. It is determined by statistically analyzing the garbage collection benefits under different effective page ratios during storage system operation, and selecting the effective page ratio that achieves the preset standard for garbage collection benefits as the preset effective ratio threshold. In one example, this threshold can be set to a fixed empirical value, such as 20%. This means that if the effective sampling ratio of a candidate block is higher than 20%, it is considered to still have a large amount of valid data, and the benefit of immediate collection is low; it is better to postpone its processing until more data becomes invalid.

[0059] If the sampling effective proportion is not higher than the preset effective proportion threshold, it indicates that the overall effective page proportion of the candidate BS block is low and it has high garbage collection value. At this time, the segment to be verified is determined according to the segment corresponding to the bit in the first state in its segment-level bitmap, and the physical pages in the determined segment are validated to perform data migration. If the sampling effective proportion is higher than the preset effective proportion threshold, it indicates that the overall effective page proportion of the candidate BS block is high, the benefit of garbage collection is low, and there may even be invalid migration problems. At this time, the candidate BS block is added to the postponement list. The postponement list is a list in the storage system used to record BS blocks that do not have garbage collection value at the moment. BS blocks added to this list will be re-evaluated in the subsequent garbage collection process based on new failure evidence, and their priority is lower than that of BS blocks not added to this list.

[0060] In some embodiments, when a candidate BS block passes the credibility determination or the sampling effective ratio is not higher than a preset effective ratio threshold, the storage system determines the segment to be verified based on the segment corresponding to the bit in the first state in the segment-level bitmap of the candidate BS block, and performs validity verification on the physical pages in the determined segment in order to perform data migration.

[0061] Specifically, Figure 3 This is a schematic diagram of a data migration process provided for an embodiment of this disclosure. Figure 3As shown, in S301, the segments to be verified are determined based on the segments corresponding to the bits in the first state of the segment-level bitmap of the candidate BS block. These segments are those previously marked as having high-frequency failure events. Validity verification is performed only on these segments, ignoring segments in the second state of the segment-level bitmap, thereby achieving the first convergence of the verification range.

[0062] In S302, for a given segment to be verified, it is determined whether the BS block to which the segment belongs exists in the hot block table, and the sub-regions to be verified are determined based on the segment's intra-segment sub-region summary. If the BS block exists in the hot block table, it indicates that it is a hot BS block, and the validity distribution within the segment is uneven. In this case, the sub-regions to be verified are further determined based on the segment's intra-segment sub-region summary, i.e., the sub-regions corresponding to the bits in the first state in the intra-segment sub-region summary are selected as the sub-regions to be verified, thereby achieving the second convergence of the verification range. If the BS block does not exist in the hot block table, it indicates that it is not a hot BS block, and the validity distribution within the segment is relatively uniform. In this case, all sub-regions of the segment are determined as sub-regions to be verified, which is equivalent to performing verification on the entire segment. The hot block table is a table structure that stores hot BS block identifiers, with a capacity denoted as [missing information]. , It can be configured to 64 or 128. The entries in the table include BS block identifiers and heat counts. The heat count is used to characterize the frequency of write and failure events for the corresponding BS block.

[0063] In step S303, after determining the sub-region to be verified, a validity verification operation is performed on each physical page within the sub-region. The verification method is consistent with the sampling validity verification method: for each physical page within the sub-region to be verified, firstly, the corresponding physical address to logical address mapping table entry is read. If the entry is invalid, it is directly determined as a failed page and skipped. If the entry is valid, the corresponding logical address to physical address mapping table entry is read, and the currently mapped physical page identifier is compared with the physical page identifier. If the two are inconsistent, it is determined as a failed page and skipped. If the two are consistent, it is determined as a valid page, and a data migration operation needs to be performed on the physical page.

[0064] In S304, for physical pages that pass verification, the storage system processes them using a real-time verification and migration method. Instead of caching the valid page information in on-chip static random access memory, a new physical page is immediately allocated to its corresponding logical address. The new physical page is selected from the storage system's free physical page pool, which is the area in the storage system that stores free physical page identifiers.

[0065] After allocating a new physical page, the data in the valid page is completely written to the newly allocated physical page. Once the data is written, the mapping tables from logical addresses to physical addresses and from physical addresses to logical addresses are atomically updated. Atomic updates mean that the update operations on the mapping tables are executed as a whole; either all operations are completed or none are executed, avoiding intermediate states in the mapping tables and ensuring data consistency. Specifically, the logical address entry corresponding to the valid page in the logical address-to-physical address mapping table is updated to the newly allocated physical page identifier. Simultaneously, the newly allocated physical page identifier entry in the physical address-to-logical address mapping table is updated to the logical address, and the physical page identifier entries of the existing valid pages in the physical address-to-logical address mapping table are marked as invalid, completing one migration of a valid page and a mapping table update.

[0066] In step S305, after completing validity verification and data migration for all physical pages within a segment, the storage system performs a cleanup operation on the block-level metadata corresponding to that segment. First, the bits corresponding to the segment in the segment-level bitmap are reset to the second state, and the pending-processing mark for that segment is removed. Then, the segment failure count for that segment is cleared to zero, preparing for subsequent failure event statistics. If the BS block to which the segment belongs exists in the hot block table, it indicates that the BS block is configured with a segment-level sub-area summary. At this time, all segment-level sub-area summaries corresponding to that segment are simultaneously reset to the second state, and the pending-processing mark for all sub-areas within that segment is removed. This cleanup operation is contingent upon the completion of validity verification and data migration for that segment, ensuring that the state of the block-level metadata is consistent with the actual state of the physical pages, and avoiding the loss of failure evidence and missed migration issues caused by premature cleanup.

[0067] In S306, the data in all physical blocks corresponding to the BS block is erased, releasing the storage space occupied by the BS block. After completing the validity verification, data migration, and metadata cleanup operations for all segments to be verified in the candidate BS block, the storage system performs an erasure operation on the candidate BS block, that is, erasing the data in all physical blocks corresponding to the BS block, releasing the storage space occupied by the BS block. After erasure, the BS block is marked as a free BS block and added to the storage system's free BS block pool for subsequent host write requests to allocate physical pages, completing the garbage collection of the candidate BS block.

[0068] By using targeted verification and migration while verifying, verification is only performed on areas with evidence of invalidity, and the migration of valid pages and updating of the mapping table are completed in real time. The number of mapping table accesses is significantly reduced, the migration efficiency of valid pages is greatly improved, and invalid migration is avoided.

[0069] In some embodiments, during garbage collection, the storage system monitors the number of free space blocks (BS blocks) in real time. The number of free BS blocks is the total number of BS blocks in the storage system that are in an idle state, including free BS blocks released during garbage collection and existing free BS blocks. When the number of free BS blocks is detected to have recovered to or above a preset target threshold, the garbage collection process is terminated. The preset target threshold is a critical value for terminating garbage collection by the storage system. It is preset by the storage system based on free space reservation requirements and write performance requirements, and its value range is a positive integer. This threshold is greater than the preset free space threshold that triggers garbage collection. It is determined by statistically analyzing the system stability and write performance under different numbers of free BS blocks during the operation of the storage system, and selecting the number of free BS blocks that makes both system stability and write performance reach the preset standard as the preset target threshold.

[0070] When terminating the garbage collection process, the storage system performs a full persistence operation on all block-level metadata involved in this garbage collection process, ensuring that all metadata updates are written to the metadata reservation area of ​​flash memory. At the same time, it maintains data structures such as the hot block table and the deferred list, and updates the status information of the BS blocks to provide accurate data support for subsequent garbage collection and overwrite write request processing.

[0071] This method provides accurate segment marking for garbage collection by accumulating invalid evidence during write request processing; it significantly improves the startup efficiency of garbage collection by using hardware-accelerated logic to quickly filter candidate blocks; it determines the credibility of candidate blocks by comparing block version stamps with global commit versions, and avoids worthless full verification by combining sampling verification; it achieves efficient migration of valid pages and atomic updates of the mapping table through targeted verification and verification-while-migrating methods; and finally, it terminates garbage collection on demand based on the number of free BS blocks. Overall, it achieves rapid filtering, targeted verification, and efficient migration of garbage collection candidate blocks in solid-state drive storage systems with limited on-chip static random access memory (SRAM) capacity and no dynamic random access memory (DRAM). This effectively reduces peak mapping table accesses and the probability of invalid migrations, reduces read amplification and latency jitter during garbage collection, and improves the write performance and stability of the storage system in scenarios with small-block random writes and frequent overwriting of hot addresses. It also effectively addresses the problem of asynchronous metadata updates caused by power failures, ensuring data consistency and metadata credibility.

[0072] It should be noted that although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart can be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0073] Please see Figure 4 , Figure 4 This application provides a block diagram of an NVM solid-state drive garbage collection system based on a block effective segment bitmap and accelerated retrieval, as part of an embodiment of the present application. The system specifically includes: The failure evidence accumulation module 401 is used to respond to receiving an overwrite write request, determine the BS block to which the overwritten old physical page belongs and the segment within the BS block, and perform an accumulation operation on the segment failure count of the segment; and when the value of the accumulated segment failure count reaches a preset bit threshold, set the bit corresponding to the segment in the segment-level bitmap of the BS block to a first state, the segment-level bitmap being used to mark the segment to be processed within a BS block; The candidate block filtering module 402 includes a hardware acceleration logic unit. The hardware acceleration logic unit is used to respond to a garbage collection trigger event, traverse the segment-level bitmap of all BS blocks, and filter out a preset number of BS blocks as a candidate block set based on the number of bits in the first state in the segment-level bitmap of each BS block. The version comparison module 403 is used to obtain the corresponding block version stamp for each candidate BS block in the candidate block set, and compare the block version stamp with the global commit version maintained by the storage system. The full verification and migration module 404 is used to determine the segment to be verified based on the segment corresponding to the bit in the first state in the segment-level bitmap of the candidate BS block when the comparison result between the block version stamp and the global commit version is consistent, and to perform validity verification on the physical pages in the determined segment in order to perform data migration. The sampling verification decision module 405 is used to perform sampling validity verification on a portion of physical pages from the segments corresponding to the bits in the first state in the segment-level bitmap of the candidate BS block when the comparison result between the block version stamp and the global commit version is inconsistent, and to determine whether to perform data migration on the candidate BS block based on the verification result.

[0074] It should be noted that the working process of each module in the NVM solid-state disk garbage collection system based on block effective segment bitmap and accelerated retrieval described in this embodiment can refer to the working process of the NVM solid-state disk garbage collection method based on block effective segment bitmap and accelerated retrieval described in the above embodiment. The technical effect achieved is also the same as that of the NVM solid-state disk garbage collection method based on block effective segment bitmap and accelerated retrieval described in the above embodiment, and will not be repeated here.

[0075] The above description represents the preferred embodiments of the present invention. It should be noted that, for those skilled in the art, various improvements and modifications can be made without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A garbage collection method for NVM solid-state drives based on block effective segment bitmap and accelerated retrieval, characterized in that, include: In response to receiving an overwrite request, the BS block to which the old physical page to be overwritten belongs and the segment within that BS block are determined, and the segment failure count of the segment is incremented; when the value of the accumulated segment failure count reaches a preset bit threshold, the bit corresponding to the segment in the segment-level bitmap of the BS block is set to the first state, and the segment-level bitmap is used to mark the segment to be processed within a BS block. In response to a garbage collection trigger event, the hardware acceleration logic traverses the segment-level bitmap of all BS blocks and selects a preset number of BS blocks as a candidate block set based on the number of bits in the first state in the segment-level bitmap of each BS block. For each candidate BS block in the candidate block set, obtain its corresponding block version stamp, and compare the block version stamp with the global commit version maintained by the storage system; If the comparison results are consistent, the segment to be verified is determined according to the segment corresponding to the bit in the first state in the segment-level bitmap of the candidate BS block, and the physical pages in the determined segment are validated to perform data migration. If the comparison results are inconsistent, a portion of physical pages are extracted from the segments corresponding to the bits in the first state in the segment-level bitmap of the candidate BS block to perform sampling validity verification, and the data migration of the candidate BS block is determined based on the verification results.

2. The NVM solid-state drive garbage collection method based on block effective segment bitmap and accelerated retrieval according to claim 1, characterized in that, Upon receiving an overwrite request, determine the BS block to which the old physical page to be overwritten belongs and the segments within that BS block, including: The physical address of the old physical page is parsed to obtain the identifier of the BS block to which it belongs; The segment number to which the old physical page belongs is calculated based on the physical offset of the old physical page within the BS block and the preset segment size.

3. The NVM solid-state drive garbage collection method based on block effective segment bitmap and accelerated retrieval according to claim 1, characterized in that, Also includes: Maintain a hot block table entry for each BS block, the hot block table entry containing the BS block identifier and its corresponding heat count; Update the heat count of the BS block to which the old physical page belongs each time an overwrite write request is processed; Add the identifier of the BS block that has reached the preset heat threshold to the heat block table.

4. The NVM solid-state drive garbage collection method based on block effective segment bitmap and accelerated retrieval according to claim 3, characterized in that, The method further includes: Assign intra-segment sub-region summaries to the BS blocks in the hot block table. These intra-segment sub-region summaries are used to further mark the sub-regions to be processed within a segment. When the accumulated failure count of the segment reaches a preset bit threshold, and the BS block to which the old physical page belongs exists in the hot block table, the bit corresponding to the sub-region in the sub-region summary of the segment is set to the first state according to the sub-region affiliation of the old physical page in the segment.

5. The NVM solid-state drive garbage collection method based on block effective segment bitmap and accelerated retrieval according to claim 1, characterized in that, A predetermined number of BS blocks are selected from all BS blocks to form a candidate block set, including: The hardware acceleration logic sorts all BS blocks using the number of bits in the first state as the first sorting key and the sum of the segment failure counts of each BS block as the second sorting key. A predetermined number of BS blocks with the highest sorting order are selected as the candidate block set.

6. The NVM solid-state drive garbage collection method based on block effective segment bitmap and accelerated retrieval according to claim 1, characterized in that, Also includes: When the preset metadata submission conditions are met, the current segment-level bitmap and segment failure count of the BS block are persistently stored, and the block version stamp of the BS block is updated. The metadata submission conditions include: the number of times the mapping table related to the BS block is updated reaches a first threshold, or the number of times the metadata of the BS block is modified reaches a second threshold; When the metadata submission conditions are met and the current submission contains a mapping table update batch completion flag, an update operation is performed on the global submission version.

7. The NVM solid-state drive garbage collection method based on block effective segment bitmap and accelerated retrieval according to claim 1, characterized in that, Based on the verification results, determine whether to perform data migration for the candidate BS block, including: Based on the sampling validity verification results of the extracted physical pages, the sampling validity ratio of the candidate BS block is calculated. If the sampling effective ratio is not higher than the preset effective ratio threshold, then the segment to be verified is determined according to the segment corresponding to the bit in the first state in its segment-level bitmap, and the physical pages in the determined segment are validated to perform data migration. If the effective sampling ratio is higher than the preset effective ratio threshold, the candidate BS block is added to the postponement list.

8. The NVM solid-state drive garbage collection method based on block effective segment bitmap and accelerated retrieval according to claim 1, characterized in that, Perform validity checks on physical pages within segments determined by the segment-level bitmap in order to perform data migration, including: For a segment to be verified as determined by the segment-level bitmap, if the BS block to which the segment belongs exists in the hot block table, the sub-region to be verified is further determined based on the sub-region summary within the segment corresponding to the segment, and the physical pages within the sub-region are validated. For a physical page that is verified to be valid, its data is written to the newly allocated physical page, and the mapping table from logical address to physical address and the mapping table from physical address to logical address are atomically updated.

9. The NVM solid-state drive garbage collection method based on block effective segment bitmap and accelerated retrieval according to claim 8, characterized in that, Also includes: After completing the validity verification and data migration of all physical pages to be verified within a segment, the bit corresponding to the segment in the segment-level bitmap is reset to the second state, and the segment failure count of the segment is cleared to zero. If the BS block to which the segment belongs exists in the hot block table, then all sub-region summaries within the corresponding segment will be reset to the second state.

10. A garbage collection system for NVM solid-state drives based on block effective segment bitmap and accelerated retrieval, characterized in that, include: The failure evidence accumulation module is used to respond to receiving an overwrite write request, determine the BS block to which the overwritten old physical page belongs and the segment within the BS block, and perform an accumulation operation on the segment failure count of the segment; and when the value of the accumulated segment failure count reaches a preset bit threshold, set the bit corresponding to the segment in the segment-level bitmap of the BS block to the first state, the segment-level bitmap being used to mark the segment to be processed within a BS block. The candidate block filtering module includes a hardware acceleration logic unit. The hardware acceleration logic unit is used to respond to a garbage collection trigger event, traverse the segment-level bitmap of all BS blocks, and filter out a preset number of BS blocks as a candidate block set based on the number of bits in the first state in the segment-level bitmap of each BS block. The version comparison module is used to obtain the corresponding block version stamp for each candidate BS block in the candidate block set, and compare the block version stamp with the global commit version maintained by the storage system. The full verification migration module is used to determine the segment to be verified based on the segment corresponding to the bit in the first state in the segment-level bitmap of the candidate BS block when the comparison result between the block version stamp and the global commit version is consistent, and to perform validity verification on the physical pages in the determined segment in order to perform data migration. The sampling verification decision module is used to perform sampling validity verification on a portion of physical pages from the segments corresponding to the bits in the first state in the segment-level bitmap of the candidate BS block when the comparison result between the block version stamp and the global commit version is inconsistent, and to determine whether to perform data migration on the candidate BS block based on the verification result.

Images