Test systems, methods, equipment, media, and products for shared access storage functionality.

Abstract

This application discloses a testing system, method, device, medium, and product for shared access storage functionality, relating to the fields of storage management and testing technology. It involves creating a shared directory for shared access storage space using a storage device, obtaining at least one of the following information using a testing component: shared directory information, mount information, login information, and test configuration information. The shared directory is mounted to a client, and a test configuration file is generated based on the test configuration parameters. This test configuration file is written to at least one client, which then tests the shared access storage functionality of the storage device. This achieves one-click automated IO testing and confirmation of execution results, solving the technical problems of low testing efficiency and error-proneness in mounting and testing large batches of NFS shared directories. It achieves the technical effect of avoiding cumbersome user operations and improving testing efficiency and accuracy.

Description

Technical Field

[0001] This application relates to the field of storage management and testing technology, and in particular to a testing system, method, device, medium and product for shared access storage functionality. Background Technology

[0002] With the development of network storage technology, NAS (Network Attached Storage) provides a shared storage mechanism based on the NFS (Network File System) protocol, enabling clients to efficiently and conveniently access remote storage resources. To ensure the reliability and stability of NFS sharing in practical applications, it is typically necessary to complete the NAS service startup and pre-configuration on the server side, and then perform mounting operations and IO (Input / Output) tests on the client side to verify its performance.

[0003] However, when faced with a large number of NFS shared directories and their diverse mounting and load requirements, the current testing process mainly relies on manual operation, which is inefficient, cumbersome, and prone to errors, making it difficult to meet the needs of large-scale storage testing and deployment. Summary of the Invention

[0004] This application provides a testing system, method, device, medium, and product for shared access storage functions, to at least solve the technical problems of low testing efficiency and easy error in mounting and testing large numbers of NFS shared directories in related technologies.

[0005] This application provides a testing system for shared access storage functionality, comprising: a storage device, including at least one storage node, wherein a shared access storage space is configured on any storage node, and a shared directory is created within the shared access storage space; at least one client for configuring and using the shared access storage space of the storage device; and a testing component for acquiring at least one of shared directory information, mount information, login information, and test configuration information, mounting the shared directory to the client based on at least one mount parameter in the shared directory information and mount information, generating a test configuration file based on the test configuration parameters in the test configuration information, and writing the test configuration file to at least one client based on the login information; and the client testing the shared access storage functionality of the storage device based on the test configuration file.

[0006] This application also provides a method for testing shared access storage functionality. The method is applied to the test component of the aforementioned shared access storage functionality test system. The method includes: obtaining at least one of shared directory information, mount information, login information, and test configuration information; mounting the shared directory to the client based on at least one mount parameter in the shared directory information and mount information; generating a test configuration file based on the test configuration parameters in the test configuration information; writing the test configuration file to at least one client based on the login information; and having the client test the shared access storage functionality of the storage device based on the test configuration file.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the test method of the shared access memory function described above when executing the computer program.

[0008] This application also provides a non-volatile computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the test method for the shared access storage function described above.

[0009] This application also provides a computer program product, including a computer program, and the steps of the test method for implementing the above-described shared access memory function when the computer program is executed by a processor.

[0010] This application addresses the challenges of creating a shared directory for shared access storage space via a storage device, obtaining at least one of the following information using a testing component: shared directory information, mount information, login information, and test configuration information. The shared directory is then mounted to a client, and a test configuration file is generated based on the test configuration parameters. This file is written to at least one client, allowing the client to test the shared access storage function of the storage device. This enables one-click automated IO testing and confirmation of execution results. Therefore, it solves the technical problems of low testing efficiency and error-proneness in mounting and testing large quantities of NFS shared directories, thereby avoiding cumbersome user operations and improving testing efficiency and accuracy. Attached Figure Description

[0011] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A schematic diagram of the structure of a test system for shared access storage function provided in an embodiment of this application;

[0013] Figure 2 A flowchart illustrating the overall process of testing a test system for shared access storage functionality provided in one embodiment of this application;

[0014] Figure 3 A flowchart illustrating the shared directory mounting process provided in one embodiment of this application;

[0015] Figure 4 This is a flowchart illustrating the update of IO parameters according to one embodiment of this application;

[0016] Figure 5 A flowchart illustrating a test method for shared access storage functionality provided in an embodiment of this application;

[0017] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0019] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0020] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] Figure 1 This is a schematic diagram of the structure of a test system for the shared access storage function provided in an embodiment of this application. Figure 1 As shown, the test system 10 for the shared access storage function includes: a storage device 101, at least one client 102, and a test component 103.

[0022] The storage device 101 includes at least one storage node, which is configured with a shared access storage space and a shared directory is created for the shared access storage space. At least one client 102 is used to configure and use the shared access storage space of the storage device 101. The test component 103 is used to obtain at least one of the shared directory information, mount information, login information, and test configuration information. Based on at least one mount parameter in the shared directory information and mount information, the shared directory is mounted to the client 102. Based on the test configuration parameters in the test configuration information, a test configuration file is generated. Based on the login information, the test configuration file is written to at least one client 102. The client 102 tests the shared access storage function of the storage device 101 based on the test configuration file.

[0023] Among them, storage device 101 refers to the server side that provides NAS services, which can manage the file system and allow multiple clients to share access to the same storage space; shared access storage space is the storage resource provided by the storage device that can be accessed by multiple clients through network protocols (such as NFS); client 102 is a client server used to configure and use NAS NFS sharing; test configuration file is a configuration file generated based on configuration parameters provided by the user, used to guide the test tool on how to perform specific test tasks, including but not limited to settings such as file size and number of files.

[0024] It is understood that the storage device 101 in this embodiment includes at least one storage node, on which a shared access storage space is configured and a corresponding shared directory is created; at least one client 102 is used to configure and use the shared access storage space on the storage device 101; the test component 103 is responsible for obtaining relevant information of the shared directory, parameters required for mounting, login credentials, and configuration requirements for IO testing. Based on the obtained shared directory information and mounting parameters, the test component 103 mounts the specified shared directory to the client 102. Subsequently, according to the test configuration parameters, the test component 103 generates a corresponding test configuration file and writes this file to at least one client 102 using login information. Finally, the client 102 tests and verifies the shared access storage function of the storage device 101 according to the received test configuration file. This achieves a high degree of automation in the process of verifying the validity of the NAS NFS shared execution IO test results, greatly reducing the complexity and workload of manual operation and improving testing efficiency.

[0025] In this embodiment of the application, a testing tool is configured on the client 102. The testing tool generates a test load according to the test configuration file and performs at least one read operation and write operation on the shared access storage space based on the test load.

[0026] The testing tool can be Vdbench, which is a tool used to generate specific I / O (Input / Output) loads and perform storage performance tests. It can simulate different load conditions to test storage devices according to the provided test configuration file.

[0027] It is understood that the client 102 in this embodiment of the application is equipped with a testing tool. The testing tool can generate a specific test load according to the test configuration file. Based on this test load, the client 102 can perform at least one operation on the shared access storage space provided by the storage device 101, namely a read operation or a write operation. Specifically, the testing tool can create corresponding I / O loads according to predefined parameters and use these loads to evaluate the performance and stability of the shared storage space.

[0028] In this embodiment of the application, the testing component 103 logs into the client 102 based on the login information, detects whether the client 102 is configured with testing tools, and if the client 102 is not configured with testing tools, then the testing tools are installed on the client 102.

[0029] The login information includes login method, username, password, etc., which is used to remotely log in to client 102.

[0030] It is understood that before starting the test, the test component 103 in this embodiment of the application needs to log in to the client 102 based on the login information and check whether the client 102 has been configured with the required test tools, such as Vdbench. If the test component 103 finds that the client 102 has not been configured with test tools, it will automatically install the corresponding test tools on the client 102 so that the IO test task can be executed according to the generated test configuration file. This ensures that all necessary software environments are ready, so that the read and write operation test of the NAS NFS share can be performed smoothly.

[0031] According to the shared access storage function test system of the present application embodiment, a shared directory of shared access storage space can be created through a storage device. The test component is used to obtain at least one of the shared directory information, mount information, login information, and test configuration information. The shared directory is mounted to the client, and a test configuration file is generated according to the test configuration parameters. The test configuration file is written to at least one client, and the client tests the shared access storage function of the storage device. This realizes one-click start of automated IO test and confirmation of execution results, achieving the technical effect of avoiding tedious operations for users and improving test efficiency and accuracy.

[0032] He then provides a specific example to further describe the test system for shared access storage functionality.

[0033] In the specific implementation of this embodiment, three types of devices and roles are involved: storage device (referring to the server that builds the storage system and can provide NAS services), client (NFS shared client, referring to the client server used to configure and use NAS NFS sharing), and test component (referring to the server used to deploy and install automated devices and store some common tools, such as storing the Vdbench toolkit for users to download and use).

[0034] This embodiment first performs NAS pre-configuration on the storage system and categorizes shared directories based on mount parameters and IO test parameters. Directories with the same two parameters are grouped together, and shared directories of the same category can be input into the automated device simultaneously. Shared directories of different categories can be input into the automated device in batches. The device receives parameters input by the user (storage device information, NFS share client device information, shared directory name, IO parameters, mount parameters). It first mounts the shared directory on the NFS share access client according to the mount parameters, then calculates and writes the IO configuration file based on the provided IO parameters (this embodiment uses Vdbench as the IO testing tool), and finally starts the IO test and verifies its effectiveness. The flowchart is as follows: Figure 2 As shown, the details are as follows:

[0035] Step (1): Perform NAS pre-configuration on the storage side.

[0036] All operations involved in this step need to be performed on the storage device. These operations can be performed through a graphical user interface or via a background command line. The steps include creating a storage pool, enabling the NAS service, creating a file system, configuring the NAS shared service address, and creating an NFS share. Users can create these operations sequentially as needed.

[0037] Step (2): Categorize shared directories according to mount parameters / IO parameters

[0038] Users can determine the mounting parameters (such as -o vers=4, which means specifying the use of NFSv4 (NFS version 4 protocol for mounting) and IO configuration parameters (such as --xfsize 4k, --fileio random, where --xfsize 4k specifies the transfer size of the I / O operation, indicating that each I / O operation will process 4 kilobytes of data, and --fileio random indicates the access mode of the I / O operation) according to actual needs. Parameters with the same parameters are grouped together. Users can also create and summarize parameters with the same parameters together in step (1). The parameters in this step are provided by the user according to actual needs.

[0039] Step (3): Input the shared directory and user parameters into the automation device.

[0040] The automation device in this embodiment requires the user to input the NFS shared directory created in step (1), the IO configuration parameters determined in step (2), the mount parameters, and to provide specific login information for the device (storage device, NFS shared client) (such as login method, login username, password, for remote login by the actuator).

[0041] Step (4): The NFS shared client mounts the shared directory.

[0042] Since mounting requires the business address of the storage node where the NAS's shared directory resides, the corresponding business address needs to be queried in the storage system based on the shared directory first. NAS services are typically deployed on a dual-controller storage system, i.e., a storage system consisting of two storage nodes (designated node1 and node2). Each NAS file system has a home node, and its corresponding shared directory also uses the business IP of the corresponding node. The shared directory mounting process is as follows: Figure 3 As shown, the specific process is as follows:

[0043] First, query the specified shared directory name on node1. If it can be found, it means that the file system corresponding to the shared directory belongs to node1, and then the business address of node1 needs to be obtained; otherwise, the business address of node2 needs to be obtained.

[0044] Then, a local directory to be mounted is created on the NFS share client. Next, it checks if the user has provided the parameters required for mounting (e.g., `--mount_param "-o vers=3, tcp`, used to specify the specific options for mounting the NFS share; `-o` is an option of the `mount` command used to specify various options for mounting the file system; when mounting an NFS share, `-o` is followed by a series of NFS-specific options; `vers=3` specifies the version of the NFS protocol used, indicating the use of NFS version 3; `tcp` specifies the use of TCP (Transmission Control Protocol) as the transport protocol). If there are mounting parameters, `mount_param` is set to the passed parameters, and the file is mounted with the parameters; otherwise, the mounting is performed directly with empty parameters. Simultaneously, due to the differences between IPv4 (Internet Protocol version 4) and IPv6 (Internet Protocol version 6)... 6. The mounting format of Internet Protocol version 6 (IPv6) is different. When mounting, it is necessary to distinguish whether the service address is IPv4 or IPv6. If it is IPv4, then perform IPv4 NFS mounting with mount_param; otherwise, perform IPv6 NFS mounting with mount_param.

[0045] Step (5): Calculate and write to the IO configuration file

[0046] The flowchart for updating IO parameters is as follows: Figure 4As shown, since this embodiment uses the Vdbench tool as the IO load generator, the automated device first checks whether the tool is installed on the NFS shared client (first checking if the Vdbench tool directory exists, and then checking if the Vdbench executable file exists). If the tool is not found on the NFS client, it will download it from the execution machine server and install it on the NFS shared client. If the tool already exists on the NFS client, it will continue to execute the subsequent steps. After confirming that the tool is installed, it needs to generate the configuration file (auto_param) required for Vdbench to perform IO testing based on the IO parameters passed by the user. This is the test configuration file. The parameters in this file include some general IO parameters and user-customized parameters. Some general IO parameters can be obtained directly from the user input, such as the number of threads (threads), the proportion of read-only data in the load (rdpct), and the compression ratio of written data (compratio). Some user-customized parameters, such as the number of files created in the lowest level directory (files) and the file size (fsize), need to be checked and adapted to the actual situation before being written into the IO configuration file.

[0047] If the file size is provided, the maximum number of files that can actually be accommodated can be calculated based on the actual space size of the mounted directory. If the user also provides the number of files, the smaller value between the provided value and the actual calculated value will be used. (If the actual storage space size is not taken into account when the user provides both the file size and the number of files, it will lead to insufficient space and unsuccessful IO execution. Therefore, it is necessary to adjust the file size or the number of files written to the configuration file. This article adopts the method of adjusting the number of files.)

[0048] If the user does not provide the file size (fsize), it needs to be calculated by dividing the actual size of the mounted directory by the total number of files (at least one of the file size and the number of files is required; the total number of files is the directory width raised to the power of the directory depth, multiplied by the number of files).

[0049] If users want to enable data verification during IO read and write operations, they also need to ensure that the file size is an integer multiple of the data size (xfersize) of a single transfer.

[0050] Step (6): Start Vdbench on the NFS shared client to perform IO testing.

[0051] The automated device remotely logs in to the NFS shared client and sends commands to it. On the NFS shared client, Vdbench is started. Vdbench generates IO load according to the specified IO configuration file and then performs IO read and write tests on the specified directory space.

[0052] Step (7) Validation after IO test is completed

[0053] Vdbench typically prints logs to the corresponding log directory file when performing IO tests. The validity of the IO test is determined by checking the final output of the logs. If the message "Vdbench execution completed successfully" is found in the final output, the test is considered valid.

[0054] Different types of NFS sharing can be input into the automated device in batches, and the IO test can be started sequentially to obtain the test results.

[0055] Next, referring to the accompanying drawings, the test method for the shared access storage function provided in the embodiments of this application is described. Figure 5 This is a flowchart illustrating a test method for shared access storage functionality provided in an embodiment of this application. The method is applied to the test components of the aforementioned shared access storage functionality test system, such as... Figure 5 As shown, the method includes the following steps:

[0056] In step S201, at least one of the following is obtained: shared directory information, mount information, login information, and test configuration information.

[0057] Among them, shared directory information refers to relevant information about the NFS shared directory provided by the NAS, including but not limited to directory name, path, etc.; mount information involves the parameters and requirements for mounting remote files to the local machine, including mount parameters; login information contains the authentication information required to access the storage device or client, such as login method, username, password, etc., for remote login and operation; test configuration information refers to the various parameter settings required for IO performance testing. Some common IO parameters can be obtained directly from user input, including but not limited to the number of threads, the proportion of read-only in the load, file size, etc.

[0058] It is understood that the embodiments of this application first obtain shared directory information, mount information, login information or test configuration information. Based on this collected information, a series of operations from mounting the shared directory to executing and verifying the IO test results can be completed automatically.

[0059] In step S202, the shared directory is mounted to the client based on at least one of the mount parameters in the shared directory information and the mount information.

[0060] It is understood that, based on the shared directory information and at least one of the mount parameters in the mount information provided in this application, the specified NFS shared directory can be mounted to the client device. That is, by using the shared directory information and the necessary mount parameters (such as specifying the protocol version, transmission type, etc.), the required remote storage resources can be correctly mounted on the client device, ensuring that the client can access and use the specific shared storage space on the NAS according to specific needs, thus preparing for subsequent IO tests or other operations.

[0061] In this embodiment of the application, mounting a shared directory to a client based on at least one of the mounting parameters in the shared directory information and the mounting information includes: extracting the shared directory name from the shared directory information; querying the business address of the corresponding target storage node from the storage device based on the shared directory name, wherein the target storage node has created a shared access storage space; creating a local mounting directory on the client, mounting the business address to the local mounting directory, and if mounting parameters exist, carrying the mounting parameters during mounting.

[0062] Among them, the shared directory name is the identifier of the shared directory, which is used to locate specific shared resources on the storage device; the business address of the target storage node refers to the network address (i.e., IP (Internet Protocol) address) of the node on the storage device that provides NFS service, which is used for communication between the client and the storage device; the local mount directory is a directory created locally on the client, which is used as a mount point to mount the remote NFS shared directory.

[0063] It is understood that, according to the embodiments of this application, the shared directory is mounted on the client based on at least one of the mount parameters in the shared directory information and the mount information. First, the shared directory name in the shared directory information is extracted. Then, based on this name, the business address of the corresponding target storage node, i.e., the IP address of the node providing NFS service, is queried from the storage device. In this process, it is determined which storage node created the shared access storage space. Next, a local mount directory is created on the client, and the obtained business address is mounted to this local directory. If mount parameters exist, these parameters are carried during the mount operation to ensure that the mount process is correctly configured according to the user's needs. Thus, the correct mounting of the remote NFS shared directory on the client is achieved through an automated process, providing the necessary preparation for subsequent IO testing or other operations.

[0064] In this embodiment of the application, mounting a service address to a local mount directory includes: identifying the type of the service address, determining the target mount format based on the type, and mounting the service address on the local mount directory using the target mount format.

[0065] The service address types include both IPv4 and IPv6 addresses; the target mount format is the corresponding mount command format determined according to the service address type. For example, IPv4 addresses may directly use the standard mount syntax, while IPv6 addresses need to be enclosed in square brackets.

[0066] Understandably, in this embodiment of the application, mounting the service address to the local mount directory first requires identifying the type of the service address, i.e., determining whether it is an IPv4 address or an IPv6 address. Based on the identified address type, a suitable target mount format is selected. For example, if the service address is an IPv4 address, a mount format is used; if it is an IPv6 address, the mount format needs to be adjusted to conform to the IPv6 specification (e.g., adding square brackets around the IPv6 address). Subsequently, using the determined target mount format, the service address is mounted in the local mount directory on the client, ensuring that regardless of the type of service address, it can be correctly mounted to the specified local directory, laying the foundation for subsequent IO testing or other operations.

[0067] In step S203, a test configuration file is generated based on the test configuration parameters in the test configuration information. The test configuration file is written to at least one client based on the login information. The client then tests the shared access storage function of the storage device based on the test configuration file.

[0068] The test configuration information includes all the information required for IO performance testing, such as the number of threads, read / write ratio, and file size. The test configuration parameters will be described in detail below and will not be repeated here. The test configuration file is a file generated based on the test configuration parameters and is used to guide the testing tools on how to execute specific test tasks.

[0069] It is understood that, according to the specific test configuration parameters in the test configuration information, the embodiments of this application can automatically generate the corresponding test configuration file. Using the provided login information, the test configuration file is deployed to at least one client. The client uses the parameters defined in the received test configuration file to test the shared access storage function of the storage device. The whole process ensures that the test can be automatically executed according to the preset requirements and effectively evaluate the performance and stability of NFS sharing. In this way, the IO testing and verification of NAS NFS sharing can be completed efficiently and accurately.

[0070] In this embodiment, the test configuration parameters include at least one of file size and number of files. Writing the test configuration file to at least one client based on login information further includes: logging into the client based on login information; determining the target space required for the test configuration file based on at least one of file size and number of files, and obtaining the actual space of the client's local mount directory; updating the file size or number of files of the configuration file based on the target space and actual space, and writing the updated configuration file to at least one client.

[0071] The target space is the required storage space calculated based on the file size and number of files provided by the user. If the file size and number of files are provided, the target space is the result of multiplying the two. If only one parameter is provided, the other parameter needs to be calculated based on the actual situation. The actual space refers to the actual available storage space of the locally mounted directory on the client.

[0072] It is understood that, in this embodiment of the application, the user logs into at least one client based on login information, and determines the target space required for the test configuration file based on at least one of the file size and number of files in the test configuration parameters. The user obtains the actual available space of the client's local mounted directory, and adjusts the file size or number of files in the test configuration file based on the comparison between the calculated target space requirement and the actual space, so as to ensure that the test task can be effectively executed within the actual available space. Finally, the adjusted and updated configuration file is written to the client, so that the client can accurately test the shared access storage function of the storage device according to the finally confirmed configuration parameters, ensuring that the test not only meets the user's initial settings, but also runs smoothly within physical limitations.

[0073] In this embodiment of the application, before writing the test configuration file to at least one client based on the login information, the method further includes: identifying whether the user expects to enable the data verification function; if it is identified that the user expects to enable the data verification function, determining the size of each data transmission, and setting the size of the test configuration file to an integer multiple of the size of each data transmission.

[0074] The purpose of setting the test configuration file size to an integer multiple of the data size transmitted each time is to ensure that it meets the verification requirements of the testing tool and that all transmitted data can be correctly verified.

[0075] It is understood that, before writing the test configuration file to at least one client based on the login information, this application embodiment first identifies whether the user wishes to enable the data verification function. If it is identified that the user wishes to enable this function, the size of each data transmission is further determined. Subsequently, the file size in the test configuration file is adjusted to ensure that it is an integer multiple of the size of each data transmission, so as to maintain data integrity and accuracy. This ensures that when data verification is enabled, all transmitted data can be correctly checked and verified, thereby improving the reliability and accuracy of the test results. After these steps are completed, the updated test configuration file will be written to the client in preparation for subsequent IO tests.

[0076] According to the testing method for shared access storage function provided in the embodiments of this application, a shared directory of shared access storage space can be created through a storage device. At least one of the shared directory information, mount information, login information, and test configuration information is obtained using a test component. The shared directory is mounted to the client, and a test configuration file is generated according to the test configuration parameters. The test configuration file is written to at least one client, and the client tests the shared access storage function of the storage device. This achieves one-click start of automated IO testing and confirmation of execution results, thus avoiding tedious operations for users and improving the technical effect of testing efficiency and accuracy.

[0077] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to 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.

[0078] For a description of the features in the embodiment corresponding to the test method for the shared access storage function, please refer to the relevant description of the embodiment corresponding to the test system for the shared access storage function, which will not be repeated here.

[0079] Embodiments of this application also provide an electronic device, such as... Figure 6 As shown, it includes a memory 301 and a processor 302. The memory 301 stores a computer program, and the processor 302 is configured to run the computer program to perform the steps in the test method embodiment of the shared access memory function described above.

[0080] Embodiments of this application also provide a non-volatile computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in the above-described test method embodiment for shared access storage function at runtime.

[0081] In one exemplary embodiment, the aforementioned non-volatile computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0082] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in the above-described test method embodiment for shared access storage function.

[0083] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the test method embodiment for the shared access storage function described above.

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

[0085] The foregoing has provided a detailed description of a test system, method, device, medium, and product for shared access storage functionality provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A test system for shared access storage functionality, characterized in that, include: A storage device, the storage device including at least one storage node, configuring a shared access storage space on any storage node, and creating a shared directory in the shared access storage space; At least one client is provided for configuring and using the shared access storage space of the storage device; A testing component is used to obtain at least one of shared directory information, mount information, login information, and test configuration information. Based on the shared directory information and at least one mount parameter in the mount information, the component mounts the shared directory to the client. Based on the test configuration parameters in the test configuration information, the component generates a test configuration file. Based on the login information, the component writes the test configuration file to at least one client. Before writing the test configuration file to at least one client based on the login information, the component further includes identifying whether the user expects to enable the data verification function. If the user expects to enable the data verification function, the component determines the size of each data transmission and sets the size of the test configuration file to an integer multiple of the size of each data transmission. The client tests the shared access storage function of the storage device based on the test configuration file. The client is equipped with a test tool, which generates a test load based on the test configuration file and performs at least one read operation and one write operation on the shared access storage space based on the test load.

2. The test system for shared access storage function according to claim 1, characterized in that, The testing component logs into the client based on the login information, checks whether the client has the testing tool configured, and if the client has not configured the testing tool, then installs the testing tool on the client.

3. A test method for shared access storage functionality, characterized in that, The method is applied to a test component of a test system for the shared access storage function as described in any one of claims 1-2, wherein the method includes: Obtain at least one of the following: shared directory information, mount information, login information, and test configuration information; The shared directory is mounted to the client based on at least one of the mount parameters in the shared directory information and the mount information. A test configuration file is generated based on the test configuration parameters in the test configuration information. The test configuration file is written to at least one of the clients based on the login information. The clients then test the shared access storage function of the storage device based on the test configuration file.

4. The test method for shared access storage function according to claim 3, characterized in that, The step of mounting the shared directory to the client based on at least one of the shared directory information and the mount parameters includes: Extract the shared directory name from the shared directory information; Based on the shared directory name, the service address of the corresponding target storage node is queried from the storage device, wherein the target storage node has created the shared access storage space; A local mount directory is created on the client, and the service address is mounted to the local mount directory. If the mount parameters exist, they are carried over during mounting.

5. The test method for shared access storage function according to claim 4, characterized in that, Mounting the service address to the local mount directory includes: Identify the type of the service address and determine the target mounting format based on the type; The service address is mounted on the local mount directory using the target mount format.

6. The test method for shared access storage function according to claim 3, characterized in that, The test configuration parameters include at least one of file size and number of files, and the step of writing the test configuration file to at least one of the clients based on the login information further includes: Log in to the client based on the login information; Based on at least one of the file size and the number of files, determine the target space required for the test configuration file and obtain the actual space of the client's local mount directory; Update the file size or number of files of the configuration file according to the target space and the actual space, and write the updated configuration file to at least one of the clients.

7. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the test method for the shared access storage function as described in any one of claims 3 to 6 when executing the computer program.

8. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the test method for the shared access storage function as described in any one of claims 3 to 6.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the test method for the shared access storage function as described in any one of claims 3 to 6.

Images