Solid-state hard drive fault repair method, device, computer equipment and storage medium

Abstract

The present application relates to a method, apparatus, computer equipment, and storage medium for repairing a solid-state hard drive fault. The method includes: monitoring the operating status of the solid-state hard drive; determining the fault condition based on the abnormal operating status log when an abnormal operating status log is detected; obtaining a target code related to the fault condition from the current version of the solid-state hard drive firmware; analyzing the target code to determine the cause of the fault; generating an optimized code based on the cause of the fault, replacing the target code in the current version of the firmware with the optimized code, and obtaining the latest version of the firmware; compiling the latest version of the firmware to generate the latest version of the firmware file; verifying whether the latest version of the firmware file can successfully repair the fault condition, and when the repair fails, recording the number of repairs, and when the number of repairs is less than a preset number threshold, returning to determining the fault condition based on the abnormal operating status log. The present application can improve the data integrity of the solid-state hard drive and improve the stability and reliability of the solid-state hard drive application.

Description

Technical Field

[0001] The present application relates to the technical field of hard disk failure processing, and in particular to a solid-state hard disk failure repair method, device, computer equipment, and storage medium. Background Art

[0002] The rapid development of the information industry has fueled the rapid growth of the internet and traditional industries. The writing, reading, and storage of massive amounts of information, whether locally or in the cloud, requires the support of appropriate infrastructure. Hard drives are currently the most fundamental storage device. With the increasing demands and complexity of various application scenarios, traditional mechanical hard disk drives (HDDs) are rapidly transitioning to emerging solid-state drives (SSDs), driving the rapid development of the SSD industry.

[0003] With the rapid development of solid-state drive (SSD) technology, its scope and scale of use are expanding, and the probability of failure is also increasing. Compared to mechanical hard drives (SDs), SSDs are more challenging to analyze. In addition to requiring high hardware stability, the SSD firmware (FW), the software that controls the SSD's operation, also requires extremely high standards. Due to the varying technical expertise and approaches of different SSD developers, and the varying firmware algorithms, firmware issues account for a significant proportion of all SSD failures. Firmware issues can cause SSD problems such as data loss, performance degradation, and / or drive failure. Currently, resolving firmware issues requires developers to perform a series of operations, including problem reproduction, log analysis, firmware code rewriting, firmware code compilation, firmware revalidation, and firmware code release. These operations are time-consuming and labor-intensive, increasing the risk of SSD failures such as data loss, performance degradation, and / or drive failure. Summary of the Invention

[0004] To address the above-mentioned shortcomings, the present application provides a method, apparatus, computer device, and storage medium for repairing SSD failures. This method can improve the data integrity of SSDs, as well as the stability and reliability of SSD applications, thereby minimizing the risk of data loss, performance degradation, and drive failure.

[0005] According to a first aspect, the present application provides a solid-state hard drive fault repair method, the method comprising: monitoring the operating status of the solid-state hard drive during operation of the solid-state hard drive; determining the fault condition based on the abnormal operating status log when an abnormal operating status log is detected; obtaining code related to the fault condition from the current version of the solid-state hard drive firmware as a target code; analyzing the target code to determine the cause of the fault; generating an optimized code based on the cause of the fault, replacing the target code in the current version of the firmware with the optimized code to obtain the latest version of the firmware; compiling the latest version of the firmware to generate a latest version of the firmware file; verifying whether the latest version of the firmware file can successfully repair the fault condition, and when the verification result is a repair failure, recording the number of repairs, and when the number of repairs is less than a preset number threshold, returning to the step of determining the fault condition based on the abnormal operating status log.

[0006] In some embodiments, monitoring the operating status of a solid-state drive includes: monitoring the smart properties of the solid-state drive, obtaining abnormal smart property logs as abnormal operating status logs; monitoring system logs and solid-state drive logs according to predefined keyword parameters, and obtaining logs containing keyword parameters from the system logs and solid-state drive logs as abnormal operating status logs.

[0007] In some embodiments, before verifying whether the latest version of the firmware file can successfully repair the fault condition, the method also includes: obtaining current data of a preset plurality of indicators related to the host load; judging whether the host is currently in a high-load state based on the current data of the plurality of indicators; when the host is in a high-load state, entering a waiting state, recording the fault condition and issuing an early warning message based on the fault condition; when the host is not in a high-load state, entering a step of verifying whether the latest version of the firmware file can successfully repair the fault condition.

[0008] In some embodiments, verifying whether the latest version of the firmware file can successfully repair the fault condition includes: determining other solid-state drives that are currently idle based on the real-time read and write status of each other solid-state drive as the target idle solid-state drive; performing a load test on the latest version of the firmware file on the target idle solid-state drive; and determining a verification result of the latest version of the firmware file based on the load test result.

[0009] In some embodiments, other solid-state drives that are currently in an idle state are determined as target idle solid-state drives based on the real-time read and write status of each other solid-state drive, including: detecting whether each other solid-state drive is performing read and write operations, marking the other solid-state drives that are performing read and write operations as busy, and marking the other solid-state drives that are not performing read and write operations as idle; when the proportion of other solid-state drives in an idle state in the total number of other solid-state drives is greater than a first threshold, selecting a target idle solid-state drive from the solid-state drives in an idle state; when the proportion of other solid-state drives in a busy state in the total number of other solid-state drives is greater than a second threshold, detecting whether the sum of the current write speeds of all other solid-state drives is less than the sum of the write upper limit standard values ​​of all other solid-state drives; if less than, transferring the write amount of some of the other solid-state drives in a busy state to other other solid-state drives in a busy state, so that the other solid-state drives in this part are switched from a busy state to an idle state, and selecting a target idle solid-state drive from the other solid-state drives that are currently in an idle state.

[0010] In some embodiments, codes related to the fault condition are obtained from the current version of the solid-state drive firmware, including: when the abnormal operating status log comes from the system log, detecting whether the fault condition belongs to a solid-state drive failure; when the fault condition belongs to a solid-state drive failure, obtaining codes related to the fault condition from the current version of the firmware.

[0011] In some embodiments, when the verification result indicates that the repair is successful, the method further includes: upgrading the firmware of other solid-state drives in use with the same specifications as the solid-state drive according to the latest version of the firmware file.

[0012] According to a second aspect, the present application provides a solid-state hard drive fault repair device, the device comprising:

[0013] An operating status monitoring module is used to monitor the operating status of the solid-state hard disk during its operation;

[0014] A fault condition determination module is used to determine the fault condition according to the abnormal operation status log when an abnormal operation status log is monitored;

[0015] A fault cause determination module is used to obtain a code related to the fault condition from the current version of the solid-state drive firmware as a target code; and analyze the target code to determine the cause of the fault;

[0016] The firmware optimization module is used to generate optimized code based on the cause of the fault and replace the target code in the current version of the firmware with the optimized code to obtain the latest version of the firmware;

[0017] Compilation module, used to compile the latest version of the firmware and generate the latest version of the firmware file;

[0018] The verification module is used to verify whether the latest version of the firmware file can successfully repair the fault. When the verification result is that the repair fails, the number of repairs is recorded, and when the number of repairs is less than the preset number threshold, the module returns to the step of determining the fault condition based on the abnormal operation status log.

[0019] According to a third aspect, the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of any one of the solid-state drive failure repair methods in the above-mentioned embodiments are implemented.

[0020] According to a fourth aspect, the present application provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, which, when executed, implements the steps of any one of the solid-state drive failure repair methods in the above-mentioned embodiments.

[0021] The above-mentioned solid-state drive fault repair method monitors the operating status of the solid-state drive during its operation. When an abnormal operating status log is detected, the fault condition is determined based on the abnormal operating status log, and the code related to the fault condition is obtained from the current version of the solid-state drive firmware as the target code; the target code is analyzed to determine the cause of the fault, and an optimized code is generated based on the fault cause. The target code in the current version of the firmware is replaced with the optimized code to obtain the latest version of the firmware, and the latest version of the firmware is compiled to obtain the latest version of the firmware file. The latest version of the firmware file is verified to confirm whether it can successfully repair the fault condition. If the repair fails, the fault condition is repaired in a loop until it is successfully repaired or the number of repairs is greater than or equal to a preset number threshold. This method can timely detect faults during the use of the solid-state drive, analyze and repair the faults, improve the data integrity of the solid-state drive when problems occur in the solid-state drive firmware, and improve the stability and reliability of the solid-state drive application, thereby minimizing the risks of data loss, performance degradation, and disk drop. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 This is a flowchart of a method for repairing a solid-state drive failure in one or more embodiments of the present application;

[0023] Figure 2 A schematic diagram of a monitoring method of an operation monitoring module in one or more embodiments of the present application;

[0024] Figure 3 A schematic diagram of the execution flow of a host-side storage device search and analysis module in one or more embodiments of the present application;

[0025] Figure 4A schematic diagram of the structure of a solid-state drive failure repair device in one or more embodiments of the present application;

[0026] Figure 5 This is a schematic diagram of the internal structure of a computer device in one or more embodiments of the present application. DETAILED DESCRIPTION

[0027] To make the purpose, technical solutions, and advantages of this application more clear, the embodiments of this application will be further described in detail below with reference to the accompanying drawings. It should be understood that the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0028] When the following description refers to the drawings, unless otherwise indicated, the same numerals in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application.

[0029] In the description of this application, it should be understood that the terms "first", "second", "third", etc. are only used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence, nor can they be understood as indicating or implying relative importance. For those of ordinary skill in the art, the specific meanings of the above terms in this application can be understood according to the specific circumstances. In addition, in the description of this application, unless otherwise specified, "multiple" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the previous and subsequent associated objects are in an "or" relationship.

[0030] In response to the deficiencies or defects of related technologies, the present application provides a method for repairing solid-state drive faults. The method can implement a series of operations such as monitoring the operating status of the solid-state drive, analyzing fault conditions, locating fault causes, optimizing abnormal code, automatically compiling firmware, and automatically verifying and upgrading firmware. Faults can be detected in a timely manner during the use of the solid-state drive, and the faults can be analyzed and repaired. This improves the data integrity of the solid-state drive when problems occur in the solid-state drive's firmware, as well as the stability and reliability of the solid-state drive application, minimizing the risk of data loss, performance degradation, and disk drop. The above series of operations can be implemented using host-side resources, as well as the host's backup resources or cluster resources.

[0031] In certain exemplary embodiments of the present application, Figure 1As shown, the method includes steps S110 to S160. Each step of the method is described in detail below, using the host (HOST) as the execution subject. The host can monitor the operating status of the solid-state drive (SSD) and repair any detected faults using a fault repair device. The fault repair device includes multiple modules, including an operation monitoring module, an abnormality log acquisition module, an abnormality log analysis module, a firewall compilation module, a host-side storage device search and analysis module, a firewall verification module, a repair confirmation module, and a user notification module.

[0032] S110: During the operation of the solid state drive, monitor the operating status of the solid state drive.

[0033] The host can monitor the SSD's operating status by running a monitoring module. The SSD's operating status can be determined through various indicators, including health (such as lifespan percentage), performance (such as read and write error rates), abnormal events (such as speed drops and disk failures), and signs of failure (such as bad block growth).

[0034] See Figure 2 ,The operation monitoring module can use one or both of the two monitoring ,methods, smart attribute monitoring and predefined keyword parameter monitoring, to monitor the ,operation status of the solid state hard drive.

[0035] Smart attributes are built-in self-monitoring parameters of an SSD, including but not limited to read and write cycles, error rate, wear level, lifespan, and number of bad blocks. The SSD's main control chip continuously collects log data (referred to as smart attribute logs) for each smart attribute during operation. The operation monitoring module can obtain smart attribute logs by performing the following operations: First, obtain the SSD's operating drive letter from the system (referring to the host operating system), such as by executing lsblk in the system. After obtaining the SSD's operating drive letter, use the smartctl tool to obtain smart log data, such as by executing the command "smartctl –a / dev / sd*" (where / dev / sd* represents the specific drive letter obtained from the system).

[0036] Smart attribute log data can include information such as the smart attribute's attribute ID, attribute name, current attribute value, preset alarm threshold, and timestamp. The operation monitoring module can detect anomalies in each smart attribute log in various ways, such as by checking whether the attribute value is greater than or equal to a preset threshold or by checking whether the update frequency of the smart attribute value is abnormal (such as a rapid increase or decrease). The operation monitoring module records abnormal smart attribute logs as abnormal operation status logs.

[0037] In addition to monitoring the operating status of the SSD through smart attributes, the operation monitoring module also monitors the operating status of the SSD through system logs and SSD logs.

[0038] System logs are hardware events recorded by the operating system, such as / var / log / syslog in Linux and disk-related error codes in the Event Viewer in Windows. Solid-state drive (SSD) logs are private logs generated by the SSD's main control chip. These logs include, but are not limited to, FTL (Flash Translation Layer) mapping table errors, NAND (Not AND) write and erase counts, and power-off protection events.

[0039] The operation monitoring module periodically or irregularly obtains system logs and SSD logs, then uses predefined keyword parameters to traverse these logs to determine whether any logs contain the keyword parameters. If a log contains the keyword parameters, the operation monitoring module records them as abnormal operation status logs. These keyword parameters include, but are not limited to, hardware error, timeout, IO error, and link down. These keyword parameters can be defined based on the firmware fault that needs to be investigated and repaired, and can be supplemented or deleted based on actual needs.

[0040] In some embodiments, the step of monitoring the operating status of the solid-state drive includes: monitoring the smart properties of the solid-state drive, obtaining abnormal smart property logs as abnormal operating status logs; monitoring system logs and solid-state drive logs according to predefined keyword parameters, and obtaining logs containing keyword parameters from the system logs and solid-state drive logs as abnormal operating status logs.

[0041] The operation monitoring module uses two monitoring methods to monitor the operating status of the solid-state drive. By combining the smart attribute log, system log and solid-state drive log, the operating status of the solid-state drive can be monitored more comprehensively, while ensuring that abnormal operating status of the solid-state drive is discovered in time.

[0042] When the Operation Monitoring Module detects an abnormal smart log, system log, or SSD log, it triggers the Abnormal Log Acquisition Module. The Abnormal Log Acquisition Module transfers the abnormal logs detected by the Operation Monitoring Module to a pre-defined secure storage area on the host, preventing the loss of abnormal logs and the increased difficulty of problem analysis.

[0043] S120: When an abnormal operation status log is detected, a fault condition is determined according to the abnormal operation status log.

[0044] After detecting an abnormal operation status log, the abnormal log acquisition module will trigger the abnormal log analysis module, which will determine the fault condition based on the abnormal operation status log.

[0045] Fault conditions are specific abnormal phenomena directly reflected in abnormal operation status logs, such as a surge in the number of bad blocks or an abnormal increase in the lifespan count. The Abnormal Log Analysis Module analyzes abnormal operation status logs to identify fault conditions. For example, it parses key fields in the abnormal operation status logs, matches the key field information with predefined fault identification rules, and determines the fault condition based on the matching results. For example, if the lifespan count (i.e., the attribute value of the lifespan) increases abnormally, the Abnormal Log Analysis Module analyzes the abnormal operation status logs and obtains the information that "the lifespan count increases by 140% in a single day." Assuming the predefined fault identification rule is "when the lifespan count increases by more than 100% in a single day, an abnormal increase in the lifespan count is determined," the module matches the daily increase in the lifespan count to 140%, which meets the criteria for a daily increase in the lifespan count exceeding 100%. Therefore, the module can determine that the lifespan count has increased abnormally.

[0046] S130: Obtaining a code related to the fault condition from the current version of the solid state drive firmware as a target code; analyzing the target code to determine the cause of the fault.

[0047] After the abnormal log analysis module determines the fault condition by analyzing the abnormal operation status log, it will actively obtain the current version of the solid-state drive's firmware (i.e., the current version of the firmware code) and obtain the code related to the fault condition for subsequent analysis. These codes can be called target codes. For example, when it is determined that the service life of the solid-state drive has a counting abnormality, the service life algorithm logic is obtained from the current version of the solid-state drive's firmware as the target code. Among them, when obtaining the target code, the abnormal log analysis module can first back up the current version of the firmware file, and then parse the backed up current version of the firmware file to obtain the current version of the firmware and obtain the target code from it. It does not directly perform file parsing and code extraction operations on the current version of the firmware file, which can avoid these operations from affecting the operation of the solid-state drive.

[0048] The cause of a fault is the root cause of the problem, which could be a problem with underlying code logic or hardware. The specific cause of the fault needs to be determined by analyzing the target code. This can be done by performing inference analysis on the target code to identify any logical errors. If a logical error exists, the cause of the fault can be located based on the error.

[0049] For example, if the SSD's service life (percerntage used) count increases abnormally, this is usually due to a problem with the firmware (FW)'s SSD service life algorithm logic. The reasons may be: (1) abnormal bad block replacement. Bad blocks should be replaced after they occur. If spare blocks cannot be replaced after a bad block occurs, the bad blocks are directly counted as NAND loss. It may also be (2) an imperfect garbage collection mechanism, which causes some blocks to be consumed too quickly. After confirming an abnormal increase in the lifespan count, the target code's bad block replacement code (hereinafter referred to as the bad block replacement code) can be analyzed to see whether it can successfully replace the bad block with a spare block. If it cannot, the fault can be determined to be caused by an anomaly in the bad block replacement code. If it can successfully replace the bad block with a spare block, the target code's garbage collection mechanism code (hereinafter referred to as the garbage collection mechanism code) can be analyzed to see if there is an issue. For example, the garbage collection mechanism code's design for the frequency and timing of garbage collection within the SSD can be analyzed to see if it is appropriate. If the garbage collection mechanism code can trigger the garbage collection mechanism when the SSD is writing at full speed, can perform garbage collection at a high frequency, and can perform garbage collection at a regular interval, then the design can be determined to be appropriate. Otherwise, the design can be determined to be inappropriate. If the design is inappropriate, the garbage collection mechanism may accelerate the consumption of the SSD's lifespan, and the fault can be determined to be caused by an anomaly in the garbage collection mechanism code.

[0050] For example, if the cumulative number of error entries (num_err_log_entries) in the smart attribute log of an NVMe (Non-Volatile Memory Express) solid-state drive is abnormal (usually considered abnormal when the attribute value is greater than or equal to 1), this is usually because the SSD's main control chip received a command from the host requesting access to the SSD with invalid parameters. Upon receiving this command, the main control chip records it in the SMART LOG ERROR ENTRY (SMARTLOG ERROR ENTRY refers to the log entry in the NVMe SSD that records error events and health abnormalities during SSD operation and is a key component of SMART self-monitoring, analysis, and reporting technology) and increments the cumulative number of error entries. The target code can be analyzed for issues with the counting strategy for the cumulative number of error entries. For example, if the main control chip receives an SSD access command from the host with invalid parameters, does it increment the cumulative number of error entries? If so, the counting strategy for the cumulative number of error entries is abnormal.

[0051] In some embodiments, codes related to the fault condition are obtained from the current version of the solid-state drive firmware, including: when the abnormal operating status log comes from the system log, detecting whether the fault condition belongs to a solid-state drive failure; when the fault condition belongs to a solid-state drive failure, obtaining codes related to the fault condition from the current version of the firmware.

[0052] When an abnormal system log is detected using predefined keyword parameters, the abnormal log analysis module needs to first determine whether the abnormal situation points to the solid-state drive end (that is, the fault situation belongs to a solid-state drive fault). If not, it will be ignored and no fault repair process will be performed. If it points to the solid-state drive end, the fault repair process will be performed (including the relevant operations of steps S130 to S160). For example, based on the host-side slot information, busid information, etc. in the abnormal system log, it is analyzed that the error location point is not the solid-state drive, that is, the predefined keyword parameters are abnormal and it is not a disk-side error, then the problem can be ignored. Slot information refers to the physical slot position of the hardware (such as a PCIe device) where the abnormality occurs on the host (motherboard). Busid information refers to the bus identifier (such as PCIe bus number, device number, function number) where the abnormal hardware is located.

[0053] This embodiment takes into account that not all anomalies recorded in the system log need to be processed by the SSD firmware. Therefore, after determining the fault condition, the abnormal log analysis module first determines the source of the fault condition. Only when it is clear that the fault condition originates from the SSD firmware will it perform subsequent repair processing. This ensures that only faults caused by the SSD itself are repaired, effectively avoiding unnecessary and even potentially harmful "repair" operations on the SSD's own problems (such as host bus problems, other device problems, and driver problems), thereby improving the stability and reliability of the system.

[0054] S140: Generate optimized code according to the cause of the fault, replace the target code in the current version of the firmware with the optimized code, and obtain the latest version of the firmware.

[0055] After the exception log analysis module determines the cause of the failure, it will optimize the exception code (such as the abnormal bad block replacement code, garbage collection mechanism code, and the counting strategy code for the cumulative number of error entries). The purpose of optimization is to generate optimized code for repairing the failure.

[0056] For example, suppose the fault condition is an abnormal increase in the service life (percerntage used) count of the solid-state drive, and the fault cause is abnormal bad block replacement, that is, the spare block cannot be replaced after the bad block occurs, causing the bad block to be directly counted as NAND loss. At this time, the bad block replacement code in the target code can be optimized so that the new bad block replacement code can successfully replace the bad block with the spare block after the bad block occurs.

[0057] For another example, suppose the fault condition is an abnormal count of the cumulative number of error entries, and the cause of the fault is a problem in the counting strategy code for the cumulative number of error entries. At this time, the counting strategy code can be optimized so that when the main control chip executes the new counting strategy, when it receives an instruction from the host side to access the solid-state drive with invalid parameters, the count of the cumulative number of error entries will no longer be increased.

[0058] In some embodiments, the exception log analysis module can present abnormal code for R&D personnel to resolve, allowing them to review and optimize the code logic and upload the optimized code they wrote to the host. The exception log analysis module can also call on the host's integrated automatic code analysis and processing tool to automatically analyze the problems in the abnormal code and automatically write optimized code. The automatic code analysis and processing tool can be a large language model.

[0059] After obtaining the optimized code, replace the target code in the current version of the firmware with the optimized code to obtain the latest version of the firmware, that is, the latest version of the firmware code.

[0060] S150: Compile the latest version of the firmware to generate the latest version of the firmware file.

[0061] After the Abnormal Log Analysis Module obtains the latest firmware version, it triggers the FW Compilation Module. The FW Compilation Module recompiles the latest firmware version to generate a new firmware file, the latest firmware version.

[0062] S160: Verify whether the latest version of the firmware file can successfully repair the fault. If the verification result is that the repair fails, record the number of repairs. If the number of repairs is less than a preset threshold, return to the step of determining the fault according to the abnormal operation status log.

[0063] The FW verification module verifies the latest version of the firmware file generated by the FW compilation module to determine whether the latest version of the firmware file can successfully repair the fault.

[0064] In some embodiments, verifying whether the latest version of the firmware file can successfully repair the fault condition includes: determining other solid-state drives that are currently idle based on the real-time read and write status of each other solid-state drive as the target idle solid-state drive; performing a load test on the latest version of the firmware file on the target idle solid-state drive; and determining a verification result of the latest version of the firmware file based on the load test result.

[0065] Before applying the latest firmware version, the FW verification module verifies the latest version to ensure it not only fixes previously identified faults but also runs stably under real workloads without introducing new issues or causing performance degradation. Only then is the latest version officially deployed on SSDs in production environments.

[0066] Performing verification on busy SSDs in a production environment can cause service interruptions or performance degradation. Therefore, the FW verification module selects idle SSDs in the same environment as the SSD (such as a server or storage array) as the carrier for verifying the latest firmware version. Subsequent verification operations will use these SSDs. By pre-testing on a non-production, idle spare drive, you can avoid the potentially disastrous consequences (such as data loss, service interruption, and drive damage) of directly flashing unverified new firmware to production drives running critical business operations.

[0067] Among them, whether other solid-state drives are idle can be determined by whether they are performing reading or writing, and then a target idle solid-state drive is selected from these other solid-state drives. In some embodiments, determining other solid-state drives that are currently idle as target idle solid-state drives based on the real-time reading and writing status of each other solid-state drive includes: detecting whether each other solid-state drive is performing reading or writing operations, marking other solid-state drives that are performing reading or writing operations as busy, and marking other solid-state drives that are not performing reading or writing operations as idle; when the proportion of other solid-state drives in the idle state to the total number of other solid-state drives is greater than a first threshold, selecting a target idle solid-state drive from the solid-state drives in the idle state; when the proportion of other solid-state drives in the busy state to the total number of other solid-state drives is greater than a second threshold, detecting whether the sum of the current write speeds of all other solid-state drives is less than the sum of the write upper limit standard values ​​of all other solid-state drives; if so, transferring the write volume of some other solid-state drives in the busy state to other other solid-state drives in the busy state, so that the other solid-state drives in the busy state are switched to the idle state, and selecting the target idle solid-state drive from the other solid-state drives that are currently idle.

[0068] In this embodiment, it is possible to detect whether each of the other solid-state hard disks is performing a read or write operation (referring to a read or write operation). For any of the other solid-state hard disks, if the hard disk is performing a read or write operation, it indicates that the hard disk is in a busy state; if the hard disk is not performing a read or write operation, it indicates that the hard disk is in an idle state. If the proportion of the other solid-state hard disks in the idle state exceeds a preset first threshold (such as 60%) among the total number of other solid-state hard disks, some or all of the hard disks (the specific number is determined based on the verification requirements, and this embodiment does not impose a special limit on the specific number) from the other solid-state hard disks that are currently in an idle state can be selected as carriers for subsequent verification operations. When most or even all of all other solid-state drives (i.e., the proportion of other solid-state drives in a busy state is greater than the second threshold value, and the second threshold value and the first threshold value may be the same or different, for example, also 60%) are performing read and write operations, it is possible to detect whether the sum of the current write speeds of all other solid-state drives reaches the sum of the write upper limit standard values ​​of all other solid-state drives. If not, the write amount can be actively concentrated on a part of the other solid-state drives. This operation will increase the write load of these other solid-state drives, but at the same time it will also make another part of the other solid-state drives idle. At this time, the target idle solid-state drive can be selected from the other solid-state drives that are currently idle as the carrier for subsequent verification operations.

[0069] After selecting the target idle SSD, the latest version of the firmware file is flashed to the target idle SSD, and then the target idle SSD is load tested, that is, a simulated workload is applied to the target idle SSD. The load test includes: simulating normal read and write operations (such as sequential read or write, random read or write); simulating high-stress, high-concurrency read and write operations; attempting to reproduce the previously identified fault conditions to detect whether the latest version of the firmware file can actually fix the fault condition. During the load test, logs can be collected and a variety of preset indicators can be monitored, including performance indicators (such as bandwidth, latency, etc.), stability-related indicators (such as whether errors, crashes, abnormal logs, etc.), power consumption, and temperature. These logs and indicator data can be used as load test results. Based on the load test results, it can be determined whether the latest version of the firmware file can fix the fault. If the latest version of the firmware file can run stably, the performance meets expectations, the fault can be successfully fixed, and no new serious problems are introduced, then the verification result of the latest version of the firmware file can be determined to be a successful repair. Conversely, if the latest version of the firmware file behaves unstablely (such as crashing, reporting errors), has significantly degraded performance, fails to fix the fault, or introduces new faults or problems, then the verification result of the latest version of the firmware file can be determined to be a failed repair.

[0070] Before applying the latest firmware version, it is verified. If verification fails, the system will return to the process of determining the fault condition based on abnormal operation status logs to perform a remediation cycle. This remediation cycle continues until the repair is successful or the number of repair attempts reaches a preset threshold. Only the latest firmware version that has successfully verified is applied. This minimizes the risk of firmware upgrades, ensures reliable operation in production environments, and avoids the potential for further problems caused by hasty deployment of defective firmware.

[0071] If the FW verification module verifies that the repair is successful, it triggers the repair confirmation module. The repair confirmation module then performs an online firmware upgrade for other SSDs with the same specifications as the SSD using the latest firmware version. If an SSD fails due to a firmware issue, timely firmware updates for other SSDs can prevent similar failures in other SSDs.

[0072] After the repair confirmation module completes the online firmware upgrade for other SSDs, it triggers the user notification module, which notifies the customer of the successful repair of the fault condition via a pre-set notification method (e.g., email, SMS, etc.). If the repair fails the first time, the module records the number of repair attempts and restarts the exception log analysis module to analyze the problem and optimize the firmware compilation process, achieving multiple cycles of repair (the maximum number of repair attempts can be configured based on actual needs). If the fault remains unresolved after reaching the pre-set limit, the user notification module is triggered to promptly notify the user. If the fault condition is critical, or if the fault condition continues to fail after repeated repair cycles, the module provides further action suggestions, such as disk replacement.

[0073] In some embodiments, before verifying whether the latest version of the firmware file can successfully repair the fault condition, the method also includes: obtaining current data of a preset plurality of indicators related to the host load; judging whether the host is currently in a high-load state based on the current data of the plurality of indicators; when the host is in a high-load state, entering a waiting state, recording the fault condition and issuing an early warning message based on the fault condition; when the host is not in a high-load state, entering a step of verifying whether the latest version of the firmware file can successfully repair the fault condition.

[0074] See Figure 3 After the FW compilation module generates the latest version of the firmware file, the host-side storage device exploration and analysis module will first actively explore the current load operation status of the host side, such as obtaining the current data of multiple preset indicators related to the host load (such as CPU utilization, memory usage, IO latency, IO throughput, overall SSD utilization on the host, CPU temperature, etc.), and then combining the current data of these indicators with the preset host load status judgment rules to determine whether the host (i.e., the host side) is currently in a high-load state. For example, assuming that the host load status judgment rule is "when the overall SSD utilization on the host is greater than or equal to 60%, the host is determined to be in a high-load state", then if the overall SSD utilization on the current host is 80%, it can be determined that the host is in a high-load state.

[0075] If the host is determined to be under high load, the latest firmware version will not be verified and the system will enter a waiting state to prevent normal business operations from being affected by verification. Fault conditions can also be recorded and early warnings issued accordingly. While in the waiting state, the host-side storage device discovery and analysis module will continue to monitor the host's load status using metrics related to the host's load. Only when the host switches from a high load state to a low load state will the FW verification module be triggered to verify the latest firmware version.

[0076] The above operation can avoid performing firmware verification operations when the host is highly loaded, preventing system instability or business interruption due to additional test pressure. In addition, when the host is not highly loaded, the latest version of the firmware file can be verified by using the host's idle resources, which will not occupy offline resources and can save the cost of implementing verification operations.

[0077] It should be noted that, with respect to the various steps included in the solid-state drive fault repair method provided in any of the above embodiments, unless otherwise expressly stated herein, there is no strict order restriction on the execution of these steps, and these steps may be executed in other orders. Furthermore, at least some of these steps may include multiple sub-steps or multiple stages, and these sub-steps or stages do not necessarily need to be completed at the same time, but may be executed at different times. The execution order of these sub-steps or stages does not necessarily need to be sequential, but may be executed in rotation or alternation with other steps or at least some of the sub-steps or stages of other steps.

[0078] Based on the same inventive concept, the present application also provides a solid state drive fault repair device. In some embodiments, Figure 4 As shown, the solid state drive fault repair device includes the following modules:

[0079] The operating status monitoring module 110 is used to monitor the operating status of the solid-state hard disk during its operation;

[0080] The fault condition determination module 120 is configured to determine the fault condition according to the abnormal operation status log when an abnormal operation status log is detected;

[0081] The fault cause determination module 130 is configured to obtain a code related to the fault condition from the current version of the solid-state drive firmware as a target code; and analyze the target code to determine the cause of the fault;

[0082] The firmware optimization module 140 is used to generate optimized code according to the cause of the fault, and replace the target code in the current version of the firmware with the optimized code to obtain the latest version of the firmware;

[0083] Compilation module 150, used to compile the latest version of the firmware and generate the latest version of the firmware file;

[0084] Verification module 160 is used to verify whether the latest version of the firmware file can successfully repair the fault. When the verification result is that the repair fails, the number of repairs is recorded, and when the number of repairs is less than the preset number threshold, the step of determining the fault condition based on the abnormal operation status log is returned.

[0085] In some embodiments, the operating status monitoring module 110 includes:

[0086] The smart attribute monitoring submodule is used to monitor the smart attributes of the solid-state drive and obtain abnormal smart attribute logs as abnormal operation status logs;

[0087] The keyword parameter monitoring submodule is used to monitor the system log and the solid-state drive log according to the predefined keyword parameters, and obtain the log containing the keyword parameters from the system log and the solid-state drive log as the abnormal operation status log.

[0088] In some embodiments, the device further includes a host load detection module. The host load detection module is configured to obtain current data of multiple preset indicators related to the host load before verifying whether the latest version of the firmware file can successfully repair the fault; determine whether the host is currently in a high-load state based on the current data of the multiple indicators; if the host is in a high-load state, enter a waiting state, record the fault condition, and issue an early warning message based on the fault condition; and if the host is not in a high-load state, instruct the verification module 160 to enter the step of verifying whether the latest version of the firmware file can successfully repair the fault condition.

[0089] In some embodiments, the verification module 160 includes:

[0090] A verification carrier selection submodule is used to determine other solid-state drives that are currently idle as target idle solid-state drives based on the real-time read and write status of each other solid-state drive;

[0091] The load test submodule is used to perform load testing on the latest version of the firmware file on the target idle solid-state drive;

[0092] The verification result determination submodule is used to determine the verification result of the latest version of the firmware file based on the load test result.

[0093] In some embodiments, the verification vector selection submodule comprises:

[0094] A hard disk status marking unit is used to detect whether other solid-state hard disks are performing read and write operations, mark other solid-state hard disks that are performing read and write operations as busy, and mark other solid-state hard disks that are not performing read and write operations as idle;

[0095] a first verification carrier selection unit, configured to select a target idle solid-state hard disk from the idle solid-state hard disks when a proportion of the idle solid-state hard disks in the total number of the other solid-state hard disks is greater than a first threshold;

[0096] The second verification carrier selection unit is used to detect whether the sum of the current write speeds of all other solid-state drives is less than the sum of the write upper limit standard values ​​of all other solid-state drives when the proportion of other solid-state drives in a busy state in the total number of other solid-state drives is greater than a second threshold value. If so, the write amount of some of the other solid-state drives in a busy state is transferred to other other solid-state drives in a busy state, so that the other solid-state drives in this part are switched from a busy state to an idle state, and a target idle solid-state drive is selected from the other solid-state drives that are currently in an idle state.

[0097] In some embodiments, when the fault cause determination module 130 obtains the code related to the fault condition from the current version of the solid-state drive firmware, it is used to: when the abnormal operating status log comes from the system log, detect whether the fault condition belongs to a solid-state drive failure; when the fault condition belongs to a solid-state drive failure, obtain the code related to the fault condition from the current version of the firmware.

[0098] In some embodiments, the device further includes a firmware upgrade module configured to upgrade the firmware of other solid-state drives in use with the same specifications as the solid-state drive according to the latest firmware file when the verification result indicates that the repair is successful.

[0099] The specific definition of the solid-state drive fault repair device can be found in the definition of the solid-state drive fault repair method above and will not be repeated here. The various modules in the above-mentioned solid-state drive fault repair device can be implemented in whole or in part through software, hardware, or a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each of the above modules.

[0100] The present application also provides a computer device. In some embodiments, the computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the solid-state drive failure repair method provided in any of the above embodiments can be implemented.

[0101] In some embodiments, the internal structure diagram of the computer device can be as follows: Figure 5As shown. The computer device includes a processor, a memory and a network interface connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data such as sorting task information corresponding to the package. The specific stored data can also be found in the definitions in the above method embodiments. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a solid-state hard drive fault repair method is implemented.

[0102] Those skilled in the art will understand that Figure 5 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0103] The present application also provides a computer-readable storage medium. In some embodiments, a computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, the steps of the solid-state drive failure repair method provided in any of the above embodiments are implemented.

[0104] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0105] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the above-described method embodiments. Any reference to memory, storage, database, or other media used in the embodiments provided herein may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink), DRAM (SLDRAM), RAMbus, direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM).

[0106] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0107] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art may make various modifications and improvements without departing from the scope of the present application, and such modifications and improvements are all within the scope of protection of the present application.

Claims

1. A method for repairing a solid state hard drive failure, characterized in that: The method comprises: During the operation of the solid-state hard disk, monitoring the operating status of the solid-state hard disk; When an abnormal operation status log is detected, the fault condition is determined according to the abnormal operation status log; Obtaining code related to the fault condition from the current version of the solid-state drive firmware as a target code; analyzing the target code to determine the cause of the fault; Generate an optimized code according to the cause of the fault, and replace the target code in the current version of the firmware with the optimized code to obtain the latest version of the firmware; Compile the latest version of the firmware to generate a latest version of the firmware file; Verify whether the latest version of the firmware file can successfully repair the fault condition. When the verification result is that the repair fails, record the number of repairs, and when the number of repairs is less than a preset number threshold, return to the step of determining the fault condition based on the abnormal operation status log.

2. The method according to claim 1, characterized in that The monitoring of the operating status of the solid state drive includes: Monitoring the smart attributes of the solid-state drive and obtaining abnormal smart attribute logs as abnormal operation status logs; The system log and the solid-state drive log are monitored according to predefined keyword parameters, and logs containing the keyword parameters are obtained from the system log and the solid-state drive log as abnormal operation status logs.

3. The method according to claim 1, characterized in that Before verifying whether the latest version of the firmware file can successfully repair the fault condition, the method further includes: Get current data for multiple preset indicators related to host load; Determining whether the host is currently in a high load state based on current data of the multiple indicators; When the host is in a high-load state, it enters a waiting state, records the fault condition and issues an early warning message according to the fault condition; When the host is not in a high-load state, the step of verifying whether the latest version of the firmware file can successfully repair the fault condition is entered.

4. The method according to claim 1, wherein Verifying whether the latest version of the firmware file can successfully repair the fault condition includes: Determine other solid-state drives that are currently idle according to the real-time read and write status of each of the other solid-state drives as target idle solid-state drives; Performing a load test on the latest version of the firmware file on the target idle solid-state hard drive; The verification result of the latest version firmware file is determined according to the load test result.

5. The method according to claim 4, characterized in that The step of determining other solid-state drives that are currently idle as target idle solid-state drives based on the real-time read and write status of each of the other solid-state drives includes: Detecting whether each of the other solid-state hard disks is performing a read or write operation, marking the other solid-state hard disks that are performing a read or write operation as being in a busy state, and marking the other solid-state hard disks that are not performing a read or write operation as being in an idle state; When the proportion of the other solid-state hard disks in the idle state in the total number of the other solid-state hard disks is greater than a first threshold, selecting a target idle solid-state hard disk from the solid-state hard disks in the idle state; When the proportion of the other solid-state hard disks in a busy state in the total number of the other solid-state hard disks is greater than a second threshold, detect whether the sum of the current write speeds of all the other solid-state hard disks is less than the sum of the write upper limit standard values ​​of all the other solid-state hard disks. If it is less, transfer the write amount of part of the other solid-state hard disks in a busy state to other other solid-state hard disks in a busy state, so that the other solid-state hard disks in this part are switched from a busy state to an idle state, and select a target idle solid-state hard disk from the other solid-state hard disks that are currently in an idle state.

6. The method according to claim 2, characterized in that The obtaining of a code related to the fault condition from the current version of the solid state drive firmware includes: When the abnormal operation status log is from the system log, detecting whether the fault condition is a solid state hard disk fault; When the fault condition is a solid state drive fault, a code related to the fault condition is obtained from the current version of the firmware.

7. The method according to claim 1, characterized in that When the verification result is that the repair is successful, the method further includes: The firmware of other solid-state drives in use with the same specifications as the solid-state drive is upgraded according to the latest version firmware file.

8. A solid state hard disk fault repair device, characterized in that: The device comprises: An operating status monitoring module is used to monitor the operating status of the solid-state hard disk during its operation; A fault condition determination module is used to determine the fault condition according to the abnormal operation status log when an abnormal operation status log is monitored; a fault cause determination module, configured to obtain a code related to the fault condition from the current version of the solid-state drive firmware as a target code; and analyze the target code to determine the fault cause; a firmware optimization module, configured to generate an optimized code according to the cause of the fault, and replace the target code in the current version of the firmware with the optimized code to obtain the latest version of the firmware; A compiling module, used to compile the latest version of the firmware to generate the latest version of the firmware file; A verification module is used to verify whether the latest version of the firmware file can successfully repair the fault condition. When the verification result is that the repair fails, the number of repairs is recorded, and when the number of repairs is less than a preset number threshold, the step of determining the fault condition based on the abnormal operation status log is returned.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

Images