SSD test method and system, electronic equipment and medium

Abstract

The invention discloses an SSD test method and system, electronic equipment and a medium, and the method comprises the steps: determining an operation mode when a test is started, and if the operation is continuous test operation, obtaining a recorded final failure command index as a breakpoint continuous test index; loading the command list according to the breakpoint continuous test index and starting to execute from a corresponding position; recording successfully completed command information to a recently completed command historical queue in a command execution process; when a command failure is detected, recording a failure command index, performing joint backtracking marking according to an address interval of a failure command, a command list historical interval and a recently completed command historical interval, and writing the marked interval into an uncompleted LBA set; judging whether verification is skipped or not according to a preset condition in a read command verification stage; and in a playback mode based on time, when the command list is executed completely and the running duration does not reach a target, automatically resetting and continuing playback. The SSD test continuity, the fault positioning precision and the test result reliability are improved.

Description

Technical Field

[0001] This invention belongs to the field of data storage testing technology, specifically relating to SSD testing methods, systems, electronic devices, and media. Background Technology

[0002] With the rapid development of information technology, solid-state drives (SSDs) have been widely used in personal computers, data centers, and other fields due to their advantages such as high speed, low power consumption, and high reliability. The stability and data consistency of SSDs are directly related to the reliability of the entire system, therefore, it is crucial to conduct thorough testing and verification of SSDs.

[0003] Currently, for SSD stability and consistency verification, existing technologies typically employ a testing method combining random / sequential I / O with data verification and failure-based stop. The basic principle is to continuously submit I / O commands, compare the data after each command, and stop or restart the test if an error occurs. While this method can perform basic replay testing, it still has the following technical problems:

[0004] During test script execution, if an SSD loses power, I / O is manually stopped, or command execution fails, existing solutions typically cannot resume execution from the point of interruption and must start over, resulting in high costs and long testing times for repeated tests. After a command fails, existing solutions can usually only identify that a specific command has failed, but cannot accurately mark the affected LBA range or further trace back to potentially related historical ranges before the failure. In mandatory verification scenarios, existing solutions often still perform uniform comparisons for certain specific data patterns, which can easily generate false positives and affect the validity and analyzability of test results. In asynchronous or high-concurrency command scenarios, existing solutions lack historical tracking of the most recently completed commands, which is not conducive to failure reproduction, fault location, and recovery control. Summary of the Invention

[0005] The purpose of this invention is to provide an SSD testing method, system, electronic device, and medium, which aims to solve the problems of "inability to resume testing from breakpoints, difficulty in locating failure intervals, inability to trace back the historical impact, and false alarms in verification under specific modes" during SSD command list playback and consistency testing.

[0006] To achieve the above objectives, a specific embodiment of the present invention provides an SSD testing method, the method comprising: determining the running mode when the test starts; if it is a continuous test, obtaining the index of the last failed command recorded as the breakpoint continuation test index. Load the command list according to the breakpoint continuation index, and start executing the commands in the command list from the corresponding position; During command execution, successfully completed command information is recorded in the recently completed command history queue; When a command failure is detected, the index of the failed command is recorded, and a joint backtracking mark is made based on the address range of the failed command, the historical range of the command list, and the historical range of the most recently completed command. The marked range is then written into the incomplete LBA set. During the read command verification phase, determine whether to skip the verification based on preset conditions; In time-based playback mode, when the command list has been executed and the runtime has not reached the target, the command list is automatically reset and playback continues.

[0007] This embodiment achieves accurate recovery after test interruption by determining the running mode and obtaining the breakpoint continuation index, avoiding the time waste and resource consumption caused by rerunning the command list from the beginning. By recording the information of successfully completed commands to the recently completed command history queue, it provides a real execution trajectory for subsequent backtracking. When a command fails, it combines the address range of the failed command, the command list history range, and the recently completed command history range to perform backtracking marking, and writes the risk range into the incomplete LBA set, thereby expanding the impact of the fault from a single command to range-level risk identification, significantly improving the fault location accuracy. During the command verification stage, it skips verification according to preset conditions, reducing false alarms caused by special mode data and improving the reliability of verification results. In the time-based replay mode, if the runtime has not been reached after the command list is executed, it is automatically reset and replay continues, ensuring the continuity of long-term testing.

[0008] In one or more embodiments of the present invention, the joint backtracking marker includes command list history backtracking and recently completed history backtracking, wherein the command list history backtracking includes backtracking historical commands within a preset depth along the command list order based on the position of the failed command in the command list, and extracting the LBA interval covered by these historical commands; The most recently completed history backtracking involves starting from the tail record in the most recently completed command history queue, tracing back completed commands within a preset depth in reverse order of completion time, and extracting the LBA intervals actually covered by these commands.

[0009] This embodiment further defines the specific implementation method of joint backtracking markers. By backtracking the command list history, starting from the position of the failed command in the command list, historical commands within a preset depth are traced backward, enabling the capture of historical intervals where the test plan and failed commands have a contextual relationship. By backtracking the most recently completed history, starting from the tail record of the most recently completed command history queue, completed commands are traced in reverse order, enabling the capture of command intervals that have been completed at the actual execution level but whose order may deviate from the command list. These two backtracking methods jointly determine risk intervals from both the planning and actual completion perspectives, overcoming the shortcomings of missing intervals under a single perspective, making the coverage of the incomplete LBA set more comprehensive, and further improving the accuracy and completeness of failure impact surface analysis.

[0010] In one or more embodiments of the present invention, the preset conditions include one or more of the following: Pattern index condition: If the actual pattern index read meets the preset value, the verification is skipped; LBA range attribution condition: When the LBA involved in the current read command belongs to the incomplete LBA set, the corresponding range check is skipped; Command type condition: If the preceding command type corresponding to the current data source is a command type that does not require regular data comparison, skip the validation. Test phase conditions: When the test is in a preset phase, the verification is skipped.

[0011] This embodiment defines the preset conditions for skipping verification as including one or more of the following: pattern index conditions, LBA interval assignment conditions, command type conditions, and test phase conditions. The pattern index condition allows for skipping verification of empty data or special placeholder patterns, avoiding meaningless comparisons; the LBA interval assignment condition allows for skipping verification of data already marked as risky intervals, reducing redundant verification overhead; the command type condition allows for eliminating false alarms for command types such as Trim that do not require regular comparisons; and the test phase condition allows for temporary suspension of verification during the transition phase or initialization phase after a breakpoint resume test. The flexible combination of these multi-dimensional conditions allows for more refined verification control, minimizing the false alarm rate while ensuring necessary verification, and improving the engineering applicability of the test results.

[0012] In one or more embodiments of the present invention, the recently completed command history queue is maintained using a bounded queue structure with a maximum depth. When a new completed command is written, if the queue capacity has reached the upper limit, the earliest record is removed according to the first-in-first-out update strategy, and only the recently completed command history is retained. The recently completed command history queue is specifically used for historical backtracking after failure, risk range determination, debugging output, and fault reproduction analysis.

[0013] This embodiment specifies that the recently completed command history queue adopts a bounded queue structure with a maximum depth. When the queue is full, the oldest record is removed according to a first-in, first-out (FIFO) strategy, thus preserving the trajectory of the most recently completed command with limited storage overhead. It also clarifies that this queue is specifically used for historical backtracking after failures, risk range determination, debugging output, and fault reproduction analysis, rather than for command issuance control or scheduling order determination. This limitation clearly distinguishes the history queue of this application from the command queues used for scheduling optimization in existing technologies, highlighting the technical purpose and application scenario of the queue in this application. This ensures that the true completion history required for failure analysis is fully preserved, providing reliable data support for fault location and reproduction.

[0014] In one or more embodiments of the present invention, the time-based playback mode includes: a test mode with a preset runtime as the test termination condition, in which if the cumulative runtime does not reach the preset runtime after the command list is executed, the system automatically resets the command list index and re-executes the command list from the beginning until the cumulative runtime reaches the preset runtime.

[0015] This embodiment explicitly defines a time-based replay mode, where a preset runtime is used as the test termination condition. In this mode, if the cumulative runtime has not reached the preset runtime after the command list has been executed, the system automatically resets the command list index and re-executes the command list from the beginning until the cumulative runtime reaches the preset runtime. This definition clarifies the mode's operating mechanism, enabling the test to continuously apply load within a predetermined duration. It is suitable for long-term stability testing and regression testing scenarios, ensuring the continuity and sufficiency of the test load.

[0016] In one or more embodiments of the present invention, in the time-based playback mode, breakpoint continuation and automatic replay work in conjunction: When a test is interrupted due to an exception, the test will resume from the last failed command index and continue executing the command list from the vicinity of the failure point on the next startup. If the test is not interrupted and the command list is executed normally to the end but the running time has not reached the target running time, the automatic replay mechanism is triggered, the command index is reset to the beginning position and execution continues.

[0017] This embodiment defines the collaborative working relationship between breakpoint resumption testing and automatic replay in time-based playback mode. When a test is interrupted due to an anomaly, breakpoint resumption testing is prioritized based on the index of the last failed command, resuming execution from near the point of failure to avoid starting from the beginning. When the test is not interrupted and the command list has been executed normally to the end but the runtime has not reached the target, automatic replay is triggered, resetting the command index and continuing execution. Through the collaborative mechanism of "resume first, then replay," both the continuity of testing after an anomaly and the continuous load application under normal scenarios are ensured. This allows the two mechanisms to complement each other in different scenarios, further improving the robustness and automation of the test.

[0018] In one or more embodiments of the present invention, the incomplete LBA set is used for one or more of the following: During the recovery execution phase, targeted verification or rewriting operations are performed on the LBA ranges within the incomplete LBA set first, based on the incomplete LBA set. During the test reporting phase, failure logs from the incomplete LBA set are exported at the interval granularity. In the check skip control, it serves as the basis for determining whether the current read command should skip the check; In fault analysis and reproduction, the interval-level on-site information at the time of the fault is constructed in conjunction with the history of recently completed commands and the index of failed commands. During subsequent I / O operations after recovery, if some LBAs have been overwritten or re-verified by new successful commands, these LBAs will be removed from the set of incomplete LBAs or their status will be updated.

[0019] This embodiment defines several subsequent applications of the incomplete LBA set. During the recovery execution phase, targeted verification or rewriting is prioritized for the marked intervals based on this set, improving recovery efficiency. In the test reporting phase, failure logs are exported at the interval granularity, facilitating fault tracing. In verification skip control, it serves as a basis for flexibly controlling verification strategies. In fault analysis and reproduction, it is combined with the history of recently completed commands and the index of failed commands to construct interval-level on-site information, aiding in problem localization. During I / O execution after recovery, the set state is dynamically updated, ensuring the set always maintains the latest risk interval information. These applications expand the incomplete LBA set from a simple marking result into a core data structure that runs through recovery, verification, reporting, and fault analysis, enhancing the engineering practicality and scalability of the testing framework.

[0020] In another aspect of the present invention, an SSD testing system is provided, the SSD testing system comprising: The breakpoint recovery module is used to determine the running mode when the test starts. If it is a continued test, the index of the last failed command recorded is used as the breakpoint continued test index. The command loading module is used to load a command list according to the breakpoint continuation index and start executing the commands in the command list from the corresponding position. The history module is used to record information about successfully completed commands to the most recently completed command history queue during command execution. The failure handling module is used to record the index of the failed command when a command failure is detected, and to perform joint backtracking marking based on the address range of the failed command, the command list history range, and the recently completed command history range, and write the marked range into the incomplete LBA set. The verification control module is used to determine whether to skip the verification during the read command verification stage based on preset conditions. The replay control module is used to automatically reset and continue replaying the command list when the command list has been executed and the runtime has not reached the target in time-based replay mode.

[0021] In another aspect of the invention, an electronic device is provided, comprising: at least one processor; and a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform an SSD testing method.

[0022] In another aspect of the invention, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of an SSD testing method. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is an overall flowchart of an SSD testing method according to one embodiment of the present invention; Figure 2 This is a flowchart illustrating the collaborative operation of breakpoint continuation testing and automatic replay in one embodiment of the present invention. Figure 3 A flowchart of a testing method in the prior art; Figure 4 This is a schematic diagram of the process of joint backtracking markers in one embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the joint tagging of command list history backtracking and most recently completed history backtracking in one embodiment of the present invention; Figure 6 This is a schematic diagram of the process of automatically resetting and continuing playback in a time-based playback mode according to one embodiment of the present invention; Figure 7 This is a schematic diagram illustrating the process of unfinished unified maintenance and subsequent application of LBA sets in one embodiment of the present invention; Figure 8 This is a block diagram of an SSD testing system according to one embodiment of the present invention; Figure 9 This is a structural diagram of an electronic device used in an SSD testing method according to an embodiment of the present invention. Detailed Implementation

[0025] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0026] like Figure 3 As shown, the existing testing method includes the following steps: after the test begins, a test command is generated or loaded, an I / O command is submitted and the test is waited for completion. Then, data is read and a comparison verification is performed. If the verification fails, the test terminates; if the verification succeeds, the test continues with the next command until the command list is empty. This method has the following drawbacks: it cannot resume testing from breakpoints, it cannot accurately mark the affected LBA range after a failure, it lacks historical tracking of recently completed commands, and forced verification in specific modes is prone to false alarms.

[0027] In the background technology, such as Figure 3 The shortcomings of the existing technical methods shown are, for example Figure 1 As shown, this invention provides an overall flow of an SSD testing method. Figure 2 As shown, this method achieves coordinated operation of breakpoint continuation testing and automatic replay in time-based playback mode. Specifically, it includes the following steps: Step 1: Determine the running mode when the test starts. If it is a continuous test, obtain the index of the last failed command recorded as the breakpoint continuation test index.

[0028] Specifically, when the test script starts, the system first determines whether the current run is a continuation test scenario. If it is the first run, the breakpoint continuation test index is set to an initial value (e.g., 0). If it is a continuation test, the system calls the failure index retrieval interface to read the last_failed_cmd_index recorded during the most recent execution, and uses this index as the basis for the breakpoint continuation test index resume_index. Through this step, the system can identify the execution position before the test was interrupted, laying the foundation for subsequent breakpoint continuation tests.

[0029] Step 2: Load the command list according to the breakpoint continuation index, and start executing the commands in the command list from the corresponding position.

[0030] Specifically, based on the current test strategy, the system calls the recovery parameter setting interface to set the lookback (failure backtracking depth) and resume_index (breakpoint resumption index). Then, it loads the command list and sets the current command index and the number of remaining commands according to the resume_index, enabling the system to start executing the command list from a specified position, rather than starting from the beginning. When loading a new command list, the system clears the recently completed command history cache to avoid mutual interference between different test rounds. This step achieves precise recovery after test interruption, avoiding the time and resource waste of rerunning the entire command list from the beginning.

[0031] Step 3: During the execution of commands, record the information of successfully completed commands to the most recently completed command history queue.

[0032] Specifically, the system retrieves the current command one by one from the command list, submits the I / O command, and waits for the command to complete. For each valid command in the command list mode, the system maintains a corresponding command index. After a command is successfully completed, the system writes the command information to the recently completed command history queue. The recorded information includes the command index, command type, starting LBA, and LBA length. The LBA length is obtained by dividing the number of bytes transferred by the sector size, and the command type can be write, read, trim, or flush, etc. Through this history queue, the system can track the actual command trajectory within a recent period, providing a true execution history for subsequent failure backtracking.

[0033] Step 4: When a command failure is detected, record the index of the failed command, and perform a joint backtracking mark based on the address range of the failed command, the historical range of the command list, and the historical range of the most recently completed command. Write the marked range into the incomplete LBA set.

[0034] Specifically, if a command completes abnormally, the system immediately records the index of the failed command. Preferably, if multiple failures occur in the same round of execution, the smallest failed command index is saved as `last_failed_cmd_index` and simultaneously saved to both the task-level and global-level contexts, so that it can serve as the starting point for resuming testing after a breakpoint is reached. This index can be saved in both the task-level and global-level contexts for easy access by external control programs.

[0035] like Figure 4 As shown, the specific process of joint backtracking marking includes: the system first marks the LBA interval corresponding to the current failed command according to the starting LBA and transmission length of the failed command; then, it performs two types of historical backtracking based on lookback, and writes the backtracked intervals into the incomplete LBA set.

[0036] The first type is command list history backtracking: Based on the index of the current failed command in the command list, it looks back through historical commands within a preset depth range in the order of the command list and extracts the LBA intervals covered by these historical commands. This backtracking method reflects the command context at the test plan level and can identify "historical command intervals that should have been adjacent to or related to the failed command according to the command list design before the failed command". This method mainly solves the problem that "the relevant intervals of the plan before the failure cannot be covered by the current failed command alone".

[0037] The second type is recent completion history backtracking: starting from the tail record in the recent completion command history queue, it reviews completed commands within a preset depth range in reverse chronological order of completion time and extracts the LBA intervals actually covered by these commands. This backtracking method reflects the completion context at the actual execution level of the device and can identify "the command intervals that were actually completed before the failure occurred and may be related to the failure." This method mainly addresses the technical problem that relying solely on the command list history cannot accurately reflect the actual impact in scenarios such as asynchronous I / O, high concurrency, or inconsistencies between the completion order and the command list order.

[0038] When the two backtracking methods are used in combination, command list history backtracking provides the relevant intervals from the perspective of the plan, while most recently completed history backtracking provides the relevant intervals from the perspective of actual completion. The former ensures that no historical commands with contextual relationships in the test plan are missed near the failed command, while the latter ensures that no historical commands that have been completed in actual execution but whose order may deviate from the command list are missed. By combining the two, the impact of failure can be expanded from a single failed command to a more complete "set of risk intervals," improving the coverage and accuracy of failure interval marking and providing a more reliable basis for subsequent breakpoint continuation testing, verification skipping, and fault analysis.

[0039] like Figure 5As shown, command list history backtracking uses the position of the failed command in the command list as a reference, and backtracks the historical commands within the lookback depth in the order of the command list (as shown in entry[n-3] to entry[n] in the figure); recently completed history backtracking starts from the tail record of the recently completed command history queue, and backtracks the completed commands within the preset depth in reverse order of completion time. Through the joint labeling of the two types of backtracking, the risk interval is written into the incomplete LBA set.

[0040] Step 5: During the read command verification stage, determine whether to skip the verification based on preset conditions.

[0041] Specifically, when the current command is a read command and verification is required, the system further determines whether the verification skip condition is met. If the preset skip condition is met, the comparison of the current data unit is skipped; if the skip condition is not met, data verification is performed, and error information is recorded when verification fails.

[0042] The preset skip conditions may include, but are not limited to, the following categories: Pattern index condition: When the actual pattern index read meets a preset value, the verification is skipped. Preferably, when the actual pattern index is 0, the verification of the current data unit is skipped. This condition is mainly used to avoid false alarms caused by empty data, special placeholder pattern data, or other predefined non-comparison pattern data.

[0043] LBA range attribution condition: If the LBA involved in the current read command belongs to the incomplete LBA set, the failure risk range set, or other LBA ranges marked as uncertain, the corresponding range verification is skipped. This condition is mainly used to avoid performing invalid comparisons on data ranges whose states are uncertain before and after power failure, I / O stoppage, or failure recovery.

[0044] Command type condition: If the preceding command type corresponding to the current data source is a command type that does not require regular data comparison, the verification is skipped. For example, data ranges related to Trim, specific control commands, or commands used only for state synchronization can be excluded from the comparison process according to the policy.

[0045] Test phase conditions: When the test is in a preset phase, skip the verification. For example, in the transition phase after a breakpoint resume test, the re-coverage phase after a power outage recovery, the initialization phase, or the phase used only for playback recovery, the verification of some intervals can be postponed or skipped according to the strategy.

[0046] By expanding the preset skip conditions to a multi-dimensional set of conditions, this invention can flexibly control whether to perform verification based on different data patterns, different interval affiliations, different command attributes, and different test stages, thereby reducing the false alarm rate and improving the reliability and engineering applicability of test results.

[0047] In a further embodiment, it also includes determining whether the command list has been executed.

[0048] If the command list has not been completed, return to step 3 to get the next command and repeat the execution; if the command list has been completed, proceed to step 6.

[0049] Step 6: In time-based playback mode, when the command list has been executed and the runtime has not reached the target, the command list will be automatically reset and playback will continue.

[0050] Specifically, if the current task is in time-based replay mode (i.e., a test mode where the test ends with a preset runtime), and the command list has reached the end but the runtime has not yet ended, the system automatically resets the command list index to the beginning and continues submitting I / O. To avoid repeated output of replay prompts, the system maintains an automatic replay prompt control flag, outputting prompt information only upon first entering the automatic replay process. For example... Figure 6 As shown, this mechanism enables the test to continuously replay the command list within a set time period.

[0051] In time-based playback mode, the breakpoint resumption mechanism and the automatic replay mechanism work together, such as... Figure 2 As shown, when a test is interrupted due to an anomaly, the system prioritizes resuming the test based on the index of the last failed command. Upon the next startup, it continues executing the command list from near the point of failure. If the test is not interrupted and the command list executes normally to the end but the runtime has not reached the target runtime, an automatic replay mechanism is triggered, resetting the command index to the beginning and continuing execution. Therefore, in time-based replay mode, the breakpoint resumption mechanism prioritizes addressing the problem of "how to recover after an abnormal exit," while the automatic replay mechanism prioritizes addressing the problem of "how to continue after a normal run." The interaction between the two is as follows: when the test restarts, the system first determines whether to enter breakpoint resumption based on the existence of a valid failure index; during subsequent execution after recovery, if the command list is again normally exhausted and the runtime has not ended, automatic replay is then initiated. This collaborative relationship of recovery first, then replay ensures both test continuity after an abnormal interruption and load sustainability in long-running scenarios.

[0052] In a further embodiment, output statistics and debugging information is also included.

[0053] During testing, the system can output recently completed command information, failure index information, and incomplete LBA set information as needed for debugging, analysis, and fault reproduction. When debugging or analyzing the failure scenario is required, the system can call the recently completed command printing interface to output key information of the most recently completed commands in reverse order, within the limits of historical limits, current record count, and backtracking depth. This includes the command sequence number, index, type, and corresponding LBA start and end ranges. This helps testers quickly see the most recent batch of truly completed commands before the failure.

[0054] The technical solution of this application will be further explained below with reference to specific parameters and data structures.

[0055] Key parameters involved in this application include: lookback: failure backtracking depth, used to determine the historical range that needs to be looked back; resume_index: breakpoint continuation index, used to continue executing the command list from near the failure point; last_failed_cmd_index: index of the most recently failed command, read from the failure index retrieval interface as the starting point for continuation testing; setCmdListRecoveryParams: recovery parameter setting interface, used to set lookback and resume_index; RECENT_CMD_HISTORY_MAX: upper limit of the recently completed command history buffer; cmd_history_entry: recently completed command history entry, used to record the command index, command type, starting LBA, and LBA length.

[0056] The recently completed command history queue is maintained using a bounded queue structure with a maximum depth of RECENT_CMD_HISTORY_MAX. When a new completed command is written, if the queue capacity has reached the limit, the oldest record is removed according to a "first-in, first-out" update strategy, retaining only the history of commands completed within the most recent period. Each historical record preferably includes a command index, command type, starting LBA, and LBA length to reflect the execution result of the most recently completed command. Unlike the internal scheduling queues used in existing technologies for command scheduling, submission sorting, or execution control, the recently completed command history queue of this invention is not used for command issuance control or to determine the scheduling order. Instead, it is specifically used for historical backtracking after failures, risk range determination, debugging output, and fault reproduction analysis. By adopting a fixed-capacity, rolling-over maintenance method, this invention can stably retain the "recently completed command window," which is most valuable for failure analysis, while controlling storage overhead, thus balancing engineering feasibility and technical effectiveness.

[0057] The incomplete LBA set includes a global incomplete LBA set and a task-level incomplete LBA set, used for maintaining risk intervals globally and from a single task perspective, respectively. The interval marking function updates both the global and task-level incomplete sets simultaneously. The global set tracks all risk LBAs in the current test process as a whole, while the task-level set supports recovery, skipping, and debugging from a single task perspective. Since all risk intervals are ultimately settled into these two sets, subsequent processes can directly perform unified processing based on these sets, such as recovery execution, verification skipping, statistical output, and fault analysis.

[0058] like Figure 7 As shown, incomplete LBA sets have several subsequent applications in the testing process: For the recovery execution phase: In breakpoint resumption testing scenarios, the incomplete LBA set can serve as an auxiliary basis for recovery execution. When external control scripts or I / O engines resume execution from near the failure point based on resume_index, they can combine the incomplete LBA set to identify LBA ranges that have historically been marked as risky intervals, and focus on these intervals during subsequent overwrite, reread, or state synchronization processes. This allows recovery execution to be based not only on the failure index but also on failure-related intervals, thereby improving the targeting of the recovery process.

[0059] For test reports and statistical output: After a test ends, is paused at a certain stage, or is abnormally interrupted, the system can output the content or statistical information of the incomplete LBA set, such as the number of incomplete LBAs, their range distribution, the corresponding command index range, and associated failure events. By including the incomplete LBA set in the test report, testers can more intuitively understand the scope of the fault impact and the recovery process, improving the efficiency of log analysis and issue archiving.

[0060] For verification skip control: When performing verification on subsequent read paths, the system can first determine whether the LBA corresponding to the current read command belongs to the incomplete LBA set. If it does, the system can skip the comparison of the corresponding interval according to the strategy, or treat the interval as a delayed verification object. This implementation can avoid meaningless comparisons of intervals with uncertain states, thereby reducing false alarms.

[0061] For fault analysis and reproduction: Incomplete LBA sets can be used in conjunction with the history of recently completed commands, the index of failed commands, and the history of command lists to construct interval-level on-site information when a fault occurs. By analyzing the formation and evolution of incomplete LBA sets, testers can quickly determine the impact of faults and provide a basis for generating reproduction scripts, isolating problems, and locating root causes.

[0062] For updating the incomplete LBA set after recovery: During subsequent I / O execution after a breakpoint resumes testing, if some LBAs are overwritten, reacknowledged, or revalidated by new successful commands, the system can remove these LBAs from the incomplete LBA set or update their status. In this way, the incomplete LBA set is not only a statically marked result, but can also dynamically evolve as the test resumes and continues execution, thus continuously reflecting the most realistic risk range status.

[0063] Through the above application methods, the incomplete LBA set is expanded from simple failure marking data into a core intermediate data structure that runs through recovery execution, verification control, report output and fault analysis, further improving the overall synergistic effect and engineering applicability of the present invention.

[0064] like Figure 8 As shown, the present invention also provides an SSD testing system, which includes: The breakpoint recovery module is used to determine the running mode when the test starts. If it is a continued test, the index of the last failed command recorded is used as the breakpoint continued test index. The command loading module is used to load a command list according to the breakpoint continuation index and start executing the commands in the command list from the corresponding position. The history module is used to record information about successfully completed commands to the most recently completed command history queue during command execution. The failure handling module is used to record the index of the failed command when a command failure is detected, and to perform joint backtracking marking based on the address range of the failed command, the command list history range, and the recently completed command history range, and write the marked range into the incomplete LBA set. The verification control module is used to determine whether to skip the verification during the read command verification stage based on preset conditions. The replay control module is used to automatically reset and continue replaying the command list when the command list has been executed and the runtime has not reached the target in time-based replay mode.

[0065] The functions of each module correspond one-to-one with the steps described above. For specific implementation details, please refer to the description in the method section. They will not be repeated here. Figure 9 A hardware structure diagram of a computing device 30 for an SSD testing method is shown according to an embodiment of this specification. Figure 9 As shown, the computing device 30 may include at least one processor 301, a memory 302 (e.g., non-volatile memory), a main memory 303, and a communication interface 304, and the at least one processor 301, memory 302, main memory 303, and communication interface 304 are connected together via a bus 305. At least one processor 301 executes at least one computer-readable instruction stored or encoded in the memory 302.

[0066] It should be understood that the computer-executable instructions stored in memory 302, when executed, cause at least one processor 301 to perform the above-described combinations in the various embodiments of this specification. Figure 1-7 The description includes various operations and functions.

[0067] In the embodiments of this specification, the computing device 30 may include, but is not limited to: personal computer, server computer, workstation, desktop computer, laptop computer, notebook computer, mobile computing device, smartphone, tablet computer, cellular phone, personal digital assistant (PDA), handheld system, messaging device, wearable computing device, consumer electronic device, etc.

[0068] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A system that specifies functions in one or more boxes.

[0069] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including an instruction set implemented in a process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0070] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0071] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0072] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. An SSD testing method, characterized in that, Includes the following steps: Determine the running mode when the test starts. If it is a continuous test, obtain the index of the last failed command recorded as the breakpoint continuation test index. Load the command list according to the breakpoint continuation index, and start executing the commands in the command list from the corresponding position; During command execution, successfully completed command information is recorded in the recently completed command history queue; When a command failure is detected, the index of the failed command is recorded, and a joint backtracking mark is made based on the address range of the failed command, the historical range of the command list, and the historical range of the most recently completed command. The marked range is then written into the incomplete LBA set. During the read command verification phase, determine whether to skip the verification based on preset conditions; In time-based playback mode, when the command list has been executed and the runtime has not reached the target, the command list is automatically reset and playback continues.

2. The SSD testing method according to claim 1, characterized in that, The joint backtracking marker includes command list history backtracking and recently completed history backtracking. The command list history backtracking includes backtracking historical commands within a preset depth along the command list order based on the position of the failed command in the command list, and extracting the LBA intervals covered by these historical commands. The most recently completed history backtracking involves starting from the tail record in the most recently completed command history queue, tracing back completed commands within a preset depth in reverse order of completion time, and extracting the LBA intervals actually covered by these commands.

3. The SSD testing method according to claim 1, characterized in that, The preset conditions include one or more of the following: Pattern index condition: If the actual pattern index read meets the preset value, the verification is skipped; LBA range attribution condition: When the LBA involved in the current read command belongs to the incomplete LBA set, the corresponding range check is skipped; Command type condition: If the preceding command type corresponding to the current data source is a command type that does not require regular data comparison, skip the validation. Test phase conditions: When the test is in a preset phase, the verification is skipped.

4. The SSD testing method according to claim 1, characterized in that, The recently completed command history queue is maintained using a bounded queue structure with a maximum depth. When a new completed command is written, if the queue capacity has reached the upper limit, the oldest record is removed according to the first-in-first-out update strategy, and only the most recently completed command history is retained. The recently completed command history queue is specifically used for historical backtracking after failure, risk range determination, debugging output, and fault reproduction analysis.

5. The SSD testing method according to claim 1, characterized in that, The time-based playback mode includes a test mode that uses a preset runtime as the test termination condition. In this mode, if the cumulative runtime has not reached the preset runtime after the command list has been executed, the system will automatically reset the command list index and re-execute the command list from the beginning until the cumulative runtime reaches the preset runtime.

6. The SSD testing method according to claim 5, characterized in that, In the time-based playback mode, breakpoint continuation and automatic replay work together: When a test is interrupted due to an exception, the test will resume from the last failed command index and continue executing the command list from the vicinity of the failure point on the next startup. If the test is not interrupted and the command list is executed normally to the end but the running time has not reached the target running time, the automatic replay mechanism is triggered, the command index is reset to the beginning position and execution continues.

7. The SSD testing method according to claim 1, characterized in that, The incomplete LBA set is used for one or more of the following: During the recovery execution phase, targeted verification or rewriting operations are performed on the LBA ranges within the incomplete LBA set first, based on the incomplete LBA set. During the test reporting phase, failure logs from the incomplete LBA set are exported at the interval granularity. In the check skip control, it serves as the basis for determining whether the current read command should skip the check; In fault analysis and reproduction, the interval-level on-site information at the time of the fault is constructed in conjunction with the history of recently completed commands and the index of failed commands. During subsequent I / O operations after recovery, if some LBAs have been overwritten or re-verified by new successful commands, these LBAs will be removed from the set of incomplete LBAs or their status will be updated.

8. An SSD testing system supporting breakpoint continuation testing, failure interval marking, and data verification, characterized in that, include: The breakpoint recovery module is used to determine the running mode when the test starts. If it is a continued test, the index of the last failed command recorded is used as the breakpoint continued test index. The command loading module is used to load a command list according to the breakpoint continuation index and start executing the commands in the command list from the corresponding position. The history module is used to record information about successfully completed commands to the most recently completed command history queue during command execution. The failure handling module is used to record the index of the failed command when a command failure is detected, and to perform joint backtracking marking based on the address range of the failed command, the command list history range, and the recently completed command history range, and write the marked range into the incomplete LBA set. The verification control module is used to determine whether to skip the verification during the read command verification stage based on preset conditions. The replay control module is used to automatically reset and continue replaying the command list when the command list has been executed and the runtime has not reached the target in time-based replay mode.

9. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored on the memory and executable on the processor, wherein the processor executes the computer program to implement the SSD testing method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The device contains a computer program that, when executed by a processor, implements the SSD testing method as described in any one of claims 1-7.

Images