Copy command processing method and storage device

Abstract

To provide a technique for simultaneously processing by separating a copy command into a read command and a write command.SOLUTION: A method includes: receiving a copy command including a first source address and a first destination address from a host through a first queue by a first controller of a storage device; generating a first read command and a first write command on the basis of the copy command; submitting the first read command and the first write command to a second controller through a second queue; acquiring and processing the first read command and the first write command from the second queue by the second controller; reading data stored in a first position of a storage medium related to the first source address on the basis of the processing of the first read command; writing the data in a second position of the storage medium related to the first destination address on the basis of the processing of the first write command; and transmitting a signal for informing completion of the copy command to the host by the first controller.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to a storage device, and more particularly to a method for processing a copy command used to access a storage device, and the storage device. [Background technology]

[0002] A host computing device uses a storage interface protocol to access a non-volatile storage device, such as a solid-state drive (SSD). The non-volatile storage device includes a controller that processes commands generated using the protocol. As protocols grow, more features (e.g., commands) are added to the protocol. A conventional SSD may not be able to process the added features without redesigning the SSD controller. Therefore, it is desirable to have an SSD controller that can process commands from the host without redesigning the SSD controller, even when commands are added to the protocol. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] International Publication No. 2015 / 170702 Summary of the Invention [Problem to be solved by the invention]

[0004] The present invention has been made in consideration of the above-mentioned problems of the conventional technology, and an object of the present invention is to provide a copy command processing method and storage device that separates a copy command into a read command and a write command and processes them simultaneously. [Means for solving the problem]

[0005] In order to achieve the above-mentioned object, according to one aspect of the present invention, a method for processing a copy command from a host to a storage device includes the steps of: receiving, by a first controller of the storage device, a copy command including a first source address and a first destination address from a host via a first queue; 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 to a second controller of the storage device via a second queue; retrieving 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 at 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, the 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 indicating completion of the copy command to the host.

[0006] The first source address may be associated with a first logical space of the storage device identified by a first identifier, and the first destination address may be associated with a second logical space of the storage device identified by a second identifier. The copy command may include a second destination address, and writing the data may include writing a first portion of the data to a second location on the storage medium associated with the first destination address, and writing a second portion of the data to a third location on the storage medium associated with the second destination address. The data stored at the first location on the storage medium may include metadata having a first portion and a second portion, and writing the data may include writing the first portion of the metadata to a third location on the storage medium associated with the first destination address; generating, by the storage device, the third portion of the metadata based on the first destination address; and writing, by the storage device, the third portion of the metadata to the storage medium in place of the second portion of the metadata. The method may further include skipping reading a second portion of the metadata based on processing of the first read command. The method may further include omitting writing of a second portion of the metadata based on processing of the first write command. A second portion of the metadata may include data protection information. The first source address may be associated with a first logical space configured to store data blocks of a first size, and the first destination address may be associated with a second logical space configured to store data blocks of a second size different from the first size. The copy command is associated with a second source address, and the method further includes: generating, by the storage device, a second read command based on the copy command; submitting, by the storage device, the second read command to a second controller of the storage device via the second queue; retrieving, by the second controller, the second read command from the second queue and processing it; 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 can be performed simultaneously with the processing of the first write command. The storage device may be a non-volatile storage device, and the first controller and the second controller may conform to a Non-Volatile Memory Express (NVMe) protocol. The method may further include submitting, by the second controller, a first completion status to a first completion queue. Sending the signal may include submitting a second completion status to a second completion queue based on submitting the first completion status to a first completion queue.

[0007] In order to achieve the above-mentioned object, one aspect of the present invention provides a storage device comprising a storage medium and one or more processors coupled to the storage medium, wherein the one or more processors are configured to receive a copy command including a first source address and a first destination address from a host via a first controller and a first queue, 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 of the storage device 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 at 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, write the 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 send a signal indicating completion of the copy command to the host via the first controller.

[0008] The present invention enables conventional storage devices to process commands and / or extensions, such as copy commands between two addresses in the same namespace with the same logical block address (LBA) format and / or between addresses in two namespaces with different LBA formats / sizes with multiple destination ranges. By separating the copy command into internal read and write commands that can be processed simultaneously, storage device performance is improved and processing overhead is reduced.

[0009] The features, aspects, and advantages of the embodiments of the present invention will be more fully understood when considered in conjunction with the detailed description, claims, and drawings. [Effects of the Invention]

[0010] According to the copy command processing method and storage device of the present invention, the performance of the storage device can be improved by separating the copy command into a read command and a write command and processing them simultaneously. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a block diagram of a data storage and retrieval system according to one embodiment. [Figure 2] FIG. 2 is a conceptual layout diagram of various modules for submitting and processing storage interface commands according to one embodiment. [Figure 3] FIG. 1 is a layout block diagram of internal commands stored as submission queue entries (SQEs) in an internal submission queue according to one embodiment. [Figure 4] 1 is a flowchart for processing a dataset management (DSM) command to deallocate (undap) a given set of logical block address ranges from a given namespace according to one embodiment. [Figure 5] FIG. 2 is a conceptual block diagram of a logical block format according to one embodiment. [Figure 6A]10 is a flowchart for processing a copy command submitted by a host to an external submission queue according to one embodiment. [Figure 6B] 10 is a flowchart for processing a copy command submitted by a host to an external submission queue according to one embodiment. [Figure 7] FIG. 2 is a more detailed block diagram of components of a storage device for processing internal read and write commands associated with a copy command according to one embodiment. [Figure 8A] FIG. 2 is a conceptual layout diagram of various buffers involved in copying data from a source namespace to a destination namespace according to one embodiment. [Figure 8B] FIG. 2 is a conceptual layout diagram of various buffers involved in copying data from a source namespace to a destination namespace according to one embodiment. [Figure 8C] FIG. 2 is a conceptual layout diagram of various buffers involved in copying data from a source namespace to a destination namespace according to one embodiment. [Figure 9A] FIG. 1 is a conceptual layout diagram of various buffers involved in copying data from multiple LBA ranges in a source namespace to a single LBA range in a destination namespace according to one embodiment, where both the source and destination namespaces have the same LBA format. [Figure 9B] FIG. 1 is a conceptual layout diagram of various buffers involved in copying data from multiple LBA ranges in a source namespace to a single LBA range in a destination namespace according to one embodiment, where both the source and destination namespaces have the same LBA format. [Figure 10A] FIG. 1 is a conceptual layout diagram of various buffers involved in copying data from multiple LBA ranges in a source namespace to multiple LBA ranges in a destination namespace according to one embodiment, where the source and destination namespaces have different LBA formats. [Figure 10B]FIG. 1 is a conceptual layout diagram of various buffers involved in copying data from multiple LBA ranges in a source namespace to multiple LBA ranges in a destination namespace according to one embodiment, where the source and destination namespaces have different LBA formats. [Figure 11A] FIG. 10C is a conceptual layout diagram of buffers and SGL tables used to copy data in one source LBA range in one namespace to a destination LBA range in another namespace in accordance with one embodiment, where the source and destination LBA ranges have a format similar to that of the source and destination LBA ranges of FIGS. 10A and 10B. [Figure 11B] FIG. 10C is a conceptual layout diagram of buffers and SGL tables used to copy data in one source LBA range in one namespace to a destination LBA range in another namespace in accordance with one embodiment, where the source and destination LBA ranges have a format similar to that of the source and destination LBA ranges of FIGS. 10A and 10B. DETAILED DESCRIPTION OF THE INVENTION

[0012] Specific examples of embodiments of the present invention will be described in more detail below with reference to the drawings, where the same reference numerals refer to the same components. The present invention can be implemented in a variety of different forms and should not be construed as being limited to the embodiments described herein. These embodiments are provided as examples so that the aspects and features of the present invention can be fully conveyed to those skilled in the art. Therefore, processes, components, and techniques that are not required for those skilled in the art to fully understand the aspects and features of the present invention will not be described. Unless otherwise specified, similar reference numerals refer to similar components throughout the drawings and description, and their descriptions will not be repeated. Furthermore, in the drawings, the relative sizes of components, layers, and regions may be exaggerated and / or simplified for clarity.

[0013] A host computing device uses a communications protocol to access a non-volatile storage device, such as an SSD. The non-volatile storage device includes a controller for processing commands generated using the protocol. As protocols grow, more features (e.g., commands) are added to the protocol. A conventional SSD may not be able to process the additional 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 having to redesign the SSD controller.

[0014] Generally, embodiments of the present invention relate to a storage device configured to process commands from a host that conforms to a communication protocol, such as the NVMe protocol, although embodiments of the present invention are not limited thereto and may be extended to other protocols as would be understood by one skilled in the art.

[0015] In one embodiment, a command from a host is parsed into one or more internal commands that are executed by the storage device. The storage device includes an internal controller configured to fetch and execute the one or more internal commands. In one embodiment, no communication path is established between the host and the internal controller. Thus, the internal controller is not exposed to the host.

[0016] In one embodiment, the host submits host commands to an external submission queue associated with the storage device that is exposed to the host using an interface, such as an NVMe interface. An external controller of the storage device fetches / obtains the host commands and communicates the fetched commands to a processor of the storage device to generate internal commands. The internal commands are submitted to one or more internal submission queues. In one embodiment, the internal submission queues and internal controller are not exposed to the host (e.g., hidden).

[0017] The internal controller fetches / retrieves internal commands and dispatches them to be executed by the processor as standard commands conforming to a communication protocol (e.g., the NVMe protocol) or as vendor-specific commands, as if the commands originated from a host. In one embodiment, the internal commands are fetched / retrieved and executed by the storage device simultaneously (e.g., in parallel) with one another. The terms simultaneously and in parallel mean substantially simultaneously, at a speed faster than sequential processing, etc.

[0018] FIG. 1 is a block diagram of a data storage and retrieval system 100 according to one embodiment. The system includes one or more hosts (102a, 102b) (collectively 102) configured with the same or different operating systems. The one or more hosts 102 are connected to a data storage device 104 via storage interface buses (106a, 106b) (collectively 106). The storage interface bus 106 may be, for example, a Peripheral Component Interconnect Express (PCIe) bus. In one embodiment, the host 102 transfers data to and receives data from the data storage device 104 via the storage interface bus 106 using a storage interface protocol. The storage interface protocol is the NVMe protocol described in the NVM Express Base Specification Revision 1.4a (dated March 9, 2020, or any earlier or future revision), available at http: / / NVMexpress.org, the contents of which are incorporated herein by reference. The NVMe protocol is used as an example to describe this embodiment. However, those skilled in the art should understand that the various embodiments extend to other current or future storage interface protocols similar to the NVMe protocol without departing from the spirit or scope of the present invention.

[0019] Host 102 is a computing device having processors (108a, 108b) (collectively 108) configured to process data. 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 device configured with software commands, microcode, and / or firmware.

[0020] In this embodiment, processor 108 is coupled to host memory space (110a, 110b) (collectively 110). Host memory space 110 may be static random access memory (SRAM), dynamic random access memory (DRAM), or the like. Application programs are stored in host memory space 110 for execution by processor 108. The application programs request storage or retrieval of data from storage device 104. The application programs generate output based on the storage or retrieval of data. The output is displayed, for example, as retrieved data on a display device. In one embodiment, using internal commands by storage device 104 to process requests from applications allows the requests to be processed faster and with less overhead.

[0021] The host memory space 110 also stores one or more external submission queues (SQs) (112a, 112b) (collectively 112) and one or more external completion queues (CQs) (114a, 114b) (collectively 114). The host 102 uses the external submission queues 112 to submit storage interface commands for execution by the storage device 104 and uses the external completion queues 114 to receive completion messages from the storage device 104 after executing the commands. In some embodiments, the external submission and completion queues (112, 114) are included in a controller memory buffer (CMB) of the storage device 104 instead of (or in addition to) the host memory space 110. Thus, a reference to the host memory space 110 is understood to include a reference to the CMB. In either scenario, the external submission and completion queues (112, 114) are exposed to and accessible by the host.

[0022] In this embodiment, host memory space 110 stores Physical Region Page (PRP) / Scatter Gather List (SGL) entries (116a, 116b) (collectively referred to as 116) and other data (117a, 117b) (collectively referred to as 117). For example, PRP / SGL entries 116 describe physical memory locations in host memory space 110 to record data read from storage device 104 for NVMe read commands and to read data to be recorded to storage device 104 for NVMe write commands. For certain storage interface commands, LBA ranges are stored as data 117 in host memory space instead of including the range in the command itself. An example of such a command is the Data Set Management Deallocate command, which is used to deallocate / undemap a host-provided LBA range.

[0023] Storage device 104 is a non-volatile storage device such as an SSD. Storage device 104 includes a communication interface 118, an NVMe subsystem 120, and a device controller 122. While NVMe subsystem 120 and device controller 122 are shown as separate modules, it should be understood that the functionality of NVMe subsystem 120 and device controller 122 may be incorporated into a single module. In one embodiment, communication interface 118 includes PCIe ports and endpoints that enable ingress of communications from host 102 to storage device 104 and egress of communications from storage device 104 to host 102.

[0024] The NVMe subsystem 120 includes, without limitation, one or more external controllers (124a, 124b) (collectively 124) and one or more internal controllers 126. The external and internal controllers (124, 126) are implemented by one or more processors, such as ASICs. 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 queue operations for the external submission and completion queues (112, 114). For example, a particular external controller 124 fetches storage interface commands for a particular external submission queue 112 and places 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 completed).

[0025] In one embodiment, a particular external controller 124 is associated with one or more namespaces. The logical space of the storage device 104 is then divided into one or more logical spaces / namespaces, each identified by a unique namespace ID (NSID). For example, assume a 1 TB storage device using 4K logical blocks, and three namespaces are assigned to it, with capacities of 512 GB, 256 GB, and 256 GB. Commands submitted by the host 102 are directed to a particular namespace, identified via an NSID.

[0026] In one embodiment, one or more internal controllers 126 are not exposed (e.g., hidden) to the host 102 and are not accessible by the host 102, such that no communication interface (e.g., a PCIe interface) is provided between the host 102 and the internal controllers 126. The internal controllers 126, according to one embodiment, mimic the functionality of the external controller 124, such that the internal controllers 126 interact with the device controller 122 as if they were the external controllers 124.

[0027] In one embodiment, storage device 104 includes an internal CMB 128 that stores one or more internal submission queues (SQs) 130 and one or more internal completion queues (CQs) 132. CMB 128 stores 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 fetch and process internal commands submitted by device controller 122. The contents of internal CMB 128 and the processing of internal commands are not exposed (e.g., hidden) and are not accessible to host 102.

[0028] In one embodiment, the device controller 122 interacts with the external and internal controllers (124, 126) to execute commands requested by the host 102. The device controller 122 includes, without limitation, one or more processors 140 and a media interface 142. The one or more processors 140 are configured to process commands between the external and internal controllers (124, 126) and to execute computer-readable commands for managing the operation of the storage device 104. The computer-readable commands executed by the one or more processors 140 may be, for example, firmware code.

[0029] As an example, one or more processors 140 are configured to interact with the external and internal controllers (124, 126) to receive write or read commands from a storage medium (e.g., NVM media 144). The one or more processors 140 interact with the NVM media 144 over 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.

[0030] In one embodiment, storage device 104 further includes internal memory 138 for short-term storage or temporary memory during operation of storage device 104. Internal memory 138 includes DRAM, SRAM, and / or Data Tightly Coupled Memory (DTCM). Internal memory 138 is used instead of or in addition to internal CMB 128 to store some or all of the data stored in internal CMB 128, such as internal submission queue 130, completion queue 132, data 134, PRP / SGL entries 136, etc. Accordingly, references to internal CMB 128 are understood to include references to internal memory 138.

[0031] 2 is a conceptual layout diagram of various modules for submitting and processing commands for a storage interface protocol or vendor-defined commands, according to one embodiment. The various modules are hosted by external and / or internal controllers (124, 126). Also, while one or more modules are assumed to be separate functional units, those skilled in the art will recognize that the functionality of the modules may be combined or incorporated into a single module or further subdivided into additional sub-modules without departing from the spirit and scope of the present invention.

[0032] In one embodiment, instances of the command module 200 and the PRP / SGL fetch module 202 are included in both the external and internal controllers (124, 126). The command module 200 includes, for example, a command arbitration submodule, a command fetch submodule, a command parser submodule, and a command dispatcher submodule. The command fetch submodule is configured to fetch host commands from the external submission queue 112 or fetch internal commands from the internal submission queue 130. The command arbitration submodule is configured to invoke an arbitration burst policy to arbitrate between the various controllers and between the various submission queues of the selected controller to select a submission queue from which to fetch the command. The command parser submodule is configured to parse commands submitted to the external or internal controller (124, 126) to check and verify the type of command based on the namespace format, NSID validity, reservation status, whether an LBA check is required, validity of protection information, etc. The command parser sub-module may also be configured, based on programmed configuration information, to interface with an LBA overlap checker (not shown) to deliver commands if an LBA overlap check is required for the command. The command parser sub-module may also determine whether to bypass the host subsystem and send the command directly to the 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 in the same range as the newly arrived command. If the answer is yes, the LBA overlap checker puts the newly arrived command on hold until the previously fetched command and the currently being processed command are completed. The command dispatcher sub-module is responsible for distributing commands to various processors according to the command type (e.g., performance, non-performance, or management).

[0033] The PRP / SGL fetch module 202 is configured to fetch the PRP or SGL entry 116 from host memory (in the case of an external controller 124) or to fetch the PRP or SGL entry 136 from the internal CMB 128 (in the case of an internal controller 126). In one embodiment, both the command module 200 and the PRP / SGL fetch module 202 conform to a storage interface protocol when fetching commands and PRP / SGL entries, respectively.

[0034] In one embodiment, a host 102 submits a storage interface command to one of the external submission queues 112. A command module 200 (e.g., a command fetch sub-module) in one of the external controllers 124 fetches / gets the command from the external submission queue 112 and communicates the command to a device controller 122 for further processing. Depending on the type of command submitted by the host, the device controller 122 accesses the host memory 110 to read data 117 needed to process the fetched command, such as an LBA range. In one embodiment, if the command submitted by the host 102 is a data transfer command, a PRP / SGL fetch module 202 associated with the external controller 124 fetches a PRP / SGL entry 116 from the host memory 110 or the CMB for reading or writing data associated with the data transfer command.

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

[0036] The device controller 122 submits one or more internal commands to the internal submission queue 130, similar to how the host 102 submits an NVMe command to the external submission queue 112. For example, the device controller 122 updates a hardware doorbell register to notify the command module 200 of the internal controller 126 that one or more internal commands have been submitted. In some cases, a command submitted by the host 102 is split into multiple internal commands. In one embodiment, the multiple internal commands are submitted and processed simultaneously (e.g., in parallel) with one another by one or more internal controllers 126 to improve performance of the storage device 104.

[0037] In one embodiment, when an internal command requires a data transfer, a PRP / SGL fetch module 202 of the internal controller 126 fetches an internal PRP / SGL entry 136 from the internal CMB 128 for reading or writing data associated with the internal command. The internal PRP / SGL entry 136 is generated by the device controller 122. In one embodiment, for a read operation requiring a transfer from the NVM media 144, the internal PRP / SGL entry 136 is for the destination buffer 204. For a write operation requiring a transfer to the NVM media 144, the internal PRP / SGL entry 136 is for the source buffer 206.

[0038] In one embodiment, the transfer queue module 208 (TQ) is configured to process internal requests for transferring data to or from an intermediate buffer (not shown) based on the type of command (e.g., read or write). For example, in the case of an internal read or write operation, the transfer queue module 208 obtains information from the device controller 122 regarding specific data structures for controlling direct memory access, including a transfer (TR) descriptor and a direct memory access (DMA) descriptor. The TR descriptor includes the type of command for the data transfer (e.g., read or write). The DMA descriptor includes information regarding the intermediate buffer for the command type. For example, if the command type is an internal read command, the intermediate buffer is an intermediate read buffer used by the media interface 142 to temporarily hold data read from the NVM medium 144. If the command type is an internal write command, the intermediate buffer is an intermediate write buffer used by the media interface 142 to temporarily hold data to be written to the NVM medium 144.

[0039] In one embodiment, the DMA manager module (DMA_M) 210 receives the DMA descriptors as well as the PRP / SGL entries 136 and transfers data from the source buffer 206 to the NVM media 144 (via the intermediate buffers provided in the DMA descriptors) in the case of internal write operations, or from the NVM media 144 to the destination buffer 204 (via the intermediate buffers provided in the DMA descriptors) in the case of internal read operations.

[0040] 3 is a layout block diagram of an internal command stored as a submission queue entry (SQE) in internal submission queue 130 according to one embodiment. In one embodiment, the internal command is generated by the storage interface protocol for generating external commands. The internal command is 64 bytes in size and includes a command identifier (ID) 300, an operation code (OpCode) 302, a namespace ID (NSID) 304, a buffer address 306, and command parameters 308. The command ID 300 is the command ID within internal submission queue 130 to which the internal command is submitted.

[0041] OpCode 302 identifies the specific command to execute. In one embodiment, OpCode 302 is an NVMe OpCode for identifying an NVM command (e.g., write, read, management, dataset management, or vendor-specific command). In some embodiments, OpCode 302 identifies a new command in an internal command set accessible only to internal controller 126.

[0042] Namespace ID 304 identifies the namespace in which the command identified by OpCode 302 operates. Buffer address 306 contains an 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 are stored as command parameters 308.

[0043] 4 is a flowchart for processing a dataset management (DSM) command submitted by a host 102 to an external submission queue 112 to deallocate (undemap) a given set of LBA ranges from a given namespace according to one embodiment. The process starts at step 400 when one of the external controllers 124 fetches the command from the external submission queue 112 and communicates it to the device controller 122 for pre-processing by the processor 140.

[0044] In step 402, processor 140 performs certain pre-processing operations, including, for example, initiating a host direct memory access operation via storage interface bus 106 to transfer the LBA range from host memory 110 to the storage device's internal memory 138. Processor 140 also analyzes the LBA range to identify the total number of non-contiguous LBA ranges.

[0045] In step 404, processor 140 generates an internal unmap command for each non-contiguous LBA range identified by the processor. In one embodiment, the unmap command is a command that is not part of the storage interface protocol. Processor 140 submits the internal unmap command to one or more of internal submission queues (SQs) 130.

[0046] The unmap command submitted for each LBA range is processed by steps 406 through 412. Although this processing is described with respect to one unmap command for a single LBA range, it should be appreciated that other unmap commands submitted for other LBA ranges may also be processed in parallel by steps 406 through 412.

[0047] In step 406, the internal controller 126 fetches and processes the unmap command from the internal submission queue 130. The command module 200 of the internal controller 126 is invoked to fetch the unmap command from the internal submission queue 130. In one embodiment, if the processing of the unmap command does not require a data transfer, the PRP / SGL fetch module 202 of the internal controller 126 is not invoked and an internal PRP / SGL entry 136 is not created.

[0048] In step 408, internal controller 126 (e.g., an LBA overlap checker) determines whether the LBA range of the internal unmap command overlaps with the LBAs of commands being processed on behalf of host 102. For example, the LBA range of the unmap command may overlap with an LBA address currently being targeted by a read operation by host 102. If an overlap is detected, internal controller 126 waits until the host command is completed before unmapping the LBA range.

[0049] However, if no overlap is detected, the internal controller 126 sends one or more commands to the media interface 142 via the device controller 122 to perform the actual unmapping of the LBA range on the NVM media in step 410. It should be understood that the command parser sub-module may be invoked to perform other checks and verifications of the unmap command, such as the type of command based on the namespace format, the validity of the NSID, the reservation status, whether an LBA check is required, and the validity of the protection information, before transmitting the one or more commands to the media interface 142.

[0050] Upon determining the completion status of the unmap operation, the internal controller 126, in step 412, submits an internal completion entry to the internal completion queue 132 associated with the internal submission queue (SQ) 130 to which the internal unmap command was submitted.

[0051] In step 414, processor 140 determines whether all LBA ranges for the submitted DSM deallocate command have been deallocated (e.g., based on the status of the internal unmap command). If the answer is yes, then external controller 124 in step 416 submits an external completion entry to the external completion queue (SQ) 114 corresponding to the external submission queue (SQ) 112 to which the DSM deallocate command was submitted.

[0052] It should be appreciated that processing DSM deallocation commands according to one embodiment of the present invention provides technical improvements to the functionality of data storage device 104. For example, parallel processing of LBA ranges improves storage device performance because it splits DSM deallocation commands into independent unmap commands, each with a separate LBA range. Also, checking each LBA range for overlaps (e.g., via hardware) may prevent manual locking and unlocking of LBA ranges, thereby reducing processor 140 overhead. Furthermore, in embodiments in which 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) with dedicated processors (e.g., processor 140) that execute firmware (e.g., firmware executed on processor 140), host subsystem overhead is reduced because internal commands are processed without significant host subsystem involvement.

[0053] <Copy command processing>

[0054] In one embodiment, the command submitted by host 102 is a copy command (e.g., an NVMe copy command or a vendor-specific copy command) to copy data from one or more source addresses in NVM to one or more destination addresses in NVM media 144. The source and destination addresses are provided as source and destination LBA ranges. In one embodiment, the LBA range includes a start LBA and a number of logical blocks within the LBA range.

[0055] In one embodiment, the requested copy operation is from a single source LBA range to a single or multiple destination LBA ranges, or from multiple source LBA ranges to a single or multiple destination LBA ranges. The destination LBA ranges are in the same or a different namespace and / or are of the same or a different type of LBA size (e.g., logical block size) as the source LBA ranges. In some embodiments, the logical blocks have end-to-end protection information (PI) designated for error detection.

[0056] 5 is a conceptual block diagram of the format of a logical block 500 according to one embodiment. The logical block includes a data portion 502 and, optionally, a metadata portion 504. The data portion 502 has one of different sizes, such as 512B, 1024B, 4096B, etc. Logical blocks of different data sizes are described as having different LBA formats.

[0057] The metadata portion 504 is, for example, 16B and is used to convey metadata information 504a, including, for example, end-to-end protection information (PI) 504b. The end-to-end protection information is used by the controller 124 and / or host 102 to determine the integrity of the logical block. If end-to-end protection information is present, the PI 504b occupies either the first 8 bytes or the last 8 bytes of the metadata portion 504, depending on the namespace format. The remaining portion of the metadata (also called user data) is also 8 bytes or more. In some cases, the entire metadata portion 504 includes only the PI 504b or only the metadata information 504a. In one embodiment, the metadata portion 504 is referred to as metadata, and the PI 504b is a component of the metadata.

[0058] 6A and 6B are flowcharts illustrating processing a copy command (e.g., an NVMe copy command or a vendor-specific copy command) submitted by a host 102 to an external submission queue 112 according to one embodiment. While an NVMe copy command or a vendor-specific copy command is used as an example, it should be understood that the flowcharts may also apply to other copy commands submitted using other protocols similar to the NVMe protocol. It should also be understood that the order of the process steps is not fixed and can be changed to any desired order as recognized by one skilled in the art. Furthermore, two or more steps of the process may be performed serially or concurrently with one another.

[0059] The process starts in step 600 when one of the external controllers 124 fetches a submitted copy command from the external submission queue (SQ) 112 and communicates it to the device controller 122 for pre-processing by the processor 140 .

[0060] In step 602, pre-processing operations performed by the processor 140 include initiating a host direct memory access operation via the storage interface bus 106 to transfer source and destination LBA ranges from the host memory 110 to the storage device's internal memory 138. Furthermore, the processor 140 analyzes the LBA ranges to merge any adjacent ranges. One or more of the source and destination LBA ranges may be in different namespaces or have different LBA formats. For example, when using the NVMe Vendor Unique Copy command, different NSIDs are conveyed over the 64B itself for different source and destination namespaces. However, the NVMe copy command does not include information about different namespaces because it is not supported by the NVMe protocol.

[0061] In one embodiment, processor 140 generates read and write commands from the copy command. For example, processor 140 decomposes the copy command into independent read and write commands that are processed by internal controller 126 without host awareness. Then, in step 604, processor 140 prepares internal read commands for the non-contiguous source LBA ranges identified by processor 140 for submission to said internal submission queue (SQ) 130.

[0062] In step 606, processor 140 prepares one or more PRP / SGL entries 136 that describe the internal source buffers 206 from which data is to be read. If SGL entries are used, the particular SGL entry contains an SGL data block descriptor. The SGL data block descriptor contains the address and length of the data block to be read.

[0063] In step 608, internal controller 126 fetches and processes the read command from internal submission queue 130. Command module 200 of internal controller 126 is invoked to fetch and process the read command. In doing so, command module 200 interacts with processor 140 to perform the read transfer from NVM media 144 to an intermediate read buffer hosted, for example, in internal memory 138 of storage device 104. In some embodiments, internal controller 126 may process the read command based on submitting the command to internal submission queue 130 without intervention from processor 140 to improve performance of the storage device. In these embodiments, the intermediate buffer is allocated by device controller 122 without intervention by processor 140.

[0064] In addition to fetching the read command, the PRP / SGL fetch module 202 is also invoked to fetch the PRP / SGL entry 136 created by the processor 140 .

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

[0066] In one embodiment, data in source buffer 206 is processed for copying to a destination LBA range provided by the host in a copy command (e.g., an NVMe copy or vendor-specific copy command). DMA manager module 210 then prepares an internal write command to perform the copy and transfers the data in internal source buffer 206 to internal destination buffer 204. In some embodiments, processor 140 provides the address of internal source buffer 206 to which data was copied via an internal read command for use 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.

[0067] In step 609, it is determined whether all LBA ranges have been processed to generate read commands. If the answer is no, processor 140 returns to step 604 to prepare internal read commands for other non-contiguous source LBA ranges identified by processor 140. For example, if processor 140 were to read 100 non-contiguous LBA ranges, processor 140 would generate 100 separate read commands, with each read command including a different source LBA range as part of the command.

[0068] Data read via an internal read command is written via an internal write command, whereupon, in step 610, processor 140 prepares an internal write command for submission to one or more internal submission queues (SQs) 130. In one embodiment, the internal write command includes one of the destination LBA ranges of a copy command (e.g., an NVMe copy or vendor-specific copy command) submitted by the host.

[0069] In step 612, processor 140 prepares a PRP / SGL entry 136 that describes the internal destination buffer 204 (or internal source buffer 206, if provided by processor 140) containing data to be written to NVM media 144. In embodiments that use SGL entries, the SGL entry includes an SGL data block descriptor that includes the address and length of the data block to read. In some embodiments, the SGL entry includes an SGL bit bucket descriptor that includes the length of the data to omit when writing to the intermediate write buffer. In one embodiment, the SGL bit bucket descriptor is used to omit writing a PI portion of the data if the format / type of the PI in the source namespace differs from the format / type of the PI in the destination namespace. While the PI is used as an example of a portion of data that may be omitted, the invention is not so limited and other portions of data may be omitted for other types of commands as well.

[0070] In step 614, the internal controller 126 fetches and processes the write command from the internal submission queue 130. The command module 200 of the internal controller 126 is invoked to fetch and process the write command, which may interact with the processor 140 to perform the write transfer from the internal destination buffer 204 to an intermediate write buffer hosted, for example, in the internal memory 138 of the storage device 104.

[0071] In addition to fetching write commands, the PRP / SGL fetch module 202 is also invoked to fetch PRP / SGL entries 136 created by the processor 140 .

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

[0073] In one embodiment, separate read and / or write commands are submitted to one or more internal submission queues 130 for simultaneous processing. For example, after a first read command for an LBA range is executed via the steps of FIG. 6A, a first write command for the LBA range is processed via the steps of FIG. 6B, without waiting until all read commands for the LBA range have completed. Similarly, a second read command for a second LBA range is processed simultaneously with the processing of the first write command. The submission of the internal read command to internal submission queue 130 may not be detected by host 102.

[0074] In step 616, it is determined whether all LBA ranges have been copied. If the answer is YES, in step 618, the external controller 124 submits an external completion entry to the external completion queue (CQ) 114 that corresponds to the external submission queue 112 to which the copy command was submitted.

[0075] 7 is a more detailed block diagram of components of storage device 104 for processing internal read and write commands associated with copy commands according to one embodiment. The components 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.

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

[0077] In one embodiment, data blocks retrieved from NVM media 144 are placed in an intermediate read buffer 706. Intermediate read buffer 706 may reside, for example, in internal memory 138 of storage device 104. In one embodiment, data in intermediate read buffer 706 is accessed by host DMA module 700 and placed in one of internal CMB buffers 704. In this regard, host DMA module 700 is analogous to DMA manager module 210, and one of internal CMB buffers 704 into which data is placed is analogous to internal source buffer 206.

[0078] When executing an internal write command, the host DMA module 700 places data from one of the internal CMB buffers 704 (e.g., the internal destination buffer 204) into an intermediate write buffer 708. The intermediate write buffer 708 is located, for example, in the internal memory 138 of the storage device 104. In one embodiment, the 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 accesses the data in the intermediate write buffer 708 and writes the data to a location on the NVM media 144 that corresponds to the destination LBA.

[0079] 8A-8C are conceptual layout diagrams of various buffers involved in copying data from a source namespace to a destination namespace, according to one embodiment. Data in source namespace 800 is stored in multiple LBA ranges (802a-802c) (collectively referred to as 802). When processing an internal read command to perform the read portion of a copy command, flash DMA module 702 (FIG. 7) transfers reads from source LBA range 802 to intermediate read buffers (e.g., read data buffer 706a and read metadata buffer 706b). As described with reference to FIG. 5, a logical block of data then has a data portion 502 and a metadata portion 504. In one embodiment, flash DMA module 702 reads the data portions of various source LBA ranges 802 and stores the data portions in read data buffer 706a. Flash DMA module 702 also reads the metadata portions of the data and stores the metadata portions in read metadata buffer 706b.

[0080] Upon completing an internal read command, host DMA module 700 transfers data from read data buffer 706a and metadata from read metadata buffer 706b to internal CMB buffer 704a, with the transferred data stored in data section 808 of internal CMB buffer 704a and the transferred metadata stored in metadata section 810 of internal CMB buffer 704a, although embodiments are not limited in this respect.

[0081] The read data is then processed for recording to a destination LBA range. In the example of FIG. 8B, the data is recorded to a single destination LBA range 812 in the destination namespace 804. In the example of FIG. 8C, the data is recorded to multiple destination LBA ranges (814, 816). In either of these scenarios, the host DMA module 700 transfers the data from the 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 transfers data section 808 to write data buffer 708a and metadata section 810 to write metadata buffer 708b. In the example of FIG. 8B, the flash DMA module 702 then transfers the data from the write buffers (708a, 708b) along with the corresponding metadata to the single destination LBA range 812 in the destination namespace 804. 8C, flash DMA module 702 transfers data from write buffers (708a, 708b) along with corresponding metadata to multiple destination LBA ranges (814, 816). For example, data from write data buffer 708a is transferred to destination LBA ranges (814, 816), and metadata from write metadata buffer 708b is transferred to destination LBA ranges (814, 816).

[0082] 9A and 9B are conceptual layout diagrams of various buffers involved in copying data from multiple LBA ranges in a source namespace 900 to a single LBA range in a destination namespace 902, according to one embodiment, where both the source and destination namespaces have the same LBA format. For example, the data size of logical blocks in the source and destination namespaces is 512B, and each logical block has metadata including an 8B PI. 9A and 9B also illustrate buffers used to copy data from multiple LBA ranges in the source namespace 900 to multiple destination LBA ranges, where both the source and destination namespaces (900, 902) are formatted with the same LBA size.

[0083] In the example of FIGS. 9A and 9B, four source LBA ranges (904a-904d) (e.g., LBAs 0-7, 10-13, 20-23, and 28-43) are copied to a single destination LBA range 906 (e.g., LBAs 0-31). In doing so, the data in the four source LBA ranges (904a-904d) is read and stored in intermediate read data buffer 706c (e.g., 512B, 4KB, 8KB, 16KB at a time) and transferred to internal CMB buffer 704b. The PI data corresponding to each logical block of the read data is also read and stored in intermediate read metadata buffer 706d (e.g., 8B at a time) and transferred to internal CMB buffer 704b.

[0084] When performing a write operation, the data in internal CMB buffer 704b is transferred to intermediate write data buffer 708c. The metadata stored in internal CMB buffer 704b is also copied to intermediate write metadata buffer 708d. In one embodiment, in the example of Figures 9A and 9B, the source and destination LBAs are the same, so the PI portion of the metadata is not copied to intermediate write metadata buffer 708d. The data and metadata in the write buffers (708c, 708d) are transferred to destination LBA range 906 to complete the copy operation. In one embodiment, the PI portion of the metadata that was not copied is regenerated (e.g., by host DMA module 700) and stored in destination LBA range 906.

[0085] 10A and 10B are conceptual layout diagrams of various buffers involved in copying data from multiple LBA ranges in a source namespace 1000 to multiple LBA ranges in a destination namespace 1002 according to one embodiment, where the source and destination namespaces have different LBA formats. For example, the data size of a logical block in the source namespace 1000 is 512 B, while the data size of a logical block in the destination namespace 1002 is 4096 B. In the example of FIGS. 10A and 10B, four source LBA ranges (1004a-1004d) (e.g., LBAs 0-7, LBAs 10-13, LBAs 20-23, and LBAs 28-43) are copied to two destination LBA ranges (1006a, 1006b) (e.g., LBAs 0, 1 and LBAs 4, 5). 10A and 10B also describe buffers used to copy data from multiple LBA ranges in a source namespace 1000 to a single LBA range in a destination namespace 1002, where the source and destination namespaces (1000, 1002) are formatted with different LBA sizes.

[0086] When performing a read operation, data in various LBA ranges (1004a-1004d) of source namespace 1000 is copied to intermediate read data buffer 706e and corresponding metadata is copied to intermediate read metadata buffer 706f. The contents of intermediate read data buffer 706e and intermediate read metadata buffer 706f are then transferred to internal CMB buffer 704c.

[0087] When performing a write operation, data from internal CMB buffer 704c is transferred to intermediate write data buffer 708e according to the LBA format of destination namespace 1002. For example, 4096B of data from internal CMB buffer 704c is stored at once in intermediate write data buffer 708e. Metadata from internal CMB buffer 704c is also copied to intermediate write metadata buffer 708f. The data and metadata from write buffers (708e, 708f) are then transferred to destination LBA ranges (1006a, 1006b). In one embodiment, because the source and destination namespaces have different LBA formats in the example of Figures 10A and 10B, any PI portions of the metadata are regenerated by host DMA module 700 according to the PI format used by the destination namespace.

[0088] 11A and 11B are conceptual layout diagrams of a buffer and SGL table used to copy data in one source LBA range in one namespace to a destination LBA range in another namespace according to one embodiment, where the source and destination LBA ranges are the source and destination LBA ranges of FIGS. 10A and 10B. It should be understood that in the embodiment of FIGS. 9A and 9B where the LBA formats of the source and destination namespaces are the same, a similar SGL table may be used for the buffer.

[0089] 11A and 11B, the SGL bit bucket descriptor 1110 is used to omit the PI of the read data to enable assembly of the read data and associated metadata (including the appropriate PI) into different LBA formats in the destination namespace, as described below. The omitting of the PI is done as part of a read operation while writing to an internal CMB buffer, or as part of a write operation while reading from an internal CMB buffer. The regeneration of the PI is performed by the host DMA module according to the destination LBA format.

[0090] 11A and 11B, eight logical data blocks (512 B each) in the source namespace form a single destination logical block of size 4096 B. The PIs associated with each 512 B data block (e.g., the 8 B PI) are omitted using bit bucket descriptors in the write portion of the process, and a single data block of size 4096 B is formed in the destination namespace with a regenerated PI (e.g., the regenerated 8 B PI).

[0091] More specifically, when performing an internal read operation, data (e.g., 4 KB of data) retrieved from NVM media 144 and stored in intermediate read data buffer 706g is transferred to internal CMB buffer 704d (similar to the process of FIGS. 10A and 10B). Metadata stored in intermediate read metadata buffer 706h is also transferred to internal CMB buffer 704d. The internal CMB buffer 704d to which the data and metadata are transferred is described by one or more PRP / SGL entries 136a. In one embodiment, PRP / SGL entries 136a are generated by processor 140 based on the fetching and processing of an internal read command. While the examples of FIGS. 8-10 do not explicitly depict PRP / SGL entries, it should be understood that PRP / SGL entries are also used in these examples to describe the internal CMB buffers (704a-704c).

[0092] 11A and 11B, the metadata in intermediate read metadata buffer 706h includes a metadata portion 1100 and a PI portion 1102 for each logical block of data 1104 (e.g., 512 B of data) in intermediate read data buffer 706g. When executing the write portion of a copy command, the logical blocks of data 1104 and corresponding metadata portion 1100 transferred to internal CMB buffer 704d are written from internal CMB buffer 704d to intermediate write data buffer 708g and intermediate write metadata buffer 708h, respectively. In one embodiment, the data written to intermediate write data buffer 708g follows the LBA format of the destination namespace. For example, the size of each logical block of data in intermediate write data buffer 708g is 4096 B.

[0093] 11A and 11B, the LBA formats of the source and destination namespaces are different. Therefore, according to one embodiment, the PI portion 1102 of the read metadata is omitted and not copied from the internal CMB buffer 704d to the write metadata buffer 708h. In one embodiment, the omitted PI portion of the metadata is generated as PI 1106 by the host DMA module 700. The generated PI 1106 is based on the PI format used by the destination namespace.

[0094] In one embodiment, the information provided by PRP / SGL entry 136b used to write data to intermediate write buffers (708g, 708h) enables omission of the PI portion 1102 of the read metadata in internal CMB buffer 704d. In one embodiment, PRP / SGL entry 136b is generated by processor 140 based on fetching and processing of internal write commands. In one embodiment, processor 140 determines that the PI portion of the metadata to be recorded is to be omitted. These decisions are made based on a determination that the PI portion is enabled in the metadata read from the source namespace and a determination that the LBA format of the destination namespace is different from the LBA format of the source namespace.

[0095] In one embodiment, the SGL entry includes a descriptor for the data block to be copied (e.g., 512 B) and associated metadata (e.g., 8 B of user data excluding the PI portion), and includes an SGL data descriptor 1108 for the data to copy. In one embodiment, an SGL bit bucket descriptor 1110 following the SGL data descriptor 1108 is used to suppress copying the PI portion of the metadata in the internal CMB buffer 704 d. For example, the SGL bit bucket descriptor 1110 identifies the 8 B of PI data to be omitted.

[0096] In one embodiment, host DMA module 700 uses PRP / SGL entry 136b to transfer data from internal CMB buffer 704d to write data and metadata buffers (708g, 708h). In doing so, host DMA module 700 transfers the data in the CMB buffer described in SGL data descriptor 1108 to write data and metadata buffers (708g, 708h) and omits some of the data described in SGL bit bucket descriptor 1110. Host DMA module 700 continues in a similar manner, transferring the data described in the remaining SGL data descriptor 1112 and omitting the data described in the remaining SGL bit bucket descriptor 1114. The PI portion of the omitted metadata is then regenerated. The PI portion of the omitted metadata is regenerated by host DMA module 700 and stored in write metadata buffer 708h according to the LBA format of the destination namespace. In one embodiment, the regenerated PI is 8B in size and is associated with 4096B of data in the destination namespace. In one embodiment, the 8B PI 1106 is 56B in size in the example of Figure 11b and forms the last 8B of user data copied from the source namespace.

[0097] In some embodiments, instead of including an SGL bit bucket descriptor in PRP / SGL entry 136b for transferring data from internal CMB buffer 704d to write data and metadata buffers (708g, 708h) during a write process, an SGL bit bucket descriptor is included in PRP / SGL entry 136a used for a read process. According to this embodiment, some of the data described in the SGL bit bucket descriptor of the PRP / SGL entry is omitted and is not transferred from intermediate read metadata buffer 706h to internal CMB buffer 704d.

[0098] It should be appreciated that embodiments of the present invention enable processing of copy commands across different namespaces even when the LBA formats between the namespaces are different and / or when different end-to-end protection information is used by the different namespaces. Using SGL bit bucket descriptors to omit end-to-end protection information for read data allows the data (including protection information) and associated metadata to be assembled into different LBA formats in the destination namespace. Regeneration of the PI is performed by the host DMA module according to the destination LBA format.

[0099] It should be understood that the one or more processors mentioned above include programmable logic devices such as, for example, an ASIC, a general-purpose or special-purpose CPU, a digital signal processor (DSP), a graphics processing unit (GPU), and / or an FPGA. In a processor as used herein, each function is performed by hardware, firmware, and / or software. A processor may be fabricated on a single printed circuit board (PCB) or distributed across multiple connected PCBs. A processor may include other processing circuits. For example, a processing circuit may include two processing circuits, an FPGA, and a CPU interconnected on a PCB.

[0100] Terms such as "first," "second," and "third" are used to refer to various components, regions, layers, and / or sections, but these components, regions, layers, and / or sections should not be limited by these terms. These terms are used only to distinguish one component, region, layer, or section from another component, region, layer, or section. Thus, a first component, first region, first layer, or first section could be referred to as a second component, second region, second layer, or second section without departing from the spirit or scope of the present invention.

[0101] The terms used herein are intended to describe specific embodiments and are not intended to limit the concept of the present invention. As used herein, the terms "substantially," "about," and similar terms are used as terms to describe approximations and to account for inherent variations in measurements or calculations that are recognized by those of ordinary skill in the art.

[0102] As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly dictates otherwise. As used herein, the term "comprising" specifies the presence of disclosed features, numerals, steps, operations, and / or components, but does not exclude the presence or addition of one or more other features, numerals, steps, operations, components, and / or combinations thereof. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items. Phrases such as "at least one" modify the entire list of components, but not individual components of the list. When describing embodiments, the term "may" refers to one or more embodiments of the invention. The term "exemplary" is intended to refer to an example or illustration. The term "using" is considered synonymous with the term "utilizing."

[0103] When a component or layer is referred to as "on," "connected," or "coupled" to another component or layer, it is understood that the component or layer is directly connected or coupled to the other component or layer, or that intervening components or layers may be present. In contrast, when a component or layer is referred to as "directly," "directly connected," or "directly coupled" to another component or layer, there are no intervening components or layers. Like reference numbers refer to like components.

[0104] Any numerical range recited herein is intended to include all subranges subsumed within the recited range. For example, a range of "1.0 to 10.0" includes all subranges between the recited minimum of 1.0 and the recited maximum of 10.0 (e.g., 2.4 to 7.6). Any maximum numerical value recited herein is intended to include all subranges subsumed therein, and any minimum numerical value recited herein is intended to include all subranges subsumed therein.

[0105] Although the embodiments of the present invention have been described in detail above with reference to the drawings, the present invention is not limited to the above-described embodiments and can be modified in various ways without departing from the technical concept of the present invention. [Explanation of symbols]

[0106] 100 Data Storage and Retrieval System 102 Host 104 Data storage device 106 Storage Interface Bus 108, 140 Processor (CPU) 110 Host Memory (Space) 112 External Submission Queue (SQ) 114 External Completion Queue (CQ) 116 Physical Region Page (PRP) / Scattered Gather List (SGL) entries 117, 134 Data 118 Communication Interface (PCIe Interface) 120 NVMe subsystem 122 Equipment Controller 124 External Controller 126 Internal Controller 128 Internal CMB 130 Internal Submission Queue (SQ) 132 (Internal) Completion Queue (CQ) 136 (internal) PRP / SGL entries 138 internal memory 142 Media Interface 144 NVM Media 200 Command Module 202 PRP / SGL fetch module 204 (Internal) Destination Buffer 206 (internal) source buffer 208 Transmission Queue Module (TQ) 210 DMA Administrator Module (DMA_M) 300 Command Identifier (ID) 302 Operation Code (OpCode) 304 Namespace ID (NSID) 306 Buffer Address 308 Command Parameters 500 logical blocks 502 Data part 504, 1100 Metadata part 504a Metadata Information 504b, 1106 Protected Information (PI) 700 Host DMA Module 702 Flash DMA Module 704 Internal CMB Buffer 706 Intermediate Read Buffer 706a, 706c, 706e, 706g (intermediate) read data buffer 706b, 706d, 705f, 706h (intermediate) Read Metadata Buffer 708 Intermediate Write Buffer 708a, 708c, 708e, 708g (intermediate) write data buffer 708b, 708d, 708f, 708h (intermediate) Write Metadata Buffer 800, 900, 1000 source namespace 802, 904, 1004 Source LBA Range 804, 902, 1002 destination namespace 808 Data Section 810 Metadata Section 812, 906 (single) destination LBA range 814, 816, 1006 Destination LBA range 1100 Metadata part 1102 PI part 1104 Data 1108, 1112 SGL Data Descriptor 1110, 1114 SGL bit bucket descriptor

Claims

1. A method for processing a copy command from a host to a storage device, comprising: receiving, by a first controller of the storage device, a copy command from a host via a first queue, the copy command including a first source address and a first destination address; generating a first read command and a first write command by the storage device based on the copy command; submitting, by the storage device, the first read command and the first write command to a second controller of the storage device via a second queue; obtaining and processing the first read command and the first write command from the second queue by the second controller; reading, by the storage device, data stored at a first location of a storage medium of the storage device associated with the first source address based on processing the first read command; writing, by the storage device, the data to a second location on the storage medium associated with the first destination address based on processing of the first write command; sending, by the first controller, a signal to the host indicating completion of the copy command; the data stored in the first location of the storage medium includes metadata having a first portion and a second portion; The step of writing data includes: writing a first portion of the metadata to a third location on 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, a third portion of the metadata to the storage medium in place of the second portion of the metadata.

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

3. the copy command includes a second destination address; The step of writing data includes: writing a first portion of the data to a second location on the storage medium associated with the first destination address; and writing a second portion of the data to a third location on the storage medium associated with the second destination address.

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

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

6. The method of claim 1 , wherein the second portion of the metadata includes data protection information.

7. the first source address is associated with a first logical space configured to store a first sized block of data; 2. The method of claim 1, wherein 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.

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

9. the storage device is a non-volatile storage device, 2. The method of claim 1, wherein the first controller and the second controller comply with a Non-Volatile Memory Express (NVMe) protocol.

10. 2. The method of claim 1, further comprising submitting, by the second controller, a first completion status to a first completion queue.

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

12. A storage device, Storage media and one or more processors coupled to the storage medium; Each of the one or more processors: receiving a copy command from a host via a first controller and a first queue, the copy command including a first source address and a first destination address; generating a first read command and a first write command based on the copy command; submitting the first read command and the first write command to a second controller of the storage device via a second queue; obtaining and processing the first read command and the first write command from the second queue via the second controller; reading data stored at a first location of a storage medium of the storage device associated with the first source address based on processing of the first read command; writing the data to a second location on the storage medium associated with the first destination address based on processing the first write command; configured to send a signal to the host via the first controller indicating completion of the copy command; the data stored in the first location of the storage medium includes metadata having a first portion and a second portion; When writing the data, the one or more processors: writing a first portion of the metadata to a third location on the storage medium associated with the first destination address; generating a third portion of the metadata based on the first destination address; 10. The storage device, further configured to write a third portion of the metadata to the storage medium in place of the second portion of the metadata.

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

14. the copy command includes a second destination address; When writing the data, the one or more processors: writing a first portion of the data to a second location on the storage medium associated with the first destination address; 13. The storage device of claim 12, configured to write the second portion of the data to a third location on the storage medium associated with the second destination address.

15. 13. The storage device of claim 12, wherein the one or more processors are further configured to omit reading a second portion of the metadata based on processing of the first read command.

16. 13. The storage device of claim 12, wherein the one or more processors are further configured to omit writing the second portion of the metadata based on processing of the first write command.

17. 13. The storage device of claim 12, wherein the second portion of the metadata includes data protection information.

18. the first source address is associated with a first logical space configured to store a first sized block of data; 13. The storage device of claim 12, wherein 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