Data migration method, storage medium and solid state disk

Abstract

This application discloses a data migration method, storage medium, and solid-state drive (SSD). The method includes: receiving a data migration command comprising a source address range and a destination address range; allocating read cache space based on the logical address length corresponding to the source address range; dividing the source address range into at least one first fragment range at a preset granularity, creating a first cache node for each first fragment range, and inserting each first cache node into a cache linked list; dividing the destination address range into at least one second fragment range at a preset granularity, creating a second cache node for each second fragment range and allocating data cache space, and inserting each second cache node into a cache linked list; reading data from the first fragment range corresponding to each first cache node into the read cache space, and copying data segment by segment from the read cache space to the data cache space of each second cache node. This application can reduce the command processing latency of the SSD and improve data copying efficiency.

Description

Technical Field

[0001] This application relates to the field of solid-state drive technology, and in particular to a data transfer method, storage medium and solid-state drive. Background Technology

[0002] In the Non-Volatile Memory Express (NVMe) protocol of Solid State Drives (SSDs), the data copy command provides an efficient mechanism for direct data transfer within the disk initiated by the host. This avoids consuming the transmission bandwidth of the high-speed Peripheral Component Interconnect Express (PCIe) bus, which is of great significance for optimizing storage system performance.

[0003] To ensure the atomicity of data migration command execution, the industry typically imposes strict access constraints on the source address range set (src range set) and the target address range set (dst range set) spanned by the data migration command. These source and target address range sets are maintained by the firmware throughout the data migration command's lifecycle. The access constraints primarily target read and write commands received during data migration, specifically including: the source address range of the data migration command cannot be modified by write commands, but can be read normally by read commands (to prevent the migrated data from being outdated); the target address range of the data migration command cannot be modified by write commands (to prevent the migrated data from being inconsistent with the source address data); and the target address range cannot be read during data migration command execution (to prevent incomplete data reading). It should be noted that these access constraints are not explicitly defined by the NVMe protocol, but rather are common industry practices implemented for data migration command execution for reliability and availability considerations. Without these constraints, while the data migration command may complete, it usually cannot achieve a deterministic result.

[0004] Based on this, when the host initiates read, write, or other similar commands, the firmware compares the address range of each command with each entry in both the source and destination address range sets to check for address conflicts. If a conflict is detected, the corresponding command is suspended and retried later. The command can only continue execution after the traversal check confirms there are no conflicts. This set-based conflict checking mechanism is currently the common implementation method to ensure the atomicity of host data transfer and the reliability, availability, and determinism of command processing.

[0005] However, in practical applications, data migration commands often involve multiple source address ranges, and multiple data migration commands may be executed concurrently within the SSD, leading to a significant increase in the number of range entries in both the source and destination address range sets. In this situation, read and write commands need to traverse a large number of range sets to perform conflict checks. The time overhead of traversal increases linearly with the size of the set, directly resulting in a significant increase in processing latency for read and write commands. This is especially problematic in scenarios with intensive data migration commands, leading to a noticeable decline in the overall performance of the storage system. Furthermore, the conflict checking method needs to be repeated for each read and write command, failing to effectively utilize the existing cache hash lookup mechanism within the SSD. This results in a lengthy command processing path, further increasing execution latency. Therefore, reducing the time overhead of address range conflict checks for read and write commands during data migration command execution has become a key technical issue for improving system performance in host data migration scenarios. Summary of the Invention

[0006] This application mainly provides a data migration method, storage medium, and solid-state drive (SSD), aiming to solve the technical problem of system performance degradation of SSD in host data migration scenarios.

[0007] To solve the above-mentioned technical problems, the technical solution adopted in this application is: to provide a data migration method. The data migration method includes: receiving a data migration command; the data migration command includes a source address range and a target address range; allocating read cache space based on the logical address length corresponding to the source address range; splitting the source address range into at least one first fragment range according to a preset granularity, creating a first cache node for each first fragment range, and inserting each first cache node into a cache linked list; splitting the target address range into at least one second fragment range according to the preset granularity, creating a second cache node for each second fragment range, allocating data cache space for each second cache node, and inserting each second cache node into the cache linked list; based on the cache linked list, reading data from the first fragment range corresponding to each first cache node into the read cache space, and copying data segment by segment from the read cache space to the data cache space of each second cache node.

[0008] In some embodiments, each cache node records a type identifier, a status identifier, and address metadata; the type identifier of the first cache node is a read data migration scenario identifier, and the type identifier of the second cache node is a write data scenario identifier; the status identifier is used to indicate the data transmission status of the corresponding cache node; when the first cache node and the second cache node are created, the status identifier indicates that the data transmission is not complete; the status identifier of the second cache node is updated to indicate that the data transmission is complete after the data is copied from the read cache space to the second cache node; the address metadata is used to record the address mapping relationship between the cache node and the corresponding shard range; the first cache node also records a command identifier, which is used to uniquely identify the data migration command.

[0009] In some embodiments, inserting each of the first cache nodes into the cache linked list includes: determining whether there is a first conflicting cache node in the cache linked list whose corresponding address range overlaps with the first fragment range of the current first cache node; if there is a first conflicting cache node, determining whether the type identifier of the first conflicting cache node is a data migration scenario identifier or a data read scenario identifier; if the type identifier of the first conflicting cache node is neither a data migration scenario identifier nor a data read scenario identifier, identifying the status identifier of the first conflicting cache node; if the status identifier of the first conflicting cache node indicates that the data transmission is not complete, pausing the insertion of the current first cache node; if there is no first conflicting cache node, or the type identifier of the first conflicting cache node is a data migration scenario identifier or a data read scenario identifier, or the status identifier of the first conflicting cache node indicates that the data transmission is complete, then inserting the current first cache node into the cache linked list.

[0010] In some embodiments, inserting each of the second cache nodes into the cache linked list includes: determining whether there is a second conflicting cache node in the cache linked list whose corresponding address range overlaps with the second fragment range of the current second cache node; if there is a second conflicting cache node, identifying the status identifier of the second conflicting cache node; if the status identifier of the second conflicting cache node indicates that data transmission is not complete, identifying the type identifier of the second conflicting cache node; if the type identifier of the second conflicting cache node is a data transfer scenario identifier, determining whether the command identifier of the second conflicting cache node is the command identifier corresponding to the data transfer command; if the status identifier of the second conflicting cache node indicates that data transmission is not complete and the type identifier is not a read operation. If the scenario identifier is not a data transfer scenario identifier, or the status identifier of the second conflicting cache node indicates that the data transfer is not complete and the type identifier is a data transfer scenario identifier and the command identifier is not the command identifier corresponding to the data transfer command, then the insertion of the current second cache node is paused; if the second conflicting cache node does not exist, or the status identifier of the second conflicting cache node indicates that the data transfer is complete, or the status identifier of the second conflicting cache node indicates that the data transfer is not complete and the type identifier is a data transfer scenario identifier, or the status identifier of the second conflicting cache node indicates that the data transfer is not complete and the type identifier is a data transfer scenario identifier and the command identifier is the command identifier corresponding to the data transfer command, then the current second cache node is inserted into the cache list.

[0011] In some embodiments, during the process of inserting each of the first cache nodes into the cache list and inserting each of the second cache nodes into the cache list, if the insertion of any first cache node or second cache node into the cache list fails, all inserted first cache nodes and second cache nodes are removed from the cache list, the allocated data cache space and the read cache space are released, and the data migration command is retried later.

[0012] In some embodiments, updating the status flag of the second cache node to indicate that the data transmission has been completed includes: after all the second cache nodes have completed the data copy, uniformly updating the status flag of all the second cache nodes to indicate that the data transmission has been completed, and the uniform update is not interrupted during the unified update.

[0013] In some embodiments, after inserting each of the first cache nodes into the cache linked list and inserting each of the second cache nodes into the cache linked list, the method further includes: when a read command is received, searching the cache linked list for a cache node whose address range overlaps with the address range of the read command; when the found cache node is a first cache node, skipping the first cache node and continuing the search; when the found cache node is a second cache node whose status indicates that data transmission is incomplete, determining that the read command conflicts with the data transfer command; when the found cache node is a second cache node whose status indicates that data transmission is complete, returning the data in the data cache space of the second cache node; when a write command is received, searching the cache linked list for a cache node whose address range overlaps with the address range of the write command; when the found cache node is either a first cache node or a second cache node whose status indicates that data transmission is incomplete, determining that the write command conflicts with the data transfer command; when the found cache node is a second cache node whose status indicates that data transmission is complete, processing the write command according to the write conflict handling process of the cache linked list.

[0014] In some embodiments, after copying data in segments from the read cache space to the data cache space of each of the second cache nodes, the method further includes: releasing each of the first cache nodes and the read cache space.

[0015] To solve the above-mentioned technical problems, another technical solution adopted in this application is to provide a storage medium on which a computer program is stored, wherein the computer program, when executed by a solid-state drive, implements the steps of the data transfer method described above.

[0016] To solve the above-mentioned technical problems, another technical solution adopted in this application is: to provide a solid-state drive, including a processor and a memory connected to each other, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-mentioned data transfer method.

[0017] The beneficial effects of this application are as follows: Unlike existing technologies, this application discloses a data migration method, storage medium, and solid-state drive (SSD). This application splits and caches the source and target address ranges of data migration commands into first and second cache nodes in a cache linked list according to a preset granularity. Data reading and copying are performed based on the cache linked list, allowing read and write commands to directly reuse the cache linked list's lookup mechanism for address range conflict checking. This avoids traversing the large and continuously growing sets of source and target address ranges one by one, significantly reducing conflict checking time and command processing latency, thereby effectively improving the read and write performance of the SSD in scenarios with intensive data migration commands. Simultaneously, it allocates contiguous read cache space based on the logical address length corresponding to the source address range and copies data in segments from the read cache space to the data cache space of each second cache node. This avoids allocating separate data cache space for each first cache node, reducing cache space occupancy and blocking the read and write process, and improving data copying efficiency. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein: Figure 1 This is a flowchart illustrating an embodiment of the data transfer method provided in this application; Figure 2 This is a schematic diagram of the structure of an embodiment of the storage medium provided in this application; Figure 3 This is a schematic diagram of a solid-state drive embodiment provided in this application. Detailed Implementation

[0019] 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 a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0020] The terms "first," "second," and "third" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0021] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0022] This application provides a data migration method, see reference. Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the data transfer method provided in this application. The data transfer method includes: Step 10: Receive the data transfer command; the data transfer command includes the source address range and the destination address range; Step 20: Allocate read cache space based on the logical address length corresponding to the source address range; Step 30: Divide the source address range into at least one first fragment range according to the preset granularity, create a first cache node for each first fragment range, and insert each first cache node into the cache linked list; Step 40: Divide the target address range into at least one second fragment range according to the preset granularity, create a second cache node for each second fragment range, allocate data cache space for each second fragment range, and insert each second cache node into the cache linked list; Step 50: Based on the cache linked list, read data from the first shard range corresponding to each first cache node into the read cache space, and copy data from the read cache space in segments to the data cache space of each second cache node.

[0023] In this embodiment, the data migration command is a host-initiated command defined in the NVMe protocol that directly migrates data within the solid-state drive (SSD). When the host needs to migrate data within the drive, it issues a data migration command to the SSD. In existing technologies, after receiving a data migration command, the SSD maintains source and target address ranges as source address range sets and target address range sets, respectively. Throughout the entire lifecycle of the data migration command, the firmware continuously maintains these sets. During read / write command execution, it needs to traverse both sets to perform address range conflict checks. As the set size increases, the conflict checking time increases linearly, severely limiting the SSD's read / write performance in scenarios with intensive data migration commands. To reduce the time overhead of conflict checking, this embodiment caches the source and target address ranges as nodes in a cached linked list, reusing the cached linked list's lookup mechanism to replace traversing the set. This allows the conflict checking of read / write commands to converge from traversing the set to cache lookup, significantly shortening the conflict checking path.

[0024] In this embodiment, the data migration command includes a source address range and a destination address range. The source address range is the starting logical address range for data migration, indicating from which logical addresses the data will be read. It is determined by the host when assembling the data migration command and is included in the command. The destination address range is the final logical address range for data migration, indicating from which logical addresses the data will be written. It is also included in the command by the host. The NVMe protocol specifies that a data migration command can carry a maximum of 128 source address ranges, which can be limited by the Maximum Source Range Count (MSRC) attribute. A data migration command can include one or more source and destination address ranges, each segmented according to a preset granularity. The source and destination address ranges can be extracted by parsing the command descriptor block of the data migration command, providing address range information for subsequent caching processing. After receiving the data migration command, the solid-state drive performs a validity check on the source and destination address ranges to confirm that they are both within a valid logical address space.

[0025] In this embodiment, the solid-state drive (SSD) requests read cache space based on the logical address length corresponding to the source address range. The read cache space is the intermediate storage space after data is read from the source address range and before it is copied to the second cache node. Specifically, the SSD calculates the total logical address length of all source address ranges in the data migration command and requests a contiguous read cache space based on this total length to accommodate all source data involved in the data migration command at once. The read cache space is requested directly through a memory allocation mechanism (such as mem alloc), rather than through the cache node's cache space pool mechanism (such as bufferpool).

[0026] In this embodiment, a memory allocation mechanism is used to directly request a large, contiguous block of read cache space, rather than requesting a separate data cache space for each first cache node. This is mainly based on two considerations: First, the memory allocation mechanism directly requests cache space without occupying the cache space pool resources of the cache node, avoiding the cache space pool being occupied and blocking the cache space request of the cache node that generates write and read commands, thereby avoiding blocking the read and write process; Second, the source address range and the target address range are usually split differently, and using a contiguous read cache space can avoid fragmented data copying and improve data copying efficiency. For example, if the source address range is (64KB, 192KB) and the length is 128KB, and the starting logical address of the target address range is 256KB, the source address range will be split into two first cache nodes (64KB, 128KB) and (128KB, 192KB) according to a preset granularity, while the target address range will only be split into one second cache node (256KB, 384KB). In this case, if a scheme of allocating data cache space separately for each first cache node is adopted, data needs to be read from the two first cache nodes and then copied to the data cache space of the second cache node. The copying process is fragmented and inefficient. However, using a contiguous read cache space can directly read and copy from a whole space, which is more efficient.

[0027] In this embodiment, the solid-state drive (SSD) divides the source address range into at least one first fragment range according to a preset granularity, creates a first cache node for each first fragment range, and inserts each first cache node into a cache linked list. The cache linked list is a data structure in the SSD used to manage cache nodes, supporting fast location of cache nodes based on address ranges. It can be, for example, a hash list, or other data structures that support fast lookups, such as a balanced tree or skip list. Taking a hash list as an example, it organizes cache nodes into different hash buckets using a hash algorithm. Each hash bucket is managed through a linked list: when inserting a cache node, the corresponding hash bucket is first determined using a hash algorithm, and then collision handling is performed on the linked list within the bucket before attaching it to the linked list; when searching for a cache node, the corresponding hash bucket is located using hash calculation, and then a small amount of traversal is performed on the linked list within the bucket to complete the search. Compared to the O(n) time complexity of traversing a set for search, the time complexity of hash lookup is close to O(1), which can significantly improve the efficiency of collision checking. This application uses a hash linked list as an example implementation of a cache linked list for illustration, but the specific implementation of the cache linked list is not limited to a hash linked list. It can also be other data structures that support fast lookup, such as a balanced tree or a skip list, with a lookup time complexity of O(log n), which can also greatly improve the efficiency of conflict checking.

[0028] In this embodiment, the preset granularity is a fixed granularity for cache list management, enabling each cache node to directly locate its corresponding management position through the cache list's lookup mechanism. The specific selection of the preset granularity can be configured based on the SSD's cache management strategy and the page size of the flash memory medium, exemplarily a hash bucket management granularity or a fixed-size logical address range (e.g., 4KB, 8KB, etc.). To reduce complexity, this application uses a scenario where the start and end addresses of each fragment range are aligned with the preset granularity as an example. In other embodiments, for non-aligned scenarios, the fragment range can be expanded into an aligned range by rounding down and up, and then the location of the actual valid data can be marked using a bitmap set; this application does not specifically limit this. Based on the aforementioned cache list and preset granularity, the first cache node, as a newly added cache type in this application, is used to represent the cache mapping of the source address range of the data migration command. The first cache node does not occupy data cache space and does not need to read data from cache or flash media to fill the cache node. Its data cache space address (buffer field) is set to an invalid address to identify that it does not hold valid data at the data structure level. It is only identified and processed in the cache list by type identifier. The role of the first cache node is to mark the source address range in the cache list so that it can be identified and blocked when a write command hits, thereby protecting the source address range from being overwritten during data migration, while not affecting the normal reading access of the source address range by read commands.

[0029] In this embodiment, the solid-state drive (SSD) divides the target address range into at least one second fragment range according to a preset granularity, creates a second cache node for each second fragment range, allocates data cache space for each second cache node, and inserts each second cache node into a cache linked list. The type identifier of the second cache node is a write data scenario identifier, used to represent the cache mapping of the target address range of the data migration command. The second cache node corresponds to the actual data cache space, which is used to store data copied from the read cache space. When creating a second cache node, the status identifier of the second cache node indicates that the data transfer is not complete. At this time, a read command hitting the second cache node will return a conflict, and a write command hitting the second cache node will also return a conflict, ensuring compliance with industry access constraints that "the target address range of the data migration command cannot be modified by the write command" and "the target address range cannot be read when the data migration command is executed." After the data copy is completed, the status identifier of the second cache node is updated to indicate that the data transfer is complete. At this time, a read command hitting the second cache node can return the data in the data cache space, and a write command hitting the second cache node can be handled by the existing write conflict handling process. After the second cache node is inserted into the cache list, the cache flushing process can be reused to persist the data in the data cache space to the flash memory medium.

[0030] In this embodiment, the solid-state drive (SSD) uses a cache linked list to read data from the first fragment range corresponding to each first cache node into the read cache space, and then copies data from the read cache space in segments to the data cache space of each second cache node. Specifically, the SSD reads data from the cache or flash memory medium into the read cache space according to the logical address range in the source address range. The data source includes two cases: if the data corresponding to the source address range already exists in the SSD's cache (e.g., a cache node previously generated by a write command or read-ahead command), the data is directly copied from the cache to the read cache space without accessing the flash memory medium; if the data corresponding to the source address range is not in the cache, the data is read from the flash memory medium (e.g., NAND Flash) into the read cache space. Subsequently, the SSD copies data from the read cache space in segments to the data cache space of each second cache node. The segmented copying method is as follows: according to the length of each second cache node, data segments of corresponding lengths are sequentially extracted from the read cache space and copied to the data cache space of each second cache node respectively. After the copy is complete, the status flags of all second cache nodes are updated to indicate that the data transfer is complete. Then, the background processes the data in the second cache nodes and persists the data to the flash memory medium.

[0031] This embodiment splits and caches the source and target address ranges of the data migration command into first and second cache nodes in a cache linked list. This transforms the address range conflict checking of read and write commands from traversing the source and target address range sets to reusing the cache linked list lookup mechanism, significantly shortening the conflict checking path and reducing the processing latency of read and write commands. At the same time, it allocates contiguous read cache space based on the logical address length corresponding to the source address range and copies data in segments from the read cache space to the data cache space of each second cache node. This avoids allocating data cache space separately for each first cache node, reducing the blocking of the read and write process by cache space occupation, improving data copying efficiency, and thus improving the overall performance of the solid-state drive during the execution of the data migration command.

[0032] Optionally, in some embodiments, each cache node records a type identifier, a status identifier, and address metadata; the type identifier of the first cache node is a read data migration scenario identifier, and the type identifier of the second cache node is a write data scenario identifier; the status identifier is used to indicate the data transmission status of the corresponding cache node; when the first cache node and the second cache node are created, the status identifier indicates that the data transmission is not complete; the status identifier of the second cache node is updated to indicate that the data transmission is complete after the data is copied from the read cache space to the second cache node; the address metadata is used to record the address mapping relationship between the cache node and the corresponding fragment range; the first cache node also records a command identifier, which is used to uniquely identify the data migration command.

[0033] In this optional embodiment, the fields that need to be recorded using the cache node data structure are specifically described. The fields recorded by each cache node include: Type identifiers are used to distinguish the types of cache nodes, enabling the SSD to adopt different processing strategies based on the type of cache node during conflict checking. Specifically, the type identifiers of cache nodes may include: write data scenario identifier (write), corresponding to cache nodes generated by write commands; read data scenario identifier (read), corresponding to cache nodes generated by read-ahead commands; trim data scenario identifier (trim), corresponding to cache nodes generated by trim commands; and copy read data scenario identifier (copy read), corresponding to cache nodes generated by the source address range of data copy commands, which is a new cache type added in this application. Among them, cache nodes with write data scenario identifiers and trim data scenario identifiers need to be flushed down, while cache nodes with read data scenario identifiers and copy read data scenario identifiers do not need to be flushed down. The type identifier of the first cache node is the copy read data scenario identifier, and the type identifier of the second cache node is the write data scenario identifier. The first cache node does not carry data storage, participate in conflict flag updates, or cache flushing. It primarily uses logical medium address, length, type identifier, and status identifier fields, and uses a newly added command identifier (cmdtag) field for indexing data migration commands. The first cache node does not maintain fields such as read reference count, conflict flag, and bitmap set, because it is not involved in read command hits (it does not hold data cache space) or cache flushing; therefore, it does not need to manipulate these fields. These fields are only maintained and manipulated in cache nodes that handle write data scenario identifiers and prune data scenario identifiers. In addition to read and write commands, the NVMe protocol also includes other types of commands, such as verification commands, comparison commands, and write commands (write zero commands). In the actual protocol, read commands undergo conflict checking according to the read command checking rules, and write commands undergo conflict checking according to the write command checking rules. This application uses read and write commands as examples for illustration.

[0034] The status flag indicates the data transfer status of the corresponding cache node, specifically including "data transfer incomplete" (exemplarily represented by 0, meaning data transfer is in progress and unreadable) and "data transfer complete" (exemplarily represented by 1, meaning data transfer is complete and readable). When creating the first and second cache nodes, the status flag indicates "data transfer incomplete." For the first cache node, the status flag always remains indicating "data transfer incomplete," without any status transition, because the first cache node does not handle data copying; it only exists as a cached mapping of the source address range. Unlike the second cache node, the status flag of the first cache node does not affect the behavior of read commands. When a read command hits the first cache node, it skips directly based on the type flag without checking the status flag. The status flag only blocks write commands; when a write command hits the first cache node, it returns a conflict because the status flag indicates "data transfer incomplete." For the second cache node, the status flag is updated to indicate "data transfer complete" after the data is copied from the read cache space to the second cache node. When the status indicates that data transmission is incomplete, both read and write commands hitting the cache node will return a conflict, and the command will be suspended and retried later. When the status indicates that data transmission is complete, read commands hitting the cache node can return the data in the data cache space, and write commands hitting the cache node can be handled through the existing write conflict handling process.

[0035] Address metadata records the address mapping relationship between cache nodes and their corresponding shard ranges, and may include logical media addresses, length fields, and conflict flags. The logical media address records the starting position of the cache node in the logical address space, and the length records the size of the address range covered by the cache node. Through address metadata, the SSD can quickly locate the corresponding cache node in the cache list based on the address range of read / write commands and perform conflict checks. Conflict flags are used to record the address range conflict relationship between new and old cache nodes when a cache node is inserted into the cache list, facilitating conflict handling during subsequent cache flushing and cache lookup processes.

[0036] In this optional embodiment, the first cache node also records a command identifier (denoted as cmdtag), which is used to uniquely identify a data migration command. Specifically, the solid-state drive (SSD) assigns a unique command identifier (denoted as tag) to each command, which remains unchanged throughout the command's lifecycle. The value of the cmdtag field is taken from the tag corresponding to the command, allowing the first cache node to index the associated data migration command through the cmdtag field. For example, when the SSD supports 512 concurrent commands, the tag value range is 0 to 511, and 512 can be used as an invalid tag. When the first cache node is created, the cmdtag field is set to the tag value corresponding to the current data migration command, while the cmdtag field of other types of cache nodes is set to an invalid tag. The purpose of the first cache node recording the command identifier is: when a second cache node is inserted into the cache list, if there is an address range conflict with an existing first cache node, comparing the command identifiers can determine whether the source address range and target address range of the same data migration command overlap (i.e., a self-conflict scenario), thus allowing insertion to continue even in the event of a self-conflict.

[0037] In this optional embodiment, the cache node data structure can be implemented in a variety of ways, such as reusing the existing data structure in the solid-state drive (such as the DirtyNode data structure introduced later), or creating a new data structure that can achieve the corresponding function. As long as the cache node can effectively record information such as the type, status and address range of the cache node and support fast lookup through the corresponding data structure, it is all within the protection scope of this application.

[0038] This optional embodiment defines a unified field structure for each cache node and distinguishes type identifiers, enabling the first and second cache nodes to be integrated into the existing cache management framework of the solid-state drive for unified management. Simultaneously, the command identifier field supports self-conflict identification, providing a field foundation for subsequent conflict checking. The definitions of the aforementioned type identifier, status identifier, and address metadata fields are not limited to specific data structures; any structure that can record information such as the type, status, and address range of the cache node and support fast lookup is acceptable.

[0039] Alternatively, in some embodiments, cache nodes are constructed based on a dirty data block data structure.

[0040] In this optional embodiment, some solid-state drive caching systems already use a dirty node data structure to organize and manage cache nodes. The cache nodes in this application can be constructed using this data structure, with a new command identifier (cmdtag) field added to support self-conflict identification of data migration commands. The DirtyNode data structure includes multiple fields, among which key fields include: a logical media address (lma) and length (len) field, used to record the logical address range corresponding to the cache node, with the same meaning for all types of cache nodes; a type identifier (type) field, used to distinguish the type of cache node; a status identifier (isready) field, used to indicate the data transmission status of the cache node; a data cache space address (buffer) field, used to record the physical address of the stored data; a read reference count (rdrefcnt) field, used to record the number of references to the cache node for read operations; and a conflict marker field (which may include two marker bits, hasnewoverlap and hasoldoverlap, where hasnewoverlap is used to mark the existence of the old cache node and the new cache node). The address range overlaps between cache nodes (hasoldoverlap is used to mark the overlap between the address ranges of new and old cache nodes). This is used to record the address range conflict relationship between new and old cache nodes when they are inserted into the cache list, facilitating conflict handling during subsequent cache flushing and cache lookup processes. Bitmap set fields (including dirtybmp, validbmp, pendingbmp, sentbmp, and donebmp, etc.) are used to record various states of data in the cache node, such as dirty valid, pending flushing, sent, and completed. Each bit represents a LMA (Level of Memory) data point. These bitmaps work together to accurately track the data state at each LMA position in the cache node during cache flushing and conflict handling, ensuring data consistency. In the DirtyNode data structure, the address range length covered by each DirtyNode is up to a preset granularity, allowing each cache node to directly locate its corresponding management position through the cache list lookup mechanism. It is understandable that, in addition to the DirtyNode data structure, other data structures that support unified management of cache nodes or new data structures that can achieve the corresponding functions can be used, as long as the data structure can effectively record information such as the type, status and address range of cache nodes and support fast lookup.

[0041] In this optional embodiment, regarding the specific application of the conflict flag field, when a new cache node is inserted into the cache list and its address range overlaps with an existing old cache node, the `hasnewoverlap` property of the old cache node is set to one, indicating that the old cache node's address range overlaps with the new cache node's; simultaneously, the `hasoldoverlap` property of the new cache node is set to one, indicating that the new cache node's address range overlaps with the old cache node's. Through the conflict flag, the solid-state drive can quickly identify cache nodes with overlapping address ranges during subsequent cache flushing and cache lookup processes, and handle conflicts accordingly. For example, during cache flushing, if the `hasnewoverlap` property of a cache node is set to one, the data of that cache node within the overlapping address range may have been overwritten by data in the new cache node. The flushing process needs to determine whether the cache node still holds valid data within the overlapping address range based on the marker at the corresponding position in the bitmap set, avoiding writing expired data to the flash memory medium. When a write command hits a second cache node that has already been transferred, the conflict flag is updated to mark the overwritten position, ensuring that subsequent read commands hit the newly written cache node rather than the overwritten old cache node.

[0042] This optional embodiment reuses the existing DirtyNode data structure in the solid-state drive and adds a command identifier field. The first cache node and the second cache node can be directly incorporated into the existing cache management framework of the solid-state drive for unified management without the need to develop a new data structure, thus reducing the implementation complexity. At the same time, with the support of the conflict marker field and the bitmap set field, a complete data foundation is provided for conflict handling during cache flushing and conflict checking.

[0043] Optionally, in some embodiments, inserting each first cache node into the cache linked list includes: determining whether there is a first conflicting cache node in the cache linked list whose corresponding address range overlaps with the first fragment range of the current first cache node; if there is a first conflicting cache node, determining whether the type identifier of the first conflicting cache node is a data migration scenario identifier or a data read scenario identifier; if the type identifier of the first conflicting cache node is neither a data migration scenario identifier nor a data read scenario identifier, identifying the status identifier of the first conflicting cache node; if the status identifier of the first conflicting cache node indicates that the data transmission is not complete, pausing the insertion of the current first cache node; if there is no first conflicting cache node, or the type identifier of the first conflicting cache node is a data migration scenario identifier or a data read scenario identifier, or the status identifier of the first conflicting cache node indicates that the data transmission is complete, then inserting the current first cache node into the cache linked list.

[0044] In this optional embodiment, the insertion process of the first cache node (i.e., copy-read node) includes the following steps: First, apply for a copy-read type cache node, with the fragment range being the first fragment range corresponding to the split source address range. The data cache space address is set to an invalid address, the status flag indicates that the data transfer is not complete, and the cmdtag field is set to the tag value corresponding to the current data migration command. Then, locate the corresponding management position in the cache linked list based on the address range of the first cache node (taking a hash linked list as an example, i.e., determining the hash bucket through hash calculation), and begin traversing the linked list at the corresponding position. During the traversal, check whether there is a first conflicting cache node that overlaps with the first fragment range of the current first cache node by comparing the address ranges. If there is no first conflicting cache node, directly insert the current first cache node into the cache linked list. If there is a first conflicting cache node, determine the type flag of the first conflicting cache node.

[0045] In this optional embodiment, if the type identifier of the first conflicting cache node is a copy read node or a read node, it indicates that the first conflicting cache node is a copy read node or a read node. These two types of cache nodes do not involve data rewriting and will not affect the protection of the source address range. Therefore, they can be considered conflict-free, and there is no need to update the conflict flag. Continue traversing the next node in the linked list. If the type identifier of the first conflicting cache node is neither a copy read node nor a read node, it indicates that the first conflicting cache node is a write node or a trim node. In this case, it is necessary to further identify the status identifier of the first conflicting cache node. If the status identifier of the first conflicting cache node indicates that the data transmission is complete, it means that the data in the address range has been written, and it can be considered conflict-free. There is no need to update the conflict flag, and continue traversing. If the status identifier of the first conflicting cache node indicates that the data transmission is not complete, it means that the address range is being rewritten and cannot be protected. Therefore, the insertion of the current first cache node fails, the insertion is paused, and it will be retried later. After the traversal is completed, if no situation requiring a pause in insertion is encountered, the current first cache node is inserted into the cache linked list.

[0046] This optional embodiment performs conflict checks when inserting the first cache node, and distinguishes between conflicting cache nodes based on their type and status. This makes read nodes and copy read nodes considered conflict-free and can be inserted directly, while write nodes and trim nodes are also considered conflict-free when data transmission is complete. Insertion is only paused when data transmission is incomplete. This ensures the protection of the source address range and avoids unnecessary insertion failures, thereby improving the success rate of inserting the first cache node.

[0047] Optionally, in some embodiments, inserting each second cache node into a cache linked list includes: determining whether there is a second conflicting cache node in the cache linked list whose corresponding address range overlaps with the second fragment range of the current second cache node; if there is a second conflicting cache node, identifying the status identifier of the second conflicting cache node; if the status identifier of the second conflicting cache node indicates that data transmission is not complete, identifying the type identifier of the second conflicting cache node; if the type identifier of the second conflicting cache node is a data migration read scenario identifier, determining whether the command identifier of the second conflicting cache node is the command identifier corresponding to the data migration command; if the status identifier of the second conflicting cache node indicates that data transmission is not complete and the type identifier is not a data migration scenario identifier, determining whether the command identifier of the second conflicting cache node is the command identifier corresponding to the data migration command; if the status identifier of the second conflicting cache node indicates that data transmission is not complete and the type identifier is not a data migration scenario identifier, determining whether the command identifier of the second conflicting cache node is the command identifier corresponding to the data migration command. If the status identifier of the second conflicting cache node is not a data transfer scenario identifier, or the status identifier of the second conflicting cache node indicates that the data transfer is not complete and the type identifier is a data transfer scenario identifier and the command identifier is not the command identifier corresponding to the data transfer command, then the insertion of the current second cache node is paused; if there is no second conflicting cache node, or the status identifier of the second conflicting cache node indicates that the data transfer is complete, or the status identifier of the second conflicting cache node indicates that the data transfer is not complete and the type identifier is a data transfer scenario identifier, or the status identifier of the second conflicting cache node indicates that the data transfer is not complete and the type identifier is a data transfer scenario identifier and the command identifier is the command identifier corresponding to the data transfer command, then the current second cache node is inserted into the cache list.

[0048] In this optional embodiment, the insertion process of the second cache node (i.e., write node) includes the following steps: First, a write-type cache node is requested, with the sharding range being the second sharding range corresponding to the split target address range. Data cache space is requested for the second cache node according to its length, and a status flag indicates that data transmission is incomplete. Then, the corresponding management position is located in the cache linked list according to the address range of the second cache node (taking a hash linked list as an example, i.e., determining the hash bucket through hash calculation), and traversal begins on the linked list at the corresponding position. During the traversal, the existence of a second conflicting cache node that overlaps with the second sharding range of the current second cache node is checked by comparing the address ranges. If no second conflicting cache node exists, the current second cache node is directly inserted into the cache linked list. If a second conflicting cache node exists, its status flag is first identified.

[0049] In this optional embodiment, if the status flag of the second conflicting cache node indicates that the data transmission is complete, it means that the data in the second conflicting cache node has been written. At this time, the conflict flag is updated (the hasnewoverlap of the old cache node is set to 1, and the hasoldoverlap of the current second cache node is set to 1) so that the corresponding conflict processing can be performed according to the conflict flag, and then the next node in the linked list can be traversed. If the status flag of the second conflicting cache node indicates that the data transmission is not complete, the type flag of the second conflicting cache node is further identified. If the type flag of the second conflicting cache node is a read data scenario flag, it means that the second conflicting cache node is a read node and does not involve data rewriting. At this time, the conflict flag is updated to identify the overlapping relationship between the old and new cache nodes in the subsequent cache lookup process, ensuring the correctness of the data consistency lookup path, and then the traversal continues. If the type flag of the second conflicting cache node is a move read data scenario flag, it means that the second conflicting cache node is a copy read node. At this time, the cmdtag field value of the second conflicting cache node needs to be extracted for judgment. If the cmdtag field value of the second conflicting cache node is the same as the tag value corresponding to the current data migration command, it indicates that the source address range and target address range of the same data migration command overlap (i.e., a self-conflicting scenario). The current second cache node is allowed to continue insertion and is considered conflict-free; no update of the conflict flag is required. If the cmdtag field value of the second conflicting cache node is different from the tag value corresponding to the current data migration command, it indicates that the source address range of different data migration commands overlaps with the current target address range. The current second cache node insertion fails, and insertion is paused and retried later. If the type identifier of the second conflicting cache node is a write data scenario identifier or a prune data scenario identifier, it indicates that the address range is being rewritten, and insertion of the second cache node is impossible. Insertion is paused and retried later. After traversal, if no situation requiring paused insertion is encountered, the current second cache node is inserted into the cache linked list.

[0050] This optional embodiment performs conflict checks when inserting into the second cache node, and handles conflicts differently based on the status and type of the conflicting cache node. In particular, it identifies self-conflict scenarios where the source address range and target address range of the data transfer command overlap by comparing command identifiers, allowing insertion to continue even in the event of a self-conflict. This avoids the problem of data transfer commands failing to execute due to overlapping address ranges. At the same time, it maintains a pause and retry mechanism for conflicts between different data transfer commands, ensuring the correctness and atomicity of data transfer command execution.

[0051] Optionally, in some embodiments, if any first cache node or second cache node fails to be inserted into the cache list during the process of inserting each first cache node into the cache list and each second cache node into the cache list, all inserted first cache nodes and second cache nodes are removed from the cache list, the allocated data cache space and read cache space are released, and the data migration command is retried later.

[0052] In this optional embodiment, during the insertion of the first cache node into the cache list and the insertion of the second cache node into the cache list, if the insertion of either cache node fails (e.g., due to insufficient resources or unresolved conflicts), a resource rollback is performed. The principle of resource rollback is: if any cache node insertion fails, all previously allocated and inserted resources are released. Specifically, if the insertion of the second cache node fails, all second cache nodes already inserted into the cache list are removed from the cache list, and the data cache space of each second cache node is released; all first cache nodes already inserted into the cache list are removed from the cache list; and the read cache space is released. If the insertion of the first cache node fails, all first cache nodes already inserted into the cache list are removed from the cache list, and the read cache space is released. At this time, the second cache node has not yet been created, and there is no data cache space to be released. After completing the resource rollback, the entire data migration command processing flow is retried later.

[0053] This optional embodiment ensures resource consistency and availability by performing a full resource rollback when a cache node insertion fails, thus preventing invalid cache nodes or unreleased cache space from remaining due to partial insertion failures. This avoids the impact of resource leaks on subsequent command processing.

[0054] Optionally, in some embodiments, updating the status flag of the second cache node to indicate that the data transmission has been completed includes: after all the second cache nodes have completed the data copy, uniformly updating the status flag of all the second cache nodes to indicate that the data transmission has been completed, and the uniform update is not interrupted during the process.

[0055] In this optional embodiment, during the process of copying data from the read cache space to the data cache space of each second cache node in segments, the status flags of all second cache nodes indicate that the data transfer is not complete. After all second cache nodes have completed the data copy, the solid-state drive updates the status flags of all second cache nodes uniformly to indicate that the data transfer is complete. The core means of uniform update is to ensure that the update is not interrupted (for example, to place interrupt reporting and processing on other processor cores), so that the status flags of all second cache nodes are either all in the state of incomplete data transfer or all in the state of complete data transfer, avoiding a mixed state where some second cache nodes have been updated while others have not. In other embodiments, the uniform update of status flags can also be achieved through other methods such as locking mechanisms, atomic operations, or critical section protection, as long as the status flags of all second cache nodes remain consistent during the update. State consistency exists throughout the entire lifecycle of the data migration command, ensuring the atomicity of the data migration command execution. If the update is interrupted, some second cache nodes may have their status updated to indicate that the data transmission is complete, while others may still indicate that the data transmission is incomplete. In this case, read and write commands may misjudge when searching for cache nodes in the cache chain, resulting in data inconsistency.

[0056] This optional embodiment ensures the consistency of the status identifiers of all second cache nodes throughout the lifecycle of the data migration command by uniformly updating the status identifiers after all data copying is completed on all second cache nodes without interruption. This avoids misjudgments caused by some second cache nodes updating their status due to interruption, thereby ensuring the atomicity of the data migration command execution.

[0057] Optionally, in some embodiments, after inserting each first cache node into the cache linked list and each second cache node into the cache linked list, the method further includes: when a read command is received, searching the cache linked list for a cache node whose address range overlaps with the address range of the read command; when the found cache node is a first cache node, skipping the first cache node and continuing the search; when the found cache node is a second cache node whose status flag indicates that data transmission is not complete, determining that there is a conflict between the read command and the data transfer command; when the found cache node is a second cache node whose status flag indicates that data transmission is complete, returning the data in the data cache space of the second cache node.

[0058] In this optional embodiment, during the lifecycle of a data migration command, when the solid-state drive receives a read command from the host, it searches the cache list for a cache node whose address range overlaps with the address range of the read command. Since the target address range has already been cached as the second cache node in the cache list, the range check of the read command converges from traversing the target address range set to searching the cache list, significantly shortening the check path. When the found cache node is the first cache node (copy read node), since the first cache node does not occupy data cache space and has no impact on the read command, the first cache node is skipped and the search continues for the next node in the cache list, ensuring compliance with the industry constraint that "the source address range of a data migration command cannot be modified by a write command, but can be read normally by a read command." When the found cache node is the second cache node whose status indicates that the data transfer is not complete, it means that the data in the target address range has not been copied, the read command returns a conflict, and is suspended for retry later, ensuring compliance with the industry constraint that "the target address range cannot be read when the data migration command is executed." When the found cache node is the second cache node whose status indicates that the data transmission has been completed, it means that the data in the target address range has been copied. The data in the data cache space of the second cache node is returned directly without reading from the flash memory medium, which improves the response speed of the read command.

[0059] This optional embodiment searches for the cache node corresponding to the address range of the read command in the cache linked list, and executes different processing logic according to the type and status of the cache node. This allows the range check of the read command to reuse the lookup mechanism of the cache linked list, avoiding traversing the target address range set and reducing the processing latency of the read command. At the same time, the transparency of the first cache node to the read command ensures that the source address range can be read normally by the read command.

[0060] Optionally, in some embodiments, after inserting each first cache node into the cache linked list and each second cache node into the cache linked list, the method further includes: when a write command is received, searching the cache linked list for a cache node whose address range overlaps with the address range of the write command; when the found cache node is a first cache node or a second cache node whose status flag indicates that the data transmission is not complete, determining that the write command and the data transfer command conflict; when the found cache node is a second cache node whose status flag indicates that the data transmission is complete, processing the write command according to the write conflict handling process of the cache linked list.

[0061] In this optional embodiment, during the lifecycle of a data migration command, when the solid-state drive receives a write command from the host, it searches the cache list for a cache node whose address range overlaps with the address range of the write command. Since the source and target address ranges are already cached as the first and second cache nodes in the cache list, the range check for the write command converges from traversing the source and target address range sets to searching the cache list, significantly shortening the check path. When the found cache node is the first cache node (copy read node), because the status flag of the first cache node always indicates that the data transfer is incomplete, it blocks the write command, causing a conflict and suspending it for later retry, ensuring compliance with the industry constraint that "the source address range of a data migration command cannot be modified by the write command." When the found cache node is the second cache node whose status flag indicates that the data transfer is incomplete, it means that the data in the target address range has not been copied completely, the write command returns a conflict, and is suspended for later retry, ensuring compliance with the industry constraint that "the target address range written by the data migration command cannot be modified by the write command." When the found cache node is the second cache node whose status indicates that the data transmission has been completed, it means that the data in the target address range has been copied, and the write command can be processed through the existing write conflict handling process of the cache linked list.

[0062] This optional embodiment searches for the cache node corresponding to the address range of the write command in the cache linked list, and executes different processing logic according to the type and status of the cache node. This makes the range check of the write command reuse the lookup mechanism of the cache linked list, avoiding traversing the source address range set and the target address range set, reducing the processing latency of the write command. At the same time, the feature of the first cache node blocking the write command ensures that the source address range is not modified during data migration.

[0063] Optionally, in some embodiments, the write command is processed according to the write conflict handling process of the cache list, including: marking the position covered by the write command in the conflict marker of the second cache node; creating a new write cache node for the write command, and inserting the new write cache node into the cache list so that the new write cache node replaces the role of the second cache node at the conflict position.

[0064] In this optional embodiment, when a write command hits a second cache node whose status flag indicates that data transmission has been completed, the solid-state drive (SSD) processes the conflict according to the existing write conflict handling procedure of the cache list. Specifically, as mentioned above, the conflict markers in the cache node include old conflict markers (hasoldoverlap) and new conflict markers (hasnewoverlap), which are part of the address metadata. For the scenario where a write command hits a second cache node whose status flag indicates that data transmission has been completed, the SSD marks the location covered by the write command in the conflict markers of the second cache node. That is, it clears the valid data marker (validbmp) and dirty data marker (dirtybmp) of the conflict location in the second cache node, indicating that the conflict location is no longer considered to hold the latest data and no longer needs to be flushed. Subsequently, a new write cache node is created for the write command. The new write cache node records the logical address range and data information of the write command and is inserted into the cache list. After the new write cache node is inserted, since the valid data marker of the conflict location of the second cache node has been cleared, the read command will hit the new write cache node instead of the second cache node when searching the cache, thereby ensuring that the host can read the latest written data. If the logical address range of the write command completely covers the logical address range of the second cache node, all valid data markers and dirty data markers of the second cache node are cleared and can be released in the subsequent flush process. If the logical address range of the write command only partially covers the logical address range of the second cache node, only the markers at the conflicting locations in the second cache node are cleared, while the non-conflicting portions retain valid data markers and dirty data markers and continue to participate in the subsequent flush process.

[0065] This optional embodiment reuses the existing write conflict handling process when the write command hits the second cache node that has already been transferred, thereby making the target address range of the data migration command available to the write command after the data copy is completed. At the same time, through the conflict marking mechanism and the replacement of the new write cache node, the consistency and correctness of the data are guaranteed.

[0066] Optionally, in some embodiments, after copying data in segments from the read cache space to the data cache space of each second cache node, the method further includes: releasing each first cache node and the read cache space.

[0067] In this optional embodiment, after the data is copied in segments from the read cache space to the data cache space of each second cache node, the solid-state drive (SSD) releases all first cache nodes and read cache space. Specifically, the SSD finds all first cache nodes generated by this data migration command from the context management information of the data migration command, removes each first cache node from the cache list, and releases the node resources occupied by the first cache nodes, while simultaneously releasing the read cache space. First cache nodes are only used in the data migration command scenario; they are created at the start of the data migration command processing and released at the end of the data migration command. Their lifecycle differs from that of read nodes generated by the pre-read command, but both are managed for conflict lookup on the cache list. Since first cache nodes do not occupy data cache space, do not contain dirty data that needs to be flushed, and do not occupy cache space pool resources, they do not participate in the cache flushing process and cache eviction mechanisms (such as the Least Recently Used (LRU) strategy). They will not be accidentally removed due to cache eviction and will continuously reside in the cache list during the execution of the data migration command to support conflict checking. After releasing the first cache nodes and read cache space, the data migration command completes processing and returns a command completion response to the host completion queue. The second cache node is not released in this step, but is kept in the cache list. The background flush process persists the data in the second cache node's data cache space to the flash media and then releases it according to the existing cache eviction mechanism.

[0068] This optional embodiment avoids the first cache node occupying cache list resources for a long time and affecting the conflict checking of other commands by releasing the first cache node and read cache space in a timely manner after the data copy is completed. At the same time, releasing the read cache space allows memory resources to be reclaimed in a timely manner for the processing of other commands, thereby improving resource utilization.

[0069] Optionally, in some embodiments, after the status flag of the second cache node is updated to indicate that the data transmission has been completed, the method further includes: flushing the data in the second cache node to the flash memory medium.

[0070] In this optional embodiment, after the status identifiers of all second cache nodes are uniformly updated to indicate that data transmission has been completed, the background flushing process of the solid-state drive (SSD) persists the data in the data cache space of the second cache nodes to the flash memory medium. The type identifier of the second cache node is "write," which is consistent with the cache node type generated by existing write commands, so the existing cache flushing process can be used. After the flushing is completed, the data in the second cache node has been persistently stored, and subsequent read commands can directly read data from the flash memory medium without going through the cache node again. After the second cache node is flushed, it is released according to the existing cache eviction mechanism. Since the conflict marker (hasoldoverlap / hasnewoverlap) may have been updated when the second cache node was inserted into the cache list, after the status of the second cache node is updated to indicate that data transmission has been completed, the SSD will perform relevant conflict handling based on the conflict marker. The specific conflict handling method is implemented by the existing cache conflict handling mechanism, including determining the data validity of each cache node within the overlapping address range based on the conflict marker and bitmap set, and skipping or reclaiming invalid data.

[0071] This optional embodiment reuses the existing cache flushing process to persist the data in the second cache node to the flash memory medium. This eliminates the need to develop a separate data persistence mechanism for the data migration command, reducing implementation complexity, while ensuring that the data written by the data migration command can be correctly persisted and stored.

[0072] Optionally, in some embodiments, the context management information of the data migration command records the index information of each first cache node and each second cache node.

[0073] In this optional embodiment, when the solid-state drive (SSD) creates the first and second cache nodes, it records the index information of each cache node in the context management information of the data migration command. The index information is exemplarily the node identifier (tag) of the cache node in the cache list, used to index and locate each cache node during the processing of the data migration command. The context management information is a management data structure maintained internally by the SSD for each executing command, recording information such as the command's status, allocated resources, and created cache nodes. Through the context management information, the SSD can quickly locate the relevant cache nodes at each processing stage of the data migration command. For example, in the data copy stage, the SSD obtains the index information of all second cache nodes from the context management information, locates each second cache node based on the index information, obtains the destination address (i.e., the data cache space address) of the data copy from each second cache node, and copies the data in the read cache space into the corresponding data cache space in segments according to the length of each second cache node. In the resource release stage, the SSD obtains the index information of all first cache nodes from the context management information, locates each first cache node based on the index information, and removes it from the cache list. Context management information can also record the address and length of the read cache space so that the read cache space can be released when resources are rolled back or commands are completed.

[0074] This optional embodiment records the index information of each cache node in the context management information of the data migration command, providing a convenient indexing method for locating and operating cache nodes in each processing stage of the data migration command, avoiding the overhead of searching for cache nodes again in the cache chain, and improving the processing efficiency of the data migration command.

[0075] Based on the above embodiments and optional embodiments, this application splits and caches the source address range and target address range of the data migration command into a first cache node and a second cache node in a cache linked list. This transforms the address range conflict checking of read and write commands from traversing the source address range set and the target address range set to a search mechanism that reuses the cache linked list, significantly shortening the conflict checking path. By allocating contiguous read cache space based on the logical address length corresponding to the source address range, it avoids allocating data cache space separately for each first cache node, reducing the blocking of the read and write process by cache space occupation. By defining a unified field structure and distinguishing type identifiers for each cache node, the first cache node and the second cache node can be incorporated into the existing cache management framework of the solid-state drive for unified management. By distinguishing and processing conflicting cache nodes according to their type and status when inserting a first cache node, the protection of the source address range is ensured while improving the insertion success rate. By distinguishing and processing conflicting cache nodes according to their status and type when inserting a second cache node and supporting command-line-based conflict checking, the application achieves the following: The system employs self-conflict identification for identifier comparison, resolving conflicts when the address ranges of data migration commands overlap. It ensures resource consistency and availability by performing a comprehensive resource rollback when cache node insertion fails. It guarantees the atomicity of data migration command execution by uniformly updating the status identifiers of all second cache nodes without interruption. It ensures that command processing effectively satisfies access constraints and reduces processing latency by searching the cache node corresponding to the address range of the read / write command in the cache chain and processing it differently based on type and status. It improves resource utilization by promptly releasing the first cache node and read cache space after data copying. It reduces implementation complexity by reusing the existing cache flushing process to persist data in the second cache node. It avoids data migration commands occupying cache space pool resources and affecting other commands by using different allocation mechanisms for read cache space and data cache space. Finally, it covers multiple scenarios for data migration commands by supporting the splitting and caching of multiple source and destination address ranges.

[0076] This application uses the aforementioned data migration method to cache the source and destination address ranges of data migration commands as nodes in a cache linked list. It reuses the existing cache linked list lookup mechanism of the solid-state drive for conflict checking, avoiding the linear time overhead of traversing the set for search, significantly reducing conflict checking time, lowering command processing latency, and effectively improving the read and write performance of the solid-state drive in scenarios with intensive data migration commands. At the same time, it ensures the atomicity of data migration command execution and improves the reliability, availability, and determinism of command processing.

[0077] See Figure 2 , Figure 2 This is a schematic diagram of the structure of an embodiment of the storage medium provided in this application.

[0078] The storage medium 60 stores program data 61, which, when executed by the processor, implements, as follows: Figure 1 The described data migration method.

[0079] The program data 61 is stored in a storage medium 60 and includes several instructions for causing the solid-state drive (SSD) to execute all or part of the steps of the methods in the various embodiments of this application. The storage medium 60 can be a NAND flash memory, dynamic random access memory (DRAM), or static random access memory (SRAM) in the SSD, thereby providing the firmware of the SSD with the program code and data storage space required for operation. Alternatively, the storage medium can be other types of computer-readable storage media, such as read-only memory (ROM), programmable ROM, erasable programmable ROM, or electrically erasable programmable ROM, used to store firmware programs and configuration data, enabling the SSD to load and execute the corresponding program code during startup or operation, thus realizing the various functions of the data transfer method. As long as the storage medium 60 can store the corresponding program data 61 and implement the required data transfer method processing steps when the processor executes the corresponding program data 61, it can be used as the applicable object of the embodiments of this application.

[0080] See Figure 3 , Figure 3 This is a schematic diagram of the structure of an embodiment of the solid-state drive provided in this application.

[0081] The solid-state drive 70 includes a processor 72 and a memory 71 interconnected. The memory 71 stores a computer program, and when the processor 72 executes the computer program, it implements, for example, Figure 1 The described data transfer method. The memory 71 may include the storage medium 60, or it may be another separately developed memory.

[0082] In this embodiment, the solid-state drive 70 can specifically be one of the following types of solid-state drives: SATA solid-state drive, PCIe solid-state drive, or M.2 solid-state drive. This application does not specifically limit this type. The processor 72 and the memory 71 can be connected via a bus or other means. The memory 71, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and functional modules, such as the program instructions / modules of the data transfer method in this embodiment. The processor 72 executes various functional applications and data processing of the solid-state drive by running the software programs, instructions, and modules stored in the memory 71, thereby implementing the data transfer method of the above-described method embodiment. The solid-state drive 70 also includes a flash memory medium used for persistent data storage. This flash memory medium can be NAND Flash, including but not limited to single-level cell (SLC), multi-level cell (MLC), three-level cell (TLC), and four-level cell (QLC) flash memory chips. On storage media with long programming latency such as QLC NAND, the data migration method of this application caches the source address range and target address range of the data migration command as nodes in a cache linked list, reuses the lookup mechanism of the cache linked list for conflict checking, avoids the linear time overhead of traversing the set for lookup, can optimize the application experience of solid-state drives in scenarios with intensive data migration commands, and improve overall performance, reliability and service life.

[0083] Unlike existing technologies, this application discloses a data migration method, storage medium, and solid-state drive (SSD). This application splits and caches the source and target address ranges of data migration commands into first and second cache nodes in a cache linked list, based on a preset granularity. Data reading and copying are performed using this cache linked list, allowing read and write commands to directly reuse the cache linked list's lookup mechanism for address range conflict checking. This avoids traversing the large and continuously growing sets of source and target address ranges one by one, significantly reducing conflict checking time and command processing latency, thereby effectively improving the read and write performance of the SSD in scenarios with intensive data migration commands. Simultaneously, it allocates contiguous read cache space based on the logical address length corresponding to the source address range and copies data in segments from the read cache space to the data cache space of each second cache node. This avoids allocating separate data cache space for each first cache node, reducing cache space usage and blocking the read and write process, and improving data copying efficiency.

[0084] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. It should be noted that the storage medium embodiments and solid-state drive embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0085] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A data migration method, characterized in that, include: Receive data transfer command; The data migration command includes a source address range and a destination address range; Based on the logical address length corresponding to the source address range, allocate read cache space; The source address range is split into at least one first fragment range according to a preset granularity, and a first cache node is created for each first fragment range, and each first cache node is inserted into the cache linked list. The target address range is divided into at least one second segment range according to the preset granularity, and a second cache node is created for each second segment range. Data cache space is allocated for each second cache node, and each second cache node is inserted into the cache linked list. Based on the cache list, data is read from the first shard range corresponding to each first cache node into the read cache space, and data is copied in segments from the read cache space to the data cache space of each second cache node.

2. The data transfer method according to claim 1, characterized in that, Each cache node records type identifier, status identifier, and address metadata; The type identifier of the first cache node is the data migration read scenario identifier, and the type identifier of the second cache node is the data write scenario identifier; The status flag is used to indicate the data transmission status of the corresponding cache node; when the first cache node and the second cache node are created, the status flag indicates that the data transmission is not complete; the status flag of the second cache node is updated to indicate that the data transmission is complete after the data is copied from the read cache space to the second cache node. Address metadata is used to record the address mapping relationship between cache nodes and corresponding shard ranges; The first cache node also records a command identifier, which is used to uniquely identify the data migration command.

3. The data transfer method according to claim 2, characterized in that, The step of inserting each of the first cache nodes into the cache linked list includes: Determine whether there exists a first conflicting cache node in the cache list whose corresponding address range overlaps with the first fragment range of the current first cache node; If the first conflicting cache node exists, determine whether the type identifier of the first conflicting cache node is a data migration scenario identifier or a data read scenario identifier; If the type identifier of the first conflicting cache node is neither a data migration scenario identifier nor a data read scenario identifier, then the status identifier of the first conflicting cache node is identified. If the status flag of the first conflicting cache node indicates that the data transmission has not been completed, then the insertion of the current first cache node is paused. If the first conflicting cache node does not exist, or the type identifier of the first conflicting cache node is a data transfer scenario identifier or a data read scenario identifier, or the status identifier of the first conflicting cache node indicates that the data transfer has been completed, then the current first cache node is inserted into the cache list.

4. The data transfer method according to claim 2, characterized in that, The step of inserting each of the second cache nodes into the cache linked list includes: Determine whether there exists a second conflicting cache node in the cache list whose address range overlaps with the second fragment range of the current second cache node; If the second conflicting cache node exists, then identify the status identifier of the second conflicting cache node; If the status flag of the second conflict cache node indicates that the data transmission has not been completed, then the type flag of the second conflict cache node is identified; If the type identifier of the second conflict cache node is a data migration scenario identifier, then determine whether the command identifier of the second conflict cache node is the command identifier corresponding to the data migration command; If the status identifier of the second conflict cache node indicates that the data transmission is not complete and the type identifier is neither the read data scenario identifier nor the move read data scenario identifier, or if the status identifier of the second conflict cache node indicates that the data transmission is not complete and the type identifier is the move read data scenario identifier and the command identifier is not the command identifier corresponding to the data move command, then the insertion of the current second cache node is paused. If the second conflict cache node does not exist, or the status identifier of the second conflict cache node indicates that the data transmission is complete, or the status identifier of the second conflict cache node indicates that the data transmission is incomplete and the type identifier is a read data scenario identifier, or the status identifier of the second conflict cache node indicates that the data transmission is incomplete and the type identifier is a move read data scenario identifier and the command identifier is the command identifier corresponding to the data move command, then the current second cache node is inserted into the cache list.

5. The data transfer method according to claim 1, characterized in that, If any first cache node or second cache node fails to be inserted into the cache list during the process of inserting each of the first cache nodes into the cache list and inserting each of the second cache nodes into the cache list, then all inserted first cache nodes and second cache nodes are removed from the cache list, the allocated data cache space and the read cache space are released, and the data migration command is retried later.

6. The data transfer method according to claim 2, characterized in that, The status flag of the second cache node is updated to indicate that data transmission has been completed, including: After all the data copies have been completed on all the second cache nodes, the status flags of all the second cache nodes are uniformly updated to indicate that the data transmission has been completed, and the uniform update is not interrupted during the process.

7. The data transfer method according to claim 2, characterized in that, After inserting each of the first cache nodes into the cache linked list and each of the second cache nodes into the cache linked list, the method further includes: Upon receiving a read command, the system searches the cache list for a cache node whose address range overlaps with the address range of the read command. If the found cache node is the first cache node, the system skips the first cache node and continues searching. If the found cache node is the second cache node whose status indicates that data transmission is incomplete, the system determines that the read command conflicts with the data transfer command. If the found cache node is the second cache node whose status indicates that data transmission is complete, the system returns the data in the data cache space of the second cache node. When a write command is received, the cache node whose address range overlaps with the address range of the write command is searched in the cache list. If the cache node found is the first cache node or the second cache node whose status indicates that the data transmission is not complete, it is determined that the write command and the data transfer command conflict. If the cache node found is the second cache node whose status indicates that the data transmission is complete, the write command is processed according to the write conflict handling process of the cache list.

8. The data transfer method according to claim 1, characterized in that, After copying data in segments from the read cache space to the data cache space of each of the second cache nodes, the method further includes: Release each of the first cache nodes and the read cache space.

9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the solid-state drive, it implements the steps of the data transfer method as described in any one of claims 1 to 8.

10. A solid-state drive, characterized in that, It includes an interconnected processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the steps of the data transfer method as described in any one of claims 1 to 8.

Images