A compatibility and reliability test method for solid state disks

Abstract

The application relates to the technical field of data storage, and discloses a compatibility and reliability test method for a solid state disk, which comprises the following steps: initializing a test environment, installing an operating system, writing and executing a test script, and configuring a compiling environment; recognizing basic information of the solid state disk and classifying the solid state disk, writing an automatic script, creating file clusters of different sizes, performing continuous / random read-write tests, and checking file integrity according to the classified basic information of the solid state disk; using an Fio tool to perform performance tests on the classified basic information of the solid state disk and recording performance indexes of the solid state disk, including sequential read-write speed, random IOPS and response delay, writing an automatic script, and simulating a database load to perform small random read-write operations. The application integrates multiple modules, such as basic function and compatibility tests, performance tests, power management and reliability tests, and security characteristic tests, into a complete and automatic test scheme.

Description

Technical Field

[0001] This invention relates to the field of data storage technology, and in particular to a method for testing the compatibility and reliability of solid-state drives. Background Technology

[0002] With the rapid development of cloud computing and internet technologies, the demand for data storage is increasing daily. Solid-state drives (SSDs), as one of the mainstream storage technologies, are widely used in personal computers, servers, data centers, and other fields due to their advantages such as low cost, fast read speed, and low power consumption. SSDs offer significantly better performance and reliability than traditional hard disk drives (HDDs), making their use increasingly common across various application areas. However, as the usage and application areas of SSDs continue to expand, new requirements are being placed on their testing methods and technologies.

[0003] Currently, solid-state drive (SSD) testing methods mainly include functional testing, performance testing, and compatibility testing. However, existing testing methods are often independent and discontinuous, requiring manual switching of the operating system or preparation of the test environment, causing many inconveniences to the testing process, disrupting the integrity of the entire test, lengthening the testing time, making it difficult to comprehensively and completely test SSD performance, and the testing steps are cumbersome and time-consuming. Summary of the Invention

[0004] This invention provides a method for testing the compatibility and reliability of solid-state drives (SSDs). It addresses the technical problems of existing testing methods, which are often independent and discontinuous, requiring manual switching of the operating system or preparation of the test environment. These methods cause numerous inconveniences, disrupt the integrity of the entire test, prolong the test time, and make it difficult to comprehensively and completely test SSD performance. Furthermore, the testing steps are cumbersome and time-consuming.

[0005] To solve the above-mentioned technical problems, one technical solution adopted by the present invention is: to provide a method for testing the compatibility and reliability of a solid-state drive, the method comprising:

[0006] Initialize the test environment, install the operating system, write and execute test scripts, and configure the compilation environment;

[0007] Identify and classify the basic information of solid-state drives (SSDs), write automated scripts, and use these scripts to create file clusters of different sizes, perform sequential / random read / write tests, and verify file integrity based on the classified SSD information.

[0008] The Fio tool was used to perform performance tests on the basic information of the categorized solid-state drives and record the performance indicators of the solid-state drives, including sequential read and write speeds, random IOPS and response latency. An automated script was written to simulate database load and perform small-block random read and write operations.

[0009] High-load read / write tests combined with mixed I / O stress tests were performed on the solid-state drive. During high-load read / write operations, random power-off tests were added to check the system startup status and file system integrity.

[0010] Verify whether the encryption module of the solid-state drive complies with the security protocol standard, and verify the full-process secure boot mechanism in conjunction with the TPM chip to ensure that the solid-state drive has a complete security protection system in a multi-stress coupling environment;

[0011] The test data from each stage is summarized, analyzed, and a test report for the solid-state drive is automatically generated. The test report includes performance trend charts, stability scores, security compliance conclusions, and timelines of abnormal events for the solid-state drive under different test scenarios.

[0012] The beneficial effects of this invention are as follows: By integrating multiple modules such as basic function and compatibility testing, performance testing, power management and reliability testing, and security feature testing, a complete and automated testing solution is formed, avoiding the shortcomings of traditional testing methods that are independent and discontinuous, and improving the completeness and efficiency of testing; by adopting automated test scripts and tools, the testing process is made intelligent and automated, reducing manual operation and labor costs, while improving the accuracy and reliability of testing; by simulating real-world application scenarios, such as database load simulation and system startup speed testing, the functional compatibility, performance, and data reliability of SSDs on specified domestic IT platforms are comprehensively evaluated. In terms of power consumption, stability, and security, it meets the requirements of enterprise-level applications. Key test items such as long-term stress testing and abnormal power outage testing are introduced to examine the SSD's durability and performance stability, ensuring the accuracy of test results and providing a reliable data storage solution for enterprise applications. Through national cryptographic algorithm verification and secure erasure testing, the SSD's security performance is verified, meeting the standards of the State Cryptography Administration and improving data security levels. The provided testing scheme has good scalability and adaptability, allowing for flexible adjustments to test content and processes according to actual needs. It is applicable to different types of solid-state drives and domestic IT innovation platforms, possessing strong practicality and promotional value. Attached Figure Description

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

[0014] Figure 2 yes Figure 1 A flowchart illustrating step 1.

[0015] Figure 3 yes Figure 1 A flowchart illustrating step 2.

[0016] Figure 4 yes Figure 1 A flowchart illustrating step 3.

[0017] Figure 5 yes Figure 1 A flowchart illustrating step 4.

[0018] Figure 6 yes Figure 1 A flowchart of step 5 in the middle.

[0019] Figure 7 yes Figure 1 A flowchart illustrating step 6. Detailed Implementation

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

[0021] The terms "comprising" and "having," and any variations thereof, used in this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

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

[0023] Figure 1 This is a flowchart illustrating the compatibility and reliability testing method for a solid-state drive according to the first embodiment of the present invention. Figure 1 As shown, the system includes hardware and software components:

[0024] Step 1: Initialize the test environment, install the operating system, write and execute test scripts, and configure the compilation environment;

[0025] Step 2: Identify and classify the basic information of the solid-state drives (SSDs), write an automated script, and use the automated script to create file clusters of different sizes, perform sequential / random read / write tests, and verify file integrity based on the classified SSD information.

[0026] Step 3: Use the Fio tool to perform performance tests on the basic information of the categorized solid-state drives and record the performance indicators of the solid-state drives, including sequential read and write speeds, random IOPS and response latency. Write automated scripts to simulate database load and perform small-block random read and write operations.

[0027] Step 4: Perform high-load read / write tests on the solid-state drive, combined with mixed IO stress tests. During high-load read / write operations, randomly add power-off tests to check the system startup status and file system integrity.

[0028] Step 5: Verify whether the encryption module of the solid-state drive complies with the security protocol standard, and verify the full-process secure boot mechanism in conjunction with the TPM chip to ensure that the solid-state drive has a complete security protection system in a multi-stress coupling environment.

[0029] Step 6: Summarize the test data from each stage, analyze the test data from each stage, and automatically generate a test report for the solid-state drive. The test report includes performance trend charts, stability scores, security compliance conclusions, and timelines of abnormal events for the solid-state drive under different test scenarios.

[0030] This embodiment covers six major stages: environment initialization, information classification, performance testing, high-load verification, security and compliance testing, and report generation, ensuring that the test results are accurate and reproducible, and providing a basis for hard drive quality assessment.

[0031] The test environment was initialized, and the operating system was selected as CentOS 7.9 or Ubuntu 20.04 LTS, using a minimal installation mode. The partitioning was planned as follows: / boot partition 2GB (ext4 format), swap partition size twice the RAM (maximum 32GB), / partition using the remaining space (ext4 format). After installation, firewalls, SELinux, and other interfering services were disabled. The kernel version was verified using system commands to ensure support for NVMe protocol, TRIM, and other advanced SSD features.

[0032] Write an environment initialization script in Python. This script should automatically install dependencies such as gcc, make, and python3-pip, configure SSH remote access permissions, and synchronize the system time to an NTP server. After executing the script, verify that all dependencies are installed successfully using system package management commands. Install the gcc, gcc-c++, make, and cmake build toolchains, and confirm that the gcc version is at least 4.8.5 using version checking commands. Add the build environment variable (setting the CFLAGS parameter to "-O2 -m64") to the system's global configuration file, and execute the activation command to make the configuration immediately effective in the current environment.

[0033] In the basic information identification and processing of solid-state drives (SSDs), key information about the hard drive is obtained through system commands: the `lsblk` command is used to view the device name (e.g., ` / dev / nvme0n1`) and capacity; the `smartctl` command is used to view the hard drive model, interface type (SATA or NVMe), and firmware version; for NVMe hard drives, the `nvme id-ctrl` command is used, and for SATA hard drives, the `hdparm` command is used to obtain the sector size and supported IO queue depth.

[0034] The classification rules are divided into three dimensions: interface type (SATA / NVMe), capacity (≤512GB, 512GB-2TB, >2TB), and sector size (512B / 4KB), ultimately generating a classification record containing "device name, interface, capacity, sector size, and firmware version".

[0035] Write a Python script to automate the process: automatically call the above information retrieval command, parse the command output, classify the hard drives according to preset classification rules, and finally generate a CSV format classification file (filename: ssd_classification.csv). The core logic of the script is to retrieve data by calling the module through system commands and then use data processing tools to generate a structured file.

[0036] File cluster creation and integrity verification: Create corresponding file clusters based on the sector size classification results: For a 4KB sector hard disk, use the dd command to create a file cluster of 10,000 data blocks (total capacity 40MB) in 4KB units; for a 512B sector hard disk, create a file cluster of 80,000 data blocks (total capacity 40MB) in 512B units.

[0037] Perform sequential and random read / write operations: Use the dd command to perform sequential writes (specify 4KB block size, skip the first 1000 block positions to write), and use the Fio tool to perform random reads (specify 4KB block size, read 40MB file clusters).

[0038] Integrity verification is achieved using the md5sum command: first, the original checksum value of the file cluster is generated and saved; after read and write operations, the checksum value is recalculated; and the two results are compared to ensure that the file is not corrupted.

[0039] In performance testing and load simulation, the Fio tool must be installed first (using the yum command on CentOS and the apt command on Ubuntu), ensuring the version is at least 3.1. For different types of hard drives, four types of performance test cases are executed, each repeated three times and the average value is taken: Sequential read test: block size 128K, queue depth 32, test file size 100GB, continuous execution for 300 seconds, log results output; Sequential write test: parameters are the same as sequential read, only the read / write mode is changed to write, also log output; Random read test: block size 4K, queue depth 16, test file size 50GB, continuous execution for 300 seconds, log output; Random write test: parameters are the same as random read, read / write mode is changed to write, log output.

[0040] Extract key performance metrics from each test log: sequential read / write speed (MB / s), random IOPS, and response latency (ms), and record them in an Excel-formatted performance test file.

[0041] Write a Python script to simulate a typical small-block random read / write scenario in a MySQL database—70% read, 30% write, 4KB block size, 200GB test file size, running continuously for 600 seconds (10 minutes), and outputting log results. After executing the script, extract the IOPS and latency metrics from the logs and compare them with the results of a basic random read / write test to analyze the impact of database load on disk performance.

[0042] In high-load and power-off testing, the high-load read / write test used the Fio tool to simulate a multi-threaded high-load scenario: 8 test threads were started, block size 4K, queue depth 64, test file size 500GB, and the test ran continuously for 1800 seconds (30 minutes), with logs recording the results. During the test, the `top` command was used to monitor CPU utilization (must reach above 80%), and the `iostat` command (refreshed every second) was used to monitor disk I / O utilization (must reach above 90%), ensuring the system was under high load. The monitoring data was recorded to a text file.

[0043] Configure mixed IO parameters using the Fio tool: 50% read and 50% write, block size randomly varying between 4K and 64K, queue depth 32, test file size 300GB, run continuously for 1200 seconds (20 minutes), and output log results to test the hard drive's performance stability in scenarios with non-fixed block sizes.

[0044] The hardware includes a programmable power controller (such as the Keysight N6705B) connected to the test host via a serial port for remote power-off control. The test process consists of three steps: First, during high-load or mixed I / O testing, a Python script randomly triggers power outages (intervals between 30 and 300 seconds, executed 10 times). Second, after each power outage, the system is restarted, and the boot process is observed and recorded, noting the boot time and any boot failures. Third, after system startup, the hard drive partitions are unmounted, and the file system integrity is checked using the fsck command, recording any bad blocks, inode errors, or other issues. Finally, a power-off test report text file is generated.

[0045] In the security compliance verification, the encryption module verification uses AES-256-XTS as the target encryption protocol (referencing the NIST SP800-38E specification) and is performed in three steps: First, enable the hard drive encryption function—NVMe hard drives are configured with encryption features via the nvme command, and SATA hard drives are configured with a security password via the hdparm command; Second, perform the Fio sequential read / write test (with parameters consistent with the sequential read / write test in step 3.1), and compare the performance difference before and after encryption is enabled, requiring a performance loss of no more than 10%; Third, use a dedicated command (NVMe hard drives use the nvme id-ctrl command with specified encryption parameters, and SATA hard drives use the corresponding query command) to check whether the encryption algorithm is AES-256-XTS, confirm compliance with the standard, and record the verification in the encryption verification text file.

[0046] TPM chip and secure boot verification require confirming the test host is equipped with a TPM2.0 chip, enabling the TPM function in the BIOS, and verifying the TPM driver loading correctly by checking the system logs. The full-process secure boot verification consists of three steps: First, generate and store the encryption key in the TPM—first create a TPM master key, then create an encryption key based on the master key, and set key access permissions (fixed association with TPM, fixed parent key, restricted read access); Second, encrypt and store the SSD encryption key using the TPM, ensuring only systems verified by the TPM can decrypt the hard drive; Third, test under multi-stress coupling environments—combining high-load scenarios (parameters consistent with step 4.1) and high / low temperature environments (temperature range -10℃~60℃, controlled by an environmental chamber), repeatedly execute the secure boot process to verify whether the system can decrypt and boot normally, ensuring the security protection system is functioning correctly, and record the results in the TPM security report text file.

[0047] During the test data aggregation and report generation process, the first step is to collect test data from each stage, including environment initialization logs, SSD classification files, performance test files, high-load and power-off test reports, and security verification reports, all of which are stored in a designated directory (directory name: ssd_test_data). The performance test data is then cleaned using Python data processing libraries to remove outliers (such as data showing a sudden performance drop due to power outages), calculate the data mean and standard deviation, and generate standardized data records.

[0048] Performance trend analysis: Use Python plotting libraries to generate performance trend charts, including sequential read / write speed change curves, random IOPS fluctuation graphs, and response latency distribution histograms under different test scenarios, to analyze the performance changes over time or load.

[0049] Stability rating: A rating standard with a maximum score of 100 points is established - 30 points for no power outage failure, 20 points for no file system corruption, 20 points for performance fluctuation not exceeding 15%, and 30 points for safe boot without failure. The final stability rating is calculated based on the test results.

[0050] Security compliance conclusion: Based on the verification of the encryption module and the results of TPM secure boot, determine whether the hard drive complies with the AES-256-XTS encryption standard and the TPM 2.0 specification, and clearly give a conclusion of "compliant" or "non-compliant" and the specific reasons.

[0051] Abnormal Event Timeline: Records all abnormal events in chronological order (such as startup failure after power failure, file system error, encryption / decryption failure), including the time of occurrence, the test scenario, the handling method, and the result.

[0052] A Python script was written to generate a PDF test report, which is then used to create a PDF version of the report. The report structure includes six parts: 1) Test Overview (explaining the test purpose, scope, and environment); 2) Test Steps and Process (detailing the operations at each stage); 3) Test Results (presenting data records, trend charts, and stability scores); 4) Security and Compliance Conclusions; 5) Timeline of Abnormal Events; and 6) Improvement Suggestions (proposing optimization directions for performance bottlenecks and security risks). After executing the script, the final test report (filename: ssd_test_report.pdf) is generated.

[0053] Figure 2 yes Figure 1 The flowchart for step 1 is as follows: Figure 2 As shown, step 1 includes: step 101, installing at least two operating systems, deploying the script execution environment, and configuring performance testing tools on the target domestic IT innovation platform;

[0054] Step 102: Record the SSD identification, partitioning process, and driver loading during the installation process; Step 103: Add an interface for reading extended information from the SSD's internal SMART log, and an interface for triggering firmware-specific debug modes, to the existing driver interface for the SSD; Step 104: Write and execute test scripts and configure the compilation environment.

[0055] Step 101: Installation and Environment Deployment of the Domestic IT Innovation Platform System: For the target domestic IT innovation platform, select a common architecture (such as Phytium FT-2000+ / 64, Kunpeng 920), and install at least two domestic IT innovation operating systems: Galaxy Kylin Advanced Server Operating System V10 (Phytium / Kunpeng Edition): Use a minimal installation mode, with partitioning based on domestic IT innovation specifications— / boot partition 2GB (ext4 format, supports UEFI boot), swap partition twice the memory size (maximum 32GB), / partition remaining space (ext4 format), and check the "Install Domestic IT Innovation Driver Adaptation Package" option; openEuler 22.03 LTS (Domestic IT Innovation Edition): During installation, select "Server Basic Environment," with the partitioning scheme consistent with Galaxy Kylin, and install domestic IT innovation hardware adaptation components (such as Kunpeng chip drivers and NVMe hard drive domestic IT innovation drivers) through "Additional Software."

[0056] After installation, verify the architecture (e.g., "aarch64") using `uname -m` and confirm the system version using `cat / etc / os-release` to ensure compatibility with the current IT innovation platform hardware.

[0057] Script runtime environment deployment: Deploying a Python script runtime environment for the domestic IT innovation architecture (aarch64):

[0058] Galaxy Kylin System: Install Python 3.9 through the system's built-in "Domestic Software Innovation Source" (command: yum install -y python3.9 python3.9-pip) to avoid architecture incompatibility caused by using non-domestic software innovation sources;

[0059] OpenEuler system: Enable the Euler software repository (dnf config-manager--enableopenEuler-22.03-LTS-SP1-os-aarch64), then execute dnf install-y python3.9 python3-pip.

[0060] After installation, verify the version using python3 --version, and install the script's dependencies using pip3 install pandas fio-python (ensure that the dependencies are for the aarch64 architecture).

[0061] For the domestic IT innovation compatibility performance testing tool configuration, select performance testing tools adapted to the domestic IT innovation platform to avoid tool architecture incompatibility: Fio (domestic IT innovation version): Obtain from the domestic IT innovation software repository (using `yum install -y fio-aarch64` for Galaxy Kylin, and `dnf install -y fio` for openEuler), version ≥ 3.28 (supports domestic IT innovation hard drive driver interfaces); Auxiliary monitoring tools: Install the domestic IT innovation version of iostat (`yum install -y sysstat-aarch64`) and top (system comes with a domestic IT innovation adapted version) to ensure monitoring of CPU and IO resource usage on the domestic IT innovation platform. After installation, verify compatibility using `fio --version` and `iostat -V` to confirm no "architecture not supported" errors.

[0062] Step 102: Record information during the installation process of the domestic IT platform. During the system installation process, the following should be recorded: Device identification results: On the "Disk Selection" interface, check whether the solid-state drive device name (e.g., / dev / nvme0n1), interface type (SATA / NVMe), and capacity are correctly identified, and whether "Unknown disk" or "Capacity identification error" prompts appear; Identification tool feedback: If the system's built-in disk tool (e.g., Galaxy Kylin "Disk Management") can identify the drive, record the hard drive model and firmware version displayed by the tool; if identification fails, record the failure prompt (e.g., "Missing NVMe domestic IT driver") and the solution (e.g., manually loading the driver package).

[0063] During partitioning operations, record: Partitioning tool compatibility: Whether the partitioning tool included with the domestically developed system (such as Anaconda Partitioner) supports solid-state drive partitioning, whether it can create ext4 format partitions normally, and whether "partition table error" or "partition size exceeds limit" issues occur; Partitioning progress and time consumption: Record the total number of partitions, the creation time of each partition (e.g., " / partition 500GB creation time 2 minutes 15 seconds"), whether there are partitioning interruptions or retries, and the error messages when interrupted (e.g., "IO timeout").

[0064] After system installation and startup, record the following: Automatic loading results: Check the installation log (e.g., / var / log / anaconda / journal.log) to see if the SSD driver is automatically loaded, the driver version (e.g., "nvme-aarch64-driverv5.10.0"), and whether there are "driver mismatch" or "loading failure" logs; Manual loading results: If automatic loading fails, record the manual loading steps (e.g., loading via the modprobe nvme command), the loading result (success / failure), and the verification method (lsmod / grep nvme to check the driver module) to ensure that the hard drive can be accessed normally after the driver is loaded.

[0065] Step 103: SSD driver interface expansion. Based on existing driver interfaces (such as NVMe standard interface and SATA standard interface), a new SMART log extended information reading interface is added. This expansion is achieved through the following methods: Based on domestically developed drivers: If using the domestically developed driver source code provided by the manufacturer, add a "SMART extended information reading" function to the driver—add a dedicated command (such as adding the "0x1F" command for NVMe drives) to support reading extended SMART parameters (such as SSD erase count, NAND flash health status, and cache error count); If no driver modification is needed, implement this through an extended domestically developed version of the smartctl tool—obtain a smartctl tool (version ≥ 7.3 domestically developed version) that supports extended information from the domestically developed software repository, and read the extended log using smartctl -x / dev / nvme0n1 (adding the "-x" parameter) to ensure that extended information such as "erasure count: 12 times" and "remaining lifespan: 98%" can be obtained, verifying that the interface can return data normally.

[0066] To pinpoint firmware issues, a new debug mode trigger interface has been added: Driver-level interface: A "Debug Mode Trigger" interface has been added to the SSD's domestically developed driver. Trigger commands (such as passing the "0x02" debug flag to the driver) are sent via system calls (e.g., ioctl commands) to trigger the firmware into debug mode (e.g., pausing background garbage collection, enabling detailed log output). Tool-level trigger: If the driver supports this, a simple trigger script (based on Python calling ioctl) can be written, or a domestically developed debugging tool provided by the manufacturer (e.g., "SSD Debug Tool-aarch64") can be used. The tool can be used to select the "Debug Mode" option and record the trigger results (e.g., "Firmware has entered debug mode, log output to / var / log / ssd_debug.log"), ensuring that the interface can stably trigger debug mode without affecting the hard drive's basic functions.

[0067] Step 104: Writing and compiling test scripts for the domestic IT innovation platform. Write an adaptation script for the domestic IT innovation platform architecture (aarch64): Script functions: Focusing on the needs of the domestic IT innovation scenario, write a script (e.g., "ssd_info_collect.py") with functions including automatically collecting hard drive identification information (calling lsblk, smartctl -x), recording driver loading status (calling lsmod), and generating a domestic IT innovation platform-specific information report (including architecture, system version, and driver version); Execution verification: After writing the script, execute it on both domestic IT innovation systems (python3 ssd_info_collect.py), record the execution results (whether there are errors, whether the report is complete). If an error occurs (e.g., "aarch64 architecture does not support a certain function"), modify the script adaptation (e.g., replace compatible functions) to ensure the script runs stably on the domestic IT innovation platform.

[0068] Configure a compilation environment adapted to the domestic IT architecture: Install the domestic IT compilation toolchain: On the Galaxy Kylin system, install via `yum install -y gcc-aarch64 g++-aarch64 make-aarch64 cmake-aarch64` (toolchain version requires gcc ≥ 8.3.0, adapted for Phytium / Kunpeng); on the openEuler system, install via `dnf install -y gcc g++make cmake` (default provides aarch64 version); Configure environment variables: Add the domestic IT compilation variables to ` / etc / profile`—`export CC=gcc-aarch64` (specifying the aarch64 compiler), `export CXX=g++-aarch64`, `export CFLAGS="-O2 -march=armv8-a"` (adapting to the domestic IT CPU architecture), and execute `source / etc / profile` to take effect; Verification: Check the architecture using `gcc -v` (displays "Target: aarch64-redhat-linux-gnu"), and compile a simple C program (e.g., `gcc test.c -o`). (test), executing . / test yielded no errors, confirming that the compilation environment is compatible with the domestic IT innovation platform.

[0069] After the preparation for the domestic IT innovation project is completed, perform the general environment configuration of the original step 1, and supplement the domestic IT innovation adaptation adjustments:

[0070] Operating System Installation: If a general environment is required, install CentOS / Ubuntu according to the original steps (ensure compatibility with the domestic IT innovation platform architecture, such as the aarch64 version of CentOS); Script and Compilation Environment: If the general environment and the domestic IT innovation environment are shared, ensure that the script is compatible with multiple architectures (use if-else statements to determine the architecture and execute the corresponding command), and that the compilation tools support cross-architecture compilation (e.g., compiling the domestic IT innovation version program using gcc-target aarch64). Subsequent SSD basic information processing, performance testing, high-load verification, security compliance testing, and report generation will be performed according to the original steps, with the addition of verification points for domestic IT innovation scenarios: Performance Testing: Compare the hard drive performance under domestic IT innovation systems and general systems (e.g., the difference in sequential read / write speeds between Kylin and CentOS); Security Verification: Confirm the compatibility of the TPM chip on the domestic IT innovation platform (e.g., whether the domestic IT innovation TPM 2.0 chip on the Phytium platform supports key storage);

[0071] Report generation: A new section titled "Compatibility Conclusions of Domestic IT Platforms" has been added, explaining the hard drive's identification, performance, and security characteristics in domestic IT systems.

[0072] Figure 3 yes Figure 1 The flowchart for step 2 is as follows: Figure 3 As shown, step 2 includes:

[0073] Step 201: Use the commands lspci, lsblk, or fdisk -l to confirm the recognition of the solid-state drive (SSD); Step 202: Use graphical disk tools and command-line tools to create partition table formats including MBR and GPT; Step 203: Create file systems including ext4, xfs, and the domestic Taiji file system in at least two operating system environments; Step 204: Write an automated script to complete the creation of file clusters of different sizes, sequential / random read / write tests, and file integrity verification based on the basic information of the categorized SSDs.

[0074] Step 203: Create ext4, xfs, and Taiji file systems respectively in the Kylin and UnionTech UOS dual-system environments to ensure file system compatibility and formatting efficiency;

[0075] Step 204: Use the dd command to write specific data patterns to verify the initial write performance and bad block isolation capability of the solid-state drive under each file system;

[0076] Step 205: Record the mounting stability and metadata consistency under different combinations of partition tables and file systems.

[0077] Based on the domestically developed system environment, the hard drive recognition status is accurately confirmed by specifying a command-line tool, supplementing the basic record of step 102. The operation is as follows: The lspci command is used to verify controller recognition. Execute lspci|grep -i "storage\|nvme\|sata" to check whether the solid-state drive controller is recognized: NVMe hard drive: If the output is "Non-Volatile memory controller: xxx" (such as "KIOXIA Corporation NVMe SSD Controller"), it means that the NVMe controller is recognized normally; SATA hard drive: If the output is "SATA controller: xxx" (such as "Intel Corporation SATAController"), it means that the SATA controller is recognized normally; Record abnormal situations: If there is no corresponding output, check the power supply of the PCIe slot of the domestically developed motherboard and the controller driver (using lsmod|grep nvme or sata). If the driver is not loaded, execute modprobenvme (NVMe) or modprobe ahci (SATA) to reload it.

[0078] The `lsblk` command verifies device and capacity identification. Execute `lsblk -o NAME,SIZE,TYPE,MOUNTPOINT`, and pay close attention to: Device Name: Confirm the solid-state drive device name (e.g., / dev / nvme0n1, / dev / sda) to avoid confusion with other storage devices; Capacity: Compare the hard drive's nominal capacity (e.g., 1TB) with the capacity displayed in the command (e.g., 931.5G, which is normal due to differences in the number system). If the capacity display is abnormal (e.g., only 200MB is identified), check if the driver is compatible with the hard drive capacity (a domestically developed driver must support large-capacity hard drives); Type: Confirm that the "TYPE" column is "disk" (indicating a block device), not "part" (partition), to ensure that the entire hard drive is identified.

[0079] The `fdisk -l` command verifies partition and sector information. Execute `fdisk -l / dev / nvme0n1` (replace with the actual device name) and check the following: Sector size: Record "Units: sectors of 1 × 512 = 512 bytes" or "4096 bytes", confirming the sector size matches the record in step 102; Partition table type: If no partition has been created, it displays "Disk labeltype: dos" (MBR) or "gpt" (GPT). If it displays "no valid partition table", the partition table needs to be created later; Partition status: If partitions already exist, record the number of partitions and the start / end sectors of each partition, confirming there are no "invalid partition" errors. Finally, a "Hard Disk Identification Confirmation Report" is generated, containing a summary of the output of the three commands, the identification result (normal / abnormal), and the handling measures for the abnormality.

[0080] Step 202: MBR and GPT Partition Table Creation (Graphical + Command Line) In the two domestically developed operating systems (Kylin and openEuler), MBR and GPT partition tables are created using both graphical and command-line tools to ensure compatibility with different domestically developed operating system requirements.

[0081] Graphical disk utility operation (suitable for visual configuration): In the Kylin system: Open the "Disk Management" tool (desktop menu → System Tools → Disk Management), select the solid-state drive (e.g., / dev / nvme0n1), and click "Format Disk": Create an MBR partition table: In "Partition Table Type," select "Master Boot Record (MBR)," click "OK," and wait for the operation to complete (applicable to ≤2TB hard drives); Create a GPT partition table: Select "GUID Partition Table (GPT)," and click "OK" (supports >2TB hard drives and is compatible with UEFI boot); In the openEuler system: Install and open the "GNOME Disk" tool (dnf install -y gnome-disk-utility), select the hard drive, and click "Settings" in the upper right corner → "Format Disk." Select the same partition table type as in Kylin, and click "Apply" to take effect.

[0082] Record the results of the graphical tool operation: whether errors such as "insufficient permissions" (requires switching to root user) or "disk busy" (requires unmounting the mounted partition) occur, and the solutions (such as umount / dev / nvme0n1p1 to unmount the partition). Command-line tool operations (suitable for automation and server scenarios): Creating an MBR partition table using fdisk: Execute `fdisk / dev / nvme0n1`, type "o" (create a new DOS partition table, i.e., MBR), type "w" to save and exit, execute `partprobe / dev / nvme0n1` to refresh the partition table, and confirm "Disk label type: dos" using `fdisk -l`; Creating a GPT partition table using parted: Execute `parted / dev / nvme0n1`, type "mklabel gpt" (create a GPT partition table), type "quit" to exit, execute `partprobe / dev / nvme0n1`, and confirm "Partition Table: gpt" using `parted -l / dev / nvme0n1`; Notes: Under domestically developed systems, fdisk supports MBR by default, and parted needs to be version 3.2 or higher (verified by `parted -v`) to avoid lower versions not supporting large GPT partitions; Back up hard drive data before creating the partition table to avoid data deletion.

[0083] Partition table verification: After the two tools are completed, execute lsblk (check if the "TYPE" column displays "disk" and there are no errors) and blkid (check if the hard drive has generated a UUID; the UUID format is different for MBR / GPT partition tables) in Kylin and openEuler respectively to ensure that the partition table is created successfully and can be recognized normally in the domestic IT system.

[0084] Step 203: Multi-type file system creation (domestic innovation + general), based on the partition table created in step 202, ext4, xfs, and the domestic Taiji file system are created for MBR / GPT partitions in Kylin and openEuler systems respectively, ensuring coverage of commonly used file system types for domestic innovation:

[0085] Preparation before file system creation: In both domestic and international IT systems, first create a test partition (based on GPT partitioning example): Execute `parted / dev / nvme0n1`, enter `mkpart primary 1GB 201GB` (create a 200GB primary partition, device name / dev / nvme0n1p1), enter `quit`, and execute `partprobe` to refresh; ensure the partition status is normal (lsblk shows / dev / nvme0n1p1 as "part"), and there are no "unallocated" errors.

[0086] Creating general file systems (ext4, xfs): ext4 file system: In Kylin / openEuler, execute `mkfs.ext4 / dev / nvme0n1p1`, set the file system label (optional: `-L ext4_test`), wait for formatting to complete (displaying "done"), and confirm "TYPE="ext4"" using `blkid / dev / nvme0n1p1`; xfs file system: First install the xfs tool (Kylin: `yum install -y xfsprogs`; openEuler: `dnf install -y xfsprogs`), execute `mkfs.xfs / dev / nvme0n1p1` (overwriting the original ext4, confirming no data is present), and confirm "TYPE="xfs"" using `blkid`; Record creation time: For example, creating a 200GB ext4 takes approximately 1 minute and 30 seconds, while xfs takes approximately 1 minute and 10 seconds, comparing the efficiency differences between the two domestically developed systems.

[0087] Creating the domestic Taiji file system (dedicated to IT innovation): Tool installation: The Taiji file system requires a dedicated IT innovation tool package. For Galaxy Kylin, execute `yum install -y taiji-fs-utils` through the "IT innovation software source"; for openEuler, add the Taiji file system repository (`dnf config-manager --add-repo https: / / xxx / taiji.repo`), then execute `dnf install -y taiji-fs-utils`; Creation operation: Execute `mkfs.taiji / dev / nvme0n1p1`, set the label (`-Ltaiji_test`), wait for completion (displaying "Taiji filesystem created successfully"), and confirm "TYPE="taiji"" using `blkid`; Mounting and verification: Create the mount point (`mkdir / mnt / taiji`), execute `mount / dev / nvme0n1p1 / mnt / taiji`, and verify using `df`. Use the command `-h / mnt / taiji` to check the mounted capacity (it should be close to 200GB). Create a test file (`touch / mnt / taiji / test.txt`), confirm that the file can be read and written normally, and verify the compatibility of the Taiji file system in the domestic IT innovation system.

[0088] Cross-system file system recognition verification: The ext4 / xfs / Taiji partition created in Kylin was mounted to the openEuler system (mount / dev / nvme0n1p1 / mnt / cross-test). By viewing the files using ls / mnt / cross-test, it was confirmed that the file systems of different domestic innovation systems can be recognized normally, and there are no "unknown filesystem type" errors.

[0089] Step 204: Automated script for file cluster creation and read / write verification (for domestic IT innovation adaptation). Based on the domestic IT innovation compilation environment of Step 104, an automated script is written to realize the reading of basic information of the solid-state drive, the creation of file clusters of different sizes, continuous / random read / write, and integrity verification, adapting to the aarch64 architecture. Script core functional module design: The script is named "ssd_file_cluster_auto.py", focusing on domestic IT innovation scenario adaptation, and includes three main modules: Basic information reading module: calls lsblk (to get device name and capacity), blkid (to get file system type), and smartctl-x (to get SMART extended information). Automatically categorizes hard drives (by interface, capacity, and file system type) and generates a categorization dictionary; File cluster creation module: Based on the categorization results, creates multiple file cluster sizes for different file systems (ext4 / xfs / Taiji) and sector sizes (512B / 4KB): Small file cluster: 4KB×10000 (40MB, adapted to the smallest block size of the Taiji file system); Medium file cluster: 64KB×10000 (625MB, adapted to xfs journal blocks); Large file cluster: 128KB×10000 (1.22GB, adapted to ext4 large file storage); Implemented by calling the dd command through the subprocess module (e.g., creating a 4KB small file cluster: dd if= / dev / zero of= / mnt / test / 4k_cluster.bin bs=4Kcount=10000).

[0090] Read / Write and Verification Module: Continuous Read / Write: Calls dd to perform continuous write (dd if=4k_cluster.bin of= / dev / nvme0n1p1 bs=4K seek=100) and continuous read (dd if= / dev / nvme0n1p1 of=read_back.bin bs=4K count=10000); Random Read / Write: Calls the domestically developed version of Fio (fio --name=rand_rw --filename= / mnt / test / 64k_cluster.bin --rw=randrw --bs=64K --size=625MB); Integrity Verification: Calculates the file cluster MD5 value using the hashlib library (generates the original MD5 before reading / writing and recalculates it after reading / writing), compares the two values ​​to see if they match, and if they do not match, records "file corrupted" and the corresponding file cluster specification and file system type.

[0091] Script Execution and Verification (Adaptation to Domestic IT Systems): Permission Configuration: Due to the involvement of hard disk read / write, the script requires root privileges to execute (sudo python3 ssd_file_cluster_auto.py); Cross-System Execution: Run the script on both Kylin and openEuler, and record: Execution Time: For example, the total time taken to create three types of file clusters (approximately 3 minutes and 20 seconds on Kylin and approximately 3 minutes and 5 seconds on openEuler); Error Handling: If the Taiji file system reports a "Permission denied" error when creating a file cluster, check the Taiji partition mount parameters in / etc / fstab ("defaults" needs to be added); If random read / write is slow, check the domestic IT system's IO scheduler (execute cat / sys / block / nvme0n1 / queue / scheduler and switch to "mq-deadline" for optimization); Result Output: The script generates "file_cluster_report.txt", which includes classification information, a list of file cluster creations, read / write speeds (calculated by outputting "bytes copied, xxx s, xxx MB / s" via dd), and verification results, ensuring traceability at each stage.

[0092] Step 205: Record the mounting stability and metadata consistency of the partition table and file system combination. For all combinations formed in steps 202-203 (MBR+ext4, MBR+xfs, MBR+Taiji, GPT+ext4, GPT+xfs, GPT+Taiji), continuously monitor the mount status and metadata integrity in two domestic IT innovation systems (Kylin and openEuler). The operation is as follows: Mount stability monitoring design, monitoring period: 72 consecutive hours (covering the typical business cycle of domestic IT innovation servers), perform a mount status check once per hour; check command: execute mount | grep / dev / nvme0n1pX (X is the partition number) to confirm whether the partition is continuously mounted (without accidental unmounting), execute df -h / mnt / test to confirm that the mount point capacity is displayed normally (no "capacity is 0" or "read-only file system" abnormalities); abnormal record: if mount loss occurs (mount command has no output) or read-only status occurs (mount displays "ro" mark), record the time of occurrence and the combination (e.g., "GPT"). +Tai Chi, Galaxy Qilin System, 36th hour”, system log (dmesg |grep / dev / nvme0n1pX extracts error messages, such as “ext4-fs error: I / O error”).

[0093] Metadata (such as inodes, directory structure, and permission information) is the core of the file system. Consistency is verified through the following steps: Initial metadata snapshot: After mounting each partition combination, execute `ls -liR / mnt / test>initial_metadata.txt` (recording the inode number, permissions, and directory structure of all files), and execute `stat / mnt / test` to record file system metadata (block size, total number of inodes); Metadata comparison after stress read / write: After executing the file cluster read / write script in step 204 (continuous 24-hour random read / write), execute `ls -liR / mnt / test>post_metadata.txt` again. Compare the differences between `diffinitial_metadata.txt` and `post_metadata.txt`, focusing on: whether the inode number has changed (it should remain unchanged normally); whether the directory structure is complete (no new / missing directory entries); whether the file permissions are consistent with the initial values ​​(e.g., not accidentally modified to "000"); File system check tool verification: After unmounting the partition, execute the dedicated check command (e2fsck -f for ext4, xfs_repair -n for xfs, and taiji_fsck for Taiji file system). -v), records whether there are metadata errors such as "inode link count error", "directory entry corruption", "superblock check failure" or "inode link count error".

[0094] Summarize 72 hours of monitoring data and analyze it by the dimension of "partition table type - file system - domestically developed system": Mount stability: Calculate the "percentage of fault-free mount time" for each combination (e.g., GPT+ext4 is 100% on the Kylin system, MBR+Taiji is 98% on the openEuler system, due to a brief unmount at the 45th hour); Metadata consistency: Count the "number of metadata errors" for each combination (e.g., GPT+xfs has no errors, MBR+Taiji has one minor directory entry error, which can be repaired using taiji_fsck).

[0095] Generate a "Partition Table and File System Combination Stability Report" which clearly recommends combinations (e.g., "GPT+ext4 performs best in both domestic IT systems, with no mount anomalies for 72 hours and zero metadata errors") and requires optimization (e.g., "MBR+Taiji requires upgrading the Taiji driver of the openEuler system to v2.2.1").

[0096] Figure 4 yes Figure 1 The flowchart for step 3 is as follows: Figure 4As shown, step 3 includes: Step 301: Use the Fio tool to perform performance tests on the categorized solid-state drives, setting block sizes to 4KB, 64KB, and 1MB, and queue depths to 1, 2, 4, 8, and 16 respectively, performing random read / write and sequential read / write tests, and recording IOPS, throughput, and latency data; Step 302: Run scripts under at least two operating systems to compare the performance differences of the same solid-state drive under different operating systems and file systems; Step 303: Write automated scripts based on the Fio engine to automatically generate I / O mode configuration files simulating MySQL database OLTP transactions, and perform small-block random read / write operations and continuous execution for a specified time, while recording performance fluctuation curves; Step 304: Combine perf and iostat to collect system-level resource usage and analyze the impact of IO scheduling strategies on performance.

[0097] Step 301: Fio Multi-Parameter Performance Testing. Based on the solid-state drives (categorized by interface, capacity, and file system) as described in Step 204, performance tests are performed using multiple sets of parameters on domestically developed systems (Kylin, openEuler) and general-purpose systems (such as CentOS 7.9 aarch64). IOPS, throughput, and latency are accurately recorded. Test Parameter Design (Covering Typical Scenarios): Parameter combinations are designed for different application scenarios. Each set of parameters is tested three times, and the average value is taken to avoid random errors. Block size selection: 4KB (suitable for small block read / write in databases, such as MySQL), 64KB (suitable for medium file transfers, such as log storage), 1MB (suitable for large file read / write, such as video caching); Queue depth selection: 1 (light load scenarios, such as personal office), 2 / 4 (normal server load), 8 / 16 (high concurrency scenarios, such as cloud computing); Read / write modes: sequential read (SEQ-R), sequential write (SEQ-W), random read (RND-R), random write (RND-W), covering different IO characteristics.

[0098] Fio Test Execution (Domestic Application Adaptation Operation): For each category of hard disk partition (e.g., / dev / nvme0n1p1, ext4 file system), execute the Fio command. Example logic is as follows: 4KB block, queue depth 1, random read: fio --name=4k_q1_randread --filename= / dev / nvme0n1p1 --rw=randread --bs=4K --iodepth=1 --size=100GB --runtime=300 --ioengine=libaio --direct=1 --output=4k_q1_randread.log; 1MB block, queue depth 16, sequential write: fio --name=1m_q16_seqwrite --filename= / dev / nvme0n1p1 --rw=write --bs=1MB --iodepth=16 --size=200GB --runtime=300 --ioengine=libaio --direct=1 --output=1m_q16_seqwrite.log; Key parameter descriptions: --ioengine=libaio (adapts to asynchronous I / O in domestically developed systems), --direct=1 (skips system cache and tests the actual performance of the hard drive), avoiding interference from the cache mechanism of domestically developed systems on the results.

[0099] Performance Metric Extraction and Recording: Extract core metrics from Fio output logs and organize them by "block size - queue depth - read / write mode": IOPS: Key metric for random read / write scenarios, extracted from log "iops : xxx" (e.g., 4KB random read IOPS: 12000); Throughput: Key metric for sequential read / write scenarios, extracted from "bw : xxx MB / s" (e.g., 1MB sequential write throughput: 500MB / s); Latency: Average latency extracted from "lat (ms) : avg=xxx" (e.g., average latency at queue depth 16: 8ms); Generate a "Fio Performance Raw Data Table" containing the test environment (system + file system), parameter combinations, and the three metric values ​​to ensure data traceability.

[0100] Step 302: In the cross-system and cross-file system performance comparison, based on the test data in Step 301, the performance differences of the same solid-state drive are compared under at least two operating systems (Kylin V10, openEuler 22.03 LTS, with CentOS 7.9 added for general comparison) and three file systems (ext4, xfs, Taiji), and the environmental influencing factors are identified: the comparison test environment is unified to ensure consistent test conditions: the same hard drive partition (avoiding hardware differences), the same combination of Fio parameters (such as 4KB blocks, queue depth 8, random read / write), the same test duration (300 seconds), and system background processes are closed (such as temporarily disabling "Kylin Security Center" in the domestic IT system to reduce resource consumption), avoiding interference from irrelevant variables.

[0101] The difference analysis is mainly carried out in two dimensions: "system comparison" and "file system comparison". Cross-system comparison: For example, the difference in 4KB random read IOPS between Kylin and openEuler. If Kylin is 11500 and openEuler is 12200, analyze the reasons for the difference (e.g., the openEuler kernel IO scheduler defaults to "mq-deadline", which has higher scheduling efficiency). Cross-file system comparison: Under the same domestic innovation system, the 1MB sequential write throughput of Taiji file system and ext4. If Taiji is 480MB / s and ext4 is 510MB / s, analyze the reasons for the difference (e.g., the log verification mechanism of Taiji file system adds a small amount of overhead, but the security is better). Calculate the percentage difference in performance (e.g., "openEuler has 6.1% higher IOPS than Kylin"), generate a "cross-environment performance comparison report", and clarify the performance advantages and disadvantages of domestic innovation systems and general systems, and domestic file systems and general file systems.

[0102] Troubleshooting for anomalies: If significant differences are found (e.g., IOPS on one system is only 50% of that on other systems), check the following: Driver compatibility: Confirm the domestic driver version using lsmod|grep nvme. If the version is too low (e.g., below v5.4), upgrade to the latest domestic driver provided by the manufacturer; File system parameters: Check the output of the mount command and compare the file system mount parameters on different systems (e.g., "data=ordered" vs. "data=writeback" for ext4, the latter has higher write performance), adjust and retest to verify.

[0103] Step 303: Simulate MySQL OLTP I / O and Record Performance Fluctuations. An automated script based on the Fio engine is written to simulate the typical I / O mode of MySQL OLTP (Online Transaction Processing) database. The script is continuously run and performance fluctuations are recorded to verify the stability of the hard drive in a domestically developed database scenario. The OLTP I / O mode characteristics are defined with reference to the I / O characteristics of the MySQL InnoDB storage engine: 70% random reads, 30% random writes, block size 4KB (corresponding to database page size), queue depth 8-16 (for high-concurrency transaction scenarios). The read / write ratio, block size, and queue depth are consistent with real OLTP scenarios.

[0104] The automated script is named "oltp_fio_auto.py". Its core functions include: Configuration file generation: Automatically generating the Fio OLTP test configuration file (.fio format), which includes I / O mode parameters (rw=randrw, rwmixread=70, bs=4K, iodepth=12) and test parameters (size=150GB, runtime=1800 (lasting 30 minutes), interval=10 (recording data every 10 seconds)); Test execution: Calling the domestically developed version of Fio to execute the configuration file (fio oltp_test.fio --output=oltp_result.log), ensuring that the script is compatible with the aarch64 architecture and has no "exec format error"; Fluctuation curve generation: Parsing the real-time data output by Fio (IOPS and latency every 10 seconds), and using Matplotlib to draw a performance fluctuation line graph (x-axis is time, y-axis is IOPS / latency), marking the fluctuation peak (e.g., "IOPS drops to 8000 in the 5th minute, and latency rises to 15ms").

[0105] During script execution, the hard drive status is monitored synchronously: SMART extended information (such as whether the "cache error count" increases) is viewed in real-time using `smartctl -x / dev / nvme0n1`; if performance fluctuations exceed 20% (e.g., IOPS drops sharply from 12000 to 9000), the fluctuation time point and system load are recorded (CPU / memory usage is checked using `top`), and it is investigated whether resource contention is caused by processes from the domestic IT system (e.g., "Kylin Firewall background scanning causes increased IO latency"). Output: The script generates an "OLTP Test Report," including the Fio configuration file content, performance fluctuation graph, and fluctuation analysis conclusions (e.g., "Performance fluctuation ≤ 12% within 30 minutes, meeting the stability requirements of the OLTP scenario").

[0106] Step 304: System-level Resource Analysis and IO Scheduling Strategy Impact Assessment. Using perf (a performance analysis tool) and iostat (an IO statistics tool) to collect system-level resource usage data, analyze the impact of IO scheduling strategies on SSD performance, and optimize the IO configuration of the domestically developed system. Tool Deployment and Parameter Settings: perf Installation: Install perf from the official source in the domestically developed system (Kylin: yum install -y perf; openEuler: dnf install -y perf), ensuring the version supports the aarch64 architecture (perf --version verification ≥ 5.10); iostat Installation: Depends on the sysstat package (pre-installed by default in domestically developed systems; if not installed, execute yum install -y sysstat), set the statistical interval to 1 second, and the duration to be consistent with the Fio test (e.g., 300 seconds).

[0107] Resource data collection: Performed synchronously with the Fio test in step 301, collecting two types of data: perf data: Execute `perf stat -e cpu-cycles,iowait,block:block_rq_issue -a -I 1000 -o perf_stats.log` to collect CPU cycles, IO wait time, and the number of block device IO requests, analyzing whether CPU performance is degraded due to IO wait bottlenecks; iostat data: Execute `iostat -x 1 300 -d / dev / nvme0n1>iostat_stats.log` to collect disk IO utilization (%util) and average queue length (avgqu-sz). If %util is close to 100% and avgqu-sz > iodepth, it indicates IO queue accumulation and a performance bottleneck.

[0108] In the comparative analysis of IO scheduling strategies, common IO scheduling strategies in domestically developed systems include mq-deadline (default), noop (no-operation scheduling, suitable for SSDs), and cfq (Completely Fair Queued). The impact is compared through the following steps: Scheduling strategy switching: Execute `echo "noop"> / sys / block / nvme0n1 / queue / scheduler` to switch to noop, and similarly switch to cfq. Confirm the switching result using `at / sys / block / nvme0n1 / queue / scheduler`; Performance comparison: Under the three scheduling strategies, perform the 4KB random read test (queue depth 16) in step 301, and compare IOPS and latency: Example results: mq-deadline strategy IOPS 11800, latency 8.2ms; noop strategy IOPS 12100, latency 7.8ms; cfq The strategy achieved 10,500 IOPS and a latency of 9.5ms. The conclusion is that the noop strategy is more suitable for SSDs (no mechanical disk seek time and low scheduling overhead) in domestically developed systems, followed by MQ-Deadline. CFQ suffers performance loss due to fairness scheduling. Therefore, it is recommended to adopt the noop strategy for domestically developed database scenarios.

[0109] System resource and performance correlation analysis combines perf, iostat, and Fio data to establish a correlation: if iostat shows %util=100%, perf shows iowait=30%, and Fio IOPS is lower than expected, it indicates that the hard drive has reached the IO bottleneck; if %util<80% but iowait=25%, it indicates that there is a bottleneck in system CPU scheduling (such as excessive CPU usage by kernel threads in a domestically developed system), and system configuration needs to be optimized.

[0110] Figure 5 yes Figure 1 The flowchart for step 4 is as follows: Figure 5 As shown, step 4 includes:

[0111] Step 401: Build a full-partition environment and use the `dd` command to fill the file system to 95% capacity; Step 402: In the full-partition environment, continuously run a mixed IO stress test for a preset time. The mixed IO stress test consists of sequential writes, random writes, and random reads in a specific ratio; Step 403: Continuously run for a preset time to simulate the IO load under real business scenarios. By writing a background monitoring script, read the solid-state drive temperature using the `smartctl -a / dev / sdX` command at preset intervals, and execute the `iostat -x 1 5` command once at preset intervals to collect IO performance data, which is recorded in a time-series database for subsequent consistency analysis; Step 404: Set a preset number of loops and enter and wake up the loop test within the preset number of loops; Step 405: Under high system load read / write, randomly perform power-off tests to check the system startup status and file system integrity.

[0112] Step 401: Set up a full partition test environment (fill capacity to 95%). Based on the file system partition created in step 204 (such as ext4, xfs, Taichi, taking a 200GB partition as an example), use the dd command to fill data to 95% of the partition capacity to simulate the high-pressure state of a hard drive near full capacity in a real scenario. The operation is as follows:

[0113] Partition capacity calculation and preparation: First, check the total partition capacity (e.g., 200GB) using `df -h / dev / nvme0n1p1`, and calculate the 95% target capacity (200GB × 95% = 190GB). To avoid filling deviations caused by caching in the `dd` command, choose a "non-zero data source" (e.g., ` / dev / urandom`, which generates random data, closer to real file writing) instead of ` / dev / zero` (easily compressed or optimized by the system cache). `dd` command filling operation (for domestically developed systems): Execute the filling command: `dd if= / dev / urandomof= / mnt / fill_data.bin bs=1G count=190 oflag=direct`. Key parameter explanations: `bs=1G`: Writes in 1GB units, reducing the number of IO operations and improving filling efficiency; `count=190`: Total write volume is 190GB, precisely controlling the filling ratio; `oflag=direct`: Skips the system cache and writes directly to the hard drive, ensuring that the filled data actually occupies physical space, avoiding "false full capacity" caused by the caching mechanism of domestically developed systems. During the filling process, monitor the capacity usage in real time using `watch -n 10 df -h / mnt`. When it displays "95% used" (e.g., 190GB / 200GB), terminate the `dd` command (if the capacity is full beforehand, `dd` will automatically stop and prompt "No space on the device").

[0114] After filling is complete, execute `df -h / mnt` to confirm the capacity percentage (it must be ≥94.5% and ≤95.5%, allowing for minor errors), then execute `ls -l / mnt / fill_data.bin` to confirm the fill file exists and its size is close to 190GB. If the error message "Capacity not reaching 95% after filling" appears, check if the domestically developed system has "disk quota" enabled (check using `quota -u root`; if enabled, execute `quotaoff / mnt` to disable it), ensuring the full partition environment is truly effective.

[0115] Step 402: Hybrid IO stress test under full partition. In the full partition environment built in Step 401, perform a hybrid IO stress test for a preset time using the Fio tool to simulate multiple types of concurrent IO scenarios in real business (such as server log writing + database query + file transfer). The specific operation is as follows: Hybrid IO stress test parameter design (close to real business). Referring to the common business IO characteristics of domestically developed servers, set the hybrid ratio as follows: 40% sequential write (such as log file writing), 30% random write (such as database transaction commit), and 30% random read (such as database query). The block size is selected based on the scenario: sequential write: 64KB (adapting to log block size); random read / write: 4KB (adapting to database page size); preset test time: 2 hours (7200 seconds) to ensure coverage of the impact period of "IO fragmentation accumulation under full partition"; queue depth is set to 16 (high concurrency business scenario) to avoid the inability to trigger high load due to a shallow queue.

[0116] The Fio mixed I / O test is executed on a full partition (e.g., / mnt, ext4 file system). The Fio command is: `fio --name=full_vol_mix_io --filename= / mnt / mix_test.bin --rw=mix --rwmixseq=40 --rwmixrand=30 --bsseq=64K --bsrand=4K --iodepth=16 --size=100GB --runtime=7200 --ioengine=libaio --direct=1 --output=full_vol_mix_io.log`. Key parameters are: `rw=mix`: Enables mixed I / O stress testing; `rwmixseq=40`: Sequential writes account for 40% of the load; `rwmixrand=30`: Random writes account for 30% of the load (random reads default to 100% - sequential writes - random writes = 30%); `bsseq=64K / bsrand=4K`: Specifies the block size for sequential I / O and random I / O respectively.

[0117] Record and compare test results, extract core metrics from Fio output logs: average IOPS, average latency, and throughput of mixed IO, and compare them with test results of the same parameters under "non-full partition" (e.g., capacity ratio of 50%) (refer to the baseline data in step 301), analyze the impact of full partition on performance (e.g., "random IOPS decreases by 15% and latency increases by 20ms under full partition, which is in line with the industry average attenuation range"), and generate a "Full Partition Mixed IO Performance Report".

[0118] Step 403: Background Monitoring and Time-Series Data Storage. By writing a background monitoring script adapted to the domestic IT innovation architecture, real-time solid-state drive temperature and IO performance data are collected and stored in a time-series database (a domestic database adapted to the domestic IT innovation scenario). This provides data support for subsequent stability analysis. The operation is as follows: Time-series database deployment (domestic IT innovation adaptation): Select the domestic time-series database TDengine (domestic IT innovation version, supporting aarch64 architecture). Install it through the domestic IT innovation software source: Kylin system: yum install -y tdengine; openEuler system: dnf install -y tdengine; After installation, start the service (systemctl start taosd), create the database (taos -e "create database ssd_monitor"), data tables (e.g., the "temp" table stores temperature, the "io_stats" table stores IO data), and define fields (e.g., timestamp, device name, temperature value, IO utilization, etc.).

[0119] The background monitoring script is named "ssd_monitor.py" and is written in Python (adapted for aarch64). Its core functions and execution logic are as follows: Temperature acquisition: Every 5 minutes, `smartctl -a / dev / nvme0n1` is executed to extract the "Temperature_Celsius" field (e.g., "Temperature_Celsius: 42") from the output to obtain the temperature value; IO performance acquisition: Every 10 minutes, `iostat -x 1 5` is executed (collecting data for 5 consecutive seconds and taking the average), extracting "% util" (IO utilization), "avgqu-sz" (average queue length), and "r_await / w_await" (average read / write latency); Data writing: The collected data in the format of "timestamp-device name-metric value" is written to the database using the TDengine Python SDK (taospy) to avoid data loss (the script includes "retry on write failure" logic, recording the error log after 3 retries).

[0120] The monitoring script runs in the background. A background service is configured using systemd in the domestic IT innovation system to ensure continuous script execution: Create the service file ` / etc / systemd / system / ssd-monitor.service` and configure it with `ExecStart= / usr / bin / python3 / path / ssd_monitor.py`; Start the service: `systemctl daemon-reload && systemctl start ssd-monitor.service`; Verify the service status using `systemctl status ssd-monitor.service` to ensure no errors occur, and store logs in ` / var / log / ssd_monitor.log`.

[0121] Step 404: The hibernation and wake-up cycle test simulates the alternating scenario of "hibernation energy saving - wake-up service" on the domestically developed server. A preset number of cycles is set to verify the functional integrity and performance stability of the SSD after hibernation and wake-up. The operation is as follows: Cycle parameters and domestically developed system hibernation configuration need to be set as follows: 20 cycles (covering the typical hibernation and wake-up frequency throughout the day), each cycle includes "10 minutes of hibernation + 10 minutes of mixed I / O after wake-up". For domestically developed system hibernation, "hardware hibernation support" needs to be enabled: Enable "SSD Sleep Mode" in the BIOS (some domestically developed motherboards require setting it in "Power Management"); System-level verification of hibernation function: Execute `systemctl suspend` to confirm that the host enters hibernation (screen black, hard drive indicator light off), then press the power button to wake it up. Check the hibernation and wake-up logs using `dmesg|grep suspend` to ensure there are no "hibernation failure" errors.

[0122] Write a loop control script "sleep_wake_cycle.py" with the following core logic: Loop initialization: Set a loop counter (from 1 to 20), and record the current time before each loop; Sleep operation: Call rtcwake -m mem -s 600 (set to automatically wake up after 10 minutes to avoid manual operation errors), and the host enters sleep mode; Verification after wake-up: After waking up, execute lsblk to confirm that the SSD is correctly recognized (device name / dev / nvme0n1 exists), and execute mount to confirm that the full partition / mnt is correctly mounted; Load test after wake-up: Execute the mixed IO test in step 402 (shortened to 10 minutes, runtime=600) to ensure that the hard drive can handle the load after wake-up and there is no "IO timeout"; Loop recording: After each loop, record "loop count - sleep / wake status - whether IO performance is normal" to sleep_wake_report.txt.

[0123] Anomaly Handling and Result Analysis: If an anomaly occurs in a certain loop (such as the hard drive not being recognized after wake-up), perform the following checks: Driver level: lsmod|grep nvme to confirm whether the NVMe driver is loaded. If not loaded, execute modprobe nvme to reload it; Hardware level: Check the power supply of the PCIe slot on the domestically developed motherboard (check whether "Current Speed" is "8GT / s" using lspci -v, and whether there is any speed reduction); After the loop ends, count the number of anomalies (required to be ≤1, i.e., anomaly rate ≤5%), and analyze the cause of the anomaly (such as "the driver was not loaded on the 12th wake-up because the driver released resources during the domestically developed kernel hibernation and did not recover").

[0124] Step 405: Under the full-partition mixed I / O high-load scenario of Step 402, perform a random power outage test to verify the system boot capability and file system integrity of the SSD after an extreme power outage. This follows the power outage test in Step 4 and intensifies the "high load + full partition" dual stress. The operation is as follows: Power outage test preparation: Hardware continues the programmable power controller (such as Keysight N6705B) from Step 4, connected to the domestic innovation test host via serial port to ensure that the power outage command can be triggered in real time; Software level: Ensure that the mixed I / O test is running (fio process is active, confirmed by ps aux|grep fio); Disable the system's "power outage protection mechanism" (such as the "Kylin power outage backup" of the domestic innovation system, to avoid automatic backup interfering with the test, execute systemctl stop power-backup.service).

[0125] Random power-off execution logic: Write a power-off control script "random_power_off.py". The core logic is as follows: Random power-off interval: Set a random interval of 30 seconds to 300 seconds (generated by the Python random module), and perform a total of 10 power-off operations; Power-off trigger: The script sends a command (such as "POWER_OFF") to the power controller via the serial port to cut off the host power supply, and restores the power supply after 10 seconds (simulating "unexpected power-off + rapid power-on"); Power-off timing record: Record the current runtime of the mixed IO at each power-off (such as "when the 3rd power-off occurred, the mixed IO had been running for 45 minutes"), which is convenient for subsequent correlation with anomalies.

[0126] The verification process after a power outage is as follows: System startup status: Observe the host startup process and record the startup time (normally ≤60 seconds). Note any boot errors such as "disk error" or "unable to mount partition" (e.g., " / dev / nvme0n1p1 mount failed"). File system integrity verification: If startup is normal, first unmount the full partition (umount / mnt), and execute the file system check command: ext4: fsck.ext4 / dev / nvme0n1p1, to check for "inode error" or "block corruption" (normally should display "clean, xxx files, xxx blocks"). Taiji file system: fsck.taiji / dev / nvme0n1p1 (a dedicated check command for domestic IT innovation), confirming no "log check failure". Data integrity: After mounting the partition (mount / dev / nvme0n1p1 / mnt), execute md5sum / mnt / fill_data.bin (fill file) and compare it with the checksum before the power outage to confirm no data corruption.

[0127] The test results are recorded to generate a "High Load Power Outage Test Report", which includes: number of power outages, number of startup anomalies (≤0), number of file system errors (≤0), and number of data corruptions (≤0). If an anomaly occurs (such as "fsck detected 2 bad blocks after the 7th power outage"), check whether "Bad Block Count" increases using smartctl -a to locate the hardware problem.

[0128] Figure 6 yes Figure 1 The flowchart for step 5 is as follows: Figure 6 As shown, step 5 includes: Step 501, obtaining the list of encryption algorithms supported by the solid-state drive by sending a query command to the solid-state drive, and confirming that it includes the national cryptographic algorithms SM2, SM3, and SM4; Step 502, using the gmssl toolset certified by the State Cryptography Administration to test the encryption and decryption speed of the encrypted partition of the solid-state drive using the SM4-CTR algorithm; Step 503, verifying whether the encryption module of the solid-state drive conforms to the security protocol standard, and testing the security of the TRIM command and the reliability of data erasure.

[0129] Step 501: To address the mandatory requirement for national cryptographic algorithms (SM2 / SM3 / SM4) in the domestic IT innovation scenario, use a dedicated command to query the list of encryption algorithms supported by the solid-state drive (SSD) to verify whether the national cryptographic algorithms are integrated. The operation is as follows: Algorithm query command adaptation (based on interface type): According to the SSD interface type (NVMe / SATA), execute the corresponding query command in the domestic IT innovation system (Kylin, openEuler) to ensure that the tool supports the aarch64 architecture: NVMe SSD: Use the domestic IT innovation version of the NVMe tool (version ≥ 1.16) and execute `nvme crypto-get-supported / dev / nvme0n1` (some manufacturers extend the command to `nvme id-ctrl --crypto / dev / nvme0n1`). This command will output information such as the "encryption algorithm ID", "key size", and "mode" supported by the SSD; SATA SSD: Use the domestic IT innovation version of hdparm (version ≥ 9.60) or smartctl (version ≥ 7.3) and execute `hdparm`. Use `--security-help / dev / sda` or `smartctl -x / dev / sda|grep "EncryptionAlgorithm"` to extract the encryption algorithm description field.

[0130] Filter the command output for national cryptographic algorithm characteristics to determine whether it includes SM2, SM3, or SM4: SM4 algorithm: usually labeled "SM4-128" (128-bit key), supports CTR, CBC, and other modes (CTR mode is commonly used in domestically developed encryption). If the output is "Algorithm: SM4-128-CTR", it means SM4 is supported; SM3 algorithm: used for multiple associated data integrity checks, the output may show "Hash Algorithm: SM3" (used for hash verification of encrypted data); SM2 algorithm: mainly used for key exchange, the output may be labeled "Key Exchange: SM2" (integrated in the secure boot process on some hard drives); if the command output does not have a clear national cryptographic algorithm identifier, contact the hard drive manufacturer to obtain a "domestic encryption algorithm support certificate", or use the manufacturer's domestically developed encryption-specific tool (such as "SSD Crypto Tool-aarch64") to re-query to ensure the algorithm list is traceable. Generate an "Encryption Algorithm Support Report" which records the query command, the complete list of algorithms, and the status of national cryptographic algorithms (e.g., "Supports SM4-128-CTR and SM3, but does not support SM2 (SM2 is supplemented by TPM chip)"). It also makes a preliminary determination of whether the basic requirements for domestic encryption innovation are met (at least SM4 must be supported, and SM2 / SM3 can be supplemented by the system layer).

[0131] Step 502: GMSSL toolset and SM4-CTR encryption / decryption speed test. Using the GMSSL toolset certified by the State Cryptography Administration (domestic innovation version, supporting aarch64), perform SM4-CTR algorithm encryption / decryption tests on the encrypted partition of the solid-state drive to quantify encryption performance loss. The operation is as follows: Obtain the domestically adapted GMSSL (version ≥ 3.1.1, must include the "National Cryptography Product Model Certificate") from the channels recommended by the State Cryptography Administration, and install it on the domestically developed system: Galaxy Kylin system: execute yum install -y gmssl-aarch64 through the domestically developed software source; openEuler system: download the rpm package and execute dnflocalinstall gmssl-3.1.1-1.aarch64.rpm; after installation, verify the version with gmssl version, and confirm that the SM4 algorithm module is loaded with gmssl help sm4.

[0132] Encryption partition preparation and test data generation: Enable partition encryption: For the 200GB test partition (e.g., / dev / nvme0n1p2) created in step 204, enable SM4 encryption using the cryptsetup tool (domestic innovation version). Execute `cryptsetupluksFormat --cipher sm4-ctr / dev / nvme0n1p2`, set the encryption key (must meet the domestic innovation password complexity, such as 16-character alphanumeric characters), and then mount the encrypted partition: `cryptsetup open / dev / nvme0n1p2 ssd_crypto&&mount / dev / mapper / ssd_crypto / mnt / crypto`; Generate test data: Within the encrypted partition, create a 50GB random test file (simulating real business data, avoiding compression optimization affecting speed) using `dd if= / dev / urandom of= / mnt / crypto / test_data.bin bs=1G count=50`.

[0133] SM4-CTR Encryption / Decryption Speed ​​Test and Analysis. Encryption speed test: Execute `gmssl sm4 -e -in / mnt / crypto / test_data.bin -out / mnt / crypto / test_data.sm4 -K 0123456789abcdef0123456789abcdef -iv 0123456789abcdef0123456789abcdef -mode ctr` (-K for 128-bit key, -iv for initialization vector), record the encryption time (e.g., "50GB data encryption time 120 seconds"), and calculate the encryption speed (50GB / 120s ≈ 416.7 MB / s). Decryption speed test: Execute `gmssl sm4 -d -in / mnt / crypto / test_data.sm4 -out / mnt / crypto / test_data_dec.bin -K` Run the command `0123456789abcdef0123456789abcdef-iv 0123456789abcdef0123456789abcdef-mode ctr` to record the decryption time and calculate the decryption speed. Performance loss comparison: Compare the SM4 encryption / decryption speed with the unencrypted sequential read / write speed of the same partition in step 301 (e.g., unencrypted sequential write speed of 500MB / s), calculate the performance loss (e.g., "encrypted write speed 416.7 MB / s, loss 16.7%, meets the ≤20% loss requirement for domestic IT innovation"), and generate an "SM4-CTR encryption / decryption performance report". Data integrity verification: After decryption, execute `md5sum / mnt / crypto / test_data.bin` and `md5sum / mnt / crypto / test_data_dec.bin`, and compare the two checksums to ensure that the SM4-CTR encryption / decryption process is free of data corruption.

[0134] Step 503: Encryption Module Compliance and TRIM / Data Erasure Security Testing. This step verifies whether the solid-state drive encryption module complies with the domestic IT security protocol standard, and tests the security of the TRIM command and the reliability of data erasure to eliminate the risk of data leakage. Encryption module compliance verification (referencing national cryptographic standards): Based on "GM / T 0028-2014 Security Technical Requirements for Cryptographic Modules" (domestic IT encryption module benchmark standard), verification is performed from three aspects: Key Management: Execute `nvme security-send / dev / nvme0n1 --send-op=0x01` (NVMe) or `hdparm --security-set-pass 123456 / dev / sda` (SATA) to set the encryption key, then execute `nvme security-send --send-op=0x02` (key erasure) to verify whether the key supports the entire "create-store-erasure" process, and whether key storage relies on a hardware encryption chip (not system memory); Algorithm Implementation via GMSSSL Speed. The SM4 algorithm performance stability test is performed by running it three times consecutively (10 minutes each time). If the performance fluctuation is ≤5%, it indicates that the algorithm implementation is normal. Compliance document verification: The hard drive manufacturer is required to provide a "National Cryptography Compliance Certification Report for Encryption Module" (such as the "Security Test Report for Cryptographic Module") to confirm that the module has passed the test of the State Cryptography Administration. The number can be found on the "Official Website of the State Cryptography Administration".

[0135] The TRIM command is used to release invalid sectors. It's necessary to verify whether TRIM will lead to encrypted data leakage in an encrypted scenario: Enabling TRIM and Encryption: In a domestically developed system, enable TRIM on the encrypted partition (mount -o discard / dev / mapper / ssd_crypto / mnt / crypto), and execute `fstrim / mnt / crypto` to trigger TRIM; Data Recovery Detection: Before TRIM, write 10GB of random data to the encrypted partition (dd if= / dev / urandom of= / mnt / crypto / secret.bin bs=1G count=10), delete the file (rm / mnt / crypto / secret.bin), and then execute TRIM; Sector Data Reading: Use a domestically developed data recovery tool (such as "DiskGenius for..."). Try reading the sectors after TRIM (e.g., sectors 1000-2000 of / dev / nvme0n1p2) using "aarch64". If the result is "all zeros" or "encrypted garbled characters" (not the original data), it means that the TRIM command is safe and there is no data leakage. If the original data fragment can be read, TRIM should be disabled and the encryption driver should be investigated.

[0136] Data erasure reliability test (secure erasure) verifies whether data erasure is thorough in a solid-state drive (SSD) encrypted scenario, meeting the "data unrecoverable" requirement of domestic IT innovation: Secure erasure is performed: NVMe hard drive: execute `nvme format / dev / nvme0n1 --ses=2` (`--ses=2` means "encrypted secure erasure," which makes the data unusable by destroying the encryption key); SATA hard drive: execute `hdparm --security-erase 123456 / dev / sda` (a security password needs to be set first, as in step 503); Post-erasure verification: After erasure, use `dd if= / dev / nvme0n1 of= / dev / null bs=1G count=10` to read the first 10GB of data from the hard drive. If the output is all "00" or "random garbled characters" (without any original data characteristics), and `smartctl -a / dev / nvme0n1` displays "Erase Count" increasing and "Data...", then the data erasure is successful. A "Remaining" value of 0 indicates reliable data erasure. Third-party verification: A qualified third-party testing organization was commissioned to use professional equipment (such as a hard drive sector analyzer) to test the erased sectors and issue a "Data Irrecoverability Report" as a compliance basis. Security test results summary: A "Security Compliance Report for Encryption Module" is generated, including compliance determination (compliant / non-compliant with GM / T 0028), TRIM security conclusion (secure / risky), and data erasure reliability conclusion (reliable / unreliable), along with key test logs (such as GMSSL speed test logs and TRIM data recovery screenshots).

[0137] Figure 7 yes Figure 1 The flowchart for step 6 is as follows: Figure 7 As shown, step 6 includes: step 601, summarizing test data from each stage and automatically generating a test report for the solid-state drive, the test report including performance trend charts, stability scores, security compliance conclusions and timelines of abnormal events for the solid-state drive under different test scenarios; step 602, multi-dimensional filtering and comparative analysis of test results to determine whether they meet enterprise-level application requirements.

[0138] Step 601: Based on the structured data from each previous testing phase (stored in the TDengine time-series database and CSV log files), integrate the data using automated scripts to generate a test report containing multi-dimensional content. The specific operations are as follows: Data aggregation scope and core indicator selection: Filter key data according to four dimensions: "Basic Configuration - Performance - Stability - Security," ensuring coverage of enterprise-level priorities: Basic configuration data: System version (Kylin V10 / openEuler 22.03), hard drive interface type (NVMe / SATA), partition table type (MBR / GPT), file system type and mount success rate, driver version (e.g., nvme-aarch64-driver v5.10.0), tool version (Fio 3.28 / gmssl3.1.1); Performance data: "Block size - queue depth - IOPS / latency / throughput" in non-encrypted / encrypted scenarios. Comparison table (e.g., 4KB random read IOPS: unencrypted 12000 / encrypted 10200), cross-system performance difference value (e.g., Kylin's sequential write throughput is 5% lower than openEuler), OLTP scenario 30-minute performance fluctuation curve data (IOPS / latency record every 10 seconds); stability data: full partition (95% capacity) mixed IO 2-hour performance decay rate (e.g., 12%), number of abnormal sleep wake-up attempts (0 times), system startup success rate after 10 high load power outages (100%), number of file system errors (0 times), peak hard disk temperature (45℃, ambient temperature 25℃); security data: national cryptographic algorithm support status (supports SM4-CTR / SM3, SM2 is supplemented by TPM), SM4 encryption performance loss rate (15%), TRIM command security judgment (secure, no data leakage), third-party detection conclusion after data erasure (unrecoverable), encryption module national cryptographic compliance certification number (e.g., GM0012-2024).

[0139] The automated report generation tool and core module were designed, and a Python automation script (ssd_test_report_generator.py, adapted for the aarch64 architecture) was written, integrating data extraction, chart generation, and report layout functions. Data extraction was integrated by reading time-series data (such as temperature-IO utilization correlation data) using the TDengine Python SDK (taospy), parsing CSV log files (such as Fio test results and sleep / wake records) using pandas, and automatically removing outliers (such as sudden drops in IOPS due to power outages). The chart generation module used Matplotlib to draw performance trend charts for multiple scenarios, including: a line chart comparing IOPS in non-encrypted and encrypted scenarios (x-axis is queue depth, y-axis is IOPS); and a full-partition mixed IO... 2-hour latency change curve (x-axis is time, y-axis is latency); bar chart of sequential read / write throughput for different file systems (ext4 / xfs / Taiji); stability scoring module: a 100-point scoring standard is established, calculated by weight (basic configuration 10 points + performance 30 points + stability 35 points + security 25 points), example: basic configuration: 10 points for all file systems mounted successfully, 3 points deducted for each failure; stability: 10 points for full partition performance degradation rate ≤15%, 1 point deducted for each 1% exceeding the limit; 10 points for no abnormalities during hibernation and wake-up, 5 points deducted for each abnormality; 15 points for file system intact after power failure, all points deducted for any errors.

[0140] Security and Compliance Conclusion Module: Automatically integrates results on national cryptographic algorithm support, encryption performance loss, TRIM security, and data erasure reliability to generate structured conclusions (e.g., "Complies with domestic encryption requirements: Supports SM4-CTR algorithm, encryption loss 15%≤20%, no data leakage during TRIM, data erasure is unrecoverable"); Abnormal Event Timeline Module: Records abnormal events, occurrence scenarios, handling measures, and results in chronological order of test time (e.g., "Step 102: SATA hard drive driver failed to load during Galaxy Kylin installation → Step 303: IOPS dropped sharply at the 15th minute of OLTP test → Step 405: bad blocks were detected by fsck after the 7th power outage (later confirmed as a false alarm)"), generating a visual timeline (horizontal timeline drawn using Matplotlib).

[0141] Report Output and Formatting Specifications: The script generates a PDF report (SSD_Enterprise_Test_Report_2024.pdf), formatted according to the structure of "Report Summary - Test Environment - Test Process - Test Results - Security and Compliance Conclusions - Anomaly Timeline - Improvement Suggestions". The "Test Results" section includes all selected core data, generated trend charts, and stability scores (e.g., 88 points, excellent). Ensure the report conforms to enterprise-level document standards (clear fonts, page numbers, and chart annotations) and can be directly used for the acceptance of domestic IT innovation projects.

[0142] Step 602: Multi-dimensional screening and comparison analysis and enterprise-level application adaptability determination. Based on the test data summarized in Step 601, multi-dimensional screening and comparison are conducted according to the core requirements of enterprise-level applications (performance, stability, security, compatibility) to determine whether the hard drive meets the requirements of enterprise-level scenarios (such as domestically developed server databases, high-concurrency storage, core business systems): Multi-dimensional screening conditions and comparison logic design are set according to "scenario-based requirements". The test data is compared with enterprise-level standards: Performance dimension screening and comparison: Screening conditions: For enterprise-level database scenarios (MySQL OLTP), focus on "4KB random read / write IOPS / latency" and "performance loss after encryption"; for high-concurrency storage scenarios, focus on "1MB sequential read / write throughput" and "IO utilization when queue depth is 16"; Comparison standards: Refer to the "Performance Indicator Requirements for Domestically Developed Enterprise-level SSDs" (such as OLTP scenario 4K random read IOPS ≥ 10000, encryption performance loss ≤ 20%). If the test data (encrypted 4K random read IOPS 10200, loss 15%) meets the standard, performance adaptability is determined.

[0143] Stability Dimension Screening and Comparison: Screening criteria: Enterprise-level core business requirements "7×24 hours high load operation without failure" and "Annual Failure Rate (AFR) ≤ 0.5%"; Comparison standard: Based on test data (full partition mixed IO 2 hours without failure, 20 sleep wake-ups without anomalies, 10 power outages without file system errors), the estimated annual failure rate (AFR≈0.2%) is lower than the 0.5% standard, and the stability is deemed suitable.

[0144] Security Dimension Screening and Comparison: Screening Criteria: Enterprise-level data security requirements "Supports national cryptographic algorithms", "Data erasure is irreversible", "TRIM does not leak"; Comparison Standard: Complies with "GB / T 38636-2020 Information Security Technology Solid State Drive Security Technical Requirements", test data shows support for SM4-CTR / SM3, third-party detection shows data erasure is irreversible, and security is deemed compatible.

[0145] Compatibility Dimension Screening and Comparison: Screening criteria: Enterprise-level domestically developed servers must be compatible with at least two operating systems and multiple file systems; Comparison standard: Test data shows that the hard drive can be recognized normally on both Galaxy Kylin V10 and openEuler 22.03 (100% success rate), and the mounting success rate of ext4 / xfs / Taiji file systems is 100%, with no compatibility errors, thus determining compatibility.

[0146] Enterprise-level compatibility comprehensive assessment and risk warning. Comprehensive assessment logic: If all four dimensions meet the standards, it is judged as "fully compatible with enterprise-level domestic IT application"; if a single dimension is not met (such as performance meeting the standard but lacking SM2 security support), it is judged as "partially compatible and requires supplementary optimization"; if two or more dimensions are not met, it is judged as "not compatible".

[0147] Example judgment result: Based on test data, the hard drive meets enterprise-level standards in all four dimensions of "performance-stability-security-compatibility", and the encryption performance loss (15%) is lower than the industry average (20%). There are no abnormalities in hibernation and wake-up. It is judged to be "fully adapted to enterprise-level database servers and high-concurrency storage node application scenarios". Optimization suggestions and risk warnings: If there are minor deficiencies (such as the sequential write throughput of Taiji file system under openEuler system is 8% lower than ext4), optimization suggestions are made (such as upgrading Taiji file system driver to v2.1.0); Enterprise-level application precautions are reminded (such as using noop IO scheduling strategy in high-load scenarios and backing up encryption partition keys regularly).

[0148] The assessment report outputs the "Solid State Drive Enterprise-Level Domestic Application Adaptability Assessment Report," which includes a multi-dimensional comparison table (text description version), comprehensive assessment conclusions, and optimization suggestions. This serves as the core basis for enterprise procurement and deployment, and is accompanied by a complete preliminary test report as supporting material.

[0149] A second embodiment is proposed based on the first embodiment, and the second embodiment includes:

[0150] Step 1: Initialize the test environment, install the operating system, and configure the compilation environment. Using the official Huawei image, install the Kylin OS and UnionTech UOS operating system on the Huawei TaiShan server platform. Record whether the hard drive is recognized during installation, whether the partitioning process is smooth, and whether the driver loads correctly. After installation, use commands such as lspci, lsblk, and fdisk -l to confirm that the SSD is correctly recognized, model "Huawei Hygon Flash Memory Technology Co., Ltd. HNS3C0E60", with a capacity of 1TB. Based on the existing driver interface of the open-source driver, add the necessary test interfaces for the "Huawei Hygon Flash Memory Technology Co., Ltd. HNS3C0E60" SSD under test. Write and execute test scripts to verify whether the compilation environment is normal.

[0151] Step 2: Perform basic function and compatibility tests. Use commands such as lspci, lsblk, and fdisk -l to confirm that the SSD is correctly recognized, model "Huawei Hygon Flash Memory Technology Co., Ltd. HNS3C0E60", capacity 1TB. Use graphical disk tools and command-line tools to perform partitioning operations, creating both MBR and GPT partition table formats. Create two file systems, ext4 and xfs, and test the Taiji file system. Write an automated script to perform operations such as creating 100GB file clusters, sequential read / write, and verifying file integrity, executing it 100 times in a loop.

[0152] Step 3: Perform performance testing. Use Fio for performance testing, with block sizes of 4K, 64K, and 1M, read / write modes of sequential read and random read / write, and queue depths of 1, 2, 4, and 8. Record random read / write IOPS, sequential read / write throughput, average latency, and 99.9% tail latency. Write an automated script to simulate database load by performing random read / write operations on 100GB of data.

[0153] Step 4: Perform power management and reliability testing. Use the `dd` command to fill the SSD partition to 95% capacity. Run a 96-hour random I / O stress test continuously. Monitor the SSD temperature range as 5-40℃, control performance consistency variation within ±10%, and ensure the bad block remapping count is 0. Perform 50 S3 / S4 loop tests, verifying file system integrity and application status after each wake-up. Under high load read / write, randomly power off twice, check the system startup status, use the `fsck` tool to verify file system integrity, confirm that the "unexpected power failure count" increases by 2 times, and no data is lost.

[0154] Step 5: Perform security feature tests. Verify that the SSD supports SM2, SM3, and SM4 national cryptographic algorithms. Use a national cryptographic algorithm testing toolset to verify that the encryption and decryption speed reaches the theoretical line speed of 1GB / s. Use the secure erase command to completely delete the test data, and use the dd tool to verify whether the data can be recovered. For SSDs that support SED, test the PSID recovery function and verify that the performance overhead is controlled within 5%.

[0155] Step 6: Generate a test report. Summarize the test results and generate an Excel test data table. Analyze the test results to determine whether the requirements for enterprise-level applications are met. Generate the "SSD Domestic Application Compatibility Certification Test Report," which includes test environment details, quantitative test results, reliability conclusions, security feature verification results, issues and logs, and a final compatibility rating of "Excellent."

[0156] A third embodiment is proposed based on the first embodiment, and the third embodiment includes:

[0157] Step 1: Initialize the test environment, install the operating system, and configure the compilation environment. Using the official Kunpeng image, install the Tongxin UOS operating system on the Kunpeng 920 server platform. Record whether the hard drive is recognized during installation, whether the partitioning process is smooth, and whether the driver loads correctly. After installation, use commands such as lspci, lsblk, and fdisk -l to confirm that the SSD is correctly recognized, model "Loongson Storage Technology Co., Ltd. DC1600", with a capacity of 2TB. Add the necessary test interfaces for the "Loongson Storage Technology Co., Ltd. DC1600" SSD under test, based on the existing open-source driver interface. Write and execute test scripts to verify whether the compilation environment is normal.

[0158] Step 2: Perform basic function and compatibility tests. Use commands such as lspci, lsblk, and fdisk -l to confirm that the SSD is correctly recognized, model "Loongson Storage Technology Co., Ltd. DC1600", capacity 2TB. Use graphical disk tools and command-line tools to perform partitioning operations, creating both MBR and GPT partition table formats. Create two file systems, ext4 and xfs, and test the Feiyu file system. Write an automated script to perform operations such as creating 200GB file clusters, sequential read / write, and verifying file integrity, executing it 150 times in a loop.

[0159] Step 3: Perform performance testing. Use Fio for performance testing, with block sizes of 4K, 64K, and 1M, read / write modes of sequential read and random read / write, and queue depths of 1, 2, 4, and 8. Record random read / write IOPS, sequential read / write throughput, average latency, and 99.9% tail latency. Write an automated script to simulate database load by performing random read / write operations on 200GB of data.

[0160] Step 4: Perform power management and reliability testing. Use the `dd` command to fill the SSD partition to 98% capacity. Run a 120-hour random I / O stress test continuously. Monitor the SSD temperature range as 10-45℃, control performance consistency variation within ±8%, and maintain a bad block remapping count of 0. Perform 60 S3 / S4 loop tests, verifying file system integrity and application status after each wake-up. Under high load read / write, randomly power off 3 times, check the system startup status, use the `fsck` tool to verify file system integrity, confirm that the "unexpected power failure count" increases by 3 times, and no data is lost.

[0161] Step 5: Perform security feature tests. Verify that the SSD supports SM2, SM3, and SM4 national cryptographic algorithms. Use a national cryptographic algorithm testing toolset to verify that the encryption / decryption speed reaches the theoretical line speed of 2GB / s. Use the secure erase command to completely delete the test data, and use the dd tool to verify whether the data can be recovered. For SSDs that support SED, test the PSID recovery function and verify that the performance overhead is controlled within 3%.

[0162] Step 6: Generate a test report. Summarize the test results and generate an Excel test data table. Analyze the test results to determine whether the requirements for enterprise-level applications are met. Generate the "SSD Domestic Application Compatibility Certification Test Report," which includes test environment details, quantitative test results, reliability conclusions, security feature verification results, issues and logs, and a final compatibility rating of "Excellent."

[0163] A fourth embodiment is proposed based on the first embodiment, and the fourth embodiment includes:

[0164] This embodiment aims to detail how to implement the deep compatibility and reliability testing scheme of this invention on an enterprise-grade solid-state drive (model: Huawei Hygon HNS3C0E60, capacity: 1TB) in a typical domestic IT innovation environment (Huawei TaiShan server, Kylin operating system). 1. Test Environment Initialization and Configuration: Hardware Platform: Huawei TaiShan 2280 V3 server. Solid-state drive under test: Huawei Hygon HNS3C0E60 (1TB), installed in the server's built-in NVMe slot. Operating System: Kylin Advanced Server Operating System V10 (SP2) installed using the official image, kernel version 4.19.90-25.ky10.x86_64. Driver and Interface Preparation: Based on the standard Linux NVMe driver, to achieve deep monitoring of the SSD, we developed a dedicated kernel module ssd_monitor.ko. This module provides the ability to read non-standard SMART attributes (such as: average NAND erase / write cycles, internal temperature sensor readings) through extended ioctl interfaces (e.g., IOCTL_SSD_GET_EXT_SMART). This module is compiled and loaded into the kernel before the test begins. The automation script framework uses the main control script `ssd_auto_test.py` written in Python 3.8. This script is responsible for calling each test submodule sequentially, logging, and collecting test results.

[0165] 2. Basic Functionality and Compatibility Testing (executed by the main control script calling test_basic.py): The script executes the command lsblk -d -o NAME,MODEL,SIZE / dev / nvme0n1 and parses the output to confirm that the system recognizes the SSD with model "HNS3C0E60" and a capacity of 953.9GB (i.e., 1TB).

[0166] Using the parted command-line tool, create MBR and GPT partition tables for / dev / nvme0n1 in sequence; create an ext4 file system on the MBR partition (command: mkfs.ext4 / dev / nvme0n1p1); create an xfs file system on the GPT partition (command: mkfs.xfs / dev / nvme0n1p1) and a Taichi file system (command: mkfs.taichi / dev / nvme0n1p2); Steps 2-3 (basic I / O verification): After mounting the ext4 file system, run an automated script. This script performs the following operations: creates a 1GB test file (using the dd command), calculates the MD5 checksum of the file, then performs continuous read and write operations, and after completion, recalculates the checksum and compares it with the original value to verify data integrity. This loop is automatically repeated 100 times.

[0167] 3. Performance Testing (executed by the main control script calling the test_performance.fio configuration file): Step 3-1 (Standard Performance Benchmark): Testing is performed using Fio 3.28. The main control script generates and executes a Fio job file with key parameters including: rw=randread, randwrite, read, write (tested separately); bs=4k, 64k, 1m; iodepth=1, 4, 8, 32; each test run takes 300 seconds. Simulates database OLTP load. Using Fio configuration rw=randrw, rwmixread=70, bs=8k, iodepth=16, numjobs=4, the run time is 12 hours. The script records the average IOPS, standard deviation, and 99.9% tail latency throughout the process.

[0168] During performance testing, the background monitoring script monitor_perf.sh collects IO operation counts and latency data from / sys / block / nvme0n1 / stat once per second for subsequent performance consistency analysis.

[0169] 4. Power Management and Reliability Testing: The SSD's available space was filled to over 95% using the `dd if= / dev / zero` command. A mixed I / O stress test was run continuously for 96 hours at full capacity. The mixed mode was: 60% random write (4K), 30% sequential read (128K), and 10% random read (4K). This test used the Fio driver. During the stress test, the `smartctl -x / dev / nvme0n1` command was executed every 5 minutes to record extended SMART data (obtained through the aforementioned custom module) to a log file. Simultaneously, a monitoring script recorded the SSD's current temperature. Performance consistency analysis was performed by comparing the average IOPS of the first and 96th hours of the stress test to calculate the performance degradation rate (≤8% measured in this example). The `systemctl suspend` and `rtcwake` commands were used to automate 50 cycles of S3 hibernation to wake-up. After each wake-up, the script automatically checked the file system mount status (using the `mount` command) and verified the integrity of a pre-generated checksum file. During the mixed I / O stress test, at the 48th and 72nd hours, a forced power-off was performed on the server via the remote management interface (iBMC). Power was then restored after 60 seconds. Upon system startup, a script automatically checked the kernel log for I / O errors and ran `fsck.ext4 -f / dev / nvme0n1p1` to force a filesystem check. Simultaneously, the SMART log confirmed that the "Unexpected Power Outage Count" field had increased by two.

[0170] 5. Security Feature Testing: Execute the command `nvme id-ctrl / dev / nvme0n1|grep -i crypto` to check the list of encryption algorithms supported by the controller, confirming the presence of "SM4". Use the `cryptsetup` tool to create an SM4-XTS encrypted volume using the kernel's DM-Crypt layer. Run the Fio sequential read / write test (1MB block size) on this volume, measuring a throughput of approximately 950MB / s, close to the sequential read / write performance of the hard drive in its unencrypted state, indicating support for hardware SM4 acceleration. Execute the `NVMeFormat` command (`nvme format / dev / nvme0n1 -s 1`) to erase user data. After erasure, attempt to scan the first 100MB of raw data using the command `dd if= / dev / nvme0n1 bs=1M count=100|strings`, confirming that no meaningful plaintext test data can be recovered.

[0171] 6. Test Report Generation: After all tests are completed, the main control script ssd_auto_test.py starts the report generation module report_generator.py. This module performs the following operations: parses all log files generated during the testing phase (Fio output, SMART logs, system logs, etc.); automatically fills key data (such as 4K random read / write IOPS, sequential read / write bandwidth, long-term test performance degradation rate, file system status after power failure test, encryption performance, etc.) into a predefined Markdown template; determines each test item as "pass / fail" based on preset enterprise-level application thresholds (e.g., 99.9% latency <10ms, long-term performance degradation <15%, thorough secure erasure); and finally generates a comprehensive test report named SSD_Compatibility_Report_HNS3C0E60_Kylin.md, which includes test environment details, quantitative data charts, issue logs, and a final compatibility rating (in this embodiment, all key indicators meet the standards, and the rating is "excellent").

[0172] This embodiment integrates multiple modules, including basic function and compatibility testing, performance testing, power management and reliability testing, and security feature testing, to form a complete and automated testing solution. This avoids the shortcomings of traditional testing methods, which are often independent and discontinuous, thus improving the completeness and efficiency of the testing. By employing automated test scripts and tools, the testing process is made intelligent and automated, reducing manual operation and labor costs while improving the accuracy and reliability of the tests. Through simulating real-world application scenarios, such as database load simulation and system startup speed testing, the functional compatibility, performance, data reliability, power consumption, and other aspects of the SSD on the specified domestic IT platform are comprehensively evaluated. In terms of stability and security, it meets the requirements of enterprise-level applications; it introduces key test items such as long-term stress testing and abnormal power failure testing to test the durability and performance stability of the SSD, ensuring the accuracy of test results and providing a reliable data storage solution for enterprise-level applications; through national cryptographic algorithm verification and secure erasure testing, the security performance of the SSD is verified, meeting the standard requirements of the State Cryptography Administration and improving the level of data security protection; the provided test scheme has good scalability and adaptability, and the test content and process can be flexibly adjusted according to actual needs, applicable to different types of solid-state drives and domestic IT innovation platforms, with strong practicality and promotional value.

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

[0174] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0175] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for testing the compatibility and reliability of a solid-state drive, characterized in that, The method includes: Initialize the test environment, install the operating system, write and execute test scripts, and configure the compilation environment; Identify and classify the basic information of solid-state drives (SSDs), write automated scripts, and use these scripts to create file clusters of different sizes, perform sequential / random read / write tests, and verify file integrity based on the classified SSD information. The Fio tool was used to perform performance tests on the basic information of the categorized solid-state drives and record the performance indicators of the solid-state drives, including sequential read and write speeds, random IOPS and response latency. An automated script was written to simulate database load and perform small-block random read and write operations. High-load read / write tests combined with mixed I / O stress tests were performed on the solid-state drive. During high-load read / write operations, random power-off tests were added to check the system startup status and file system integrity. Verify whether the encryption module of the solid-state drive complies with the security protocol standard, and verify the full-process secure boot mechanism in conjunction with the TPM chip to ensure that the solid-state drive has a complete security protection system in a multi-stress coupling environment; The test data from each stage is summarized, analyzed, and a test report for the solid-state drive is automatically generated. The test report includes performance trend charts, stability scores, security compliance conclusions, and timelines of abnormal events for the solid-state drive under different test scenarios.

2. The method for testing the compatibility and reliability of a solid-state drive according to claim 1, characterized in that, The steps of initializing the test environment, installing the operating system, writing and executing test scripts, and configuring the compilation environment include: On the target IT innovation platform, install at least two operating systems, deploy the script execution environment, and configure performance testing tools; Record the SSD identification, partitioning process, and driver loading during the installation process; Based on the existing driver interface of the solid-state drive, an interface for reading extended information of the internal SMART log of the solid-state drive and an interface for triggering firmware-specific debug modes are added. Write and execute test scripts, and configure the compilation environment.

3. The method for testing the compatibility and reliability of a solid-state drive according to claim 1, characterized in that, The steps of identifying and classifying basic information of solid-state drives (SSDs), writing automated scripts, and using these scripts to create file clusters of different sizes, perform sequential / random read / write tests, and verify file integrity based on the classified SSD information include: Use the commands lspci, lsblk, or fdisk -l to confirm the recognition of the solid-state drive; Use graphical disk tools and command-line tools to create partition table formats including MBR and GPT; Create file systems including ext4, xfs, and the domestic Taiji file system in at least two operating system environments; Write automated scripts to create file clusters of different sizes, perform sequential / random read / write tests, and verify file integrity based on the basic information of the categorized solid-state drives.

4. The method for testing the compatibility and reliability of a solid-state drive according to claim 1, characterized in that, The steps of using the Fio tool to perform performance tests on the basic information of the categorized solid-state drives (SSDs) and record their performance metrics, including sequential read / write speeds, random IOPS, and response latency, and writing automated scripts to simulate database load for small-block random read / write operations include: The Fio tool was used to perform performance tests on the categorized solid-state drives. Block sizes were set to 4KB, 64KB, and 1MB, and queue depths were set to 1, 2, 4, 8, and 16, respectively. Random read / write and sequential read / write tests were performed, and IOPS, throughput, and latency data were recorded. Run the script on at least two operating systems to compare the performance differences of the same solid-state drive under different operating systems and file systems. An automated script based on the Fio engine is used to automatically generate an I / O mode configuration file that simulates MySQL database OLTP transactions, and perform small random read and write operations and continuous execution for a specified time, while recording the performance fluctuation curve. By combining perf and iostat to collect system-level resource usage, the impact of IO scheduling strategies on performance is analyzed.

5. The method for testing the compatibility and reliability of a solid-state drive according to claim 1, characterized in that, The steps of performing high-load read / write tests on the solid-state drive combined with hybrid I / O stress tests, and randomly adding power-off tests during high-load read / write operations to check the system startup status and file system integrity, include: Set up a full partition environment and use the dd command to fill the file system to 95% capacity; In the full partition environment, a mixed IO stress test is continuously run for a preset time. The mixed IO stress test consists of sequential write, random write, and random read in a specific ratio. The system continuously runs for a preset time to simulate the IO load under real business scenarios. By writing a background monitoring script, the system reads the solid-state drive temperature at preset intervals using the command `smartctl -a / dev / sdX`, and executes the command `iostat -x 1 5` once at preset intervals to collect IO performance data, which is then recorded in a time-series database for subsequent consistency analysis. Set a preset number of loops and enter and wake up the test loop within the preset number of loops; During periods of high system load read / write, random power outage tests are performed to check the system startup status and file system integrity.

6. The method for testing the compatibility and reliability of a solid-state drive according to claim 1, characterized in that, The steps for verifying whether the encryption module of the solid-state drive (SSD) complies with security protocol standards, and combining this with the TPM chip verification of the entire secure boot mechanism, to ensure that the SSD has a complete security protection system under multi-stress coupling environments, include: By sending a query command to the solid-state drive, the list of encryption algorithms supported by the solid-state drive is obtained, and it is confirmed that it includes the Chinese national cryptographic algorithms SM2, SM3, and SM4. Using the gmssl toolset certified by the State Cryptography Administration, the encryption and decryption speed of the encrypted partition of the solid-state drive was tested using the sm4-ctr algorithm. Verify whether the encryption module of the solid-state drive complies with security protocol standards, and test the security of the TRIM command and the reliability of data erasure.

7. The method for testing the compatibility and reliability of a solid-state drive according to claim 1, characterized in that, The steps of summarizing test data from each stage, analyzing the test data from each stage, and automatically generating a test report for the solid-state drive (SSD), which includes performance trend charts, stability scores, security compliance conclusions, and anomaly timelines for the SSD under different test scenarios, include: The test data from each stage is summarized and a test report for the solid-state drive is automatically generated. The test report includes performance trend charts, stability scores, security compliance conclusions, and timelines of abnormal events for the solid-state drive under different test scenarios. Multi-dimensional screening and comparative analysis of test results determine whether they meet enterprise-level application requirements.

Images