Quick reset method for SSD (Solid State Disk)

Abstract

The invention discloses a quick reset method of a solid state disk (SSD), the SSD comprises a plurality of command processing modules and is used for processing read-write commands issued by a host, and the method comprises the following steps: after receiving a reset request, immediately replying a reset completion response to the host; marking the command which is not processed at present as a discarding identifier so as to be identified by a plurality of command processing modules in the SSD; and in the subsequent task execution process, if the multiple command processing modules identify the discarding identifier, asynchronously releasing the resources associated with the corresponding commands without blocking the reply process of the reset completion response. Therefore, according to the SSD quick reset method provided by the embodiment of the invention, the reset time is shorter, the host response is faster, and the reset action completion time is at a millisecond level. When the link is abnormal or the controller is reset, the IO return-to-zero phenomenon can be avoided, and the reliability of the system and the user experience are improved.

Description

Technical Field

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

[0002] An SSD typically contains multiple cooperating command processing modules to handle read and write commands issued by the host. These modules may include a front-end (FE) module, a data cache (DC) module, a flash translation layer (FTL) module, and a NAND flash controller (NFC) module. The front-end module is mainly used for protocol layer processing and data reception; the data cache module caches commands issued by the host; the data translation layer module flushes the cached data and manages the mapping between logical addresses and physical addresses; the NAND flash controller module shields the characteristics of different NAND flash chips and flushes the data onto the NAND chips. Data transmission between the SSD and the host is achieved through links such as SATA and PCIe. When link failures, command timeouts, or host-initiated resets occur, the SSD firmware (FW) needs to be reset to restore a stable state.

[0003] Traditional reset methods typically employ a blocking process to avoid data loss. Specifically, the controller first pops commands that haven't yet been completed and responded to from the processing queue (these commands may not have been submitted to the front-end module for direct memory access (DMA) operations). Then, it flushes the data of commands that have been completed and responded to from the host to flash memory. This process continues until the flushing is complete, while waiting for the queues of modules like FTL and NFC to be emptied. Finally, it resets the entire DC module and clears its resources. This process requires emptying all queues of FE, DC, FTL, and NFC step by step, and also requires flushing the DC data and releasing its buffer, which is time-consuming, taking approximately one to several seconds. Under heavy load, this situation becomes even more severe, inevitably leading the host to observe zero I / O data. Furthermore, this method requires complex exception handling for commands; for example, commands that are only partially processed should not be flushed to avoid the problem of some new data and some old data appearing in the I / O data. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method for fast SSD reset. Through a pre-reset mechanism, the firmware can quickly respond to the host without waiting for all internal commands and resources to be cleared.

[0005] The objective of this invention is achieved through the following technical solution:

[0006] This application discloses a fast reset method for a solid-state drive (SSD). The SSD includes multiple command processing modules for processing read and write commands issued by the host. The method includes: upon receiving a reset request, immediately replying to the host with a reset completion response; marking currently unprocessed commands as discard flags for identification by the multiple command processing modules within the SSD; and asynchronously releasing the resources associated with the corresponding command during subsequent task execution if the multiple command processing modules identify the discard flags, without blocking the reset completion response reply process.

[0007] Furthermore, the step of marking currently unprocessed commands as discarded also includes: for commands that have been processed and responded to by the host, only their context resources are released.

[0008] Furthermore, the unprocessed commands include read commands, and marking read commands as discarded includes: marking all read commands received by the SSD front-end module as discarded, and searching and marking the corresponding requests in the next-level processing modules according to the request context of the read commands.

[0009] Furthermore, the unfinished commands also include write commands, and marking write commands as discarded includes: excluding write commands that have been completed and responded to by the host, and marking the remaining unfinished write commands as discarded.

[0010] Furthermore, before replying to the host with a reset completion response, the process also includes: the front-end module marking all its context commands with discard flags, and then determining that the reset action is complete.

[0011] Furthermore, the asynchronous release of resources associated with the corresponding command includes at least: before the task execution of the command processing module, traversing and releasing all resources associated with commands marked as discarded; or, when the task execution of the command processing module reaches the current command, if it is identified that the command has been marked as discarded, releasing the resources associated with the command and returning directly.

[0012] Furthermore, after responding to the host with a reset completion response, the SSD immediately restores the link connection to the host or issues a new command.

[0013] Furthermore, the multiple command processing modules include: a front-end module, a command cache module, a flash conversion layer module, and a flash control module; the step of marking the discard identifier is initiated by the front-end module, and the discard identifier is passed down level by level based on the request context relationship recorded between modules at each level.

[0014] The beneficial effects of this invention are: the SSD fast reset method provided in this application has a shorter reset time, faster host response, and a reset action completion time in milliseconds. It can avoid IO zeroing when encountering link anomalies or controller resets, thus improving system reliability and user experience. Attached Figure Description

[0015] Figure 1 This is a simplified schematic diagram illustrating data partitioning according to an embodiment of this application;

[0016] Figure 2 This is a simplified schematic diagram of a method for fast SSD reset according to an embodiment of this application. Detailed Implementation

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

[0018] Combination Figure 1 and Figure 2 To understand a method for fast SSD reset according to an embodiment of this application.

[0019] like Figure 1 The SSD fast reset method described in this embodiment, upon receiving a reset request, immediately assumes the reset is complete and replies with a reset completion response to the host. The reset request includes requests from the host, internal SSD determinations requiring a reset, etc. Simultaneously, the firmware divides currently processed commands into completed and incomplete parts. For commands that have been replied to the host as completed, their data has reached the DC, and the firmware does not need to perform special processing or flush the data; it only needs to release its context resources. For all incomplete commands, a discard flag is preset, such as... Figure 1 The Cmd1-CmdN flags are used in the firmware's internal modules. When subsequent tasks encounter a command marked with this flag, they asynchronously release the context and resources associated with that command, without waiting for all queues and resources to be cleared in a blocking manner.

[0020] In other words, when each task within the firmware encounters a command marked with a discard flag, it recognizes that the command and its associated resources do not require further processing and can be directly returned. Compared to the previous blocking wait queue and resource emptying, the optimized process only requires pre-setting the flag, significantly shortening the processing time. The firmware can respond quickly to the host after setting the discard flag, drastically reducing processing latency to the millisecond level. This allows for rapid generation of controller reset requests, avoiding disk recognition issues caused by some hosts responding to controller resets. Furthermore, the host is unaware of the IO zeroing phenomenon during the IO process, improving the firmware's host compatibility.

[0021] Next, combine Figure 2 A specific embodiment will be described below.

[0022] In practical implementation, the fast reset method first sends a reset completion response to the host immediately upon receiving a reset request. This process does not require waiting for the completion of the complex internal resource cleanup process. Simultaneously, the firmware marks all currently incomplete commands as discarded. In this example, the incomplete commands refer to commands that have been received by the front-end module but have not yet completed their entire processing flow; for example, they may be in the processing queue of the DC, FTL, or NFC modules and have not yet responded to the host with a final completion status. Furthermore, the discard flags are recognized by multiple command processing modules within the SSD (such as FE, DC, FTL, and NFC).

[0023] Subsequently, during their respective task execution, if these command processing modules identify a command currently being processed with a discard flag, they will asynchronously release all resources associated with that command, such as the command context and DC buffer. In this example, the asynchronous execution ensures that the resource release operation is performed in the background, parallel and non-blocking to the main process of responding to the host with a reset completion response. Therefore, the action of responding to the host is not blocked by the internal time-consuming resource release process, thus achieving a fast reset response. After responding to the host with a reset completion response, the SSD can immediately restore the link connection to the host or begin processing newly issued commands from the host.

[0024] To more efficiently mark all incomplete commands, this embodiment utilizes the contextual relationships between command processing modules.

[0025] In detail, the typical processing flow of a command is as follows: the front-end module generates a request, then the command cache module generates a request, then the flash conversion layer module generates a request, and finally the flash control module generates a request. When a downstream module receives a command, it records the context information of the upstream module. For example, a request from the DC module will record the context of the FE request that processed it. This is used so that after the downstream module completes its task, it can call back the request completion of the upstream module level by level, and perform command and resource release operations in the callback.

[0026] In this embodiment, to quickly pre-set unprocessed commands when resetting the controller, requests from the front-end module also need to record the context requests from the subsequent modules. Thus, when it's necessary to quickly mark an incomplete front-end module command as a discard flag during reset, the context recorded by the front-end module can be used to quickly find and mark the corresponding requests in subsequent modules such as DC, FTL, and NFC, achieving a hierarchical transmission of the discard flag. That is, the step of marking a discard flag is initiated by the front-end module and, based on the request context relationships recorded between modules, the discard flag is passed down level by level.

[0027] Based on the above mechanism, the step of marking currently incomplete commands as discardable requires differentiating command types in practice. For read I / O commands, none of them need to return data to the host. Therefore, the firmware uniformly marks all read commands received by all front-end modules as discardable. Then, based on the request context of each read command in the front-end module, it searches down level by level for the corresponding request in the command cache module, flash memory conversion layer module, and other lower-level processing modules, and presets discardable flags for these lower-level requests as well. For write I / O commands, the firmware first needs to exclude those commands that have already been replied to the host as completed. For these completed write commands, the data has been sent by the host and confirmed, and the firmware only needs to release its context resources, while the DC resources (buffer) it occupies are not released. For the remaining incomplete write commands, such as those that have entered the DC but have not replied to the host, or those that are being processed in FTL or NFC, the front-end module initiates the process, similar to the handling of read commands, and searches down level by level for and marks the corresponding request in the lower-level processing module as discardable.

[0028] In some embodiments, before replying to the host with a reset completion response, the front-end module needs to mark all context commands it manages as discardable. Once the front-end module has successfully marked all incomplete commands (including read commands and incomplete write commands) within its jurisdiction with discardable flags and completed the release of context resources for completed commands, the firmware can determine that the core part of this reset action has been completed, i.e., perform a front-end module pre-reset. At this point, the firmware can consider the reset action complete after marking the context of all front-end modules, and reply to the host with a completion response, without waiting for all resources within the firmware to be released, and can immediately respond to host connections or commands.

[0029] After the reset completion response is sent back to the host, the command with the preset discard flag will be released naturally during the subsequent task execution of each module of the firmware, that is, the discard command task release will be performed.

[0030] Furthermore, the asynchronous release of resources associated with the corresponding command can be implemented in two efficient ways.

[0031] One approach is to proactively traverse all request queues managed by a command processing module before its task begins execution. If a request is found to have a pre-set discard flag, the context and allocated resources associated with that command are immediately released. Another approach is to observe the status of a request only when the command processing module's task is executing normally up to processing a specific request. If, at this point, the command is found to have a pre-set discard flag, the task will not execute the original processing logic for that command, thus releasing the context and allocated DC resources more quickly—that is, directly releasing the resources associated with the command and returning immediately. For example, in the callback function of a command's DMA operation completion, if it is found that the command has been discarded, the allocated DC resources are released, the operation is discarded, and the DC resources are released.

[0032] It is understood that the SSD fast reset method provided in this application embodiment has a shorter reset time, faster host response, and a reset action completion time in milliseconds. When encountering link anomalies or controller resets, it can avoid IO zeroing, improving system reliability and user experience.

[0033] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A fast reset method for a solid-state drive (SSD), wherein the SSD includes multiple command processing modules for processing read and write commands issued by a host, characterized in that, include: Upon receiving a reset request, immediately reply to the host with a reset complete response; Commands that are not currently being processed are marked as discarded so that they can be identified by the multiple command processing modules inside the SSD; If the discard flag is identified during subsequent task execution, the multiple command processing modules will asynchronously release the resources associated with the corresponding command without blocking the reset completion response process.

2. The fast reset method for a solid-state drive (SSD) according to claim 1, characterized in that, The step of marking currently unprocessed commands as discarded further includes: For commands that have been processed and responded to by the host, only their context resources are released.

3. The fast reset method for a solid-state drive (SSD) according to claim 1 or 2, characterized in that: The unprocessed commands include read commands. Marking read commands as discarded includes: marking all read commands received by the SSD front-end module as discarded, and searching and marking the corresponding requests in the next lower-level processing modules according to the request context of the read commands.

4. The fast reset method for a solid-state drive (SSD) according to claim 3, characterized in that: The commands that have not been processed include write commands. Marking write commands as discarded includes: excluding write commands that have been completed and replied to by the host, and marking the remaining uncompleted write commands as discarded.

5. The fast reset method for a solid-state drive (SSD) according to claim 1, characterized in that, Before sending a reset completion response to the host, the following is also included: The front-end module marks all context commands with discard flags, and then determines that the reset action is complete.

6. The fast reset method for a solid-state drive (SSD) according to claim 1, characterized in that, The asynchronous release of resources associated with the corresponding command includes at least: Before the task execution of the command processing module, iterate through and release all resources associated with commands marked as discarded; Alternatively, when the task execution of the command processing module reaches the current command, if it is recognized that the command has been marked as discarded, the resources associated with the command are released and the process returns directly.

7. The fast reset method for a solid-state drive (SSD) according to claim 1, characterized in that, After responding to the host with a reset completion response, the SSD immediately restores the link connection to the host or issues a new command.

8. The fast reset method for a solid-state drive (SSD) according to claim 1, characterized in that, The multiple command processing modules include: a front-end module, a command cache module, a flash conversion layer module, and a flash control module; The step of marking the discard flag is initiated by the front-end module and passed down level by level based on the request context relationship recorded between modules at each level.

Images