Method and system for controlling virtual block device I / O throttling based on device mapping framework

Abstract

This invention discloses a virtual block device I / O rate limiting control method and system based on a device mapping framework. The method includes: creating and initializing a control structure for the virtual block device; receiving block device I / O requests transmitted from the device mapping layer and remapping the request addresses; calculating the delay time of the request based on the request data size and rate limit, calculating the expiration time of the request by combining the current system time and the time window for the next allowed I / O request, adding the request to a rate limiting queue, starting a timer, and simultaneously updating the time window for the next allowed request and relevant statistics for all requests; after the timer expires, starting a rate limiting work queue thread, removing requests that have reached their expiration time from the rate limiting queue and dispatching them, while simultaneously updating relevant statistics for all requests in the virtual block device. This invention can achieve precise and stable control of the I / O rate of the underlying physical block device.

Description

Technical Field

[0001] This invention relates to the field of I / O rate limiting control technology, specifically to a virtual block device I / O rate limiting control method and system based on a device mapping framework. Background Technology

[0002] As a core component of the operating system's storage subsystem, the block device undertakes the basic tasks of data reading and writing, and its I / O performance and functionality directly affect the overall stability and service quality of the system.

[0003] On the one hand, in multi-tenant environments, virtual machine management (KVM / QEMU), container platforms (Docker / Kubernetes), and high-performance databases or log systems, I / O resources often become the focus of performance competition. When multiple applications or virtual disks compete for underlying storage bandwidth simultaneously, the system's I / O response time can increase sharply, even causing latency jitter in core services. With the development of multi-task concurrency and containerization technologies, multiple applications or virtual machine instances often share the same physical block device, leading to severe I / O bandwidth competition, significant system response time jitter, and even causing critical business latency to exceed limits.

[0004] On the other hand, I / O simulation and performance testing play an important role in kernel development and system integration. Developers often need to simulate specific I / O rates or latencies in a controlled environment to verify the stability of various services, test the consistency of the file system, and simulate the fault tolerance of various scenarios to I / O anomalies.

[0005] US Patent 10,768,827B2 discloses a method for customizing and throttling storage device performance at the per-virtual-drive level. Its focus is on allocating physical storage disks to meet virtual drive performance metrics, i.e., throttling from a resource allocation perspective (number of physical disks, mapping method), rather than limiting the I / O request rate itself at the drive link (such as the kernel device mapping layer). Secondly, this technology is primarily geared towards cloud / virtualization environments, with limited application in physical machine and I / O emulation scenarios. Chinese Patent Application CN202411744402.2 discloses I / O rate limiting methods, devices, electronic devices, storage media, and program products, but this technology mainly controls the I / O speed of preset executable files in the target virtual machine through a daemon in user space.

[0006] In summary, existing I / O rate limiting mechanisms provided by Linux systems (such as cgroup blkio, io.cost, and the BFQ scheduler) primarily target the process or control group level, scheduling request traffic at the application layer. They do not involve the kernel DM framework and struggle to provide precise rate limiting control for individual virtual block devices or complex logical devices. Furthermore, traditional cgroup or I / O scheduler-level rate limiting operations and configurations are complex and pose a significant barrier to entry for ordinary users. Therefore, there is an urgent need for a new technology applicable to container virtualization, storage QoS, and I / O emulation scenarios to achieve precise control and dynamic adjustment of I / O bandwidth and rate for any virtual block device. Summary of the Invention

[0007] The technical problem to be solved by the present invention is to provide a virtual block device I / O rate limiting control method and system based on a device mapping framework, in order to achieve accurate and stable control of the I / O rate of the underlying physical block device, thereby improving the stability and resource utilization of the storage system.

[0008] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0009] A virtual block device I / O rate limiting control method based on a device mapping framework includes the following steps:

[0010] S1, Initialization Construction: Create and initialize the control structure of the virtual block device used to store key metadata information for speed limit control;

[0011] S2, I / O Mapping: Receives block device I / O requests from the device mapping layer and remaps the addresses of the block device I / O requests to point to the underlying physical block device;

[0012] S3, I / O Rate Limiting Queuing: Calculate the latency of the block device I / O request based on the I / O data size and the preset rate limit. Combine this with the current system time and the time window maintained internally by the virtual block device for the next allowed I / O request to be sent, calculate the expiration time of the block device I / O request, add the block device I / O request to the I / O rate limiting queue, start the I / O rate limiting queue timer, and simultaneously update the time window for the next allowed I / O request to be sent in the virtual block device and all block device I / O request related statistics.

[0013] S4, I / O rate limiting dequeue: After the I / O rate limiting queue timer expires, the rate limiting work queue thread is started to remove the block device I / O requests that have reached their expiration time from the I / O rate limiting queue from the queue and dispatch them to the underlying physical block device. At the same time, the statistics related to all block device I / O requests in the virtual block device are updated.

[0014] Further, step S1 includes:

[0015] In the Linux kernel, a control structure is defined for managing virtual block devices with I / O rate limiting. The control structure defines one or more of the following: the underlying physical device information corresponding to the virtual block device, the device's starting sector, the user-defined I / O rate limit, and I / O scheduling-related resource parameters.

[0016] Specifically, during the initialization of the I / O scheduling-related resource parameters, a timer for triggering I / O timeout processing, a work queue and work tasks for asynchronously dispatching I / O requests are created, and a queue structure for caching rate-limited I / O requests is established. At the same time, the throttling control flag and the next I / O sendable time window parameters are initialized.

[0017] Furthermore, step S2 also includes filtering block device I / O requests, as follows:

[0018] If the block device I / O request is a special I / O request or the corresponding I / O length is 0, the block device I / O request is returned to the device mapping layer, which then directly passes the block device I / O request to the underlying physical block device.

[0019] Furthermore, in step S3, the expression for calculating the delay time delay_ms of the block device I / O request is:

[0020] delay_ms = ceil(bytes * 1000 / rate_bps);

[0021] bytes = bio_sectors(bio)<<9;

[0022] In the above formula, bytes represents the data size of the current block device I / O request, bio_sectors(bio) represents the number of sectors contained in the current block device I / O request, << represents a left shift operation, rate_bps represents the device's allowed I / O rate limit set when creating the virtual block device, and ceil() is the round-up function;

[0023] The expression for calculating the expires time of block device I / O requests is:

[0024] expires = start + delay_ms;

[0025] start = max(jiffies, next_avail);

[0026] In the above formula, start is the time base for calculating the delay of the current block device I / O request, jiffies is the current system time, next_avail is the time window maintained internally by the virtual block device for the next allowed I / O request, and max() indicates taking the maximum value.

[0027] Furthermore, in step S3, the time window for the next allowed I / O request in the virtual block device is set to the expiration time of the current block device I / O request; the block device I / O request related statistics include the number of block device I / O requests temporarily stored in the current I / O rate limiting queue and the current I / O issuance rate.

[0028] Furthermore, in step S3, when starting the I / O rate limiting queue timer, it is also necessary to determine whether the timer corresponding to the current I / O rate limiting queue is in an inactive state or whether the expiration time of the current block device I / O request is earlier than the set timer trigger time. If it is in an inactive state or earlier than the set timer trigger time, the timer trigger time is updated through the timer modification interface so that the timer triggers at the expiration time of the current block device I / O request, thereby driving the dispatching and processing of the expired block device I / O requests in the I / O rate limiting queue.

[0029] Further, in step S4, after the I / O rate limiting queue timer expires, the rate limiting work queue thread is started to remove block device I / O requests that have reached their expiration time from the I / O rate limiting queue and dispatch them to the underlying physical block device. This specifically includes:

[0030] When the timer in the I / O rate limiting queue expires, a callback function is triggered, in which a rate limiting processing thread is started through the work queue mechanism;

[0031] In the rate limiting processing thread, the I / O rate limiting queue is traversed, and each block device I / O request in the queue is detected. Block device I / O requests that have reached their expiration time are removed from the rate limiting queue and added to the dispatch queue. For block device I / O requests that have not reached their expiration time, the next trigger time of the timer is updated to the expiration time of the earliest expiring block device I / O request, and the timer is restarted.

[0032] Traverse the queue of pending requests and dispatch all block device I / O requests to the underlying physical block device through the block layer I / O submission interface.

[0033] Furthermore, the method also includes performing a resource release operation when the virtual block device is unloaded, including:

[0034] Call the work queue destruction interface to release the work queue resources created during the initialization phase;

[0035] Call the timer synchronization deletion interface to stop and release the timer resources used for I / O scheduling;

[0036] Release the memory resources occupied by the control structure.

[0037] A virtual block device I / O rate limiting control system based on a device mapping framework includes a microprocessor and a memory interconnected, the microprocessor being programmed or configured to execute the steps of a virtual block device I / O rate limiting control method based on a device mapping framework.

[0038] A computer-readable storage medium storing a computer program / instructions programmed or configured to execute, via a processor, the steps of a virtual block device I / O rate limiting control method based on a device mapping framework.

[0039] Compared with the prior art, the advantages of the present invention are as follows:

[0040] This invention constructs and initializes a virtual block device control structure, enabling unified management of key metadata information for rate limiting control and providing a stable operating environment for subsequent I / O rate limiting scheduling. By remapping I / O request addresses, virtual block devices can transparently access underlying physical devices, improving system compatibility without requiring modifications to the underlying drivers. Calculating latency based on I / O data volume and rate limits and maintaining the next I / O transmission window allows for precise rate limiting and orderly queuing of I / O requests, avoiding bandwidth surges caused by sudden I / O. The orderly dispatch of expired I / O requests through a timer and work queue coordination mechanism improves scheduling efficiency and reduces system overhead. This invention achieves precise and stable control of the I / O rate of the underlying physical block devices, improving the stability and resource utilization of the storage system. Attached Figure Description

[0041] Figure 1 This diagram illustrates the block device I / O processing architecture and data flow in the Linux kernel.

[0042] Figure 2 This is a flowchart of a virtual block device I / O rate limiting control method based on a device mapping framework, according to an embodiment of the present invention.

[0043] Figure 3 This is a flowchart of I / O rate limiting in a specific application embodiment, where the left half is the process of I / O rate limiting enqueueing and the right half is the process of I / O rate limiting dequeueing.

[0044] Figure 4 This is a flowchart of a virtual block device I / O rate limiting control method based on a device mapping framework, as shown in a specific application embodiment. Detailed Implementation

[0045] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0046] The following are definitions of some abbreviations and key terms in this invention:

[0047] DM: DM (Device Mapper) is a block device virtualization framework for the Linux kernel that allows logical device behavior to be defined in some form within the kernel, such as mapping, caching, snapshots, encryption, etc.

[0048] BIO: BIO (Block I / O) is a data structure in the kernel that represents block device I / O requests and is the basic unit of interaction between the file system and the block layer.

[0049] IOPS: IOPS (Input / Output Operations Per Second) is the number of input / output operations per second, used to measure the read and write performance of block devices.

[0050] QoS: QoS (Quality of Service) refers to a technology or strategy used in computers to improve the quality of service, aiming to ensure the performance, reliability, and response time of services, especially for applications with strict requirements on indicators such as latency, bandwidth, and packet loss.

[0051] Block: Block is short for Generic Block Layer in the Linux kernel, which is responsible for tasks such as I / O scheduling, request management, scheduler selection, and cache processing of block devices.

[0052] Cgroup: cgroup is a resource management mechanism provided by Linux that can control the quotas of CPU, memory, I / O and other resources of process groups.

[0053] dm-ioband: This refers to a DM-based target implemented in this invention, which supports rate limiting of the underlying physical block storage. This invention uses a custom Device Mapper target, implementing access, metering, and latency mechanisms for BIO requests within its map() function, forming dynamically adjustable rate control logic to meet user I / O rate requirements in specific scenarios.

[0054] like Figure 1As shown, the Linux kernel's block device I / O processing adopts a layered architecture. The overall process, from top to bottom, passes through the application layer, virtual file system (VFS), logical file system, device mapping layer, block layer, and the actual physical device driver. Clear abstract interfaces are used between each layer to ensure the system's scalability and composability. The overall process framework is as follows:

[0055] 1. Application Layer: User-space applications submit I / O requests to the kernel through system calls (such as read / write). These requests are first passed to the standard library and system call interfaces.

[0056] 2. Virtual File System (VFS): As an abstraction layer for multiple file systems, VFS is responsible for unifying the file system interface. The common file system interface and processing logic are handled by the VFS layer, and then handed over to the specific logical file system, such as XFS, EXT4, etc.

[0057] 3. Logical File System: I / O requests forwarded by VFS will be resolved by the specific file system (EXT4, XFS, etc.) by parsing the file address, inode, data block location, etc., and the corresponding block address will be calculated based on the logical address.

[0058] 4. Device Mapper: The Device Mapper is a general framework in the Linux kernel used to build virtual block devices. It implements various capabilities such as encryption, RAID, caching, and snapshots through pluggable targets, serving as the core virtualization hub between the file system layer and physical devices. It is optional along the entire I / O storage path, providing more advanced functionality to the underlying physical storage media. It can intercept I / O to implement various QoS functions, such as dm-crypt encryption, dm-thin thin provisioning, dm-cache caching, and dm-multipath multipathing. In terms of process, after a block-level BIO request enters the Device Mapper, it performs BIO redirection or fragmentation and I / O attribute correction according to the target's logic, finally mapping it into a new underlying BIO and sending it to the lower-level block device.

[0059] 5. Block Layer: The block layer is the core scheduling layer in the Linux I / O stack. It is responsible for organizing general I / O requests from the file system or DM layer into BIO structures, and is responsible for I / O merging, splitting, scheduling, etc. Finally, it distributes the requests to the appropriate lower-level devices according to the device mapping relationship.

[0060] 6. Device Driver Layer: After I / O requests pass through the Block Layer, they eventually enter the Device Driver Layer. Located between the kernel and the hardware, the Device Driver Layer is responsible for translating uniform block I / O requests into instruction formats that the specific hardware can understand, and managing all interactions with the hardware.

[0061] 7. Storage Device: A storage device is the underlying physical storage medium, such as NVMe SSD, SATA HDD, RAID array, etc. The storage device performs the actual read and write operations and returns the results to the application through the same path.

[0062] like Figure 2 As shown, the virtual block device I / O rate limiting control method based on the device mapping framework in this embodiment includes the following steps:

[0063] S1, Initialization Construction: Create and initialize the control structure of the virtual block device used to store key metadata information for speed limit control;

[0064] S2, I / O Mapping: Receives block device I / O requests (BIO) from the device mapping layer and remaps the addresses of the block device I / O requests to point to the underlying physical block device.

[0065] S3, I / O Rate Limiting Queuing: Calculate the latency of the block device I / O request based on the I / O data size and the preset rate limit. Combine this with the current system time and the time window maintained internally by the virtual block device for the next allowed I / O request to be sent, calculate the expiration time of the block device I / O request, add the block device I / O request to the I / O rate limiting queue, start the I / O rate limiting queue timer, and simultaneously update the time window for the next allowed I / O request to be sent in the virtual block device and all block device I / O request related statistics.

[0066] S4, I / O rate limiting dequeue: After the I / O rate limiting queue timer expires, the rate limiting work queue thread is started to remove the block device I / O requests that have reached their expiration time from the I / O rate limiting queue from the queue and dispatch them to the underlying physical block device. At the same time, the statistics related to all block device I / O requests in the virtual block device are updated.

[0067] In specific application embodiments, such as Figure 1As shown, a Device Mapper target named dm-ioband, implemented within the Device Mapper framework, supports stacked virtual block devices and provides basic I / O rate limiting capabilities. Located within the Device Mapper layer, dm-ioband performs bandwidth shaping, rate limiting, and priority control on underlying I / O based on rate limiting policies. It can be directly mapped to the underlying physical storage medium to achieve precise rate limiting control of physical block devices.

[0068] In this embodiment, step S1 includes:

[0069] In the Linux kernel, a control structure is defined for managing virtual block devices with I / O rate limiting. The control structure defines one or more of the following: the underlying physical device information corresponding to the virtual block device, the device's starting sector, the user-defined I / O rate limit, and I / O scheduling-related resource parameters.

[0070] Specifically, during the initialization of the I / O scheduling-related resource parameters, a timer for triggering I / O timeout processing, a work queue and work tasks for asynchronously dispatching I / O requests are created, and a queue structure for caching rate-limited I / O requests is established. At the same time, the throttling control flag and the next I / O sendable time window parameters are initialized.

[0071] In a specific application example, the initialization build (ctr) mainly includes parsing configuration parameters, initializing the timer, workqueue, lock, and throttling switch, obtaining the underlying physical storage device to be rate-limited, and saving it to a specific location. The specific process is as follows:

[0072] Define a struct ioband_c structure to store key metadata information:

[0073] struct ioband_c {

[0074] struct dm_dev *dev; / / Corresponds to the underlying physical device

[0075] sector_t start;

[0076] / * bytes per second rate limit * /

[0077] unsigned long rate_bps; / / User-defined I / O rate limit

[0078] / * scheduling * /

[0079] struct timer_list timer; / / Timer used to trigger I / O timeouts

[0080] struct workqueue_struct *wq;

[0081] struct work_struct flush_work; / / wq and flush_work are used to dispatch timed-out controlled I / O.

[0082] struct list_head queued_bios; / / A linked list used to store rate-limited I / O operations.

[0083] / * control flags * /

[0084] atomic_t may_throttle; / / Throttling control flag

[0085] / * next available jiffies for sending a new bio (serialized schedule)* /

[0086] unsigned long next_avail; / / Parameter for the next I / O window to be sent.

[0087] };

[0088] Optionally, the static int ioband_ctr(struct dm_target *ti, unsignedint argc, char **argv) function can be implemented to parse configuration parameters and initialize parameters such as timer, workqueue, lock, and throttling switch.

[0089] In this embodiment, step S2 further includes filtering block device I / O requests, as follows:

[0090] If the block device I / O request is a special I / O request or the corresponding I / O length is 0, the block device I / O request is returned to the device mapping layer, which then directly passes the block device I / O request to the underlying physical block device.

[0091] In a specific application embodiment, step S2 includes I / O mapping and filtering, mainly involving remapping the BIO to the sectors of the underlying block device (common read / write path); for special operations (such as REQ_PREFLUSH, FLUSH, DISCARD, and zero-length BIO), direct pass-through is performed without rate limiting. The `static int ioband_map(struct dm_target *ti, struct bio *bio)` function can be implemented for I / O mapping and filtering, and its main working logic is as follows:

[0092] The I / O offsets and sizes of BIO passed down from the Device Mapper are for dm-ioband and need to be remapped to sectors of the underlying physical storage medium.

[0093] Determine whether the BIO operation is a special I / O operation such as REQ_PREFLUSH. If it is, return it directly to the DeviceMapper layer, and the DM layer will directly pass it through to the underlying storage device.

[0094] Check if the I / O length corresponding to BIO is 0. If it is, return it directly to the Device Mapper layer. Similarly, DM will be directly sent to the underlying storage device.

[0095] In this embodiment, the expression for calculating the delay time delay_ms of the block device I / O request in step S3 is as follows:

[0096] delay_ms = ceil(bytes * 1000 / rate_bps);

[0097] bytes = bio_sectors(bio)<<9;

[0098] In the above formula, bytes represents the data size of the current block device I / O request, bio_sectors(bio) represents the number of sectors contained in the current block device I / O request, << represents a left shift operation, rate_bps represents the device's allowed I / O rate limit set when creating the virtual block device, and ceil() is the round-up function;

[0099] The expression for calculating the expires time of block device I / O requests is:

[0100] expires = start + delay_ms;

[0101] start = max(jiffies, next_avail);

[0102] In the above formula, start is the time base for calculating the delay of the current block device I / O request, jiffies is the current system time, next_avail is the time window maintained internally by the virtual block device for the next allowed I / O request, and max() indicates taking the maximum value.

[0103] In this embodiment, in step S3, the time window for the next allowed I / O request in the virtual block device is set as the expiration time of the current block device I / O request; the block device I / O request related statistics include the number of block device I / O requests temporarily stored in the current I / O rate limiting queue and the current I / O issuance speed.

[0104] In this embodiment, in step S3, when starting the I / O rate limiting queue timer, it is also necessary to determine whether the timer corresponding to the current I / O rate limiting queue is in an inactive state or whether the expiration time of the current block device I / O request is earlier than the set timer trigger time. If it is in an inactive state or earlier than the set timer trigger time, the timer trigger time is updated through the timer modification interface so that the timer is triggered at the expiration time of the current block device I / O request, thereby driving the dispatching process of the expired block device I / O requests in the I / O rate limiting queue.

[0105] Following the filtering operation in step S2, only rate limiting is needed for regular read / write I / O. In a specific application embodiment, combined with... Figure 3 The flowchart shown below illustrates the I / O rate limiting and queuing process (the entire I / O rate limiting process). Figure 3 The left half of the text will be used to explain the detailed implementation of I / O rate limiting and requeuing in step S3.

[0106] S31, Calculate I / O size based on BIO:

[0107] bytes = bio_sectors(bio)<<9;

[0108] S32, calculate the I / O rate-limited latency based on bytes and the set rate limit rate_bps, where rate_bps is the device I / O rate set when creating the dm-ioband, in bytes per second; the calculation expression is as follows:

[0109] delay_ms = ceil(bytes * 1000 / rate_bps);

[0110] S33, calculate the expiration time of this I / O based on the dispatch time of the previous I / O:

[0111] start = max(jiffies, next_avail), expires = start + delay_ms;

[0112] Where next_avail is the time expiration window maintained by the dm-ioband kernel. If the dispatchable time of the previous BIO is next_avail, then the timeout start point of the current BIO calculation is the larger of the current system time jiffies and next_avail.

[0113] S34, based on the above parameter information, add the BIO to the I / O rate limiting queue:

[0114] After the BIO update expires, add it to the rate-limiting queue using list_add_tail(&info->list,&ic->queued_bios);

[0115] S35, start the I / O rate limiting queue timer:

[0116] First, check if the current system timer queue is empty and if the timeout of this BIO is earlier than the timeout of the previous BIO. If necessary, start the timer using mod_timer(&ic->timer, expires).

[0117] S36, Update dm-ioband statistics:

[0118] First, next_avail needs to be updated by assigning the current BIO's expires time to next_avail, indicating that the timeout window for the next BIO starts from the current BIO's expires time. At the same time, dm-ioband also maintains the number of BIOs temporarily stored in the current rate-limiting queue and the current I / O issuance speed, so it is updated synchronously.

[0119] In this embodiment, step S4, after the I / O rate limiting queue timer expires, starts the rate limiting work queue thread to remove block device I / O requests that have reached their expiration time from the I / O rate limiting queue and dispatch them to the underlying physical block device. Specifically, this includes:

[0120] When the timer in the I / O rate limiting queue expires, a callback function is triggered, in which a rate limiting processing thread is started through the work queue mechanism;

[0121] In the rate limiting processing thread, the I / O rate limiting queue is traversed, and each block device I / O request in the queue is detected. Block device I / O requests that have reached their expiration time are removed from the rate limiting queue and added to the dispatch queue. For block device I / O requests that have not reached their expiration time, the next trigger time of the timer is updated to the expiration time of the earliest expiring block device I / O request, and the timer is restarted.

[0122] Traverse the queue of pending requests and dispatch all block device I / O requests to the underlying physical block device through the block layer I / O submission interface.

[0123] In specific application embodiments, combined with Figure 3 The I / O rate limiting and dequeueing flowchart shown (the entire I / O rate limiting process) Figure 3 The right half of the text will be used to explain the detailed implementation of I / O rate limiting dequeueing in step S4.

[0124] S41, Start the rate-limiting work queue thread:

[0125] The I / O rate limiting queue has added BIO to the queue and started a timeout timer. When the timer expires, an expiration callback function will be called, in which the work queue thread will be started: queue_work(ic->wq,&ic->flush_work);

[0126] S42, collect expired BIOs:

[0127] Implement the `struct bio *ioband_collect_ready_bios(struct ioband_c *ic, intflush_all)` interface to collect expired BIOs. The basic logic is to use `list_for_each_entry_safe(elem, next, &ic->queued_bios, list)` to iterate through the timeout queue. For each BIO, if it has expired, it is removed from the timeout queue and added to the dispatch queue; if it has not expired, the timer timeout is updated and the timer is started again to prepare for processing when the timer is triggered next time.

[0128] S43, Distribute expired BIOs:

[0129] Iterate through the BIOs collected in the dispatch queue in the previous step, and call generic_make_request to dispatch them to the underlying block layer;

[0130] S44, Update dm-ioband statistics:

[0131] Similar to step S36 of the I / O rate-limiting queue enqueue, which updates the dm-ioband statistics, BIOs that are removed and dispatched need to have their statistics updated synchronously.

[0132] It should be noted that the rate-limited dequeueing adopts a timed refresh (Timer + Workqueue) working mode. When the timer set in step S3 expires, it triggers the work queue. The work function collects the "expired" BIOs and then sends them down to the underlying device. If there are still unexpired BIOs in the queue, the timer is set to the time of the earliest expiring BIO item.

[0133] In this embodiment, as Figure 4 As shown, corresponding to step S1 "Initialize Build", the method further includes an exit cleanup (dtr) step that performs resource release operations when the virtual block device is unloaded, including:

[0134] Call the work queue destruction interface destroy_workqueue() to release the work queue resources created during the initialization phase;

[0135] Call the timer synchronization deletion interface del_timer_sync() to stop and release the timer resources used for I / O scheduling;

[0136] Call the kfree() interface to release the memory resources occupied by the control structure struct iobanc_c.

[0137] It is understood that the device-mapper-based virtual block device I / O rate limiting control method implemented in this embodiment enables users to achieve precise control over the I / O bandwidth and rate of the underlying physical storage device based on a virtual stack block device, with finer rate limiting granularity (device-level rate limiting can be achieved), meeting the user's I / O rate requirements in specific scenarios.

[0138] The present invention further provides a virtual block device I / O rate limiting control system based on a device mapping framework, including a microprocessor and a memory interconnected thereto, wherein the microprocessor is programmed or configured to execute the steps of a virtual block device I / O rate limiting control method based on a device mapping framework.

[0139] The present invention further provides a computer-readable storage medium storing a computer program / instructions, the computer program / instructions being programmed or configured to execute, via a processor, the steps of a virtual block device I / O rate limiting control method based on a device mapping framework.

[0140] The system and medium of the present invention, corresponding to the methods described above, also have the advantages described above.

[0141] The present invention can implement all or part of the processes in the methods of the above embodiments, or it can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of the above method embodiments. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. Computer-readable media include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. The memory is used to store computer programs and / or modules. The processor implements various functions by running or executing the computer programs and / or modules stored in the memory, and by calling data stored in the memory. The memory may include high-speed random access memory, as well as non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart media cards (SMC), secure digital (SD) cards, flash cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0142] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A virtual block device I / O rate limiting control method based on a device mapping framework, characterized in that, Including the following steps: S1, Initialization Construction: Create and initialize the control structure of the virtual block device used to store key metadata information for speed limit control; S2, I / O Mapping: Receives block device I / O requests from the device mapping layer and remaps the addresses of the block device I / O requests to point to the underlying physical block device; S3, I / O Rate Limiting Queuing: Calculate the latency of the block device I / O request based on the I / O data size and the preset rate limit. Combine this with the current system time and the time window maintained internally by the virtual block device for the next allowed I / O request to be sent, calculate the expiration time of the block device I / O request, add the block device I / O request to the I / O rate limiting queue, start the I / O rate limiting queue timer, and simultaneously update the time window for the next allowed I / O request to be sent in the virtual block device and all block device I / O request related statistics. S4, I / O rate limiting dequeue: After the I / O rate limiting queue timer expires, the rate limiting work queue thread is started to remove the block device I / O requests that have reached their expiration time from the I / O rate limiting queue from the queue and dispatch them to the underlying physical block device. At the same time, the statistics related to all block device I / O requests in the virtual block device are updated. In step S3, the expression for calculating the delay time delay_ms of the block device I / O request is as follows: delay_ms = ceil(bytes * 1000 / rate_bps); bytes = bio_sectors(bio)<<9; In the above formula, bytes represents the data size of the current block device I / O request, bio_sectors(bio) represents the number of sectors contained in the current block device I / O request, << represents a left shift operation, rate_bps represents the device's allowed I / O rate limit set when creating the virtual block device, and ceil() is the round-up function; The expression for calculating the expires time of block device I / O requests is: expires = start + delay_ms; start = max(jiffies, next_avail); In the above formula, start is the time base for calculating the delay of the current block device I / O request, jiffies is the current system time, next_avail is the time window maintained internally by the virtual block device for the next allowed I / O request, and max() indicates taking the maximum value; In step S3, the statistics related to block device I / O requests include the number of block device I / O requests temporarily stored in the current I / O rate limiting queue and the current block device I / O issuance rate.

2. The virtual block device I / O rate limiting control method based on a device mapping framework according to claim 1, characterized in that, Step S1 includes: In the Linux kernel, a control structure is defined for managing virtual block devices with I / O rate limiting. The control structure defines one or more of the following: the underlying physical device information corresponding to the virtual block device, the device's starting sector, the user-defined I / O rate limit, and I / O scheduling-related resource parameters. Specifically, during the initialization of the I / O scheduling-related resource parameters, a timer for triggering I / O timeout processing, a work queue and work tasks for asynchronously dispatching I / O requests are created, and a queue structure for caching rate-limited I / O requests is established. At the same time, the throttling control flag and the next I / O sendable time window parameters are initialized.

3. The virtual block device I / O rate limiting control method based on a device mapping framework according to claim 1, characterized in that, Step S2 also includes filtering block device I / O requests, as follows: If the block device I / O request is a special I / O request or the corresponding I / O length is 0, the block device I / O request is returned to the device mapping layer, which then directly passes the block device I / O request to the underlying physical block device.

4. The virtual block device I / O rate limiting control method based on a device mapping framework according to claim 1, characterized in that, In step S3, the time window for the next allowed I / O request in the virtual block device is set to the expiration time of the current block device I / O request.

5. The virtual block device I / O rate limiting control method based on a device mapping framework according to claim 1, characterized in that, In step S3, when starting the I / O rate limiting queue timer, it is also necessary to determine whether the timer corresponding to the current I / O rate limiting queue is in an inactive state or whether the expiration time of the current block device I / O request is earlier than the set timer trigger time. If it is in an inactive state or earlier than the set timer trigger time, the timer trigger time is updated through the timer modification interface so that the timer triggers at the expiration time of the current block device I / O request, thereby driving the dispatching and processing of the expired block device I / O requests in the I / O rate limiting queue.

6. The virtual block device I / O rate limiting control method based on a device mapping framework according to claim 1, characterized in that, In step S4, after the I / O rate limiting queue timer expires, the rate limiting work queue thread is started to remove block device I / O requests that have reached their expiration time from the I / O rate limiting queue and dispatch them to the underlying physical block device. Specifically, this includes: When the timer in the I / O rate limiting queue expires, a callback function is triggered, in which a rate limiting processing thread is started through the work queue mechanism; In the rate limiting processing thread, the I / O rate limiting queue is traversed, and each block device I / O request in the queue is detected. Block device I / O requests that have reached their expiration time are removed from the rate limiting queue and added to the dispatch queue. For block device I / O requests that have not reached their expiration time, the next trigger time of the timer is updated to the expiration time of the earliest expiring block device I / O request, and the timer is restarted. Traverse the queue of pending requests and dispatch all block device I / O requests to the underlying physical block device through the block layer I / O submission interface.

7. The virtual block device I / O rate limiting control method based on a device mapping framework according to claim 1, characterized in that, The method further includes performing a resource release operation when the virtual block device is unloaded, including: Call the work queue destruction interface to release the work queue resources created during the initialization phase; Call the timer synchronization deletion interface to stop and release the timer resources used for I / O scheduling; Release the memory resources occupied by the control structure.

8. A virtual block device I / O rate limiting control system based on a device mapping framework, comprising a microprocessor and a memory interconnected, characterized in that, The microprocessor is programmed or configured to perform the steps of the virtual block device I / O rate limiting control method based on a device mapping framework as described in any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program / instructions, characterized in that, The computer program / instructions are programmed or configured to execute the steps of the virtual block device I / O rate limiting control method based on the device mapping framework as described in any one of claims 1 to 7 via a processor.

Images