Hard disk testing method, electronic device, medium, and computer program product

Abstract

This application discloses a hard disk testing method, electronic device, medium, and computer program product, relating to the field of hard disk testing technology. The method includes: responding to a first target address range and a data pattern identifier indicated in a pre-embedding instruction; marking bits in a bitmap corresponding to the first target address range as pre-embedded; associating the data pattern identifier with the bits marked as pre-embedded; responding to a second target address range indicated in a read instruction; determining a first bit in the bitmap corresponding to the second target address range; and, if at least some bits in the first bit are in a pre-embedded state, generating first test data based on the data pattern identifier associated with the pre-embedded bits in the first bit; and performing hard disk testing based on the first test data. This application embodiment allows hard disk testing without pre-embedded data, improving testing efficiency and reducing hard disk wear.

Description

Technical Field

[0001] This application relates to the field of hard disk testing technology, and in particular to a hard disk testing method, electronic device, medium, and computer program product. Background Technology

[0002] When testing the performance of a hard drive, it is generally necessary to pre-embed data in a certain logical block address (LBA) range of the hard drive. The performance of the hard drive can then be tested by reading this pre-embedded data.

[0003] However, pre-embedding data in the hard drive leads to problems such as low efficiency and reduced hard drive lifespan. Therefore, how to conduct hard drive testing efficiently has become an urgent problem to be solved. Summary of the Invention

[0004] This application provides a hard disk testing method, electronic device, media, and computer program product to improve hard disk testing efficiency.

[0005] This application provides a hard disk testing method, comprising: constructing a bitmap, wherein each bit in the bitmap corresponds to a portion of the logical block address range in the hard disk, and each bit in the bitmap is marked as unembedded; responding to a first target address range and a data pattern identifier indicated in an embedding instruction, marking the bits in the bitmap corresponding to the first target address range as pre-embedded, and associating the data pattern identifier with the bits marked as pre-embedded; responding to a second target address range indicated in a read instruction, determining a first bit in the bitmap corresponding to the second target address range, and, if at least some bits in the first bit are in a pre-embedded state, generating first test data based on the data pattern identifier associated with the pre-embedded bits in the first bit; and testing the hard disk based on the first test data.

[0006] This application also provides a hard disk testing apparatus, comprising: a bitmap construction module for constructing a bitmap, wherein each bit in the bitmap corresponds to a portion of the logical block address range in the hard disk, and each bit in the bitmap is marked as unembedded; an embedding module for, in response to a first target address range and a data pattern identifier indicated in an embedding instruction, marking the bits in the bitmap corresponding to the first target address range as embedded, and associating the data pattern identifier with the bits marked as embedded; a reading module for, in response to a second target address range indicated in a reading instruction, determining a first bit in the bitmap corresponding to the second target address range, and generating first test data based on the data pattern identifier associated with the bits in the first bit that are embedded, provided that at least some bits in the first bit are in an embedded state; and a hard disk testing module for testing the hard disk based on the first test data.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described hard disk testing methods.

[0008] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described hard disk testing methods.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described hard disk testing methods.

[0010] This application enables the generation of a bitmap corresponding to a portion of the logical block address range of the hard disk during hard disk testing. By using a pre-embedded instruction to indicate a first target address range and a data pattern identifier, the bit corresponding to the first target address range can be found in the bitmap and marked as pre-embedded. This bit is then associated with the data pattern identifier, which indicates the data pattern for generating data within the first target address range. The pre-embedded bit and the associated data pattern identifier are considered to represent virtual pre-embedded data within the first target address range. Upon receiving a read instruction, the first bit corresponding to the bitmap is determined based on the second target address range of the read instruction. First test data is generated using the data pattern identifier associated with the pre-embedded state bit in the first bit. This first test data is considered to be the read pre-embedded data. Thus, data pre-embedding and reading during hard disk testing can be simulated without actually writing data to the hard disk, reducing hard disk testing time and hard disk lifespan. Attached Figure Description

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

[0012] Figure 1 An implementation scenario diagram provided for an embodiment of this application;

[0013] Figure 2 Flowchart of the hard disk testing method provided in the embodiments of this application Figure 1 ;

[0014] Figure 3 Flowchart of the hard disk testing method provided in the embodiments of this application Figure 2 ;

[0015] Figure 4 Flowchart of the hard disk testing method provided in the embodiments of this application Figure 3 ;

[0016] Figure 5 This is a schematic diagram of the hard disk testing device provided in the embodiments of this application;

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

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

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

[0020] Testing Non-Volatile Memory Express (NVMe) solid-state drives (SSDs) requires pre-embedding data within a specific LBA range. This pre-embedded data is used for testing the drive, such as performance verification, bad block management testing, and reliability testing.

[0021] Some data embedding methods create files and write data on the mounted drive letter, but this method is slow (limited by file system overhead and caching strategies) and cannot precisely control physical block-level writing, resulting in slow hard drive testing efficiency.

[0022] Other data embedding methods write data blocks to the hard drive using NVMe commands. This method bypasses the file system, but still requires a large number of NAND Flash (non-volatile memory) programming operations, which is time-consuming, especially when embedding data across the entire or a large area of ​​a large-capacity hard drive. In addition, this method also consumes the hard drive's write / erase cycles and generates a large amount of write amplification.

[0023] Based on this, this application proposes a hard disk testing method, electronic device, medium, and computer program product that can perform hard disk testing without pre-embedded data, thereby improving the efficiency of hard disk testing and reducing the wear and tear on the hard disk.

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

[0025] This section describes the specific application environment architecture or hardware architecture upon which the hard drive testing methods depend. (References) Figure 1 , Figure 1 This is an implementation scenario diagram provided for an embodiment of this application.

[0026] like Figure 1 As shown, this implementation scenario includes a client 10 and a server 11, which are connected via network communication.

[0027] In this embodiment, the client 10 is an electronic device on the user side, which can be a wired terminal with a visual structure or a wireless terminal. In other embodiments, the terminal can be an electronic device with a visual structure, such as a mobile phone, computer, tablet, or vehicle-mounted device.

[0028] Server 11 can be used in edge and cloud environments, such as physical servers, server clusters, and cloud servers; no specific restrictions are imposed here.

[0029] Server 11 serves as the test host for hard drives. After a hard drive is connected to server 11, hard drive testing can be performed.

[0030] The execution subject of the method in this embodiment is server 11. Client 10 can receive pre-embedded instructions and read instructions. Client 10 sends the pre-embedded instructions and read instructions to server 11 through the network. Server 11 performs hard disk testing and can feed back the hard disk test results to client 10 through the network. Client 10 has a graphical user interface, in which the hard disk test results can be displayed.

[0031] In some embodiments, after the hard disk is connected, the server 11 constructs a bitmap, where each bit in the bitmap corresponds to a portion of the logical block address range in the hard disk, and each bit in the bitmap is marked as unembedded; in response to the first target address range and data pattern identifier indicated in the pre-embedding instruction, the bit in the bitmap corresponding to the first target address range is marked as pre-embedded, and the data pattern identifier is associated with the bit marked as pre-embedded; in response to the second target address range indicated in the read instruction, the server 11 determines the first bit in the bitmap corresponding to the second target address range, and if at least some bits in the first bit are in the pre-embedded state, the server 11 generates first test data based on the data pattern identifier associated with the bit in the pre-embedded state in the first bit; and the server performs a hard disk test based on the first test data.

[0032] Understandably, the hard drive testing device can be set up at... Figure 1 In server 11, but as shown in this embodiment... Figure 1 The implementation environment shown is merely exemplary. In other embodiments, the hard disk testing method can also be applied to other implementation environments, and the hard disk testing device can also be set in other structures in other implementation environments. No specific limitations are made here.

[0033] Figure 2 Flowchart of the hard disk testing method provided in the embodiments of this application Figure 1 ,like Figure 2 As shown, an embodiment of this application provides a hard disk testing method, which is described in detail below:

[0034] S201. Construct a bitmap. Each bit in the bitmap corresponds to a range of logical blocks in the hard disk. Each bit in the bitmap is marked as unembedded.

[0035] In some embodiments, the hard drive is the hard drive to be tested.

[0036] In some embodiments, the hard drive is an NVMe SSD.

[0037] In some embodiments, the hard drive is connected to the server, the server loads the hard drive driver, identifies and obtains the namespace information of the hard drive, and determines the logical block address range to be tested on the hard drive.

[0038] After determining the logical block address range to be tested on the hard drive, a bitmap is created that corresponds to the logical block address range to be tested on the hard drive.

[0039] The logical block address range to be tested on the hard drive can be at least a portion of the logical block address range of the hard drive.

[0040] In some embodiments, the bitmap includes at least one bit, where a bit can be considered as a single bit of the bitmap, and a bit corresponds to a portion of the logical block address range in the logical block address range to be tested on the hard disk.

[0041] In some embodiments, one or more bits in the bitmap may correspond to one or more minimum data units in the logical block address range to be tested on the hard disk. The minimum data unit is an LBA block, typically 4KB (kilobytes).

[0042] After the bitmap is constructed, each bit in the bitmap is marked as unembedded.

[0043] In some embodiments, marking each bit as unembedded can be done by setting each bit to "0".

[0044] In some embodiments, each bit in the bitmap corresponds to a portion of the logical block address range in the logical block address range to be tested on the hard disk. That is, each bit in the bitmap corresponds to a portion of the logical block address range on the hard disk, and the logical block address range corresponding to each bit in the bitmap is the logical block address range to be tested on the hard disk.

[0045] S202. In response to the first target address range and data mode identifier indicated in the pre-embedded instruction, the bit corresponding to the first target address range in the bitmap is marked as pre-embedded, and the data mode identifier is associated with the bit marked as pre-embedded.

[0046] In some embodiments, the bitmap may be stored in a cache on the hard disk.

[0047] In some embodiments, virtual data is pre-embedded in at least a portion of the logical block address range to be tested by pre-embedding instructions.

[0048] The pre-embedded instruction includes information indicating the first target address range and information about the data pattern identifier.

[0049] The first target address range is the logical block address range for virtual data pre-embedding.

[0050] The first target address range is included in the logical block address range corresponding to the bitmap for the hard disk test.

[0051] The data schema identifier is the identifier for the data schema, which identifies the schema that generates the data.

[0052] In some embodiments, after receiving the pre-embedded instruction, one or more bits in the bitmap corresponding to the first target address range are determined according to the first target address range, and the bits in the bitmap corresponding to the first target address range are marked as pre-embedded.

[0053] In some embodiments, marking a bit as pre-embedded can be done by setting the bit to "1" in the bitmap.

[0054] In some embodiments, upon receiving a pre-embedded instruction, instead of writing data to the first target address range on the hard disk, the bits corresponding to the first target address range are marked as pre-embedded, and the data pattern identifier is associated with the bits marked as pre-embedded.

[0055] In some embodiments, associating a data pattern identifier with a bit marked as pre-embedded can be stored by associating the data pattern identifier with the bit marked as pre-embedded (e.g., stored in the extended information of the bitmap data structure).

[0056] The first target address range corresponding to the bit marked as pre-embedded can be considered as having data virtually pre-embedded.

[0057] In some embodiments, the first target address range can be determined by the starting logical block address and the logical block address length in the pre-embedded instruction.

[0058] S203. In response to the second target address range indicated in the read instruction, determine the first bit in the bitmap corresponding to the second target address range, and if at least some bits in the first bit are in a pre-embedded state, generate first test data based on the data pattern identifier associated with the bits in the first bit that are in a pre-embedded state.

[0059] In some embodiments, the read instruction is an instruction to read data from a second target address range.

[0060] In some embodiments, the read command can be an NVMe Read Command.

[0061] The second target address range is at least a portion of the logical block address range in the hard disk.

[0062] In some embodiments, after receiving a read instruction, the first bit in the bitmap corresponding to the second target address range is determined according to the second target address range.

[0063] If at least some bits in the first bit are in a pre-embedded state, then the logical block address range corresponding to the bits in the first bit that are in a pre-embedded state is the logical block address range of the virtual pre-embedded data, and the bits in the first bit that are in a pre-embedded state are associated with a data pattern identifier, so that first test data can be generated according to the data pattern identifier associated with the bits in the first bit that are in a pre-embedded state. The first test data can be regarded as data read from the logical block address range corresponding to the bits in the first bit that are in a pre-embedded state in the hard disk.

[0064] The size of the first test data is the same as the data size that the logical block address range corresponding to the bit in the first bit that is in a pre-embedded state can carry.

[0065] In some embodiments, the second target address range can be determined by the starting logical block address and the logical block address length in the read instruction.

[0066] S204. Test the hard drive based on the first test data.

[0067] The first test data can be regarded as data read from the hard drive, and the hard drive can be tested based on the first test data.

[0068] In some embodiments, after the first test data is generated, it is returned to the unit that issued the read instruction, such as a test program or test module in a server.

[0069] The testing of this hard drive may include one or more of the following: hard drive data integrity verification, read performance testing, end-to-end data protection testing, functional testing, and bad block remapping testing.

[0070] In this embodiment, during hard disk testing, a bitmap corresponding to a portion of the hard disk's logical block address range is generated. A pre-embedded instruction indicates a first target address range and a data pattern identifier. A bit corresponding to the first target address range can be found in the bitmap and marked as pre-embedded. This bit is then associated with the data pattern identifier, which indicates the data pattern for generating data within the first target address range. The pre-embedded bit and associated data pattern identifier are considered as if data has been virtually pre-embedded within the first target address range. Upon receiving a read instruction, a first bit corresponding to the bitmap is determined based on the second target address range of the read instruction. First test data is generated using the data pattern identifier associated with the pre-embedded state bit in the first bit. This first test data is considered as the read pre-embedded data. Therefore, pre-embedded and read data on the hard disk can be simulated without actually writing data to the hard disk, reducing the hard disk testing time caused by pre-embedded data, reducing resource consumption during data reading, and reducing hard disk lifespan.

[0071] Figure 3 Flowchart of the hard disk testing method provided in the embodiments of this application Figure 2 ,like Figure 3 As shown, embodiments of this application provide a method for associating bits with data pattern identifiers, which will be described in detail below:

[0072] S301. Determine the bits corresponding to the data mode address range of each data mode identifier from the bits marked as pre-embedded.

[0073] In some embodiments, the pre-embedded instruction indicates multiple data pattern identifiers and the data pattern address ranges corresponding to different data pattern identifiers in the first target address range.

[0074] In some embodiments, the data pattern identifier includes at least one of the following: an identifier for an all-zero data pattern, an identifier for an all-one data pattern, an identifier for a specific pseudo-random sequence pattern, an identifier for a pattern with end-to-end data protection metadata, and an identifier for an error simulation pattern.

[0075] In some embodiments, the all-zero data mode means that the data generated by the all-zero data mode is all "0", the all-one data mode means that the data generated by the all-one data mode is all "1", the specific pseudo-random sequence mode means that the data generated by the specific pseudo-random sequence mode includes a specific pseudo-random sequence, the mode with end-to-end data protection metadata means that the data generated by the mode with end-to-end data protection metadata includes end-to-end data protection metadata, and the error simulation mode means that the data generated by the error simulation mode includes data indicating read errors.

[0076] In some embodiments, the pre-embedded instruction indicates multiple data pattern identifiers, and also indicates the data pattern address range corresponding to different data pattern identifiers in the first target address range, that is, one data pattern identifier corresponds to a data pattern address range.

[0077] A data pattern address range can correspond to one or more data pattern identifiers.

[0078] In some embodiments, the corresponding bits for each data mode address range can be determined in the bitmap. Since the data mode address range is a part of the first target address range, the state of the corresponding bits for each data mode address range in the bitmap is a pre-embedded state.

[0079] Therefore, the bits corresponding to the data mode address range of each data mode identifier can be directly determined from the bits marked as pre-embedded.

[0080] S302. Associate the bits corresponding to the data mode address range of each data mode identifier with the corresponding data mode identifier.

[0081] The data pattern address range corresponds to the data pattern identifier. Therefore, the bits corresponding to the data pattern address range of each data pattern identifier also correspond to the corresponding data pattern identifier. Thus, the bits corresponding to the data pattern address range of each data pattern identifier can be associated with the corresponding data pattern identifier.

[0082] In some embodiments, the pre-embedded instructions indicate the identifier of the all-zero data mode and the identifier of the all-one data mode, and also indicate the data mode address range corresponding to the identifier of the all-zero data mode and the data mode address range corresponding to the identifier of the all-one data mode. This allows the bits corresponding to the data mode address range corresponding to the identifier of the all-zero data mode to be determined, and the bits corresponding to the data mode address range corresponding to the identifier of the all-zero data mode to be associated with the identifier of the all-zero data mode, and the bits corresponding to the data mode address range corresponding to the identifier of the all-one data mode to be associated with the identifier of the all-one data mode.

[0083] In some embodiments, when generating data, or when a bit corresponds to two or more data pattern identifiers, and the logical block address range corresponding to the bit includes an LBA, when generating data, the data corresponding to an LBA is generated using the data corresponding to a data pattern identifier, that is, a data pattern identifier can be randomly selected from two or more data pattern identifiers for data generation.

[0084] Figure 4 Flowchart of the hard disk testing method provided in the embodiments of this application Figure 3 ,like Figure 4 As shown, embodiments of this application provide a method for generating first test data, which will be described in detail below:

[0085] S401. Determine the first data pattern identifier associated with the bit in the first bit that is in a pre-embedded state.

[0086] In some embodiments, a data pattern identifier corresponds to a data pattern.

[0087] In some embodiments, bits in the bitmap that are in a pre-embedded state are associated with a data pattern identifier, thereby determining the first data pattern identifier associated with the bits in the first bit that are in a pre-embedded state.

[0088] S402. Determine the range of the third target address corresponding to the bits in the first bit that are in the pre-embedded state and the hard disk.

[0089] In some embodiments, bits in the bitmap correspond to logical block address ranges, thereby determining the third target address range corresponding to the bits in the first bit that are in a pre-embedded state and the hard disk.

[0090] The third target address range is used to determine the size of the data corresponding to the first test data.

[0091] S403. Generate first test data based on the data pattern corresponding to the first data pattern identifier, which is the same size as the data volume that the third target address range can carry.

[0092] In some embodiments, first test data is generated by the data pattern corresponding to the first data pattern identifier, and the data size of the first test data is the same as the data size that the third target address range can carry.

[0093] In some embodiments, the third target address range includes at least one target logical block address range, and the bits corresponding to a target logical block address range in the bitmap are associated with a first data pattern identifier.

[0094] For each target logical block address range in the third target address range, based on the data pattern corresponding to the first data pattern identifier associated with the corresponding bit in the bitmap of each target logical block address range, logical block test data corresponding to each target logical block address range is generated. The data size of the logical block test data is the same as the data size that the target logical block address range can carry. Based on the logical block test data corresponding to each target logical block address range in the third target address range, the first test data is determined.

[0095] In some embodiments, for multiple bits in the bitmap corresponding to the third target address range, and at least two of the multiple bits may be associated with different first data pattern identifiers, the target logical block address range corresponding to a bit associated with a first data pattern identifier can be determined, and different target logical block address ranges have different first data pattern identifiers associated with the corresponding bits in the bitmap.

[0096] Therefore, for each target logical block address range, based on the data pattern corresponding to the first data pattern identifier associated with the corresponding bit in the bitmap, logical block test data corresponding to each target logical block address range is generated. The size of a logical block test data is the same as the amount of data that the corresponding target logical block address range can carry.

[0097] The first test data is obtained by combining the test data of the logical blocks corresponding to the address ranges of each logical block in the third target address range with the first test data.

[0098] In this embodiment of the application, for different first data pattern identifiers associated with different bits in the first bit, test data of the same data volume that the target logical block address range corresponding to the bit can carry is generated according to the corresponding first data pattern identifier, so that accurate first test data can be obtained based on the first data pattern identifier.

[0099] In some embodiments, when at least some bits in the first bit are in an unembedded state, data within the address range corresponding to the unembedded bits in the first bit are read from the hard disk to obtain second test data; hard disk testing is performed based on the second test data.

[0100] In some embodiments, if at least some bits in the first bit are in an unembedded state, then there is no virtual pre-embedded data in the logical block address range corresponding to the unembedded state bits. Data in the address range corresponding to the unembedded state bits in the first bit can be read from the hard disk to obtain the second test data, which is an integer of data from the hard disk.

[0101] If there is no data within the address range corresponding to the bits in the first bit that are not pre-embedded, then the second test data can be data indicating a read error.

[0102] The second set of test data for hard drive testing may include one or more of the following: hard drive data integrity verification, read performance testing, end-to-end data protection testing, functional testing, and bad block remapping testing.

[0103] In some embodiments, when the read instruction includes a target data pattern identifier, the generated data pattern of the first test data is determined based on the first test data; and the data integrity of the hard disk is verified based on the identifier of the generated data pattern and the target data pattern identifier.

[0104] In some embodiments, the target data pattern identifier is sent via a read instruction or via an integrity checker.

[0105] After obtaining the first test data, the generated data pattern can be determined based on the first test data. If the identifier of the generated data pattern is the same as the identifier of the target data pattern, it means that the integrity verification has passed; if the identifier of the generated data pattern is different from the identifier of the target data pattern, it means that the integrity verification has failed.

[0106] Understandably, when performing integrity verification, the data pattern identifier associated with the bits corresponding to the second target address range should include the target data pattern identifier. Only then can the integrity verification be determined by comparing the generated data pattern identifier with the target data pattern identifier.

[0107] In some embodiments, the expected value of the target data pattern corresponding to the target data pattern identifier can be compared with the first test data. If the first test data includes the expected value of the target data pattern identifier, the integrity check is passed; if the first test data does not include the expected value of the target data pattern identifier, the integrity check is failed.

[0108] The target data pattern identifier includes at least one of the following: an identifier for an all-zero data pattern, an identifier for an all-one data pattern, an identifier for a specific pseudo-random sequence pattern, an identifier for a pattern with end-to-end data protection metadata, and an identifier for an error simulation pattern.

[0109] The expected value of the target data pattern identifier is related to the data pattern corresponding to the target data pattern identifier. For example, if the target data pattern identifier is an identifier of an all-zero data pattern, then the expected value of the target data pattern identifier is 0; if the target data pattern identifier is an identifier of an all-one data pattern, then the expected value of the target data pattern identifier is 1; if the target data pattern identifier is an identifier of a specific pseudo-random sequence pattern, then the expected value of the target data pattern identifier is the specific pseudo-random sequence; if the target data pattern identifier is an identifier of a pattern with end-to-end data protection metadata, then the expected value of the target data pattern identifier is end-to-end data protection metadata.

[0110] In some embodiments, if second test data is obtained, data integrity verification can also be performed using the second test data.

[0111] In some embodiments, the read duration between sending a read command and receiving first test data is determined; the hard drive read performance is tested based on the read duration.

[0112] The test program or test module sends a read command and receives first test data. The read time between sending the read command and receiving the first test data is determined, and the hard drive read performance is tested based on this read time.

[0113] The longer the read time, the worse the hard drive's read performance; the longer the read time, the better the hard drive's read performance. This read time can be used to test the extreme read performance of the controller, interface, and driver.

[0114] In some embodiments, if second test data is obtained, read performance testing can also be performed using the second test data.

[0115] In some embodiments, the data mode identifier includes an identifier for a mode with end-to-end data protection metadata. The presence of end-to-end data protection metadata is determined in the first test data; if end-to-end data protection metadata is present in the first test data, the end-to-end data protection test of the hard drive is determined to have passed; if end-to-end data protection metadata is not present in the first test data, the end-to-end data protection test of the hard drive is determined to have failed.

[0116] In some embodiments, the data pattern identifier in the pre-embedded instruction includes an identifier of the pattern with end-to-end data protection metadata, and the data pattern identifier associated with the bits of the pre-embedded state corresponding to the second target address range includes an identifier of the pattern with end-to-end data protection metadata. In this case, the end-to-end data protection test can be determined based on whether end-to-end data protection metadata exists in the first test data.

[0117] If the first test data contains end-to-end data protection metadata, then the first test data is determined to have been generated correctly, and the hard drive's end-to-end data protection test has passed; if the first test data does not contain end-to-end data protection metadata, then the hard drive's end-to-end data protection test has failed.

[0118] In some embodiments, if second test data is obtained, end-to-end data protection testing of the hard drive can also be performed using the second test data.

[0119] In some embodiments, if the first test data is readable, and the read instruction is a target type instruction, the hard disk functional test is determined to have passed; if the first test data is unreadable, and the read instruction is a target type instruction, the hard disk functional test is determined to have failed.

[0120] This function test is used to test whether the hard drive can perform the corresponding function.

[0121] For example, the target type instruction is a Trim / Discard command, or the target type instruction is write-protected.

[0122] If the first test data is readable, the hard drive's functional test is considered passed, indicating that the hard drive can perform the function. If the first test data is unreadable, the hard drive's functional test is considered failed.

[0123] In some embodiments, if second test data is obtained, the hard drive's functionality can also be tested using the second test data.

[0124] In some embodiments, the data mode identifier includes an identifier for an error simulation mode. If the first test data includes data indicating a read error, the hard disk bad block remapping test is considered passed; if the first test data does not include data indicating a read error, the hard disk bad block remapping test is considered failed.

[0125] In some embodiments, the data pattern identifier in the pre-embedded instruction includes an identifier for an error simulation mode, and the data pattern identifier associated with the bits of the pre-embedded state corresponding to the second target address range includes an identifier for an error simulation mode.

[0126] The logical block address range corresponding to the bits associated with the identifier of this error simulation mode can be considered as a bad block.

[0127] If the first test data includes data indicating a read error, the hard drive's bad block remapping test is considered passed; if the first test data does not include data indicating a read error, the hard drive's bad block remapping test is considered failed.

[0128] In some embodiments, if second test data is obtained, bad block remapping tests can also be performed using the second test data.

[0129] In some embodiments, in response to the fourth target address range in the erase instruction, a second bit corresponding to the fourth target address range is determined in the bitmap; the pre-embedded state of the second bit is reset to the unembedded state, and the data pattern identifier associated with the second bit is cleared.

[0130] In some embodiments, the erase instruction instructs the erasure of virtually embedded data in a fourth target address range.

[0131] In some embodiments, the second bit corresponding to the fourth target address range is obtained, the pre-embedded state of the second bit is reset to the non-embedded state, and the data pattern identifier associated with the second bit is cleared. This can be regarded as erasing the virtual pre-embedded data in the fourth target address range.

[0132] This method of erasing virtual pre-embedded data via erase commands eliminates the need to actually erase the data on the hard drive, thus reducing hard drive lifespan.

[0133] In some embodiments, when the hard disk testing process needs to be interrupted and resumed, the state of the bitmap can be saved to the server's non-volatile storage to achieve bitmap persistence.

[0134] In some embodiments, this method can also support test interruption recovery, where the bitmap state is reloaded and the bitmap is restored during subsequent test recovery.

[0135] In some embodiments, the server may include a bitmap tool module, which includes a bitmap management module. The bitmap management module is used to generate a bitmap, update the state of each bit in the bitmap, and associate a data pattern identifier.

[0136] The server may also include a test module that can generate read commands and pre-embedded commands, and this test module can be a test program.

[0137] The bitmap management module can receive pre-embedded instructions to update the state of each bit in the bitmap and associate it with data pattern identifiers.

[0138] The bitmap management module can receive erase commands, update the state of each bit in the bitmap, and erase the data mode identifier.

[0139] The bitmap tool module may also include an instruction interception module, which intercepts the read instructions sent by the test module and is connected to the bitmap management module. It can determine the state of the first bit corresponding to the second target address range in the bitmap and determine whether to generate the first test data or obtain the second test data from the hard disk.

[0140] The bitmap tool module may also include a data generation module, which is connected to the instruction interception module. The instruction interception module determines that at least some bits in the first bit are in a pre-embedded state and can send the information to the data generation module. The data generation module generates the first test data and can feed the first test data back to the test module.

[0141] This application embodiment achieves ultra-fast pre-embedding and virtual reading in hard disk testing by using the state of bits in the bitmap and the associated data pattern identifier. During pre-embedding, only the bitmap state update and data pattern identifier storage in memory are involved, which usually takes milliseconds or even microseconds. Compared with actually writing data to the hard disk, it can improve efficiency by hundreds to thousands of times.

[0142] This application embodiment does not write actual data to NAND Flash, thus maximizing the saving of SSD write / erase cycles (P / ECycles), significantly reducing write amplification, and is particularly suitable for R&D testing, mass production testing, and reliability verification scenarios that require repeated data pre-embedding, greatly reducing testing costs.

[0143] The embodiments of this application can precisely control the data state and data mode of any LBA range, including simulating bad blocks, specific data modes, etc., providing flexibility for testing in complex scenarios.

[0144] The embodiments of this application can completely eliminate the influence of NAND Flash physical read latency during read performance testing, focusing on testing the extreme read processing capabilities of the controller, interface, driver, and system software.

[0145] This application embodiment supports the pre-embedded simulation of arbitrarily complex data patterns (such as pseudo-random, specific check codes, etc.) by associating data pattern identifiers and dynamically generating test data.

[0146] The embodiments of this application mainly maintain the bitmap data structure in the server's memory, which consumes relatively few resources.

[0147] The hard disk testing method in this application can also be used in distributed storage systems to extend the bitmap to multiple nodes and simulate cross-hard disk data consistency testing. Understandably, in distributed storage systems, it is necessary to optimize bitmap memory usage and synchronize the bitmap status of each node.

[0148] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0149] Figure 5 This is a schematic diagram of the hard disk testing device provided in an embodiment of this application. Figure 5 As shown, an embodiment of this application provides a hard disk testing device 500, comprising:

[0150] Bitmap construction module 510 is used to construct a bitmap. Each bit in the bitmap corresponds to a range of logical block addresses in the hard disk, and each bit in the bitmap is marked as unembedded.

[0151] The pre-embedded module 530 is used to mark the bits corresponding to the first target address range in the bitmap as pre-embedded in response to the first target address range and data mode identifier indicated in the pre-embedded instruction, and associate the data mode identifier with the bits marked as pre-embedded.

[0152] The reading module 550 is configured to, in response to the second target address range indicated in the reading instruction, determine the first bit in the bitmap corresponding to the second target address range, and, if at least some bits in the first bit are in a pre-embedded state, generate first test data based on the data pattern identifier associated with the bits in the first bit that are in a pre-embedded state.

[0153] The hard drive testing module 570 is used to test the hard drive based on the first test data.

[0154] In some embodiments, the data pattern identifier includes at least one of the following: an identifier for an all-zero data pattern, an identifier for an all-one data pattern, an identifier for a specific pseudo-random sequence pattern, an identifier for a pattern with end-to-end data protection metadata, and an identifier for an error simulation pattern.

[0155] In some embodiments, the pre-embedded instruction indicates multiple data pattern identifiers and the data pattern address ranges corresponding to different data pattern identifiers in the first target address range; the pre-embedded module 530 includes:

[0156] The bit determination unit is used to determine the bits corresponding to the data mode address range of each data mode identifier from the bits marked as pre-embedded.

[0157] The association unit is used to associate the bits corresponding to the data pattern address range of each data pattern identifier with the corresponding data pattern identifier.

[0158] In some embodiments, the data pattern identifier corresponds to the data pattern; the reading module 550 includes:

[0159] The identifier determination unit is used to determine the first data pattern identifier associated with the bit in the first bit that is in a pre-embedded state.

[0160] The address determination unit is used to determine the third target address range corresponding to the bits in the first bit that are in a pre-embedded state and the hard disk.

[0161] The data generation unit is used to generate first test data with the same data volume as the third target address range based on the data pattern corresponding to the first data pattern identifier.

[0162] In some embodiments, the third target address range includes at least one target logical block address range, and the bits associated with different target logical block address ranges in the bitmap are different with the first data pattern identifier; the data generation unit includes:

[0163] The first data generation module is used to generate logical block test data for each target logical block address range in the third target address range, based on the data pattern corresponding to the first data pattern identifier associated with the corresponding bit in the bitmap of each target logical block address range. The data size of the logical block test data is the same as the data size that the target logical block address range can carry.

[0164] The second data generation module is used to determine the first test data based on the logical block test data corresponding to each target logical block address range in the third target address range.

[0165] In some embodiments, the hard disk testing module 570 includes:

[0166] The pattern determination unit is used to determine the generation data pattern of the first test data based on the first test data when the read instruction includes a target data pattern identifier.

[0167] The integrity verification unit is used to perform data integrity verification on the hard disk based on the identifier of the generated data pattern and the identifier of the target data pattern.

[0168] In some embodiments, the hard disk testing module 570 includes:

[0169] The duration acquisition unit is used to determine the reading duration between sending the read command and receiving the first test data.

[0170] The performance testing unit is used to test the hard drive's read performance based on read time.

[0171] In some embodiments, the data mode identifier includes an identifier for a mode with end-to-end data protection metadata; the hard disk test module 570 includes:

[0172] Metadata determination unit, used to determine whether end-to-end data protection metadata exists in the first test data.

[0173] The first judgment unit is used to determine that the hard disk's end-to-end data protection test has passed if end-to-end data protection metadata exists in the first test data.

[0174] The second judgment unit is used to determine that the end-to-end data protection test of the hard drive has failed if the end-to-end data protection metadata is not present in the first test data.

[0175] In some embodiments, the hard disk testing module 570 includes:

[0176] The third judgment unit is used to determine that the hard disk's functional test has passed if the first test data is readable, provided that the read instruction is a target type instruction.

[0177] The fourth judgment unit is used to determine that the hard disk's functional test has failed if the first test data is unreadable, provided that the read instruction is a target type instruction.

[0178] In some embodiments, the data mode identifier includes an identifier for an error simulation mode; the hard disk test module 570 includes:

[0179] The fifth judgment unit is used to indicate that the bad block remapping test of the hard disk has passed if the first test data includes data indicating a read error.

[0180] The sixth judgment unit is used to indicate that the bad block remapping test of the hard disk has failed if the first test data does not include data indicating a read error.

[0181] In some embodiments, the hard disk testing apparatus further includes:

[0182] The erase instruction processing module is used to determine the second bit corresponding to the fourth target address range in the bitmap in response to the fourth target address range in the erase instruction.

[0183] The erase module is used to reset the pre-embedded state of the second bit to the unembedded state and clear the data pattern identifier associated with the second bit.

[0184] In some embodiments, the hard disk testing apparatus further includes:

[0185] The hard disk read module is used to read data within the address range corresponding to the unembedded bits in the first bit when at least some bits in the first bit are in an unembedded state, and obtain the second test data.

[0186] The physical testing module is used to perform hard drive testing based on the second test data.

[0187] For a description of the features in the embodiment corresponding to the hard disk testing device, please refer to the relevant description in the embodiment corresponding to the hard disk testing method, which will not be repeated here.

[0188] Figure 6 A schematic diagram of the structure of the electronic device provided in this application. Figure 6 As shown, the electronic device 60 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the electronic device 60 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus.

[0189] In a specific implementation, at least one processor 601 executes a computer program stored in memory 602, causing at least one processor 601 to execute the above-described hard disk testing method embodiment.

[0190] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0191] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0192] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0193] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0194] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the hard disk testing method when it is run.

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

[0196] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described hard disk testing method embodiments.

[0197] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described hard disk testing method embodiments.

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

[0199] The above provides a detailed description of the hard disk testing method, electronic device, medium, and computer program product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A hard disk testing method, characterized in that, include: Construct a bitmap, wherein each bit in the bitmap corresponds to a range of logical block addresses in the hard disk, and each bit in the bitmap is marked as unembedded; In response to the first target address range and data pattern identifier indicated in the pre-embedded instruction, the bit in the bitmap corresponding to the first target address range is marked as pre-embedded, and the data pattern identifier is associated with the bit marked as pre-embedded; the data pattern identifier corresponds to the data pattern. In response to the second target address range indicated in the read instruction, a first bit corresponding to the second target address range in the bitmap is determined, and if at least some bits in the first bit are in a pre-embedded state, first test data is generated based on the data pattern identifier associated with the bits in the first bit that are in a pre-embedded state. The hard drive is tested based on the first test data; wherein, The generation of first test data based on the data pattern identifier associated with the pre-embedded bits in the first bit includes: Determine the first data pattern identifier associated with the bit in the first bit that is in a pre-embedded state; Determine the third target address range corresponding to the bits in the first bit that are in a pre-embedded state and the hard disk; First test data is generated based on the data pattern corresponding to the first data pattern identifier, with the same data volume as that that the third target address range can carry.

2. The method according to claim 1, characterized in that, The data pattern identifier includes at least one of the following: an identifier for an all-zero data pattern, an identifier for an all-one data pattern, an identifier for a specific pseudo-random sequence pattern, an identifier for a pattern with end-to-end data protection metadata, and an identifier for an error simulation pattern.

3. The method according to claim 1, characterized in that, The pre-embedded instruction indicates multiple data pattern identifiers and the data pattern address ranges corresponding to different data pattern identifiers in the first target address range. Associating the data pattern identifier with bits marked as pre-embedded includes: Determine the bits corresponding to the data mode address range of each data mode identifier from the bits marked as pre-embedded; Associate the bits corresponding to the data pattern address range of each data pattern identifier with the corresponding data pattern identifier.

4. The method according to claim 1, characterized in that, The third target address range includes at least one target logical block address range, and the bit associations of different target logical block address ranges in the bitmap are different first data pattern identifiers; the generation of first test data with the same data volume as the third target address range based on the data pattern corresponding to the first data pattern identifier includes: For each target logical block address range in the third target address range, based on the data pattern corresponding to the first data pattern identifier associated with the corresponding bit in the bitmap, logical block test data corresponding to each target logical block address range is generated. The data size of the logical block test data is the same as the data size that the target logical block address range can carry. The first test data is determined based on the logical block test data corresponding to each target logical block address range in the third target address range.

5. The method according to any one of claims 1 to 4, characterized in that, The test of the hard drive based on the first test data includes: When the read instruction includes a target data pattern identifier, the generation data pattern of the first test data is determined based on the first test data; Data integrity verification of the hard disk is performed based on the identifier of the generated data pattern and the identifier of the target data pattern.

6. The method according to any one of claims 1 to 4, characterized in that, The test of the hard drive based on the first test data includes: Determine the reading time between sending the read instruction and receiving the first test data; The hard drive's read performance was tested based on the read duration.

7. The method according to any one of claims 1 to 4, characterized in that, The data pattern identifier includes an identifier for the pattern with end-to-end data protection metadata; The test of the hard drive based on the first test data includes: Determine whether end-to-end data protection metadata exists in the first test data; If end-to-end data protection metadata is present in the first test data, then the end-to-end data protection test of the hard drive is determined to be passed; If the first test data does not contain end-to-end data protection metadata, then the end-to-end data protection test of the hard drive is determined to have failed.

8. The method according to any one of claims 1 to 4, characterized in that, The test of the hard drive based on the first test data includes: If the first test data is readable data, provided that the read instruction is a target type instruction, then the functional test of the hard disk is determined to be passed. If the first test data is unreadable, provided that the read instruction is a target type instruction, then the functional test of the hard disk is determined to have failed.

9. The method according to any one of claims 1 to 4, characterized in that, The data mode identifier includes an identifier for an error simulation mode; the testing of the hard drive based on the first test data includes: If the first test data includes data indicating a read error, then the bad block remapping test of the hard disk is passed; If the first test data does not include data indicating a read error, then the bad block remapping test of the hard disk has failed.

10. The method according to claim 1, characterized in that, The method further includes: In response to the fourth target address range in the erase instruction, a second bit corresponding to the fourth target address range is determined in the bitmap; Reset the pre-embedded state of the second bit to the unembedded state and clear the data pattern identifier associated with the second bit.

11. The method according to claim 1, characterized in that, The method further includes: If at least some bits in the first bit are in an unembedded state, data within the address range corresponding to the unembedded bits in the first bit are read from the hard disk to obtain the second test data; Hard drive testing was performed based on the second test data.

12. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the method as described in any one of claims 1 to 11.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 11.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 11.

Images