Test method of storage device, related device and storage medium

Abstract

The application discloses a storage device testing method, a related device and a storage medium. The storage device testing method comprises the following steps: obtaining a test script; wherein the test script is obtained by embedding an SGL database into a test command; and transmitting the test command to the storage device by using an SGL data transmission mode through a driving unit based on the test script, so as to test the storage device. The above scheme can realize SGL testing of the storage device, avoid hardware conditions, and thus improve the flexibility and portability of SGL automatic testing.

Description

Technical Field

[0001] This application relates to the field of storage technology, and in particular to a testing method, related equipment, and storage medium for a storage device. Background Technology

[0002] When testing NVMe SSDs (solid-state drives), traditional testing tools are heavily relied upon, such as fio, nvme-cli, dnvme, and other commercial tools.

[0003] However, these tools either do not support SGL (Scatter-Gather List) testing, or they require specific hardware to perform SGL testing.

[0004] This results in significant limitations for SGL testing, making it impossible to promote its widespread use. Summary of the Invention

[0005] The main technical problem addressed by this application is to provide a testing method, related equipment, and storage medium for storage devices, in order to overcome the limitations of SGL testing.

[0006] To address the aforementioned issues, this application provides a method for testing a storage device, comprising: obtaining a test script; wherein the test script is obtained by embedding an SGL database into a test command; and transmitting the test command to the storage device via a driver unit using the SGL data transfer mode based on the test script, in order to test the storage device.

[0007] Specifically, based on the test script, the driver unit uses the SGL data transfer mode to transmit test commands to the storage device for testing. This includes: obtaining the test commands in the test script; generating a cache area corresponding to the test commands through the SGL database based on the test commands; converting the virtual address of the cache area to a physical address through the driver unit, and generating an SGL descriptor based on the physical address and address length; and sending the SGL descriptor to the storage device for testing.

[0008] The process of sending an SGL descriptor to a storage device for testing includes: in response to a test command being a data read command, sending the SGL descriptor of the data read command to the storage device; receiving the read data returned by the storage device based on the SGL descriptor of the data read command; storing the read data in a cache area to detect whether the read data matches the data read command, thereby obtaining the read test result of the storage device.

[0009] The process of sending an SGL descriptor to a storage device for testing includes: responding to a test command as a data write command, storing the write data of the data write command in a cache area; sending the write data and the SGL descriptor of the data write command to the storage device, so that the storage device can retrieve the write data from the cache area and store it based on the SGL descriptor of the data write command; receiving write feedback data returned by the storage device based on the SGL descriptor of the data write command; and determining the write test result of the storage device based on the write feedback data.

[0010] The process of generating a cache area corresponding to a test command from the SGL database based on the test command includes: calculating the data size of the test data corresponding to the test command from the SGL database; and determining a cache area with the same data size as the test data from the empty memory area of ​​the SGL database.

[0011] The process of determining a cache region with the same data size as the test data from the blank memory region of the SGL database includes: in response to the existence of a contiguous memory region in the blank memory region that is larger than the data size of the test data, dividing the memory region into a contiguous cache region with the same data size as the test data; and in response to the absence of a contiguous memory region in the blank memory region that is larger than the data size of the test data, selecting and combining multiple discrete blank memory regions as cache regions based on the data size of the test data.

[0012] The process of generating an SGL descriptor based on the physical address and address length also includes: responding to a test command as a local read instruction for the target data; generating an SGL descriptor based on the physical address and address length of the target data, and marking the area in the SGL descriptor outside the area corresponding to the local read instruction with a data filter character, so that the storage device can perform data read filtering based on the data filter character.

[0013] Among them, the types of SGL descriptors include single-chain descriptors; generating SGL descriptors based on physical addresses and address lengths includes: generating single-chain descriptors that include multiple data segment descriptors based on physical addresses and address lengths, wherein the last descriptor among the multiple data segment descriptors is an address descriptor to identify the end of the single-chain descriptor.

[0014] The SGL descriptor types include multi-chain descriptors; generating SGL descriptors based on physical addresses and address lengths includes: generating multi-chain descriptors that include multiple chain descriptors based on physical addresses and address lengths; wherein the last descriptor in each chain descriptor is an address descriptor, pointing to the next chain descriptor or marking the end of the multi-chain descriptor.

[0015] The test commands include various error injection commands; the testing of the storage device also includes: receiving feedback data sent by the storage device based on the error injection commands; determining whether the feedback data matches the error type corresponding to the error injection command; if the feedback data matches the error type corresponding to the error injection command, determining that the storage device has error detection capability; if the feedback data does not match the error type corresponding to the error injection command, determining that the storage device does not have error detection capability.

[0016] To address the aforementioned technical problems, the present invention also provides a testing device comprising: a driver unit, a storage unit, and an interface unit; the driver unit is used to transmit test commands to the storage device based on a test script using the SGL data transmission mode, for testing the storage device; the storage unit is used to store the test script, wherein the test script is obtained by embedding an SGL database into the test commands; the interface unit is used to connect the driver unit and the storage unit, and to connect the driver unit and the storage device.

[0017] To address the aforementioned technical problems, the present invention also provides an electronic device, including a memory and a processor coupled to each other, wherein the processor is used to execute program instructions stored in the memory to implement a testing method for a storage device as described above.

[0018] To address the aforementioned technical problems, the present invention also provides a computer-readable storage medium having program instructions stored thereon, wherein the program instructions, when executed by a processor, implement a testing method for a storage device as described above.

[0019] The beneficial effects of this invention are as follows: Unlike the prior art, this application obtains a test script and, based on the test script, uses the SGL data transmission mode through the driver unit to transmit test commands to the storage device for testing. The test script is obtained by embedding an SGL database into the test commands, thereby endowing the test commands with SGL functionality using the SGL database. This enables the driver unit to support transmitting test commands with SGL functionality to the storage device via the SGL data transmission mode, thus achieving SGL testing of the storage device, bypassing hardware limitations, and improving the flexibility and portability of automated SGL testing, as well as expanding the applicability of SGL testing. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating an embodiment of the testing method for the storage device of this application;

[0021] Figure 2 This is a flowchart illustrating another embodiment of the testing method for the storage device of this application;

[0022] Figure 3 This is a schematic diagram of one implementation method of the cache area;

[0023] Figure 4 This is a schematic diagram of another implementation of the cache area;

[0024] Figure 5 This is a schematic diagram of an implementation of an SGL descriptor marked with data filter characters;

[0025] Figure 6 This is a flowchart illustrating one embodiment of a storage device being tested;

[0026] Figure 7 This is a schematic diagram of the framework of an embodiment of the test equipment of this application;

[0027] Figure 8 This is a schematic diagram of the framework of an embodiment of the electronic device of this application;

[0028] Figure 9 This is a schematic diagram of a framework of an embodiment of the computer-readable storage medium of this application. Detailed Implementation

[0029] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0030] In the following description, specific details such as particular system architectures, interfaces, and technologies are presented for illustrative purposes rather than for limiting purposes, in order to provide a thorough understanding of this application.

[0031] In this paper, the terms "system" and "network" are often used interchangeably. The term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, "many" in this paper means two or more.

[0032] Please see Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the testing method for the storage device according to this application. The testing method for the storage device in this embodiment specifically includes the following steps:

[0033] Step S11: Obtain the test script, which is obtained by embedding the SGL database into the test command.

[0034] Test scripts instruct the host on the specific test steps and content for the storage device. A test script may include specific configurations such as test commands, start and end addresses of the test data, test data size, test mode, queue depth, etc.

[0035] In the automated testing of storage devices, the host connects to the storage device and can invoke multiple test scripts to perform various tests on the storage device to verify its performance. Storage devices include, but are not limited to, hard drives, solid-state drives, external hard drives, USB flash drives, memory cards, non-volatile memory (NAND flash), or optical discs, etc.

[0036] In this embodiment, the test script is obtained by embedding the SGL database into the test command. The test command is a test command set according to the test requirements in the automated testing of storage devices.

[0037] SGL database is a database system optimized based on SGL (Scatter-Gather List) technology, which can efficiently handle non-contiguous memory data (such as scattered cache pages or memory blocks).

[0038] In a specific application scenario, the test script is obtained by embedding the SGL database into the test command. Specifically, the SGL database is provided to the test command for invocation, thereby enabling the test command to have SGL functionality and form the test script.

[0039] Step S12: Based on the test script, the test command is transmitted to the storage device through the driver unit using the SGL data transfer mode to test the storage device.

[0040] After the host obtains the test script, it uses the SGL data transfer mode to transmit the test commands to the storage device through the driver unit based on the test script in order to test the storage device.

[0041] The driver unit is a kernel module written in a programming language. It is responsible for interacting directly with the hardware. As a bridge between the hardware (NVMe SSD) and the operating system and testing software, the driver unit is responsible for core functions such as data transmission, command execution, and error handling.

[0042] SGL data transfer mode refers to the transfer of data based on the SGL format—combining non-contiguous memory regions into a logically contiguous memory block, thereby reducing memory copy operations and improving efficiency during data transfer.

[0043] Since the test commands are embedded in the SGL database, the host can call the SGL database when executing the test commands to enable the test commands to have SGL functionality, without the need for hardware to participate in the implementation of SGL functionality. This improves the flexibility and portability of SGL automated testing and expands the applicability of SGL testing.

[0044] Through the above steps, the storage device testing method of this embodiment includes: obtaining a test script, and transmitting test commands to the storage device through the driver unit using the SGL data transfer mode based on the test script to test the storage device. The test script is obtained by embedding an SGL database into the test commands, thereby giving the test commands SGL functionality using the SGL database. This enables the driver unit to support transmitting test commands with SGL functionality to the storage device through the SGL data transfer mode, thereby realizing SGL testing of the storage device, bypassing hardware limitations, and improving the flexibility and portability of SGL automated testing, as well as expanding the applicability of SGL testing.

[0045] Please see Figure 2 , Figure 2 This is a flowchart illustrating another embodiment of the testing method for the storage device according to this application. The testing method for the storage device in this embodiment specifically includes the following steps:

[0046] Step S21: Obtain the test script; wherein, the test script is obtained by embedding the SGL database into the test command.

[0047] This step is the same as step S11 in the aforementioned embodiment, please refer to the previous text, and will not be repeated here.

[0048] Step S22: Obtain the test commands in the test script, and generate the corresponding cache area for the test commands through the SGL database based on the test commands.

[0049] The test command in the test script is obtained. Based on the specific command content, a blank memory block is searched in the SGL database and used as the buffer area corresponding to the test command. The buffer area is then used to store the test data required by the test script.

[0050] In a specific application scenario, the size of the test data corresponding to the test command can be calculated using the SGL database; a cache area of ​​the same size as the test data can then be allocated from the empty memory area of ​​the SGL database. For example, if the SGL database calculates that the size of the test data corresponding to the test command is 32KB, then a 32KB cache area is determined from the empty memory area of ​​the SGL database. If the SGL database calculates that the size of the test data corresponding to the test command is 8KB, then an 8KB cache area is determined from the empty memory area of ​​the SGL database.

[0051] Generating a cache area corresponding to test commands using the SGL database can improve the effective utilization of the cache area and reduce the occurrence of invalid memory usage.

[0052] In a specific application scenario, in response to the existence of a contiguous memory region in the blank memory region that is larger than the size of the test data, a contiguous cache region of the same size as the test data is partitioned from the memory region; that is, when the contiguous memory region in the blank memory region is large enough to include the entire test data, a contiguous cache region of the same size as the test data is directly partitioned from the memory region.

[0053] Please see Figure 3 , Figure 3 This is a schematic diagram of one implementation method of the cache area.

[0054] In this embodiment, if the test data size is 8K, a continuous 8K cache area 31 is determined from the blank memory area 30 of the SGL database.

[0055] The above method can store all test data in a cache area, thereby reducing the number of times test data is stored. Only one storage operation is needed to completely store the test data, and the number of address descriptors in the test data stored in the cache area is reduced to only one address descriptor. This reduces the number of storage operations and the amount of stored data, thereby reducing the complexity of automated testing.

[0056] In another specific application scenario, in response to the absence of a contiguous memory region larger than the test data size within the blank memory region, multiple discrete blank memory regions are selected as cache regions based on the test data size. When the contiguous memory region within the blank memory region is insufficient to encompass the entire test data, multiple discrete blank memory regions are pieced together to form a cache region.

[0057] Please see Figure 4 , Figure 4 This is a schematic diagram of another implementation of the cache area.

[0058] In this embodiment, if the test data size is 32K, and the contiguous memory in the blank memory region 40 includes: 2K, 1K, 5K, 10K, 3K, 5K, 8K, 2K, 2K; then multiple discrete blank memory regions 10K+5K+5K+8K+2K+2K=32K are pieced together to form the cache region 41. This allows the storage needs of the test commands to be met through non-contiguous discrete memory, thereby improving the overall memory utilization efficiency.

[0059] Step S23: The virtual address of the cache region is converted into a physical address through the driver unit, and an SGL descriptor is generated based on the physical address and the address length.

[0060] The driver unit maps the virtual address of the cache region to the DMA physical address, and generates an SGL descriptor based on the physical address and address length. The SGL descriptor is used to implement the SGL data transfer mode between the host and the storage device.

[0061] Each SGL descriptor describes a memory block, containing its address, length, and type. The driver unit traverses all memory blocks corresponding to the cache region, forming one or more SGL descriptors.

[0062] SGL descriptors come in two structures: singly linked and multi-linked. Singly linked descriptors are described using the Last Segment Descriptor, while multi-linked descriptors are described using the next Segment Descriptor. The choice between singly and multi-linked descriptor types is arbitrary and based on actual needs; no restrictions are imposed here.

[0063] In a specific application scenario, a singly linked list of descriptors, comprising multiple data segment descriptors, can be generated based on the physical address and address length. The last descriptor in this list is the Last Segment address descriptor, which marks the end of the singly linked list. The Last Segment address descriptor describes the last data segment: it contains the address and length information of the last data segment. The data segment descriptor includes both data descriptors and address descriptors.

[0064] The Last Segment address descriptor format can include: address (DMA address of the last data segment), length (length of the last data segment), and type (sets the Last Segment type flag).

[0065] When all data blocks can be described by a single SGL descriptor, a single-chain descriptor is used, i.e., the LastSegment address descriptor identifies the end of the chain.

[0066] In a specific application scenario, a multi-chain descriptor can be generated based on the physical address and address length, comprising multiple chained descriptors. The last descriptor in each chain is an address descriptor, pointing to the next chain descriptor or marking the end of the multi-chain descriptor. Each chain descriptor contains multiple data segment descriptors, which include both data descriptors and address descriptors.

[0067] Assuming there are three descriptor chains, the last descriptor segment of the first chain is an address descriptor pointing to the second chained descriptor. The last descriptor segment of the second chain is also an address descriptor pointing to the third chained descriptor. The last descriptor segment of the third chain is also an address descriptor, marking the end of the multi-chained descriptor system. This example is for illustrative purposes only and is not a limitation. In practical applications, the number of chains in a multi-chained descriptor system can be 2, 3, 5, 7, 9, 10, 20, 50, or 80, etc., which is not limited here. Specifically, the address descriptors in this multi-chained descriptor system can include multiple next segment descriptors plus one last segment descriptor.

[0068] In a specific application scenario, if the number of memory blocks exceeds the limit of a single SGL descriptor, multiple lists can be linked in a nested manner using Next Segment address descriptors. However, since this embodiment is for performance testing of storage devices, in some test scenarios, even if the number of memory blocks does not exceed the limit of a single SGL descriptor, multi-chained descriptors can be used to describe them, thereby increasing the complexity of the SGL descriptors and testing the storage device's ability to handle complex SGL descriptors.

[0069] In a specific application scenario, in response to a test command, a partial read instruction for the target data is generated; an SGL descriptor is generated based on the physical address and address length of the target data, and the area in the SGL descriptor other than the area corresponding to the partial read instruction is marked with a data filter (bit bucket) so that the storage device can filter data read based on the data filter.

[0070] Assuming the target data is located at page 5-page 9, but the local read instruction only reads page 5-page 7, the region corresponding to page 8-page 9 on the SGL descriptor can be marked with a data filter character. This allows the local data of the target data to be obtained from the storage device with only one SGL descriptor command, reducing the number of command commands issued and improving testing efficiency.

[0071] Please see Figure 5 , Figure 5 This is a schematic diagram of an implementation of an SGL descriptor marked with data filter characters.

[0072] Figure 5 In (5a), the first SGL descriptor 51 is set with a first data filter 501.

[0073] Figure 5In (5b), the second SGL descriptor 52 has multiple second data filter characters 502.

[0074] Figure 5 The edge of the third SGL descriptor 53 in (5c) is set with a third data filter 503.

[0075] The specific settings for data filters are only provided as examples and are not limited here.

[0076] Step S24: Send the SGL descriptor to the storage device to test the storage device.

[0077] Sending SGL descriptors to the storage device allows for testing not only the test commands but also the storage device's ability to parse SGL descriptors, thus improving the comprehensiveness of the storage device test and ultimately enhancing the reliability of the tested storage devices. The SGL data transfer model refers to transmitting test commands to the storage device in the form of SGL descriptors.

[0078] In a specific application scenario, in response to a test command that is a data read command, the SGL descriptor of the data read command is sent to the storage device; the read data returned by the storage device based on the SGL descriptor of the data read command is received; the read data is stored in the cache area to detect whether the read data matches the data read command, and the read test result of the storage device is obtained.

[0079] In a specific application scenario, in response to a test command, a data write command is executed, and the write data of the data write command is stored in the cache area. The write data and the SGL descriptor of the data write command are sent to the storage device, so that the storage device can retrieve the write data from the cache area and store it based on the SGL descriptor of the data write command. Write feedback data returned by the storage device based on the SGL descriptor of the data write command is received. The write test result of the storage device is determined based on the write feedback data.

[0080] After data is stored in the cache area, the data stored in a single cache area can also be checked for contiguous physical addresses. If contiguous physical addresses are detected, they can be combined and described by a single address descriptor, namely the Last Segment Descriptor. If there are scattered, non-contiguous physical addresses in a cache area, they are described by the combination of the Next Segment Descriptor and the Last Segment Descriptor.

[0081] In a specific application scenario, the test command may include an error injection command. After the driver unit sends the error injection command to the storage device using the SGL data transfer mode, it receives the feedback data sent by the storage device based on the error injection command; it determines whether the feedback data matches the error type corresponding to the error injection command; if the feedback data matches the error type corresponding to the error injection command, it is determined that the storage device has error detection capability; if the feedback data does not match the error type corresponding to the error injection command, it is determined that the storage device does not have error detection capability.

[0082] Error correction commands include, but are not limited to: 1. `lastt seg contains next seg` (the last segment contains information pointing to the next segment); 2. `lastt seg contains last seg` (the last segment contains information pointing to itself); 3. `lastseg invalid length` (the last segment's length is invalid or does not meet expectations); 4. `next seg not last des` (the next segment is not the last segment in the list); 5. `last seg not last des` (the last segment is not the last segment in the list); 6. `data blk sgl length invalid` (the data block length is invalid); 7. `bit bucket sgl length invalid` (the data filter in SGL is invalid); 8. `data blk addr gt max` (the address of the data block exceeds the maximum allowed value); 9. `next seg addr gt max` (the address of the next segment exceeds the maximum allowed value); 10. `last seg addr gt max` (the address of the last segment exceeds the maximum allowed value); 11. `metadata sgl length invalid` (the length field related to SGL in the metadata contains an invalid value); 12. `sgl des type` 13. invalid (SGL descriptor type invalid); 14. invalid (SGL descriptor offset invalid); 15. invalid (SGL data blk addr granularity) (Invalid data block address encountered when processing SGL); 16. invalid (SGL data blk len granularity invalid) (Data block length does not meet device granularity requirements); 17. invalid field in command (Invalid field hit).

[0083] The ability of the storage device to handle errors corresponding to the above-mentioned error injection commands is tested by using these error injection commands, thereby obtaining the corresponding test results and improving the comprehensiveness of SGL testing.

[0084] Through the above steps, the storage device testing method of this embodiment obtains a test script. The test script is obtained by embedding an SGL database into test commands. The test commands in the test script are obtained, and a corresponding cache region is generated based on the test commands using the SGL database. The driver unit converts the virtual address of the cache region into a physical address and generates an SGL descriptor based on the physical address and address length. The SGL descriptor is then sent to the storage device for testing. This utilizes the SGL database to endow the test commands with SGL functionality, enabling the driver unit to support converting test commands with SGL functionality into SGL descriptors for SGL data transmission mode to the storage device. This achieves SGL testing of the storage device, circumventing hardware limitations and improving the flexibility and portability of automated SGL testing, thus expanding the applicability of SGL testing.

[0085] Please see Figure 6 , Figure 6 This is a flowchart illustrating one embodiment of a storage device being tested.

[0086] Step S301: Receive the test command transmitted by the host.

[0087] The storage device receives a test command transmitted from the host.

[0088] Step S302: Determine whether the test command is an SGL descriptor.

[0089] If the test command is an SGL descriptor, proceed to step S304; if the test command is not an SGL descriptor, proceed to step S303.

[0090] Step S303: Parse the test command using PRP.

[0091] PRP (Physical Region Page) is a different data mode from SGL. When testing storage devices, if the test data is not an SGL descriptor, then it is in PRP data mode, and the test commands are parsed using the parsing method corresponding to PRP data mode.

[0092] Step S304: Determine whether the test command is a data block type.

[0093] If the test command is a data block type, proceed directly to step S311. If the test command is not a data block type, proceed to step S305.

[0094] Step S305: Determine whether the test command contains a data filter character.

[0095] If the test command contains a data filter character, proceed to step S306; if the test command does not contain a data filter character, proceed to step S308.

[0096] Step S306: Determine whether the test command is a read command.

[0097] Write commands can also contain data filter characters, but these will not be executed. Therefore, it is necessary to determine the read / write type of the test command. If the test command is a read command, proceed to step S307; if the test command is not a read command, proceed to step S311.

[0098] Step S307: Filter data based on data filter symbols.

[0099] Step S308: Determine whether the test command contains a singly linked descriptor.

[0100] The test commands here include only two types: singly linked descriptors and multi-linked descriptors. When the test command is a singly linked descriptor, step S309 is executed; when the test command is not a singly linked descriptor, it is a multi-linked descriptor, and step S310 is executed.

[0101] Step S309: Parse the singly linked descriptor using SGL.

[0102] Step S310: Parse the multi-chain descriptor using SGL.

[0103] Step S311: Execute the test command and send the execution result back to the host.

[0104] The storage device executes test commands in the above manner and sends the execution results back to the host so that the host can detect the performance of the storage device.

[0105] Please see Figure 7 , Figure 7 This is a schematic diagram of a framework of one embodiment of the test equipment of this application. The test equipment of this embodiment can be applied to the testing method of the storage device in any of the above embodiments to perform host testing.

[0106] The test device 70 includes a driver unit 71, a storage unit 73, and an interface unit 72. The driver unit 71 is used to transmit test commands to the storage device based on the test script using the SGL data transmission mode, so as to test the storage device; the storage unit 73 is used to store the test script, wherein the test script is obtained by embedding the SGL database into the test commands; the interface unit 72 is used to connect the driver unit and the storage unit, and to connect the driver unit and the storage device.

[0107] The above structure enables the use of the SGL database to imbue test commands with SGL functionality, allowing the driver unit to support the conversion of SGL-enabled test commands into SGL descriptors for SGL data transfer mode, which is then transmitted to the storage device. This achieves SGL testing of the storage device, circumventing hardware limitations and thus improving the flexibility and portability of SGL automated testing, as well as expanding the applicability of SGL testing.

[0108] In some embodiments, the driver unit 71 can be modified before testing to support SGL functionality. Specifically, the driver unit 71 is modified so that read commands, write commands, and read commands containing data filtering all have SGL capabilities. The main modification involves altering the read and write methods of the driver unit 71 to support SGL (Scatter-Gather List) data transmission, and finally compiling to generate a new nvme.so file so that the host can easily call it using the Python programming language.

[0109] Specific modifications may include: 1. Checking hardware support: Confirming whether the test device 70 supports SGL. 2. Modifying the command submission function: Setting the DPTR field according to SGL. 3. Modifying the DMA mapping function: Correctly handling the DMA address of the SGL descriptor. 4. Adding an SGL descriptor structure: Defining the structure of the SGL descriptor. 5. Modifying the driver configuration: Adding options to support SGL. After modification, use testing tools to verify the correctness and performance of the SGL function, ensuring that the driver can correctly handle SGL data transfer.

[0110] In some embodiments, during testing, the GitLab tool can be installed on the host to assist the host in performing the above testing steps. Specifically, the SGL test code in the test script can be uploaded to the GitLab tool so that the GitLab tool can compile the code. Once the code compiles successfully, the GitLab repository is configured to begin testing the storage device, thus achieving automated testing of SGL without the need for manual commands and reducing manual workload.

[0111] In some embodiments, the specific test framework of the test device 70 may further include: a test script comprising an SGL test library and a set of test commands (test suite), wherein the test commands can be configured based on customized requirements, consistency, and performance. The SGL test library may include power units, ZNS (Storage Device Partitioning Command Space Technology), TCG (Trusted Computing Group, security standards and technical specifications), MI (Management Interface), and SGL (Distributed-Clustered List).

[0112] The driver unit 71 may include spdk:nvme drive (the modified driver), command log (cmdlog), checksum, and ioworker (a thread responsible for performing I / O operations). Specifically, modifying spdk:nvme drive enables read commands, write commands, and read commands containing data filtering to have SGL capabilities. This can be achieved by modifying the code using the Python programming language.

[0113] The interface unit 72 may include: a controller, a namespace, a qpair (queue), a pcie (bus), and a buffer (buffer area).

[0114] The above structure improves the efficiency of SGL testing of storage devices, saves resources, is more user-friendly for script development, increases test coverage, enhances automation, and accelerates the development iteration pace. With this structure, only one motherboard and accessories are needed for testing, which is not limited by hardware resources, resulting in high execution efficiency. Furthermore, the script development and maintenance costs are low, the test scenarios are more diverse with higher coverage, and the drivers are optimized for higher performance.

[0115] Please see Figure 8 , Figure 8 This is a schematic diagram of a framework of an embodiment of the electronic device of this application. The electronic device 80 includes a memory 81 and a processor 82 coupled to each other. The processor 82 is used to execute program instructions stored in the memory 81 to implement the steps of the above-described method embodiment. In a specific implementation scenario, the electronic device 80 may include, but is not limited to, a microcomputer, a server, etc. In addition, the electronic device 80 may also include a laptop computer, a tablet computer, a Nand Flash memory, etc., without limitation.

[0116] Specifically, processor 82 controls itself and memory 81 to implement the steps of any of the above method embodiments. Processor 82 may also be referred to as a CPU (Central Processing Unit). Processor 82 may be an integrated circuit chip with signal processing capabilities. Processor 82 may also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor may be a microprocessor or any conventional processor. Furthermore, processor 82 may be implemented using integrated circuit chips.

[0117] The above solution can improve the flexibility and portability of SGL automated testing, and expand the applicability of SGL testing.

[0118] Please see Figure 9 , Figure 9 This is a schematic diagram of a framework of an embodiment of the computer-readable storage medium of this application. The computer-readable storage medium 90 stores program instructions 901 that can be executed by a processor. The program instructions 901 are used to implement the steps of any of the above method embodiments.

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

[0120] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0121] Furthermore, the functional units in the various embodiments of this application 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.

[0122] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0123] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention 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 testing method for a storage device, characterized in that, include: The test script is obtained; wherein the test script is obtained by embedding the SGL database into the test command; Based on the test script, the test command is transmitted to the storage device through the driver unit using the SGL data transmission mode to test the storage device.

2. The testing method for the storage device according to claim 1, characterized in that, The step of transmitting the test commands to the storage device via the driver unit using the SGL data transfer mode based on the test script to test the storage device includes: Obtain the test commands in the test script, and generate a cache area corresponding to the test commands through the SGL database based on the test commands; The driver unit converts the virtual address of the cache region into a physical address and generates an SGL descriptor based on the physical address and the address length. The SGL descriptor is sent to the storage device for testing.

3. The testing method for the storage device according to claim 2, characterized in that, Sending the SGL descriptor to the storage device for testing the storage device includes: In response to the test command being a data read command, the SGL descriptor of the data read command is sent to the storage device; Receive the read data returned by the storage device based on the SGL descriptor of the data read command; The read data is stored in the cache area to detect whether the read data matches the data read command, thereby obtaining the read test result of the storage device.

4. The testing method for the storage device according to claim 2, characterized in that, Sending the SGL descriptor to the storage device for testing the storage device includes: In response to the test command being a data write command, the write data of the data write command is stored in the cache area; The write data and the SGL descriptor of the data write command are sent to the storage device, so that the storage device can obtain the write data from the cache area and store it based on the SGL descriptor of the data write command; Receive write feedback data returned by the storage device based on the SGL descriptor of the data write command; determine the write test result of the storage device based on the write feedback data.

5. The testing method for a storage device according to claim 2, characterized in that, The step of generating a cache area corresponding to the test command through the SGL database based on the test command includes: The size of the test data corresponding to the test command is calculated using the SGL database. Determine the cache region with the same data size as the test data from the empty memory region of the SGL database.

6. The testing method for the storage device according to claim 5, characterized in that, The step of determining the cache region with the same data size as the test data from the blank memory region of the SGL database includes: In response to the existence of a contiguous memory region in the blank memory region that is larger than the size of the test data, a contiguous cache region of the same size as the test data is partitioned from the memory region; In response to the absence of a contiguous memory region in the blank memory region that is larger than the data size of the test data, multiple discrete blank memory regions are selected and combined as the cache region based on the data size of the test data.

7. The testing method for a storage device according to claim 2, characterized in that, The process of generating an SGL descriptor based on the physical address and address length further includes: In response to the test command being a partial read instruction for target data, an SGL descriptor is generated based on the physical address and address length of the target data, and a data filter character is marked on the area of ​​the SGL descriptor other than the area corresponding to the partial read instruction, so that the storage device performs data read filtering based on the data filter character.

8. The testing method for a storage device according to claim 2, characterized in that, The SGL descriptor type includes a single-chain descriptor; the generation of the SGL descriptor based on the physical address and address length includes: Based on the physical address and address length, a single-chain descriptor is generated, which includes multiple data segment descriptors. The last descriptor among the multiple data segment descriptors is an address descriptor to indicate the end of the single-chain descriptor.

9. The testing method for a storage device according to claim 2, characterized in that, The SGL descriptor type includes multi-chain descriptors; the generation of the SGL descriptor based on the physical address and address length includes: A multi-chain descriptor is generated based on the physical address and address length, comprising multiple chain descriptors; wherein the last descriptor in each chain descriptor is an address descriptor, pointing to the next chain descriptor or marking the end of the multi-chain descriptor.

10. The testing method for a storage device according to claim 1, characterized in that, The test commands include various error-checking commands; The testing of the storage device further includes: Receive feedback data sent by the storage device based on the error injection command; Determine whether the feedback data matches the error type corresponding to the error annotation command; When the feedback data matches the error type corresponding to the error injection command, it is determined that the storage device has error detection capability. If the feedback data does not match the error type corresponding to the error injection command, it is determined that the storage device does not have error detection capability.

11. A testing device, characterized in that, The testing equipment includes: The driving unit is used to transmit the test command to the storage device based on the test script using the SGL data transfer mode, so as to test the storage device; A storage unit for storing test scripts, wherein the test scripts are obtained by embedding an SGL database into test commands; An interface unit is used to connect the driving unit and the storage unit, and to connect the driving unit and the storage device.

12. An electronic device, characterized in that, The device includes a memory and a processor coupled to each other, the processor being configured to execute program instructions stored in the memory to implement a test method for a storage device as described in any one of claims 1 to 10.

13. A computer-readable storage medium having program instructions stored thereon, characterized in that, When the program instructions are executed by the processor, they implement the testing method for the storage device as described in any one of claims 1 to 10.

Images