Disk array card detection method, terminal and storage medium

Abstract

The application relates to the technical field of storage, and particularly provides a disk array card detection method, a terminal and a storage medium, which comprise the following steps: configuring a self-checking area for a volume in a disk array; defining a first interface of a volume level and a second interface of a hard disk management level; writing data to the self-checking area through the first interface, and reading data from the self-checking area through the first interface and the second interface respectively; and generating a detection result of the disk array card based on the matching degree of the read data and the write data. The application realizes accurate testing of the read-write function of the disk array card.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of storage, and particularly relates to a disk array card detection method, a terminal and a storage medium. BACKGROUND

[0002] Array card, full name disk array card, is designed for building RAID (Redundant Array of Independent Disks) system. RAID system enhances the reliability, performance and capacity of data storage by integrating multiple hard drives into a logical unit according to certain rules and managing them efficiently by a dedicated array controller. Inside the RAID card, dozens of precise hardware IP modules are integrated, each responsible for its own function: some focus on analyzing high-speed nvme instructions, some are responsible for smooth DMA (Direct Memory Access) transmission, and some modules are responsible for precise interaction with hard drives and resource optimization recovery. Taking PCIe 4.0 interface as an example, the card can process up to 64Gbps of data flow per second, showing its powerful data processing capacity.

[0003] However, in the face of such a huge data flow, if the abnormality of the internal hardware of the RAID card cannot be detected, corrected and repaired in time, it will directly lead to abnormal data processing, and may cause immeasurable data loss or system failure.

[0004] To solve this problem, the traditional detection method usually involves writing data from the interface layer and then reading it immediately, and verifying the consistency of read and write data. However, this method has limitations, because read-write inconsistency may not be caused only by disk array abnormalities, but also by problems at other levels or accidental covering of detection data by external program data. Therefore, simply relying on such detection means to evaluate the health status of RAID card function modules often cannot achieve the desired accuracy, and more comprehensive and accurate monitoring and diagnosis strategies are needed to ensure the stable operation of the data center. SUMMARY

[0005] In view of the above problems of the prior art, the application provides a disk array card detection method, a terminal and a storage medium to solve the above technical problems.

[0006] In a first aspect, the application provides a disk array card detection method, comprising:

[0007] configuring a self-check area for a volume in a disk array;

[0008] defining a first interface of the volume level and a second interface of the hard disk management level;

[0009] writing data to the self-check area through the first interface, and reading data from the self-check area through the first interface and the second interface respectively;

[0010] Based on the matching degree of the read data and the write data, a detection result of the disk array card is generated.

[0011] In an optional embodiment, a self-checking area is configured for a volume in a disk array, comprising:

[0012] When the volume is created, a self-checking area of 3 stripe sizes is reserved;

[0013] The self-checking area is set in a hidden partition by using a custom configuration function.

[0014] In an optional embodiment, the method further comprises:

[0015] The detection data is configured, and the test firmware is compiled;

[0016] The detection data and the test firmware are saved to a specified path;

[0017] The test firmware is granted permission to call the first interface and the second interface.

[0018] In an optional embodiment, the detection data is provided with a label, and the label comprises time, volume ID, array ID, volume logical address, and hard disk logical address.

[0019] In an optional embodiment, the test firmware comprises:

[0020] A plurality of test cases, and the read-write modes adopted by the plurality of test cases cover all read-write modes supported by the disk array.

[0021] In an optional embodiment, data is written to the self-checking area through the first interface, and data is read from the self-checking area through the first interface and the second interface, respectively, comprising:

[0022] The test firmware is executed;

[0023] The test firmware reads the label of the detection data, and parses the test time and the test address from the label;

[0024] The test firmware writes test data to the test address through the first interface in the test time according to the write mode defined by the test case, and reads data from the test address through the first interface and the second interface after the write operation is completed according to the read mode defined by the test case, to obtain first check data and second check data.

[0025] In an optional embodiment, based on the matching degree of the read data and the write data, a detection result of the disk array card is generated, comprising:

[0026] The consistency of the first check data, the second check data, and the test data is compared;

[0027] If the first check data, the second check data and the test data are consistent, it is determined that the disk array card is normal.

[0028] If the first check data is different from the test data, and the first check data is the same as the second check data, it is determined that the write operation of the disk array card is abnormal.

[0029] If the first check data is different from the test data, and the test data is the same as the second check data, it is determined that the read operation of the disk array card is abnormal.

[0030] If the first check data is the same as the test data, and the first check data is different from the second check data, it is determined that the read-write position of the disk array card is overall abnormal offset.

[0031] In an optional implementation, comparing the consistency of the first check data, the second check data and the test data comprises:

[0032] calculating a hash value of the first check data to obtain a first hash value;

[0033] calculating a hash value of the second check data to obtain a second hash value;

[0034] obtaining detection data cached by the test firmware and calculating a hash value to obtain a third hash value;

[0035] comparing the consistency of the first hash value, the second hash value and the third hash value.

[0036] In a second aspect, the present application provides a disk array card detection system, comprising:

[0037] a region configuration module configured to configure a self-check region for a volume in a disk array;

[0038] an interface definition module configured to define a first interface of a volume level and a second interface of a hard disk management level;

[0039] a read-write test module configured to write data to the self-check region through the first interface, and read data from the self-check region through the first interface and the second interface respectively;

[0040] a result analysis module configured to generate a detection result of the disk array card based on a matching degree of the read data and the write data.

[0041] In a third aspect, a terminal is provided, comprising:

[0042] a processor and a memory,

[0043] the memory is configured to store a computer program,

[0044] The processor is configured to call and run the computer program from the memory, so that the terminal executes the method of the terminal.

[0045] In a fourth aspect, a computer storage medium is provided, and the computer readable storage medium stores instructions, which, when executed on a computer, cause the computer to perform the method of the above aspects.

[0046] The disk array card detection method, the terminal and the storage medium provided by the application have the advantages that the self-checking area is configured for the volume in the disk array architecture, the problem of batch data damage caused by hardware exception can be avoided through runtime self-checking, the damage of detection data by other programs is avoided, and the precise test of the read-write function of the disk array card is realized by adding interfaces at different levels to bypass the influence of other levels.

[0047] In addition, the application has reliable design principles, simple structure and very wide application prospects. BRIEF DESCRIPTION OF DRAWINGS

[0048] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, for those skilled in the art, other drawings can also be obtained without creative labor based on these drawings.

[0049] Figure 1 is a schematic flow chart of the method of an embodiment of the application.

[0050] Figure 2 is another schematic flow chart of the method of an embodiment of the application.

[0051] Figure 3 is a schematic diagram of the disk array architecture of the method of an embodiment of the application.

[0052] Figure 4 is a schematic diagram of the read-write mode of the method of an embodiment of the application.

[0053] Figure 5 is a schematic principle diagram of the read-write test of the method of an embodiment of the application.

[0054] Figure 6 is a schematic principle diagram of the test result analysis of the method of an embodiment of the application.

[0055] Figure 7 is a schematic block diagram of the system of an embodiment of the application.

[0056] Figure 8 is a structural schematic diagram of a terminal provided by an embodiment of the application. DETAILED DESCRIPTION

[0057] In order to make the technical solutions in the present application better understood by those skilled in the art, the technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work should belong to the scope of protection of the present application.

[0058] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in the description herein is for describing particular embodiments only and is not intended to be limiting of the application.

[0059] The key terms appearing in the present application are explained below.

[0060] RAID : Redundant Array of Independent Disks, an array of independent disks with redundancy. Using a redundant array of member disks can effectively improve data reliability and I / O performance. Using this technology, data is cut into many sections and stored on each disk.

[0061] Linked list: a data structure in computer programming, containing data and a pointer to the next data, the linked list structure is friendly to insertion and deletion operations, and can reduce the number of data movements compared with arrays.

[0062] RAID card: a device that can create a hard disk RAID group, which can improve the access speed of data through multi-disk parallel access, and provide the ability to correct errors for redundant data.

[0063] Red-black tree: a special binary search tree, binary balanced tree, because it can provide stable binary search performance, so it is widely used.

[0064] Skip list: a data structure used to implement an ordered set. A skip list speeds up lookup, insertion, and deletion operations in a probabilistic, hierarchical manner by adding some additional pointers at each level. This makes the skip list have similar performance to a balanced tree in some ways, but its implementation is relatively simple.

[0065] Logical address (LBA): an address passed by the HOST when reading and writing data on the RAID, which is a logical address, not the actual physical address of the hard disk. Through the mapping of logical addresses and physical addresses in the RAID, the real data of the hard disk is accessed.

[0066] Physical Address (PBA): refers to the physical disk address provided externally, although the actual address provided externally on the SSD disk is also the logical address of the disk layer, but in this paper. The address provided externally by the physical disk is collectively referred to as the physical address, and no longer distinguished.

[0067] Disk Management (DM): The hard disk management layer is mainly responsible for IO read and write from the hard disk.

[0068] Volume (VOL): Volume level, located at the top of the RAID array, and space utilization flexibility can be increased by creating a volume on the RAID array.

[0069] NVMe module: mainly processing external NVMe commands, or packaging internal information to be returned into NVMe command format.

[0070] Host (HOST): Host layer, which can be considered as the usual PC operating system layer.

[0071] The disk array card detection method provided by the embodiment of the application is executed by a computer device, and accordingly, the disk array card detection system runs in the computer device.

[0072] Figure 1 is a schematic flowchart of the method of an embodiment of the application. Wherein, Figure 1 The execution subject can be a disk array card detection system. According to different needs, the order of steps in the flowchart can be changed, and some can be omitted.

[0073] As Figure 1 shown, the method comprises:

[0074] Step 110, configuring a self-checking area for a volume in a disk array;

[0075] Step 120, defining a first interface of the volume level and a second interface of the hard disk management level;

[0076] Step 130, writing data to the self-checking area through the first interface, and reading data from the self-checking area through the first interface and the second interface respectively;

[0077] Step 140, generating a detection result of the disk array card based on the matching degree of the read data and the write data.

[0078] In an embodiment, the detailed description of each step includes:

[0079] Step 110, configuring a self-checking area for a volume in a disk array;

[0080] First, the location and size of the self-checking area are defined. The administrator needs to log in to the management interface of the disk array and select a specific logical volume or physical area as the self-checking area. This area will be dedicated to storing data for subsequent self-detection and verification, ensuring that it does not overlap with other business data and avoid interference. According to the capacity of the disk array, performance requirements and the expected frequency of self-checking, the size of the self-checking area is reasonably planned.

[0081] Step 120, define the first interface of the volume level and the second interface of the hard disk management level:

[0082] First interface: Define an interface at the volume level to interact with the operating system or upper-layer application program, and realize the writing and preliminary processing of data. This interface is responsible for mapping the data that needs to be checked to the self-checking area through the logical volume, ensuring the consistency and integrity of the data at the logical level.

[0083] Second interface: Define an interface at the hard disk management level to directly communicate with the physical hard disk. This interface is used to read the data stored in the self-checking area, and can also be used for health status checking at the hard disk level. Through this interface, the operating system or file system can be bypassed to directly access the physical medium and obtain more detailed hardware status information at a lower level.

[0084] Step 130, write data to the self-checking area through the first interface, and read data from the self-checking area through the first interface and the second interface respectively:

[0085] Write data: Use the first interface of the volume level to write preset test data or specific pattern data to the self-checking area. These data can be simple sequence numbers, random data or data blocks with specific checksums to facilitate subsequent verification.

[0086] Read data: First, read the data in the self-checking area from the logical level through the first interface to verify whether the data writing is successful and whether the data processing at the logical level is accurate. Then, read the data in the same area from the hard disk management level directly through the second interface to verify the data consistency at the physical level and the reading ability of the hard disk.

[0087] Step 140, generate the detection result of the disk array card based on the matching degree of the read data and the write data:

[0088] Data comparison: Compare the data read through the two interfaces with the original written data to calculate the matching degree. The matching degree can be obtained by calculating the number of difference bits, checksum verification or more complex data integrity verification algorithms.

[0089] Result analysis: According to the comparison result, analyze whether there is a problem with the disk array card and the hard disk it manages. If the read data is completely consistent with the written data, it indicates that the disk array card and the hard disk are working normally; if there is a difference, it may indicate that there is a hardware failure, data transmission error or logical level problem.

[0090] Generate report: Organize the detection results into a report, including detection time, detection object, specific error details and recommended repair measures, etc., for the administrator to refer to and make decisions.

[0091] Through the above steps, the disk array card and the hard disk it manages can be effectively self-detected, potential problems can be found and handled in a timely manner, and the safety of data and the stability of the system can be ensured.

[0092] In order to facilitate the understanding of the present application, the principle of the disk array card detection method of the present application will be described further in the following combined with the process of detecting the disk array card in the embodiment.

[0093] Specifically, please refer to Figure 2 , the disk array card detection method comprises:

[0094] S1, configure a self-checking area for a volume in the disk array.

[0095] When creating a volume, reserve a self-checking area of 3 stripe sizes; use the custom configuration function to set the self-checking area in the hidden partition.

[0096] A basic RAID hierarchy structure, where each layer from top to bottom is explained as follows:

[0097] HOST layer: refers to the host side, the volume created on the RAID card is displayed in the form of nvme device on the HOST side.

[0098] NVMe layer: the layer responsible for processing NVMe command processing inside the RAID card, responsible for command interaction with HOST.

[0099] VOL layer: volume layer, the volume layer mainly contains some basic information of the volume, including name, start and end LBA address, etc., each volume corresponds to an NS of the NVMe layer.

[0100] RAID layer: the RAID layer is mainly used to divide the hard disk space into a strip for the use of the volume, and the space source when creating the volume is directly obtained through mapping.

[0101] DM layer: the DM layer is mainly responsible for the management and IO interaction of the hard disk, all write and read operations on the hard disk will pass through here.

[0102] Each layer has various sub-modules, if the sub-modules in each layer appear abnormal in the data processing process, it is usually not easy to be found, and the amount of error data generated in this time period cannot be evaluated. Among them, the volume layer mainly does some simple address mapping, and converts the IO operation of the volume to the RAID layer, while the IO operation on the RAID layer is more complex, usually there are multiple read-write operation processes, usually there are strip splitting, result summarizing, and in the writing mode, there are also large and small writing, full strip writing, and P, Q check value calculation for RAID5 and RAID6, in addition, when actually writing data, the data also needs to be split to each disk, the business process and algorithm are complex and easy to appear abnormal, and the part that is easy to have problems is also this part.

[0103] Please refer to Figure 3 Reserve a part of space (C4, C9, C13) in each volume as a self-checking area, the reservation of this area is not perceived by the upper layer NVMe, and also not perceived by the lower layer RAID, the size of this self-checking area is usually left for 3 strips.

[0104] The setting method of the self-checking area includes: setting the self-checking area in the hidden partition by using the self-defined configuration function.

[0105] S2, define a first interface of the volume layer and a second interface of the hard disk management layer.

[0106] Define a first interface capable of managing the volume and a second interface capable of directly managing the hard disk.

[0107] In an embodiment of the present application, the following method is used to define the interface:

[0108] The first interface of the nova accessing the VOLUME layer is defined under the directory of nova / volume.

[0109] In Linux distributions such as Red Hat Enterprise Linux (RHEL), the second interface of the DM layer is defined by the Device Mapper technology.

[0110] S3, read and write test.

[0111] S301, file preparation.

[0112] Configure detection data, and compile test firmware; save the detection data and the test firmware to a specified path; grant the test firmware the permission to call the first interface and the second interface.

[0113] The detection data is provided with labels, including time, volume ID, array ID, volume logical address, and hard disk logical address.

[0114] The test firmware includes multiple test cases, and the read-write modes adopted by the multiple test cases cover all read-write modes supported by the disk array.

[0115] Specifically, the following steps are included:

[0116] First, configure the detection data according to the test requirements. These data are not only used to test the performance and reliability of the disk array, but also to verify the data integrity and system response. Detection data is given a unique label so that it can be easily tracked and identified during and after testing.

[0117] Label setting: Each detection data block is attached with a label containing multiple fields, including but not limited to:

[0118] Time: Record the timestamp of data generation or configuration.

[0119] Volume ID: Identify the specific logical volume to which the data belongs.

[0120] Array ID: Specifies the unique identifier of the disk array where the data is located.

[0121] Volume logical address: Position information in the logical volume.

[0122] Hard disk logical address (or physical address): If applicable, also record the location of the data on the physical hard disk.

[0123] These labels help testers quickly locate problem areas and understand the location and status of data in the testing process.

[0124] Next, write or modify the test firmware according to the test plan. The test firmware is a set of program codes used to execute predefined test cases to verify the functionality and performance of the disk array.

[0125] Test case writing: Ensure that the test firmware contains multiple test cases that cover all read-write modes supported by the disk array, including but not limited to sequential read-write, random read-write, mixed read-write mode, etc. The design of test cases should be comprehensive and representative to fully expose potential problems.

[0126] Compilation process: Use appropriate compilers and build tools to compile the test firmware source code into executable files. During the compilation process, ensure that best practices such as code optimization, error checking, etc. are followed to improve the efficiency and reliability of the test firmware.

[0127] Save the configured test data and compiled test firmware to a designated path. This path should be accessible to all testers and have sufficient storage space and security.

[0128] Designated Path: Choose an easily accessible and protected directory as the storage location. The path should be clearly documented in the test plan so that all relevant personnel can quickly find the required files.

[0129] File Naming and Organization: Use clear naming conventions for test data and test firmware files, and organize the file structure logically to facilitate management and retrieval.

[0130] Finally, grant the test firmware the permission to call the first interface and the second interface. These interfaces are usually used to interact with the disk array, perform read-write operations, etc.

[0131] Permission Settings: Set the appropriate permissions at the system or hardware level based on the needs of the test firmware. This may involve modifying system configuration files, updating firmware settings, or using specific command-line tools.

[0132] Verify Permissions: After setting permissions, verify that the permissions are correctly granted by performing pre-tests or checking commands for the test firmware. This helps ensure that the test firmware can smoothly access the required interfaces and resources during the formal testing process.

[0133] For details, please refer to Figure 4 , multiple read-write modes include single strip full read-write, first IO cutting aggregation read-write, second IO cutting aggregation read-write, small write, and large write.

[0134] In a specific embodiment of the present application, the configuration method of multiple read-write modes is as follows:

[0135] (1) Single strip full read-write test case

[0136] Definition: Single strip full read-write test case is mainly used to test the performance and stability of the database or storage system when handling a large number of read-write operations.

[0137] Preparation phase: Determine the test target (such as a specific database table, file system, etc.), and prepare enough test data to approach or reach the maximum read-write capacity of the system.

[0138] Test steps:

[0139] Initialize the test environment, including connecting to the database or storage system.

[0140] Write scripts or programs to simulate high-concurrency read-write requests, ensuring that each request is as close as possible to or reaches the maximum processing capacity of the system.

[0141] Monitor the performance metrics of the system, such as response time, throughput, error rate, etc.

[0142] Verify the consistency and integrity of the data, ensuring that read and write operations do not cause data corruption or loss.

[0143] Expected result: The system should be able to run stably under high load, with performance metrics meeting expectations.

[0144] (2) Cutting and Aggregation Read-Write Test Case

[0145] Definition: Cutting and aggregation read-write test case may refer to the process of dividing a large amount of data into multiple parts (cutting) and then performing aggregation analysis or read-write operations on the data.

[0146] Preparation phase: Prepare a large amount of test data and design a reasonable cutting and aggregation strategy.

[0147] Test steps:

[0148] Cut the data into multiple parts according to certain rules.

[0149] Perform read-write operations on the cut data separately.

[0150] Aggregate the processed data and verify the correctness of the aggregation results.

[0151] Monitor the performance metrics during the entire processing process.

[0152] Expected result: Cutting and aggregation operations should be executed correctly, and the aggregation results should be consistent with expectations.

[0153] (3) Lowercase Test Case

[0154] Definition: Lowercase test case is mainly used to verify whether the behavior of the software system in processing all lowercase inputs meets expectations.

[0155] Preparation phase: Prepare all lowercase test data, such as usernames, passwords, text content, etc.

[0156] Test steps:

[0157] Enter all lowercase test data into the system.

[0158] Perform corresponding operations, such as login, query, submission, etc.

[0159] Verify whether the system can correctly process all lowercase inputs and return expected results.

[0160] Expected result: The system should be able to correctly process all lowercase inputs, and the returned results should meet expectations.

[0161] (4) Uppercase Test Case

[0162] Definition: Upper-case test case is similar to lower-case test case, but focuses on verifying the behavior of the software system when handling all upper-case inputs.

[0163] Preparation phase: Prepare test data in all upper-case.

[0164] Test steps:

[0165] Input test data in all upper-case into the system.

[0166] Perform corresponding operations.

[0167] Verify whether the system can correctly handle all upper-case inputs and return expected results.

[0168] Expected result: The system should be able to correctly handle all upper-case inputs and return results as expected.

[0169] S302, execute the test firmware.

[0170] The test firmware is executed; the test firmware reads the label of the detection data and parses the test time and test address from the label; the test firmware writes test data to the test address through the first interface at the test time in the write mode defined by the test case, and after the write operation is completed, it reads data from the test address through the first interface and the second interface in the read mode defined by the test case, respectively, to obtain first check data and second check data.

[0171] The self-test starting flow is controlled by the firmware, and the firmware provides an interface to specify the self-test starting time. The self-test can be triggered by the actual running IO ratio, or it can be triggered by external personnel through the external interface. In the case of triggering by the actual running IO ratio, the read-write inconsistency problem of the hardware in the actual environment can be detected. The other way is used for on-site viewing and confirming exceptions. Specifically, the following steps are included:

[0172] Once the test firmware is compiled and saved in the specified path, the tester will start or trigger the execution of the firmware. This step is the core part of the test process, which will perform a comprehensive check on the disk array according to the predefined test case.

[0173] (1) Read and parse the detection data label

[0174] During execution, the test firmware first accesses the saved detection data file. Each data file is accompanied by label information, which is the key for the test firmware to identify and parse the test requirements.

[0175] Read the tag: The test firmware opens the detection data file and reads the tag section in the file. The tag information is usually located at the head of the file or exists as metadata of the file.

[0176] Parse the tag: Key information is parsed from the tag, including test time, test address (which may include volume ID, array ID, volume logical address, hard disk logical address, etc.). These information will guide the subsequent read and write operations.

[0177] (2) Perform write and read operations

[0178] Based on the parsed test time and test address, the test firmware will perform the corresponding write and read operations according to the test case definition.

[0179] Write test data:

[0180] At the specified test time (or the time when the test firmware receives the execution command if the test time is not critical), the test firmware sends a write request to the test address through the first interface.

[0181] According to the write method defined in the test case, write test data to the specified location of the disk array.

[0182] After the write operation is completed, the test firmware will record the operation results and any possible errors or exceptions.

[0183] Read data and verify:

[0184] After the write operation is completed, the test firmware immediately or according to the time interval specified in the test case, sends a read request to the test address through the first interface and the second interface respectively.

[0185] Using the read method defined in the test case, the same as the corresponding write method, read data from the disk array.

[0186] The data read through the first interface generates the first verification data, and the data read through the second interface generates the second verification data.

[0187] Compare the two sets of verification data to verify the consistency and integrity of the data. At the same time, compare the verification data with the original detection data to ensure that the data has not been tampered with or damaged during transmission and storage.

[0188] (3) Record test results

[0189] The test firmware will record the results of each operation, including the success or failure of the write operation, the correctness of the read data, and any errors or exceptions. These records are crucial for subsequent problem analysis, troubleshooting, and test report writing.

[0190] In a specific embodiment of the present application, please refer to Figure 5 In actual operation, the control flow includes:

[0191] Write operation on the self-check area: the read and write operations on the self-check area are performed through a hardware-provided interface, and the written content is provided by the firmware. Generally, the written content provided by the firmware needs to be marked, and the content contains various tags, such as time, volume ID, array ID, volume LBA address, and hard disk LBA address information (the hard disk LBA address information is obtained by the firmware through a hardware interface or calculated by the firmware according to the data arrangement in the array).

[0192] Read operation on the self-check: after the data is written, the firmware performs a read operation on the same position again through the VOLUME interface.

[0193] Direct read operation on the hard disk through the DM interface.

[0194] S4, based on the matching degree of the read data and the write data, generate the detection result of the disk array card, please refer to Figure 6 .

[0195] S401, compare the consistency of the first check data, the second check data, and the test data.

[0196] Calculate the hash value of the first check data using the MD5 information digest algorithm to obtain a first hash value; calculate the hash value of the second check data using the MD5 information digest algorithm to obtain a second hash value; obtain the detection data cached by the test firmware and calculate the hash value to obtain a third hash value; compare the consistency of the first hash value, the second hash value, and the third hash value. The consistency of the first check data, the second check data, and the test data is determined by comparing the consistency of the hash values.

[0197] S402, analyze the comparison result.

[0198] If the first check data, the second check data, and the test data all remain consistent, it is determined that the disk array card is normal; if the first check data is different from the test data, and the first check data is the same as the second check data, it is determined that the write operation of the disk array card is abnormal; if the first check data is different from the test data, and the test data is the same as the second check data, it is determined that the read operation of the disk array card is abnormal; if the first check data is the same as the test data, and the first check data is different from the second check data, it is determined that the read and write positions of the disk array card are overall abnormal offset.

[0199] In some embodiments, the disk array card detection system can include a plurality of functional modules composed of computer program segments. The computer programs of each program segment in the disk array card detection system can be stored in the memory of the computer device and executed by at least one processor to perform the functions of (see detailed description) Figure 1 described) disk array card detection.

[0200] In this embodiment, the disk array card detection system can be divided into a plurality of functional modules according to the functions it performs, as shown in Figure 7 The functional modules of system 700 can include: region configuration module 710, interface definition module 720, read-write test module 730, and result analysis module 740. The module referred to in the present application refers to a series of computer program segments that can be executed by at least one processor and can complete a fixed function, which are stored in the memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0201] The region configuration module is configured to configure a self-test region for a volume in a disk array.

[0202] The interface definition module is configured to define a first interface at the volume level and a second interface at the hard disk management level.

[0203] The read-write test module is configured to write data to the self-test region through the first interface, and read data from the self-test region through the first interface and the second interface, respectively.

[0204] The result analysis module is configured to generate a detection result of the disk array card based on the matching degree of the read data and the write data.

[0205] Optionally, as one embodiment of the present application, the self-test region is configured for a volume in a disk array, comprising:

[0206] When creating a volume, a self-test region of 3 stripe sizes is reserved;

[0207] The self-test region is set in a hidden partition using a custom configuration function.

[0208] Optionally, as one embodiment of the present application, it further comprises:

[0209] Configure detection data and compile test firmware;

[0210] Save the detection data and the test firmware to a specified path;

[0211] Grant the test firmware the permission to call the first interface and the second interface.

[0212] Optionally, as one embodiment of the present application, the detection data is provided with a label, and the label includes time, volume ID, array ID, volume logical address, and hard disk logical address.

[0213] Optionally, as one embodiment of the present application, the test firmware includes:

[0214] a plurality of test cases, and the read-write modes adopted by the plurality of test cases cover all read-write modes supported by the disk array.

[0215] Optionally, as one embodiment of the present application, writing data to the self-check area through the first interface and reading data from the self-check area through the first interface and the second interface respectively includes:

[0216] executing the test firmware;

[0217] the test firmware reads the label of the detection data and parses test time and test address from the label;

[0218] the test firmware writes test data to the test address through the first interface at the test time according to the write mode defined by the test case, and reads data from the test address through the first interface and the second interface respectively after the write operation is completed according to the read mode defined by the test case, to obtain first check data and second check data.

[0219] Optionally, as one embodiment of the present application, based on the matching degree of the read data and the write data, a detection result of the disk array card is generated, including:

[0220] comparing the consistency of the first check data, the second check data, and the test data;

[0221] if the first check data, the second check data, and the test data all remain consistent, it is determined that the disk array card is normal;

[0222] if the first check data is different from the test data, and the first check data is the same as the second check data, it is determined that the write operation of the disk array card is abnormal;

[0223] if the first check data is different from the test data, and the test data is the same as the second check data, it is determined that the read operation of the disk array card is abnormal;

[0224] if the first check data is the same as the test data, and the first check data is different from the second check data, it is determined that the read-write position of the disk array card is overall abnormal offset.

[0225] Optionally, as one embodiment of the present application, comparing the consistency of the first check data, the second check data, and the test data includes:

[0226] Calculate the hash value of the first check data to obtain a first hash value;

[0227] Calculate the hash value of the second check data to obtain a second hash value;

[0228] Obtain the detection data of the test firmware cache, and calculate the hash value to obtain a third hash value;

[0229] Compare the consistency of the first hash value, the second hash value and the third hash value.

[0230] Figure 8 A structure schematic diagram of a terminal 800 is provided for the embodiments of the present application, and the terminal 800 can be used to execute the disk array card detection method provided by the embodiments of the present application.

[0231] The terminal 800 can include a processor 810, a memory 820 and a communication unit 830. These components communicate through one or more buses, and those skilled in the art can understand that the structure of the server shown in the figure does not constitute a limitation on the present application, which can be a bus structure or a star structure, and can include more or fewer components than shown in the figure, or combine some components, or different component arrangements.

[0232] The memory 820 can be used to store the execution instructions of the processor 810, and the memory 820 can be realized by any type of volatile or non-volatile storage terminal or their combination, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk. When the execution instructions in the memory 820 are executed by the processor 810, the terminal 800 can execute part or all of the steps in the following method embodiments.

[0233] The processor 810 is the control center of the storage terminal, which connects all parts of the electronic terminal through various interfaces and lines, executes the software programs and / or modules stored in the memory 820, and calls the data stored in the memory, to execute various functions of the electronic terminal and / or process data. The processor can be composed of integrated circuits (IC), for example, it can be composed of a single packaged IC, or it can be composed of multiple packaged ICs with the same function or different functions. For example, the processor 810 can only include a central processing unit (CPU). In the embodiments of the present application, the CPU can be a single operation core, or can include multiple operation cores.

[0234] The communication unit 830 is configured to establish a communication channel, so that the storage terminal can communicate with other terminals. The communication unit 830 receives user data sent by other terminals or sends user data to other terminals.

[0235] The present application also provides a computer storage medium, wherein the computer storage medium can store a program, and the program can include some or all steps in the embodiments provided by the present application when executed. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM) and the like.

[0236] Therefore, the present application configures a self-checking area for a volume in a disk array architecture, and can avoid the problem of bulk data damage caused by hardware exceptions through runtime self-checking, and avoid the damage of other programs to the detection data. Meanwhile, through the additional interfaces at different levels, the influence of other levels is bypassed, and the precise test for the read-write function of the disk array card is realized. The technical effects that can be achieved by the present embodiment can be referred to the description in the foregoing, and will not be described here.

[0237] Those skilled in the art can clearly understand that the technology in the embodiments of the present application can be realized by means of software and necessary general hardware platforms. Based on such understanding, the technical solutions in the embodiments of the present application can be embodied in the form of a software product, which is stored in a storage medium such as a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and the like, and includes a plurality of instructions for causing a computer terminal (which can be a personal computer, a server, or a second terminal, a network terminal, etc.) to execute all or part of the steps of the method described in the embodiments of the present application.

[0238] In the present specification, the same or similar parts among various embodiments can be referred to each other. Especially, for the terminal embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

[0239] In several embodiments provided by the present application, it should be understood that the disclosed system and method can be implemented in other manners. For example, the system embodiments described above are merely schematic. For example, the division of the modules is only a logical function division. There can be another division manner for the actual implementation. For example, a plurality of modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between different modules can be indirect couplings or communication connections through some interfaces, and electrical, mechanical or other forms.

[0240] The modules illustrated as separated components can or can not be physically separated, and the components illustrated as modules can or can not be physical modules, i.e., can be located in one place, or can be distributed to a plurality of network modules. Part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiment.

[0241] In addition, each functional module in each embodiment of the present application can be integrated into a processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0242] Although the present application has been described in detail by referring to the preferred embodiments thereof, it is to be understood that the present application is not limited to the embodiments described above. Rather, it should be appreciated that those skilled in the art, upon consideration of the disclosure, can make modifications and / or improvements to the embodiments of the application without deviating from the spirit and scope of the application. Any modifications and / or improvements made to the embodiments of the application by those skilled in the art are to be considered within the scope of the application.

Claims

1. A method for detecting a disk array card, characterized in that, include: Configure a self-test zone for the volume in the disk array; Define the first interface at the volume level and the second interface at the disk management level; Data is written to the self-test area through the first interface, and data is read from the self-test area through the first interface and the second interface respectively. The detection results of the disk array card are generated based on the matching degree of read data and write data; The method further includes: Configure the detection data and compile the test firmware; Save the detection data and the test firmware to the specified path; Grant the test firmware permission to call the first interface and the second interface; The detection data is tagged, and the tags include time, volume ID, array ID, volume logical address, and hard disk logical address; The test firmware includes: Multiple test cases, and the read / write methods used in these test cases cover all read / write methods supported by the disk array.

2. The method according to claim 1, characterized in that, Configure a self-test zone for the volume in the disk array, including: When creating the volume, reserve a self-check area of ​​3 stripe sizes; Use the custom configuration function to set the self-test area in a hidden partition.

3. The method according to claim 1, characterized in that, Writing data to the self-test area through the first interface, and reading data from the self-test area through the first interface and the second interface respectively, includes: Execute the test firmware; The test firmware reads the tags of the detection data and parses the test time and test address from the tags; The test firmware writes test data to the test address through the first interface according to the write method specified by the test case during the test time, and reads data from the test address through the first interface and the second interface respectively according to the read method specified by the test case after the write operation is completed, to obtain the first verification data and the second verification data.

4. The method according to claim 3, characterized in that, Based on the matching degree between read and write data, the detection results of the disk array card are generated, including: Compare the consistency of the first verification data, the second verification data, and the test data; If the first verification data, the second verification data, and the test data are all consistent, then the disk array card is considered to be normal. If the first verification data is different from the test data, and the first verification data is the same as the second verification data, then the write operation of the disk array card is determined to be abnormal. If the first verification data is different from the test data, and the test data is the same as the second verification data, then the read operation of the disk array card is determined to be abnormal. If the first verification data is the same as the test data, and the first verification data is different from the second verification data, then the read / write position of the disk array card is determined to be abnormally offset.

5. The method according to claim 4, characterized in that, Compare the consistency of the first verification data, the second verification data, and the test data, including: Calculate the hash value of the first verification data to obtain the first hash value; Calculate the hash value of the second verification data to obtain the second hash value; Obtain the detection data cached in the test firmware and calculate the hash value to obtain the third hash value; Compare the consistency of the first hash value, the second hash value, and the third hash value.

6. A terminal, characterized in that, include: The memory is used to store the disk array card detection program; A processor is configured to implement the steps of the disk array card detection method as described in any one of claims 1-5 when executing the disk array card detection program.

7. A computer-readable storage medium storing a computer program, characterized in that, The readable storage medium stores a disk array card detection program, which, when executed by a processor, implements the steps of the disk array card detection method as described in any one of claims 1-5.

Images