Solid-state drive fault handling method and device, product and medium

Abstract

The present application relates to the technical field of storage. Disclosed are a solid-state drive fault handling method and device, a product and a medium. A solution comprises: monitoring the operating state of a solid-state drive; when determining that a fault has occurred in the solid-state drive, determining a fault type of the faulty solid-state drive and executing a corresponding fault handling strategy; at the same time, actively sending corresponding feedback information to a host, so that the host determines, on the basis of the received feedback information, the number of input / output request errors corresponding to the faulty solid-state drive; and, when the host determines that the number of input / output request errors exceeds a first threshold, the host marking the faulty solid-state drive as being in a faulty state, and removing the faulty solid-state drive from a redundant array of independent disks. Thus, a host system can execute disk removal without waiting for timeout of an input / output command or a management command for solid-state drives and undergoing prolonged timeout processing, thereby greatly improving the speed in identifying and removing faulty solid-state drives, and effectively reducing the maintenance cost of redundant arrays of independent disks.

Description

A method, product, device and medium for handling solid-state drive failures

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411207161.8, filed on August 30, 2024, entitled "A method, product, device and medium for handling solid-state drive failures", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of storage technology, and in particular to a method, product, device and medium for handling solid-state drive (SSD) failures. Background Technology

[0004] The solid-state drive (SSD) controller is the core hardware that manages the data storage and retrieval of an SSD. It supports multiple hardware units to achieve a balance between complex functionality and performance. However, due to the complexity of the SSD's internal design, its stability may not be as good as that of a hard disk drive (HDD).

[0005] To ensure SSD reliability, a common approach is to use a dedicated storage server or general-purpose server with a Redundant Array of Independent Disks (RAID). When an SSD fails, such as due to firmware logic errors, hardware unit failures, or software-induced Central Processing Unit (CPU) core dumps, the SSD is typically placed in read-only mode or allowed to be ejected by the host system. However, when a failure occurs, the host system must wait for input / output commands or management commands to the SSD to time out before ejecting it from the Linux system. This process can be lengthy and impacts business stability. Summary of the Invention

[0006] The purpose of this application is to provide a solid-state drive (SSD) failure handling method, product, device, and medium to solve the problem that when an SSD fails, the host system needs a long time to detect and handle the failure, which affects business stability.

[0007] To address the aforementioned technical problems, this application provides a solid-state drive (SSD) fault handling method applied to a redundant independent disk array (DISA); the method includes:

[0008] Monitor the operating status of the solid-state drive (SSD) to determine if it has malfunctioned.

[0009] If the solid-state drive (SSD) is confirmed to be faulty, determine the type of fault.

[0010] Based on the fault type of the faulty SSD, the corresponding fault handling strategy is executed, and feedback information corresponding to the fault handling strategy is sent to the host. This allows the host to determine the number of input / output request errors corresponding to the faulty SSD based on the received feedback information, and to determine whether the number of received input / output request errors exceeds a first threshold. If the host confirms that the number of input / output request errors does not exceed the first threshold, the host continues to monitor the number of received input / output request errors. If the host confirms that the number of input / output request errors exceeds the first threshold, the host marks the faulty SSD as faulty and removes the faulty SSD from the independent disk redundancy array.

[0011] On the one hand, when the failure type of the faulty solid-state drive is a storage media error, the corresponding fault handling strategy is executed according to the fault type of the faulty solid-state drive, and feedback information corresponding to the fault handling strategy is sent to the host, including:

[0012] Set the faulty SSD to read-only mode using the SSD firmware;

[0013] When a faulty solid-state drive receives a write operation request from the host, it sends an input / output request error feedback message to the host.

[0014] On the other hand, when the failure type of the faulty solid-state drive is a software logic error based on input / output command paths, the corresponding fault handling strategy is executed according to the fault type of the faulty solid-state drive, and feedback information corresponding to the fault handling strategy is sent to the host, including:

[0015] Identify the faulty disk management module that caused the failure in the faulty solid-state drive;

[0016] Set the multicast assertion flag for the faulty disk management module;

[0017] When other disk management modules in the failed solid-state drive detect the multicast assertion flag of the failed disk management module, the target disk management module is selected from the remaining disk management modules.

[0018] The target disk management module processes the input / output requests of the faulty disk management module and sends the corresponding feedback information to the host.

[0019] On the other hand, before identifying the faulty disk management module that caused the failure in the faulty solid-state drive, the following is also included:

[0020] Set the priority of all disk management modules in the failed solid-state drive;

[0021] Correspondingly, select the target disk management module from the remaining disk management modules, including:

[0022] Obtain the priority of each disk management module except the faulty disk management module;

[0023] Select the disk management module with the highest priority as the target disk management module.

[0024] On the other hand, the target disk management module processes the input / output requests of the faulty disk management module and sends corresponding feedback information to the host, including:

[0025] The target disk management module selects the current cache from the caches of the faulty disk management module and obtains the input / output command state machine structure of the current cache.

[0026] Determine whether the input / output request in the current cache has returned completion information to the host based on the input / output command state machine structure;

[0027] If it is confirmed that no completion information has been returned to the host, then the target disk management module sends feedback information about the input / output request error corresponding to the current cache to the host;

[0028] If the completion information is confirmed to be returned to the host, the target disk management module selects the next cache from the remaining cache of the faulty disk management module as the current cache, and enters the step of obtaining the input and output command state machine structure of the current cache, until all caches of the faulty disk management module have been traversed.

[0029] On the other hand, when the failure type of the faulty solid-state drive is a software logic error based on the management command path, the corresponding fault handling strategy is executed according to the fault type of the faulty solid-state drive, and feedback information corresponding to the fault handling strategy is sent to the host, including:

[0030] Set the asynchronous assertion flag for the failed solid-state drive;

[0031] When the disk management cores of the faulty solid-state drive process the host's input / output requests, they send feedback information about the input / output request error to the host according to the asynchronous assertion flag;

[0032] The disk management core is the central processing unit that runs the disk management module in the solid-state drive and is used to handle input / output requests.

[0033] On the other hand, when the fault type of the failed solid-state drive is a hardware unit error based on the input / output command path or a hardware unit error based on the management command path, the corresponding fault handling strategy is executed according to the fault type of the failed solid-state drive, and feedback information corresponding to the fault handling strategy is sent to the host, including:

[0034] Set the hardware unit error flag for the faulty solid-state drive;

[0035] When the disk management cores of the faulty solid-state drive process the host's input / output requests, they send feedback information about the input / output request error to the host based on the hardware unit error flag.

[0036] The disk management core is the central processing unit that runs the disk management module in the solid-state drive and is used to process input / output requests.

[0037] On the other hand, when the fault type of the faulty solid-state drive is a solid-state drive controller failure, it also includes:

[0038] By monitoring the processing time of input / output requests and / or management requests of the faulty solid-state drive on the host, it can be determined whether the processing time of input / output requests and / or management requests exceeds the corresponding time threshold.

[0039] If the host confirms that the processing time of input / output requests and / or the processing time of management requests exceeds the corresponding time threshold, the host will mark the faulty SSD as faulty and remove the faulty SSD from the independent disk redundancy array.

[0040] On the other hand, it also includes:

[0041] The host uses non-volatile memory to drive the setting information of the critical fault status in the status register of the monitoring controller, and determines whether the critical fault status is set based on the setting information.

[0042] If the critical failure status is set, the failed solid-state drive will be removed from the independent disk redundancy array after the command termination timeout period via the non-volatile memory driver.

[0043] On the other hand, it also includes:

[0044] By monitoring the setting information of key warning fields in the host self-monitoring analysis report technical log, and determining whether the key warning fields are set based on the setting information;

[0045] If the critical warning field is set, the error type and severity of the faulty SSD are obtained;

[0046] The faulty SSD is removed from the independent disk redundancy array based on the type and severity of the error.

[0047] On the other hand, after the host removes the faulty solid-state drive from the independent redundant disk array based on the feedback information, it also includes:

[0048] Obtain the time of failure of the faulty SSD, detailed information about the faulty SSD, the cause of the failure, and the steps to remove the faulty SSD;

[0049] A removal log for the faulty SSD is generated based on the time of the failure, detailed information about the faulty SSD, the cause of the failure, and the steps to remove the faulty SSD.

[0050] To address the aforementioned technical problems, this application also provides another solid-state drive (SSD) failure handling method, applied to a host computer; the method includes:

[0051] Receive feedback information sent by the independent disk redundancy array; wherein, the feedback information is the feedback information of the corresponding link of the fault handling strategy when the faulty solid-state drive fails, according to the fault type of the faulty solid-state drive.

[0052] Determine the number of input / output request errors corresponding to the faulty solid-state drive based on the received feedback information;

[0053] Determine if the number of input / output request errors exceeds a first threshold;

[0054] If it is confirmed that the number of input / output request errors has not exceeded the first threshold, then continue to monitor the number of received input / output request errors and return to the step of determining the number of input / output request errors corresponding to the faulty solid-state drive based on the received feedback information;

[0055] If the number of input / output request errors exceeds the first threshold, the faulty SSD is marked as faulty and removed from the independent disk redundancy array.

[0056] To address the aforementioned technical problems, this application also provides a computer program product, including a computer program or instructions, which, when executed by a processor, represent the steps of the aforementioned solid-state drive fault handling method.

[0057] To address the aforementioned technical problems, this application also provides a solid-state drive (SSD) fault handling device, comprising:

[0058] Memory, used to store computer programs;

[0059] The processor is used to implement the steps of the above-described solid-state drive fault handling method when executing computer programs.

[0060] To address the aforementioned technical problems, this application also provides a computer non-volatile readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the aforementioned solid-state drive fault handling method.

[0061] The solid-state drive (SSD) failure handling method provided in this application is applied to a redundant array of independent disks (RAID). Specifically, it monitors the operating status of the SSD to determine if it has failed. If a failure is confirmed, the failure type of the SSD is determined. A corresponding failure handling strategy is executed based on the failure type, and feedback information corresponding to the failure handling strategy is sent to the host. This allows the host to determine the number of input / output request errors (I / O requests) corresponding to the failed SSD based on the received feedback information, and to determine whether the number of received I / O requests exceeds a first threshold. If the host confirms that the number of I / O requests does not exceed the first threshold, the host continues to monitor the number of received I / O requests. If the host confirms that the number of I / O requests exceeds the first threshold, the host marks the failed SSD as faulty and removes it from the RAID.

[0062] The beneficial effects of this application are as follows: by monitoring the operating status of the solid-state drive (SSD), when a fault is confirmed, the fault type of the faulty SSD is determined and the corresponding fault handling strategy is executed; simultaneously, corresponding feedback information is actively sent to the host, so that the host can determine the number of input / output request errors corresponding to the faulty SSD based on the received feedback information; when the host confirms that the number of input / output request errors exceeds a first threshold, the faulty SSD is marked as faulty and removed from the independent disk redundancy array. This eliminates the need for the host system to wait for input / output commands or management commands to the SSD to time out and then undergo a lengthy timeout process before removing the SSD, greatly improving the speed of faulty SSD identification and removal. It effectively reduces the maintenance cost of the independent disk redundancy array and improves its utilization efficiency.

[0063] On the other hand, this solution specifically sets the faulty SSD to read-only mode through SSD firmware. When the faulty SSD receives a write operation request from the host, it sends input / output request error feedback information to the host, thus implementing the fault handling strategy and sending feedback information under storage media errors. The solution identifies the faulty disk management module within the faulty SSD; sets the multicast assertion flag for the faulty disk management module; when other disk management modules in the faulty SSD detect the multicast assertion flag, a target disk management module is selected from the remaining disk management modules; the target disk management module processes the input / output requests of the faulty disk management module and sends corresponding feedback information to the host, thus implementing the fault handling strategy and sending feedback information under software logic errors based on input / output command paths. The solution also sets an asynchronous assertion flag for the faulty SSD; when each disk management core of the faulty SSD processes the host's input / output requests, it sends input / output request error feedback information to the host according to the asynchronous assertion flag, thus implementing the fault handling strategy and sending feedback information under software logic errors based on management command paths. Sets a hardware unit error flag for the faulty SSD; when each disk management core of the faulty SSD processes the host's input / output requests, it sends feedback information about the input / output request error to the host based on the hardware unit error flag; implements the execution of fault handling strategies and the sending of feedback information under hardware unit errors based on input / output command paths or hardware unit errors based on management command paths.

[0064] In addition, this application also provides a solid-state drive fault handling device, a computer product, and a medium, with the same effect as above. Attached Figure Description

[0065] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0066] Figure 1 is a flowchart of a solid-state drive fault handling method provided in an embodiment of this application;

[0067] Figure 2 is a flowchart of another solid-state drive fault handling method provided in an embodiment of this application;

[0068] Figure 3 is a schematic diagram of a solid-state drive fault handling device provided in an embodiment of this application;

[0069] Figure 4 is a schematic diagram of another solid-state drive fault handling device provided in an embodiment of this application;

[0070] Figure 5 is a schematic diagram of a solid-state drive fault handling device provided in an embodiment of this application. Detailed Implementation

[0071] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0072] The core of this application is to provide a solid-state drive (SSD) failure handling method, product, device, and medium to solve the problem that when an SSD fails, the host system needs a long time to detect and handle the failure, which affects business stability.

[0073] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0074] The SSD controller, as the core hardware, is responsible for managing the storage and retrieval of data on the solid-state drive (SSD). It supports multiple hardware units to achieve a balance between complex functions and performance, including XOR units, memory management units, and flash interface units. However, due to the complex internal design of SSDs, their stability may not be as good as that of mechanical hard drives (HDDs). To ensure SSD reliability, a professional high-end storage server or a general-purpose server with software RAID is typically used. When an SSD fails, such as due to firmware logic errors, hardware unit failures, or software-induced CPU core dumps, the SSD is often placed in read-only mode or waits for the host system to evict the failed drive. However, when a failure occurs, such as a hardware unit failure or an internal firmware error, the host system detects input / output (IO) timeouts and performs retries and controller resets, resulting in excessively long times for evicting the failed drive. Therefore, to solve the above problems, this application provides a solid-state drive failure handling method. It should be noted that the method provided in this application applies to RAID.

[0075] Figure 1 is a flowchart of a solid-state drive (SSD) fault handling method provided in an embodiment of this application. As shown in Figure 1, the method includes:

[0076] S10: Monitor the operating status of the solid-state drive (SSD) and determine if the SSD has malfunctioned; if the SSD has malfunctioned, proceed to step S11.

[0077] In practical implementation, the first step is to monitor the SSD's operating status to determine if it has malfunctioned. This embodiment does not limit the specific methods used to determine SSD malfunction. For example, check the SSD's firmware version and status to ensure it is the latest version and check its status; some SSDs offer firmware update tools or status checking tools, which can be used to check the firmware status. Monitor the SSD's temperature; SSDs generate heat during normal operation, but excessively high temperatures can lead to performance degradation or malfunction; tools can be used to monitor the SSD's temperature. Check the SSD's read / write error rate; this is a crucial indicator of its health, and a sudden increase in the error rate may be a sign of SSD malfunction. Check the SSD's lifespan; performance degradation or malfunction may occur when it approaches or exceeds its design lifespan. Check for bad blocks; bad blocks in an SSD are data blocks that cannot be read or written normally, and an excessive number of bad blocks can lead to performance degradation or malfunction. Also check the SSD's interface and connections to ensure they are secure and not loose or damaged. If an SSD failure is confirmed, proceed to step S11; if no SSD failure is confirmed, return to continue monitoring the SSD's operating status.

[0078] S11: Determine the type of failure of the faulty solid-state drive.

[0079] The fault types include at least storage media errors, software logic errors based on input / output command paths, software logic errors based on management command paths, hardware unit errors based on input / output command paths, and hardware unit errors based on management command paths.

[0080] After confirming an SSD failure, it is necessary to determine the type of failure. It is worth noting that in this embodiment, the SSD failure type should at least include storage media errors, software logic errors based on I / O command paths, software logic errors based on administrative (admin) command paths, hardware unit errors based on I / O command paths, and hardware unit errors based on administrative (admin) command paths. The following provides a detailed explanation of each of these error types:

[0081] Storage media errors refer to faults or problems related to the storage media detected by the SSD's firmware during operation, such as NAND flash memory errors and electrically erasable programmable read-only memory (EEPROM) errors. These errors may include: bad block errors: data blocks in the storage media that cannot be read or written normally, which may be caused by manufacturing defects, wear and tear, or data corruption; read / write errors: data reading or writing failures due to various reasons (such as interference, voltage fluctuations, etc.) during read / write operations on the storage media; error checking and correction (ECC): SSDs use ECC technology to detect and correct errors in the data, but if the number of errors exceeds the ECC's correction capability, it will result in an ECC error; wear level: storage media has a certain lifespan. When a block reaches a certain threshold of erase / write cycles, it may be marked as worn, thus affecting the SSD's performance and reliability.

[0082] Software logic errors based on the I / O command path refer to errors caused by software logic problems during the I / O command processing of an SSD. These errors can occur in the SSD's firmware, drivers, or operating system, and specifically include the following: Firmware logic errors: Logical errors in the SSD firmware may lead to incorrect command processing, such as incorrectly mapping logical block addresses to physical block addresses, or incorrectly handling ECC checks of data; Driver errors: SSD drivers in the operating system may contain logical errors, such as incorrectly parsing or processing I / O commands from the host, or incorrectly communicating with the SSD firmware; Operating system errors: Logical errors may exist in the file system or block device layer of the operating system, such as incorrectly handling file system metadata or data block mapping relationships. The occurrence of software logic errors based on the I / O command path triggers an assertion (ASSERT), ultimately causing the SSD's CPU to become unresponsive.

[0083] Software logic errors based on the admin command path are errors caused by software logic problems during the processing of admin commands on the SSD. These errors can occur in the SSD's firmware, drivers, or operating system, and specifically include the following: Firmware logic errors: Logical errors in the SSD firmware may cause incorrect processing of admin commands, such as incorrectly parsing or executing admin commands, or incorrectly handling command parameters and return values; Driver errors: SSD drivers in the operating system may contain logical errors, such as incorrectly parsing or processing admin commands from the host, or incorrectly communicating with the SSD firmware; Operating system errors: SSD management software or tools in the operating system may contain logical errors, such as incorrectly calling or processing admin commands, or incorrectly parsing command output. Software logic errors based on the admin command path will also trigger ASSERT, ultimately causing the SSD's CPU to become unresponsive.

[0084] Hardware unit errors based on the I / O command path are errors caused by hardware unit failures during SSD I / O command processing. These errors can occur in multiple hardware units within the SSD, specifically including the following: NAND Flash errors: If the NAND Flash has bad blocks, wear, or read / write errors, data may not be read or written correctly; Controller errors: The SSD controller manages and controls data read and write operations. If the controller fails, such as with register errors, clock errors, or data bus errors, command processing may fail; Cache errors: The cache in the SSD is used for temporary data storage. If the cache fails, such as with data loss, corruption, or access errors, data inconsistency or loss may occur; Interface errors: If the interface between the SSD and the host fails, such as with signal loss, signal interference, or connection errors, commands may not be transmitted or received correctly. These hardware unit errors may cause the SSD to fail to execute I / O commands correctly, thus affecting data read / write performance or data integrity.

[0085] Hardware unit errors based on the admin command path refer to errors caused by hardware unit failures during the processing of admin commands on the SSD. These errors can occur in multiple hardware units within the SSD, specifically including the following: Controller errors: The SSD controller is responsible for managing and controlling the execution of admin commands. If the controller fails, such as due to register errors, state machine errors, or control logic errors, the admin command may fail to execute correctly. Interface errors: If the interface between the SSD and the host fails, such as due to signal loss, signal interference, or connection errors, the admin command may fail to be transmitted or received correctly. Cache errors: The cache in the SSD is used to temporarily store the parameters and results of admin commands. If the cache fails, such as due to data loss, data corruption, or access errors, the admin command may fail to execute or produce incorrect results. Power management unit errors: The SSD's power management unit is responsible for providing a stable power supply to the SSD. If the power management unit fails, such as due to abnormal voltage, abnormal current, or power switch errors, the admin command execution may be interrupted or fail. These hardware unit errors may prevent the SSD from correctly executing admin commands, thus affecting the SSD's management functions or system configuration. In severe cases, these errors may lead to SSD failure or data loss.

[0086] S12: Execute the corresponding fault handling strategy according to the fault type of the faulty solid-state drive, and send feedback information corresponding to the fault handling strategy to the host, so that the host can determine the number of input / output request errors corresponding to the faulty solid-state drive based on the received feedback information, and determine whether the number of received input / output request errors exceeds the first threshold; if the host confirms that the number of input / output request errors does not exceed the first threshold, the host continues to monitor the number of received input / output request errors; if the host confirms that the number of input / output request errors exceeds the first threshold, the host marks the faulty solid-state drive as faulty and removes the faulty solid-state drive from the independent disk redundancy array.

[0087] After determining the fault type of the faulty SSD, a corresponding fault handling strategy needs to be executed to address the issue. Simultaneously, feedback information corresponding to the execution phase of the fault handling strategy needs to be sent to the host. This embodiment does not restrict the specific process of executing the corresponding fault handling strategy based on the fault type of the SSD and sending feedback information to the host corresponding to the fault handling strategy's execution phase.

[0088] After receiving feedback information about IO request errors from a faulty SSD, the host can determine the number of IO request errors corresponding to the faulty SSD based on the feedback information and judge whether the number of received IO request errors exceeds a first threshold. In this embodiment, the first threshold is not limited and depends on the specific implementation. If the host confirms that the number of IO request errors does not exceed the first threshold, the host continues to monitor the number of received IO request errors; if the host confirms that the number of IO request errors exceeds the first threshold, the host marks the faulty SSD as faulty and removes the faulty SSD from the independent disk redundancy array. This achieves the removal of the faulty SSD.

[0089] In this embodiment, by monitoring the operating status of the solid-state drive (SSD), when a fault is confirmed, the fault type of the faulty SSD is determined and the corresponding fault handling strategy is executed. Simultaneously, corresponding feedback information is actively sent to the host, allowing the host to determine the number of input / output request errors corresponding to the faulty SSD based on the received feedback. When the host confirms that the number of input / output request errors exceeds a first threshold, the faulty SSD is marked as faulty and removed from the independent disk redundancy array. This eliminates the need for the host system to wait for input / output commands or management commands to the SSD to time out and then undergo a lengthy timeout process before removing the SSD, significantly improving the speed of faulty SSD identification and removal. This effectively reduces the maintenance cost of the independent disk redundancy array and improves its utilization efficiency.

[0090] Based on the above embodiments, in some embodiments, when the failure type of the faulty solid-state drive is a storage media error, a corresponding fault handling strategy is executed according to the fault type of the faulty solid-state drive, and feedback information corresponding to the fault handling strategy is sent to the host, including:

[0091] S120: Set the faulty SSD to read-only mode via SSD firmware;

[0092] S121: When a faulty solid-state drive receives a write operation request from the host, it sends an input / output request error feedback message to the host.

[0093] When the failure type of the SSD is confirmed to be a storage media error, the corresponding failure handling strategy is executed. Specifically, the SSD firmware is used to set the failed SSD to read-only mode. When the failed SSD receives a write operation request from the host again, it cannot process the host's write operation request because it is currently in read-only mode. At this time, an input / output request error feedback message is sent to the host so that the host can remove the failed SSD from the independent disk redundancy array based on the feedback information.

[0094] In this embodiment, the faulty SSD is set to read-only mode through the SSD firmware; when the faulty SSD receives a write operation request from the host, it sends input / output request error feedback information to the host, thereby realizing the execution of the fault handling strategy and the sending of feedback information under storage medium error.

[0095] Based on the above embodiments, in some embodiments, when the failure type of the faulty solid-state drive is a software logic error based on input / output command paths, a corresponding fault handling strategy is executed according to the fault type of the faulty solid-state drive, and feedback information corresponding to the fault handling strategy is sent to the host, including:

[0096] S122: Identify the faulty disk management module that has failed in the faulty solid-state drive;

[0097] S123: Set the multicast assertion flag for the faulty disk management module;

[0098] S124: When other disk management modules in the failed solid-state drive detect the multicast assertion flag of the failed disk management module, select the target disk management module from the remaining disk management modules;

[0099] S125: Process the input / output requests of the faulty disk management module through the target disk management module and send the corresponding feedback information to the host.

[0100] When the fault type of the faulty SSD is confirmed to be a software logic error based on the IO command path, the corresponding fault handling strategy is executed, specifically identifying the faulty disk management (DM) module in the faulty SSD.

[0101] Understandably, in SSD firmware architecture design, the IO request path is generally designed with multiple cores to meet performance requirements, meaning multiple CPUs process the host's IO requests simultaneously. Therefore, a CPU can also be called an IO core. Furthermore, because a DM module exists within the CPU, which is specifically responsible for handling the host's IO requests, the CPU can also be called a DM core. For example, if an SSD has four CPUs processing the host's IO requests, the DM modules corresponding to each CPU can be defined as DM0-DM3. In this embodiment, the faulty DM module that has failed is first identified.

[0102] Furthermore, the multicast assertion flag dm_assert_flag of the faulty DM module is set to 1. In this embodiment, a bitmap can be used to represent the multicast assertion flag. When other DM modules in the faulty SSD detect the multicast assertion flag dm_assert_flag of the faulty DM module, a target DM module is selected from the remaining DM modules. In this embodiment, there are no restrictions on the selection method of the target DM module; for example, it can be selected randomly or according to selection rules, depending on the specific implementation.

[0103] Finally, the target DM module processes the IO requests from the faulty DM module and sends corresponding feedback information to the host. This embodiment does not limit the specific process by which the target DM module processes the IO requests from the faulty DM module.

[0104] In this embodiment, the faulty disk management module in the faulty solid-state drive is identified; a multicast assertion flag for the faulty disk management module is set; when other disk management modules in the faulty solid-state drive detect the multicast assertion flag of the faulty disk management module, a target disk management module is selected from the remaining disk management modules; the target disk management module processes the input / output requests of the faulty disk management module and sends corresponding feedback information to the host, thereby realizing the execution of the fault handling strategy and the sending of feedback information under software logic errors based on input / output command paths.

[0105] To better select the target DM module, based on the above embodiments, in some embodiments, before determining the faulty disk management module that failed in the faulty solid-state drive, the following method is also included:

[0106] S126: Set the priority of all disk management modules in the failed solid-state drive.

[0107] Specifically, the priority of all DM modules in the failed SSD is set. Taking DM0-DM3 in the above embodiment as an example, the priority of the DM modules can be set to DM0. <DM1<DM2<DM3。

[0108] Correspondingly, select the target disk management module from the remaining disk management modules, including:

[0109] S127: Obtain the priority of each disk management module except the faulty disk management module;

[0110] S128: Select the disk management module with the highest priority as the target disk management module.

[0111] When a target DM module needs to be selected, the priorities of the remaining DM modules except the faulty DM module can be obtained, and the DM module with the highest priority is selected as the target DM module. Taking DM0 - DM3 in the above embodiment as an example, the priority order of DM0 - DM3 is DM0 < DM1 < DM2 < DM3. Then, when only DM0 fails, DM3 is used as the target DM module; if DM3 fails, DM2 is used as the target DM module. In this way, the selection of the target DM module is achieved.

[0112] In order to enable the target DM module to handle the IO requests of the faulty DM module on behalf, based on the above embodiment, in some embodiments, the input and output requests of the faulty disk management module are processed by the target disk management module, and the corresponding feedback information is sent to the host, including:

[0113] S129: Select the current cache from the caches of the faulty disk management module by the target disk management module, and obtain the input-output command state machine structure of the current cache;

[0114] S130: Determine whether the input-output request in the current cache returns a completion message to the host according to the input-output command state machine structure; if the input-output request in the current cache does not return a completion message to the host, step S131 is entered; if the input-output request in the current cache has returned a completion message to the host, step S132 is entered;

[0115] S131: Send the feedback message of the input-output request error corresponding to the current cache to the host by the target disk management module;

[0116] S132: Select the next cache from the remaining caches of the faulty disk management module as the current cache by the target disk management module, and enter the step of obtaining the input-output command state machine structure of the current cache until all the caches of the faulty disk management module are traversed.

[0117] Specifically, the current cache is selected from the caches of the faulty DM module by the target DM module, and the IO command state machine structure of the current cache is obtained. Determine whether the IO request in the current cache returns a completion message to the host according to the IO command state machine structure;

[0118] If it is confirmed that no completion information has been returned to the host, the target DM module sends an error feedback message for the IO request corresponding to the current cache to the host. If it is confirmed that a completion information has been returned to the host, the current cache is skipped, and the target DM module selects the next cache from the remaining caches of the faulty DM module as the current cache, proceeding to the step of obtaining the IO command state machine structure of the current cache, until all caches of the faulty DM module have been traversed and all IO operations have been completed. In this way, the target DM module handles the IO requests of the faulty DM module on behalf of the faulty DM module.

[0119] Based on the above embodiments, in some embodiments, when the failure type of the faulty solid-state drive is a software logic error based on the management command path, the corresponding fault handling strategy is executed according to the fault type of the faulty solid-state drive, and feedback information corresponding to the fault handling strategy is sent to the host, including:

[0120] S133: Set the asynchronous assertion flag for the failed solid-state drive;

[0121] S134: When the disk management cores of the faulty solid-state drive process the host's input / output requests, they send feedback information about the input / output request error to the host according to the asynchronous assertion flag;

[0122] The disk management core is the central processing unit that runs the disk management module in the solid-state drive and is used to handle input / output requests.

[0123] When the failure type of the faulty SSD is confirmed to be a software logic error based on the admin command path, the corresponding fault handling strategy is executed. Specifically, the asynchronous assertion flag am_assert_flag of the faulty SSD is set to 1. When each DM core of the faulty SSD processes host I / O requests, if the asynchronous assertion flag am_assert_flag is confirmed to be 1, feedback information about the I / O request error needs to be sent to the host. It can be understood that the DM core is the CPU within the SSD that runs the DM module and handles I / O requests.

[0124] In this embodiment, an asynchronous assertion flag is set for the faulty solid-state drive. When each disk management core of the faulty solid-state drive processes the host's input / output requests, it sends feedback information about the input / output request error to the host according to the asynchronous assertion flag, thereby realizing the execution of the fault handling strategy and the sending of feedback information under software logic errors based on the management command path.

[0125] Based on the above embodiments, in some embodiments, when the fault type of the faulty solid-state drive is a hardware unit error based on the input / output command path or a hardware unit error based on the management command path, the corresponding fault handling strategy is executed according to the fault type of the faulty solid-state drive, and feedback information corresponding to the fault handling strategy is sent to the host, including:

[0126] S135: Set the hardware unit error flag for the faulty solid-state drive;

[0127] S136: When the disk management cores of the faulty solid-state drive process the host's input / output requests, they send feedback information about the input / output request error to the host according to the hardware unit error flag.

[0128] The disk management core is the central processing unit that runs the disk management module in the solid-state drive and is used to process input / output requests.

[0129] When the faulty SSD is confirmed to have a hardware unit error based on the IO command path or the admin command path, the corresponding fault handling strategy is executed. Specifically, the hardware unit error flag `hard_unit_error_flag` of the faulty SSD is set to 1. When each DM core of the faulty SSD processes the host's IO requests, if the hardware unit error flag `hard_unit_error_flag` is confirmed to be 1, IO request error feedback information needs to be sent to the host. It can be understood that the DM core is the central processing unit within the SSD that runs the DM module and handles IO requests.

[0130] In this embodiment, a hardware unit error flag is set for the faulty solid-state drive; when each disk management core of the faulty solid-state drive processes the host's input / output requests, it sends feedback information about the input / output request error to the host according to the hardware unit error flag; thus realizing the execution of fault handling strategies and the sending of feedback information under hardware unit errors based on input / output command paths or hardware unit errors based on management command paths.

[0131] The above embodiments have described the execution of handling strategies and the occurrence of feedback information for several types of faults. However, there is another type of fault, specifically a solid-state drive (SSD) controller failure. In this type of fault, the faulty SSD will be unable to perform any operations and will be unable to send any information to the host. To handle SSD controller failures, when the fault type of the faulty SSD is an SSD controller failure, the method further includes:

[0132] S150: By monitoring the processing time of input / output requests and / or management requests of the faulty solid-state drive by the host, determine whether the processing time of input / output requests and / or management requests exceeds the corresponding time threshold; if the processing time of input / output requests and / or management requests exceeds the corresponding time threshold, proceed to step S151.

[0133] S151: The host marks the faulty SSD as faulty and removes the faulty SSD from the independent disk redundancy array.

[0134] Specifically, the host monitors the processing time of IO requests and / or admin requests for the faulty SSD to determine whether these processing times exceed corresponding time thresholds. It should be noted that this embodiment does not impose any restrictions on the time thresholds; they will be determined based on the specific implementation.

[0135] If the host confirms that the processing time of both IO requests and admin requests does not exceed the corresponding time thresholds, the SSD is considered to be operating normally. If the host confirms that the processing time of IO requests and / or the processing time of admin requests exceeds the corresponding time thresholds, it indicates that all IO cores of the faulty SSD have experienced logical errors or errors in its Completion Queue Element (CQE) hardware units, causing IO requests in the current cache to fail to return to the host normally. In this case, the SSD firmware cannot process the IO and return completion to the host. Therefore, the host marks the faulty SSD as faulty and removes it from the independent redundant disk array.

[0136] In specific implementations, the host computer may also employ other methods for kicking the disk. Based on the above embodiments, in some embodiments, the method further includes:

[0137] S161: Drive the setting information of the critical fault status in the status register of the monitoring controller through the non-volatile memory of the host, and determine whether the critical fault status is set according to the setting information; if the critical fault status is set, proceed to step S162.

[0138] S162: Remove the failed solid-state drive from the independent disk redundancy array after the command termination timeout period via non-volatile memory drive.

[0139] Non-Volatile Memory Express (NVMe) is a high-speed data transfer protocol for accessing SSDs. The NVMe controller contains a Controller Status (CSTS) register, which holds the controller's status information. In practice, the host NVMe driver monitors the setting of the fatal status bit in the CSTS register. When an SSD experiences a fatal failure, the fatal status bit in the CSTS register is set, indicating a fatal error. Upon detecting this status, the NVMe driver waits for the Command Abort Timeout (CAP.TO) period before removing the failed SSD from the Linux system. This process effectively removes the failed SSD.

[0140] It should be noted that CAP.TO time is a configurable parameter that specifies how long the system waits before evicting a failed SSD after a fatal error occurs.

[0141] Based on the above embodiments, in some embodiments, the method further includes:

[0142] S163: Monitor the setting information of key warning fields in the host self-monitoring analysis report technical log, and determine whether the key warning fields are set based on the setting information; if the key warning fields are set, proceed to step S164.

[0143] S164: Obtain the error type and severity of the faulty solid-state drive;

[0144] S165: Remove the failed solid-state drive from the independent disk redundancy array based on the error type and severity of the failed solid-state drive.

[0145] Self-Monitoring, Analysis, and Reporting Technology (SMART) is a hard drive health monitoring technology that can monitor various indicators of the hard drive, such as temperature and error rate, and report the status of these indicators.

[0146] In this embodiment, the host monitors the critical warning (criticalWarn) field in the SMART log. When an SSD's health status is compromised, the criticalWarn field in the smartlog is set, indicating a critical warning has occurred. The host software can periodically monitor this field, and when it is set, it obtains the error type and severity of the failed SSD, and decides whether to proactively remove the failed SSD based on the error type and severity. The details are explained below:

[0147] To determine whether to actively remove a faulty SSD based on its error type and severity, the following steps can be taken: Define the error type and severity level. First, it is necessary to clearly define the type of error occurring on the SSD and its corresponding severity level. For example, the fault types mentioned in the above embodiment can be used, and different severity levels can be defined according to their impact on the system, such as Fatal, Critical, Major, Minor, etc.

[0148] Further monitoring of SSD health status is conducted, and when critical warnings are detected, the host performs an assessment based on the error type and severity. Specifically, the impact of the current error on the system is evaluated according to the defined error type and severity level. For example, a fatal error may immediately lead to data loss or system crash, requiring immediate action; while a minor error may only affect performance and can be addressed later. Based on the assessment results, a decision is made as to whether to proactively remove the faulty SSD. For example, for fatal or severe errors, the faulty SSD should be removed immediately to protect data and system stability; for major or minor errors, the decision can be made on a case-by-case basis, such as replacement within a maintenance window without impacting business operations.

[0149] Finally, if you decide to remove a faulty SSD, you can do so using software RAID tools (such as mdadm) or system management tools to remove the faulty SSD from the system.

[0150] By following the steps above, you can make a reasonable decision on whether to actively remove a faulty SSD based on the type and severity of the error, in order to ensure system reliability and data security.

[0151] Based on the above embodiments, in some embodiments, after the host removes the faulty solid-state drive from the independent disk redundancy array according to the feedback information, the method further includes:

[0152] S171: Obtain the time when the faulty SSD occurred, detailed information about the faulty SSD, the cause of the faulty SSD, and the steps to remove the faulty SSD;

[0153] S172: Generate a removal log for the faulty SSD based on the time of the faulty SSD, detailed information about the faulty SSD, the cause of the faulty SSD, and the steps to remove the faulty SSD.

[0154] After the host removes the failed SSD from the RAID, to help users better understand the removal process, this embodiment specifically obtains the time of the SSD's failure, detailed information about the failed SSD, the cause of the failure, and the steps taken to remove it. Furthermore, based on these information, a removal log is generated, allowing users to review the entire removal process.

[0155] Furthermore, if data backup or recovery was performed before removing the failed SSD, the removal log can record relevant details, such as backup time, recovery process, and methods for verifying data integrity. If a new SSD was added after removing the failed SSD, the removal log can also record information about the new SSD and the process of adding it to the RAID. If a RAID rebuild operation was performed, the removal log can also record the rebuild start time, completion time, and any warnings or errors during the process. Finally, the removal log can also record the process of verifying and testing the repaired RAID, such as checking data integrity and performing performance tests. By generating removal logs, system administrators or maintenance personnel can track the fault handling process, analyze the causes of the fault, and take appropriate measures to ensure system reliability and data security.

[0156] Figure 2 is a flowchart of another solid-state drive (SSD) fault handling method provided in an embodiment of this application. The method is applied to a host computer, and as shown in Figure 2, the method includes:

[0157] S20: Receive feedback information sent by the independent disk redundant array.

[0158] The feedback information refers to the feedback information from the corresponding steps of the fault handling strategy when a faulty solid-state drive (SSD) fails, based on the fault type of the SSD.

[0159] S21: Determine the number of input / output request errors corresponding to the faulty solid-state drive based on the received feedback information.

[0160] S22: Determine whether the number of input / output request errors exceeds the first threshold; if the number of input / output request errors does not exceed the first threshold, proceed to step S23; if the number of input / output request errors exceeds the first threshold, proceed to step S24.

[0161] S23: Continue monitoring the number of received input / output request errors, then return to step S21.

[0162] S24: Mark the faulty SSD as faulty and remove it from the independent disk redundancy array.

[0163] In this embodiment, the operating status of the solid-state drives (SSDs) is monitored through an independent disk redundancy array (IDA). When a SSD failure is confirmed, the failure type is determined and the corresponding fault handling strategy is executed. Simultaneously, the IDA actively sends corresponding feedback information to the host. The host determines the number of input / output request errors corresponding to the failed SSD based on the received feedback information. When the host confirms that the number of input / output request errors exceeds a first threshold, the failed SSD is marked as faulty and removed from the IDA. This eliminates the need for the host system to wait for input / output commands or management commands to the SSD to time out and then undergo a lengthy timeout process before removing the SSD, significantly improving the speed of faulty SSD identification and removal. This effectively reduces the maintenance cost of the IDA and improves its utilization efficiency.

[0164] In the above embodiments, the solid-state drive (SSD) failure handling method has been described in detail. This application also provides embodiments of the solid-state drive (SSD) failure handling device.

[0165] Figure 3 is a schematic diagram of a solid-state drive (SSD) fault handling device provided in an embodiment of this application. The device is applied to an independent disk redundancy array; as shown in Figure 3, the device includes:

[0166] The first monitoring module 10 is used to monitor the operating status of the solid-state drive (SSD) and determine whether the SSD has malfunctioned. If the SSD is confirmed to have malfunctioned, the determination module is triggered.

[0167] The first determining module 11 is used to determine the fault type of the faulty solid-state drive; wherein the fault type includes at least storage media error, software logic error based on input / output command path, software logic error based on management command path, hardware unit error based on input / output command path, and hardware unit error based on management command path;

[0168] The execution module 12 is used to execute the corresponding fault handling strategy according to the fault type of the faulty solid-state drive, and send feedback information corresponding to the fault handling strategy to the host, so that the host can determine the number of input / output request errors corresponding to the faulty solid-state drive based on the received feedback information, and determine whether the number of received input / output request errors exceeds a first threshold; if the host confirms that the number of input / output request errors does not exceed the first threshold, the host continues to monitor the number of received input / output request errors; if the host confirms that the number of input / output request errors exceeds the first threshold, the host marks the faulty solid-state drive as faulty and removes the faulty solid-state drive from the independent disk redundancy array.

[0169] In some embodiments, the execution module 12 includes:

[0170] The first settings submodule is used to set a faulty solid-state drive to read-only mode via the solid-state drive firmware.

[0171] The first sending submodule is used to send input / output request error feedback information to the host when the faulty solid-state drive receives a write operation request from the host.

[0172] In some embodiments, the execution module 12 includes:

[0173] The first determination submodule is used to determine the faulty disk management module that has failed in the faulty solid-state drive;

[0174] The second settings submodule is used to set the multicast assertion flag for the faulty disk management module;

[0175] The first selection submodule is used to select a target disk management module from the remaining disk management modules when the other disk management modules in the failed solid-state drive detect the multicast assertion flag of the failed disk management module.

[0176] The second sending submodule is used to process the input / output requests of the faulty disk management module through the target disk management module and send the corresponding feedback information to the host.

[0177] In some embodiments, the execution module 12 further includes:

[0178] The third settings submodule is used to set the priority of all disk management modules in the failed solid-state drive;

[0179] Correspondingly, the first selection submodule includes:

[0180] The first acquisition submodule is used to acquire the priority of each disk management module except for the faulty disk management module;

[0181] The second selection submodule is used to select the disk management module with the highest priority as the target disk management module.

[0182] In some embodiments, the second transmitting submodule includes:

[0183] The third selection submodule is used to select the current cache from the caches of the faulty disk management module through the target disk management module, and obtain the input / output command state machine structure of the current cache;

[0184] The first judgment submodule is used to determine whether the input / output request in the current cache has returned completion information to the host based on the input / output command state machine structure; if the input / output request in the current cache has not returned completion information to the host, the third sending submodule is triggered; if the input / output request in the current cache has returned completion information to the host, the fourth selection submodule is triggered.

[0185] The third sending submodule is used to send feedback information of input / output request errors corresponding to the current cache to the host through the target disk management module;

[0186] The fourth selection submodule is used to select the next cache as the current cache from the remaining cache of the faulty disk management module through the target disk management module, and enter the step of obtaining the input and output command state machine structure of the current cache until all caches of the faulty disk management module have been traversed.

[0187] In some embodiments, the execution module 12 includes:

[0188] The fourth settings submodule is used to set the asynchronous assertion flag for the faulty solid-state drive;

[0189] The fourth sending submodule is used to send feedback information about input / output request errors to the host based on the asynchronous assertion flag when each disk management core of the faulty solid-state drive processes the host's input / output requests.

[0190] The disk management core is the central processing unit that runs the disk management module in the solid-state drive and is used to handle input / output requests.

[0191] In some embodiments, the execution module 12 includes:

[0192] The fifth settings submodule is used to set the hardware unit error flag for the faulty solid-state drive;

[0193] The fifth sending submodule is used to send feedback information about input / output request errors to the host based on the hardware unit error flag when each disk management core of the faulty solid-state drive processes the host's input / output requests.

[0194] The disk management core is the central processing unit that runs the disk management module in the solid-state drive and is used to process input / output requests.

[0195] In some embodiments, it also includes:

[0196] The second judgment submodule is used to monitor the processing time of input / output requests and / or management requests of the faulty solid-state drive through the host, and determine whether the processing time of input / output requests and / or management requests exceeds the corresponding time threshold; if the processing time of input / output requests and / or management requests exceeds the corresponding time threshold, the mark removal submodule is triggered.

[0197] The mark-removal submodule is used by the host to mark a faulty SSD as faulty and remove the faulty SSD from the independent disk redundancy array.

[0198] In some embodiments, it also includes:

[0199] The third judgment submodule is used to drive the setting information of the critical fault status in the status register of the monitoring controller through the host's non-volatile memory, and to determine whether the critical fault status is set according to the setting information; if the critical fault status is set, the first removal submodule is triggered.

[0200] The first removal submodule is used to remove the faulty solid-state drive from the independent disk redundancy array after the command termination timeout period via a non-volatile memory driver.

[0201] In some embodiments, it also includes:

[0202] The fourth judgment submodule is used to check the setting information of key warning fields in the host monitoring self-monitoring analysis report technical log, and determine whether the key warning fields are set based on the setting information; if the key warning fields are set, the second acquisition submodule is triggered.

[0203] The second acquisition submodule is used to acquire the error type and severity of the faulty solid-state drive;

[0204] The second removal submodule is used to remove the faulty solid-state drive from the independent disk redundancy array based on the error type and severity of the faulty solid-state drive.

[0205] In some embodiments, it also includes:

[0206] The third acquisition submodule is used to acquire the time when the faulty solid-state drive (SSD) failed, detailed information about the faulty SSD, the cause of the faulty SSD, and the steps to remove the faulty SSD.

[0207] The log generation submodule is used to generate a removal log for the failed SSD based on the time of the failure, detailed information about the failed SSD, the cause of the failure, and the steps to remove the failed SSD.

[0208] Figure 4 is a schematic diagram of another solid-state drive fault handling device provided in an embodiment of this application. The device is applied to a host computer, and as shown in Figure 4, the device includes:

[0209] The receiving module 15 is used to receive feedback information sent by the independent disk redundancy array. This feedback information is the feedback information corresponding to the fault handling strategy executed based on the fault type of the faulty solid-state drive when a fault occurs.

[0210] The second determining module 16 is used to determine the number of input / output request errors corresponding to the faulty solid-state drive based on the received feedback information.

[0211] The judgment module 17 is used to determine whether the number of input / output request errors exceeds the first threshold. If the number of input / output request errors does not exceed the first threshold, the second monitoring module 18 is triggered. If the number of input / output request errors exceeds the first threshold, the removal module 19 is triggered.

[0212] The second monitoring module 18 is used to continue monitoring the number of received input / output request errors and trigger the second determination module 16.

[0213] Remove module 19 is used to mark the faulty solid-state drive as faulty and remove the faulty solid-state drive from the independent disk redundancy array.

[0214] Since the embodiments and beneficial effects of the apparatus section correspond to the embodiments and beneficial effects of the method section, please refer to the description of the embodiments of the method section for the embodiments and beneficial effects of the apparatus section, and they will not be repeated here.

[0215] In addition, this application also provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the above-described solid-state drive fault handling method.

[0216] Figure 5 is a schematic diagram of a solid-state drive (SSD) fault handling device provided in an embodiment of this application. As shown in Figure 5, the SSD fault handling device includes:

[0217] Memory 20 is used to store computer programs;

[0218] The processor 21 is used to execute computer programs to implement the steps of the solid-state drive fault handling method mentioned in the above embodiments.

[0219] The solid-state drive fault handling device provided in this embodiment may include, but is not limited to, smartphones, tablets, laptops, or desktop computers.

[0220] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one of the following hardware forms: Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as the central processing unit, is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an Artificial Intelligence (AI) processor, which is used to handle computational operations related to machine learning.

[0221] The memory 20 may include one or more computer-defined non-volatile readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 20 is used to store at least the following computer program 201, which, after being loaded and executed by the processor 21, can implement the relevant steps of the solid-state drive failure handling method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, and the storage method may be temporary or permanent storage. The operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include, but is not limited to, the data involved in the solid-state drive failure handling method.

[0222] In some embodiments, the solid-state drive fault handling device may further include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26.

[0223] Those skilled in the art will understand that the structure shown in Figure 5 does not constitute a limitation on the solid-state drive failure handling device and may include more or fewer components than shown.

[0224] Since the beneficial effects of the equipment section correspond to those of the method section, please refer to the description of the beneficial effects of the method section for details on the beneficial effects of the equipment section; they will not be repeated here.

[0225] Finally, this application also provides an embodiment corresponding to a computer non-volatile readable storage medium. The computer non-volatile readable storage medium stores a computer program, which, when executed by a processor, implements the steps described in the above method embodiments (which may be a method corresponding to the independent disk redundant array side, a method corresponding to the host side, or a method corresponding to both the independent disk redundant array side and the host side).

[0226] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0227] Since the beneficial effects of the medium section correspond to the beneficial effects of the method section, please refer to the description of the beneficial effects of the method section for the beneficial effects of the medium section, and will not be repeated here.

[0228] The foregoing provides a detailed description of a solid-state drive (SSD) fault handling method, product, device, and medium. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

[0229] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

Claims

1. A method for handling solid-state drive (SSD) failures, characterized in that, Applied to independent disk redundancy arrays; the method includes: monitoring the operating status of solid-state drives (SSDs) to determine whether the SSDs have malfunctioned; If the solid-state drive (SSD) is confirmed to be faulty, determine the type of fault. The system executes a corresponding fault handling strategy based on the fault type of the faulty solid-state drive (SSD) and sends feedback information corresponding to the fault handling strategy to the host. This allows the host to determine the number of input / output request errors (I / O requests) corresponding to the faulty SSD based on the received feedback information, and to determine whether the number of received I / O requests exceeds a first threshold. If the host confirms that the number of I / O requests does not exceed the first threshold, the host continues to monitor the number of received I / O requests. If the host confirms that the number of I / O requests exceeds the first threshold, the host marks the faulty SSD as faulty and removes it from the independent disk redundancy array (IDA).

2. The solid-state drive fault handling method according to claim 1, characterized in that, In response to the fault type of the faulty solid-state drive being a storage media error, the step of executing the corresponding fault handling strategy according to the fault type of the faulty solid-state drive and sending feedback information corresponding to the fault handling strategy to the host includes: Set the faulty solid-state drive to read-only mode using the solid-state drive firmware; In response to the faulty solid-state drive receiving a write operation request from the host, it sends an input / output request error feedback message to the host.

3. The solid-state drive fault handling method according to claim 1, characterized in that, In response to the fault type of the faulty solid-state drive being a software logic error based on input / output command paths, the step of executing the corresponding fault handling strategy according to the fault type of the faulty solid-state drive and sending feedback information corresponding to the fault handling strategy to the host includes: Identify the faulty disk management module that caused the failure in the faulty solid-state drive; Set the multicast assertion flag for the faulty disk management module; In response to the other disk management modules in the failed solid-state drive detecting the multicast assertion flag of the failed disk management module, a target disk management module is selected from the remaining disk management modules; The target disk management module processes the input / output requests of the faulty disk management module and sends the corresponding feedback information to the host.

4. The solid-state drive fault handling method according to claim 3, characterized in that, Before the faulty disk management module that determines that a fault has occurred in the faulty solid-state drive, the following is also included: Set the priority of all disk management modules in the failed solid-state drive; Correspondingly, selecting the target disk management module from the remaining disk management modules includes: Obtain the priority of each disk management module except the faulty disk management module; Select the disk management module with the highest priority as the target disk management module.

5. The solid-state drive fault handling method according to claim 3, characterized in that, The step of processing the input / output requests of the faulty disk management module through the target disk management module and sending the corresponding feedback information to the host includes: selecting the current cache in each cache of the faulty disk management module through the target disk management module and obtaining the input / output command state machine structure of the current cache; The system determines whether the input / output request in the current cache has returned completion information to the host based on the input / output command state machine structure. If it is confirmed that no completion information has been returned to the host, then the target disk management module sends feedback information about the input / output request error corresponding to the current cache to the host; If the completion information is confirmed to be returned to the host, the target disk management module selects the next cache from the remaining cache of the faulty disk management module as the current cache, and enters the step of obtaining the input / output command state machine structure of the current cache, until all caches of the faulty disk management module are traversed.

6. The solid-state drive fault handling method according to claim 1, characterized in that, In response to the fault type of the faulty solid-state drive being a software logic error based on a management command path, the step of executing the corresponding fault handling strategy according to the fault type of the faulty solid-state drive and sending feedback information corresponding to the fault handling strategy to the host includes: Set the asynchronous assertion flag for the faulty solid-state drive; In response to the disk management cores of the faulty solid-state drive processing the host's input / output requests, feedback information of input / output request errors is sent to the host according to the asynchronous assertion flag; The disk management core is the disk management module running in the solid-state drive, which is configured as the central processing unit to handle input / output requests.

7. The solid-state drive fault handling method according to claim 1, characterized in that, In response to the fault type of the faulty solid-state drive being either a hardware unit error based on an input / output command path or a hardware unit error based on a management command path, the step of executing the corresponding fault handling strategy according to the fault type of the faulty solid-state drive and sending feedback information corresponding to the fault handling strategy to the host includes: Set the hardware unit error flag for the faulty solid-state drive; In response to the faulty solid-state drive, each disk management core processes the host's input / output requests and sends feedback information about the input / output request error to the host based on the hardware unit error flag; The disk management core is the disk management module that runs on the solid-state drive and is configured as a central processing unit to handle input / output requests.

8. The solid-state drive fault handling method according to claim 1, characterized in that, In response to the fault type of the faulty solid-state drive being a solid-state drive controller failure, the following additional methods are also included: The host monitors the processing time of input / output requests and / or the processing time of management requests of the faulty solid-state drive to determine whether the processing time of input / output requests and / or the processing time of management requests exceeds the corresponding time threshold. If the host confirms that the processing time of the input / output request and / or the processing time of the management request exceeds the corresponding time threshold, the host marks the faulty solid-state drive as faulty and removes the faulty solid-state drive from the independent disk redundancy array.

9. The solid-state drive fault handling method according to claim 1, characterized in that, Also includes: The host computer uses its non-volatile memory to drive the setting information of the critical fault status in the status register of the monitoring controller, and determines whether the critical fault status is set based on the setting information. If the critical fault status is set, the faulty solid-state drive is removed from the independent disk redundancy array after the command termination timeout period via the non-volatile memory driver.

10. The solid-state drive fault handling method according to claim 1, characterized in that, Also includes: The system monitors the setting information of key warning fields in the host self-monitoring analysis report technical log, and determines whether the key warning fields are set based on the setting information. If the critical warning field is set, the error type and severity of the faulty solid-state drive are obtained; The faulty solid-state drive is removed from the independent disk redundancy array based on the error type and severity of the faulty solid-state drive.

11. The solid-state drive fault handling method according to any one of claims 1 to 10, characterized in that, After the host removes the faulty solid-state drive from the independent redundant disk array based on the feedback information, the process further includes: Obtain the time when the faulty solid-state drive (SSD) failed, the detailed information of the faulty SSD, the cause of the faulty SSD, and the operation steps for removing the faulty SSD; A removal log for the faulty solid-state drive is generated based on the time of the failure, detailed information about the faulty solid-state drive, the cause of the failure, and the steps taken to remove the faulty solid-state drive.

12. The solid-state drive fault handling method according to claim 1, characterized in that, The monitoring of the operating status of the solid-state drive (SSD) to determine whether the SSD has malfunctioned includes: Check the firmware version and firmware status of the solid-state drive. Determine whether the solid-state drive is faulty based on whether the firmware version is the latest version and whether the firmware status is normal. Alternatively, check the temperature of the solid-state drive (SSD) and determine whether the SSD is malfunctioning based on the temperature. Alternatively, check the read / write error rate of the solid-state drive, and determine whether the solid-state drive has malfunctioned based on the read / write error rate; Alternatively, check the lifespan of the solid-state drive (SSD), and determine whether the SSD has malfunctioned based on the lifespan and design lifespan. Alternatively, check the bad blocks of the solid-state drive, and determine whether the solid-state drive is faulty based on the number of bad blocks; Alternatively, check the interface and connection of the solid-state drive (SSD), and determine whether the SSD is faulty based on whether the interface and connection are normal.

13. The solid-state drive fault handling method according to claim 10, characterized in that, The step of removing the faulty solid-state drive (SSD) from the independent redundant disk array based on the error type and severity of the faulty SSD includes: Assess the impact of the current error on the system based on the error type and severity of the faulty solid-state drive; Based on the impact of the current error on the system, determine whether to remove the faulty solid-state drive from the independent disk redundancy array.

14. The solid-state drive fault handling method according to claim 13, characterized in that, Based on the impact of the current error on the system, determining whether to remove the faulty solid-state drive from the independent disk redundancy array includes: Determine the severity level based on the impact of the current error on the system; If the severity level is fatal or critical, the faulty solid-state drive should be immediately removed from the independent disk redundant array; If the severity level is a major or minor error, the replacement can be performed within the maintenance window without affecting business operations.

15. The solid-state drive fault handling method according to claim 11, characterized in that, After generating a removal log for the faulty solid-state drive (SSD) based on the time of its failure, detailed information about the SSD, the cause of its failure, and the steps taken to remove it, the method further includes: If a data backup or recovery operation was performed before the faulty SSD was removed, the backup time, recovery process, and method for verifying data integrity will be recorded in the removal log. If a new SSD is added after the faulty SSD is removed, the information of the new SSD and the process of adding it to the independent disk redundancy array are recorded in the removal log. If an independent redundant disk array rebuild operation is performed, the rebuild start time, completion time, and any warnings or errors during the process will be recorded in the removal log.

16. The solid-state drive fault handling method according to claim 3, characterized in that, The multicast assertion flags are represented using a bitmap.

17. A method for handling solid-state drive (SSD) failures, characterized in that, Applied to a host; the method includes: Receive feedback information sent by the independent disk redundancy array; wherein, the feedback information is the feedback information of the corresponding link of the fault handling strategy when the faulty solid-state drive fails and the corresponding fault handling strategy is executed according to the fault type of the faulty solid-state drive. The number of input / output request errors corresponding to the faulty solid-state drive is determined based on the received feedback information; Determine if the number of input / output request errors exceeds a first threshold; If it is confirmed that the number of input / output request errors does not exceed the first threshold, then continue to monitor the number of received input / output request errors and return to the step of determining the number of input / output request errors corresponding to the faulty solid-state drive based on the received feedback information; If the number of input / output request errors is confirmed to exceed the first threshold, the faulty solid-state drive is marked as faulty and removed from the independent disk redundancy array.

18. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by the processor, they implement the steps of the solid-state drive failure handling method according to any one of claims 1 to 17.

19. A solid-state drive (SSD) fault handling device, characterized in that, include: Memory, configured to store computer programs; The processor, configured to execute the computer program, implements the steps of the solid-state drive failure handling method as described in any one of claims 1 to 17.

20. A computer non-volatile readable storage medium, characterized in that, The computer non-volatile readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the solid-state drive failure handling method as described in any one of claims 1 to 17.

Images