A method and device for enabling an ssd to enter an emergency mode and be visible to a host

Abstract

The application discloses a method and device for enabling an SSD to enter an emergency mode and be visible to a host end. Firmware of the SSD is separated into a front-end component and a back-end component, the front-end component is used for responding to a host command, and the back-end component is used for managing NAND; the method comprises the following steps: when a failure occurs in operation of the SSD, the SSD enters an emergency mode after being restarted, only the front-end component is operated in the emergency mode, and a command sent by the host to the SSD is processed by the front-end component, so that the host end can identify the SSD. By adopting the technical scheme of the application, the SSD can enter the emergency mode after being restarted when a failure occurs in the firmware of the SSD, the firmware of the SSD and the host end can send instructions to each other in the emergency mode, and a device failure can be solved in time.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of storage, in particular to a method and device for enabling an SSD to enter an emergency mode and be visible to a host. BACKGROUND

[0002] Because some states of the controller registers of a storage device such as an SSD (solid state disk) are cached in the memory (Host DDR) of the host, when a traditional SSD has some firmware running faults or abnormal power failure protection failures, the register states may fail to be recovered at the back end of the SSD, leading to NVMe initialization failure at the front end, the host cannot identify the SSD, and the host cannot obtain error register log information of the first time when the device has a fault, which greatly affects the problem positioning and analysis efficiency. Because the host cannot identify the SSD device, user data cannot be accessed, and the user experience of SSD fault processing is not good. SUMMARY

[0003] The present application provides a method for enabling an SSD to enter an emergency mode and be visible to a host, firmware of the SSD is separated into a front-end component and a back-end component, the front-end component is used to respond to host commands, and the back-end component is used to manage NAND; the method comprises: when the SSD runs a fault, the SSD enters an emergency mode after restarting, in the emergency mode, only the front-end component is run, and the front-end component processes commands sent by the host to the SSD, so that the host can identify the SSD.

[0004] The method for enabling an SSD to enter an emergency mode and be visible to a host as described above, wherein the front-end component comprises a PCIe module, an Admin module, and a data management module, is used to process PCIe physical layer events, execute NVMe management instructions, manage data processing read / write requests, and convert front-end read requests into back-end available microcode; the back-end component comprises NAND management related modules, including log records for updating FTL, facilitating FTL reconstruction, and being used for complete recovery of data after abnormal power failure; including a garbage collection function; including a function of scheduling read, write, and erase instructions according to different priorities.

[0005] The method for enabling an SSD to enter an emergency mode and be visible to a host as described above, wherein the front-end component of the SSD firmware responds to IO instructions issued by the host, and prevents the host from being down by returning an error status code.

[0006] The method for enabling an SSD to enter an emergency mode and be visible to a host as described above, wherein in the emergency mode, the front-end component of the SSD firmware reports one or more asynchronous events to the host, is used to notify the host of the running state of the SSD when the events occur, including error and running health status information.

[0007] The method for entering the emergency mode and being visible to the host side of the SSD as described above, wherein in the emergency mode, the front-end component supports the upgrade function of the SSD firmware, and the problem is repaired by upgrading the firmware.

[0008] The method for entering the emergency mode and being visible to the host side of the SSD as described above, wherein in the emergency mode, the Elog enters the read-only state, so that the important key information is not covered or damaged.

[0009] The method for entering the emergency mode and being visible to the host side of the SSD as described above, wherein in the emergency mode, the front-end component deletes all IO submission and completion queues and resets the management submission queue and the completion queue in response to receiving the controller reset command, so as to be compatible with different hosts.

[0010] The method for entering the emergency mode and being visible to the host side of the SSD as described above, wherein in the emergency mode, the back-end component of the SSD is stopped, so as to ensure that the user data is in the frozen state.

[0011] The method for entering the emergency mode and being visible to the host side of the SSD as described above, wherein in the emergency mode, the front-end component clears the emergency mode flag in response to the NVMe format command, so that the SSD enters the normal mode.

[0012] The application also provides a solid-state storage device, comprising a memory, a controller and a non-volatile memory, wherein the controller executes the method described in any one of the above.

[0013] The application has the following beneficial effects: by using the technical solution of the application, when the SSD firmware fails, the SSD can automatically enter the emergency mode after restarting, the SSD firmware and the host side can send commands to each other in the emergency mode, instead of being in the "dead" state of not responding to any host command, so that the user can effectively find and timely solve the device failure. BRIEF DESCRIPTION OF DRAWINGS

[0014] In order to more clearly illustrate the technical solutions of the embodiments of the application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiment or prior art description. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can also be obtained by those skilled in the art according to these drawings.

[0015] Figure 1 is a flow chart of SSD firmware instruction processing;

[0016] Figure 2 is a data structure diagram of the telemetry log (Telemetry: Host-Initiated log) initiated by the host.

[0017] Figure 3 is a flow chart of the process of SSD firmware error handling;

[0018] Figure 4 is a flow chart of the process of SSD cold start automatically entering emergency mode;

[0019] Figure 5 is a flow chart of the process of SSD entering emergency mode according to another embodiment of the application;

[0020] Figure 6 is a flow chart of the process of SSD entering emergency mode according to still another embodiment of the application;

[0021] Figure 7 is a flow chart of the process of SSD entering emergency mode according to still another embodiment of the application. DETAILED DESCRIPTION

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

[0023] Embodiment one

[0024] Figure 1 is a flow chart of the process of SSD firmware instruction. In the figure, the execution of an instruction first translates the context, distributes to a specific core, then takes metadata and submits a calculation request, verifies the calculation result after the calculation is completed, and finally checks the state of the exception register.

[0025] Before the panic mode (emergency mode) of the application is designed, if the firmware runs abnormally, the register state of the controller of the SSD will be lost completely, and the abnormal situation can only be determined by checking the static log, and the log generally only records the state of the register fault according to experience setting, rather than the state of all registers. Based on this, the panic mode (emergency mode) is designed, and the controller register state and other information of the host memory cache (such as Telemetry data area 2) can be saved to the NAND of the SSD; the storage device is restarted, and the Telemetry data area 2 is reloaded, so that all register states can be seen.

[0026] Among them, telemetry (Telemetry) is NVMExpress TMBaseSpecification (e.g. available from https: / / nvmexpress.org / wp-content / uploads / NVM-Express-Base-Specification-2_0-2021.06.02-Ratified-5.pdf) defines an error log collection standard interface to collect SSD vendor custom data logs, a user issues a standard NVMe command to obtain the required logs, and then sends the collected logs to the SSD vendor for further log analysis. Reduces or saves the possibility of removing the SSD from the deployed system for log collection, effectively reduces on-site debugging time, and improves user operation and maintenance efficiency. Telemetry function defines the mechanism for collecting SSD vendor custom logs, and Telemetry data collection can be Host-Initiated or Controller-Initiated. The former is Host-Initiated to obtain some key information of the SSD, and the latter is Controller-Initiated to obtain important data, and the data content and format are defined by the SSD vendor.

[0027] Figure 2 is a schematic diagram of the data structure of the Host-Initiated Telemetry log. The data structure of the Host-Initiated Telemetry log is similar to that of the Controller-Initiated Telemetry log. The present application designs different triggering methods and log structures that need to be recorded when the SSD firmware kernel exception or fatal error, non-kernel exception or non-fatal error occurs. Each Telemetry log is composed of a group of individual Telemetry data blocks, each Telemetry data block is 512 bytes in size, and the Telemetry log is returned in units of Telemetry data blocks. The Telemetry data block is the smallest unit of the Telemetry log.

[0028] The NVMe Spec (NVMe specification) defines a standard TelemetryHeader information, Block0 is a log Header part, including Byte#0~511, 511:384Reason Identifier part belongs to a vendor self-defined field. Block1…k is a Telemetry data area, each Telemetry data log is divided into three Telemetry data areas, namely Area1, Area2 and Area3, the latter all contain the former, and all Telemetry data areas start from Telemetry Area1. A Telemetry log contains at most three consecutive data areas:

[0029] Data Area1 (Data Area1): the first stage, the problem category is determined by collecting the smallest and most critical data set.

[0030] Data Area2 (Data Area2): the second stage, a more in-depth medium-sized effective data set is collected and analyzed to determine the source of the problem.

[0031] Data Area3 (Data Area3): the third stage, which can be used to collect the largest and most complete data set to diagnose the problem.

[0032] From the firmware point of view, the SSD firmware includes a front-end component and a back-end component. The front-end component includes a PCIe module, an Admin module, and a data management module, which are used to process PCIe physical layer events, execute NVMe management instructions, manage data processing read / write requests, and convert front-end read requests into back-end available commands; the back-end component includes NAND management related modules, including log records for updating FTL, facilitating FTL reconstruction, such as complete recovery of data after abnormal power failure; including garbage collection function, ensuring sufficient valid space, including functions of scheduling read, write and erase instructions according to different priorities, etc. The front-end component and the back-end component are separated in the present application, the SSD initialization is independent of the back-end, the command is completed directly in the front-end, and the completion response is directly returned to the host end, without the participation of the back-end.

[0033] Since the back-end component modifies NAND data when working, by distinguishing the front-end component and the back-end component, only the front-end component is run without the back-end component in the PanicMode according to the embodiment of the present application to avoid the NAND data from being damaged, but the ability to process NVMe commands or other commands of the host is retained. At this time, since there is no service provided by the back-end component, the front-end component may not be able to correctly process the host command, but can report an error to the host as the processing result of the host command.

[0034] From the program point of view, the SSD firmware in panic mode supports the following functions:

[0035] 1. By processing the identify command sent by the host, the host can identify the NVMe device.

[0036] 2. Process the IO command issued by the host, although it cannot correctly process the IO command, prevent the host from crashing by returning an error status code.

[0037] 3. Report one or more asynchronous events (Asynchronous Event Request, AER) to the host, which is used to notify the host of the running status of the SSD when these events occur, including error and running health information (status, error, and health information), and the host monitoring software can make early warning response according to the returned state.

[0038] 4. If the SSD firmware fails, support firmware upgrade function, repair the problem by upgrading the firmware.

[0039] 5. In panic mode, the device can still retain the error state information before entering panic mode after power failure and restart.

[0040] 6. Elog enters read-only state to prevent important key information from being overwritten or damaged, and improve fault location and problem debugging and repair efficiency. Elog, the abbreviation of Event log, is the event name on the information processing device log, which records the time of the information processing device switching on and off, and is used to find system faults. Event log includes critical and general generic logs.

[0041] 7. Support controller reset, better compatibility with different hosts, prevent SSD from restarting some hosts that send controller reset because SSD does not support reset, and give users a better error handling experience. Reset will delete all IO submission and completion queues, and reset management submission and completion queues.

[0042] 8. In order to protect the fault scene, the background scanning service of the device will be stopped to ensure that the user data is in a "frozen" state.

[0043] 9. The device can be recovered by sending NVMe Format command to reformat, which greatly improves the efficient operation and maintenance of batch deployment of SSD in data center.

[0044] Figure 3Figure 1 is a flow chart of the process of SSD firmware error handling. When the firmware has an error, the SSD automatically enters panic mode after a power cycle or when error injection is performed by sending a custom command. When an error occurs, the SSD records the on-site and debugging information at the time of the error and records it in the Telemetry data area. After the SSD enters panic mode, the host can obtain complete Telemetry log debugging information from the Telemetry data in the SSD using standard NVMe Telemetry commands, and use NVMe Format or other initialization methods to process so that the SSD returns to normal. Among them, the firmware error trigger conditions include: trigger condition 1, firmware exception or assertion during operation, metadata corruption caused by memory DBE (Double Bit Error) and other errors; trigger condition 2, APL (Abrupt Power Loss) protection failure.

[0045] Figure 4 Figure 2 is a flow chart of the process of the SSD automatically entering panic mode after a cold start. Specifically, it includes:

[0046] When the firmware has an exception or assertion during operation, that is, when trigger condition 1 is met, the SSD will flush the error log in the host memory to the Telemetry data area 2 of the NAND, and save the backup Super Page to the NAND (here the firmware reads the backup Super Page by automatically searching the relevant NAND area). The backup Super Page can provide complete debugging information at the last failure. Then the firmware stops running (Halt), and ensures that the complete Superpage will not be saved to the NAND before the power is off. The firmware stops running, which also ensures that no new data will overwrite the log or other data on the NAND. In the case of firmware stop running, it also does not respond to the host's command, so that the host can detect that the SSD has failed.

[0047] When the firmware has an exception or assertion during operation, that is, when trigger condition 1 is met, the SSD will flush the error log in the host memory to the Telemetry data area 2 of the NAND, and save the backup Super Page to the NAND (here the firmware reads the backup Super Page by automatically searching the relevant NAND area). The backup Super Page can provide complete debugging information at the last failure. Then the firmware stops running (Halt), and ensures that the complete Superpage will not be saved to the NAND before the power is off. The firmware stops running, which also ensures that no new data will overwrite the log or other data on the NAND. In the case of firmware stop running, it also does not respond to the host's command, so that the host can detect that the SSD has failed.

[0048] When the SSD is cold rebooted (the cold reboot can occur after the SSD fails or can be instructed by the user during the normal operation of the SSD), if the firmware is running normally (i.e., enters the normal mode), a complete Super Page is required, which contains the complete metadata information required by the firmware. If there is no complete Super Page, the firmware enters the Panic Mode. Thus, after the SSD is rebooted, whether to enter the Panic Mode is identified by whether the complete Super Page can be acquired. If the complete Super Page can be acquired, the SSD starts to enter the normal mode, otherwise, the Panic Mode is entered. After entering the Panic Mode, there are two cases, one is to find a backup Super Page, and the other is to create a default Super Page, which does not contain any debugging information.

[0049] After entering the Panic Mode, in order to protect the fault scene, the back-end components are frozen, so that the back-end components do not work, for example, the device background scanning service is stopped, and it is ensured that the user data is in a "frozen" state.

[0050] In the Panic Mode, the front-end components are enabled to work to respond to the commands of the host. After the NVMe device is initialized, if the asynchronous event (Asynchronous Event Request, AER) function is enabled, the SSD reports one or more asynchronous events to the host, which is used to notify the host of the running state of the SSD when the events occur.

[0051] In the Panic Mode, the host IO command is still allowed to be issued, and the working front-end components respond to the host IO command and simply process, for example, an error status code is returned to prevent the host from being down (SCT, Status Code Type, indicates the type of status code returned by the controller; SC, Status Code, indicates any error or status information of the indicated command).

[0052] In the Panic Mode, for the NVMe management command (Admin Command), the front-end components can process it without depending on the back-end components, so that most of the management commands can be processed normally or the processing result reflecting the actual situation is given.

[0053] In Panic Mode, the front-end component fetches the corresponding log from the NAND when processing a Get Log Page NVMe command issued by the host. The front-end component retains the ability to read log data from the NAND and provide it to the host. When the Get Log command is to access a Telemetry log, the front-end component fetches the error log recorded in the NAND at the time of the error (e.g., from Telemetry data area 2) and provides it as a response to the Get Log command.

[0054] In Panic Mode, the front-end component processes firmware upgrade, format, and other commands. The existing firmware is replaced by a firmware upgrade to eliminate the error. The existing user data on the SSD is cleared by the format command so that a complete Superpage is no longer needed. Since a complete Superpage is no longer needed, the next time the SSD is powered on, it does not need to enter Panic Mode and starts normally.

[0055] Figure 5 is a flowchart of an SSD entering Panic Mode according to yet another embodiment of the application.

[0056] As yet another embodiment, when an exception occurs or an assertion is made by a processor core of the controller of the SSD, it is recognized that a trigger condition 1 has occurred. In response, the error log needed for future debugging is saved in a designated area of the NAND, such as the data area 2 of Telemetry. Also, a Panic flag is set, and the Panic flag set is non-volatile so that the Panic flag can be discovered after a cold reboot of the SSD. The Panic flag can be, for example, flag data recorded on the NVM chip, or a backup Superpage as used in the embodiment of Figure 4 of the application. Subsequently, the firmware of the SSD no longer runs (is paused). The paused firmware does not respond to host commands and no longer updates the NAND to avoid corrupting data recorded in the SSD.

[0057] For an SSD that does not respond to the host, the user's usual practice is to reboot the SSD. After the SSD is rebooted, it is checked whether there is a Panic flag. If not, it enters normal mode. If there is a Panic flag, the SSD enters Panic mode, in which the back-end components are frozen and only the front-end components are run. The front-end components respond to various commands from the host. Thus, the SSD appears to be visible or accessible to the host because the SSD can respond to host commands in Panic mode. The host can discover that the SSD always fails to process IO commands, or it can identify that the SSD is in Panic mode through AER, at which point the host can obtain the Telemetry data area through the GetLog Page command to obtain the error log when the SSD had an error to analyze the cause of the error.

[0058] In Panic mode, the front-end components can receive and process firmware update or firmware upgrade commands from the host to replace the faulty firmware to fix the SSD.

[0059] Figure 6 is a flowchart of an SSD entering emergency mode according to yet another embodiment of the present application.

[0060] As one embodiment, when the SSD has an abnormal power down and fails to complete the power down process within a specified time, it is identified that trigger condition 2 has occurred. In response, a Panic flag is set. Subsequently, the SSD is powered off as the power is depleted.

[0061] After the SSD is rebooted, it is checked whether there is a Panic flag. If not, it enters normal mode. If there is a Panic flag, the SSD enters Panic mode, in which the back-end components are frozen and only the front-end components are run. The front-end components respond to various commands from the host.

[0062] Figure 7 is a flowchart of an SSD entering emergency mode according to yet another embodiment of the present application.

[0063] As yet another embodiment, when the processor core of the controller of the SSD has an exception or asserts, i.e., it is identified that trigger condition 1 has occurred, in response, the error log needed for future debugging is saved in a specified area of the NAND, such as the data area 2 of the Telemetry. Also, a Panic flag is set, and the Panic flag set is non-volatile so that it can be found after the SSD is cold rebooted. The Panic flag can be, for example, flag data recorded on the NVM chip, or it can be, for example, a flag in the NVM chip. Figure 4the backup Superpage used in the embodiments above instead of the full Superpage. Subsequently, the firmware of the SSD stops running (pauses). The paused firmware does not respond to host commands nor does it update the NAND to avoid corrupting the data recorded in the SSD.

[0064] In addition, when the SSD is abnormally powered down and fails to complete the power down process within a specified time, it is identified that the trigger condition 2 has occurred. In response, the Panic flag is set. Subsequently, as the power is depleted, the SSD is shut down.

[0065] After the SSD is restarted, it is checked whether the Panic flag exists. If not, it enters the normal mode. If the Panic flag exists, the SSD enters the Panic mode and accordingly freezes the back-end components while only running the front-end components. And the front-end components respond to various commands from the host.

[0066] The above detailed description of the specific embodiments has further detailed the purposes, technical solutions and beneficial effects of the present application. It should be understood that the above detailed description is only a specific embodiment of the present application and is not used to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made on the basis of the technical solutions of the present application should be included in the protection scope of the present application.

Claims

1. A method for entering an emergency mode of an SSD and being visible to a host, characterized in that, The firmware of the SSD is separated into a front-end component and a back-end component, the front-end component is used to respond to host commands, and the back-end component is used to manage NAND; the method comprises: When the SSD operation fails, whether the emergency mode is entered is identified by whether a complete Super Page can be acquired after the SSD is restarted; If there is no complete Super Page, the emergency mode is entered, in the emergency mode, the back-end component is frozen to ensure that user data is in a frozen state, only the front-end component is run, the front-end component processes the command sent by the host to the SSD to enable the host end to identify the SSD, and the front-end component responds to the IO instruction issued by the host, returns an error status code as the processing result of the IO command to prevent the host from being down.

2. The method of claim 1, wherein, The front-end component comprises a PCIe module, an Admin module and a data management module, is used to process PCIe physical layer events, execute NVMe management instructions, manage data processing read / write requests, convert front-end read requests into back-end available microcode; the back-end component comprises a NAND management related module, comprises a log record for updating an FTL, facilitates FTL reconstruction, is used for complete data recovery after abnormal power failure, comprises a garbage collection function, and comprises a function of scheduling read, write and erase instructions according to different priorities.

3. The method of claim 1, wherein, In the emergency mode, the front-end component of the SSD firmware reports one or more asynchronous events to the host end, which is used to notify the host end of the running state of the SSD when these events occur, including error and running health status information.

4. The method of claim 1, wherein, In the emergency mode, the front-end component supports the upgrade function of the SSD firmware, and the problem is repaired by upgrading the firmware.

5. The method of claim 1, wherein, In the emergency mode, the Elog enters a read-only state, so that important key information is not covered or damaged.

6. The method of claim 1, wherein, In the emergency mode, the front-end component deletes all IO submission and completion queues in response to receiving a controller reset command, resets the management submission queue and the completion queue to be compatible with different hosts.

7. The method of claim 1, wherein, In the emergency mode, the front-end component responds to the NVMe formatting command, clears the emergency mode flag, and enables the SSD to enter the normal mode.

8. A solid state storage device comprising a memory, a controller and a non-volatile memory, wherein, The controller executes the method of any one of claims 1-7.

Images