Disk array card detection method, terminal and storage medium

Abstract

The invention relates to the technical field of storage, and particularly provides a disk array card detection method, a terminal and a storage medium, and the method comprises the steps: configuring a self-inspection 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. According to the invention, accurate testing of the read-write function of the disk array card is realized.

Description

Technical Field

[0001] The invention belongs to the field of storage technology, and in particular relates to a disk array card detection method, a terminal and a storage medium. Background Art

[0002] Array card, full name disk array card, is designed for building RAID (Redundant Array of Independent Disks) system. RAID system integrates multiple hard disk drives into a logical unit according to specific rules and is efficiently managed by a dedicated array controller, thereby enhancing the reliability, performance and capacity of data storage. Inside the RAID card, dozens of sophisticated hardware IP modules are integrated, each with its own responsibilities: some focus on parsing high-speed nvme instructions, some are responsible for the smooth transmission of DMA (direct memory access), and there are modules responsible for precise interaction with hard disks and resource optimization and recovery. Taking the PCIe 4.0 interface as an example, the card can handle up to 64Gbps of data traffic per second, demonstrating its powerful data processing capabilities.

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

[0004] To address this problem, traditional detection methods usually involve reading data immediately after writing it to the interface layer, and verifying the consistency of the read and written data. However, this method has limitations, because read-write inconsistencies may not only be caused by disk array anomalies, but may also be caused by problems at other levels or the detection data is accidentally overwritten by external program data. Therefore, simply relying on such detection methods to evaluate the health status of RAID card function modules is often difficult to achieve the ideal level of accuracy, and a more comprehensive and accurate monitoring and diagnosis strategy is urgently needed to ensure the stable operation of the data center. Summary of the invention

[0005] In view of the above-mentioned deficiencies in the prior art, the present invention provides a disk array card detection method, a terminal and a storage medium to solve the above-mentioned technical problems.

[0006] In a first aspect, the present invention provides a disk array card detection method, comprising: Configure a self-check area for the volume in the disk array; A first interface defining a volume level and a second interface defining a disk management level; 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; Based on the matching degree between the read data and the write data, the detection result of the disk array card is generated.

[0007] In an optional implementation, configuring a self-check area for a volume in a disk array includes: When creating a volume, a self-check area of ​​3 stripes is reserved; The self-check area is set in a hidden partition by using a custom configuration function.

[0008] In an optional embodiment, the method further comprises: Configure detection data and compile test firmware; Saving the detection data and the test firmware to a specified path; The test firmware is granted permission to call the first interface and the second interface.

[0009] In an optional implementation, 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.

[0010] In an optional embodiment, the test firmware includes: Multiple test cases, where the reading and writing methods adopted by the multiple test cases cover all reading and writing methods supported by the disk array.

[0011] In an optional implementation, 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, comprises: Executing the test firmware; The test firmware reads the label of the detection data and parses the test time and the test address from the label; The test firmware writes test data to the test address through the first interface at the test time in a write mode specified by the test case, and reads data from the test address through the first interface and the second interface respectively in a read mode specified by the test case after the write operation is completed to obtain first verification data and second verification data.

[0012] In an optional implementation, generating a detection result of the disk array card based on the matching degree between the read data and the write data includes: Comparing 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, it is determined that the disk array card is 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, it is determined that the write operation of the disk array card is abnormal; If the first verification data is different from the test data, and the test data is the same as the second verification data, it is determined that the read operation of the disk array card is 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, it is determined that the read and write positions of the disk array card are abnormally offset as a whole.

[0013] In an optional implementation, comparing the consistency of the first verification data, the second verification data, and the test data includes: Calculate a hash value of the first verification data to obtain a first hash value; Calculate a hash value of the second verification data to obtain a second hash value; Obtaining detection data cached by the test firmware, and calculating a hash value to obtain a third hash value; The first hash value, the second hash value, and the third hash value are compared for consistency.

[0014] In a second aspect, the present invention provides a disk array card detection system, comprising: A zone configuration module, used to configure a self-check zone for a volume in a disk array; An interface definition module, used to define a first interface at a volume level and a second interface at a hard disk management level; a read-write test module, used for 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; The result analysis module is used to generate the detection result of the disk array card based on the matching degree between the read data and the write data.

[0015] In a third aspect, a terminal is provided, including: processor, memory, wherein: The memory is used to store computer programs. The processor is used to call and run the computer program from the memory, so that the terminal executes the above-mentioned terminal method.

[0016] According to a fourth aspect, a computer storage medium is provided, wherein the computer-readable storage medium stores instructions, and when the instructions are executed on a computer, the computer executes the methods described in the above aspects.

[0017] The beneficial effect of the present invention is that the disk array card detection method, terminal and storage medium provided by the present invention configure a self-check area for the volume in the disk array architecture, and the problem of batch data damage caused by hardware abnormalities can be avoided through self-checking during runtime, and the damage to the detection data by other programs can be avoided. At the same time, by adding interfaces at different levels, the influence of other levels is bypassed, and accurate testing of the read and write functions of the disk array card is achieved.

[0018] In addition, the invention has a reliable design principle, a simple structure and a very broad application prospect. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0020] Figure 1 is a schematic flow chart of a method according to an embodiment of the present invention.

[0021] Figure 2 is another schematic flow chart of a method according to an embodiment of the present invention.

[0022] Figure 3 It is a schematic diagram of a disk array architecture of a method according to an embodiment of the present invention.

[0023] Figure 4 It is a schematic diagram of the reading and writing method of a method according to an embodiment of the present invention.

[0024] Figure 5 It is a schematic principle diagram of the read-write test of the method according to an embodiment of the present invention.

[0025] Figure 6 It is a schematic principle diagram of the test result analysis of the method according to an embodiment of the present invention.

[0026] Figure 7 is a schematic block diagram of a system according to an embodiment of the present invention.

[0027] Figure 8 A schematic diagram of the structure of a terminal provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0028] In order to enable those skilled in the art to better understand the technical solutions in the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0029] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present invention. The terms used in the specification of the present invention herein are only for the purpose of describing specific embodiments and are not intended to limit the present invention.

[0030] The key terms appearing in the present invention are explained below.

[0031] RAID: Redundant Array of Independent Disks Redundant array composed of independent disks. The redundant array composed of member disks can effectively improve data reliability and I / O performance. Using this technology, data is divided into many segments and stored on each disk.

[0032] Linked list: A data structure in computer programming that contains data and a pointer to the next data. The linked list structure is more friendly to insertion and deletion operations and can reduce the number of data movements compared to arrays.

[0033] RAID card: A device that can create a hard disk RAID group. It can increase the data access speed by accessing multiple disks in parallel, and also provides the ability to perform redundant error correction on the data.

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

[0035] Skip list: A skip list is a data structure used to implement ordered sets. A skip list speeds up search, insertion, and deletion operations in a probabilistic hierarchical manner by adding some extra pointers on each level. This makes the skip list have performance similar to a balanced tree in some aspects, but its implementation is relatively simple.

[0036] Logical address (LBA): The address passed when the HOST side reads and writes data on the RAID. This is a logical address, not the actual physical address of the hard disk. In RAID, the real data of the hard disk is accessed through the mapping of logical addresses and physical addresses.

[0037] Physical address (PBA): This refers to the address provided by the physical disk. Although the address provided by the SSD disk is actually the logical address of the disk layer, in this article, the address provided by the physical disk is collectively referred to as the physical address and no distinction is made.

[0038] Disk Management (DM): The disk management layer is mainly responsible for IO reading and writing from the hard disk.

[0039] Volume (VOL): Volume level, located at the top of the RAID array. You can increase the flexibility of space utilization by creating volumes on the RAID array.

[0040] NVMe module: mainly processes external NVMe commands, or packages the internal information that needs to be returned into the NVMe command format.

[0041] Host (HOST): The host layer can be considered as the usual PC operating system layer.

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

[0043] Figure 1 is a schematic flow chart of a method according to an embodiment of the present invention. Figure 1 The execution subject may be a disk array card detection system. According to different requirements, the order of the steps in the flow chart may be changed, and some may be omitted.

[0044] like Figure 1 As shown, the method includes: Step 110, configuring a self-check area for the volume in the disk array; Step 120, defining a first interface at the volume level and a second interface at the disk management level; 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; Step 140: Generate a detection result of the disk array card based on the matching degree between the read data and the write data.

[0045] In one embodiment, the detailed description of each step includes: Step 110, configure a self-check area for the volume in the disk array: First, clarify the location and size of the self-test area. The administrator needs to log in to the disk array management interface and select a specific logical volume or physical area as the self-test area. This area will be dedicated to storing data for subsequent self-test and verification, ensuring that it does not overlap with other business data to avoid interference. According to the capacity and performance requirements of the disk array and the expected self-test frequency, the size of the self-test area should be reasonably planned.

[0046] Step 120, define a first interface at the volume level and a second interface at the disk management level: First interface: An interface is defined at the volume level to interact with the operating system or upper-layer application to implement data writing and preliminary processing. This interface is responsible for mapping the data that needs to be self-checked to the self-checking area through the logical volume to ensure the consistency and integrity of the data at the logical level.

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

[0048] 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: Write data: Use the first interface of the volume layer to write the preset test data or data of a specific pattern into the self-check area. These data can be simple sequence numbers, random data, or data blocks with specific checksums to facilitate subsequent verification.

[0049] Read data: First, read the data in the self-test area from the logical level through the first interface to verify whether the data is written successfully and whether the data is processed accurately by the logical level. Then, read the data in the same area directly from the hard disk management level through the second interface to verify the data consistency at the physical level and the hard disk's reading ability.

[0050] Step 140, based on the matching degree between the read data and the write data, generate the detection result of the disk array card: Data comparison: Compare the data read through the two interfaces with the original written data and 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.

[0051] Result analysis: Based on the comparison results, analyze whether there are any problems with the disk array card and the hard disk it manages. If the read data is exactly the same as the written data, it means that the disk array card and the hard disk are working properly; if there is a difference, it may indicate a hardware failure, data transmission error, or a problem at the logic level.

[0052] Generate report: Organize the detection results into a report, including detection time, detection object, specific error details and recommended repair measures, etc., for administrators' reference and decision-making.

[0053] Through the above steps, you can effectively perform self-detection on the disk array card and the hard disks it manages, discover and deal with potential problems in a timely manner, and ensure data security and system stability.

[0054] To facilitate understanding of the present invention, the disk array card detection method provided by the present invention is further described below based on the principle of the disk array card detection method of the present invention and the process of detecting the disk array card in the embodiment.

[0055] For details, please refer to Figure 2 , the disk array card detection method includes: S1. Configure a self-test area for the volume in the disk array.

[0056] When creating a volume, a self-check area of ​​3 stripes is reserved; the self-check area is set in the hidden partition by using the custom configuration function.

[0057] A basic RAID hierarchy, with each layer explained from top to bottom, is as follows: HOST layer: refers to the host side. The volumes created on the RAID card are displayed on the HOST side in the form of nvme devices.

[0058] NVMe layer: The layer inside the RAID card that is responsible for handling NVMe command processing and for command interaction with the HOST.

[0059] VOL layer: volume level, which mainly contains some basic information of the volume, including name, start and end LBA addresses, etc. Each volume corresponds to an NS of the NVMe layer.

[0060] RAID layer: The RAID layer mainly divides the hard disk space into strips for volume use. The space source when the volume is created is directly obtained through mapping.

[0061] DM layer: The DM layer is mainly responsible for hard disk management and hard disk IO interaction. All write and read operations on the hard disk will pass through here.

[0062] Each layer has its own submodules. If an exception occurs in the data processing of a submodule in each layer, it is usually not easy to be discovered. Usually, the data written by the user will not be discovered until the next read, and the amount of erroneous data generated during this period cannot be evaluated. Among them, the volume level mainly performs some simple address mapping to convert the IO operation of the volume to the RAID level. The IO operation at the RAID level is more complicated. There are usually multiple read and write operation processes, usually stripe splitting and result aggregation. There are also uppercase, lowercase, full stripe writes, and P, Q check value calculations for RAID5 and RAID6 in the writing method. In addition, when actually writing data, the data must be split onto each disk. The business process and algorithm for sorting are relatively complex and prone to exceptions. This part is also the part that is prone to problems.

[0063] Please refer to Figure 3 , a portion of space (C4, C9, C13) is reserved in each volume as a self-check area. The retention of this area is not perceived by the upper-layer NVMe, nor by the lower-layer RAID. The size of this self-check area is usually enough for 3 stripes.

[0064] The method for setting the self-check area includes: using a custom configuration function to set the self-check area in a hidden partition.

[0065] S2, defining a first interface at the volume level and a second interface at the disk management level.

[0066] A first interface capable of managing volumes and a second interface capable of directly managing hard disks are defined respectively.

[0067] In one embodiment of the present invention, the following method is used to define the interface: The first interface for nova to access the VOLUME layer is defined in the nova / volume directory.

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

[0069] S3. Reading and writing test.

[0070] S301. Document preparation.

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

[0072] 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.

[0073] The test firmware includes multiple test cases, and the reading and writing methods adopted by the multiple test cases cover all reading and writing methods supported by the disk array.

[0074] The specific steps include: First, configure the test data according to the test requirements. This data is not only used to test the performance and reliability of the disk array, but also to verify data integrity and system response. The test data is given a unique label so that it can be easily tracked and identified during and after the test.

[0075] Tag settings: Each detection data block is attached with a tag containing multiple fields, including but not limited to: Time: The timestamp when the data is generated or configured.

[0076] Volume ID: Identifies the specific logical volume to which the data belongs.

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

[0078] Volume logical address: location information in the logical volume.

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

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

[0081] 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.

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

[0083] 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.

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

[0085] Specify the path: Choose an easily accessible and protected directory as the storage location. This path should be clearly documented in the test plan so that all stakeholders can quickly find the required files.

[0086] File naming and organization: Use clear naming conventions for test data and test firmware files, and organize the files in a reasonable structure for easy management and retrieval.

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

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

[0089] Verify permissions: After setting permissions, verify that permissions are granted correctly by executing pre-test or check commands of the test firmware. This helps ensure that the test firmware can successfully access the required interfaces and resources during the formal test process.

[0090] For details, please refer to Figure 4 , multiple read and write modes include single-strip full read and write, first type IO split aggregate read and write, second type IO split aggregate read and write, lowercase, and uppercase.

[0091] In a specific implementation of the present invention, the configuration method of multiple reading and writing modes is as follows: (1) Single-strip full read and write test case Definition: The single-strip full read and write test case is mainly used to test the performance and stability of the database or storage system when processing a large number of read and write operations.

[0092] 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 and write capacity of the system.

[0093] Test steps: Initialize the test environment, including connecting to the database or storage system.

[0094] Write scripts or programs to simulate high-concurrency read and write requests to ensure that each request is as close to or as close to the system's maximum processing capacity as possible.

[0095] Monitor system performance indicators such as response time, throughput, error rate, etc.

[0096] Verify data consistency and integrity to ensure that read and write operations do not result in data corruption or loss.

[0097] Expected results: The system should be able to run stably under high load and the performance indicators should meet expectations.

[0098] (2) Split aggregation read and write test cases Definition: Split aggregation read and write test cases may refer to the test of splitting (slicing) a large amount of data before performing aggregation analysis or read and write operations during the test process.

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

[0100] Test steps: Cut the data into multiple parts according to certain rules.

[0101] Read and write the cut data respectively.

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

[0103] Monitor performance indicators throughout the process.

[0104] Expected Results: The cutting and aggregation operations should be performed correctly and the aggregation results should be consistent with expectations.

[0105] (3) Lowercase test cases Definition: Lowercase test cases are mainly used to verify whether the behavior of the software system is as expected when processing all-lowercase input.

[0106] Preparation stage: Prepare all lowercase test data, such as user names, passwords, text content, etc.

[0107] Test steps: Enter the test data into the system in all lowercase letters.

[0108] Perform corresponding operations, such as login, query, submit, etc.

[0109] Verify that the system can correctly handle all-lowercase input and return the expected results.

[0110] Expected results: The system should be able to correctly process all-lowercase input and return results as expected.

[0111] (4) Uppercase test cases Definition: Uppercase test cases are similar to lowercase test cases, but focus on verifying the behavior of the software system when processing all-uppercase input.

[0112] Preparation stage: Prepare all-capital test data.

[0113] Test steps: Enter the test data into the system in all caps.

[0114] Perform the corresponding action.

[0115] Verify that the system handles all-uppercase input correctly and returns the expected results.

[0116] Expected results: The system should be able to correctly process all-uppercase input and return results as expected.

[0117] S302, execute the test firmware.

[0118] Execute the test firmware; 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 the test data to the test address through the first interface at the test time in a write mode specified by the test case, and reads data from the test address through the first interface and the second interface respectively in a read mode specified by the test case after the write operation is completed, to obtain first verification data and second verification data.

[0119] The firmware controls the self-test startup process. The firmware provides an external interface to specify the self-test startup time. The self-test can be triggered at the actual IO ratio, or it can be triggered by an external person through an external interface. When triggered at the actual IO ratio, the read-write inconsistency problem caused by the hardware running in the actual environment can be detected. Another method is used for on-site inspection and confirmation of abnormalities. Specifically, it includes the following steps: 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 conduct a comprehensive check on the disk array according to the predefined test cases.

[0120] (1) Read and parse detection data tags During the execution process, the test firmware first accesses the saved detection data files. Each data file is accompanied by tag information, which is the key for the test firmware to identify and parse the test requirements.

[0121] Read tag: The test firmware opens the detection data file and reads the tag part of the file. The tag information is usually located in the header of the file or exists as the metadata of the file.

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

[0123] (2) Perform write and read operations Based on the parsed test time and test address, the test firmware will perform corresponding write and read operations according to the limitations of the test case.

[0124] Write test data: At the designated test time (or the instant 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.

[0125] Write the test data to the specified location of the disk array according to the writing method specified by the test case.

[0126] After the write operation is complete, the test firmware records the results of the operation and any errors or anomalies that may have occurred.

[0127] Read data and verify: After the write operation is completed, the test firmware sends a read request to the test address through the first interface and the second interface respectively immediately or at a time interval specified by the test case.

[0128] Use the read method defined by the test case, the same as the corresponding write method, to read data from the disk array.

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

[0130] The two sets of verification data are compared to verify the consistency and integrity of the data. At the same time, the verification data is compared with the original test data to ensure that the data has not been tampered with or damaged during transmission and storage.

[0131] (3) Record test results The test firmware records the results of each operation, including the success or failure of the write operation, the correctness of the read data, and any errors or abnormalities. These records are crucial for subsequent problem analysis, troubleshooting, and test report writing.

[0132] In a specific embodiment of the present invention, please refer to Figure 5 ,In the actual operation process, the control process includes: Write to the self-test area: The read and write operations on the self-test area are performed through the interface provided by the hardware. The write content is provided by the firmware. Usually, the write 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 firmware obtains through the hardware interface or calculates it according to the data arrangement in the array).

[0133] Read the self-test: After the data is written, the firmware reads the same location again through the VOLUME interface.

[0134] The DM interface is used to directly read the hard disk.

[0135] S4. Generate the disk array card detection result based on the matching degree of read data and write data. Please refer to Figure 6 .

[0136] S401 : Compare the consistency of the first verification data, the second verification data and the test data.

[0137] Calculate the hash value of the first verification data using the MD5 information digest algorithm to obtain a first hash value; calculate the hash value of the second verification 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. Determine the consistency of the first verification data, the second verification data and the test data by comparing the consistency of the hash values.

[0138] S402: Analyze the comparison results.

[0139] If the first verification data, the second verification data and the test data are all consistent, it is determined that the disk array card is 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, it is determined that the write operation of the disk array card is abnormal; if the first verification data is different from the test data, and the test data is the same as the second verification data, it is determined that the read operation of the disk array card is 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, it is determined that the read and write position of the disk array card is abnormally offset as a whole.

[0140] In some embodiments, the disk array card detection system may include multiple functional modules composed of computer program segments. The computer programs of the various program segments in the disk array card detection system may be stored in a memory of a computer device and executed by at least one processor to perform (see Figure 1 Description) Disk array card detection function.

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

[0142] A zone configuration module, used to configure a self-check zone for a volume in a disk array; An interface definition module, used to define a first interface at a volume level and a second interface at a hard disk management level; a read-write test module, used for 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; The result analysis module is used to generate the detection result of the disk array card based on the matching degree between the read data and the write data.

[0143] Optionally, as an embodiment of the present invention, configuring a self-check area for a volume in a disk array includes: When creating a volume, a self-check area of ​​3 stripes is reserved; The self-check area is set in a hidden partition by using a custom configuration function.

[0144] Optionally, as an embodiment of the present invention, it further includes: Configure detection data and compile test firmware; Saving the detection data and the test firmware to a specified path; The test firmware is granted permission to call the first interface and the second interface.

[0145] Optionally, as an embodiment of the present invention, 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.

[0146] Optionally, as an embodiment of the present invention, the test firmware includes: Multiple test cases, where the reading and writing methods adopted by the multiple test cases cover all reading and writing methods supported by the disk array.

[0147] Optionally, as an embodiment of the present invention, 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: Executing the test firmware; The test firmware reads the label of the detection data and parses the test time and the test address from the label; The test firmware writes test data to the test address through the first interface at the test time in a write mode specified by the test case, and reads data from the test address through the first interface and the second interface respectively in a read mode specified by the test case after the write operation is completed to obtain first verification data and second verification data.

[0148] Optionally, as an embodiment of the present invention, generating a detection result of the disk array card based on the matching degree of the read data and the write data includes: Comparing 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, it is determined that the disk array card is 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, it is determined that the write operation of the disk array card is abnormal; If the first verification data is different from the test data, and the test data is the same as the second verification data, it is determined that the read operation of the disk array card is 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, it is determined that the read and write positions of the disk array card are abnormally offset as a whole.

[0149] Optionally, as an embodiment of the present invention, comparing the consistency of the first verification data, the second verification data and the test data includes: Calculate a hash value of the first verification data to obtain a first hash value; Calculate a hash value of the second verification data to obtain a second hash value; Obtaining detection data cached by the test firmware, and calculating a hash value to obtain a third hash value; The first hash value, the second hash value, and the third hash value are compared for consistency.

[0150] Figure 8 The present invention provides a schematic diagram of the structure of a terminal 800 provided in an embodiment of the present invention. The terminal 800 can be used to execute the disk array card detection method provided in an embodiment of the present invention.

[0151] The terminal 800 may include: a processor 810, a memory 820 and a communication unit 830. These components communicate via one or more buses. Those skilled in the art will appreciate that the server structure shown in the figure does not limit the present invention, and it may be a bus structure or a star structure, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0152] The memory 820 can be used to store the execution instructions of the processor 810, and the memory 820 can be implemented by any type of volatile or non-volatile storage terminal or a combination thereof, 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 memory, 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 perform some or all of the steps in the following method embodiments.

[0153] The processor 810 is the control center of the storage terminal, and uses various interfaces and lines to connect various parts of the entire electronic terminal. It runs or executes software programs and / or modules stored in the memory 820, and calls data stored in the memory to perform various functions of the electronic terminal and / or process data. The processor can be composed of an integrated circuit (IC), for example, it can be composed of a single packaged IC, or it can be composed of multiple packaged ICs with the same or different functions. For example, the processor 810 can include only a central processing unit (CPU). In the embodiment of the present invention, the CPU can be a single computing core or multiple computing cores.

[0154] The communication unit 830 is used to establish a communication channel so that the storage terminal can communicate with other terminals, receive user data sent by other terminals or send user data to other terminals.

[0155] The present invention also provides a computer storage medium, wherein the computer storage medium may store a program, and when the program is executed, the program may include some or all of the steps in each embodiment provided by the present invention. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM).

[0156] Therefore, the present invention configures a self-check area for the volume in the disk array architecture. The self-check during runtime can avoid the problem of batch data damage caused by hardware abnormalities and avoid the damage of other programs to the test data. At the same time, by adding interfaces at different levels, the influence of other levels is bypassed to achieve accurate testing of the read and write functions of the disk array card. The technical effects that can be achieved by this embodiment can be found in the description above and will not be repeated here.

[0157] Those skilled in the art can clearly understand that the technology in the embodiments of the present invention can be implemented by means of software plus a necessary general hardware platform. Based on this understanding, the technical solution in the embodiments of the present invention, in essence or in other words, the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, and other media that can store program codes, including several instructions for enabling 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 methods described in each embodiment of the present invention.

[0158] In this specification, the same or similar parts between the various embodiments can be referred to each other. In particular, for the terminal embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description in the method embodiment.

[0159] In the several embodiments provided by the present invention, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of systems or modules, which can be electrical, mechanical or other forms.

[0160] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0161] In addition, each functional module in each embodiment of the present invention may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0162] Although the present invention has been described in detail with reference to the accompanying drawings and in combination with the preferred embodiments, the present invention is not limited thereto. Without departing from the spirit and essence of the present invention, a person of ordinary skill in the art may make various equivalent modifications or substitutions to the embodiments of the present invention, and these modifications or substitutions shall be within the scope of the present invention. Any person of ordinary skill in the art may easily think of changes or substitutions within the technical scope disclosed by the present invention, and these shall be within the scope of protection of the present invention.

Claims

1. A disk array card detection method, characterized in that: include: Configure a self-check area for the volume in the disk array; A first interface defining a volume level and a second interface defining a disk management level; 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; Based on the matching degree between the read data and the write data, the detection result of the disk array card is generated.

2. The method according to claim 1, characterized in that Configure the self-test area for the volume in the disk array, including: When creating a volume, a self-check area of ​​3 stripes is reserved; The self-check area is set in a hidden partition by using a custom configuration function.

3. The method according to claim 1, characterized in that The method further comprises: Configure test data and compile test firmware; Saving the detection data and the test firmware to a specified path; The test firmware is granted permission to call the first interface and the second interface.

4. The method according to claim 3, characterized in that 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.

5. The method according to claim 4, characterized in that The test firmware includes: Multiple test cases, where the reading and writing methods adopted by the multiple test cases cover all reading and writing methods supported by the disk array.

6. The method according to claim 5, characterized in that 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, comprising: Executing the test firmware; The test firmware reads the label of the detection data and parses the test time and the test address from the label; The test firmware writes test data to the test address through the first interface at the test time in a write mode specified by the test case, and reads data from the test address through the first interface and the second interface respectively in a read mode specified by the test case after the write operation is completed to obtain first verification data and second verification data.

7. The method according to claim 6, characterized in that Based on the matching degree of read data and write data, the disk array card detection results are generated, including: Comparing 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, it is determined that the disk array card is 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, it is determined that the write operation of the disk array card is abnormal; If the first verification data is different from the test data, and the test data is the same as the second verification data, it is determined that the read operation of the disk array card is 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, it is determined that the read and write positions of the disk array card are abnormally offset as a whole.

8. The method according to claim 7, characterized in that Comparing the consistency of the first verification data, the second verification data and the test data, including: Calculate a hash value of the first verification data to obtain a first hash value; Calculate a hash value of the second verification data to obtain a second hash value; Obtaining detection data cached by the test firmware, and calculating a hash value to obtain a third hash value; The first hash value, the second hash value, and the third hash value are compared for consistency.

9. A terminal, characterized in that: include: A memory, used for storing a disk array card detection program; A processor is used to implement the steps of the disk array card detection method according to any one of claims 1 to 8 when executing the disk array card detection program.

10. A computer-readable storage medium storing a computer program, characterized in that: The readable storage medium stores a disk array card detection program, and when the disk array card detection program is executed by the processor, the steps of the disk array card detection method according to any one of claims 1 to 8 are implemented.

Images