A slow disk simulation method, device, equipment and medium
By intercepting I/O requests and injecting latency at the block layer of the operating system kernel, the simulation problem of slow disk detection in storage systems is solved, enabling effective testing of different hard disk types and ensuring the reliability of the detection mechanism and system stability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- JINAN INSPUR DATA TECH CO LTD
- Filing Date
- 2022-10-21
- Publication Date
- 2026-07-24
AI Technical Summary
Existing technologies are insufficient to effectively simulate and detect slow disks in storage systems, thus affecting the read and write performance of the storage system.
By intercepting I/O requests at the block level of the operating system kernel and using preset logic for delayed injection, a slow disk is simulated to meet the testing requirements of the detection mechanism.
It enables slow disk simulation for various types of hard drives, and can test the reliability of the slow disk detection mechanism of the storage system. It supports mechanical hard drives, SATA SSDs and NVMe SSDs, and does not affect the normal operation of non-injected devices.
Smart Images

Figure CN115576767B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of hard disk failure simulation technology, and in particular to a slow disk simulation method, apparatus, device and medium. Background Technology
[0002] During use, hard drives in storage systems may experience increased latency during I / O (input / output) read and write operations due to magnetic degradation, bad sectors, vibration, or other environmental and mechanical issues. Such hard drives with increased latency during I / O operations are called slow drives.
[0003] Typically, to reduce the impact of slow disks on the read / write performance of a storage system, the latency of I / O operations performed by each hard drive in the storage system is monitored in real time during system operation to detect whether these hard drives are slow. Specifically, taking a single hard drive as an example, the average latency of I / O operations performed by that hard drive in each first cycle is calculated and compared to a preset time threshold. If the average latency is greater than or equal to the time threshold, it is recorded as a threshold event. The number of threshold events occurring in each second cycle (which is longer than the first cycle) is also calculated and compared to a preset frequency threshold. If the frequency is greater than or equal to the preset frequency threshold, the hard drive is determined to be slow. Whether the slow disk detection mechanism meets practical requirements usually requires testing. How to simulate a slow disk to detect and determine whether the slow disk detection mechanism of the storage system is functioning correctly and reliably is a problem that needs to be solved. Summary of the Invention
[0004] In view of this, the purpose of this application is to provide a slow disk simulation method, apparatus, device, and medium capable of simulating slow disks for various types of hard drives to meet the testing requirements of slow disk detection mechanisms. The specific solution is as follows:
[0005] In a first aspect, this application discloses a slow disk simulation method, including:
[0006] When the target function begins execution, a jump instruction is set in the target function to a preset hook function; the target function is a function in the block layer of the operating system kernel that processes I / O requests; the I / O request is an I / O request for the hard disk;
[0007] The preset hook function is used to intercept IO requests, and preset logic is used to perform delayed injection.
[0008] Optionally, the delayed injection using preset logic includes:
[0009] Determine whether the cumulative duration of the IO request from the request start time to the current time has reached a preset delay threshold. If it has not reached the preset delay threshold, execute the sleep function to make the cumulative duration reach the preset delay threshold.
[0010] Optionally, if the preset delay threshold is not reached, the sleep function is executed to make the accumulated duration reach the preset delay threshold, including:
[0011] If the preset delay threshold is not reached, the time difference between the current cumulative duration and the preset delay threshold is calculated, and the sleep function is executed based on the time difference to make the cumulative duration reach the preset delay threshold.
[0012] Optionally, after determining whether the cumulative duration of the IO request from the request start time to the current time reaches a preset delay threshold, the method further includes:
[0013] If the preset delay threshold is reached, the execution of the preset hook function will end.
[0014] Optionally, before performing delayed injection using preset logic, the method further includes:
[0015] Determine whether the block device parameters carried in the IO request are consistent with the configuration parameters. If the block device parameters carried in the IO request are consistent with the configuration parameters, then perform delayed injection using preset logic.
[0016] Optional, also includes:
[0017] Configure the master device number and slave device number corresponding to the target hard disk to be injected with delay to obtain the configuration parameters.
[0018] Optionally, the target function is the blk_mq_start_request function.
[0019] Secondly, this application discloses a slow disk simulation device, comprising:
[0020] The hook function adjustment module is used to jump to a preset hook function through a preset jump instruction in the target function when the target function starts executing; the target function is a function in the block layer of the operating system kernel that processes I / O requests; the I / O request is an I / O request for the hard disk;
[0021] The delayed injection module is used to intercept IO requests using the preset hook function and perform delayed injection using preset logic.
[0022] Optional, a delayed injection module, specifically used for:
[0023] Determine whether the cumulative duration of the IO request from the request start time to the current time has reached a preset delay threshold. If it has not reached the preset delay threshold, execute the sleep function to make the cumulative duration reach the preset delay threshold.
[0024] Optionally, the delay injection module is specifically used to: if the preset delay threshold is not reached, calculate the time difference between the current cumulative duration and the preset delay threshold, and execute the sleep function based on the time difference to make the cumulative duration reach the preset delay threshold.
[0025] Optionally, the delay injection module is further configured to: after determining whether the cumulative duration of the IO request from the request start time to the current time has reached a preset delay threshold, if the preset delay threshold is reached, then terminate the execution of the preset hook function.
[0026] Optionally, the delayed injection module is further configured to: before performing delayed injection using preset logic, determine whether the block device parameters carried in the IO request are consistent with the configuration parameters; if the block device parameters carried in the IO request are consistent with the configuration parameters, then perform delayed injection using preset logic.
[0027] Optionally, the device further includes:
[0028] The parameter configuration module is used to configure the master device number and slave device number of the target hard disk to be injected with delay, and to obtain the configuration parameters.
[0029] Optionally, the target function is the blk_mq_start_request function.
[0030] Thirdly, this application discloses an electronic device, including a memory and a processor, wherein:
[0031] The memory is used to store computer programs;
[0032] The processor is used to execute the computer program to implement the aforementioned slow disk emulation method.
[0033] Fourthly, this application discloses a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the aforementioned slow disk emulation method.
[0034] As can be seen, when the target function begins execution, this application jumps to a preset hook function through a preset jump instruction within the target function. The target function is a function in the block layer of the operating system kernel that processes I / O requests. The I / O request is a hard drive I / O request. The preset hook function intercepts the I / O request and uses preset logic for delayed injection. Although mechanical hard drives and SATA SSDs use the SCSI protocol in the kernel, and the kernel uses the SCSI protocol to interact with the hard drive, while NVMe SSDs use the PCIe bus to access the system, and the kernel directly interacts with the PCIe device to read and write data, mechanical hard drives, SATA SSDs, and NVMe SSDs are ultimately abstracted as block devices in Linux. This application selects the function in the block layer of the operating system kernel that processes I / O requests as the target function, presets jump instructions and hook functions, and realizes the interception and delayed injection of I / O requests. That is, this application performs I / O interception and delayed injection at the block layer. In this way, slow disk simulation can be performed for various types of hard drives to meet the testing requirements of slow disk detection mechanisms. Attached Figure Description
[0035] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0036] Figure 1 This is a flowchart of a slow disk simulation method disclosed in an embodiment of this application;
[0037] Figure 2 This is a schematic diagram of a slow disk simulation device disclosed in an embodiment of this application;
[0038] Figure 3 This is a schematic diagram of an electronic device disclosed in an embodiment of this application. Detailed Implementation
[0039] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0040] Typically, to reduce the impact of slow disks on the read / write performance of a storage system, the latency of I / O operations performed by each hard drive in the storage system is monitored in real time during system operation to detect whether these hard drives are slow. Specifically, taking a single hard drive as an example, the average latency of I / O operations performed by that hard drive in each first cycle is calculated and compared with a preset time threshold. If the average latency is greater than or equal to the time threshold, it is recorded as a threshold event. The number of threshold events occurring in each second cycle is also calculated and compared with a preset frequency threshold. If the frequency is greater than or equal to the preset frequency threshold, the hard drive is determined to be a slow drive. Whether the slow disk detection mechanism meets practical requirements usually requires testing. How to simulate slow disks to detect and determine whether the slow disk detection mechanism of a storage system is normal and reliable is a problem that needs to be solved. Therefore, this application provides a slow disk simulation scheme that can simulate slow disks for various types of hard drives to meet the testing requirements of the slow disk detection mechanism.
[0041] See Figure 1 As shown in the figure, this application discloses a slow disk simulation method, including:
[0042] Step S11: When the target function starts executing, jump to the preset hook function through the preset jump instruction in the target function; the target function is a function in the block layer of the operating system kernel that processes IO requests; the IO request is an IO request for the hard disk.
[0043] It should be noted that in distributed storage, hard drives generally include NVMe (Non-Volatile Memory Express) SSDs (Solid State Disks), SATA (Serial Advanced Technology Attachment) SSDs, and mechanical hard drives (HDDs). Mechanical hard drives and SATA SSDs use the SCSI (Small Computer System Interface) protocol in the kernel, and the kernel interacts with the disk using the SCSI protocol. In contrast, NVMe SSDs use the PCIe (Peripheral Component Interconnect Express) bus to access the system, and the kernel directly interacts with the PCIe device to read and write data. Since mechanical hard drives, SATA SSDs, and NVMe SSDs are ultimately abstracted as block devices in Linux, this embodiment selects the function in the block layer of the operating system kernel that handles I / O requests as the target function, pre-sets jump instructions and hook functions, and implements I / O request interception and delay injection, that is, intercepting I / O and injecting delay at the general block layer. It is understandable that latency injection involves kernel modification, and this application embodiment implements it as a kernel module.
[0044] In one implementation, the target function is the blk_mq_start_request function. This function initiates the addition of I / O requests to the multi-queue.
[0045] Step S12: Intercept IO requests using the preset hook function and perform delayed injection using preset logic.
[0046] In one implementation, this application embodiment can configure the master device number and slave device number corresponding to the target hard drive to be injected with delay to obtain configuration parameters. After intercepting the IO request using the preset hook function, it is determined whether the block device parameters carried in the IO request are consistent with the configuration parameters. If the block device parameters carried in the IO request are consistent with the configuration parameters, then delayed injection is performed using preset logic.
[0047] Furthermore, it can be determined whether the cumulative duration of the IO request from the request start time to the current time has reached a preset delay threshold. If it has not reached the preset delay threshold, the sleep function is executed to make the cumulative duration reach the preset delay threshold. If it has reached the preset delay threshold, the execution of the preset hook function is terminated.
[0048] If the preset delay threshold is not reached, the time difference between the current accumulated time and the preset delay threshold is calculated, and a sleep function is executed based on this time difference to bring the accumulated time to the preset delay threshold. That is, the sleep time is this time difference. It should be noted that different I / O requests may take different amounts of time to process in the target function. This embodiment of the application can uniformly perform delay injection, facilitating the testing of the slow disk detection mechanism.
[0049] Understandably, storage systems typically have many hard drives installed. To determine which hard drive needs to be injected, this embodiment of the application can configure the block device's major (master device number) and first_minor (slave device number) to determine which disk to inject latency into. Furthermore, a preset latency threshold, delay_time, is configured, in milliseconds; for example, the default value can be 1000. Of course, in specific scenarios testing the slow disk detection mechanism of the storage system, this value can be modified to meet the requirements.
[0050] Below, using blk_mq_start_request as an example of the target function X for time-delayed injection, the principle of function injection is explained as follows:
[0051]
[0052]
[0053] By modifying the first few instructions of function X (the instructions corresponding to the number of bytes occupied by the jump instructions), and adding jump and recovery instructions, a pre-defined HOOK function call is inserted. The injected function HOOK.fn is specifically implemented as khook_blk_mq_start_request. It checks whether the major and minor device numbers in the request match the parameter configuration values to determine the specific hard drive. If they match, it checks whether the request start time (start_time_ns) has reached the time threshold of the parameter delay_time. If not, it needs to sleep for a certain period to achieve the required injection delay. The request start time is the start time marked by the request creation function. The specific implementation code for delay injection is as follows:
[0054]
[0055] That is, the embodiments of this application can modify the blk_mq_start_request function, replace the instruction executed at the beginning of blk_mq_start_request with a jump instruction to jump to a preset hook function, and back up the replaced instruction. After the preset hook function is executed, the backed-up instruction and the subsequent instructions in the original blk_mq_start_request function are executed.
[0056] Thus, this application provides a method for simulating slow disks, which can test the slow disk handling mechanism of a storage system and the overall performance of the storage system when a slow disk occurs. Injecting latency from the Linux kernel's blk layer provides a testing tool for slow disk detection mechanisms in distributed storage, supporting mechanical hard drives, SATA SSDs, and NVMe SSDs, making it a common slow disk injection scheme for distributed storage systems. Furthermore, the specific hard drive to be injected and the injection latency can be specified. It supports multi-queue kernel block devices, and the injection latency does not affect non-injected devices, causing no other adverse effects on the storage system.
[0057] As can be seen, in this embodiment, when the target function begins execution, it jumps to a preset hook function through a preset jump instruction within the target function. The target function is a function in the block layer of the operating system kernel that processes I / O requests. The I / O request is a hard drive I / O request. The preset hook function intercepts the I / O request and uses preset logic for delayed injection. Although mechanical hard drives and SATA SSDs use the SCSI protocol in the kernel, and the kernel uses the SCSI protocol to interact with the hard drive, while NVMe SSDs use the PCIe bus to access the system, and the kernel directly interacts with the PCIe device to read and write data, mechanical hard drives, SATA SSDs, and NVMe SSDs are ultimately abstracted as block devices in Linux. This embodiment selects the function in the block layer of the operating system kernel that processes I / O requests as the target function, presets jump instructions and hook functions, and realizes the interception and delayed injection of I / O requests. That is, this embodiment performs I / O interception and delayed injection at the block layer. In this way, slow disk simulation can be performed for various types of hard drives to meet the testing requirements of the slow disk detection mechanism.
[0058] See Figure 2 As shown in the figure, this application discloses a slow disk emulation device, including:
[0059] The hook function adjustment module 11 is used to jump to a preset hook function through a preset jump instruction in the target function when the target function starts executing; the target function is a function in the block layer of the operating system kernel that processes IO requests; the IO request is an IO request for the hard disk;
[0060] The delayed injection module 12 is used to intercept IO requests using the preset hook function and perform delayed injection using preset logic.
[0061] As can be seen, when the target function begins execution, this application jumps to a preset hook function through a preset jump instruction within the target function. The target function is a function in the block layer of the operating system kernel that processes I / O requests. The I / O request is a hard drive I / O request. The preset hook function intercepts the I / O request and uses preset logic for delayed injection. Although mechanical hard drives and SATA SSDs use the SCSI protocol in the kernel, and the kernel uses the SCSI protocol to interact with the hard drive, while NVMe SSDs use the PCIe bus to access the system, and the kernel directly interacts with the PCIe device to read and write data, mechanical hard drives, SATA SSDs, and NVMe SSDs are ultimately abstracted as block devices in Linux. This application performs I / O interception and delayed injection at the block layer, which can simulate slow drives for various types of hard drives to meet the testing requirements of slow drive detection mechanisms.
[0062] In one implementation, the delay injection module 12 is specifically used for:
[0063] Determine whether the cumulative duration of the IO request from the request start time to the current time has reached a preset delay threshold. If it has not reached the preset delay threshold, execute the sleep function to make the cumulative duration reach the preset delay threshold.
[0064] In one implementation, the delay injection module 12 is specifically used to: if the preset delay threshold is not reached, calculate the time difference between the current accumulated duration and the preset delay threshold, and execute a sleep function based on the time difference to make the accumulated duration reach the preset delay threshold. That is, the sleep time is the time difference. It should be noted that different IO requests may take different amounts of time to process in the target function. This embodiment of the application can uniformly perform delay injection, which is convenient for testing the slow disk detection mechanism of the storage system.
[0065] Furthermore, the delay injection module 12 is also used to: after determining whether the cumulative duration of the IO request from the request start time to the current time has reached a preset delay threshold, if the preset delay threshold is reached, then terminate the execution of the preset hook function.
[0066] Furthermore, the delayed injection module 12 is also used to: before performing delayed injection using preset logic, determine whether the block device parameters carried in the IO request are consistent with the configuration parameters; if the block device parameters carried in the IO request are consistent with the configuration parameters, then perform delayed injection using preset logic.
[0067] Furthermore, the device also includes:
[0068] The parameter configuration module is used to configure the master device number and slave device number of the target hard disk to be injected with delay, and to obtain the configuration parameters.
[0069] Understandably, storage systems typically have many hard drives installed. To determine which hard drive needs to be injected, this embodiment of the application can configure the block device's major (master device number) and first_minor (slave device number) to determine which disk to inject latency into. Furthermore, a preset latency threshold, delay_time, is configured, in milliseconds; for example, the default value can be 1000. Of course, in specific scenarios testing the slow disk detection mechanism of the storage system, this value can be modified to meet the requirements.
[0070] In one implementation, the target function is the `blk_mq_start_request` function. Specifically, by modifying the first few instructions of function X (instructions corresponding to the number of bytes occupied by jump instructions), jump instructions and recovery instructions are added to insert a preset HOOK function call. The injected function `HOOK.fn` is specifically implemented as `khook_blk_mq_start_request`, which determines the specific hard drive by checking whether the major and minor device numbers in the request match the parameter configuration values. If they match, it checks whether the request start time: `start_time_ns`, has reached the time threshold of the parameter `delay_time`. If the time has not reached the threshold, it needs to sleep for a certain period of time to achieve the required injection delay. Here, the request start time is the start time of the request creation function marker.
[0071] That is, the embodiments of this application can modify the blk_mq_start_request function, replace the instruction executed at the beginning of blk_mq_start_request with a jump instruction to jump to a preset hook function, and back up the replaced instruction. After the preset hook function is executed, the backed-up instruction and the subsequent instructions in the original blk_mq_start_request function are executed.
[0072] Thus, this application provides a scheme for simulating slow disks, which can test the slow disk handling mechanism of a storage system and the overall performance of the storage system when a slow disk occurs. Injecting latency from the Linux kernel's blk layer provides a testing tool for slow disk detection mechanisms in distributed storage, supporting mechanical hard drives, SATA SSDs, and NVMe SSDs, making it a common slow disk injection scheme for distributed storage systems. Furthermore, the specific hard drive to be injected and the injection latency can be specified. It supports multi-queue kernel block devices, and the injection latency does not affect non-injected devices, causing no other adverse effects on the storage system.
[0073] See Figure 3 As shown in the illustration, this application discloses an electronic device 20, including a processor 21 and a memory 22; wherein, the memory 22 is used to store a computer program; and the processor 21 is used to execute the computer program to implement the following steps:
[0074] When the target function begins execution, a jump instruction is set in the target function to a preset hook function; the target function is a function in the block layer of the operating system kernel that processes I / O requests; the I / O request is an I / O request for the hard disk;
[0075] The preset hook function is used to intercept IO requests, and preset logic is used to perform delayed injection.
[0076] As can be seen, in this embodiment, when the target function begins execution, it jumps to a preset hook function through a preset jump instruction within the target function. The target function is a function in the block layer of the operating system kernel that processes I / O requests. The I / O request is a hard drive I / O request. The preset hook function intercepts the I / O request and uses preset logic for delayed injection. Although mechanical hard drives and SATA SSDs use the SCSI protocol in the kernel, and the kernel uses the SCSI protocol to interact with the hard drive, while NVMe SSDs use the PCIe bus to access the system, and the kernel directly interacts with the PCIe device to read and write data, mechanical hard drives, SATA SSDs, and NVMe SSDs are ultimately abstracted as block devices in Linux. This embodiment selects the function in the block layer of the operating system kernel that processes I / O requests as the target function, presets jump instructions and hook functions, and realizes the interception and delayed injection of I / O requests. That is, this embodiment performs I / O interception and delayed injection at the block layer. In this way, slow disk simulation can be performed for various types of hard drives to meet the testing requirements of the slow disk detection mechanism.
[0077] In this embodiment, when the processor 21 executes the computer subroutine stored in the memory 22, it can specifically implement the following steps: determine whether the cumulative duration of the IO request from the request start time to the current time has reached a preset delay threshold; if it has not reached the preset delay threshold, execute the sleep function to make the cumulative duration reach the preset delay threshold.
[0078] In this embodiment, when the processor 21 executes the computer subroutine stored in the memory 22, it can specifically implement the following steps: if the preset delay threshold is not reached, calculate the time difference between the current cumulative duration and the preset delay threshold, and execute the sleep function based on the time difference to make the cumulative duration reach the preset delay threshold.
[0079] In this embodiment, when the processor 21 executes the computer subroutine stored in the memory 22, it can specifically implement the following steps: after determining whether the cumulative duration of the IO request from the request start time to the current time has reached a preset delay threshold, if the preset delay threshold is reached, the execution of the preset hook function is terminated.
[0080] In this embodiment, when the processor 21 executes the computer subroutine stored in the memory 22, it can specifically implement the following steps: before performing delayed injection using preset logic, it determines whether the block device parameters carried in the IO request are consistent with the configuration parameters. If the block device parameters carried in the IO request are consistent with the configuration parameters, then delayed injection is performed using preset logic.
[0081] In this embodiment, when the processor 21 executes the computer subroutine stored in the memory 22, it can specifically implement the following steps: configure the master device number and slave device number corresponding to the target hard disk to be injected with delay, and obtain the configuration parameters.
[0082] Understandably, storage systems typically have many hard drives installed. To determine which hard drive needs to be injected, this embodiment of the application can configure the block device's major (master device number) and first_minor (slave device number) to determine which disk to inject latency into. Furthermore, a preset latency threshold, delay_time, is configured, in milliseconds; for example, the default value can be 1000. Of course, in specific scenarios testing the slow disk detection mechanism of the storage system, this value can be modified to meet the requirements.
[0083] In one implementation, the target function is the `blk_mq_start_request` function. Specifically, by modifying the first few instructions of function X (instructions corresponding to the number of bytes occupied by jump instructions), jump instructions and recovery instructions are added to insert a preset HOOK function call. The injected function `HOOK.fn` is specifically implemented as `khook_blk_mq_start_request`, which determines the specific hard drive by checking whether the major and minor device numbers in the request match the parameter configuration values. If they match, it checks whether the request start time: `start_time_ns`, has reached the time threshold of the parameter `delay_time`. If the time has not reached the threshold, it needs to sleep for a certain period of time to achieve the required injection delay. Here, the request start time is the start time of the request creation function marker. That is, the embodiments of this application can modify the blk_mq_start_request function, replace the instruction executed at the beginning of blk_mq_start_request with a jump instruction to jump to a preset hook function, and back up the replaced instruction. After the preset hook function is executed, the backed-up instruction and the subsequent instructions in the original blk_mq_start_request function are executed.
[0084] Thus, this application provides a scheme for simulating slow disks, which can test the slow disk handling mechanism of a storage system and the overall performance of the storage system when a slow disk occurs. Injecting latency from the Linux kernel's blk layer provides a testing tool for slow disk detection mechanisms in distributed storage, supporting mechanical hard drives, SATA SSDs, and NVMe SSDs, making it a common slow disk injection scheme for distributed storage systems. Furthermore, the specific hard drive to be injected and the injection latency can be specified. It supports multi-queue kernel block devices, and the injection latency does not affect non-injected devices, causing no other adverse effects on the storage system.
[0085] Furthermore, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, and the storage method can be temporary storage or permanent storage.
[0086] In addition, the electronic device 20 also includes a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26; wherein, the power supply 23 is used to provide operating voltage for the various hardware devices on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.
[0087] Furthermore, embodiments of this application disclose a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, performs the following steps:
[0088] When the target function begins execution, a jump instruction is set in the target function to a preset hook function; the target function is a function in the block layer of the operating system kernel that processes I / O requests; the I / O request is an I / O request for the hard disk;
[0089] The preset hook function is used to intercept IO requests, and preset logic is used to perform delayed injection.
[0090] As can be seen, in this embodiment, when the target function begins execution, it jumps to a preset hook function through a preset jump instruction within the target function. The target function is a function in the block layer of the operating system kernel that processes I / O requests. The I / O request is a hard drive I / O request. The preset hook function intercepts the I / O request and uses preset logic for delayed injection. Although mechanical hard drives and SATA SSDs use the SCSI protocol in the kernel, and the kernel uses the SCSI protocol to interact with the hard drive, while NVMe SSDs use the PCIe bus to access the system, and the kernel directly interacts with the PCIe device to read and write data, mechanical hard drives, SATA SSDs, and NVMe SSDs are ultimately abstracted as block devices in Linux. This embodiment selects the function in the block layer of the operating system kernel that processes I / O requests as the target function, presets jump instructions and hook functions, and realizes the interception and delayed injection of I / O requests. That is, this embodiment performs I / O interception and delayed injection at the block layer. In this way, slow disk simulation can be performed for various types of hard drives to meet the testing requirements of the slow disk detection mechanism.
[0091] In this embodiment, when the computer subroutine stored in the computer-readable storage medium is executed by the processor, the following steps can be specifically implemented: determining whether the cumulative duration of the IO request from the request start time to the current time has reached a preset delay threshold; if it has not reached the preset delay threshold, then executing the sleep function to make the cumulative duration reach the preset delay threshold.
[0092] In this embodiment, when the computer subroutine stored in the computer-readable storage medium is executed by the processor, it can specifically implement the following steps: if the preset delay threshold is not reached, calculate the time difference between the current cumulative duration and the preset delay threshold, and execute the sleep function based on the time difference to make the cumulative duration reach the preset delay threshold.
[0093] In this embodiment, when the computer subroutine stored in the computer-readable storage medium is executed by the processor, the following steps can be specifically implemented: after determining whether the cumulative duration of the IO request from the request start time to the current time has reached a preset delay threshold, if the preset delay threshold is reached, the execution of the preset hook function is terminated.
[0094] In this embodiment, when the computer subroutine stored in the computer-readable storage medium is executed by the processor, the following steps can be specifically implemented: before performing delayed injection using preset logic, it is determined whether the block device parameters carried in the IO request are consistent with the configuration parameters. If the block device parameters carried in the IO request are consistent with the configuration parameters, then delayed injection is performed using preset logic.
[0095] In this embodiment, when the computer subroutine stored in the computer-readable storage medium is executed by the processor, the following steps can be specifically implemented: configuring the master device number and slave device number corresponding to the target hard disk to be injected with delay, and obtaining the configuration parameters.
[0096] Understandably, storage systems typically have many hard drives installed. To determine which hard drive needs to be injected, this embodiment of the application can configure the block device's major (master device number) and first_minor (slave device number) to determine which disk to inject latency into. Furthermore, a preset latency threshold, delay_time, is configured, in milliseconds; for example, the default value can be 1000. Of course, in specific scenarios testing the slow disk detection mechanism of the storage system, this value can be modified to meet the requirements.
[0097] In one implementation, the target function is the `blk_mq_start_request` function. Specifically, by modifying the first few instructions of function X (instructions corresponding to the number of bytes occupied by jump instructions), jump instructions and recovery instructions are added to insert a preset HOOK function call. The injected function `HOOK.fn` is specifically implemented as `khook_blk_mq_start_request`, which determines the specific hard drive by checking whether the major and minor device numbers in the request match the parameter configuration values. If they match, it checks whether the request start time: `start_time_ns`, has reached the time threshold of the parameter `delay_time`. If the time has not reached the threshold, it needs to sleep for a certain period of time to achieve the required injection delay. Here, the request start time is the start time of the request creation function marker. That is, the embodiments of this application can modify the blk_mq_start_request function, replace the instruction executed at the beginning of blk_mq_start_request with a jump instruction to jump to a preset hook function, and back up the replaced instruction. After the preset hook function is executed, the backed-up instruction and the subsequent instructions in the original blk_mq_start_request function are executed.
[0098] Thus, this application provides a scheme for simulating slow disks, which can test the slow disk handling mechanism of a storage system and the overall performance of the storage system when a slow disk occurs. Injecting latency from the Linux kernel's blk layer provides a testing tool for slow disk detection mechanisms in distributed storage, supporting mechanical hard drives, SATA SSDs, and NVMe SSDs, making it a common slow disk injection scheme for distributed storage systems. Furthermore, the specific hard drive to be injected and the injection latency can be specified. It supports multi-queue kernel block devices, and the injection latency does not affect non-injected devices, causing no other adverse effects on the storage system.
[0099] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.
[0100] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.
[0101] The above provides a detailed description of a slow disk simulation method, apparatus, device, and medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A slow disk simulation method, characterized in that, include: When the target function begins execution, it jumps to the preset hook function through the preset jump instruction in the target function; The target function is a function in the block layer of the operating system kernel that processes I / O requests; the I / O request is an I / O request for the hard disk; the target function is the blk_mq_start_request function. The preset hook function is used to intercept IO requests, and preset logic is used to perform delayed injection; The method of using preset logic for delayed injection includes: determining whether the cumulative duration of the IO request from the request start time to the current time has reached a preset delay threshold; if it has not reached the preset delay threshold, executing the sleep function to make the cumulative duration reach the preset delay threshold. If the preset delay threshold is not reached, the sleep function is executed to make the accumulated time reach the preset delay threshold, including: if the preset delay threshold is not reached, calculating the time difference between the current accumulated time and the preset delay threshold, and executing the sleep function based on the time difference to make the accumulated time reach the preset delay threshold; After determining whether the cumulative duration of the IO request from the request start time to the current time has reached the preset delay threshold, the method further includes: if the preset delay threshold is reached, then the execution of the preset hook function is terminated; Before performing delayed injection using preset logic, the method further includes: determining whether the block device parameters carried in the IO request are consistent with the configuration parameters; if the block device parameters carried in the IO request are consistent with the configuration parameters, then performing delayed injection using preset logic.
2. The slow disk simulation method according to claim 1, characterized in that, Also includes: Configure the master device number and slave device number corresponding to the target hard disk to be injected with delay to obtain the configuration parameters.
3. A slow disk simulation device, characterized in that, include: The hook function adjustment module is used to jump to a preset hook function through a preset jump instruction in the target function when the target function starts executing; The target function is a function in the block layer of the operating system kernel that processes I / O requests; the I / O request is an I / O request for the hard disk; the target function is the blk_mq_start_request function. The delayed injection module is used to intercept IO requests using the preset hook function and perform delayed injection using preset logic; The method of using preset logic for delayed injection includes: determining whether the cumulative duration of the IO request from the request start time to the current time has reached a preset delay threshold; if it has not reached the preset delay threshold, executing the sleep function to make the cumulative duration reach the preset delay threshold. If the preset delay threshold is not reached, the sleep function is executed to make the accumulated time reach the preset delay threshold, including: if the preset delay threshold is not reached, calculating the time difference between the current accumulated time and the preset delay threshold, and executing the sleep function based on the time difference to make the accumulated time reach the preset delay threshold; After determining whether the cumulative duration of the IO request from the request start time to the current time has reached the preset delay threshold, the method further includes: if the preset delay threshold is reached, then the execution of the preset hook function is terminated; Before performing delayed injection using preset logic, the method further includes: determining whether the block device parameters carried in the IO request are consistent with the configuration parameters; if the block device parameters carried in the IO request are consistent with the configuration parameters, then performing delayed injection using preset logic.
4. An electronic device, characterized in that, Includes memory and processor, wherein: The memory is used to store computer programs; The processor is configured to execute the computer program to implement the slow disk emulation method as described in any one of claims 1 to 2.
5. A computer-readable storage medium, characterized in that, Used to store a computer program, wherein the computer program, when executed by a processor, implements the slow disk emulation method as described in any one of claims 1 to 2.