Method, apparatus and computer program product for processing input output request

Abstract

The invention relates to a method, a device and a computer program product for processing IO requests. The method includes sending a first IO request from a source end to a target end. The method further comprises the steps that whether the second IO request and the first IO request share the same page of the target end or not is determined based on the first page size of the source end and the second page size of the target end, and the second IO request is after the first IO request. In addition, the method further comprises the steps that the second IO request and the first IO request are responded to share the same page of the target end, and the second IO request is put into a queue to be queued to wait for sending. In this way, the sequential IO requests are reordered, IO performance degradation in the copying period of the cross-storage array platform is avoided, and the data transmission speed is increased.

Description

Technical Field

[0001] This invention relates to the field of data storage, and more particularly to methods, apparatus, and computer program products for processing input / output (I / O) requests. Background Technology

[0002] As is well known, page size is an internal parameter of a storage array. Not only do different types of storage arrays differ in page size, but also versions of the same storage array can vary in page size due to technological updates. Therefore, the same I / O pattern may result in different performance on storage array platforms with different parameters.

[0003] As storage array software evolves, the page size of the storage array may be changed during implementation to improve storage efficiency or for other purposes. This can typically improve host I / O performance in certain modes, but may not always be beneficial for replication I / O. Summary of the Invention

[0004] Embodiments of the present invention provide a method, apparatus, and computer program product for processing I / O requests.

[0005] According to a first aspect of an embodiment of the present invention, a method for processing an I / O request is provided, the method comprising: sending a first I / O request from a source to a target; determining, based on a first page size of the source and a second page size of the target, whether a second I / O request shares the same page of the target with the first I / O request, the second I / O request being after the first I / O request; and, in response to the second I / O request sharing the same page of the target with the first I / O request, placing the second I / O request in a queue to wait for transmission.

[0006] According to a second aspect of an embodiment of the present invention, an electronic device is provided, comprising: at least one processor; and instructions coupled to the at least one processor and having stored thereon, the instructions causing the electronic device to perform an action when executed by the at least one processor, the action comprising: sending a first I / O request from a source to a target; determining, based on a first page size of the source and a second page size of the target, whether a second I / O request shares the same page of the target with the first I / O request, the second I / O request being after the first I / O request; and, in response to the second I / O request sharing the same page of the target with the first I / O request, queuing the second I / O request for transmission.

[0007] According to a third aspect of an embodiment of the present invention, a computer program product is provided, which is tangibly stored on a non-volatile computer-readable medium and includes machine-executable instructions that, when executed, cause a machine to perform an action comprising: sending a first I / O request from a source to a target; determining, based on a first page size at the source and a second page size at the target, whether a second I / O request shares the same page at the target as the first I / O request, the second I / O request being after the first I / O request; and, in response to the second I / O request sharing the same page at the target as the first I / O request, queuing the second I / O request for transmission.

[0008] It should be understood that the description in the Summary of the Invention section is not intended to limit the key or essential features of the embodiments of this disclosure, nor is it intended to restrict the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0009] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals consistently denote the same or similar elements, as follows:

[0010] Figure 1 A schematic diagram of an environment for implementing an example scheme of this disclosure is shown;

[0011] Figure 2 A flowchart of a method for processing I / O requests according to some embodiments of the present disclosure is shown;

[0012] Figure 3A A schematic diagram of I / O request processing in asynchronous replication is shown according to some embodiments of the present disclosure;

[0013] Figure 3B Another schematic diagram of I / O request processing for asynchronous replication according to some embodiments of the present disclosure is shown;

[0014] Figure 4 A schematic diagram of IO request processing in synchronous replication according to some embodiments of the present disclosure is shown;

[0015] Figure 5 A schematic diagram illustrating the variation of the number of characters exiting the queue relative to the queue length according to some embodiments of the present disclosure is shown; and

[0016] Figure 6 A schematic block diagram of an example device suitable for implementing embodiments of the present disclosure is shown. Detailed Implementation

[0017] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0018] In the description of embodiments of this disclosure, the terms "comprising," "having," and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to." The term "based on" should be understood as "at least partially based on." The terms "embodiment," "an embodiment," or "the embodiment" should be understood as "at least one embodiment."

[0019] I / O patterns can exhibit different performance on storage array platforms with varying page sizes, where a page (or byte) is the smallest unit of storage, typically an integer multiple of the smallest unit of data read / write in a file system. For example, an I / O that is page-size aligned on one storage array might become page-size misaligned on another with a different page size. For instance, when the page size is set to 8KB, each I / O will have 8KB granularity in terms of data write / read, locking, and snapshot differences; if an I / O writes partial data within a page (an unaligned 8KB), the entire 8KB page will also need to be locked. If two ongoing I / Os share the same 8KB page, lock contention will occur between them, leading to increased I / O latency.

[0020] While increasing the page size of a storage array can improve storage efficiency and host I / O performance, it can lead to performance degradation when copying data volumes between storage arrays with different page sizes. For example, when copying a data volume from a source storage array to a target storage array, if the target array has a larger page size than the source array (e.g., the source array has a page size of 4KB while the target array has a page size of 8KB), the copy I / O that was aligned in the source array will be misaligned in the target array. This means two I / O operations will share an 8KB page, causing lock contention between the two I / O operations and resulting in I / O latency.

[0021] To address this, this disclosure provides a solution that determines whether the current IO request shares the same page as the previously sent IO request based on the page size of the source and target, thereby determining whether queuing processing of the current IO request is required. This avoids the IO performance degradation problem during cross-storage array platform replication and improves data transfer speed.

[0022] Figure 1 A schematic diagram of an environment 100 for implementing an example scheme of this disclosure is shown. Environment 100 includes a source end 102, an IO request processing unit 106, a target end 112, and IO requests, wherein the IO requests include sequential IO requests 104, an IO request waiting queue 108, and a first-come IO request 110. In some embodiments, the source end 102 may be a storage array system, a host, etc., the target end 112 may be a storage array system, etc., and the IO request processing unit 106 may be an organization providing tiered services, a replicator, etc.

[0023] like Figure 1 As shown, source 102 sends sequential I / O requests 104 to I / O request processing unit 106. The I / O requests in the sequential I / O request 104 are arranged sequentially. Since adjacent I / O requests may share the same page on the target end, they need to pass through I / O request processing unit 106 before being sent to target end 112. I / O request processing unit 106 can decide whether to reorder the sequential I / O requests 104, and when it is determined that the sequential I / O requests 104 need to be reordered, it performs the operation of sending the I / O requests in the sequential I / O request 104 to target end 112 in the new order.

[0024] In some embodiments, if the page size of the source end 102 is smaller than the page size of the target end, the IO request processing unit 106 determines that the sequential IO requests 104 need to be reordered. After issuing IO request 1 in the sequential IO requests 104, the IO request processing unit 106 determines whether IO request 2 will share the same page as IO request 1. If so, IO request 2 is placed in the IO request waiting queue 108 to wait for sending; otherwise, it is sent directly to the target end 112. Then, it determines whether IO request 3 will share the same page as the previously sent IO request. If not, IO request 3 is sent directly to the target end; if so, it is placed in the IO request waiting queue 108 to wait for sending. This process continues to judge and process subsequent IO requests, thereby forming the IO request waiting queue 108 in which IO requests are not adjacent and the first IO request 110. Because the IO requests in sequential IO request 104 are spaced very close together or even close to each other, once the first (odd-order) IO request is sent out, the even-order IO requests will have to wait. Therefore, the IO request waiting queue 108 consists of even-order IO requests, while the first IO request 110 consists of odd-order IO requests.

[0025] I / O requests waiting in I / O request queue 108 will be sent to the target end 112 by I / O request processing unit 106 when a send action is triggered. The triggering mechanism includes: when there is an I / O request callback, whether there are enough I / O requests in I / O request queue 108 or whether a sufficient amount of time has passed since the last I / O request was sent; or when a thread dedicated to scanning I / O request queue 108 detects that there are I / O requests in I / O request queue 108.

[0026] In this way, by comparing the page sizes of the source and target ends, and reordering IO requests when the page size of the source end is smaller than that of the target end, the problem of IO requests sharing a single page is avoided, thus preventing IO performance degradation. Compared to data transmission without IO reordering, this improves data transmission speed.

[0027] Figure 2 A flowchart illustrating a method 200 for processing I / O requests according to some embodiments of the present disclosure is shown. Method 200 can be... Figure 1 The process is executed in environment 100 as shown. Furthermore, the numbers in the flowchart do not indicate the order in which these steps are executed; some or all of these steps may be executed in parallel, or their execution order may be interchanged, and this disclosure does not impose any limitations on this.

[0028] At box 202, a first IO request is sent from the source to the target. In some embodiments, IO request 1 (IO request 3, IO request 5, etc.) is sent from the source 102 to the target 112. The first IO request can also be IO request 3, IO request 5, etc. in sequential IO requests 104, as long as they do not share the same page on the target 112, they can be sent to the target 112.

[0029] At box 204, based on the first page size of the source end and the second page size of the target end, it is determined whether the second IO request shares the same page on the target end as the first IO request, and the second IO request follows the first IO request. In some embodiments, based on the page size of the source end 102 and the page size of the target end 112, it is determined whether IO request 2 (IO request 4, IO request 6...) shares the same page on the target end as IO request 1 (IO request 3, IO request 5...). The second IO request can also be IO request 4, IO request 6, etc. in sequential IO requests 104, and the second IO request needs to be one step ahead of the first IO request in the IO order.

[0030] In some embodiments, when the page size of the source 102 is smaller than the page size of the target 112, if the offset of the IO from the source 102 (the distance between the actual address of the storage unit and the segment address of its segment is called the offset, also known as the intra-segment offset or effective address) cannot be aligned with the page size of the target 112 (from a storage perspective, this means that the IO from the source partially occupies the page of the target; from a mathematical perspective, this means that the offset cannot be divided evenly by the page size of the target), then for sequential IO requests 104 with an IO interval of 0, the offset of any IO request cannot be aligned with the page size of the target 112. In this case, adjacent IO requests will share the same page in the target 112, leading to lock contention and thus latency.

[0031] For sequential I / O requests with a non-zero I / O interval, the previous I / O request and the current I / O request may or may not share the same page. This needs to be determined based on the end offset of the previous I / O request, the offset of the current I / O request, and the page size of the target page 112. If the end offset of the previous I / O request satisfies the following equation:

[0032] (End offset - 1) / (page size) = Current IO offset / page size (1) Therefore, the previous IO request and the current IO request share the same page. In equation (1), the division sign represents integer division, the number 1 represents one byte, and the remaining parameters are converted to numerical values ​​in bytes for calculation. The page size refers to the page size of the target endpoint 112. Typically, the end offset of an IO request is not known, but it can be obtained by summing its offset and length, where the length of the IO request is usually fixed and known.

[0033] At box 206, in response to the second IO request sharing the same page on the target end as the first IO request, the second IO request is placed in a queue to await transmission. In some embodiments, in response to IO request 2 sharing the same page on the target end 112 as IO request 1, IO request 2 is placed in the IO request waiting queue 108 to await transmission. In embodiments, the second IO request needs to be one step ahead of the first IO request in order.

[0034] As for the foregoing, page size is a critical parameter during IO replication session execution. Existing mechanisms populate the local system's function list with predefined function values ​​via a data path proxy during system startup; when configuring the remote system, the peer's functions are queried and their values ​​saved to the remote system object, ensuring that the functions of both the source and remote systems are known before the replication session. In embodiments of this disclosure, this mechanism is extended by adding a new function representing the storage system's page size: if the system uses a 4KB page size, it has a function called PAGESIZE_IN_4KB; if the page size is 8KB, it uses PAGESIZE_IN_8KB.

[0035] Furthermore, in embodiments of this disclosure, new attributes are added to the data volume to facilitate operations performed using these attributes during the replication session. These new attributes include: optimal transfer length, whose value is initialized to the page size of the end (source or destination) where the data volume resides; and IO end offset, whose value is initialized to zero.

[0036] Figure 3A A schematic diagram of a flow 300A for I / O request processing in asynchronous replication according to some embodiments of the present disclosure is shown. Figure 3A In this process, replicator 308 periodically retrieves incremental snapshots from two snapshots in the scatter-aggregate list (a new snapshot 306 and a base snapshot 304). These snapshots are fully functional copies of data volume 302, containing all information about the data in data volume 302 at the point of copying. The time and I / O required to create these snapshots do not increase with the amount of data. In some storage systems, once the initial snapshot of data volume 302 is retrieved, subsequent snapshots only copy the changed data and use a pointer system to reference the initial snapshot. This pointer-based snapshot method consumes less disk space compared to repeatedly cloning the dataset.

[0037] After acquiring the increment, the replicator 308 splits it into fixed-length sequential I / O requests 104. This fixed length is related to the characteristics of the storage system itself, for example, it could be 64KB. To avoid performance degradation during replication I / O, two attributes are set in the replicator: a reordering indicator, which indicates whether to reorder the I / O requests; and an I / O end offset, whose value is initialized to 0. In some embodiments, if the source end of the data volume 302 has a PAGESIZE_IN_4KB capability and the target end has a PAGESIZE_IN_8KB capability, it can be determined that the page size of the source end is smaller than the page size of the target end. Therefore, after sending I / O request 1, the I / O end offset needs to be updated by summing the offset of I / O request 1 with the fixed length, and the offset of the next I / O request is compared with the updated I / O end offset to determine whether the next I / O request shares the same page as the previously sent I / O request.

[0038] If the offset of the next IO request satisfies equation (1) with the updated IO end offset, it can be determined that the next IO request will share the same page as the previously sent IO request. Therefore, the next IO request is placed in the waiting queue to await transmission. Otherwise, the next IO request is sent to sender 312, which then transmits it to the target end. The IO end offset is updated with the sum of the offset of the next IO request and a fixed length, and compared with the offset of the next IO request after that. This process continues, and the sequential IO requests 104 are actually reordered by the replicator 308 into non-sequential IO requests 310 with odd-order IO requests preceding even-order IO requests.

[0039] To ensure that queued I / O requests can also be sent, a dequeueing operation needs to be set up for them. Once the triggering condition is met, the queued I / O requests can be sent. There are two mechanisms for triggering this: one is to use a callback function. When an I / O request callback occurs, if there are enough I / O requests in the I / O request waiting queue 108 or a sufficiently long time has passed since the last I / O request was sent, the I / O requests in the waiting queue 108 will be sent. The other is to create a new thread specifically for scanning the I / O request waiting queue 108. When it detects that there is an I / O request in the waiting queue 108, it will trigger the sending of the I / O requests in the waiting queue 108.

[0040] In the mechanism of creating a new thread, the new thread is used to periodically scan all queues in replicator 308. If there is an IO request in any queue, a queue is dequeued and sent to sender 312 every replication cycle (a few milliseconds, depending on replication network overhead) to ensure that all requests are eventually sent. Otherwise, the last replicator IO request is dequeued.

[0041] If any IO request fails, the replicator 308 will clear the IO requests in the queue and stop at the failed IO request.

[0042] The following is combined with Figure 3B This describes the complete process of sequential I / O request 108 being sent to the target. Figure 3B A schematic diagram of a flow 300B for asynchronous replication IO request processing according to some embodiments of the present disclosure is shown. Figure 3B As shown, process 300B can be divided into five processes, including sequential IO sending process ①, IO request first sending process ②, IO request queuing process ③, IO request callback process ④, and IO request dequeueing process ⑤.

[0043] In the sequential IO sending process ①, the sequential IO request 104 is sent to the layered service 402. The layered service 402 can perform reordering processing on the sequential IO request 104 that is not aligned with the page size of the target end 112. For the first IO request 110 whose IO offset does not satisfy equation (1), the IO request first sending process ② is executed and it is sent directly to the target end 112. For the IO request whose IO offset satisfies equation (1), the IO request queuing process ③ is executed and it is placed in the IO request waiting queue 108 to wait for sending.

[0044] After the replication session of the IO request is completed at the target end 112, the data path executes the IO request callback procedure ④. During procedure ④, it checks whether there are enough IO requests in the IO request waiting queue 108, or whether enough time has elapsed since the last IO request was sent, such as at least 4 IO requests or 1ms, to further reduce conflicts. If so, the IO request dequeue procedure ⑤ is executed, dequeueing the IO requests in the IO request waiting queue 108 and sending them to the sender 312.

[0045] In this way, after the IO requests are rearranged, most IO requests will no longer share the same page. In some embodiments, the IO requests dequeued in the IO request dequeuing process ⑤ are IO requests that are determined to share the same page as the recalled IO requests. In some embodiments, the dequeued IO requests are random IO requests. In embodiments of this disclosure, dequeuing random IO requests from the queue was tested, and the results were not significantly different from those where the dequeued IO requests were IO requests that shared the same page as the recalled IO requests.

[0046] Figure 4 A schematic diagram of a flow 400 for I / O request processing in synchronous replication according to some embodiments of the present disclosure is shown. Figure 4 In this process, tiered service 402 receives sequential I / O requests 104 from the host. Typically, the storage array will always inform the host of its optimal transfer length, which is consistent with its internal page size. Therefore, when the host sends data with a page size consistent with the storage array, it achieves better performance. However, if the page size at the destination is larger than the page size at the source, in embodiments of this disclosure, the optimal transfer length of the source data volume is updated to the page size at the destination, and after replication is complete, the optimal transfer length of the source data volume is restored to the page size at the source.

[0047] Similar to the operations performed by replicator 308 in asynchronous replication, when the target remote system has a larger page size than the local system, the optimal transfer length of data volume 302 is updated to the target's page size. After the hierarchical service 402 sends an IO request to the navigator 404, the IO end offset is updated with the sum of the IO request's offset and a fixed length. The IO request's offset is then compared with the updated IO end offset to determine if the IO request shares the same page as the previously sent IO request. For example, after the hierarchical service 402 sends IO request 1 to the navigator 404, the IO end offset is updated with the sum of the IO request 1's offset and a fixed length. The offset of IO request 2 is then compared with the updated IO end offset to determine if IO request 2 shares the same page as IO request 1.

[0048] If the offset of the next IO request satisfies equation (1) with the updated IO end offset, it can be determined that the next IO request will share the same page as the previously sent IO request. Therefore, the next IO request is placed in the IO request waiting queue 108 to await sending. Otherwise, the next IO request is sent to the navigator 404, and the IO end offset is updated with the sum of the offset of the next IO request and a fixed length, and compared with the offset of the next IO request. For example, if the offset of IO request 2 satisfies equation (1) with the updated IO end offset, it can be determined that IO request 2 will share the same page as IO request 1. Therefore, IO request 2 is placed in the IO request waiting queue 108. Otherwise, IO request 2 is sent to the navigator 404, and the IO end offset is updated with the sum of the offset of IO request 2 and a fixed length.

[0049] In some embodiments, navigator 404, as another layered service for mirrored host I / O, is located below layered service 402 and is therefore transparent to I / O reordering. I / O requests arriving at navigator 402 can be directly sent to data volume 302 without further processing. Furthermore, since the I / O requests sent by the host are transmitted according to the optimal transfer length at the destination, I / O requests arriving at navigator 402 can also be directly sent to the sender for delivery to the destination (target site) without further processing. Additionally, at the destination (target site), the layered service will not reorder replicated I / O from the peer system.

[0050] For IO requests in IO request waiting queue 108, in order to ensure they can also be sent without increasing latency, the two mechanisms used in asynchronous replication described above are employed, and will not be repeated here (see reference). Figures 3A to 3B (and its description).

[0051] As described above, regardless of whether it's synchronous replication, asynchronous replication, or other replication types, IO reordering can avoid IO performance degradation caused by the source page size being smaller than the target page size. The following test results will demonstrate the improvement in IO latency achieved by using the methods described in this article.

[0052] Table 1 shows the test results on a 4KB page size system for reference. In the embodiments of this disclosure, the offset of partial writes is set to 2KB. It can be found that the average IO latency increases significantly, while the transmission speed drops to less than 1 / 10, where IOPS represents the number of reads and writes per second.

[0053] Table 1. Results of the Unaligned IO Copy Test

[0054]

[0055] Furthermore, as shown in Table 2, on systems with a 4KB page size, the Metro volume with unaligned host I / O was also tested in embodiments of this disclosure, where latency increased further due to the sharing of pages between two sites.

[0056] Table 2. Results of Unaligned Host I / O Replication Test

[0057]

[0058] However, after adopting the method described in this paper, tests were conducted using a system with a 4KB page size and an offset set to 2KB. The test results are shown in Table 3 and... Figure 5As shown in Table 3, during testing, the queue length was adjusted in the embodiments of this disclosure to achieve better performance. The results showed that a queue length greater than 3 had little impact. According to the results in Table 3, the latency of unaligned sequential IO was reduced from 22.86 milliseconds to approximately 1.6 milliseconds, indicating that the method of this disclosure reduces the sharing of unaligned IO requests in the queue on cached pages, thereby improving overall IO performance.

[0059] Table 3. Test results of unaligned IO replication after applying the method of this disclosure.

[0060]

[0061] also, Figure 5 A schematic diagram illustrating the variation of the number of characters exiting a line relative to the queue length according to some embodiments of the present disclosure is shown. The vertical axis represents the number of characters exiting a line, and the horizontal axis represents the queue length. (Refer to Table 3 and...) Figure 5 The results show that the optimal setting is to perform dequeueing when the queue length is greater than 4 or when more than 100 ns have elapsed. In the embodiments of this disclosure, logs show that when a dequeue request is made, the queue length is almost always less than 6. Therefore, in general, the queue length will be short, which means limited memory consumption.

[0062] Furthermore, in the embodiments of this disclosure, the situation of unaligned host I / O on a Metro volume was also tested, and it was found that the host I / O latency was also significantly improved compared to the previous values, as shown in Table 4.

[0063] Table 4. Test results of unaligned host I / O replication using the method disclosed herein

[0064]

[0065]

[0066] Figure 6 A schematic block diagram of an example device 600 that can be used to implement embodiments of the present disclosure is shown. As shown, device 600 includes a processor 601, which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) 602 or loaded from storage unit 608 into random access memory (RAM) 603. Various programs and data required for the operation of device 600 may also be stored in RAM 603. The processor 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0067] Multiple components in device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 606, such as various types of monitors, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0068] Processor 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 601 performs the various methods and processes described above, such as method 200. For example, in some embodiments, method 200 may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by processor 601, one or more steps of method 200 described above may be performed. Alternatively, in other embodiments, processor 601 may be configured to perform method 200 by any other suitable means (e.g., by means of firmware).

[0069] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload programmable logic devices (CPLDs), and so on.

[0070] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0071] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. Furthermore, although operations are depicted in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations.

[0072] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A method for processing input / output (I / O) requests, comprising: Send the first I / O request from the source to the target. Based on the first page size of the source end and the second page size of the target end, it is determined whether the second IO request shares the same page of the target end with the first IO request, and the second IO request is after the first IO request; as well as In response to the second IO request sharing the same page on the target end as the first IO request, the second IO request is placed in a queue to be sent.

2. The method according to claim 1, further comprising: In response to the callback of the first IO request, check whether there are more than a threshold number of IO requests in the queue; as well as In response to the presence of more than the threshold number of IO requests in the queue, the IO requests in the queue are sent to the target.

3. The method according to claim 1, further comprising: In response to the callback of the first IO request, check whether the queue has experienced a waiting time exceeding a threshold since the last IO request was sent; as well as In response to the queue having waited for more than a threshold time since the last I / O request was sent, the I / O request in the queue is sent to the target.

4. The method according to claim 1, further comprising: Create a thread to periodically check the I / O requests in the queue; as well as In response to the detection of an IO request in the queue by the thread, the IO request is sent to the target.

5. The method according to claim 1, further comprising: Set two properties for the data volume, wherein the two properties include: The optimal transfer length, whose value is initialized to the page size at the end of the data volume; and The IO end offset, whose value is initialized to zero.

6. The method according to claim 5, further comprising: In response to the replication from the source to the target being synchronous, the optimal transfer length of the data volume at the source is updated to the page size at the target. as well as In response to the completion of the copy, the optimal transfer length of the data volume at the source end is restored to the page size at the source end.

7. The method according to claim 5, further comprising: In response to the fact that the replication from the source to the target is asynchronous, two properties are set in the replicator, wherein the two properties include: Reordering instructions indicate whether to reorder I / O requests; and The IO end offset is initialized to zero.

8. The method according to claim 7, further comprising: The IO end offset is recorded in the replicator, and The value of the IO end offset is updated based on the IO offset of the first IO request and the length of the first IO request.

9. The method of claim 8, wherein determining whether the second IO request shares the same page of the target terminal with the first IO request comprises: Based on the offset of the second IO request, the IO end offset of the first IO request, and the page size of the target end, it is determined whether the second IO request shares the same page of the target end with the first IO request.

10. The method according to claim 1, further comprising: In response to the fact that the second IO request does not share the same page on the target end as the first IO request, the second IO request is sent to the target end.

11. An electronic device, the electronic device comprising: At least one processor; as well as A memory, coupled to the at least one processor and having instructions stored thereon, which, when executed by the at least one processor, cause the electronic device to perform actions, including: Send the first I / O request from the source to the target. Based on the first page size of the source end and the second page size of the target end, determine whether the second IO request shares the same page on the target end as the first IO request, wherein the second IO request follows the first IO request; and In response to the second IO request sharing the same page on the target end as the first IO request, the second IO request is placed in a queue to be sent.

12. The device according to claim 11, wherein the action further includes: In response to the callback of the first IO request, check whether there are more than a threshold number of IO requests in the queue; as well as In response to the presence of more than the threshold number of IO requests in the queue, the IO requests in the queue are sent to the target.

13. The device according to claim 11, wherein the action further includes: In response to the callback of the first IO request, check whether the queue has experienced a waiting time exceeding a threshold since the last IO request was sent; as well as In response to the queue having waited for more than a threshold time since the last I / O request was sent, the I / O request in the queue is sent to the target.

14. The device according to claim 11, wherein the action further includes: Create a thread to periodically check the I / O requests in the queue; as well as In response to the detection of an IO request in the queue by the thread, the IO request is sent to the target.

15. The device according to claim 11, wherein the action further includes: Set two properties for the data volume, wherein the two properties include: The optimal transfer length, whose value is initialized to the page size at the end of the data volume; and The IO end offset, whose value is initialized to zero.

16. The device according to claim 15, wherein the action further includes: In response to the replication from the source to the target being synchronous, the optimal transfer length of the data volume at the source is updated to the page size at the target. as well as In response to the completion of the copy, the optimal transfer length of the data volume at the source end is restored to the page size at the source end.

17. The device according to claim 15, wherein the action further includes: In response to the fact that the replication from the source to the target is asynchronous, two properties are set in the replicator, wherein the two properties include: Reordering instructions indicate whether to reorder I / O requests; and The IO end offset is initialized to zero.

18. The device according to claim 17, wherein the action further includes: The IO end offset is recorded in the replicator, and The value of the IO end offset is updated based on the IO offset of the first IO request and the length of the first IO request.

19. The device of claim 18, wherein determining whether the second IO request shares the same page of the target terminal with the first IO request comprises: Based on the offset of the second IO request, the IO end offset of the first IO request, and the page size of the target end, it is determined whether the second IO request shares the same page of the target end with the first IO request.

20. A computer program product tangibly stored on a non-volatile computer-readable medium and comprising machine-executable instructions that, when executed, cause a machine to: Send the first I / O request from the source to the target. Based on the first page size of the source end and the second page size of the target end, it is determined whether the second IO request shares the same page of the target end with the first IO request, and the second IO request is after the first IO request; as well as In response to the second IO request sharing the same page on the target end as the first IO request, the second IO request is placed in a queue to be sent.

Images