System and method for processing replication commands

Abstract

Systems and methods for processing copy commands are disclosed. A first controller of a storage device receives a copy command from a host via a first queue. The storage device generates a read command and a write command based on the copy command and submits the read command and the write command to a second controller of the storage device via a second queue. The second controller fetches and processes the read command and the write command from the second queue. The storage device reads data stored in a first location of a storage medium associated with a source address based on the processing of the read command and writes the data to a second location of the storage medium associated with a destination address. The first controller sends a signal to the host indicating completion of the copy command.

Description

[0001] This application claims priority and benefit to U.S. Provisional Application No. 63 / 057,726, filed July 28, 2020, entitled "Method for Processing Copy Commands in an NVMe SSD," the entire contents of which are incorporated herein by reference. This application also relates to U.S. Application No. 17 / 024,598, filed September 17, 2020, entitled "System and Method for Processing Commands for a Storage Device," the contents of which are incorporated herein by reference. This application further relates to U.S. Application No. 17 / 062,467, filed October 2, 2020, the contents of which are incorporated herein by reference. Technical Field

[0002] One or more aspects of embodiments of this disclosure relate to storage devices, and more specifically, to processing commands for accessing storage devices. Background Technology

[0003] Host computing devices can utilize storage interface protocols to access non-volatile storage devices (such as solid-state drives (SSDs)). Non-volatile storage devices may include controllers for processing commands generated using the protocol. As protocols evolve, more and more features (e.g., commands) can be added. Traditional SSDs may not be able to handle these added features without redesigning the SSD controller. Therefore, it is desirable to have an SSD controller that can process commands from the host even when commands are added to the protocol without requiring a redesign of the SSD controller. Summary of the Invention

[0004] Embodiments of this disclosure include a method for processing a copy command from a host to a storage device. A first controller of the storage device receives the copy command from the host via a first queue. The copy command includes a first source address and a first destination address. The storage device generates a first read command and a first write command based on the copy command. The storage device submits the first read command and the first write command to a second controller of the storage device via a second queue. The second controller retrieves and processes the first read command and the first write command from the second queue. Based on the processing of the first read command, the storage device reads data stored in a first location associated with the first source address on the storage medium of the storage device. Based on the processing of the first write command, the storage device writes the data to a second location associated with the first destination address on the storage medium. The first controller sends a signal indicating the completion of the copy command to the host.

[0005] According to one embodiment, a first source address is associated with a first logical space of the storage device identified by a first identifier, and a first destination address is associated with a second logical space of the storage device identified by a second identifier.

[0006] According to one embodiment, the copy command includes a second destination address, wherein the step of writing data includes: writing a first portion of the data to a second location of the storage medium associated with the first destination address, and writing a second portion of the data to a third location of the storage medium associated with the second destination address.

[0007] According to one embodiment, the data stored in a first location of the storage medium includes metadata having a first part and a second part, wherein the step of writing the data includes: writing the first part of the metadata to a third location of the storage medium associated with a first destination address; generating the third part of the metadata by the storage device based on the first destination address; and writing the third part of the metadata, instead of the second part of the metadata, into the storage medium by the storage device.

[0008] According to one embodiment, the method further includes: skipping the reading of a second portion of the metadata based on the processing of the first read command.

[0009] According to one embodiment, the method further includes: skipping the writing of a second portion of the metadata based on the processing of the first write command.

[0010] According to one embodiment, the second part of the metadata includes data protection information.

[0011] According to one embodiment, a first source address is associated with a first logical space configured to store data blocks of a first size, and a first destination address is associated with a second logical space configured to store data blocks of a second size different from the first size.

[0012] According to one embodiment, the copy command is associated with a second source address. The method further includes: generating a second read command by the storage device based on the copy command; submitting the second read command to a second controller of the storage device via a second queue; retrieving and processing the second read command from the second queue by the second controller; and reading data stored in a third location of the storage device associated with the second source address based on the processing of the second read command, wherein the processing of the second read command by the second controller occurs simultaneously with the processing of the first write command.

[0013] According to one embodiment, the storage device is a non-volatile storage device, and the first controller and the second controller follow the Fast Non-Volatile Memory (NVMe) protocol.

[0014] According to one embodiment, the method further includes: submitting a first completion status to a first completion queue by a second controller.

[0015] According to one embodiment, the step of sending a signal includes: submitting a second completion status to a second completion queue based on submitting a first completion status to a first completion queue.

[0016] Embodiments of this disclosure also include a storage device comprising a storage medium and one or more processors connected to the storage medium. The one or more processors are respectively configured to: receive a copy command from a host via a first controller and a first queue, wherein the copy command includes a first source address and a first destination address; generate a first read command and a first write command based on the copy command; submit the first read command and the first write command to a second controller via a second queue; retrieve and process the first read command and the first write command from the second queue via the second controller; read data stored in a first location associated with the first source address in the storage medium based on the processing of the first read command; write data to a second location associated with the first destination address in the storage medium based on the processing of the first write command; and send a signal indicating completion of the copy command to the host via the first controller.

[0017] As those skilled in the art will recognize, embodiments of this disclosure allow conventional storage devices to process commands and / or extensions. A command can be a copy command between two addresses in the same namespace having the same Logical Block Address (LBA) format and / or a copy command between addresses in two namespaces having different LBA formats / sizes and multiple destination ranges. Decomposing copy commands into concurrently processable internal read and write commands can lead to better performance and / or reduced processing overhead for the storage device.

[0018] These and other features, aspects, and advantages of the embodiments of this disclosure will be more fully understood when considered in conjunction with the following detailed description, the appended claims, and the accompanying drawings. Of course, the actual scope of the invention is defined by the appended claims. Attached Figure Description

[0019] Non-limiting and non-exhaustive embodiments of this invention are described with reference to the following drawings, wherein, unless otherwise stated, the same reference numerals denote the same parts throughout the drawings.

[0020] Figure 1 This is a block diagram of a data storage and retrieval system according to one embodiment;

[0021] Figure 2 This is a conceptual layout diagram of various modules for submitting and processing storage interface commands according to one embodiment;

[0022] Figure 3This is a layout diagram of internal commands stored as Submission Queue Entries (SQEs) in an internal submission queue according to one embodiment;

[0023] Figure 4 This is a flowchart, according to one embodiment, of a Data Set Management (DSM) command for processing a given set of logical block address ranges to deallocate (unmap) from a given namespace;

[0024] Figure 5 It is a conceptual block diagram in the format of a logic block according to one embodiment;

[0025] Figure 6A and Figure 6B This is a flowchart, according to one embodiment, for processing a replication command submitted by a host to an external commit queue;

[0026] Figure 7 This is a more detailed block diagram of the components of a storage device according to one embodiment for processing internal read and write commands associated with copy commands;

[0027] Figures 8A to 8C This is a conceptual layout diagram of various buffers invoked according to one embodiment to copy data from a source namespace to a destination namespace;

[0028] Figures 9A to 9B This is a conceptual layout diagram of various buffers invoked according to one embodiment to copy data from multiple LBA ranges of a source namespace to a single LBA range of a destination namespace, wherein both the source and destination namespaces have the same LBA format.

[0029] Figures 10A to 10B This is a conceptual layout diagram of various buffers invoked according to one embodiment to copy data from multiple LBA ranges of a source namespace to multiple LBA ranges of a destination namespace, wherein the source namespace and the destination namespace have different LBA formats; and

[0030] Figures 11A to 11B This is a conceptual layout diagram of a buffer and SGL table according to one embodiment for copying data from a source LBA range of one namespace to a destination LBA range of another namespace, wherein the source LBA range and the destination LBA range have the same characteristics as... Figures 10A to 10B The source LBA range and destination LBA range in the LBA have similar formats. Detailed Implementation

[0031] In the following description, exemplary embodiments will be illustrated with reference to the accompanying drawings, wherein the same reference numerals throughout denote the same elements. However, this disclosure may be implemented in various different forms and should not be construed as being limited to the embodiments shown herein. Rather, these embodiments are provided as examples so that this disclosure will be thorough and complete, and will fully convey the aspects and features of this disclosure to those skilled in the art. Therefore, processes, elements, and techniques unnecessary for a full understanding of the aspects and features of this disclosure by those skilled in the art are not described. Unless otherwise stated, the same reference numerals denote the same elements throughout the drawings and textual description, and therefore their description is not repeated. Furthermore, in the drawings, the relative dimensions of elements, layers, and regions may be exaggerated and / or simplified for clarity.

[0032] Host computing devices can utilize communication protocols to access non-volatile storage devices (such as solid-state drives (SSDs)). Non-volatile storage devices may include controllers for processing commands generated using the protocol. As protocols evolve, more and more features (e.g., commands) can be added. Traditional SSDs may not be able to handle these added features without redesigning the SSD controller. Therefore, it is desirable to have an SSD controller that can handle commands from the host even when commands are added to the protocol without requiring a redesign of the SSD controller.

[0033] Generally, embodiments of this disclosure relate to a storage device configured to process commands from a host that follows a communication protocol. The communication protocol may be, for example, the Fast Non-Volatile Memory (NVMe) protocol, but embodiments of this disclosure are not limited thereto and can be extended to other protocols that will be understood by those skilled in the art.

[0034] In one embodiment, commands from the host are broken down into one or more internal commands for execution by the storage device. The storage device may include an internal controller configured to retrieve and execute one or more internal commands. In one embodiment, no communication path is established between the host and the internal controller. Therefore, the internal controller is not exposed to the host.

[0035] In one embodiment, the host uses an interface (such as an NVMe interface) to submit host commands to an external commit queue exposed to the host and associated with the storage device. An external controller of the storage device can retrieve / obtain the host commands and pass the retrieved commands to the storage device's processor for generating internal commands. The internal commands can be submitted to one or more internal commit queues. In one embodiment, the internal commit queues and the internal controller are not exposed to the host (e.g., hidden from the host).

[0036] The internal controller can fetch / acquire internal commands and send them as standard commands conforming to a communication protocol (e.g., the NVMe protocol) or vendor-specific commands for the processor to execute, as if these commands originated from the host. In one embodiment, internal commands are fetched / acquired and executed by storage devices simultaneously (e.g., in parallel). The terms "simultaneously" and "in parallel" can mean substantially simultaneously, at a rate faster than sequential processing, etc.

[0037] Figure 1 This is a block diagram of a data storage and retrieval system 100 according to one embodiment. The system includes one or more hosts 102a to 102b (host A and host B, collectively referred to as 102) configured with the same or different operating systems (e.g., Windows OS and Linux OS). One or more hosts 102 can be connected to a data storage device 104 via storage interface buses 106a, 106b (collectively referred to as 106). The storage interface bus 106 may be, for example, a Fast Peripheral Component Interconnect (PCIe) bus. In one embodiment, the host 102 uses a storage interface protocol to transfer and receive data from and receive data from the data storage device 104 via the storage interface bus 106. The storage interface protocol may be the NVMe protocol as described in NVM (NVMe) Fundamental Specification Revision 1.4a (or a previous or future revision) of March 9, 2020, available at http: / / nvmexpress.org, the contents of which are incorporated herein by reference. For the purposes of describing this embodiment, the NVMe protocol is used as an example. However, those skilled in the art will understand that various embodiments will be extended to other current or future storage interface protocols similar to the NVMe protocol without departing from the spirit and scope of the inventive concept.

[0038] The host 102 may be a computing device having processors 108a, 108b (collectively referred to as 108) configured to process data. The processor 108 may be a general-purpose central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or any other form of processing unit configured with software instructions, microcode, and / or firmware.

[0039] In one embodiment, processor 108 is connected to host memory spaces 110a, 110b (collectively referred to as 110). Host memory space 110 may be static random access memory (SRAM), dynamic random access memory (DRAM), etc. Applications may be stored in host memory space 110 for execution by processor 108. Applications may request data to be stored in or retrieved from storage device 104. Applications may generate output based on the storage or retrieval of data. Output may be, for example, displaying the retrieved data on a display device. In one embodiment, storage device 104 uses internal commands to process requests from applications, allowing for faster and less overhead processing of requests.

[0040] Host memory space 110 may also store one or more external commit queues (SQs) 112a, 112b (collectively referred to as 112) and one or more external complete queues (CQs) 114a, 114b (collectively referred to as 114). Host 102 may use external commit queue 112 to submit storage interface commands for execution by storage device 104, and use external complete queue 114 to receive completion messages from storage device 104 after the commands have been executed. In some embodiments, instead of host memory space 110 (or in addition to host memory space 110), external commit queue 112 and external complete queue 114 are included in a controller memory buffer (CMB) of storage device 104. Therefore, a reference to host memory space 110 may be understood to include a reference to the CMB. In either scenario, external commit queue 112 and external complete queue 114 are exposed to and accessible by the host.

[0041] In one embodiment, host memory space 110 stores Physical Region Page (PRP) / Scatter Aggregate Table (SGL) entries 116a, 116b (collectively referred to as 116) and other data 117a, 117b (collectively referred to as 117). For example, PRP / SGL entry 116 may describe the physical memory location of host memory space 110, be used to write data read from storage device 104 for NVMe read commands, and be used to read data to be written to storage device 104 for NVMe write commands. For a specific storage interface command, a Logical Block Address (LBA) range may be stored as data 117 in host memory space, rather than being included in the command itself. An example of such a command is a dataset management deallocation command that can be used to deallocate / unmap an LBA range provided by the host.

[0042] Storage device 104 may be a non-volatile storage device (such as a solid-state drive (SSD)). Storage device 104 may include communication interface 118, NVMe subsystem 120, and device controller 122. Although NVMe subsystem 120 and device controller 122 are depicted as separate modules, it should be understood that the functionality of NVMe subsystem 120 and device controller 122 may also be combined into a single module. In one embodiment, communication interface 118 includes a PCIe port and endpoints, enabling ingress communication from host 102 to storage device 104 and egress communication from storage device 104 to host 102.

[0043] The NVMe subsystem 120 may include, but is not limited to, one or more external controllers 124a, 124b (collectively referred to as 124) and one or more internal controllers 126. The external controllers 124 and internal controllers 126 may be implemented via one or more processors (such as, for example, an application-specific integrated circuit (ASIC). In one embodiment, one or more external controllers 124 are exposed to the host via a communication interface 118 (e.g., a PCIe interface) and are invoked to handle queuing operations of the external submission queue 112 and the external completion queue 114. For example, a particular external controller 124 may retrieve a storage interface command from a particular external submission queue 112 and place a completion status in the corresponding external completion queue 114 based on the status of the requested command (e.g., an indication that the requested command has been completed).

[0044] In one embodiment, a specific external controller 124 is associated with one or more namespaces. In this regard, the logical space of the storage device 104 can be divided into one or more logical spaces / namespaces, each identified by a unique namespace ID (NSID). For example, assuming a 1TB storage device using 4K logical blocks, three namespaces could be allocated with the following capacities: 512GB, 256GB, and 256GB. Commands submitted by host 102 can relate to a specific namespace identified via the NSID.

[0045] In one embodiment, one or more internal controllers 126 are not exposed to host 102 (e.g., hidden from host 102) and are not accessible by host 102. In this respect, no communication interface (e.g., PCIe interface) is provided between host 102 and internal controller 126. According to one embodiment, internal controller 126 may emulate the function of external controller 124. In this respect, internal controller 126 may interact with device controller 122 as if it were external controller 124.

[0046] In one embodiment, storage device 104 includes an internal CMB 128 for storing one or more internal submit queues 130 and one or more internal complete queues 132. CMB 128 may store other data 134 (e.g., internal data buffers) and internal PRP / SGL entries 136. In one embodiment, internal controller 126 accesses internal CMB 128 to retrieve and process internal commands submitted by device controller 122. The contents of internal CMB 128 and the processing of internal commands may not be exposed to host 102 (e.g., hidden from host 102) and may not be accessible by host 102.

[0047] In one embodiment, device controller 122 interacts with external controller 124 and internal controller 126 to execute commands requested by host 102. Device controller 122 may include, but is not limited to, one or more processors 140 and one or more media interfaces 142. The one or more processors 140 may be configured to execute computer-readable instructions for processing commands to and from external controller 124 and internal controller 126, and for managing the operation of storage device 104. The computer-readable instructions executed by the one or more processors 140 may be, for example, firmware code.

[0048] In one example, one or more processors 140 may be configured to interact with an external controller 124 and an internal controller 126 to receive write commands or read commands from a storage medium (e.g., NVM media 144). One or more processors 140 may interact with the NVM media 144 via a media interface 142 to perform write or read operations. The NVM media 144 may include one or more types of non-volatile memory (such as flash memory).

[0049] In one embodiment, storage device 104 further includes internal memory 138 for short-term or temporary storage during operation of storage device 104. Internal memory 138 may include DRAM (Dynamic Random Access Memory), SRAM (Static Random Access Memory), and / or DTCM (Data Tightly Coupled Memory). Internal memory 138 may be used in place of or in addition to internal CMB 128 to store some or all of the data stored in internal CMB 128 (e.g., internal submit queue 130, internal completion queue 132, data 134, PRP / SGL entry 136, etc.). Therefore, a reference to internal CMB 128 can be understood to include a reference to internal memory 138.

[0050] Figure 2This is a conceptual layout diagram of various modules for submitting and processing commands associated with a storage interface protocol or vendor-defined commands, according to one embodiment. The various modules may be hosted by an external controller 124 and / or an internal controller 126. Furthermore, although it is assumed that one or more modules are separate functional units, those skilled in the art will recognize that, without departing from the spirit and scope of the inventive concept, the functionality of the modules may be combined or integrated into a single module, or further subdivided into additional sub-modules.

[0051] In one embodiment, instances of command module 200 and PRP / SGL extraction module 202 are included in both external controller 124 and internal controller 126. Command module 200 may include, for example, a command arbitration submodule, a command extraction submodule, a command parser submodule, and a command scheduler submodule. The command extraction submodule may be configured to extract host commands from external submission queue 112 or internal commands from internal submission queue 130. The command arbitration submodule may be configured to invoke an arbitration burst policy to arbitrate between various controllers and between various submission queues of the selected controller to select the submission queue from which commands are extracted. The command parser submodule may be configured to parse commands submitted to external controller 124 or internal controller 126 for checking and verifying command format, NSID validity, reservation status, whether LBA checks are required, protection information validity, etc., based on namespace format checks. The command parser submodule may also be configured to interface with an LBA overlap checker (not shown) to pass commands based on programmed configuration information when LBA overlap checks are necessary for the command. The command parser submodule can also determine whether commands should be bypassed from the host subsystem and sent directly to media interface 142 to improve system performance. The LBA overlap checker is responsible for checking whether a host or internal command is currently being processed for the same scope as a newly arrived command. If the answer is yes, the LBA overlap checker can hold the newly arrived command until a previously retrieved and currently being processed command completes. The command scheduler submodule is responsible for assigning commands to various processors based on their type (e.g., performance, non-performance, or administrative).

[0052] The PRP / SGL extraction module 202 can be configured to extract PRP or SGL entries 116 from host memory (in the case of external controller 124) or PRP or SGL entries 136 from internal CMB 128 (in the case of internal controller 126). In one embodiment, both the command module 200 and the PRP / SGL extraction module 202 follow the storage interface protocol when extracting commands and PRP / SGL entries, respectively.

[0053] In one embodiment, host 102 submits a storage interface command to one of the external submission queues 112. Command module 200 (e.g., command retrieval submodule) in one of the external controllers 124 retrieves / obtains the command from the external submission queue 112 and passes it to device controller 122 for further processing. Depending on the type of command submitted by the host, device controller 122 may access host memory 110 to read data 117 (e.g., LBA range) required to process the retrieved command. In one embodiment, if the command submitted by host 102 is a data transfer command, the PRP / SGL retrieval module 202 associated with external controller 124 may retrieve PRP / SGL entry 116 or PRP / SGL entry 136 from host memory 110 or CMB, respectively, for reading or writing data associated with the data transfer command.

[0054] In one embodiment, the device controller 122 is configured to generate one or more internal commands based on an extracted command. The one or more internal commands may include a portion of the extracted command (e.g., an opcode in the extracted command). In one embodiment, the one or more internal commands are different from the extracted command. For example, the internal command may have an opcode different from the opcode in the extracted command.

[0055] Similar to how host 102 submits NVMe commands to external submission queue 112, device controller 122 can submit one or more internal commands to internal submission queue 130. For example, device controller 122 can notify command module 200 of internal controller 126 that one or more internal commands have been submitted by updating a hardware doorbell register. In some cases, commands submitted by host 102 can be broken down into multiple internal commands. In one embodiment, multiple internal commands are submitted and processed by one or more internal controllers 126 simultaneously (e.g., in parallel), thereby allowing for improved performance of storage device 104.

[0056] In one embodiment, if an internal command requires data transfer, the PRP / SGL extraction module 202 of the internal controller 126 can extract internal PRP / SGL entries 136 from the internal CMB 128 for reading or writing data associated with the internal command. Internal PRP / SGL entries 136 may be generated by the device controller 122. In one embodiment, for read operations requiring transfer from the NVM medium 144, internal PRP / SGL entries 136 may be used in the destination buffer 204. For write operations requiring transfer to the NVM medium 144, internal PRP / SGL entries 136 may be used in the source buffer 206.

[0057] In one embodiment, the transfer queue (TQ) module 208 may be configured to process internal requests for transferring data to / from an intermediate buffer (not shown) based on command type (e.g., read or write). For example, for an internal read or write operation, the transfer queue module 208 may obtain information (including transfer (TR) descriptors and direct memory access (DMA) descriptors) from the device controller 122 regarding certain data structures used to control direct memory access. The TR descriptor may contain the command type (e.g., read or write) for the data transfer. The DMA descriptor may contain information about the intermediate buffer for the command type. For example, if the command type is an internal read command, the intermediate buffer may be an intermediate read buffer used by the media interface 142 to temporarily hold data read from the NVM media 144. If the command type is an internal write command, the intermediate buffer may be an intermediate write buffer used by the media interface 142 to temporarily hold data to be written to the NVM media 144.

[0058] In one embodiment, the DMA manager (DMA_M) module 210 receives a DMA descriptor and a PRP / SGL entry 136, and transfers data from the source buffer 206 to the NVM medium 144 for internal write operations (via an intermediate buffer provided in the DMA descriptor), or transfers data from the NVM medium 144 to the destination buffer 204 for internal read operations (via an intermediate buffer provided in the DMA descriptor).

[0059] Figure 3 This is a layout block diagram of internal commands stored as Submission Queue Entries (SQEs) in an internal submission queue 130 according to one embodiment. In one embodiment, the internal commands are generated according to a storage interface protocol used to generate external commands. In this regard, the size of the internal command may be 64 bytes and may include a command identifier (ID) 300, an opcode (OpCode) 302, a namespace ID (NSID) 304, a buffer address 306, and command parameters 308. The command ID 300 may be the command ID within the internal submission queue 130 to which the internal command is submitted.

[0060] OpCode 302 can identify a specific command to be executed. In one embodiment, OpCode 302 is an NVMe OpCode that identifies an NVM command (e.g., write, read, management, dataset management, or vendor-specific command). In some embodiments, OpCode 302 identifies a new command in the internal command set that can be accessed separately by the internal controller 126.

[0061] Namespace ID 304 identifies the namespace on which the command identified by opcode 302 operates. Buffer address 306 may include internal PRP / SGL entry 136 (or a pointer to a PRP / SGL entry) in internal CMB 128. Any parameters associated with the command to be executed may be stored as command parameters 308.

[0062] Figure 4 This is a flowchart, according to one embodiment, for processing Data Set Management (DSM) commands submitted by host 102 to external submission queue 112 for the purpose of reclaiming (releasing) a given set of LBA ranges from a given namespace. Processing begins in block 400, where one of the external controllers 124 retrieves a command from external submission queue 112 and passes the retrieved command to device controller 122 for preprocessing by processor 140.

[0063] In block 402, processor 140 performs certain preprocessing actions (including, for example, initiating a host direct memory access operation via memory interface bus 106) to transfer LBA ranges from host memory 110 to internal memory 138 of the storage device. Furthermore, processor 140 can parse the LBA ranges to identify the total number of non-contiguous LBA ranges.

[0064] In block 404, processor 140 generates an internal release command for each non-contiguous LBA range identified by the processor. In one embodiment, the release command is a command that is not part of the storage interface protocol. Processor 140 may submit one or more internal release commands to one or more of the internal submission queue 130.

[0065] In boxes 406 through 412, release commands submitted for each LBA range are processed. Although processing is described with respect to a release command for a single LBA range, it should be understood that other release commands submitted for other LBA ranges may also be processed in parallel according to boxes 406 through 412.

[0066] In block 406, internal controller 126 retrieves and processes a release command from internal submission queue 130. Command module 200 of internal controller 126 can be invoked to retrieve the release command from internal submission queue 130. In one embodiment, assuming that processing the release command does not require data transfer, the PRP / SGL retrieval module 202 of internal controller 126 is not invoked, and no internal PRP / SGL entry 136 is created.

[0067] In block 408, internal controller 126 (e.g., an LBA overlap checker) determines whether the LBA range in an internal release command overlaps with the LBA of a command representing a command being processed by host 102. For example, the LBA range of the release command may overlap with the LBA address of an object currently being read by host 102. If an overlap is detected, internal controller 126 may wait until the host command completes before proceeding with the release of the LBA range.

[0068] However, if no overlap is detected, in block 410, the internal controller 126 transmits one or more commands via the device controller 122 to the media interface 142 for performing an LBA-scoped actual release operation on the NVM media 144. It should be understood that the command parser submodule may also be invoked to perform additional checks and verifications on the release commands based on the namespace format (e.g., checking and verifying command format, NSID validity, reservation status, whether LBA checks are required, protection information validity, etc.) before delivering one or more commands to the media interface 142.

[0069] When determining the completion status of the release operation, in box 412, the internal controller 126 submits the internal completion entry to the internal completion queue 132 associated with the internal submission queue 130 that submitted the internal release command.

[0070] In block 414, processor 140 (e.g., based on the state of the internal release command) determines whether all LBA ranges of the submitted DSM reclamation command have been reclaimed. If the answer is yes, then in block 416, external controller 124 submits the external completion entry to external completion queue 114 corresponding to external submission queue 112 to which the DSM reclamation command was submitted.

[0071] It should be understood that the processing of DSM reclamation commands according to embodiments of this disclosure provides technical improvements to the functionality of data storage device 104. For example, parallel processing of LBA ranges, resulting from dividing DSM reclamation commands into independent release commands (each release command having a separate LBA range), allows for better performance of the storage device. Furthermore, checking the overlap of each LBA range (e.g., via hardware) reduces the overhead of processor 140 by avoiding manual locking and unlocking of ranges. Additionally, in embodiments where the storage device includes two subsystems (e.g., a host subsystem for interacting with host 102 and a flash subsystem for interacting with NVM media 144) of a dedicated processor (e.g., processor 140) with executing firmware (e.g., firmware running on processor 140), the overhead of the host subsystem can be reduced because internal commands can be processed without much involvement from the host subsystem.

[0072] Process copy commands

[0073] In one embodiment, the command submitted by host 102 is a replication command (e.g., an NVMe replication command or a vendor-unique replication command) for copying data from one or more source addresses of NVM media 144 to one or more destination addresses. The source and destination addresses may be provided as source LBA ranges and destination LBA ranges. In one embodiment, the LBA range includes a starting LBA and the number of logical blocks within that range.

[0074] In one embodiment, the requested copy action may be from a single source LBA range to one or more destination LBA ranges, or from multiple source LBA ranges to one or more destination LBA ranges. One or more destination LBA ranges may reside in the same or different namespaces as the source LBA ranges, and / or have LBA sizes (e.g., logical block sizes) with the same or different formats. In some embodiments, the logical block may have end-to-end protection information (PI) specified for error detection.

[0075] Figure 5 This is a conceptual block diagram of the format of a logic block 500 according to one embodiment. The logic block may include a data portion 502 and an optional metadata portion 504. The data portion 502 may be one of different sizes (e.g., 512B, 1024B, 4096B, etc.). Logic blocks with different data sizes can be described as having different LBA formats.

[0076] Metadata portion 504 may be, for example, 16 bytes and may be used to convey metadata information 504a (including, for example, end-to-end protection information (PI) 504b). Controller 124 and / or host 102 may use the end-to-end protection information to determine the integrity of logical blocks. If present, the PI 504b portion may occupy the first eight bytes or the last eight bytes of the metadata portion 504, depending on the namespace format. The remaining portion of the metadata (which may be referred to as user data) may also be eight or more bytes. In some cases, the entire metadata portion 504 may contain only PI information 504b or metadata information 504a. In one embodiment, metadata portion 504 may be referred to as metadata, and PI 504b may be a component of the metadata.

[0077] Figures 6A to 6BThis is a flowchart, according to one embodiment, for processing replication commands (e.g., NVMe replication commands or vendor-unique replication commands) submitted by host 102 to external submission queue 112. Although NVMe replication commands or vendor-unique replication commands are used as examples, it should be understood that the flowchart can also be applied to other replication commands submitted using other protocols similar to NVMe. It should also be understood that the order of the processing steps is not fixed but can be changed to any desired order recognized by those skilled in the art. Furthermore, two or more steps in the processing may be performed sequentially or simultaneously with each other.

[0078] Processing begins in box 600, where one of the external controllers 124 retrieves the submitted copy command from the external submission queue 112 and passes the copy command to the device controller 122 for preprocessing by the processor 140.

[0079] In block 602, preprocessing actions taken by processor 140 may include initiating a host direct memory access operation via storage interface bus 106 to transfer source LBA ranges and destination LBA ranges from host memory 110 to internal memory 138 of the storage device. Furthermore, processor 140 may resolve LBA ranges to merge any contiguous ranges. One or more source LBA ranges and destination LBA ranges may reside in different namespaces and / or have different LBA formats. For example, when using NVMe vendor-unique replication commands, different NSIDs for different source and destination namespaces may be passed via the 64B itself. However, NVMe replication commands may not include different namespace information because they may not be supported by the NVMe protocol.

[0080] In one embodiment, processor 140 may generate read and write commands from a replication command. For example, processor 140 may break down a replication command into separate read and write commands that can be processed by internal controller 126 without the host's knowledge. In this regard, at block 604, processor 140 prepares internal read commands for non-contiguous source LBA ranges identified by processor 140 for submission to one or more in internal submission queue 130.

[0081] In box 606, processor 140 prepares one or more PRP / SGL entries 136 describing the internal source buffer 206 from which data will be read. Assuming SGL entries are used, a particular SGL entry may include an SGL data block descriptor. The SGL data block descriptor may include the address and length of the data block to be read.

[0082] At block 608, internal controller 126 retrieves and processes read commands from internal submission queue 130. Command module 200 of internal controller 126 can be invoked to retrieve and process read commands. In this regard, command module 200 can interact with processor 140 to perform read transfers from NVM media 144 to an intermediate read buffer, such as that hosted in internal memory 138 of storage device 104. In some embodiments, internal controller 126 can process read commands based on submitting them to internal submission queue 130 without processor 140 intervention, in order to help improve storage device performance. In such embodiments, the intermediate buffer can be allocated by device controller 122 without processor 140 intervention.

[0083] In addition to extracting read commands, the PRP / SGL extraction module 202 can also be invoked to extract the PRP / SGL entries 136 generated by the processor 140.

[0084] When processing a read command, the transfer queue module 208 can be invoked to obtain information about the intermediate read buffer storing the read data. Based on this information, the DMA manager module 210 transfers the data in the intermediate read buffer to the internal source buffer 206 described by PRP / SGL entry 136, and notifies the processor 140 when the transfer is complete.

[0085] In one embodiment, data in source buffer 206 is processed for replication to a destination LBA range provided by the host in a replication command (e.g., an NVMe replication command or a vendor-specific replication command). In this regard, DMA manager module 210 may transfer data from internal source buffer 206 to internal destination buffer 204 to prepare for an internal write command to perform replication. In some embodiments, processor 140 supplies the address of the internal source buffer 206 in which data is copied via an internal read command to serve as a buffer for processing the internal write command. This helps avoid the overhead associated with transferring data from internal source buffer 206 to internal destination buffer 204.

[0086] In box 609, it is determined whether all LBA ranges have been processed for generating read commands. If the answer is no, processor 140 returns to box 604 to prepare an internal read command for another non-contiguous source LBA range identified by processor 140. For example, assuming processor 140 identifies 100 non-contiguous LBA ranges to be read, processor 140 may generate 100 separate read commands, each of which includes a different source LBA range as part of the command.

[0087] Data read via an internal read command can then be written via an internal write command. In this regard, in block 610, processor 140 prepares internal write commands for submission to one or more internal submit queues 130. In one embodiment, the internal write command includes one of the destination LBA ranges in a replication command (e.g., an NVMe replication command or a vendor-unique replication command) submitted by the host.

[0088] In block 612, processor 140 prepares a PRP / SGL entry 136, which describes an internal destination buffer 204 (or an internal source buffer 206, if supplied by processor 140) containing data to be written to NVM medium 144. In embodiments using SGL entries, the SGL entry may include an SGL data block descriptor, which includes the address and length of the data block to be read. In some embodiments, the SGL entry may include an SGL bitbucket descriptor, which includes the length of data to be skipped when writing to an intermediate write buffer. In one embodiment, the SGL bitbucket descriptor is used to skip the PI portion of the written data if the PI format / type of the source namespace differs from the PI format / type of the destination namespace. Although the PI is used as an example of a skippable portion of data, the disclosure is not limited thereto, and other portions of data may be skipped for other types of commands.

[0089] In block 614, internal controller 126 retrieves and processes write commands from internal submission queue 130. Command module 200 of internal controller 126 can be invoked to retrieve and process write commands. In this regard, command module 200 can interact with processor 140 to perform write transfers from internal destination buffer 204 to intermediate write buffers, such as those hosted in internal memory 138 of storage device 104.

[0090] In addition to extracting write commands, the PRP / SGL extraction module 202 can also be invoked to extract the PRP / SGL entries 136 generated by the processor 140.

[0091] When processing a write command, the transfer queue module 208 can be invoked to obtain information about the intermediate write buffer to which the data will be transferred. Based on this information, the DMA manager module 210 transfers the data in the internal destination buffer 204 (or internal source buffer 206 (if supplied by processor 140)) described by PRP / SGL entry 136 to the intermediate write buffer and notifies processor 140 when the transfer is complete.

[0092] In one embodiment, individual read and / or write commands are submitted to one or more internal submission queues 130 for simultaneous processing. For example, via... Figure 6A After the first read command for the LBA range has been executed, it can be accessed via... Figure 6B The first write command for the LBA range is processed in the following steps without waiting for read commands for all LBA ranges to complete. Similarly, the second read command for the second LBA range can be processed concurrently with the processing of the first write command. Submitting an internal read command to the internal commit queue 130 may not be detected by the host 102.

[0093] In box 616, it is determined whether all LBA ranges have been copied. If the answer is yes, then in box 618, the external controller 124 submits the external completion entry to the external completion queue 114 corresponding to the external commit queue 112 to which the copy command was submitted.

[0094] Figure 7 This is a more detailed block diagram of the components of a storage device 104 for processing internal read and write commands associated with copy commands, according to one embodiment. The components may include a host DMA module 700, a flash DMA module 702, an internal CMB buffer 704, an intermediate read buffer 706, and an intermediate write buffer 708.

[0095] When executing an internal read command, processor 140 submits a read request to flash DMA module 702 to read a logical data block corresponding to the source LBA address of the copy command from NVM media 144. In one example, flash DMA module 702 may be part of media interface 142. The size of the data accessible by flash DMA module 702 may depend on the LBA format used by the namespace from which the data is read, and may also depend on the size of the available intermediate data buffer. Requests to flash DMA module 702 can be represented by intermediate buffer granularity, which may be 512B, 4KB, 8KB, or 16KB. For example, depending on the LBA format and the required copy data length, 512B, 4KB, 8KB, or 16KB of data may be accessed at once.

[0096] In one embodiment, data blocks acquired from NVM media 144 are placed in an intermediate read buffer 706. The intermediate read buffer 706 may be located, for example, in the internal memory 138 of storage device 104. In one embodiment, data in the intermediate read buffer 706 is accessed by a host DMA module 700 and placed in one of the internal CMB buffers 704. In this respect, the host DMA module 700 may be similar to the DMA manager module 210, and one of the internal CMB buffers 704 where the data is placed may be similar to the internal source buffer 206.

[0097] When executing an internal write command, the host DMA module 700 places data from one of the internal CMB buffers 704 (e.g., internal destination buffer 204) into an intermediate write buffer 708. The intermediate write buffer 708 may be located in, for example, the internal memory 138 of storage device 104. In one embodiment, data is written to the intermediate write buffer 708 according to the LBA format of the namespace associated with the destination LBA. The flash DMA module 702 can access the data in the intermediate write buffer 708 and write the data to the location on the NVM medium 144 corresponding to the destination LBA.

[0098] Figures 8A to 8C This is a conceptual layout diagram of various buffers invoked according to one embodiment to copy data from a source namespace to a destination namespace. Data in the source namespace (NS-A) 800 can be stored in multiple LBA ranges 802a to 802c (i.e., range A, range B, and range C, collectively referred to as 802). During the processing of the internal read command to execute the copy command's read portion, the flash DMA module 702 ( Figure 7 This allows for read transfers from the source LBA range 802 to intermediate read buffers (e.g., read data buffer 706a and read metadata buffer 706b). In this regard, see reference... Figure 5 The logical data block under discussion may have a data portion 502 and a metadata portion 504. In one embodiment, the flash DMA module 702 reads the data portion from each source LBA range 802 and stores the data portion in a read data buffer 706a. The flash DMA module 702 may also read the metadata portion of the data and store the metadata portion in a read metadata buffer 706b.

[0099] Upon completion of an internal read command, the host DMA module 700 may transfer data from the read data buffer 706a and metadata from the read metadata buffer 706b to the internal CMB buffer 704a. The transferred data may be stored in the data portion 808 of the internal CMB buffer 704a, and the transferred metadata may be stored in the metadata portion 810 of the internal CMB buffer 704a, but the embodiments are not limited thereto.

[0100] The read data can then be processed to be written to one or more destination LBA ranges. Figure 8B In the example, data is written to a single destination LBA range 812 within the destination namespace (NS-B) 804. Figure 8CIn the example, data is written to multiple destination LBA ranges 814, 816 (i.e., destination range A, destination range B) within the destination namespace (NS-C) 806. In both cases, the host DMA module 700 can transfer data from its internal CMB buffer 704a to intermediate write buffers (e.g., write data buffer 708a and write metadata buffer 708b). For example, the host DMA module 700 can transfer data portion 808 to write data buffer 708a and metadata portion 810 to write metadata buffer 708b. Figure 8B In the example, the flash DMA module 702 can then transfer the data written to buffers 708a, 708b along with the corresponding metadata to a single destination LBA range 812 in the destination namespace 804. Figure 8C In the example, the flash DMA module 702 can transfer data written to buffers 708a and 708b along with corresponding metadata to multiple destination LBA ranges 814 and 816. For example, data written to data buffer 708a can be transferred to target LBA ranges 814 and 816, and metadata written to metadata buffer 708b can be transferred to target LBA ranges 814 and 816.

[0101] Figures 9A to 9B This is a conceptual layout diagram of various buffers invoked to copy data from multiple LBA ranges in the source namespace 900 to a single LBA range in the destination namespace (NS-B) 902, where both the source and destination namespaces have the same LBA format. For example, the logical block data size in both the source and destination namespaces could be 512B, where each logical block has metadata including 8B PI. Figures 9A to 9B It can also describe a buffer that can be used to copy data from multiple LBA ranges of source namespace 900 to multiple destination LBA ranges, wherein both source namespace 900 and destination namespace 902 are formatted using the same LBA size.

[0102] exist Figures 9A to 9BIn the example, four source LBA ranges 904a to 904d (e.g., LBAs 0 to 7, LBAs 10 to 13, LBAs 20 to 23, and LBAs 28 to 43) are copied to a single destination LBA range 906 (e.g., LBAs 0 to 31). In this regard, data in the four source LBA ranges 904a to 904d can be read and stored (e.g., 512B, 4KB, 8KB, and 16KB at a time) into an intermediate read data buffer 706c and transferred to an internal CMB buffer 704b. PI data corresponding to each logical data block read can also be read and stored (e.g., 8B at a time) into an intermediate read metadata buffer 706d and transferred to an internal CMB buffer 704b.

[0103] During a write operation, data in the internal CMB buffer 704b can be transferred to the intermediate write data buffer 708c. Metadata stored in the internal CMB buffer 704b can also be copied to the intermediate write metadata buffer 708d. In one embodiment, because... Figures 9A to 9B In the example, the source LBA format and the destination LBA format are the same, so the PI portion of the metadata is not copied to the intermediate write metadata buffer 708d. The data and metadata in the intermediate write data buffer 708c and the intermediate write metadata buffer 708d can be transferred to the destination LBA range 906 to complete the copy operation. In one embodiment, the PI portion of the uncopied metadata can be regenerated (e.g., via the host DMA module 700) and stored in the destination LBA range 906.

[0104] Figures 10A to 10B This is a conceptual layout diagram of various buffers invoked to copy data from multiple LBA ranges in a source namespace (NS-A) 1000 to multiple LBA ranges in a destination namespace (NS-B) 1002, where the source and destination namespaces have different LBA formats. For example, the logical block data size in source namespace 1000 could be 512B, while the logical block data size in destination namespace 1002 could be 4096B. Figures 10A to 10B In the example, four source LBA ranges 1004a to 1004d (e.g., LBA 0 to 7, LBA 10 to 13, LBA 20 to 23, and LBA 28 to 43) are replicated to two destination LBA ranges 1006a and 1006b (e.g., LBA 0 to 1 and LBA 4 to 5). Figures 10A to 10B It can also be described a buffer that can be used to copy data from multiple LBA ranges of source namespace 1000 to a single LBA range of destination namespace 1002, wherein source namespace 1000 and destination namespace 1002 are formatted using different LBA sizes.

[0105] During a read operation, data in each LBA range 1004a to 1004d of the source namespace 1000 is copied to the intermediate read data buffer 706e, and the corresponding metadata is copied to the intermediate read metadata buffer 706f. The contents of the intermediate read data buffer 706e and the intermediate read metadata buffer 706f are then transferred to the internal CMB buffer 704c.

[0106] During a write operation, data in the internal CMB buffer 704c can be transferred to the intermediate write data buffer 708e according to the LBA format of the destination namespace 1002. For example, 4096B of data from the internal CMB buffer 704c can be stored in the intermediate write data buffer 708e at once. Metadata in the internal CMB buffer 704c can also be copied to the intermediate write metadata buffer 708f. Then, the data and metadata in the intermediate write data buffer 708e and the intermediate write metadata buffer 708f can be transferred to the destination LBA ranges 1006a and 1006b. In one embodiment, because Figures 10A to 10B In the example, the source namespace and destination namespace have different LBA formats, so any PI portion of the metadata can be regenerated by the host DMA module 700 according to the PI format used by the destination namespace.

[0107] Figures 11A to 11B This is a conceptual layout diagram of buffers and SGL tables used to copy data from a source LBA range in one namespace to a destination LBA range in another namespace, where the source LBA range and the destination LBA range are... Figures 10A to 10B The source LBA range and destination LBA range are specified in the table. It should be understood that similar SGL tables can be used... Figures 9A to 9B The buffer in the embodiment has the same LBA format for the source namespace and the destination namespace.

[0108] exist Figures 11A to 11B In the example, SGL bit bucket descriptor 1110 is used as described below to skip the PI information of the read data, thereby allowing the read data and associated metadata (including the appropriate PI information) to be assembled in a different LBA format in the destination namespace. Skipping the PI information can be done as part of a read operation while writing to the internal CMB buffer, or as part of a write operation while reading from the internal CMB buffer. The PI can then be regenerated by the host DMA module according to the destination LBA format.

[0109] exist Figures 11A to 11BIn the example, eight logical data blocks (each 512B) in the source namespace are formed into a single destination logical block of size 4096B. During the write portion of the processing, the PI information associated with each 512B data block (e.g., 8B PI information) is skipped using a bit bucket descriptor, and a single data block of size 4096B (with regenerated PI information (e.g., regenerated 8B PI information)) can be formed in the destination namespace.

[0110] More specifically, during an internal read operation, data (e.g., 4KB of data) is retrieved from NVM medium 144 and stored in intermediate read data buffer 706g (and...). Figures 10A to 10B The data (similar to the processing in the previous step) can be transferred to the internal CMB buffer 704d. Metadata stored in the intermediate read metadata buffer 706h can also be transferred to the internal CMB buffer 704d. The internal CMB buffer 704d to which data and metadata are transferred can be described by one or more PRP / SGL entries (e.g., read SGL list) 136a. In one embodiment, the PRP / SGL entry 136a is generated by the processor 140 based on the fetching and processing of internal read commands. It should be understood that, although... Figures 8A to 10B The examples do not explicitly depict PRP / SGL entries, but PRP / SGL entries can also be used in those examples to describe internal CMB buffers 704a to 704c.

[0111] exist Figures 11A to 11B In the example, the metadata in the intermediate read metadata buffer 706h may include a metadata portion 1100 and a PI portion 1102 for each logical data block 1104 (e.g., 512B of data) in the intermediate read data buffer 706g. During the write portion of the copy command, the logical data block 1104 and the corresponding metadata portion 1100 transferred to the internal CMB buffer 704d may be written from the internal CMB buffer 704d to the intermediate write data buffer 708g and the intermediate write metadata buffer 708h, respectively. In one embodiment, the data written to the intermediate write data buffer 708g conforms to the LBA format of the destination namespace. For example, the size of each logical data block in the intermediate write data buffer 708g may be 4096B.

[0112] Figures 11A to 11BIn the example, the source namespace and destination namespace have different LBA formats. Therefore, according to one embodiment, the PI portion 1102 for reading metadata is skipped and not copied from the internal CMB 704d to the write metadata buffer 708h. In one embodiment, the skipped PI portion of the metadata is generated as PI 1106 by the host DMA module 700. The generated PI 1106 may be based on the PI format used by the destination namespace.

[0113] In one embodiment, information provided by PRP / SGL entries (e.g., write SGL lists) 136b used to write data to intermediate write data buffer 708g and intermediate write metadata buffer 708h allows skipping the PI portion 1102 of the metadata read in the internal CMB 704d. In one embodiment, the PRP / SGL entry 136b is generated by the processor 140 based on fetching and processing internal write commands. In one embodiment, the processor 140 may determine that the PI portion of the metadata to be written will be skipped. Such determination may be based on determining that the metadata read from the source namespace has an enabled PI portion, and also on determining that the LBA format of the destination namespace is different from the LBA format of the source namespace.

[0114] In one embodiment, an SGL entry may include an SGL data descriptor 1108 for the data to be copied (including a descriptor for the data block to be copied (e.g., 512B) and associated metadata (e.g., 8B of user data excluding the PI portion)). In one embodiment, an SGL bit bucket descriptor 1110 following the SGL data descriptor 1108 may be used to avoid copying the PI portion of metadata in the internal CMB 704d. For example, the SGL bit bucket descriptor 1110 may identify 8B of PI data that will be skipped.

[0115] In one embodiment, the host DMA module 700 uses PRP / SGL entry 136b to transfer data from the internal CMB buffer 704d to the intermediate write data buffer 708g and the intermediate write metadata buffer 708h. In this respect, the host DMA module 700 can transfer data from the CMB buffer described in SGL data descriptor 1108 to the intermediate write data buffer 708g and the intermediate write metadata buffer 708h, skipping a portion of the data described in SGL bit bucket descriptor 1110. The host DMA module 700 can continue in a similar manner, transferring data described in the remaining SGL data descriptor 1112, and skipping data described in the remaining SGL bit bucket descriptor 1114. The skipped metadata PI portion can then be regenerated by the host DMA module 700 according to the destination namespace LBA format and stored in the intermediate write metadata buffer 708h. In one embodiment, the regenerated PI is 8B in size and associated with 4096B of data in the destination namespace. In one embodiment, the 8B PI information 1106 can form user data (user data in... Figure 11B The example is 56B in size, and the remaining 8B is copied from the source namespace.

[0116] In some embodiments, instead of including the SGL bit bucket descriptor in PRP / SGL entry 136b for transferring data from the internal CMB buffer 704d to the intermediate write data buffer 708g and intermediate write metadata buffer 708h during write processing, the SGL bit bucket descriptor can be included in PRP / SGL entry 136a for read processing. According to this embodiment, a portion of the data described in the SGL bit bucket descriptor in the PRP / SGL entry is skipped and not transferred from the intermediate read metadata buffer 706h to the internal CMB buffer 704d.

[0117] It should be understood that embodiments of this disclosure allow copy commands to be processed across different namespaces even when the LBA formats differ between namespaces, and / or even when different namespaces use different end-to-end protection information. Using SGL bit bucket descriptors to skip end-to-end protection information for reading data allows data and associated metadata (including protection information) to be assembled in different LBA formats in the destination namespace. The host DMA module can then regenerate the PI according to the destination LBA format.

[0118] It should be understood that one or more processors discussed above may include, for example, application-specific integrated circuits (ASICs), general-purpose or special-purpose central processing units (CPUs), digital signal processors (DSPs), graphics processing units (GPUs), and / or programmable logic devices (such as field-programmable gate arrays (FPGAs)). Within a processor, as used herein, each function may be performed by hardware, firmware, and / or software. The processor may be manufactured on a single printed circuit board (PCB) or distributed across several interconnected PCBs. The processor may include other processing circuitry (e.g., the processing circuitry may include two processing circuits (FPGA and CPU) interconnected on the PCBs).

[0119] It will be understood that although the terms “first,” “second,” “third,” etc., may be used herein to describe various elements, components, regions, layers, and / or portions, these elements, components, regions, layers, and / or portions should not be limited by these terms. These terms are used only to distinguish one element, component, region, layer, or portion from another. Therefore, without departing from the spirit and scope of the inventive concept, the first element, first component, first region, first layer, or first portion discussed herein may be referred to as a second element, second component, second region, second layer, or second portion.

[0120] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the inventive concept. As used herein, the terms “substantially,” “about,” and similar terms are used as approximate terms rather than terms of degree and are intended to take into account the inherent biases of measurements or calculations that will be recognized by those skilled in the art.

[0121] As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. It will also be understood that, when used herein, the term “comprising” indicates the presence of the stated features, integrals, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items. Expressions such as “at least one of…” modify the entire list of elements when following a list of elements, rather than modifying a single element in the list. Furthermore, the word “may” as used in describing embodiments of the inventive concept means “one or more embodiments of this disclosure.” Additionally, the term “exemplary” is intended to indicate an example or illustration. As used herein, the term “use” may be considered synonymous with the term “utilize.”

[0122] It will be understood that when a component or layer is referred to as being "on" another component or layer, "connected to", "bonded to", or "adjacent to" another component or layer, it may be directly on, directly connected to, bonded to, or immediately adjacent to the other component or layer, or one or more intermediate components or layers may exist. Conversely, when a component or layer is referred to as being "directly on" another component or layer, "directly connected to", "directly bonded to", or "immediately adjacent to" another component or layer, no intermediate components or layers exist.

[0123] Any numerical range described herein is intended to include all subranges of the same numerical precision contained within the described range. For example, the range “1.0 to 10.0” is intended to include all subranges between the described minimum value 1.0 and the described maximum value 10.0 (and includes both the described minimum value 1.0 and the described maximum value 10.0) (i.e., a minimum value equal to or greater than 1.0 and a maximum value equal to or less than 10.0 (e.g., 2.4 to 7.6, for example)). Any maximum numerical limit described herein is intended to include all lower numerical limits contained therein, and any minimum numerical limit described in this specification is intended to include all higher numerical limits contained therein.

[0124] Although exemplary embodiments of systems and methods for processing copy commands have been specifically described and illustrated herein, many modifications and variations will be apparent to those skilled in the art. Therefore, it should be understood that systems and methods for processing copy commands constructed in accordance with the principles of this disclosure may be implemented in ways different from those specifically described herein. The disclosure is also defined in the appended claims and their equivalents.

Claims

1. A method for processing a copy command from a host to a storage device, the method comprising: receiving, by a first controller of the storage device, the copy command from the host via a first queue, wherein the copy command includes a first source address and a first destination address; generating, by the storage device, a first read command and a first write command based on the copy command; submitting, by the storage device, the first read command and the first write command generated based on the copy command to a second controller of the storage device via a second queue; fetching and processing, by the second controller, the first read command and the first write command from the second queue; reading, by the storage device, data stored in a first location of a storage medium of the storage device associated with the first source address based on the processing of the first read command; writing, by the storage device, data to a second location of the storage medium associated with the first destination address based on the processing of the first write command; and sending, by the first controller, a signal to the host indicating completion of the copy command.

2. The method of claim 1, wherein, the first source address is associated with a first logical space of the storage device identified by a first identifier, and the first destination address is associated with a second logical space of the storage device identified by a second identifier.

3. The method of claim 1, wherein, the copy command includes a second destination address, wherein the step of writing the data comprises writing a first portion of the data to the second location of the storage medium associated with the first destination address and writing a second portion of the data to a third location of the storage medium associated with the second destination address.

4. The method of claim 1, wherein, the data stored in the first location of the storage medium includes metadata having the first portion and the second portion, wherein the step of writing the data comprises: writing the first portion of the metadata to a third location of the storage medium associated with the first destination address; generating, by the storage device, a third portion of the metadata based on the first destination address; and writing, by the storage device, the third portion of the metadata instead of the second portion of the metadata to the storage medium.

5. The method of claim 4, further comprising: skipping, based on the processing of the first read command, reading of the second portion of the metadata.

6. The method of claim 4, further comprising: skipping, based on the processing of the first write command, writing of the second portion of the metadata.

7. The method of claim 4, wherein, the second portion of the metadata includes data protection information.

8. The method of claim 4, wherein, the first source address is associated with a first logical space configured to store data blocks of a first size, and the first destination address is associated with a second logical space configured to store data blocks of a second size different from the first size.

9. The method of claim 1, wherein, the copy command is associated with a second source address, the method further comprising: generating, by the storage device, a second read command based on the copy command; submitting, by the storage device, the second read command to the second controller of the storage device via the second queue; fetching and processing, by the second controller, the second read command from the second queue; and reading, by the storage device, data stored in a third location of the storage device associated with the second source address based on the processing of the second read command, wherein the processing of the second read command by the second controller occurs concurrently with the processing of the first write command.

10. The method of claim 1, wherein, The storage device is a non-volatile storage device, and the first controller and the second controller comply with a NVM Express protocol.

11. The method of claim 1, further comprising: submitting, by the second controller, the first completion status to the first completion queue.

12. The method of claim 11, wherein, The step of sending a signal includes submitting a second completion status to a second completion queue based on submitting the first completion status to the first completion queue.

13. A storage device, comprising: a storage medium; one or more processors connected to the storage medium, the one or more processors respectively configured to: receive, from a host via a first controller and a first queue, a copy command, wherein the copy command includes a first source address and a first destination address; generate a first read command and a first write command based on the copy command; submit, via a second queue, the first read command and the first write command generated based on the copy command to a second controller; fetch and process, via the second controller, the first read command and the first write command from the second queue; read, based on the processing of the first read command, data stored in a first location of the storage medium associated with the first source address; write, based on the processing of the first write command, data to a second location of the storage medium associated with the first destination address; and send, via the first controller, a signal to the host indicating completion of the copy command.

14. The memory device of claim 13, wherein, The first source address is associated with a first logical space of the storage device identified by a first identifier, and the first destination address is associated with a second logical space of the storage device identified by a second identifier.

15. The memory device of claim 13, wherein, The copy command includes a second destination address, wherein, when writing the data, the one or more processors are configured to write a first portion of the data to the second location of the storage medium associated with the first destination address, and write a second portion of the data to a third location of the storage medium associated with the second destination address.

16. The memory device of claim 13, wherein, The data stored in the first location of the storage medium includes metadata having the first portion and the second portion, wherein, when writing the data, the one or more processors are further configured to: write the first portion of the metadata to a third location of the storage medium associated with the first destination address; generate a third portion of the metadata based on the first destination address; and write the third portion of the metadata instead of the second portion of the metadata to the storage medium.

17. The memory device of claim 16, wherein, The one or more processors are further configured to: skip, based on the processing of the first read command, reading the second portion of the metadata.

18. The memory device of claim 16, wherein, The one or more processors are further configured to: skip, based on the processing of the first write command, writing the second portion of the metadata.

19. The memory device of claim 16, wherein, The second portion of the metadata includes data protection information.

20. The storage device of claim 16, wherein, The first source address is associated with a first logical space configured to store data blocks of a first size, and the first destination address is associated with a second logical space configured to store data blocks of a second size different from the first size. The first source address is associated with a first logical space configured to store data blocks of a first size, and the first destination address is associated with a second logical space configured to store data blocks of a second size different from the first size.

Images