Solid state disk self-adaptive test system and method based on composite environment fingerprint

Abstract

The application discloses a kind of based on composite environment fingerprint solid state disk self-adapting test system and method, system includes central dispatch server and test agent platform, central dispatch server is configured with fingerprint generation unit, for generating target composite environment fingerprint;Test agent platform includes acquisition module, out-of-band management module, decision module and execution module;Acquisition module is used to obtain solid state disk hardware attribute and host software environment information;Out-of-band management module runs at BMC side, independent of host operating system maintenance physical layer environment vector, and receives acquisition module heartbeat maintenance software layer environment vector;Decision module is used to generate current composite environment fingerprint and compare with target composite environment fingerprint to determine operation type, and whether update historical composite environment fingerprint after environment switching according to fingerprint consistency determination;Execution module is used to execute corresponding environment switching operation.The application realizes the unified modeling and adaptive switching of SSD test environment.

Description

Technical Field

[0001] This application relates to the field of solid-state drive testing technology, and in particular to an adaptive testing system and method for solid-state drives based on composite environmental fingerprints. Background Technology

[0002] With the rapid development of cloud computing and big data, the demand for enterprise-grade solid-state drives (SSDs) has surged. The development of SSDs requires extensive compatibility and stress testing across various hardware platforms (different motherboards, CPUs, PCIe controllers) and software environments (different operating systems, driver versions, BIOS settings). Currently, R&D labs commonly prepare their environments by manually plugging and unplugging hard drives, reinstalling the system, or restoring from Ghost images, which presents the following significant problems: First, there is a disconnect between hardware status and environment. Existing solutions cannot uniformly model hardware attributes such as SSD firmware version and controller model with software attributes such as OS and driver version, resulting in a disconnect between the test environment and the actual application scenario, and thus low reference value of the test results.

[0003] Second, the integration and debugging of drivers and firmware is inefficient. Each time a driver or firmware is changed, the entire operating system often needs to be reinstalled, with an iteration cycle that can take several hours.

[0004] Third, there is a lack of BIOS-level control. Existing automated tools cannot modify the BIOS parameters of the test machine, causing the testing process to be interrupted and requiring manual intervention.

[0005] Fourth, the purity of the environment cannot be guaranteed. Residual partition tables or cached data inside the solid-state drive can interfere with the accuracy of subsequent performance tests.

[0006] Fifth, the system cannot self-heal under abnormal conditions. When the operating system crashes or fails to boot, existing solutions lack an automated recovery mechanism, causing testing tasks to stall for extended periods. Summary of the Invention

[0007] In view of this, this application provides an adaptive testing system and method for solid-state drives based on composite environmental fingerprints to solve the above problems.

[0008] To solve the above-mentioned technical problems, one technical solution adopted in this application is: to provide a solid-state drive adaptive testing system based on composite environment fingerprint, including a central scheduling server and a test agent platform, wherein the test agent platform is deployed on the physical machine under test; The central scheduling server is equipped with a fingerprint generation unit, which is used to generate a target composite environment fingerprint according to the target configuration of the test task. The test agent platform includes: The acquisition module is used to obtain the hardware attributes of the solid-state drive and the software environment information of the host operating system; The out-of-band management module runs on the BMC side of the test agent platform. It is used to independently acquire and maintain the physical layer environment vector, which includes the solid-state drive firmware version and BIOS configuration, and to receive the heartbeat reported by the acquisition module and maintain the software layer environment vector. The decision module communicates with the out-of-band management module and is used to generate the current composite environment fingerprint based on the physical layer environment vector and the software layer environment vector. It compares the current composite environment fingerprint with the target composite environment fingerprint to determine the type of operation to be performed. After the environment switching operation is completed, it judges whether the current composite environment fingerprint and the target composite environment fingerprint are consistent. If they are consistent, the historical composite environment fingerprint is updated. If they are inconsistent, the update of the historical composite environment fingerprint is prohibited. The execution module communicates with the decision module and is used to perform the environment switching operation corresponding to the operation type.

[0009] To address the aforementioned technical problems, another technical solution adopted in this application is: providing an adaptive testing method for solid-state drives based on composite environment fingerprints, which is applied to the aforementioned adaptive testing system for solid-state drives based on composite environment fingerprints. The method includes: The fingerprint generation unit of the central scheduling server generates the target composite environment fingerprint according to the test plan, and the central scheduling server distributes the task to the test agent platform. The current environment fingerprint is collected, including: the out-of-band management module obtains the physical layer environment vector before the operating system loads; the acquisition module obtains the software layer environment vector through the system API and reports the heartbeat to the out-of-band management module; the decision module merges the physical layer environment vector and the software layer environment vector to generate the current composite environment fingerprint. The decision module compares the current composite environment fingerprint with the target composite environment fingerprint to determine the type of operation to be performed; The execution module performs the corresponding environment switching operation based on the operation type; The decision module determines whether the current composite environment fingerprint is consistent with the target composite environment fingerprint. If they are consistent, the historical composite environment fingerprint is updated. If they are inconsistent, the update of the historical composite environment fingerprint is prohibited and an alarm is reported. The test agent platform uploads the test results to the central dispatch server.

[0010] Compared to existing technologies, this invention integrates the solid-state drive firmware version, PN number, operating system version, driver version, and BIOS configuration items into a composite environmental fingerprint, achieving unified modeling of hardware attributes and software environment. This allows for standardized description and precise matching of the test environment. The out-of-band management module operates independently of the host operating system, continuously sensing the physical hardware status even when the OS crashes. Combined with the decision module's rapid identification of the UNKNOWN state and automatic triggering of complete image recovery, it achieves unattended self-healing in extreme abnormal scenarios such as operating system crashes, significantly reducing test downtime. After environment switching, the decision module conditionally updates historical fingerprints based on fingerprint comparison results, ensuring the purity of the historical baseline and preventing rollback to the target due to abnormal environment contamination. The collaborative work of the acquisition module, out-of-band management module, decision module, and execution module enables automated execution of the entire chain from BIOS parameter configuration to system image recovery, eliminating the need for manual hard drive insertion / reinstallation or system reinstallation, significantly improving the efficiency and reliability of solid-state drive R&D testing. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of an embodiment of the solid-state drive adaptive testing system based on composite environmental fingerprinting of the present invention.

[0012] Figure 2 This is a flowchart illustrating an embodiment of the adaptive testing method for solid-state drives based on composite environmental fingerprints according to the present invention. Detailed Implementation

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

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

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

[0016] Figure 1 A schematic diagram of an embodiment of the solid-state drive adaptive testing system based on composite environmental fingerprinting of the present invention is shown. Figure 1 As shown, the solid-state drive adaptive testing system based on composite environmental fingerprinting includes: a central scheduling server 1 and a test agent platform 2, with the test agent platform 2 deployed on the physical machine under test.

[0017] The central scheduling server 1 is equipped with a fingerprint generation unit, which is used to generate a target composite environment fingerprint according to the target configuration of the test task.

[0018] Specifically, the central scheduling server 1 is a Dell PowerEdge R750 server, configured with a Xeon Gold 6330 CPU, 128GB RAM, and an Ubuntu 20.04 LTS operating system. A MySQL database is deployed on the server to store the composite environment fingerprint index, image metadata, task progress status table for each test node, recently successful composite environment fingerprint records, and circuit breaker counters. The central scheduling server 1 is equipped with a fingerprint generation unit 11. This unit, based on the target configuration of the test task, including the solid-state drive firmware version, PN number, operating system version, driver version, and BIOS configuration items, serializes these fields in a preset fixed order and calculates the SHA-256 hash value to generate the target composite environment fingerprint.

[0019] The test agent platform 2 includes: a data acquisition module 21, an out-of-band management module 22, a decision-making module 23, and an execution module 24.

[0020] Specifically, test agent platform 2 is deployed on the physical machine under test, using a Dell PowerEdge R740xd server (supporting IPMI 2.0) and a KVM virtualization platform installed. The test virtual machine is equipped with an Intel i7-9700 CPU (pass-through NVMe device) and 16GB of RAM. Test agent platform 2 consists of four core components: acquisition module 21, out-of-band management module 22, decision module 23, and execution module 24.

[0021] The acquisition module 21 is used to acquire the hardware attributes of the solid-state drive and the software environment information of the host operating system.

[0022] Specifically, the acquisition module 21 runs within the host operating system, reading hardware attributes such as the solid-state drive firmware version and PN number via NVMe Admin Command or SAT command; and obtaining operating system software environment information via system APIs (e.g., obtaining the OS version by reading / etc / os-release in Linux, and obtaining the driver version through the system driver information query interface). The acquisition module 21 periodically reports heartbeat and software layer environment information to the out-of-band management module 22. Upon startup, the module checks the / run / autotest_ready.flag (Linux) or \autotest_ready.flag (Windows, located in the root directory of the system partition) flag file. If it exists, it immediately and proactively reports a heartbeat and deletes the file to ensure rapid system readiness after recovery.

[0023] Out-of-band management module 22 runs on the BMC side of test agent platform 2. It is used to independently acquire and maintain the physical layer environment vector containing the solid-state drive firmware version and BIOS configuration, and to receive the heartbeat reported by acquisition module 21 and maintain the software layer environment vector.

[0024] Specifically, the out-of-band management module 22 operates independently on the BMC (Baseboard Management Controller) side, communicating with the server BMC via IPMI 2.0 or the Redfish protocol. This module runs independently of the host operating system. After each physical server cold boot or restart, before the operating system loads, it directly reads the NVMe controller's PCIe configuration space and Identify Controller data structure via the PCIe-side bandpass (such as MCTP over PCIe-VDM protocol) to obtain the current PN and firmware version. Simultaneously, it reads BIOS non-volatile variables via BMC / IPMI (if out-of-band is unavailable, it falls back to the most recently booted UEFI variable or POST log cached by the BMC; if the cache is empty, it attempts to read the default settings via IPMI; if this also fails, it marks BIOS_CFG as "DEFAULT_UNKNOWN" and issues an alarm, pausing the task), and refreshes and caches data including the PN, current firmware version, and... Physical layer environment vector The data includes a timestamp t1. This set of data operates completely independently of the operating system, ensuring that the physical hardware status is still monitored even if the OS crashes. The out-of-band management module 22 is also responsible for receiving heartbeat reports from the acquisition module 21 and maintaining the software-layer environment vector. (Include , The cache uses a lenient timestamp verification mechanism.

[0025] The decision module 23 is connected to the out-of-band management module 22. It is used to generate the current composite environment fingerprint based on the physical layer environment vector and the software layer environment vector, compare the current composite environment fingerprint with the target composite environment fingerprint to determine the type of operation to be performed, and determine whether the current composite environment fingerprint and the target composite environment fingerprint are consistent after the environment switching operation is completed. If they are consistent, the historical composite environment fingerprint is updated; if they are inconsistent, the update of the historical composite environment fingerprint is prohibited.

[0026] Specifically, the decision module 23 communicates with the out-of-band management module 22, employing a two-layer parsing logic. The decision layer extracts the original field values ​​from the current composite environment fingerprint and compares them item by item with the target composite environment fingerprint (firmware version, OS version, driver version, BIOS parameters) to determine the specific dimensions of difference. The retrieval layer uses the complete composite environment fingerprint hash value as the image library retrieval key to quickly locate the matching base image and differentiation layer. The decision module 23 generates the current composite environment fingerprint based on the physical layer environment vector and the software layer environment vector, and compares the current composite environment fingerprint with the target composite environment fingerprint to determine the type of operation to be performed. After the environment switching operation is completed, the decision module 23 determines whether the current composite environment fingerprint and the target composite environment fingerprint are consistent. If they are consistent, the historical composite environment fingerprint is updated; if they are inconsistent, updating the historical composite environment fingerprint is prohibited.

[0027] The execution module 24 is communicatively connected to the decision module 23 and is used to perform the environment switching operation corresponding to the operation type.

[0028] Specifically, the execution module 24 is communicatively connected to the decision module 23 and includes a driver engine (installation / uninstallation / switching), an image engine (layered image download / restore), and a firmware flashing module (calling nvme commands) to execute the environment switching operation corresponding to the operation type determined by the decision module 23.

[0029] Furthermore, the composite environment fingerprint is generated as follows: the firmware version, PN number, operating system version, driver version and BIOS configuration items of the solid-state drive are serialized in a preset fixed order, and a hash value is calculated using a hash algorithm. The hash value is then used as the composite environment fingerprint.

[0030] Specifically, the essence of a composite environment fingerprint is to integrate the hardware attributes of the solid-state drive (SSD) with the host software environment attributes into a unique, standardized environment identifier. A composite environment fingerprint contains five core fields: firmware version (…). ), PN number ( ), operating system version ( ), driver version ( ) and BIOS configuration items ( The "Driver Version" field should be filled with the user-visible version number of the NVMe driver in all scenarios: for scenarios with loadable kernel modules, fill in the module version (e.g., obtained through modinfo nvme | grep version); for scenarios with built-in kernel drivers, fill in the kernel version (e.g., obtained through the system kernel version query interface), ensuring consistent hash calculations within the same environment.

[0031] Arrange the above five fields in a preset fixed order: , , , , It uses compact serialization in JSON format. JSON format completely eliminates parsing ambiguity caused by special characters within fields (such as underscores, periods, parentheses, etc.). For example, a typical target environment serialization result would be: {"fw_ver":"A01","pn":"Solid State Drive-1234","os_ver":"Ubuntu 22.04","drv_ver":"1.2.3","bios_cfg":{"PcieLinkSpeed":"Gen4","BootOrder":"PXE,Solid State Drive"}}; The SHA-256 hash algorithm is used to calculate the hash value of the above JSON string, and the resulting 64-bit hexadecimal hash value is used as the composite environment fingerprint of this environment. The collision-resistant property of the SHA-256 algorithm ensures that it is almost impossible for different environment configurations to generate the same composite environment fingerprint, achieving zero collision of environment identification.

[0032] In this embodiment, during the task issuance phase, the fingerprint generation unit 11 of the central scheduling server 1 generates the target composite environment fingerprint according to the test plan and issues it to the test agent platform 2. During the environment acquisition phase, the test agent platform 2 serializes the acquired current environment information and calculates SHA-256 according to the same rules to generate the current composite environment fingerprint. Since the generation rules are completely consistent, the target composite environment fingerprint and the current composite environment fingerprint are directly comparable.

[0033] Through the standardized generation method described above, composite environmental fingerprints can be uniformly identified, stored, and retrieved as unique environmental identifiers throughout the entire testing system, laying a data foundation for subsequent difference comparisons and accurate decision-making.

[0034] Furthermore, the out-of-band management module 22 is also used to: mark the operating system version and driver version as UNKNOWN when the heartbeat timeout is detected to have reached a preset number of consecutive times.

[0035] Specifically, during normal operation of the host operating system, the acquisition module 21 reports a heartbeat to the out-of-band management module 22 every 5 seconds. The heartbeat data packet contains the current OS version and driver version information. The out-of-band management module 22 continuously listens for the heartbeat signal. When the out-of-band management module 22 detects that it has not received a heartbeat for 3 consecutive times (i.e., 15 consecutive seconds), it determines that the host operating system has crashed or the acquisition module 21 is not functioning properly. At this time, the out-of-band management module 22 automatically transfers the software layer environment vector. In and The field is marked as UNKNOWN, while the physical layer environment vector is retained. (Includes PN, firmware version, This mechanism ensures that even in the event of a complete operating system crash, the system can still perceive the physical hardware status through the out-of-band management module 22 on the BMC side.

[0036] After the decision module 23 detects the UNKNOWN state, it skips the regular difference comparison and unconditionally determines that the operation to be performed is a complete image recovery.

[0037] Specifically, when the decision module 23 obtains the current environment vector, it first checks... In and Whether it is marked as UNKNOWN. If UNKNOWN is detected, the decision module 23 skips the regular item-by-item difference comparison process and unconditionally determines that the operation to be performed is a full image recovery. This "fast track" mechanism avoids meaningless fingerprint item-by-item comparison when the OS has crashed, directly triggers the recovery process, and significantly shortens the abnormal recovery time.

[0038] The complete image recovery process specifically includes: After determining to perform a complete image recovery, the decision module 23 first reads the historical composite environment fingerprint of the node's most recent successful achievement of the task objective from the persistent record as a recovery candidate, and queries the central scheduling server 1 to see if the base image and differentiation layer corresponding to the candidate still exist in the image library (a temporary lease lock is applied during the query, valid for 10 minutes, to ensure the atomicity of the "check-pull" operation). If available, the historical composite environment fingerprint is used as the recovery target; if unavailable, the target composite environment fingerprint of the current task is used as a fallback, and the abnormal circuit breaker counter is incremented. Subsequently, the execution module 24 performs out-of-band BIOS settings and system image recovery operations: the out-of-band management module 22 switches to physical recovery mode, performs Secure Erase to thoroughly clean the solid-state drive, pulls the image according to the recovery target composite environment fingerprint and performs recovery, and finally creates a marker file and restarts into the target OS. After the recovery is completed, the acquisition module 21 detects the marker file and immediately reports the heartbeat, and the system comes back online.

[0039] Furthermore, to prevent the system from repeatedly crashing in the UNKNOWN state and causing an infinite recovery loop, an abnormal circuit breaker counter is configured. For each test node, the number of consecutive failures triggered by a full recovery in the UNKNOWN state is recorded. After each UNKNOWN recovery, the system enters a 10-minute stability observation window. If it crashes again within this window, the circuit breaker counter is incremented by one. When the number of consecutive failures reaches the threshold of three, the system automatically stops automatic recovery, marks the node as requiring "manual intervention," and freezes task issuance to avoid an infinite loop.

[0040] Through the above mechanism, this invention achieves automatic recovery without human intervention in operating system crash scenarios, while avoiding the risk of infinite recovery loops through circuit breaker protection.

[0041] Furthermore, when merging the physical layer environment vector and the software layer environment vector: if the timestamp of the software layer environment vector is marked as to be refreshed, the timestamp verification is skipped and the vector is merged directly; otherwise, the absolute difference between the timestamps of the physical layer environment vector and the software layer environment vector is verified to be less than a preset threshold.

[0042] Specifically, after each cold start or restart of the physical server, before the operating system loads, the out-of-band management module 22 reads the NVMe Identify Controller data structure through the PCIe side band channel to obtain the PN and firmware version, and reads the BIOS non-volatile variables through BMC / IPMI to obtain... ,generate = ( , , The data is recorded along with a timestamp t1. This timestamp is accurate to the millisecond and records the moment when the physical layer information was read.

[0043] During normal operation of the host operating system, the acquisition module 21 obtains the OS version and driver version through the system API and generates... The data collection module 21 reports its heartbeat to the out-of-band management module 22 every 5 seconds, and each report includes the latest data collection timestamp t2. and its timestamp t2.

[0044] In normal merging scenarios, i.e. When the timestamp is a normal value (not marked "awaiting refresh") and the heartbeat is valid, decision module 23 verifies whether the absolute difference between the timestamps of the physical layer and the software layer is less than a preset threshold of 120 seconds, i.e., verifying |t2 - t1| < 120s. The logic behind this verification is that the physical layer environment vector is collected when the server starts, while the software layer environment vector is periodically reported during OS operation; both reflect the environment state within the same startup cycle. If the timestamp difference exceeds 120 seconds, it indicates... This could originate from an earlier boot cycle (e.g., a physical reboot after a BIOS change, but the old heartbeat data hasn't timed out and been cleared). In this case, merging might cause a mismatch between the physical and software layers. Only after successful verification can the data be merged into a complete current environment vector. .

[0045] When the BIOS configuration changes (e.g., changing the PCIe link from Gen3 to Gen4 via out-of-band management module 22), the physical server needs to be rebooted for the new BIOS configuration to take effect. During the reboot process, out-of-band management module 22 will... The cache is marked as "pending refresh" (timestamp set to a special status value). This is because the old operating system instance has terminated after the reboot, and the new operating system has not yet been loaded. The data in the cache has expired. The acquisition module 21 reports for the first time after the new operating system boots up. At that time, the out-of-band management module 22 detected If the timestamp is marked as "to be refreshed", then the timestamp verification will be skipped during the merge (i.e., |t2-t1|<120s will not be verified), and the merge will proceed directly. With the new This is because a physical reboot after a BIOS change will inevitably lead to... Re-collect (with a new t1), and The "to be refreshed" flag ensures that it must be newly reported data after the restart, and both reflect the same time segment, so there is no need to perform time window verification.

[0046] After three consecutive heartbeat timeouts, the out-of-band management module 22 will... In and Marked as UNKNOWN, merged with Enter the current attribute. and Enter UNKNOWN.

[0047] Through the aforementioned flexible timestamp verification mechanism, this invention not only ensures the time consistency of physical layer and software layer data under normal scenarios, but also solves the verification problem in scenarios such as BIOS changes through the "to be refreshed" marker.

[0048] Furthermore, the environment switching operations performed by execution module 24 include: 1. Firmware flashing operation, used to perform firmware flashing when only the firmware is different.

[0049] Specifically, the firmware flashing operation is triggered when decision module 23 determines "only the firmware is different". The execution process is as follows: Execution module 24 calls the nvme fw-download command to download the target firmware file to the solid-state drive, and then calls the nvmefw-commit command to submit the firmware update. The non-reboot activation method is preferred (--action=2 indicates activation after download but no reboot, --action=3 indicates download and immediate activation). If a reset is required, out-of-band management module 22 sends a PCIeFLR (functional-level reset) or Secondary Bus Reset via BMC. After reset, device readiness polling is performed: the nvme list command is executed cyclically at 1-second intervals, with a maximum wait of 30 seconds. If the device path changes, the mapping table is updated; otherwise, an alarm is triggered and the process exits. After firmware flashing is complete, the current firmware version is read using the nvme id-ctrl command and compared with the target version. A maximum of three retries are made; if all three attempts fail, an alarm is triggered and the process exits, and logs are uploaded (including return code, current version, target version, and number of reset attempts). Updates are made after successful flashing. The firmware version field in the file contains the persistence progress "S4a_done".

[0050] 2. Driver switching operation, used to perform driver switching when only the drivers are different.

[0051] Specifically, the driver switching operation is triggered when decision module 23 determines that "only the drivers are different." Different execution strategies are adopted based on the operating system type and driver type (loadable kernel module or built into the kernel): (1) Windows Environment: Execution module 24 reboots and boots the system into WinPE (Windows Preinstallation Environment) via out-of-band management module 22. In WinPE, the target driver is injected offline using the DISM (Deployment Image Servicing and Management) tool. After injection, the system boot configuration management tool is used to enumerate all boot entries and precisely locate the boot entry that meets the following conditions: (1) the description field contains "Windows"; (2) it points to the target system partition; (3) the path field is winload.exe (traditional BIOS) or winload.efi (UEFI). The boot entry is placed on top (set as the default boot entry), and then the system is rebooted into the target system. After entering the target system, the acquisition module 21 obtains the current driver version through Device Manager or the Get-WmiObject command and compares it with the driver version field in the target composite environment fingerprint for verification. After verification, the system is updated. .

[0052] (2) Linux environment (loadable kernel module): Execution module 24 compiles the target version of the NVMe kernel module through the dynamic kernel module management mechanism, executes update-initramfs -u to update the initial memory disk, modifies the GRUB configuration to add module loading parameters, and then restarts the system. After restarting, the current module version is obtained by using modinfo nvme | grep version and compared with the driver version field in the target composite environment fingerprint for verification.

[0053] (3) Linux environment (kernel built-in driver, i.e., kernel replacement): Execution module 24 calls the system package manager (such as a Debian or Red Hat-based package management tool) to install a new kernel containing the target driver. The package manager automatically updates the GRUB configuration, executes grub-set-default to set the new kernel as the default boot option, and then restarts the system. After restarting, the current kernel version is obtained through the system kernel version query interface and compared with the driver version field in the target composite environment fingerprint for verification (because the driver version is equal to the kernel version in the kernel built-in driver scenario).

[0054] 3. Out-of-band BIOS settings and system image recovery operations, used to perform when the operating system is different, the BIOS configuration is different, or an UNKNOWN state is detected.

[0055] Specifically, the out-of-band BIOS settings and system image recovery operation is triggered when the decision module 23 determines that "the OS is different", "the BIOS configuration is different", or detects an UNKNOWN state. This operation includes sub-steps such as determining the target composite environment fingerprint, BIOS configuration synchronization, and layered image recovery.

[0056] By differentiating the execution of the above three types of operations, this invention achieves "on-demand switching"—only the firmware is not touched at the same time as the OS and the driver, and only the driver is not touched at the same time as the firmware and the OS, thus minimizing the overhead and risk of environment switching.

[0057] Furthermore, the central dispatch server 1 also includes an image library, and out-of-band BIOS settings and system image recovery operations include determining the composite environment fingerprint of the recovery target, specifically including: 1. If the reason for entering the recovery is the UNKNOWN state, then read the historical composite environment fingerprint from the persistent record as a candidate, and check whether the base image and differential layer corresponding to the candidate still exist in the image library. If they exist, then use the candidate as the recovery target. If they do not exist, then use the target composite environment fingerprint of the current task as a fallback and increment the abnormal circuit breaker counter.

[0058] 2. If it is not an UNKNOWN scenario, then directly use the target composite environment fingerprint of the current task.

[0059] Specifically, when decision module 23 determines that a full image restoration needs to be performed, it first needs to determine the composite environment fingerprint of the restoration target. This determination process is divided into two scenarios: Scenario 1: UNKNOWN Scenario (Operating system crash or heartbeat loss). In this scenario, the system cannot determine the current OS version or driver version. The only reliable information is the physical layer environment vector maintained by the out-of-band management module 22. (PN, firmware version, The process for determining the recovery target is as follows: (1) The decision module 23 reads the "historical composite environment fingerprint of the most recent successful achievement of the task objective" of the test node from the persistent record of the central scheduling server 1 as a candidate. The historical composite environment fingerprint records the complete environment configuration (including firmware version, PN number, OS version, driver version, BIOS configuration) when the node last successfully completed the test task. It is updated and persisted by the central scheduling server 1 in the S5 stage when the current composite environment fingerprint is consistent with the target composite environment fingerprint.

[0060] (2) The decision module 23 queries the central scheduling server 1 to see if the base image and the differentiation layer corresponding to the historical composite environment fingerprint still exist in the image library 12. During the query, the central scheduling server 1 applies a temporary lease lock (valid for 10 minutes) to the queried image layer to ensure that these image layers will not be deleted by the garbage collection process during the query and subsequent pull operations. This "check-pull" atomicity guarantee mechanism avoids the race condition of "existing at the time of query, but deleted at the time of pull".

[0061] (3) If the mirror layer corresponding to the historical composite environment fingerprint is available, then the historical composite environment fingerprint is used as the recovery target. If it is not available (for example, the mirror layer has been garbage collected), then the target composite environment fingerprint of the current task is used as the recovery target, and an alarm is triggered to notify the operation and maintenance personnel, and the abnormal circuit breaker counter of the node is incremented.

[0062] Scenario 2: Non-UNKNOWN Scenario (Different OS or Different BIOS Configuration). In this scenario, the system can normally collect the fingerprint of the current composite environment, and the decision module 23 has determined the difference dimension to be "Different OS" or "Different BIOS Configuration" through item-by-item comparison. In this scenario, the recovery target is directly determined as the target composite environment fingerprint of the current task, without the need to query historical composite environment fingerprints.

[0063] Specifically, each time the task target composite environment fingerprint is used due to a downgrade in an UNKNOWN scenario, the abnormal circuit breaker counter increments by 1. When the number of consecutive failures reaches the threshold of 3, the system automatically stops the automatic recovery of that node, marks the node as "requiring manual intervention," and freezes task issuance. This mechanism prevents the system from repeatedly attempting recovery under certain persistent environmental problems (such as corrupted image libraries, network partitions, etc.) and wasting resources in vain.

[0064] Through the above-mentioned recovery target determination mechanism, this invention prioritizes rolling back to the most recent successful historical baseline (which has been proven to be stable and usable) in the UNKNOWN anomaly scenario, and then downgrades to the task target when the historical baseline is unavailable, thereby maximizing the success rate of anomaly recovery.

[0065] Furthermore, the system image recovery operation within the out-of-band BIOS settings and system image recovery process includes: 1. Switch to the physical recovery environment.

[0066] Specifically, before execution, the out-of-band management module 22 switches the physical server from virtualization pass-through mode to physical recovery mode via BMC (suspending the virtual machine's exclusive PCIe access to the solid-state drive), and boots it into an independent recovery environment (such as a Linux rescue system or Windows WinPE) via PXE (Preboot Execution Environment). This step ensures that the recovery operation is performed in a clean, independent environment, unaffected by the target OS state.

[0067] 2. Perform a secure wipe, re-enumerate device paths, and update the mapping table.

[0068] Specifically, in the recovery environment, module 24 directly executes the `nvme format -s 1` command to perform a Secure Erase on the solid-state drive (SSD). This command thoroughly erases all user data areas of the SSD, including the partition table, file system, and all user data, restoring the SSD to its factory-fresh state. After formatting, the device path is re-enumerated using the `nvme list` command (because the device path may change after a Secure Erase), updating the system's internal device mapping table. This step ensures the purity of the subsequent recovery environment, avoiding interference from residual partition tables or cached data on test results.

[0069] 3. Retrieve the base image and differentiation layer from the image library based on the composite environment fingerprint of the target environment for recovery.

[0070] Specifically, based on the recovery target composite environment fingerprint determined in step one, the corresponding base image and differentiation layer are retrieved from the image library 12 of the central scheduling server 1: Windows environment: In WinPE or Windows Recovery Environment (WinRE), use the diskpart command to set the target system partition to an offline state, and then use the DISM (Deployment Image Servicing and Management) tool to directly merge the WIM format differential layers into the base image to complete system recovery.

[0071] In a Linux environment: Rollback is achieved through the logical volume snapshot merging function. After rollback, the target logical volume is activated. Then, the merge completion detection phase begins: the logical volume merge status is polled until the merge is complete. The overall timeout is set to 300 seconds; if the timeout occurs, an error is reported and the process exits. After confirming the merge is complete, the root file system is mounted to the / mnt directory, and then NFS storage is mounted to pull the target driver RPM or DEB package. The system package manager (such as a Debian- or Red Hat-based package management tool) is used to install the package into the system, completing the overlay of the differentiation layer.

[0072] 4. After the recovery is complete, check the 4K alignment status of the partition.

[0073] Specifically, after recovery, module 24 checks the 4K alignment of the partitions: using a partitioning tool to check the alignment of the partition's starting sector. If the alignment is correct, proceed to the next steps. If misaligned and the partition table can be safely adjusted, the partition table is backed up first, and the alignment is repaired using a file system check and adjustment tool; in Windows, the diskpart script is used to create an aligned partition, and then the image is reapplied. If the partition alignment cannot be automatically repaired or a risk is detected during the repair process, the image layer is marked as "alignment abnormal," and the system automatically reverts to the base image and re-executes the recovery operation with alignment parameters (such as the / Align parameter in DISM, or the lvcreate --align parameter in Linux). 4K alignment verification ensures that the SSD's IO performance after recovery is not affected by partition misalignment.

[0074] 5. Create a marker file in the root directory of the target system partition, and then restart to enter the target operating system.

[0075] Specifically, after all recovery and alignment operations are completed, execution module 24 mounts the target system partition and creates a flag file in its root directory. For Linux systems, this is done by mounting to / mnt and creating / mnt / run / autotest_ready.flag; for Windows systems, it is done by creating X:\autotest_ready.flag if the target partition drive letter is X:. After creation, the partition is unmounted, and the system restarts to enter the target operating system. The purpose of this flag file is to ensure that when the acquisition module 21 detects this file after the operating system starts, it immediately reports a heartbeat to the out-of-band management module 22 and deletes the file, ensuring that the system recovery can be quickly detected and confirmed as ready.

[0076] In the above process, the creation of the marker file is scheduled as the last step after Secure Erase and all recovery operations are completed. This timing design ensures that the marker file is not erased by the Secure Erase operation, thus guaranteeing the effectiveness of the marker file mechanism.

[0077] Furthermore, the image layer metadata in the image repository maintains a reference count; if and only if the current composite environment fingerprint is consistent with the target composite environment fingerprint, the historical composite environment fingerprint of the most recent successful achievement of the task objective is updated to the current composite environment fingerprint, and the reference count of the image layer corresponding to the composite environment fingerprint is incremented by 1; if there is an old historical composite environment fingerprint, its reference count is decremented by 1.

[0078] Specifically, the image repository 12 of the central scheduling server 1 stores the base image and the differentiation layer. The metadata of each image layer maintains a reference count field. The reference count indicates how many active test tasks or historical records are currently referencing that image layer. Image layers with a reference count greater than 0 are skipped during garbage collection and are not physically deleted.

[0079] Reference counts increase in the following two scenarios: (1) When the task is issued: When the central scheduling server 1 generates the target composite environment fingerprint according to the test plan and issues the task to the test agent platform 2, the reference count of the base image and the differentiation layer corresponding to the target composite environment fingerprint is incremented by 1. This ensures that the image layer required by the test task being executed will not be garbage collected.

[0080] (2) When updating historical composite environment fingerprints: The central scheduling server 1 updates the "historical composite environment fingerprint that most recently achieved the task objective" to the current composite environment fingerprint if and only if the current composite environment fingerprint is consistent with the target composite environment fingerprint (i.e., the test task has successfully achieved the objective). At the same time, if there is an old historical composite environment fingerprint, the reference count of its corresponding mirror layer is decremented by 1.

[0081] Reference counts decrease in the following scenarios: (1) When the task is completed: When the test task is completed (S6 phase), the central scheduling server 1 releases the reference count of the composite environment fingerprint of the task target (decrements by 1).

[0082] (2) When the historical composite environment fingerprint is replaced: As mentioned above, when a new historical composite environment fingerprint is generated, the reference count of the old historical composite environment fingerprint is decremented by 1.

[0083] Decision module 23 compares the current composite environment fingerprint with the task target composite environment fingerprint: If consistent (goal achieved normally): Central scheduling server 1 updates the "historical composite environment fingerprint of the most recent successful achievement of the task goal" to the current composite environment fingerprint, and increments the reference count of the mirror layer corresponding to the composite environment fingerprint by 1; if an old historical composite environment fingerprint exists, its reference count is decremented by 1; the circuit breaker counter is cleared; and the test continues.

[0084] If there is a discrepancy (e.g., rolling back to a historical environment for testing, but failing to achieve the mission objective): prohibit updating the historical composite environment fingerprint (preserve a clean baseline), report a warning "rollback to a stable baseline, mission objective not achieved", suspend testing and wait for manual confirmation.

[0085] The core value of this "conditional update" mechanism lies in the fact that the historical composite environment fingerprint always represents a clean environment that "most recently successfully achieved the mission objective." In scenarios where the operating system crashes and is rolled back to the historical composite environment fingerprint for recovery, because the current composite environment fingerprint (historical composite environment fingerprint) is inconsistent with the mission objective's composite environment fingerprint, the system prohibits updating the historical composite environment fingerprint, thus preserving the original clean baseline from contamination. This ensures the reliability of the historical composite environment fingerprint as a rollback target; it remains a verified, stable environment that has successfully achieved its mission objective.

[0086] Because the mirror layers corresponding to historical composite environment fingerprints hold reference counts, these mirror layers are not deleted even during garbage collection cycles. This ensures that in the event of an UNKNOWN anomaly, the system can always roll back to a usable historical baseline (unless the administrator manually releases the reference count or deletes the mirror). Only when a new historical composite environment fingerprint is generated and replaces the old record will the reference count of the old record be decremented by 1, at which point the old mirror layer can participate in garbage collection normally.

[0087] Through the aforementioned reference counting and historical composite environment fingerprint update management mechanism, this invention ensures both the continued availability of the historical baseline and the effective utilization of the mirror library storage space.

[0088] Furthermore, when the test task passes and the current composite environment fingerprint is different from any existing composite environment fingerprint in the image library, the central scheduling server 1 will solidify the current composite environment fingerprint into a new image layer in the image library and trigger transactional garbage collection, including: Marking phase: Mark the image layer with a reference count of zero as pending reclamation and commit the metadata transaction.

[0089] Cleanup phase: Background processes physically delete layer files marked as pending recycling.

[0090] Final stage: Remove or archive the corresponding metadata records.

[0091] Specifically, when all test tasks pass and performance meets the standards, the system checks whether the fingerprint of the current composite environment already exists in the index of image repository 12. If not, the central scheduling server 1 solidifies the current environment into a new image layer (base image + differentiation layer) in image repository 12 and updates the image index. The reference count of the new image is initially 0—that is, the newly solidified image does not automatically hold a reference count; instead, the reference count is increased as needed by subsequent test tasks or historical records. This design avoids useless images occupying storage space for a long time. After the image solidification is completed, the central scheduling server 1 triggers a transactional garbage collection process. Garbage collection adopts a three-phase transaction model of "mark-sweep-trace," ensuring that even if an interruption occurs during the collection process, the collection can continue after the system restarts, without leaving inconsistent metadata states.

[0092] Marking Phase: The garbage collection process scans the metadata of all image layers in image repository 12 and marks layers that meet the following conditions as "pending reclamation": (1) the reference count is equal to 0; (2) there are no active lease locks (i.e., no ongoing query or pull operation holds a lease lock for that layer). After marking is completed, all changes to the "pending reclamation" state are committed as a metadata transaction. This transactional commit ensures the atomicity of the marking operation—either all marking succeeds or all is rolled back, and there will be no partial marking.

[0093] Cleanup Phase: A background process iterates through all layer files marked "pending reclaiming" and performs physical deletion operations (deleting the corresponding image file, snapshot volume, or WIM file). If the system is interrupted during cleanup (such as a power outage or process crash), the garbage collection process automatically resumes scanning after the system restarts and continues deleting unfinished layer files. This design ensures that storage space is not exhausted by permanently occupied garbage layers.

[0094] Final stage: After all files in the garbage collection layer have been physically deleted, the garbage collection process completely removes the corresponding metadata records from the mirror index or archives them to the history table. At this point, the garbage collection transaction is fully completed.

[0095] When querying the availability of historical composite environment fingerprint mirror layers, the central scheduling server 1 applies a temporary lease lock (valid for 10 minutes) to the queried layer. During the lease lock's validity period, the garbage collection marking phase skips all locked layers, even if their reference count is 0, and they will not be marked as "pending reclamation". After the fetch is complete, the execution module 24 actively releases the lease lock. In addition, background threads automatically reclaim lease locks that have timed out (more than 10 minutes) to prevent garbage collection from being blocked by locks being held for a long time due to abnormal conditions.

[0096] Through the aforementioned transactional garbage collection mechanism, this invention achieves automated management of the storage space of the image library 12. While ensuring the availability of active images and historical baselines, it promptly cleans up useless image layers, effectively controlling the growth of storage space.

[0097] This invention integrates SSD firmware version, PN number, operating system version, driver version, and BIOS configuration items into a composite environment fingerprint, achieving unified modeling of hardware attributes and software environment. This allows for standardized description and precise matching of the test environment. The out-of-band management module operates independently of the host operating system, continuously monitoring the physical hardware status even during OS crashes. Combined with the decision module's rapid identification of UNKNOWN states and automatic triggering of complete image recovery, it enables unattended self-healing in extreme abnormal scenarios such as operating system crashes, significantly reducing test downtime. After environment switching, the decision module conditionally updates historical fingerprints based on fingerprint comparison results, ensuring the purity of the historical baseline and preventing rollback to the target due to abnormal environment contamination. The collaborative work of the acquisition module, out-of-band management module, decision module, and execution module automates the entire process from BIOS parameter configuration to system image recovery, eliminating the need for manual hard drive insertion / reinstallation or system reinstallation, significantly improving the efficiency and reliability of SSD R&D testing.

[0098] Figure 2 A flowchart illustrating an embodiment of the adaptive testing method for solid-state drives based on composite environment fingerprints according to the present invention is provided. This adaptive testing method for solid-state drives based on composite environment fingerprints is applied to any of the aforementioned adaptive testing systems for solid-state drives based on composite environment fingerprints. Figure 2 As shown, the method includes: Step S1: The fingerprint generation unit of the central scheduling server generates the target composite environment fingerprint according to the test plan, and the central scheduling server sends the task to the test agent platform.

[0099] Specifically, the fingerprint generation unit of the central scheduling server generates a target composite environment fingerprint according to the test plan. Specifically, the solid-state drive firmware version, PN number, operating system version, driver version, and BIOS configuration items specified in the test plan are arranged in a preset fixed order (…). , , , , After being compactly serialized in JSON format, the SHA-256 hash value is calculated as the target composite environment fingerprint. The central scheduling server distributes the task to the test agent platform, persists the progress "S1" and records the target composite environment fingerprint. The reference count of the image layer corresponding to the target composite environment fingerprint is incremented by 1 and is protected by garbage collection.

[0100] Step S2: Collect the current environment fingerprint, including: the out-of-band management module obtains the physical layer environment vector before the operating system loads; the acquisition module obtains the software layer environment vector through the system API and reports the heartbeat to the out-of-band management module; the decision module merges the physical layer environment vector and the software layer environment vector to generate the current composite environment fingerprint.

[0101] Specifically, this step is divided into three sub-steps: Step S2a (Physical Layer Anchor Point Read): After each cold boot or reboot of the physical server and before the operating system loads, the out-of-band management module reads the NVMe Identify Controller data structure through the PCIe side channel to obtain the PN and firmware version. It then reads BIOS non-volatile variables through BMC / IPMI (including three-level fallback: direct out-of-band read → BMC cached recently booted UEFI variables or POST logs → IPMI read default settings; if it still fails, it is marked). (For "DEFAULT_UNKNOWN" and alert pause), refresh in real time. = (PN, , ), with a timestamp t1 attached.

[0102] Step S2b (Software Layer Information Acquisition and Heartbeat Reporting): If the test virtual machine is running normally, the acquisition module 21 reads the solid-state drive hardware attributes through the NVMe Admin Command or SAT command, obtains the OS version and driver version through the system API, and generates... The system sends a heartbeat report to the out-of-band management module every 5 seconds, accompanied by a timestamp t2. If the flag file / run / autotest_ready.flag (Linux) or \autotest_ready.flag (Windows, root directory of the system partition) is detected, a heartbeat is immediately reported and the file is deleted.

[0103] Step S2c (Environment Vector Merging and Composite Environment Fingerprint Calculation): If the heartbeat is valid and The timestamp is valid (not marked "to be refreshed"). The decision module verifies that |t2-t1| < 120 seconds before merging them. ;like The timestamp is marked "Pending Refresh," so timestamp verification is skipped and the data is merged directly; if the heartbeat times out three times consecutively, the out-of-band management module will... and Marked as UNKNOWN. After merging, calculate SHA-256 as the current composite environment fingerprint according to the same serialization rules as the target composite environment fingerprint.

[0104] Step S3: The decision module compares the current composite environment fingerprint with the target composite environment fingerprint to determine the type of operation to be performed.

[0105] Specifically, the decision-making module employs a two-layer parsing logic: the decision layer compares the original field values ​​(firmware version, OS version, driver version, BIOS parameters) in the current composite environment fingerprint with those in the target composite environment fingerprint item by item to determine the specific dimensions of difference; the retrieval layer uses the complete composite environment fingerprint hash to retrieve data from the mirror library 12. If it is UNKNOWN, proceed directly to step S4c. Based on the difference dimension: if only the firmware is different, proceed to step S4a; if only the driver is different, proceed to step S4b; if the OS is different / BIOS is different / UNKNOWN, proceed to step S4c.

[0106] Step S4: The execution module performs the corresponding environment switching operation according to the operation type.

[0107] Specifically, this step is divided into four sub-steps: Step S4a: Firmware Flashing. The execution module calls nvme fw-download and nvme fw-commit to flash the firmware, prioritizing activation without reboot (--action=2 / 3); if a reset is required, the out-of-band management module sends a PCIe FLR / SecondaryBus Reset. After reset, device readiness polling is performed (nvme list interval 1 second, maximum 30 seconds), and the mapping table is updated if the path changes. After flashing, the firmware version is verified (three retries), and updated after successful verification. Persist "S4a_done".

[0108] Step S4b: Driver Switching. In the Windows environment, the execution module reboots to WinPE via an out-of-band management module. The driver is injected offline using DISM. In WinPE, use `bcdedit / enum` to precisely locate the boot entry (description containing "Windows", pointing to the target partition, path is winload.exe / efi), place this entry at the top, and reboot into the target system. In Linux scenarios with loadable kernel modules, compile via dynamic kernel module management mechanism → `update-initramfs -u` → modify GRUB → reboot; in scenarios with built-in kernel drivers, install the new kernel via package manager → `update-grub` → `grub-set-default` → reboot. After switching, verify the driver version and update. Persist "S4b_done".

[0109] Step S4c: Out-of-band BIOS settings and system image recovery. First, determine the target composite environment fingerprint to be restored (in UNKNOWN scenarios, prioritize reading historical composite environment fingerprints and querying availability, then apply a lease lock; in non-UNKNOWN scenarios, directly use the target composite environment fingerprint). Then, the out-of-band management module compares the current... With the goal If they are inconsistent, the out-of-band management module will set the target parameters and perform a physical restart. Marked as "Pending Refresh". Next, perform image recovery: Switch to the physical recovery environment → Execute Secure Erase → Re-enumerate device paths → Pull the base image and differential layer from image library 12 based on the target composite environment fingerprint (Windows uses DISM to merge WIM differential layers; Linux uses LVM snapshot rollback and polling to wait for the merge to complete) → Check 4K alignment status and repair → Finally, create a marker file in the root directory of the target system partition → Unmount the partition → Reboot. Persist "S4c_done".

[0110] Step S4d: Confirm environment readiness before testing. After restoring and restarting into the target OS, the out-of-band management module waits for a valid heartbeat (60 seconds, checked every 2 seconds). If a timeout occurs, it relies on the tag file mechanism. The acquisition module 21 checks the tag file upon startup and reports it immediately. If no heartbeat is received, it is determined to be an "initialization error," the alarm is paused, and the process does not proceed to S5.

[0111] Step S5: The decision module determines whether the current composite environment fingerprint is consistent with the target composite environment fingerprint. If they are consistent, the historical composite environment fingerprint is updated. If they are inconsistent, the historical composite environment fingerprint is not updated and an alarm is reported.

[0112] Specifically, the testing tools are injected to perform stress tests and collect logs. The key sequence is as follows: The decision module first compares the current composite environment fingerprint with the task target composite environment fingerprint. If they match (the goal is achieved normally), the central scheduling server updates the "most recently successfully achieved historical composite environment fingerprint" to the current composite environment fingerprint, increments the reference count of the corresponding mirror layer by 1, and decrements the reference count of any existing historical composite environment fingerprint by 1, clears the circuit breaker counter, and continues testing. If they do not match (rolling back to the historical environment), updating the historical composite environment fingerprint is prohibited, a warning is reported stating "rollback to stable baseline, task goal not achieved," and testing is paused pending manual confirmation.

[0113] Step S6: The test agent platform uploads the test results to the central dispatch server.

[0114] Specifically, the test results are uploaded to the central scheduling server. If all results pass and performance meets the standards, and the current composite environment fingerprint does not exist in the image index, then a new image is created and the index is updated. The new image's reference count is initially 0. After creation, transactional garbage collection is triggered (marking layers with a reference count of 0 and no lease locks → background physical deletion → removal or archiving of metadata). Simultaneously, the BMC is updated. and (New timestamp). Persist "S6_done" and release the reference count of the composite environment fingerprint of the task target.

[0115] Through the above complete process, this invention achieves a fully automated closed loop from task issuance, environmental fingerprint collection, differential decision-making, environment switching to test execution and garbage collection.

[0116] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A solid-state drive adaptive testing system based on composite environmental fingerprinting, characterized in that, It includes a central scheduling server and a test agent platform, wherein the test agent platform is deployed on the physical machine under test; The central scheduling server is equipped with a fingerprint generation unit, which is used to generate a target composite environment fingerprint according to the target configuration of the test task. The test agent platform includes: The acquisition module is used to obtain the hardware attributes of the solid-state drive and the software environment information of the host operating system; The out-of-band management module runs on the BMC side of the test agent platform. It is used to independently acquire and maintain the physical layer environment vector containing the solid-state drive firmware version and BIOS configuration, and to receive the heartbeat reported by the acquisition module and maintain the software layer environment vector. The decision module, which is communicatively connected to the out-of-band management module, is used to generate a current composite environment fingerprint based on the physical layer environment vector and the software layer environment vector, compare the current composite environment fingerprint with the target composite environment fingerprint to determine the type of operation to be performed, and determine whether the current composite environment fingerprint and the target composite environment fingerprint are consistent after the environment switching operation is completed. If they are consistent, the historical composite environment fingerprint is updated; if they are inconsistent, the update of the historical composite environment fingerprint is prohibited. The execution module is communicatively connected to the decision module and is used to execute the environment switching operation corresponding to the operation type.

2. The solid-state drive adaptive testing system based on composite environmental fingerprinting according to claim 1, characterized in that, The composite environment fingerprint is generated as follows: the firmware version, PN number, operating system version, driver version and BIOS configuration items of the solid-state drive are serialized in a preset fixed order, and a hash value is calculated using a hash algorithm. The hash value is then used as the composite environment fingerprint.

3. The solid-state drive adaptive testing system based on composite environmental fingerprinting according to claim 1, characterized in that, The out-of-band management module is also used to: mark the operating system version and driver version as UNKNOWN when the heartbeat timeout is detected to have reached a preset number of consecutive times; After the decision module detects the UNKNOWN state, it skips the regular difference comparison and unconditionally determines that the operation to be performed is a complete image recovery.

4. The solid-state drive adaptive testing system based on composite environmental fingerprinting according to claim 1, characterized in that, When the physical layer environment vector and the software layer environment vector are merged: If the timestamp of the software layer environment vector is a marker to be refreshed, the timestamp verification is skipped and the vector is merged directly; otherwise, the absolute difference between the timestamps of the physical layer environment vector and the software layer environment vector is checked to see if it is less than a preset threshold.

5. The solid-state drive adaptive testing system based on composite environmental fingerprinting according to claim 3, characterized in that, The environment switching operation performed by the execution module includes: Firmware flashing operation is used to perform firmware flashing when only the firmware is different; Driver switching operation, used to perform driver switching when only the drivers are different; Out-of-band BIOS settings and system image recovery operations are used to perform operations when the operating system is different, the BIOS configuration is different, or an UNKNOWN state is detected.

6. The solid-state drive adaptive testing system based on composite environmental fingerprinting according to claim 5, characterized in that, The central scheduling server also includes an image library, and the out-of-band BIOS settings and system image recovery operation includes determining the composite environment fingerprint of the recovery target, specifically including: If the reason for entering the recovery is the UNKNOWN state, the historical composite environment fingerprint is read from the persistent record as a candidate. The base image and differential layer corresponding to the candidate are checked to see if they still exist in the image library. If they exist, the candidate is used as the recovery target. If they do not exist, the target composite environment fingerprint of the current task is used as a fallback and the abnormal circuit breaker counter is incremented. If it is not an UNKNOWN scenario, the target composite environment fingerprint of the current task will be used directly.

7. The solid-state drive adaptive testing system based on composite environmental fingerprinting according to claim 6, characterized in that, The system image recovery operation in the out-of-band BIOS settings and system image recovery operation includes: Switch to physical recovery environment; Perform a secure wipe, re-enumerate device paths, and update the mapping table; Based on the fingerprint of the target composite environment, the base image and the differential layer are pulled from the image library for recovery; After the recovery is complete, check the 4K alignment status of the partition; Create a marker file in the root directory of the target system partition, then reboot into the target operating system.

8. The solid-state drive adaptive testing system based on composite environmental fingerprinting according to claim 6, characterized in that, The image layer metadata in the image library maintains a reference count; if and only if the current composite environment fingerprint is consistent with the target composite environment fingerprint, the historical composite environment fingerprint of the most recent successful achievement of the task objective is updated to the current composite environment fingerprint, and the reference count of the image layer corresponding to the composite environment fingerprint is incremented by 1; if there is an old historical composite environment fingerprint, its reference count is decremented by 1.

9. The solid-state drive adaptive testing system based on composite environmental fingerprinting according to claim 8, characterized in that, When the test task passes and the current composite environment fingerprint is different from any existing composite environment fingerprint in the image library, the central scheduling server will solidify the current composite environment fingerprint into a new image layer in the image library and trigger transactional garbage collection, including: Marking phase: Mark the image layer with a reference count of zero as a pending reclaiming state and commit the metadata transaction; Cleanup phase: Background processes physically delete layer files marked as pending recycling; Final stage: Remove or archive the corresponding metadata records.

10. An adaptive testing method for solid-state drives based on composite environmental fingerprints, characterized in that, It is applied to the solid-state drive adaptive testing system based on composite environmental fingerprints as described in any one of claims 1-9, the method comprising: The fingerprint generation unit of the central scheduling server generates the target composite environment fingerprint according to the test plan, and the central scheduling server distributes the task to the test agent platform. The current environment fingerprint is collected, including: the out-of-band management module obtains the physical layer environment vector before the operating system loads; the acquisition module obtains the software layer environment vector through the system API and reports the heartbeat to the out-of-band management module; the decision module merges the physical layer environment vector and the software layer environment vector to generate the current composite environment fingerprint; The decision module compares the current composite environment fingerprint with the target composite environment fingerprint to determine the type of operation to be performed; The execution module performs the corresponding environment switching operation according to the operation type; The decision module determines whether the current composite environment fingerprint is consistent with the target composite environment fingerprint. If they are consistent, the historical composite environment fingerprint is updated. If they are inconsistent, the update of the historical composite environment fingerprint is prohibited and an alarm is reported. The test agent platform uploads the test results to the central scheduling server.

Images