Solid state disk compatibility and reliability test method, device and storage medium

Abstract

The application discloses a solid state disk compatibility and reliability test method, equipment and storage medium, and the method comprises the following steps: acquiring abnormal events generated in the process that a host system accesses a solid state disk to be tested and recording the occurrence time; taking the occurrence time as a time anchor point, extracting a running state parameter set of the solid state disk to be tested inside in a corresponding specified time period; matching the running state parameter set with a plurality of preset fault characteristic models to determine the fault root cause type corresponding to the abnormal event; and outputting a root cause analysis result containing the fault root cause type. The plurality of fault characteristic models at least include a first type of fault model for representing physical layer abnormalities and a second type of fault model for representing firmware layer abnormalities. The application solves the technical problems that the system abnormalities are separated from the internal state of the SSD firmware in the prior art, and the fault root cause cannot be accurately positioned, and realizes the automatic root cause diagnosis and positioning of abnormal events in the solid state disk reliability test.

Description

Technical Field

[0001] This invention relates to the field of solid-state drive (SSD) reliability testing technology, and in particular to a method, device, and storage medium for SSD compatibility and reliability testing. Background Technology

[0002] In the development of solid-state drives (SSDs), firmware reliability testing is a crucial step in ensuring the quality of mass production. However, during the firmware testing and verification phase, when abnormal events such as I / O timeouts or device resets occur, the core challenge faced by developers is the inability to quickly and accurately pinpoint the root cause of these events.

[0003] Specifically, the existing technology has the following drawbacks: First, there is a severe disconnect between system anomalies and the internal firmware state of the SSD on the timeline. When an I / O timeout or device reset occurs, current technology can only provide system-level log information, but cannot reveal the internal operating state of the SSD firmware at the time of the anomaly. For example, it cannot determine whether the firmware is performing intensive garbage collection (GC), whether the number of error correction iterations for NAND reads is abnormally high, or whether the write amplification factor has increased sharply. This information asymmetry—where the system can see the anomaly but the internal firmware state is not—often requires developers to spend days or even weeks repeatedly reproducing the problem and manually comparing data to pinpoint the root cause.

[0004] Secondly, anomaly localization relies on manual experience, which is inefficient and prone to misjudgment. Engineers need to manually check system logs to obtain anomaly timestamps, then review firmware operation logs to find the corresponding status records at that time, and manually compare them to infer the cause of the fault. When anomalies are caused by a combination of factors, manual judgment is very likely to misjudge physical layer problems as firmware layer problems, or vice versa, leading to incorrect optimization directions.

[0005] Third, existing general-purpose testing tools can only obtain externally observable data such as SMART through standard interfaces, and cannot delve into the SSD firmware to obtain internal state parameters such as FTL mapping table fragmentation rate, GC frequency, and error correction iteration count. For R&D teams developing their own SSDs, the internal state of the firmware is completely open, but existing technologies do not provide a systematic method for using this "white-box privilege" to perform accurate root cause diagnosis.

[0006] Fourth, existing diagnostic solutions cannot distinguish between physical layer faults and firmware layer faults. Existing technologies can only identify the presence of faults, but cannot differentiate whether the fault originates from NAND physical layer signal distortion (such as high temperature causing increased read interference) or firmware layer anomalies (such as improper GC strategy configuration causing user I / O preemption), thus limiting their guiding value for firmware tuning. Summary of the Invention

[0007] In view of this, the present invention provides a method, device and storage medium for testing the compatibility and reliability of solid-state drives to solve the above problems.

[0008] To solve the above-mentioned technical problems, one technical solution adopted by the present invention is: to provide a method for testing the compatibility and reliability of solid-state drives, comprising: Acquire abnormal events generated by the host system during access to the tested solid-state drive, and record the time of occurrence of the abnormal events; Using the moment of occurrence as the time anchor, extract the set of operating status parameters inside the tested solid-state drive within the specified time period corresponding to the time anchor; Based on the set of operating status parameters, the system matches them with multiple preset fault feature models to determine the type of fault root cause corresponding to the abnormal event; among them, the multiple fault feature models include at least a first type of fault model for characterizing physical layer abnormalities and a second type of fault model for characterizing firmware layer abnormalities. The output includes root cause analysis results containing the types of root causes of the faults.

[0009] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is: to provide a solid-state drive compatibility and reliability testing device, comprising: The acquisition module is used to acquire abnormal events generated by the host system during access to the solid-state drive under test, and record the time of occurrence of the abnormal events; The extraction module is used to extract the set of operating status parameters inside the tested solid-state drive within a specified time period corresponding to the time anchor point, using the time of occurrence as the time anchor point. The matching module is used to match the set of running status parameters with a variety of preset fault feature models to determine the fault root cause type corresponding to the abnormal event; wherein, the variety of fault feature models includes at least a first type of fault model for characterizing physical layer abnormalities and a second type of fault model for characterizing firmware layer abnormalities. The output module is used to output root cause analysis results that include the root cause type of the fault.

[0010] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is to provide a computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the program to implement the solid-state drive compatibility and reliability testing method as described above.

[0011] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is to provide a computer-readable storage medium storing a computer program thereon, wherein the program, when executed by a processor, implements the solid-state drive compatibility and reliability testing method as described above.

[0012] Compared to existing technologies, this invention uses the occurrence time of system anomalies as a time anchor point to automatically trace back the set of operating state parameters within the SSD firmware during the fault window. Through a dual-path judgment architecture composed of a preset physical layer fault model and a firmware layer fault model, it achieves accurate identification of the root cause type of the fault—clearly distinguishing whether the fault originates from NAND physical layer signal distortion or firmware layer GC scheduling anomalies. This elevates fault diagnosis from "detecting the existence of anomalies" to "locating the root cause of anomalies," effectively improving the technical shortcomings of existing technologies where system logs and internal firmware states are disconnected. Simultaneously, this invention employs an event-triggered automated backtracking mechanism, replacing the inefficient traditional method of relying on engineers to manually review logs and compare timestamps, significantly reducing the time cost of fault diagnosis. Furthermore, since the diagnostic conclusions can precisely point to specific problematic modules in the physical or firmware layers, firmware developers can formulate targeted optimization solutions, avoiding the waste of R&D resources due to directional misjudgments. This invention constructs a complete diagnostic chain from anomaly triggering, state backtracking, model matching to root cause output, providing systematic technical support for the reliability verification of self-developed solid-state drives. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating one embodiment of the solid-state drive compatibility and reliability testing method of the present invention.

[0014] Figure 2 This is a functional module diagram of one embodiment of the solid-state drive compatibility and reliability testing device of the present invention.

[0015] Figure 3 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention.

[0016] Figure 4 This is a schematic diagram of the structure of a computer-readable storage medium according to an embodiment of the present invention. Detailed Implementation

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

[0018] The terms "first," "second," and "third" used in this invention are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified. All directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of this invention are only used to explain the relative positional relationships and movements between components in a specific orientation (as shown in the figures). If the specific orientation changes, the directional indications also change accordingly. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0019] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0020] Figure 1 This is a flowchart illustrating the solid-state drive compatibility and reliability testing method according to an embodiment of the present invention. It should be noted that if substantially the same results are obtained, the method in this embodiment is not necessarily identical. Figure 1 The illustrated process sequence is limited. For example... Figure 1 As shown, the solid-state drive compatibility and reliability testing method includes the following steps: Step S1: Obtain abnormal events generated by the host system during access to the tested solid-state drive, and record the time of occurrence of the abnormal events.

[0021] In this embodiment, the solid-state drive (SSD) under test is mounted on the server motherboard and connected to the host system via a standard bus interface (such as PCIe). After the host operating system boots up, it accesses the SSD under test for read and write operations through the file system or as a raw device. During the test, the interaction status between the host system and the SSD under test is continuously monitored.

[0022] The system log monitoring interface captures abnormal events generated by the host system during access to the tested SSD in real time. These abnormal events include, but are not limited to, I / O timeouts, device resets, and command execution failures. Whenever any of these abnormal events is captured, the occurrence time of the event is automatically recorded with an accuracy of at least milliseconds. This moment serves as the time reference point for subsequent backtracking operations.

[0023] Step S2: Using the time of occurrence as the time anchor, extract the set of operating status parameters inside the tested solid-state drive within the specified time period corresponding to the time anchor.

[0024] In this embodiment, the time of occurrence of the abnormal event is used as the time anchor point. An internal status read request is sent to the firmware of the solid-state drive under test to extract the set of operating status parameters of the solid-state drive under test within the specified time period corresponding to the time anchor point.

[0025] The specified time period includes a period of time before and / or after the occurrence time. The set of operating status parameters includes multiple parameters that can reflect the operating status of the physical layer and firmware layer of the solid-state drive, such as internal temperature, write amplification factor, and number of error correction iterations. These parameters are continuously recorded in advance by the solid-state drive firmware in the internal storage area of ​​the firmware in a circular cache manner.

[0026] Step S3: Based on the set of operating status parameters, match them with a variety of preset fault feature models to determine the type of fault root cause corresponding to the abnormal event.

[0027] In this embodiment, the extracted set of operating status parameters is matched with multiple preset fault feature models, and the fault root cause type corresponding to the abnormal event is determined based on the matching result.

[0028] The multiple fault characteristic models include at least a first type of fault model for characterizing physical layer anomalies and a second type of fault model for characterizing firmware layer anomalies. The first type of fault model is determined based on physical layer-related state parameters, while the second type of fault model is determined based on firmware layer-related state parameters. Each fault model has pre-defined corresponding determination conditions and rules.

[0029] Step S4: Output the root cause analysis results, including the type of the fault root cause.

[0030] In this embodiment, after matching is completed, a root cause analysis result containing the type of the fault root cause is output. The root cause analysis result includes at least the type of the abnormal event, the type of the fault root cause, and key state parameter information that triggered the matching. This completes a full diagnostic process from anomaly triggering to root cause output.

[0031] This embodiment uses the occurrence time of a system anomaly as a time anchor point to automatically trace back the set of operating state parameters within the SSD firmware during the fault window. Through a dual-path judgment architecture composed of a preset physical layer fault model and a firmware layer fault model, it achieves accurate identification of the root cause type of the fault—clearly distinguishing whether the fault originates from NAND physical layer signal distortion or firmware layer GC scheduling anomalies. This elevates fault diagnosis from "detecting the existence of anomalies" to "locating the root cause of anomalies," effectively improving the technical shortcomings of existing technologies where system logs and internal firmware states are disconnected. Simultaneously, this invention employs an event-triggered automated backtracking mechanism, replacing the inefficient traditional method of relying on engineers to manually review logs and compare timestamps, significantly reducing the time cost of fault diagnosis. Furthermore, since the diagnostic conclusions can precisely point to specific problematic modules in the physical or firmware layers, firmware developers can formulate targeted optimization solutions, avoiding the waste of R&D resources due to directional misjudgments. This invention constructs a complete diagnostic chain from anomaly triggering, state backtracking, model matching to root cause output, providing systematic technical support for the reliability verification of solid-state drives.

[0032] Furthermore, in order to ensure that physical layer faults and firmware layer faults can be accurately distinguished and to avoid misjudgments caused by parameter cross-influence, in other embodiments based on the above embodiments, the set of operating status parameters includes the internal temperature of the solid-state drive under test, the write amplification factor, and the number of LDPC error correction iterations. The first type of fault model is configured as follows: when the number of LDPC error correction iterations exceeds the LDPC iteration number threshold and the internal temperature exceeds the temperature threshold, the fault root cause type is determined to be NAND physical layer signal distortion. The second type of fault model is configured as follows: when the write amplification factor exceeds the write amplification factor threshold, the fault root cause type is determined to be firmware layer anomaly. Specifically, when the number of LDPC error correction iterations exceeds the LDPC iteration number threshold and the internal temperature exceeds the temperature threshold, the root cause of the fault is locked as NAND physical layer signal distortion.

[0033] Specifically, the operational status parameter set includes three core parameters: internal temperature, WAF (Write Amplification Factor), and LDPC (Low-Level Processing) error correction iteration count. Internal temperature is a key environmental factor affecting the physical characteristics of NAND flash memory. It should be noted that the internal temperature here refers to the temperature monitored near the SSD controller or NAND flash memory chips, not the SSD casing temperature or ambient temperature. The LDPC error correction iteration count is an important indicator of NAND physical layer signal quality. When signal quality is good, the LDPC decoder requires fewer iterations; when signal quality deteriorates due to increased temperature, read interference, or wear, the iteration count increases significantly. The write amplification factor (WAF = NAND physical writes / host logical writes) is a core indicator of firmware GC stress. When firmware performs frequent GC, the WAF increases significantly.

[0034] The first type of fault model is configured as follows: when the number of LDPC error correction iterations exceeds the LDPC iteration threshold and the internal temperature exceeds the temperature threshold, it is determined to be NAND physical layer signal distortion. The methods for setting the LDPC iteration threshold and temperature threshold are as follows: Based on statistical analysis of test data from the same batch of samples within the normal operating temperature range, both the LDPC error correction iteration number and temperature are within a relatively stable distribution range. The LDPC iteration threshold and temperature threshold are respectively set to the critical values ​​that cause a statistically significant increase in the LDPC error correction iteration number and internal temperature. Specifically, the setting method can adopt the 3σ principle (taking three times the standard deviation above the normal distribution mean as the threshold), or be based on industry-standard empirical thresholds. Under different NAND flash memory types and different firmware ECC schemes, the absolute values ​​of the above thresholds may differ, but the setting methods are consistent.

[0035] The second type of fault model is configured as follows: when the WAF exceeds the write amplification factor threshold, it is determined to be a firmware layer anomaly. The write amplification factor threshold is set as follows: based on statistical analysis of the WAF distribution of samples in the same batch under the target write load type, under steady-state random write conditions, the WAF is within a relatively stable normal range. The write amplification factor threshold is set to the critical value that causes a statistically significant increase in WAF. The absolute value of this critical value may differ significantly under different write load types, but the setting method is consistent.

[0036] Judgment rule: When the number of LDPC error correction iterations exceeds the LDPC iteration threshold and the internal temperature exceeds the temperature threshold, it is directly identified as NAND physical layer signal distortion. WAF does not constitute an influencing factor in this judgment path. It is important to understand that physical layer signal distortion is the root cause, and the increase in WAF is a secondary effect caused by physical layer anomalies. Therefore, directly locking the conclusion on the physical layer when the physical layer judgment conditions are met can effectively avoid misjudgments due to reversed causality and guide R&D personnel to prioritize investigating NAND particle characteristics or temperature management solutions.

[0037] This embodiment concretizes the set of operating status parameters into three quantifiable parameters: temperature, WAF, and LDPC, and concretizes the fault model into logic with clear judgment rules, thereby achieving accurate differentiation between physical layer faults and firmware layer faults.

[0038] Furthermore, in order to ensure that firmware internal state data within a sufficient time window before and after the anomaly can be obtained, and to avoid the loss of critical information due to the overwriting of data in the circular cache, in other embodiments based on the above embodiments, the specified time period includes N seconds before the time of the anomaly event to M seconds after the time of the event.

[0039] In this embodiment, the specified time period includes N seconds before the occurrence of the abnormal event and M seconds after. In this embodiment, N is set to 5 seconds and M is set to 5 seconds, that is, the total time window is from T0-5s to T0+5s, a total of 10 seconds.

[0040] The forward 5 seconds (T0-5s to T0) cover the "precursor period" of abnormal events. Most firmware anomalies (such as GC pressure accumulation, gradual temperature increase, and gradual increase in LDPC iterations) have been ongoing for some time before triggering an IO timeout, and the forward 5 seconds are sufficient to capture these precursory characteristics. The backward 5 seconds (T0 to T0+5s) cover the "recovery period" of abnormal events. After an IO timeout occurs, the firmware may perform device reset or recovery operations, and the backward 5 seconds can record the state changes of these recovery behaviors.

[0041] Step S2, which involves extracting the set of operating status parameters from the solid-state drive under test within a specified time period corresponding to the time anchor point, specifically includes: 1. Using the occurrence time of the abnormal event as an index, read the time series data within a specified time period from the internal circular cache of the firmware of the solid-state drive under test. The circular cache samples each parameter in the running status parameter set with millisecond precision and records the summary value of each sampling point with second as the storage granularity.

[0042] 2. When an abnormal warning is triggered before the abnormal event occurs, the internal state snapshot at the time of triggering the abnormal warning is persistently stored in the non-volatile storage area. The running state parameter set also includes the persistently stored snapshot data.

[0043] Specifically, the firmware of the tested SSD maintains a circular buffer that continuously records key state parameters during firmware operation. The firmware internally samples with millisecond precision (e.g., instantaneous values ​​are collected every 10ms), but the circular buffer stores data at a granularity of once per second (taking the maximum value or 95th percentile of each sample point within that second) to capture transient peak anomalies that may trigger I / O timeouts. It's worth noting that choosing the maximum value or quantile, rather than the average, more effectively preserves abnormal transient characteristics and prevents peaks from being masked by smoothing. The buffer size is designed to store at least 30 seconds of complete state data (one data point per second) to ensure that data from both the preceding and following 5 seconds are available when backtracking is triggered at any time.

[0044] Using the occurrence time of the abnormal event as an index, the test program reads data from the circular buffer through the following steps: (1) The test program sends a read request to the SSD firmware through the NVMe vendor's custom command. The request parameters include the time anchor T0 and the window range (N=5 seconds, M=5 seconds). (2) After receiving the request, the SSD firmware locates the corresponding data entry in the circular cache using T0 as the index; (3) The firmware reads data from T0-5s to T0+5s continuously, and packages a total of 11 data points (one per second) and returns them to the test program. (4) Each data point includes the internal temperature, WAF and LDPC error correction iterations at that second.

[0045] The data preservation mechanism when an anomaly warning is triggered before the anomaly event occurs is as follows: In some cases, the system may have already triggered anomaly alerts through other monitoring methods before an I / O timeout occurs. Alert sources include: (1) Anomaly warning based on GC / FTL threshold (triggered when GC frequency exceeds preset threshold or FTL fragmentation rate exceeds preset threshold). (2) SMART trend warning based on machine learning (triggered when the growth slope of the SMART attribute exceeds the dynamic threshold).

[0046] When any of the above warnings is triggered, the system immediately performs the following operations: persistently stores a snapshot of the current internal state in non-volatile storage: (1) Record the millisecond-level timestamp of the warning time T1; (2) Pack the state parameters such as internal temperature, WAF, LDPC error correction iteration count, GC frequency, and FTL fragmentation rate at time T1; (3) Detect the current state of the SSD: If the device can still respond to the command normally (i.e., it is not in an unrecoverable error state), the data packet is stored in the reserved non-volatile storage area of ​​the SSD firmware; if the device is in an unrecoverable state, persistent storage is abandoned and the failure state is recorded. At this time, only the data already in the circular cache is used for backtracking.

[0047] It's important to understand that the two early warning mechanisms complement each other. Rule-based early warnings can quickly respond to real-time anomalies, while machine learning-based early warnings can identify long-term degradation trends in advance. A snapshot of each early warning trigger is retained to ensure that, in the event of a subsequent IO timeout, the backtracking data contains all the information about the anomaly precursors.

[0048] When an IO timeout exception occurs subsequently, the backtracking process in step S2, in addition to reading the data from the circular buffer for T0±5s, will also automatically check whether there is a warning snapshot in persistent storage. If it exists and T1 falls within the time window of T0±5s, the warning snapshot data will be included in the runtime status parameter set as supplementary evidence for root cause determination.

[0049] This embodiment uses a 5-second time window design before and after the event and a circular buffer mechanism to ensure that the firmware's internal state data within a sufficient time window before and after the occurrence of an abnormal event can be completely traced back. Furthermore, the snapshot persistence storage triggered by the two early warning mechanisms ensures that different types of abnormal precursors can be preserved, thus avoiding the risk of data loss.

[0050] Furthermore, in order to proactively create test conditions during the testing phase that can trigger the SSD firmware to expose defects under low-power S0 state and high-load I / O concurrency scenarios, in addition to the above embodiments, other embodiments further include the following step before step S1: 1. Triggers the host system to enter the S0 low-power state.

[0051] Specifically, S0 (Modern Standby) is a low-power idle state defined in the ACPI specification, in which the system maintains network connectivity and can be quickly woken up. In this embodiment, the system is triggered to enter the S0 state in the following way: In Linux systems, the process of entering the S0ix (frozen merge) state is initiated by writing the `freeze` command to ` / sys / power / state`: echo freeze> / sys / power / state; This command causes the system kernel to freeze all user-space processes, attempting to put the system into a low-power state.

[0052] 2. Monitor the sub-state changes of the S0 low-power state and dynamically adjust the read / write load intensity of the tested solid-state drive based on the sub-state changes.

[0053] Specifically, after the system enters the S0 state, it still contains several sub-states, including different power consumption levels such as "screen off but network active" and "lowest power consumption". To detect changes in these sub-states, the test program utilizes the following methods: (1) Power state change events are obtained by listening to the DBus signal of systemd-logind. The test program subscribes to the PrepareForSleep signal of the org.freedesktop.login1.Manager interface. The signal returns True when the system is about to enter sleep mode; the signal returns False when the system resumes (wakes up) from sleep mode.

[0054] (2) Use the power status file under / sys / power / for auxiliary judgment.

[0055] Based on real-time awareness of the S0 sub-state, the test program dynamically adjusts the read / write load intensity on the tested SSD. The specific strategy is as follows: (1) When the system is detected to be in the "screen off but network active" sub-state of S0, inject a medium-intensity random read / write load. This scenario simulates the typical working condition where the system is still performing lightweight IO operations such as application updates and email synchronization in the background after the user closes the lid; (2) When it is detected that the system is about to enter the lowest power sub-state of S0 (for example, by capturing the PrepareForSleep(true) event through the DBus signal), before the system actually enters the lowest power state, inject sequential write load to simulate the working condition of writing large blocks of data during system hibernation dump or memory swapping operation. (3) When the system is detected to wake up from the S0 state (by capturing the PrepareForSleep(false) event via the DBus signal), a high queue depth of random read / write load is immediately injected after the wake-up signal is issued. This scenario simulates a sudden surge in I / O operations initiated by a user after waking up the computer.

[0056] This embodiment achieves a leap from "static concurrency" to "dynamic game theory" through S0 state-aware dynamic load adjustment. The test load can be adjusted in real time according to changes in the S0 sub-state, simulating the complex changes in background tasks under different power consumption states when a user is using a computer. Compared with traditional fixed load testing, the dynamic load of this embodiment can more effectively expose timing vulnerabilities and concurrency processing defects in SSD firmware under power state switching scenarios.

[0057] Furthermore, different hardware platforms have varying degrees of support for S0ix (Modern Standby). To adaptively select the most suitable low-power state for testing based on platform capabilities, this embodiment includes a platform adaptation step before triggering the host system to enter the low-power state: 1. Write a freeze merge command to the operating system power management interface to attempt to trigger the system to enter the S0ix state.

[0058] 2. After a preset time following the trigger, read the system's low-power state dwell time.

[0059] 3. If the dwell time increases before and after the trigger, it is determined that the system has actually entered the S0ix state.

[0060] 4. If the dwell time does not increase before and after the trigger, it is determined that the system has failed to enter the S0ix state, and the system is downgraded to enter the S3 suspended state to memory state, and the read and write load injection strategy is adjusted accordingly.

[0061] The monitoring of sub-state changes in the S0 low-power state includes: acquiring power state change events by monitoring the DBus signal of the system power management service.

[0062] Specifically, before triggering the host system to enter a low-power state, the test program performs the following operations: (1) Attempt to trigger the system to enter the S0ix state by writing the freeze command to / sys / power / state; (2) After the system enters a low-power state and stays for a preset time (e.g., 10 seconds), the system wake-up is triggered by the system timed wake-up mechanism or power management tool; (3) After the system wakes up, verify whether the system has actually entered the S0ix state by reading the system's low-power state dwell time. The specific reading method is determined according to the platform type: On the Intel x86 platform, the S0ix residency time can be read via / sys / kernel / debug / pmc_core / slp_s0_residency_usec; On platforms that support the ACPI LPIT (Low Power Idle Table), the system-level low power dwell time can be read via / sys / devices / system / cpu / cpuidle / low_power_idle_system_residency_us; On the ARM architecture platform, power consumption status can be queried through the SCPI (System Control and Power Interface) protocol, or dwell time information can be obtained through the PMU (Performance Monitoring Unit) counter.

[0063] If the dwell time increases before and after suspension, it indicates that the system has actually entered the S0ix state; if the value does not increase, it indicates that the system has not entered the S0ix state.

[0064] Adaptive degradation mechanism: If it is determined that the system has failed to actually enter the S0ix state, it will automatically degrade and trigger the system to enter the S3 (suspended to memory) state, executing the following instructions: echo mem> / sys / power / state; The S3 state is a traditional sleep state defined in the ACPI specification, supported by almost all x86 and ARM platforms. In the S3 state, the system saves the context to memory and powers off most peripherals.

[0065] Adjustments to the load injection strategy: When using the S3 state in a downgraded manner, since the wake-up latency of the S3 state is usually higher than that of S0ix, the test program should adjust the load injection strategy accordingly. Change "Inject high queue depth read / write load immediately after wake-up" to "Inject the first time the system resumes user mode execution after wake-up"; Adjust the timing of load injection related to the "lowest power state" appropriately to match the behavioral characteristics of the S3 state.

[0066] The S0 / S3 sub-state change monitoring method: Regardless of the system's low-power state, power state change events are acquired by listening to the DBus signal of systemd-logind. The test program subscribes to the PrepareForSleep signal of the org.freedesktop.login1.Manager interface.

[0067] This embodiment replaces the inaccurate static detection method with a dynamic verification mechanism of "attempt entry + dwell time verification," ensuring that the test program can reliably determine whether the system has actually entered the S0ix state. Through an adaptive degradation mechanism, the testing method of this invention can be adapted to different hardware platforms, exhibiting good platform compatibility and industrial application value.

[0068] Furthermore, in the S0 low-power state, different sub-states correspond to completely different user scenarios and I / O characteristics. In order to design differentiated load injection strategies to accurately simulate various real-world operating conditions and expose potential firmware defects in different scenarios, based on the above embodiments, in other embodiments, the step of dynamically adjusting the read / write load intensity of the tested solid-state drive according to the sub-state changes specifically includes: 2.1 When the screen is off and the network is active, inject random read / write load.

[0069] Specifically, when the test program detects that the system is in the "screen off but network active" sub-state via the DBus signal and system power status, it injects a moderate-intensity random read / write load. A typical simulated scenario is: after the user closes the laptop lid, the system continues to perform background operations such as automatic application updates, email synchronization, and cloud storage file synchronization. These operations are characterized by moderate I / O scale and are primarily random small-block read / write operations. Example of load parameters (using a general-purpose I / O load generation tool): fio --iodepth=1 --rw=randread --bs=4k --filename= / mnt / test / testfile--runtime=300; The queue depth (iodepth) is set to 1 to simulate the low concurrency of background applications, the block size (bs) is set to 4K to simulate random access to small files, and the runtime is set to 300 seconds to simulate the continuity of background tasks.

[0070] 2.2 When it is detected that the system is about to enter the lowest power consumption sub-state, inject sequential write load before the system enters the lowest power consumption state.

[0071] Specifically, when the test program captures the PrepareForSleep(true) event via the DBus signal (i.e., the system is about to enter a low-power state), a sequential write load is injected before the system actually enters the lowest power state. Typical simulation scenarios include: the system performing a hibernation dump (writing memory contents to a hibernation file on the hard drive) or memory swapping (swapping inactive memory pages to a swap partition on the hard drive). These operations are characterized by large data volumes, primarily sequential writes, and occur before the system actually enters a low-power state. Example load parameters (using the fio tool): fio --iodepth=8 --rw=write --bs=128k --filename= / mnt / test / testfile --runtime=300; The queue depth (iodepth) is set to 8 to simulate high concurrency during system dumping, and the block size (bs) is set to 128K to simulate large block sequential writing.

[0072] 2.3 When waking up from the S0 low-power state, inject a high queue depth read / write load after the wake-up signal is issued.

[0073] Specifically, when the test program captures the PrepareForSleep(false) event via the DBus signal (i.e., the system is waking up from a low-power state), a high queue depth random read / write load is injected immediately after the wake-up signal is issued. A typical simulation scenario: After a user opens the laptop lid or presses the power button to wake the computer, they immediately begin operations—opening multiple applications, loading large files, browsing web pages, etc. These operations are characterized by high concurrency, primarily random read / write operations, and a rapid surge in IO pressure. Example load parameters (using the fio tool): fio --iodepth=32 --rw=randrw --bs=4k --filename= / mnt / test / testfile --runtime=60; The queue depth (iodepth) is set to 32 to simulate high-concurrency I / O after the user wakes up, and read / write mixing (randrw) is used to simulate real user operations.

[0074] It should be noted that before executing the above fio command, testers must ensure that the / mnt / test directory has the corresponding file system mounted and that the test files have been created beforehand to avoid the test command failing due to non-existent paths. The above fio parameters are exemplary values ​​and can be adjusted according to the specifications of the SSD under test and the test objectives in actual applications.

[0075] This embodiment achieves accurate simulation of real-world user scenarios by designing differentiated load injection strategies for the three different sub-states of S0. The combination of the three scenarios covers the main I / O conditions of modern computing devices in the low-power state of S0, effectively exposing timing vulnerabilities and concurrency processing defects in SSD firmware under different power state switching scenarios.

[0076] Furthermore, in order to capture the abnormal precursors of the SSD's internal state before system anomalies occur through multi-dimensional and multi-layered real-time monitoring, thus expanding from "post-event retrospective" to "pre-event early warning," in addition to the above embodiments, other embodiments further include the following step before step S1: 1. Capture abnormal events in real time through system logs and record the millisecond-level timestamps of the abnormal events.

[0077] Specifically, NVMe timeout events and device reset events are captured in real time through the kernel log reading mechanism provided by the operating system. Whenever such an abnormal event is captured, the system automatically records the millisecond-level timestamp of the event.

[0078] 2. Periodically collect SMART data from the solid-state drive under test.

[0079] Specifically, SMART / Health information of the tested SSD is collected at fixed time intervals (every 5 minutes in this embodiment) using NVMe standard management commands. Key fields collected include temperature, percentage of rated lifetime consumed, amount of data written to the host, percentage of available reserved blocks, and media integrity error count.

[0080] 3. Read the fragmentation rate and garbage collection frequency of the FTL mapping table inside the tested solid-state drive.

[0081] Specifically, the fragmentation rate and GC activity frequency of the SSD's internal FTL mapping table are read through the NVMe vendor's custom log page.

[0082] For SSDs, the firmware pre-defined a dedicated vendor log page for reporting internal status. The test program reads this log page using the NVMe Get Log Page command. The returned data frame reveals: (1) FTL mapping table fragmentation rate: reflects the degree of fragmentation of the FTL mapping table; (2) GC activity frequency: reflects the activity level of firmware GC.

[0083] 4. When the garbage collection frequency exceeds the GC frequency alarm threshold or the FTL mapping table fragmentation rate exceeds the FTL fragmentation rate alarm threshold, an anomaly warning is triggered and an internal state snapshot at the current moment is recorded. The internal state snapshot is then persistently stored in the non-volatile storage area.

[0084] Specifically, an anomaly warning is triggered when the garbage collection frequency exceeds the GC frequency alarm threshold or the FTL mapping table fragmentation rate exceeds the FTL fragmentation rate alarm threshold. The thresholds are set as follows: based on statistical analysis of the GC frequency and FTL fragmentation rate distributions of samples in the same batch under normal operating conditions, the critical values ​​that cause a statistically significant increase in the corresponding indicators (e.g., exceeding three times the standard deviation of the normal distribution mean) are taken. It should be noted that the absolute values ​​of the above thresholds may differ under different firmware GC strategies and FTL mapping management algorithms, but the setting method remains consistent.

[0085] When an anomaly warning is triggered, the system will automatically perform the following operations: (1) Record the millisecond-level timestamp of the warning time T1; (2) Pack the state parameters such as GC frequency, FTL fragmentation rate, temperature, WAF, and LDPC error correction iteration count at time T1; (3) Detect the current status of the SSD: If the device can still respond to the command normally, write the data packet to the reserved non-volatile storage area of ​​the SSD firmware; if the device is in an unrecoverable state, abandon persistent storage and record the failure status.

[0086] This embodiment constructs a complete observation system from "system appearance" to "standard health information" and then to "deep firmware state" through three-dimensional monitoring of system logs, SMART data, and FTL / GC internal states. Automatic early warning of SSD internal anomalies is achieved through preset GC frequency thresholds and FTL fragmentation rate thresholds. The persistent storage mechanism of early warning snapshots ensures that key state data at the time of the early warning can be fully retrieved during subsequent anomaly backtracking.

[0087] Furthermore, in order to capture the abnormal precursors of the SSD's internal state before system anomalies occur through multi-dimensional and multi-layered real-time monitoring, thus expanding from "post-event retrospective" to "pre-event early warning," in addition to the above embodiments, other embodiments further include the following step before step S1: 1. Periodically collect SMART timing data of the solid-state drive under test.

[0088] Specifically, the test program continuously collects SMART data from the solid-state drive under test at fixed time intervals to form a time-series dataset.

[0089] 2. Compare the SMART time series data with the database of failed samples in the same batch, and calculate the similarity between the current sample and the failed sample.

[0090] Specifically, a "failure sample database for the same batch" is established. This database contains historical SMART timing data and corresponding failure tags recorded during accelerated aging tests for samples of the same model, firmware version, and NAND flash memory as the SSDs in this batch. The test program compares the SMART timing data of the current sample with the data in the failure sample database. Specifically, the KNN algorithm is used to calculate the similarity between the current sample and each failure sample in the database.

[0091] 3. Calculate the growth slope of the key SMART attribute over time. When the growth slope exceeds the dynamic threshold, determine that the tested solid-state drive has a hidden defect and output a warning message.

[0092] Specifically, for the key SMART attribute, its growth slope over time is calculated. The growth slope is calculated by performing linear regression on the data of the most recent N sampling points, and the slope of the fitted line is the growth rate of the attribute. When the growth slope exceeds a preset dynamic threshold, the tested solid-state drive is determined to have a hidden defect, and a warning message is output.

[0093] The dynamic threshold in this embodiment is not a fixed value, but is dynamically calculated based on the statistical distribution of historical failure samples in the same batch. The specific method is as follows: (1) Collect data on the growth slope of SMART attribute of expired samples in the same batch during the period before their failure; (2) When the sample size is not less than 30, calculate the mean μ and standard deviation σ of these slope data, and set the dynamic threshold to μ+3σ; (3) When the sample size is less than 30, the upper limit of the 95% confidence interval is determined by the t-distribution as the dynamic threshold.

[0094] Furthermore, when a new SSD model is tested for the first time, the "failure sample database for the same batch" may be empty or have insufficient sample size. To address this, the following tiered strategy is adopted: (1) When the failure sample database is empty (first test), the judgment is based on general industry experience thresholds. For example, the warning conditions corresponding to the Critical Warning status bits (such as temperature exceeding limits, reliability degradation, media error, etc.) defined in the NVMe specification can be referred to, or the SMART attribute recommended thresholds published by mainstream SSD manufacturers in their datasheets can be referenced. It should be noted that the above experience thresholds are only used for preliminary judgment when the model lacks training data, and their accuracy is lower than that of dynamic thresholds based on historical data of the same batch; (2) When the sample size of the failed sample database is less than 30, the dynamic threshold is determined by the confidence interval based on the t-distribution to avoid the problem that the normal distribution assumption does not hold under small sample size; (3) When the sample size reaches more than 30, a dynamic threshold based on the 3σ principle (mean + 3 times the standard deviation) is adopted, and the machine learning model on the server side is enabled for auxiliary analysis. (4) As test data continues to accumulate, failure data of new samples are gradually added to the database, the accuracy of dynamic threshold is improved accordingly, and the prediction accuracy of machine learning model is also improved in sync.

[0095] This embodiment utilizes machine learning methods to continuously monitor and analyze SMART time-series data, enabling early identification of latent defects in SSDs. Compared to traditional warning methods based on fixed thresholds, the dynamic threshold method in this embodiment can detect performance degradation trends earlier. A layered strategy and progressive connection mechanism addressing the "cold start" problem of new SSD models ensure a smooth transition from zero data to the intelligent model.

[0096] Furthermore, based on the above embodiments, other embodiments also include an automated closed-loop step, specifically including: 1. Upload the multi-dimensional test results generated during the testing process to the server. The multi-dimensional test results include system logs, SMART comparison table, internal status report and root cause analysis results.

[0097] Specifically, after the test is completed, the system automatically summarizes all multi-dimensional data generated during the test, including: System logs: contain timestamps of abnormal events, event types, and kernel log details; SMART Comparison Table: Includes a comparison of SMART data at the start and end of the test, as well as the changing trends of each attribute during the test; Internal status report: Includes time-series data on FTL fragmentation rate and GC frequency; Root cause analysis results: include snapshots of the root cause types and key state parameters generated in claim 1.

[0098] The data was packaged into a structured format (such as JSON) using a Python script and uploaded to the central server via HTTPS.

[0099] 2. If the upload fails, the multi-dimensional test results will be encrypted and cached locally, and the upload will be resumed after the network is restored.

[0100] Specifically, if a network interruption or server unavailability occurs during the upload process, the system will automatically encrypt and cache the multi-dimensional test results locally, and resume the upload once the network is restored.

[0101] 3. Based on machine learning models, intelligent analysis of multi-dimensional test results is performed to generate test reports and fault warning information.

[0102] Specifically, a machine learning model is deployed on the server side, which takes normalized SMART time series data as input and outputs the failure probability.

[0103] The training data for this model comes from the following sources: (1) Historical data of this model: SMART timing data and corresponding failure tags accumulated in the early testing of the same batch of SSDs (i.e., the expansion of the "same batch failure sample database" described in Example 7). (2) Cross-model transfer learning: When there is insufficient data accumulation for new model SSDs, historical data of in-production models from the same manufacturer and with the same particle type (such as TLC or QLC) can be used as the initial training set for the prediction model. The model can then be fine-tuned based on the actual test results. (3) Public datasets: Refer to publicly available SSD aging test datasets as supplementary training sources, or use data augmentation techniques to expand the training samples.

[0104] When there are fewer than 30 training samples, the machine learning model will not be enabled on the server. Once the accumulated number of labeled samples reaches the switching threshold, the system will automatically train and switch models.

[0105] In one exemplary implementation, a fully connected neural network (DNN) model built using TensorFlow can be employed, comprising an input layer, at least one hidden layer, and an output layer. The specific structure of the aforementioned DNN model (such as the number of hidden layers, the number of neurons per layer, the selection of activation functions, etc.) and training hyperparameters (such as optimizer type, learning rate, regularization coefficient, etc.) can be routinely optimized and adjusted according to the specific dataset size and characteristics. Changes in specific values ​​do not affect the implementation of this technical solution.

[0106] Once the server receives the uploaded test results, it automatically calls the model to analyze them and generate a test report and fault warning information containing information such as failure probability and risk level.

[0107] 4. Automatically generate maintenance suggestions based on test reports and fault warning information.

[0108] Specifically, based on test reports and fault warning information, the system automatically generates targeted maintenance recommendations. Recommendation types include, but are not limited to: If the problem is determined to be NAND physical layer signal distortion, the following recommendations are made: check the heat dissipation solution and optimize the NAND read voltage strategy. If the problem is determined to be a firmware layer anomaly, the following recommendations are made: optimize the firmware GC strategy and adjust the GC waterline parameters. If the NAND is determined to be excessively worn, it is recommended to replace the SSD or upgrade to a higher-endurance enterprise-grade SSD.

[0109] This embodiment ensures the integrity and reliability of test data through automated aggregation and uploading of multi-dimensional data and a mechanism for resuming interrupted uploads. Intelligent analysis of test results based on machine learning models upgrades the process from "manual report review" to "AI-powered automated diagnosis." Automatically generated maintenance suggestions directly transform test conclusions into actionable operational guidelines, significantly enhancing the practical value of the test results.

[0110] Furthermore, the server-side machine learning model in this embodiment and the dynamic threshold strategy in the above embodiment have a progressive relationship, and together they constitute a complete intelligent analysis system: (1) Cold start phase (e.g., sample size = 0): Use general industry experience thresholds for judgment; (2) Small sample stage (e.g., 0 < sample size < 30): Use confidence intervals based on t-distribution to determine dynamic thresholds; (3) Large-scale stage (e.g., sample size ≥ 30): When the number of samples in the failed sample database reaches the statistical requirements, the machine learning model on the server side is activated for intelligent analysis. (4) Switching conditions: When the number of samples accumulated in the database of failed samples in the same batch reaches the preset switching threshold (e.g., 30 valid samples, which include at least two types of labels: normal samples and failed samples), the system automatically switches from the rule judgment mode based on dynamic thresholds to the prediction mode based on machine learning models, and incorporates historical data into the model training set for retraining.

[0111] The aforementioned progressive strategy ensures that the system can function normally based on experience thresholds during the cold start phase when historical data is lacking. At the same time, as test data is gradually accumulated, it automatically transitions to a more accurate machine learning prediction mode, forming a closed loop of continuous iterative optimization.

[0112] Figure 2 A schematic diagram of the functional modules of the solid-state drive compatibility and reliability testing device according to an embodiment of the present invention is shown. Figure 2 As shown, the solid-state drive compatibility and reliability testing device 20 includes: an acquisition module 21, an extraction module 22, a matching module 23, and an output module 24.

[0113] The acquisition module 21 is used to acquire abnormal events generated by the host system during access to the solid-state drive under test, and record the time of occurrence of the abnormal events; Extraction module 22 is used to extract the set of operating status parameters inside the solid-state drive under test within a specified time period corresponding to the time anchor point, with the time of occurrence as the time anchor point; The matching module 23 is used to match the set of operating status parameters with a set of preset fault feature models to determine the fault root cause type corresponding to the abnormal event; wherein, the set of multiple fault feature models includes at least a first type of fault model for characterizing physical layer abnormalities and a second type of fault model for characterizing firmware layer abnormalities. Output module 24 is used to output root cause analysis results containing the root cause types of the faults.

[0114] Optionally, the set of operating status parameters includes the internal temperature of the solid-state drive under test, the write amplification factor, and the number of LDPC error correction iterations; The first type of fault model is configured as follows: when the number of LDPC error correction iterations exceeds the LDPC iteration number threshold and the internal temperature exceeds the temperature threshold, the fault root cause type is determined to be NAND physical layer signal distortion. The second type of fault model is configured as follows: when the write amplification factor exceeds the write amplification factor threshold, the fault root cause type is determined to be firmware layer abnormality. Specifically, when the number of LDPC error correction iterations exceeds the LDPC iteration number threshold and the internal temperature exceeds the temperature threshold, the root cause of the fault is locked as NAND physical layer signal distortion. Whether the write amplification factor exceeds the write amplification factor threshold does not affect the determination result.

[0115] Optionally, the specified time period includes N seconds before the occurrence of the abnormal event and M seconds after it; Extraction module 22 performs the operation of extracting the set of operating status parameters inside the tested solid-state drive within a specified time period corresponding to the time anchor point, specifically including: Using the occurrence time of the abnormal event as an index, time series data within a specified time period is read from the internal circular cache of the firmware of the solid-state drive under test. The circular cache samples each parameter in the running status parameter set with millisecond precision and records the summary value of each sampling point with a storage granularity of seconds. When an anomaly warning is triggered before an anomaly occurs, a snapshot of the internal state at the moment the anomaly warning is triggered is persistently stored in the non-volatile storage area. The runtime state parameter set also includes the persistently stored snapshot data.

[0116] Optionally, before performing the operation of acquiring abnormal events generated by the host system during access to the tested solid-state drive, the acquisition module 21 is further configured to: Triggers the host system to enter the S0 low-power state; Monitor the sub-state changes of the S0 low-power state and dynamically adjust the read / write load intensity on the tested solid-state drive based on the sub-state changes.

[0117] Optionally, the acquisition module 21 performs the operation of dynamically adjusting the read / write load intensity of the tested solid-state drive based on the sub-state changes, specifically including: Inject random read / write load when the screen is off and the network is active. When it is detected that the system is about to enter the lowest power sub-state, inject sequential write load before the system enters the lowest power sub-state; When waking up from the S0 low-power state, a high queue depth read / write load is injected after the wake-up signal is issued.

[0118] Optionally, before performing the operation of acquiring abnormal events generated by the host system during access to the tested solid-state drive, the acquisition module 21 is further configured to: Abnormal events are captured in real time through system logs, and the millisecond-level timestamps of the abnormal events are recorded. Periodically collect SMART data from the solid-state drive under test; Read the fragmentation rate and garbage collection frequency of the FTL mapping table inside the tested solid-state drive; When the garbage collection frequency exceeds the GC frequency alarm threshold or the FTL mapping table fragmentation rate exceeds the FTL fragmentation rate alarm threshold, an anomaly warning is triggered and an internal state snapshot at the current moment is recorded. The internal state snapshot is then persistently stored in the non-volatile storage area.

[0119] Optionally, before performing the operation of acquiring abnormal events generated by the host system during access to the tested solid-state drive, the acquisition module 21 is further configured to: Periodically collect SMART timing data of the solid-state drive under test; The SMART time-series data is compared with the database of failed samples in the same batch to calculate the similarity between the current sample and the failed samples. Calculate the growth slope of the key SMART attribute over time. When the growth slope exceeds the dynamic threshold, determine that the tested solid-state drive has a hidden defect and output a warning message.

[0120] Optionally, the solid-state drive compatibility and reliability testing apparatus 20 also includes a prediction module for: The multi-dimensional test results generated during the testing process are uploaded to the server. The multi-dimensional test results include system logs, SMART comparison table, internal status report and root cause analysis results. If the upload fails, the multi-dimensional test results will be encrypted and cached locally, and the upload will be resumed after the network is restored. Intelligent analysis of multi-dimensional test results is performed based on machine learning models to generate test reports and fault warning information; Maintenance recommendations are automatically generated based on test reports and fault warning information.

[0121] For other details regarding the implementation techniques of each module in the solid-state drive compatibility and reliability testing device of the above embodiments, please refer to the description in the solid-state drive compatibility and reliability testing method of the above embodiments, which will not be repeated here.

[0122] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0123] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention. Figure 3 As shown, the computer device 30 includes a processor 31 and a memory 32 coupled to the processor 31. The memory 32 stores program instructions. When the program instructions are executed by the processor 31, the processor 31 performs the steps of the solid-state drive compatibility and reliability testing method described in any of the above embodiments.

[0124] The processor 31 can also be referred to as a Central Processing Unit (CPU). The processor 31 may be an integrated circuit chip with signal processing capabilities. The processor 31 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor can be a microprocessor or any conventional processor.

[0125] See Figure 4 , Figure 4This is a schematic diagram of the structure of a computer-readable storage medium according to an embodiment of the present invention. The computer-readable storage medium of this embodiment stores program instructions 41 capable of implementing the above-described solid-state drive compatibility and reliability testing method. These program instructions 41 can be stored in the computer-readable storage medium in the form of a software product, including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned computer-readable 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, or computer devices such as computers, servers, mobile phones, and tablets.

[0126] In the several embodiments provided by this invention, it should be understood that the disclosed computer devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0127] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units. The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for testing the compatibility and reliability of solid-state drives, characterized in that, include: Acquire abnormal events generated by the host system during access to the tested solid-state drive, and record the time of occurrence of the abnormal events; Using the time of occurrence as the time anchor, extract the set of operating status parameters inside the solid-state drive under test within the specified time period corresponding to the time anchor; Based on the set of operating status parameters, the system matches them with a variety of preset fault feature models to determine the fault root cause type corresponding to the abnormal event; wherein, the variety of fault feature models include at least a first type of fault model for characterizing physical layer abnormalities and a second type of fault model for characterizing firmware layer abnormalities. The output includes root cause analysis results for the type of fault.

2. The solid-state drive compatibility and reliability testing method according to claim 1, characterized in that, The set of operating status parameters includes the internal temperature of the solid-state drive under test, the write amplification factor, and the number of LDPC error correction iterations. The first type of fault model is configured as follows: when the number of LDPC error correction iterations exceeds the LDPC iteration number threshold and the internal temperature exceeds the temperature threshold, the fault root cause type is determined to be NAND physical layer signal distortion. The second type of fault model is configured as follows: when the write amplification factor exceeds the write amplification factor threshold, the fault root cause type is determined to be firmware layer anomaly; Specifically, when the number of LDPC error correction iterations exceeds the LDPC iteration number threshold and the internal temperature exceeds the temperature threshold, the root cause of the fault is locked as the NAND physical layer signal distortion. Whether the write amplification factor exceeds the write amplification factor threshold does not affect the determination result.

3. The solid-state drive compatibility and reliability testing method according to claim 1, characterized in that, The specified time period includes N seconds before the occurrence of the abnormal event and M seconds after it. The extraction of the set of operating status parameters of the solid-state drive under test within the specified time period corresponding to the time anchor point includes: Using the occurrence time of the abnormal event as an index, time series data within the specified time period is read from the internal circular cache of the firmware of the solid-state drive under test. The circular cache samples each parameter in the set of running status parameters with millisecond precision and records the sum of values ​​of each sampling point with seconds as the storage granularity. When an anomaly warning is triggered before the occurrence of the anomaly event, a snapshot of the internal state at the moment the anomaly warning is triggered is persistently stored in a non-volatile storage area. The set of running state parameters also includes the persistently stored snapshot data.

4. The solid-state drive compatibility and reliability testing method according to claim 1, characterized in that, Before acquiring abnormal events generated by the host system during access to the tested SSD, the process also includes: Triggers the host system to enter the S0 low-power state; Monitor the sub-state changes of the S0 low-power state, and dynamically adjust the read / write load intensity of the tested solid-state drive based on the sub-state changes.

5. The solid-state drive compatibility and reliability testing method according to claim 4, characterized in that, The step of dynamically adjusting the read / write load intensity of the tested solid-state drive based on the sub-state changes includes: Inject random read / write load when the screen is off and the network is active. When it is detected that the system is about to enter the lowest power sub-state, inject sequential write load before the system enters the lowest power sub-state; When waking up from the S0 low-power state, a high queue depth read / write load is injected after the wake-up signal is issued.

6. The solid-state drive compatibility and reliability testing method according to claim 1, characterized in that, Before acquiring abnormal events generated by the host system during access to the tested SSD, the process also includes: The abnormal events are captured in real time by the system logs, and the millisecond-level timestamps of the abnormal events are recorded. Periodically collect SMART data from the solid-state drive under test; Read the fragmentation rate and garbage collection frequency of the FTL mapping table inside the tested solid-state drive; When the garbage collection frequency exceeds the GC frequency alarm threshold or the FTL mapping table fragmentation rate exceeds the FTL fragmentation rate alarm threshold, an anomaly warning is triggered and an internal state snapshot at the current moment is recorded. The internal state snapshot is then persistently stored in the non-volatile storage area.

7. The solid-state drive compatibility and reliability testing method according to claim 1, characterized in that, Before acquiring abnormal events generated by the host system during access to the tested SSD, the process also includes: Periodically collect SMART timing data of the solid-state drive under test; The SMART time-series data is compared with the database of failed samples in the same batch to calculate the similarity between the current sample and the failed samples. Calculate the growth slope of the key SMART attribute over time. When the growth slope exceeds a dynamic threshold, determine that the tested solid-state drive has a hidden defect and output a warning message.

8. The method according to any one of claims 1 to 7, characterized in that, Also includes: The multi-dimensional test results generated during the testing process are uploaded to the server. The multi-dimensional test results include system logs, SMART comparison table, internal status report and root cause analysis results. If the upload fails, the multi-dimensional test results will be encrypted and cached locally, and the upload will resume once the network is restored. The multi-dimensional test results are intelligently analyzed based on machine learning models to generate test reports and fault warning information. Maintenance recommendations are automatically generated based on the test report and fault warning information.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the solid-state drive compatibility and reliability testing method according to any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the solid-state drive compatibility and reliability testing method according to any one of claims 1 to 8.

Images