Solid state drive testing method, device, equipment and readable storage medium

Abstract

A solid state disk test method, device, equipment and readable storage medium, the solid state disk test method comprises: controlling the first physical host to send instruction to the to-be-tested solid state disk, to create a shared namespace in the to-be-tested solid state disk, and enable the reservation function of the shared namespace; controlling the first physical host to send a write exclusive request to the shared namespace to the to-be-tested solid state disk; controlling the second physical host to send a read-write request to the shared namespace to the to-be-tested solid state disk; based on the read-write request result returned by the to-be-tested solid state disk to the second physical host, determining whether the write exclusive test of the to-be-tested solid state disk passes; or, controlling the first physical host to send a complete exclusive request to the shared namespace to the to-be-tested solid state disk; controlling the second physical host to send a read-write request to the shared namespace to the to-be-tested solid state disk. Through the present application, the reservation function of the solid state disk is comprehensively and effectively tested.

Description

Technical Field

[0001] This application relates to the field of hard disk testing technology, and in particular to a solid-state hard disk testing method, apparatus, device, and readable storage medium. Background Technology

[0002] As enterprise-level storage demands increasing availability and data consistency, dual-port solid-state drives (SSDs) are widely used in mission-critical scenarios. Dual-port SSDs support two independent data channels, meaning they can be connected to two different storage controllers or host systems simultaneously. If one controller or connection fails, the other controller or connection can still access the drive, ensuring data continuity and system stability.

[0003] Existing technologies typically use dedicated dual-port servers or create multiple virtual machines on a server to test dual-port SSDs. Dedicated servers are expensive, virtual machines cannot truly simulate the concurrent access behavior of two independent physical hosts, and existing technologies focus on testing the read and write performance of dual-port SSDs.

[0004] In summary, current testing of dual-port SSDs suffers from high costs, poor realism, and a lack of comprehensiveness and effectiveness. Summary of the Invention

[0005] This application provides a solid-state drive (SSD) testing method, apparatus, device, and readable storage medium, aiming to solve the technical problems of high cost, poor accuracy, and insufficient comprehensiveness and effectiveness in current testing of dual-port SSDs.

[0006] In a first aspect, embodiments of this application provide a solid-state drive (SSD) testing method. The physical interface of the SSD under test is connected to one end of a connecting device, and the other end of the connecting device is divided into two branches that are respectively connected to the physical interfaces of a first physical host and a second physical host. The SSD testing method includes: The first physical host is controlled to send instructions to the solid-state drive under test to create a shared namespace on the solid-state drive under test and enable the reservation function of the shared namespace. Control the first physical host to send a write exclusive request to the solid-state drive under test for the shared namespace; Control the second physical host to send read and write requests to the shared namespace to the solid-state drive under test; Based on the read and write request results returned by the solid-state drive under test to the second physical host, determine whether the write exclusive test of the solid-state drive under test has passed. Alternatively, control the first physical host to send a complete exclusive request for the shared namespace to the solid-state drive under test; Control the second physical host to send read and write requests to the shared namespace to the solid-state drive under test; Based on the read / write request results returned by the SSD under test to the second physical host, determine whether the full exclusive test of the SSD under test has passed.

[0007] Optionally, when the first physical host sends a write exclusive request to the solid-state drive under test, determining whether the write exclusive test of the solid-state drive under test passes based on the read / write request results returned by the solid-state drive under test to the second physical host includes: If the read / write request result returned by the solid-state drive under test to the second physical host is that the write request is rejected and the read request is allowed, then the write exclusive test of the solid-state drive under test is determined to be passed. When the first physical host sends a fully exclusive request to the solid-state drive under test, determining whether the fully exclusive test of the solid-state drive under test passes based on the read / write request results returned by the solid-state drive under test to the second physical host includes: If the read / write request results returned by the SSD under test to the second physical host are both rejected, then the full exclusive test of the SSD under test is determined to be passed.

[0008] Optionally, after determining that the full exclusivity test of the solid-state drive under test has passed, if the read / write request results returned by the solid-state drive under test to the second physical host are both write and read requests rejected, the following steps are included: Simulate a failure in the first physical host using multiple methods; Control the second physical host to send a full exclusive preemption request for the shared namespace to the solid-state drive under test; After the second physical host successfully completes the preemption request, the fault of the first physical host is eliminated, and the first physical host is controlled to send read and write requests to the solid-state drive under test for the shared namespace. Based on the read / write request results returned by the SSD under test to the first physical host, determine whether the takeover test after the SSD under test has passed.

[0009] Optionally, the various methods include: powering off the first physical host, disconnecting the first physical host from the connection device, simulating a network failure of the first physical host, uninstalling or disabling the driver for the non-volatile memory host controller interface specification of the first physical host, and triggering an operating system crash of the first physical host.

[0010] Optionally, the reserved function is based on the non-volatile memory host controller interface specification, and the control of the first physical host to send instructions to the solid-state drive under test includes: Command tools based on the non-volatile memory host controller interface specification are used to control the first physical host to send commands to the solid-state drive under test.

[0011] Optionally, before the first physical host sends a write exclusive request for the shared namespace to the solid-state drive under test, the following steps are included: Control the first and second physical hosts to send registration instructions for the shared namespace to the solid-state drive under test.

[0012] Secondly, embodiments of this application provide a solid-state drive (SSD) testing device. The physical interface of the SSD under test is connected to one end of a connecting device, and the other end of the connecting device is divided into two branches that are respectively connected to the physical interfaces of a first physical host and a second physical host. The SSD testing device includes: A module is created to control the first physical host to send instructions to the solid-state drive under test, so as to create a shared namespace on the solid-state drive under test and enable the reservation function of the shared namespace. The write exclusive request module is used to control the first physical host to send a write exclusive request to the solid-state drive under test for the shared namespace; The first read / write request module is used to control the second physical host to send read / write requests to the solid-state drive under test for the shared namespace. The first result determination module is used to determine whether the write exclusive test of the solid-state drive under test has passed based on the read and write request results returned by the solid-state drive under test to the second physical host. The full exclusive request module is used to control the first physical host to send a full exclusive request for the shared namespace to the solid-state drive under test. The second read / write request module is used to control the second physical host to send read / write requests to the solid-state drive under test for the shared namespace. The second result determination module is used to determine whether the full exclusive test of the solid-state drive under test has passed based on the read and write request results returned by the solid-state drive under test to the second physical host.

[0013] Optionally, when the first physical host sends a write exclusive request to the solid-state drive under test, the first result determination module is used for: If the read / write request result returned by the solid-state drive under test to the second physical host is that the write request is rejected and the read request is allowed, then the write exclusive test of the solid-state drive under test is determined to be passed. When the first physical host sends a fully exclusive request to the solid-state drive under test, the second result determination module is used for: If the read / write request results returned by the SSD under test to the second physical host are both rejected, then the full exclusive test of the SSD under test is determined to be passed.

[0014] Thirdly, this application provides a solid-state drive (SSD) testing device, which includes a processor, a memory, and an SSD testing program stored in the memory and executable by the processor. When the SSD testing program is executed by the processor, it implements the steps of the SSD testing method described above.

[0015] Fourthly, embodiments of this application provide a readable storage medium storing a solid-state drive (SSD) test program, wherein when the SSD test program is executed by a processor, it implements the steps of the SSD test method described above.

[0016] The beneficial effects of the technical solutions provided in this application include: In this embodiment, the system controls a first physical host to send instructions to the solid-state drive (SSD) under test (SSD) to create a shared namespace and enable the reservation function of the shared namespace; controls the first physical host to send a write exclusive request to the shared namespace to the SSD under test; controls the second physical host to send read and write requests to the shared namespace to the SSD under test; and determines whether the write exclusive test of the SSD under test has passed based on the read and write request results returned by the SSD under test to the second physical host; or, controls the first physical host to send a full exclusive request to the shared namespace to the SSD under test; controls the second physical host to send read and write requests to the shared namespace to the SSD under test; and determines whether the full exclusive test of the SSD under test has passed based on the read and write request results returned by the SSD under test to the second physical host. This application's embodiments connect a dual-port SSD to one end of a connection device, and two independent physical hosts to the other end via two branches. This simulates concurrent access to the dual-port SSD by multiple hosts in real-world business scenarios. Compared to dedicated servers, this significantly reduces costs. Compared to test schemes that create multiple virtual machines on a server, it avoids interference caused by resource sharing among multiple virtual machines, making test results closer to the actual deployment environment and improving test reliability. The SSD's reserved function is used to coordinate concurrent access to the shared namespace in a multi-host environment, avoiding data conflicts and improving the availability and stability of the SSD. Compared to existing technologies that focus on testing the read and write performance of dual-port SSDs, this invention designs a proprietary test process for the SSD's reserved function. The reserved function test is not limited to write exclusive or fully exclusive tests, but can also include preemption tests, etc. This invention provides a comprehensive and effective test for the SSD's reserved function in addition to traditional SSD read and write performance tests. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the first process of an embodiment of the solid-state drive testing method of this application; Figure 2 This is a schematic diagram of the connection device architecture of an embodiment of the solid-state drive testing method of this application; Figure 3 This is a second flowchart illustrating an embodiment of the solid-state drive testing method of this application; Figure 4 This is a schematic diagram of the third process of an embodiment of the solid-state drive testing method of this application; Figure 5 This is a functional module diagram of an embodiment of the solid-state drive testing device of this application; Figure 6 This is a schematic diagram of the hardware structure of the solid-state drive testing equipment involved in the embodiments of this application. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0020] In a first aspect, embodiments of this application provide a solid-state drive (SSD) testing method.

[0021] In one embodiment, the physical interface of the solid-state drive under test is connected to one end of the connection device, and the other end of the connection device is divided into two branches that are respectively connected to the physical interfaces of the first physical host and the second physical host, as shown in the figure. Figure 1 , Figure 1 This is a schematic diagram of the first process of an embodiment of the solid-state drive testing method of this application, as shown below. Figure 1 As shown, the solid-state drive (SSD) testing methods include: Step S10: Control the first physical host to send instructions to the solid-state drive under test to create a shared namespace in the solid-state drive under test and enable the reservation function of the shared namespace.

[0022] In this embodiment, an NVMe (Non-Volatile Memory Express) management tool (such as nvme-cli) on the first physical host can send a Namespace Management command to the solid-state drive under test to create a shared namespace, and send a Set Features command to enable the Reservation function of the namespace. (Refer to...) Figure 2 , Figure 2 This is a schematic diagram of the connection device architecture of an embodiment of the solid-state drive testing method of this application, as shown below. Figure 2 As shown, one end of the connection device matches the single physical interface of the solid-state drive (SSD), leading out the two independent signal channels within the interface to form two independent branches. These branches connect to the PCIe (Peripheral Component Interconnect Express) slots or interfaces of the first and second physical hosts, respectively, enabling point-to-point direct connection between the SSD's dual logical ports and the two physical hosts. This connection device supports PCIe link training and negotiation, maintaining the independent physical link attributes of the SSD's dual ports without introducing additional PCIe switching chips or bridging logic, thus ensuring signal integrity and protocol transparency in the test environment. By using a direct physical layer connection instead of virtual machine simulation, the link negotiation status of the dual-port SSD in a multi-host environment can be realistically reflected, laying a reliable physical foundation for subsequent reserved function testing and avoiding test interference caused by virtualization resource sharing.

[0023] Step S20: Control the first physical host to send a write exclusive request for the shared namespace to the solid-state drive under test.

[0024] In this embodiment, the first physical host and the second physical host are pre-registered. Based on the registered reserved key on the first physical host, a Reservation Acquire command is sent to the SSD under test, specifying the reservation type as Write Exclusive in the command parameters. At this time, the firmware of the SSD under test will lock the write permission of the shared namespace to the first physical host, while the read permission remains open. This step simulates the state of the master node normally holding the business lock in a cluster scenario, verifying whether the SSD correctly recognizes and executes the write exclusive reservation instruction, ensuring that only the holder can modify the data, thereby preventing data conflicts. Preferably, before the first physical host and the second physical host register and start the test, the nvme resv-report command can be used to query and confirm that there are no residual reserved registrations in the current namespace, avoiding inaccurate test results caused by residual registration keys and improving the accuracy of the test results.

[0025] Step S30: Control the second physical host to send read and write requests to the solid-state drive under test for the shared namespace.

[0026] In this embodiment, the second physical host, unaware of or ignoring the reserved state of the first physical host, attempts to send standard NVMe Write and Read commands to the same shared namespace. Since the connection device directly connects the second physical host to another port of the SSD under test, the request reaches the SSD controller via a separate physical link, thus realistically simulating the physical path of concurrent access from two ports. This step aims to create an access conflict scenario to verify whether the arbitration logic of the SSD firmware in the face of non-owner access requests meets expectations.

[0027] Step S40: Based on the read / write request results returned by the solid-state drive under test to the second physical host, determine whether the write exclusive test of the solid-state drive under test has passed.

[0028] In this embodiment, the test system corresponding to the test method can be equipped with monitoring devices in the first and second physical hosts to capture the completion queue entry received by the second physical host. If the write command returns a Reservation Conflict status code while the read command completes successfully, it indicates that the solid-state drive (SSD) correctly executed the write exclusive logic. This verifies the data consistency protection mechanism of the SSD in a multi-host environment, avoids the risk of data corruption caused by concurrent writes, and ensures the business availability of non-owners in read-only scenarios, conforming to the NVMe protocol's specification definition for write exclusive reservation types.

[0029] Step S50, or, control the first physical host to send a complete exclusive request for the shared namespace to the solid-state drive under test.

[0030] In this embodiment, as another test branch, the first physical host sends a Reservation Acquire command, specifying the reservation type as Exclusive Access. Unlike write exclusive access, in Exclusive Access mode, the SSD firmware will simultaneously lock read and write permissions. This is suitable for testing scenarios with extremely high data consistency requirements and where no concurrent reads are allowed. By switching the reservation type, this solution can cover the permission control needs under different business scenarios, improving the comprehensiveness of the test.

[0031] Step S60: Control the second physical host to send read and write requests for the shared namespace to the solid-state drive under test.

[0032] In this embodiment, the second physical host attempts to send read / write requests again. At this point, due to the presence of a full exclusive lock, the SSD controller should block all access requests from non-holders. This step aims to verify the SSD's access control capabilities under the strictest reservation policy, ensuring that even in critical business scenarios, read requests will not leak data or cause state inconsistencies, further enhancing the depth of the test.

[0033] Step S70: Based on the read / write request results returned by the solid-state drive under test to the second physical host, determine whether the full exclusive test of the solid-state drive under test has passed.

[0034] In this embodiment, if both the write and read requests received by the second physical host return a ReservationConflict status code, the full exclusive test is considered passed. This indicates that the solid-state drive (SSD) strictly adheres to the definition of full exclusive reservation in the NVMe protocol, ensuring data security in extreme scenarios. By comparing the test results of write exclusive and full exclusive reservations, the logical integrity of the SSD's reservation function can be comprehensively evaluated, filling the gap in existing technologies that only focus on performance testing while neglecting protocol compliance verification.

[0035] In this embodiment, one end of the connection device matches the single physical interface of the solid-state drive (SSD), leading out the two independent signal channels within the interface to form two independent branches. These branches connect to the PCIe slots or interfaces of the first and second physical hosts, respectively, enabling point-to-point direct connection between the SSD's dual logical ports and the two physical hosts. This direct physical connection, rather than virtual machine simulation, accurately reflects the link negotiation state of the dual-port SSD in a multi-host environment, providing a reliable physical foundation for subsequent reserved function testing and avoiding test interference caused by virtualization resource sharing. Compared to dedicated servers, this significantly reduces costs. Compared to test schemes that create multiple virtual machines on a server, it avoids interference caused by resource sharing among multiple virtual machines, making the test results closer to the actual deployment environment and improving test reliability. A dedicated test process is designed for the SSD's reserved function. By comparing the test results of write-exclusive and fully exclusive functions, the logical integrity of the SSD's reserved function can be comprehensively evaluated, filling the gap in existing technologies that only focus on performance testing while neglecting protocol compliance verification.

[0036] Furthermore, in one embodiment, when the first physical host sends a write exclusive request to the solid-state drive under test, step S40 includes: If the read / write request result returned by the solid-state drive under test to the second physical host is that the write request is rejected and the read request is allowed, then the write exclusive test of the solid-state drive under test is determined to be passed. When the first physical host sends a fully exclusive request to the solid-state drive under test, step S70 includes: If the read / write request results returned by the SSD under test to the second physical host are both rejected, then the full exclusive test of the SSD under test is determined to be passed.

[0037] In this embodiment, refer to Figure 3 , Figure 3 This is a second flowchart illustrating an embodiment of the solid-state drive testing method of this application, as shown below. Figure 3 As shown, in a Write Exclusive (WE) request, the test passes when the write request is rejected and the read request is allowed; in an Exclusive Access (EA) request, the test passes when both the write and read requests are rejected. By parsing the status code fields defined in the NVMe protocol, it is possible to accurately determine whether a request is rejected or accepted. This protocol status code-based determination method is objective and standardized, avoiding potential errors from application-layer log analysis, and improving the accuracy and repeatability of test results. Furthermore, the clear pass / fail criteria enable automated testing processes, significantly improving testing efficiency.

[0038] Further, in one embodiment, after determining that the full exclusivity test of the solid-state drive under test has passed if the read / write request results returned by the solid-state drive under test to the second physical host are both write and read requests rejected, the process includes: Simulate a failure in the first physical host using multiple methods; Control the second physical host to send a full exclusive preemption request for the shared namespace to the solid-state drive under test; After the second physical host successfully completes the preemption request, the fault of the first physical host is eliminated, and the first physical host is controlled to send read and write requests to the solid-state drive under test for the shared namespace. Based on the read / write request results returned by the SSD under test to the first physical host, determine whether the takeover test after the SSD under test has passed.

[0039] In this embodiment, refer to Figure 4 , Figure 4 This is a schematic diagram of the third process of an embodiment of the solid-state drive testing method of this application, as shown below. Figure 4 As shown, after the SSD passed the Exclusive Access (EA) test, the first physical host ( Figure 4 The second physical host (Host B) performs fault simulation. Figure 4 Host A sends a Reservation Acquire command with a Preempt action, carrying the key of the first physical host as the preemption target. When the SSD detects that the original holder is unreachable or according to the preemption policy, it cancels the original key and transfers the reservation right to the second physical host. The criterion for the second physical host to fully exclusively preempt the request is: a query showing that the preemption command was executed successfully and that the reservation holder has changed to the second physical host. Subsequently, the first physical host is restored, and it is controlled to send read and write requests to the SSD under test for the shared namespace. Verification shows that if the request is rejected, the preemption is effective and the permissions have been correctly transferred. This verifies the ability of the backup node in the high-availability cluster to take over services, ensuring system continuity under single-point failures and demonstrating the advantages of this solution in fault scenario testing.

[0040] Furthermore, in one embodiment, the multiple methods include: powering off the first physical host, disconnecting the first physical host from the connection device, simulating a network failure of the first physical host, uninstalling or disabling the driver of the non-volatile memory host controller interface specification of the first physical host, and triggering an operating system crash of the first physical host.

[0041] In this embodiment, diverse fault simulation methods cover anomalies at the hardware layer (power failure, disconnection), driver layer (driver uninstallation), and system layer. Compared to existing technologies that only focus on logic layer testing, this solution can more comprehensively expose firmware behavior defects of SSDs under real physical failures, improving the coverage and depth of testing. By simulating various faults that may occur in real business scenarios, it ensures that the SSD has sufficient robustness in actual deployment environments.

[0042] Furthermore, in one embodiment, the reserved function is based on the Non-Volatile Memory Host Controller Interface Specification, and the step of controlling the first physical host to send instructions to the solid-state drive under test includes: Command tools based on the non-volatile memory host controller interface specification are used to control the first physical host to send commands to the solid-state drive under test.

[0043] In this embodiment, standardized NVMe command tools are used to send instructions, eliminating the need for customized, expensive dedicated test hardware. This not only lowers the testing threshold but also makes the test scripts easy to port and maintain, demonstrating the advantages of this solution in terms of low cost and ease of implementation. The implementation based on general-purpose tools allows this method to be widely applied to the testing of solid-state drives from different manufacturers, exhibiting good compatibility and promotional value.

[0044] Further, in one embodiment, before step S20, the following steps are included: Control the first and second physical hosts to send registration instructions for the shared namespace to the solid-state drive under test.

[0045] In this embodiment, before reserving and acquiring the key, both the first and second physical hosts first perform a Register operation to write the key. This is a necessary prerequisite for the NVMe Reservation protocol, ensuring the legitimacy of the host identity. The explicit registration step ensures that the testing process conforms to the protocol specifications, avoiding invalid tests due to skipping the registration step. This step ensures the correctness of the reserved key management, providing an authentication foundation for subsequent reservation acquisition and preemption operations.

[0046] Secondly, embodiments of this application also provide a solid-state drive testing device.

[0047] In one embodiment, the physical interface of the solid-state drive under test is connected to one end of the connection device, and the other end of the connection device is divided into two branches that are respectively connected to the physical interfaces of the first physical host and the second physical host, as shown in the figure. Figure 5 , Figure 5 This is a functional module diagram of an embodiment of the solid-state drive testing device of this application, as shown below. Figure 5 As shown, the solid-state drive testing device includes: Create module 10 to control the first physical host to send instructions to the solid-state drive under test to create a shared namespace in the solid-state drive under test and enable the reservation function of the shared namespace. The write exclusive request module 20 is used to control the first physical host to send a write exclusive request to the solid-state drive under test for the shared namespace. The first read / write request module 30 is used to control the second physical host to send read / write requests to the solid-state drive under test for the shared namespace. The first result determination module 40 is used to determine whether the write exclusive test of the solid-state drive under test has passed based on the read and write request results returned by the solid-state drive under test to the second physical host. The full exclusive request module 50 is used to control the first physical host to send a full exclusive request for the shared namespace to the solid-state drive under test. The second read / write request module 60 is used to control the second physical host to send read / write requests to the solid-state drive under test for the shared namespace. The second result determination module 70 is used to determine whether the full exclusive test of the solid-state drive under test has passed based on the read and write request results returned by the solid-state drive under test to the second physical host.

[0048] Furthermore, in one embodiment, when the first physical host sends a write exclusive request to the solid-state drive under test, the first result determination module 40 is used to: If the read / write request result returned by the solid-state drive under test to the second physical host is that the write request is rejected and the read request is allowed, then the write exclusive test of the solid-state drive under test is determined to be passed. When the first physical host sends a fully exclusive request to the solid-state drive under test, the second result determination module 70 is used for: If the read / write request results returned by the SSD under test to the second physical host are both rejected, then the full exclusive test of the SSD under test is determined to be passed.

[0049] Furthermore, in one embodiment, the solid-state drive testing apparatus further includes a fault simulation module, used for: Simulate a failure in the first physical host using multiple methods; Control the second physical host to send a full exclusive preemption request for the shared namespace to the solid-state drive under test; After the second physical host successfully completes the preemption request, the fault of the first physical host is eliminated, and the first physical host is controlled to send read and write requests to the solid-state drive under test for the shared namespace. Based on the read / write request results returned by the SSD under test to the first physical host, determine whether the takeover test after the SSD under test has passed.

[0050] Furthermore, in one embodiment, the multiple methods include: powering off the first physical host, disconnecting the first physical host from the connection device, simulating a network failure of the first physical host, uninstalling or disabling the driver of the non-volatile memory host controller interface specification of the first physical host, and triggering an operating system crash of the first physical host.

[0051] Furthermore, in one embodiment, the reserved function is based on the Non-Volatile Memory Host Controller Interface Specification, and the step of controlling the first physical host to send instructions to the solid-state drive under test includes: Command tools based on the non-volatile memory host controller interface specification are used to control the first physical host to send commands to the solid-state drive under test.

[0052] Furthermore, in one embodiment, the solid-state drive testing apparatus further includes a registration module, used for: Control the first and second physical hosts to send registration instructions for the shared namespace to the solid-state drive under test.

[0053] The functions of each module in the above-mentioned solid-state drive testing device correspond to the steps in the above-mentioned solid-state drive testing method embodiment, and their functions and implementation processes will not be described in detail here.

[0054] Thirdly, embodiments of this application provide a solid-state drive testing device.

[0055] Reference Figure 6 , Figure 6 This is a schematic diagram of the hardware structure of the solid-state drive testing device involved in the embodiments of this application. In the embodiments of this application, the solid-state drive testing device may include a processor, a memory, a communication interface, and a communication bus.

[0056] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0057] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting devices within the solid-state drive (SSD) test equipment, as well as interfaces used for interconnecting the SSD test equipment with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0058] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0059] The processor can be a general-purpose processor, which can call the solid-state drive (SSD) test program stored in the memory and execute the SSD test method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the SSD test program is called can be referred to in the various embodiments of the SSD test method of this application, and will not be repeated here.

[0060] Those skilled in the art will understand that Figure 6 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0061] Fourthly, embodiments of this application also provide a readable storage medium.

[0062] The present application has a solid-state drive test program stored on a readable storage medium, wherein when the solid-state drive test program is executed by a processor, it implements the steps of the solid-state drive test method described above.

[0063] The method implemented when the solid-state drive test program is executed can be referred to in the various embodiments of the solid-state drive test method of this application, and will not be repeated here.

[0064] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0065] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application 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 listed steps or units, 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. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0066] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0067] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0068] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0069] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

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

Claims

1. A solid-state drive testing method, characterized in that, The physical interface of the solid-state drive under test is connected to one end of a connecting device, and the other end of the connecting device is divided into two branches that are respectively connected to the physical interfaces of a first physical host and a second physical host. The solid-state drive testing method includes: The first physical host is controlled to send instructions to the solid-state drive under test to create a shared namespace on the solid-state drive under test and enable the reservation function of the shared namespace. Control the first physical host to send a write exclusive request to the solid-state drive under test for the shared namespace; Control the second physical host to send read and write requests to the shared namespace to the solid-state drive under test; Based on the read and write request results returned by the solid-state drive under test to the second physical host, determine whether the write exclusive test of the solid-state drive under test has passed. Alternatively, control the first physical host to send a complete exclusive request for the shared namespace to the solid-state drive under test; Control the second physical host to send read and write requests to the shared namespace to the solid-state drive under test; Based on the read / write request results returned by the SSD under test to the second physical host, determine whether the full exclusive test of the SSD under test has passed.

2. The solid-state drive testing method as described in claim 1, characterized in that, When the first physical host sends a write exclusive request to the solid-state drive under test, determining whether the write exclusive test of the solid-state drive under test passes based on the read / write request results returned by the solid-state drive under test to the second physical host includes: If the read / write request result returned by the solid-state drive under test to the second physical host is that the write request is rejected and the read request is allowed, then the write exclusivity test of the solid-state drive under test is determined to be passed. When the first physical host sends a fully exclusive request to the solid-state drive under test, determining whether the fully exclusive test of the solid-state drive under test passes based on the read / write request results returned by the solid-state drive under test to the second physical host includes: If the read / write request results returned by the SSD under test to the second physical host are both rejected, then the full exclusive test of the SSD under test is determined to be passed.

3. The solid-state drive testing method as described in claim 2, characterized in that, After determining that the full exclusivity test of the SSD under test has passed, if the read / write request results returned by the SSD under test to the second physical host are both rejected (write request and read request are both rejected), the process includes: Simulate a failure in the first physical host using multiple methods; Control the second physical host to send a full exclusive preemption request for the shared namespace to the solid-state drive under test; After the second physical host successfully completes the preemption request, the fault of the first physical host is eliminated, and the first physical host is controlled to send read and write requests to the solid-state drive under test for the shared namespace. Based on the read / write request results returned by the SSD under test to the first physical host, determine whether the takeover test after the SSD under test has passed.

4. The solid-state drive testing method as described in claim 3, characterized in that, The various methods include: powering off the first physical host, disconnecting the first physical host from the connection device, simulating a network failure of the first physical host, uninstalling or disabling the driver for the non-volatile memory host controller interface specification of the first physical host, and triggering an operating system crash of the first physical host.

5. The solid-state drive testing method as described in claim 1, characterized in that, The reserved function is based on the non-volatile memory host controller interface specification, and the control of the first physical host to send instructions to the solid-state drive under test includes: Command tools based on the non-volatile memory host controller interface specification are used to control the first physical host to send commands to the solid-state drive under test.

6. The solid-state drive testing method as described in claim 1, characterized in that, Before the first physical host sends a write exclusive request for the shared namespace to the solid-state drive under test, the process includes: Control the first and second physical hosts to send registration instructions for the shared namespace to the solid-state drive under test.

7. A solid-state drive testing device, characterized in that, The physical interface of the solid-state drive under test is connected to one end of a connecting device, and the other end of the connecting device is divided into two branches that are respectively connected to the physical interfaces of a first physical host and a second physical host. The solid-state drive testing device includes: A module is created to control the first physical host to send instructions to the solid-state drive under test, so as to create a shared namespace on the solid-state drive under test and enable the reservation function of the shared namespace. The write exclusive request module is used to control the first physical host to send a write exclusive request to the solid-state drive under test for the shared namespace. The first read / write request module is used to control the second physical host to send read / write requests to the solid-state drive under test for the shared namespace. The first result determination module is used to determine whether the write exclusive test of the solid-state drive under test has passed based on the read and write request results returned by the solid-state drive under test to the second physical host. The full exclusive request module is used to control the first physical host to send a full exclusive request for the shared namespace to the solid-state drive under test. The second read / write request module is used to control the second physical host to send read / write requests to the solid-state drive under test for the shared namespace. The second result determination module is used to determine whether the full exclusive test of the solid-state drive under test has passed based on the read and write request results returned by the solid-state drive under test to the second physical host.

8. The solid-state drive testing apparatus as described in claim 7, characterized in that, When the first physical host sends a write exclusive request to the solid-state drive under test, the first result determination module is used for: If the read / write request result returned by the solid-state drive under test to the second physical host is that the write request is rejected and the read request is allowed, then the write exclusivity test of the solid-state drive under test is determined to be passed. When the first physical host sends a fully exclusive request to the solid-state drive under test, the second result determination module is used for: If the read / write request results returned by the SSD under test to the second physical host are both rejected, then the full exclusive test of the SSD under test is determined to be passed.

9. A solid-state drive testing device, characterized in that, The solid-state drive testing device includes a processor, a memory, and a solid-state drive testing program stored in the memory and executable by the processor, wherein when the solid-state drive testing program is executed by the processor, it implements the steps of the solid-state drive testing method as described in any one of claims 1 to 6.

10. A readable storage medium, characterized in that, The readable storage medium stores a solid-state drive (SSD) test program, wherein when the SSD test program is executed by a processor, it implements the steps of the SSD test method as described in any one of claims 1 to 6.

Images