Method and device for verifying consistency of power-down continuous test data, equipment and medium

Abstract

The invention provides a power-down continuous test data consistency verification method and device, equipment and a medium. The method comprises the following steps: issuing a query instruction to obtain disk information of a currently connected SSD (Solid State Disk); according to the disk information, judging whether to issue a continuous test request; if a continuous test request is issued, returning a processing result according to the disk information and the continuous test request through a preset processing rule; selecting a continuous test request corresponding to a successful result as a verification request according to the processing result; and performing consistency verification on the disk information according to the verification request. By systematically executing the steps of disk information acquisition, continuous test request decision, request filtering and screening, final consistency comparison and the like, an automatic closed-loop test process is constructed, and the problem that the consistency of SSD power failure continuous test data cannot be verified by various IO tools at present is solved; and consistency verification can be carried out on the successfully written data before and after power failure.

Description

Technical Field

[0001] This invention relates to the field of solid-state drive testing, and in particular to a method, apparatus, device, and medium for verifying data consistency during power-off continuation testing. Background Technology

[0002] In solid-state drive (SSD) reliability testing, data consistency verification under power loss scenarios is crucial for evaluating its data protection capabilities and directly impacts the security of user data during sudden power outages. Currently, the industry largely uses open-source I / O tools (such as fio) for testing, but these tools have significant technical limitations and are insufficient to meet the requirements.

[0003] However, when applying such general-purpose tools to power-loss testing scenarios, their design has fundamental flaws. The working logic of fio is based on the assumption of continuous device node availability. Once an SSD drive letter disappears from the system due to a deliberate power failure, the test task will immediately terminate due to IO errors and return to a failure state. This not only leads to unexpected termination of the test process but also exposes the technical problems of existing solutions: First, test scenarios are difficult to control and construct precisely, requiring engineers to coordinate power timing and test scripts, making the process complex and difficult to reproduce; second, when faced with the critical decision of "when and how to perform data consistency verification," existing tools cannot intelligently determine and retain the verification context at the moment of power failure, making them highly susceptible to misjudgments due to interference from failed IO requests; finally, the test process lacks continuity, failing to automatically recover and complete subsequent verification after the device is powered on again, forcing the entire test to rely on manual segmented operations, resulting in low efficiency and difficulty in guaranteeing the credibility and repeatability of the conclusions. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and medium for verifying the consistency of data during power-down continuation testing. It aims to solve the problem that current IO tools cannot verify the consistency of data during power-down continuation testing, and to ensure that data successfully written before and after power-down can be verified for consistency.

[0005] In a first aspect, embodiments of the present invention provide a method for verifying the consistency of power-off continuation test data, comprising: issuing a query command to obtain disk information of the currently connected SSD; determining whether to issue a continuation test request based on the disk information; if a continuation test request is issued, returning a processing result based on the disk information and the continuation test request according to a preset processing rule; selecting the continuation test request corresponding to the successful result as a verification request based on the processing result; and performing consistency verification on the disk information based on the verification request.

[0006] Secondly, embodiments of the present invention also provide a verification device for the consistency of power-off continued testing data, which includes a unit for performing the above-described method.

[0007] Thirdly, embodiments of the present invention also provide a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0008] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a processor, can implement the above-described method.

[0009] This application provides a method, apparatus, device, and medium for verifying data consistency during power-down continuation testing. It constructs an automated closed-loop testing process by systematically executing steps such as disk information acquisition, continuation test request decision-making, request filtering, and final consistency comparison. The core of this process lies in the testing device's ability to intelligently sense the SSD device status. For continuation test IO requests issued after recovery, invalid or untrusted requests are precisely filtered out based on preset processing rules. Finally, only the data blocks associated with the filtered successful requests undergo rigorous data consistency comparison. This achieves full-process automation, overcoming the limitation of existing tools that directly terminate testing when the drive letter is lost, greatly improving testing efficiency and continuity. Secondly, through an intelligent filtering mechanism, the responsibility boundaries of the SSD are strictly distinguished, effectively preventing misjudgments and omissions caused by test logic defects, ensuring the fairness and accuracy of test conclusions. Finally, this method provides a systematic, reliable, and repeatable verification means for the data protection capabilities of SSDs under extreme power-down scenarios, significantly improving the depth and reliability of product reliability verification. Attached Figure Description

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

[0011] Figure 1 A schematic flowchart illustrating the verification method for the consistency of power-off continuation test data provided in an embodiment of the present invention; Figure 2 A schematic diagram of a sub-process of the verification method for the consistency of power-off continuation test data provided in an embodiment of the present invention; Figure 3 A schematic diagram of a sub-process of the verification method for the consistency of power-off continuation test data provided in an embodiment of the present invention; Figure 4 A schematic diagram of a sub-process of the verification method for the consistency of power-off continuation test data provided in an embodiment of the present invention; Figure 5A schematic diagram of a sub-process of the verification method for the consistency of power-off continuation test data provided in an embodiment of the present invention; Figure 6 A schematic diagram of a sub-process of the verification method for the consistency of power-off continuation test data provided in an embodiment of the present invention; Figure 7 A schematic diagram of a sub-process of the verification method for the consistency of power-off continuation test data provided in an embodiment of the present invention; Figure 8 A schematic block diagram of a verification device for the consistency of power-off continuation test data provided in an embodiment of the present invention; Figure 9 A schematic block diagram of a computer device provided for an embodiment of the present invention. Detailed Implementation

[0012] 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 some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0013] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0014] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0015] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0016] Please see Figure 1 This is a schematic flowchart illustrating the verification method for data consistency during power-down continuation testing provided in this embodiment of the invention. In this application, the verification method for data consistency during power-down continuation testing is mainly applied to the reliability verification stage in the R&D and production process of solid-state drives (SSDs), especially for high-requirement enterprise-level and data center-level SSD products. It solves the technical problem that traditional tools cannot automatically complete the entire verification process due to equipment loss during harsh testing scenarios simulating sudden power outages in operating equipment.

[0017] This application provides a method, apparatus, computer device, and storage medium for verifying the consistency of power-down resumed testing data. The method for verifying the consistency of power-down resumed testing data includes: issuing a query command to obtain the disk information of the currently connected SSD; determining whether to issue a resumed testing request based on the disk information; if a resumed testing request is issued, returning a processing result based on the disk information and the resumed testing request according to a preset processing rule; selecting the resumed testing request corresponding to the successful result as a verification request based on the processing result; and performing consistency verification on the disk information based on the verification request.

[0018] This application constructs an automated closed-loop testing process by systematically executing steps such as disk information acquisition, continuation test request decision-making, request filtering, and final consistency comparison. Its core lies in the testing device's ability to intelligently sense the SSD device status (e.g., drive letter loss). For continuation test IO requests issued after recovery, invalid or untrusted requests (e.g., unconfirmed writes during power loss) are precisely filtered out based on preset processing rules. Finally, only the data blocks associated with the filtered successful requests undergo rigorous data consistency comparison. This achieves full-process automation, overcoming the limitation of existing tools (such as fio) that directly terminate the test when the drive letter is lost, greatly improving testing efficiency and continuity. Secondly, through an intelligent filtering mechanism, the responsibility boundaries of the SSD are strictly distinguished (only verified data that has been confirmed to have been written), effectively preventing misjudgments and omissions caused by test logic defects, ensuring the fairness and accuracy of test conclusions. Finally, this method provides a systematic, reliable, and repeatable verification means for the data protection capabilities of SSDs under extreme power loss scenarios, significantly improving the depth and reliability of product reliability verification.

[0019] Figure 1 This is a flowchart illustrating the verification method for the consistency of power-off continuation test data provided in an embodiment of the present invention. Figure 1 As shown, the method includes the following steps S10-S50.

[0020] S10. Issue a query command to obtain the disk information of the currently connected SSD; Specifically, the method for verifying the consistency of data after power failure is used in the testing device to perform tests on the SSD after power failure and to verify the consistency of data before and after power failure.

[0021] The query command is a direct instruction sent by the test device to the host or SSD to request the SSD's connection status and core identification data. It includes information such as command type (disk information query) and target device filtering conditions (e.g., device bus address range), which can trigger the SSD or host to return relevant data of the currently connected SSD. The currently connected SSD refers to a solid-state drive that is physically connected to the test device / host through an interface and is in a recognizable state. The disk information is the core identification and status data of the SSD, including the drive letter (e.g., " / dev / sda" in Linux system, "D drive" in Windows system, used to locate the logical operation node of the SSD), device ID (a unique hardware code that identifies the SSD to avoid confusion with other storage devices), connection status (e.g., "online" or "disconnected", reflecting whether the SSD is interactive), logical block address (LBA) range (identifying the data address range that the SSD can read and write), etc., which are the core basis for determining whether the SSD can perform subsequent I / O operations.

[0022] In practice, after the power-off recovery test data consistency verification process is initiated, the test device first enters the "SSD connection status detection phase." The device's control module generates a standardized query command—the command explicitly specifies a request to "obtain complete disk information for all currently connected SSDs," while also carrying the test device's identification (to avoid conflicts with query commands from other devices). Subsequently, the test device sends the query command to the host or directly to the SSD via a preset communication interface. If sent to the host, the host's device management module scans all identified storage devices in the current system, filters out devices of type SSD, extracts the disk information of each SSD, and feeds it back to the test device in a unified format. If sent directly to the SSD, the SSD's firmware parses the command and directly returns its disk information (including real-time connection status, drive letter validity, etc.) to the test device, allowing the test device to proceed with subsequent steps after obtaining the disk information.

[0023] This embodiment first obtains disk information to confirm a valid SSD disk, thereby laying the foundation for subsequent data consistency verification.

[0024] Furthermore, if obtaining the disk information fails, the disk information is retrieved repeatedly according to a set timeout period; if the disk information is successfully retrieved again, a continuation test request is sent; if the disk information is not retrieved again within the timeout period, the test ends. This ensures that data verification is performed on a valid SSD disk, thereby reducing workload.

[0025] S20. Determine whether to send a continued testing request based on the disk information; Specifically, the test continuation request refers to the request issued by the testing device to resume the interrupted test process after the solid-state drive (SSD) has experienced a power outage and been reconnected to the system. In this embodiment, the test continuation request is an input / output request, i.e., an IO request. Its content includes parameters such as operation type (read / write), target logical block address (LBA), data length, and the original data corresponding to the write request. The IO request is a request executed before the SSD lost power, including requests that have been successfully executed and those that are being executed. It is the direct operation carrier for resuming the IO test and subsequently conducting data consistency verification. It is issued only when the SSD meets the test continuation conditions. Whether the test continuation conditions are met is determined based on the disk information.

[0026] Therefore, after obtaining the disk information, the testing device determines whether to issue a continued testing request based on the disk information, thereby ensuring that the continued testing IO load is accurately and reliably applied to the key control links of the correct and ready device.

[0027] In one embodiment, reference is made to Figure 2 As shown, step S20 includes steps S21-S23.

[0028] S21. Determine whether the drive letter is lost based on the drive information; S22. If lost, no continuation test request will be issued; S23. If it exists, then issue a request to continue testing.

[0029] Specifically, the drive letter refers to the logical device node path (e.g., / dev / nvme0n1) that the solid-state drive is recognized and mounted in the host operating system. It is the entry point for all input / output operations.

[0030] This embodiment primarily uses the drive letter status as the core criterion for judgment to ensure that the continued testing request (IO request) has a legitimate transmission path.

[0031] In practice, the testing device first extracts the "drive letter status" field from the acquired disk information for verification: if the disk information shows "no corresponding drive letter", or the system reports "drive letter has expired and cannot be associated with storage device", it is directly determined as "drive letter lost" - at this time, the IO request has no legal path to be transmitted to the SSD, so no continuation test request is issued; if a clear drive letter can be found in the disk information and the system marks it as "valid and available", it means that the IO request can locate the target SSD through the drive letter, which meets the basic conditions for issuing the continuation test request, so it is determined as "drive letter exists", and the testing device then generates an IO request type continuation test request with complete parameters, and issues it to the SSD through the device node corresponding to the valid drive letter, and starts the IO test continuation process after power failure.

[0032] In one embodiment, reference is made to Figure 3As shown, step S21 includes steps S211-S213.

[0033] S211. The disk information is acquired repeatedly within a preset timeout period; S212. If the disk information is successfully retrieved again, a continued testing request is sent. S213. If the disk information is not reacquired within the timeout period, the test ends.

[0034] Specifically, the timeout refers to a pre-configured key time parameter, which includes two dimensions: first, the total timeout, which is the maximum duration the device is allowed to wait for the device to recover; and second, the polling interval, which is the fixed sleep duration between two consecutive attempts to acquire disk information during the waiting period. The timeout sets the boundary for recovery attempts to avoid indefinite waiting and wasted resources. The cyclic acquisition refers to the test device repeatedly executing the disk information acquisition operation at the polling interval while in the waiting state. The successful reacquisition is a state transition event, specifically referring to the confirmation through the system interface that the target disk letter exists and is accessible again after experiencing a "disk letter lost" state.

[0035] In practice, when the testing device determines that the drive letter is lost, it immediately initiates a recovery loop constrained by the timeout period. In this loop, the testing device first enters a sleep state with a duration equal to the polling interval, then wakes up and performs a complete drive information acquisition operation. If the acquisition is successful, the loop immediately exits, and the internal state is updated to "device recovered," triggering the normal continuation test process and issuing a continuation test request. If the acquisition fails, it checks whether the accumulated waiting time since the loop started has exceeded the set total timeout period. If it has not timed out, the sleep and acquisition steps are repeated; if it has timed out, it is determined that the device cannot recover within the expected time, and the loop terminates. The testing device then records "failure to reacquire drive information within the timeout period" as a clear test conclusion, performs resource cleanup and test report generation, and then actively terminates the current test task.

[0036] This mechanism enables automatic attempts to recover from a fault state and orderly termination when recovery is deemed impossible, ensuring the automation and controllability of the testing process.

[0037] S30. If a continued testing request is issued, the processing result is returned according to the disk information and the continued testing request based on the preset processing rules.

[0038] Specifically, the preset processing rules refer to pre-configured logical rules used to parse disk information and associated data with continued testing requests. These rules primarily handle different types of requests differently, thus returning different processing results instead of directly reporting an error and stopping the process. In this embodiment, the preset processing rules mainly categorize and process IO requests into read and write types to obtain different results. The processing results are status information output based on the preset processing rules. Based on these results, each continued testing request can be filtered (the filtering mainly targets IO requests that were not written to when the SSD was powered off), to retain continued testing requests that require data consistency verification, thereby preventing non-disk version issues from occurring during subsequent data consistency checks. In this embodiment, the processing results include three outcomes: read operation failure, write operation failure, and both read and write operations succeeding.

[0039] In practice, after the testing device sends a continued testing IO request (which is explicitly defined as a read or write operation) to the SSD that has regained connection, it simultaneously starts a preset processing rule. Based on the preset processing rule, the device obtains a processing result according to the continued testing request and the disk information. In subsequent processes, the device can filter out continued testing requests that do not meet the data consistency verification (i.e., filter out continued testing requests that were not written when the SSD was powered off), thereby avoiding misjudgment and accurately verifying the consistency of data before and after power failure, preventing data loss caused by non-disk version issues.

[0040] In one embodiment, reference is made to Figure 4 As shown, step S30 may include steps S31-S34.

[0041] S31. If the request to continue testing fails, check if the drive letter exists. S32. If it does not exist, the disk information is retrieved repeatedly within a preset timeout period; S33. If the disk information is successfully obtained again, the test continuation request is resent. S34. If the disk information is not reacquired within the timeout period, the test ends.

[0042] Specifically, the timeout period refers to a pre-configured key time parameter, which includes two dimensions: first, the total timeout period, which is the maximum duration the device is allowed to wait for the device to recover; and second, the polling interval, which is the fixed sleep duration between two consecutive attempts to obtain disk information during the waiting period. The timeout period sets the boundary for recovery attempts to avoid indefinite waiting and wasted resources.

[0043] In practice, upon detecting a failed continuation test request, the testing device immediately initiates a high-priority disk information query to determine if the target drive letter's node in the file system still exists and is accessible. If this diagnosis confirms the drive letter is lost, it indicates that the SSD may have experienced a secondary abnormal power outage or a momentary physical connection interruption. The testing device will not consider this a final test failure but will instead initiate a recovery loop constrained by the aforementioned "timeout period." In this loop, the testing device periodically attempts to reacquire the disk information. If successful acquisition occurs within a certain period, the device is deemed to have recovered, and it will automatically re-initiate the previously failed continuation test request to attempt to resume the test process. If the loop continues until the timeout period expires without reacquiring the disk information, the testing device determines that the device cannot recover and proactively and systematically terminates the entire test task.

[0044] This fault-tolerant loop ensures the resilience of the testing process to temporary physical connectivity issues. Only when the continued test request is successfully issued and completed (whether successfully on the first attempt or after a retry), its execution result (success or failure) and the associated disk information are submitted to the subsequent "preset processing rules" for analysis, producing "processing results" for filtering and eventual consistency verification. This design decouples the underlying IO error recovery from the upper-layer request logic filtering, forming a layered, robust automated testing system.

[0045] In one embodiment, such as Figure 5 As shown, step S30 may include steps S35-S37.

[0046] S35. Perform read and write operations according to the continued test request; S36. If the result of read operation failure or write operation failure is returned, the continued test request shall be processed according to the preset processing rules. S37. If the result of both the read and write operations being successful is returned, then the corresponding continued test request is used to verify the data consistency of the disk information.

[0047] Specifically, in this embodiment, the continued test request is an IO request issued by the test device, which includes a clear read / write operation type, target LBA, data length, and the original data corresponding to the write operation. It is the core object that triggers the read / write operation. The preset processing rule is a pre-configured logical rule with specific processing logic for read / write operation failures. It does not directly report an error and stop the operation, and is used to filter continued test requests that meet the data consistency verification. The data consistency verification refers to comparing the original data of the write operation in the continued test request with the corresponding data read from the SSD in the read operation to confirm whether the data is consistent before and after the power failure. It is the core step in verifying the SSD's power failure protection capability.

[0048] In practice, after the testing device sends a resume test request to the SSD that has regained connection, it executes read or write operations according to the operation type of the request. If the operation returns a read or write failure result, the preset processing rules are immediately activated to process the resume test request. The rules first enter the corresponding processing branch based on the operation type of the request. Regardless of whether it is a read or write request, the core task of the rules is to combine the execution return status and disk information to make a comprehensive judgment and output an accurate "processing result".

[0049] If the rule analysis determines that the request execution failed (for example, the system call returned an error, and the analysis of the associated disk information ruled out transient link problems), then the result "read operation failed" or "write operation failed" will be output. Driven by this result, the rule will trigger specific processing logic for the failed request, such as marking the corresponding retest request as invalid, or directly removing the retest request, providing a basis for subsequent "filtering" actions and preventing it from entering the final data consistency verification stage.

[0050] Conversely, if the rule analysis confirms that the request was executed successfully, the result "Read and write both successful" will be output. This result indicates that the continued testing request itself is valid and reliable. For requests that output this result, the testing device will further enable data consistency verification logic: for write requests, it will record the address and data mode written as the expected value for subsequent read verification; for read requests, it will immediately compare the data read with the previously recorded expected value, thereby completing an accurate consistency verification of the data block associated with the continued testing request. That is, the testing device will extract the original data of the write operation in the continued testing request and compare it with the data read from the corresponding LBA of the SSD in the read operation, and perform data consistency verification on the storage data associated with the disk information to ensure accurate judgment of whether the data before and after the SSD power failure is complete, avoiding misjudgments caused by non-disk version issues.

[0051] This embodiment achieves intelligent screening and accurate verification of continued testing requests through rule-based result output and branch processing.

[0052] In one embodiment, such as Figure 6 As shown, step S36 may include steps S361-S365.

[0053] S361. If the read operation fails, check if the drive letter exists. S362. If it does not exist, the disk information is retrieved repeatedly within a preset timeout period. S363. If the disk information is successfully obtained again, the test continuation request is resent. S364. If the disk information is not reacquired within the timeout period, the test ends. S365. If the write operation fails, the corresponding test continuation request is filtered out and the test continuation request is logged.

[0054] Specifically, the read operation refers to the operation of reading specified data from the LBA corresponding to the SSD in the continued testing request; the write operation refers to the operation of writing specified data from the host to the SSD in the continued testing request.

[0055] Specifically, when the preset processing rules determine and output a "read operation failed" result, it indicates that a read request used for data acquisition or verification failed. The test device will first immediately trigger a drive letter existence diagnostic to determine whether the failure was caused by a disconnection of the underlying physical connection.

[0056] If the diagnostic confirms that the drive letter no longer exists, the testing device will not directly equate this read failure with a test failure. Instead, it will initiate a recovery loop with a preset timeout boundary, periodically attempting to reacquire complete disk information and actively probing whether the SSD has been reconnected. If the disk information is successfully acquired before the timeout expires, the testing device determines that the link has been restored and will automatically resend the same failed read request to attempt to resume the interrupted verification process. If the loop continues until the timeout and disk information cannot be acquired, the testing device determines that the device cannot be recovered and thus terminates the entire test. This series of read failure handling measures aims to ensure the continuity of the data verification process and distinguish between temporary failures caused by device offline and other reasons.

[0057] When the preset processing rule determines and outputs a "write operation failed" result, it indicates that a request for writing verification data mode has failed. The testing device's response strategy for this type of failure is fundamentally different. It immediately performs a filtering operation on the specific write request that failed, marking it as invalid in its internal list of pending verification requests and excluding it from subsequent data consistency verification. Simultaneously, the device records the request's detailed information (such as logical address, expected data, error code, etc.) in the test log for easy tracing of the failure cause. The core logic of this design is that a failed write operation means that the expected data was not reliably written to the storage medium, thus the data block itself has lost its qualification as the "gold standard" for subsequent consistency verification. Directly filtering and recording it is to prevent the data gaps or errors naturally caused by the SSD's failure to write from being misjudged as consistency failures caused by "successful writing followed by power loss," thereby accurately focusing on verifying the protection capabilities of the SSD for data that has been confirmed to have been written.

[0058] This embodiment focuses on the steps of "processing the continued test request according to the preset processing rules when the result of the read operation failure or write operation failure is returned". The core is to distinguish between read and write failure scenarios and process them separately, so as to filter out IO requests that were not written due to power failure and ensure the accuracy of data consistency verification.

[0059] S40. Select the follow-up test request corresponding to the successful result as the verification request based on the processing result.

[0060] Specifically, "successful result" refers to the state of "both read and write successful," which signifies that the corresponding continuation test request was executed completely and correctly, and that the device connection status during its execution was cross-validated as stable and reliable. "Verification request" is a subset of concepts dynamically specified internally by the device; it specifically refers to those requests corresponding to "successful results" selected from all continuation test requests. These requests, having been verified as successfully executed, possess the qualifications and credibility to serve as objects of data consistency verification operations.

[0061] In practice, after completing a test continuation request and obtaining its corresponding "processing result" through preset processing rules, the device initiates a selection logic. The core criterion of this logic is to check whether the "processing result" is "both read and write operations were successful." For each test continuation request that outputs this "successful result," the selection logic marks and extracts it, placing it into an independent "request pool to be verified" or assigning it a specific "verification eligibility" flag. This selection process is a filtering and purification step. Conversely, any test continuation request corresponding to "read operation failure" or "write operation failure" results will be excluded by this selection logic and will not be assigned the status of a "verification request."

[0062] Through this mechanism, the testing device ensures that subsequent "data consistency verification" operations are limited to requests and their associated data blocks that have been proven to have been successfully and completely executed on a stable device environment, thereby guaranteeing the reliability of the verification basis and the accuracy of the conclusions from the source.

[0063] S50. Perform consistency verification on the disk information according to the verification request.

[0064] Specifically, the consistency verification refers to comparing the original data of the write operation in the verification request with the current data read from the SSD target LBA located by the disk information to determine whether the two are completely consistent, thereby verifying whether the data was not damaged or lost before and after the power failure.

[0065] This embodiment verifies the consistency of the disk information according to the verification request to confirm whether the SSD has reliable protection capabilities for the data successfully written after experiencing a power outage, thereby systematically completing a comprehensive evaluation of the SSD's data protection capabilities in power outage scenarios.

[0066] In one embodiment, such as Figure 7 As shown, step S50 may include steps S51-S53.

[0067] S51. Read the corresponding verification data from the disk information according to the verification request; S52. Obtain the original data written into the disk information before the power failure according to the verification request; S53. Determine whether the verification data and the original data are consistent.

[0068] Specifically, the verification data refers to the instantaneous data content actually read by the testing device from the currently reconnected solid-state drive storage medium after the power outage test is completed, based on the logical address and data length recorded in the verification request, and used for comparison. The original data specifically refers to the specific data pattern or data characteristic value that the testing device recorded and saved in its local non-volatile storage (such as memory or log files) before the power outage event, which is expected to be written to the corresponding logical address. This data is the verification benchmark preset by the testing device during the initial normal testing phase, based on the write operation that has been successfully confirmed by the SSD.

[0069] In practice, the testing device iterates through its internally maintained list of "verification requests." For each request in the list, the device first issues a synchronous read command to the target SSD with the currently restored connection, based on the precise logical block address and data length recorded in the request, to obtain the actual content currently stored at that address, i.e., the "verification data." This read operation is completed at the driver layer, ensuring that the associated disk information (such as device identifier) ​​remains stable during its execution to confirm the correctness of the data source. Subsequently, the testing device uses the same logical address as the index key to query its internal data mapping table, which was built and persisted before the power failure, and retrieves the "raw data" pre-calculated and saved for that address from local storage. After successfully acquiring both data streams, the device calls a preset consistency judgment algorithm. Depending on the configuration, this algorithm may perform a precise bit-by-bit comparison byte by byte, or calculate and compare the hash values ​​(such as CRC32 or SHA-256) of the two data segments.

[0070] If the comparison results confirm a perfect match, the judgment logic outputs a "consistent" conclusion, indicating that the SSD power failure did not cause data corruption in that area. If any detectable differences exist, the logic outputs a "disconsistent" conclusion, indicating that the SSD power failure caused data corruption in that area. This final conclusion, along with the request identifier, address information, and details of the differences (if any), is recorded as the result of this verification, thus completing the authoritative determination of the consistency status of a single data block before and after the power failure.

[0071] Therefore, this embodiment determines whether the SSD data is complete before and after power failure by reading the verification data, retrieving the original data and comparing them, providing a basis for subsequent analysis of the SSD power failure protection performance.

[0072] This application constructs an automated closed-loop testing process by systematically executing steps such as disk information acquisition, continuation test request decision-making, intelligent fault-tolerant recovery, request filtering, and final consistency comparison. Its core lies in the testing device's ability to intelligently sense the SSD device status (e.g., drive letter loss) and wait for device recovery through a preset timeout loop mechanism, rather than stopping immediately upon encountering an error. For continuation test IO requests issued after recovery, the testing device diagnoses and classifies their execution results (read / write failure or success) according to preset processing rules, and precisely filters out invalid or untrusted requests (e.g., unconfirmed writes during power loss). Finally, only the data blocks associated with the filtered successful requests undergo a strict consistency comparison between the "raw data" and the "verification data." This application achieves full-process automation, overcoming the limitation of existing tools (such as fio) that directly terminate the test when the drive letter is lost, greatly improving testing efficiency and continuity. Secondly, through an intelligent filtering mechanism, the responsibility boundaries of the SSD are strictly distinguished (only the data that has been confirmed to have been written is verified), effectively preventing misjudgments and omissions caused by defects in the testing logic, and ensuring the fairness and accuracy of the test conclusions. Finally, this method provides a systematic, reliable, and repeatable verification method for the data protection capabilities of SSDs under extreme power loss scenarios, significantly improving the depth and reliability of product reliability verification.

[0073] Figure 8 This is a schematic block diagram of a power-off continuation test data consistency verification device 300 provided in an embodiment of the present invention. Figure 8 As shown, corresponding to the above-described verification method for power-down continuation test data consistency, the present invention also provides a power-down continuation test data consistency verification device 300. This power-down continuation test data consistency verification device 300 includes a unit for performing the above-described power-down continuation test data consistency verification method, and the device can be configured in a computer device. Specifically, please refer to... Figure 8 The power failure resume test data consistency verification device 300 includes a distribution unit 301, a judgment unit 302, a processing unit 303, a selection unit 304, and a verification unit 305.

[0074] The issuing unit 301 is used to issue a query command to obtain the disk information of the currently connected SSD; to not issue a continuation test request if the information is lost; to issue a continuation test request if the information exists; to issue a continuation test request if the disk information is successfully obtained again; to reissue the continuation test request if the disk information is successfully obtained again; and to reissue the continuation test request if the disk information is successfully obtained again. The judgment unit 302 is used to determine whether to send a continuation test request based on the disk information; to determine whether the disk letter exists if the continuation test request fails to be sent; and to determine whether the disk letter exists if the read operation fails. The processing unit 303 is configured to, if a continued testing request is issued, return a processing result based on the disk information and the continued testing request according to a preset processing rule; and to perform read and write operations according to the continued testing request; if a read operation fails or a write operation fails, the continued testing request is processed according to the preset processing rule. Selection unit 304 is used to select the follow-up test request corresponding to the successful result as a verification request based on the processing result. The verification unit 305 is used to perform consistency verification on the disk information according to the verification request; and if the result of both the read operation and the write operation being successful is returned, the corresponding continuation test request is used to verify the data consistency of the disk information.

[0075] In one embodiment, the determination unit 302 includes a first determination unit; The first judgment unit is used to determine whether the drive letter is lost based on the drive information.

[0076] In one embodiment, the sending unit includes an acquisition unit and an ending unit; The acquisition unit is configured to repeatedly acquire the disk information within a preset timeout period; and to repeatedly acquire the disk information within a preset timeout period if the disk does not exist. The termination unit is configured to terminate the test if the disk information is not reacquired within the timeout period; to terminate the test if the disk information is not reacquired within the timeout period; and to terminate the test if the disk information is not reacquired within the timeout period.

[0077] In one embodiment, the processing unit 303 includes a filtering unit; The filtering unit is used to filter the corresponding test continuation request if the write operation fails, and to log the test continuation request.

[0078] In one embodiment, the verification unit 305 includes a first acquisition unit and a second judgment unit; The first acquisition unit is used to read the corresponding verification data in the disk information according to the verification request; and to acquire the original data written into the disk information before the power failure according to the verification request. The second judgment unit is used to determine whether the original data and the verification data are consistent.

[0079] It should be noted that those skilled in the art can clearly understand that the specific implementation process of the above-mentioned verification device for the consistency of power-off test data and each unit can be referred to the corresponding description in the foregoing method embodiments. For the sake of convenience and brevity, it will not be repeated here.

[0080] The aforementioned verification device 300 for verifying the consistency of power-off continuation test data can be implemented as a computer program, which can, for example... Figure 9 It runs on the computer device shown.

[0081] Please see Figure 9 , Figure 9 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a terminal or a server. The terminal can be an electronic device with communication functions, such as a smartphone, tablet, laptop, desktop computer, personal digital assistant, or wearable device. The server can be a standalone server or a server cluster composed of multiple servers.

[0082] See Figure 9 The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0083] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions that, when executed, cause the processor 502 to perform a power-down continuation test data consistency verification method.

[0084] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0085] The internal memory 504 provides an environment for the operation of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a method for verifying the consistency of data after power failure.

[0086] This network interface 505 is used for network communication with other devices. Those skilled in the art will understand that... Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. The specific computer device 500 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0087] The processor 502 is used to run the computer program 5032 stored in the memory to implement the steps of the above-mentioned verification method for the consistency of power-off test data.

[0088] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0089] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0090] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program, wherein the computer program includes program instructions. When executed by a processor, the program instructions cause the processor to perform the steps of the above-described verification method for data consistency during power-down continuation testing.

[0091] The storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0092] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0093] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0094] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this 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.

[0095] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0096] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for verifying the consistency of data during power-off continuation testing, characterized in that, The method includes: Send a query command to obtain the disk information of the currently connected SSD; Determine whether to issue a continuation test request based on the disk information; If a continuation test request is issued, the processing result is returned according to the disk information and the continuation test request based on the preset processing rules; Based on the processing results, select the follow-up test request corresponding to the successful result as the verification request; The disk information is verified for consistency based on the verification request.

2. The method according to claim 1, characterized in that, The step of determining whether to issue a continuation test request based on the disk information includes: Determine whether the drive letter is lost based on the drive information; If the test is lost, no further test request will be sent. If it exists, a request to continue testing will be sent.

3. The method according to claim 2, characterized in that, The steps for not issuing a continuation test request if the test is lost include: The disk information is retrieved cyclically within a preset timeout period; If the disk information is successfully retrieved again, a continued testing request will be sent. If the disk information is not retrieved again within the timeout period, the test ends.

4. The method according to claim 1, characterized in that, The step of returning a processing result based on the disk information and the test continuation request according to preset processing rules if a test continuation request is issued includes: If the request to continue testing fails, check if the drive letter exists. If it does not exist, the disk information will be retrieved repeatedly within a preset timeout period; If the disk information is successfully retrieved again, a new test continuation request will be issued. If the disk information is not retrieved again within the timeout period, the test ends.

5. The method according to claim 1, characterized in that, The step of returning a processing result based on the disk information and the continued testing request according to preset processing rules includes: Perform read and write operations respectively according to the continued test request; If the read operation fails or the write operation fails, the continued test request is processed according to the preset processing rules. If both the read and write operations are successful, the corresponding continued test request will be used to verify the data consistency of the disk information.

6. The method according to claim 5, characterized in that, If the read operation fails or the write operation fails, the step of processing the continued testing request according to the preset processing rules includes: If the read operation fails, check if the drive letter exists. If it does not exist, the disk information will be retrieved repeatedly within a preset timeout period; If the disk information is successfully retrieved again, the continued testing request will be resent. If the disk information is not retrieved again within the timeout period, the test ends. If the write operation fails, the corresponding test continuation request is filtered out and the test continuation request is logged.

7. The method according to claim 1, characterized in that, The step of performing consistency verification on the disk information according to the verification request includes: Read the corresponding verification data from the disk information according to the verification request; According to the verification request, obtain the original data corresponding to the disk information written before the power failure; Determine whether the original data and the verification data are consistent.

8. A verification device for the consistency of data during power-off continuation testing, characterized in that, Includes a unit for performing the method as described in any one of claims 1-7.

9. A computer device, characterized in that, The computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in any one of claims 1-7.

10. A storage medium, characterized in that, The storage medium stores a computer program, which includes program instructions that, when executed by a processor, can implement the method as described in any one of claims 1-7.

Images