Request processing method and device, equipment, medium and program product

Abstract

The invention discloses a request processing method and device, equipment, a medium and a program product, and relates to the technical field of electronic computers.The request processing method comprises the steps that an original IO request issued by an application program in a host is received, and a disk list related to the original IO request is searched; if a bad disk exists in the disk list, request information of the original IO request and bad disk information are sent to a software engine, and the software engine splits the original IO request into a first sub-IO request involving the bad disk and a second sub-IO request not involving the bad disk; receiving request information of a second sub-IO request returned by the software engine; based on the request information of the second sub IO request, IO operation irrelevant to the bad disk is executed, and the software engine executes IO operation relevant to the bad disk according to the request information of the first sub IO request. For the IO request of the bad disk, the IO is cooperatively processed through software and hardware, the problem that the processing efficiency of the IO request of the bad disk is low is solved, and it is ensured that the IO of the bad disk can be efficiently processed.

Description

Technical Field

[0001] This application relates to the field of electronic computer technology, and more particularly to request processing methods, apparatus, devices, media, and program products. Background Technology

[0002] In data center server systems, to improve hard drive read / write performance, scalability, and security, server manufacturers integrate RAID (Redundant Arrays of...) based on PCIe (Peripheral Component Interconnect Express, a high-speed serial computer expansion bus standard) interfaces. Independent Disks (RAID) cards utilize hardware RAID to manage hard drives and are widely used to support SATA (Serial Advanced Technology Attachment) mechanical hard drives.

[0003] Currently, in some technologies, hardware design becomes extremely complex and costly for I / O requests involving faulty disks (i.e., requests for input and output operations). Therefore, these requests are typically handled by software engines. However, because software processing speed is far slower than hardware, I / O processing efficiency is low and cannot meet the needs of practical applications. Therefore, there is an urgent need for a technical solution to improve the efficiency of faulty disk I / O request processing, in order to solve the problem of low I / O processing efficiency in related technologies. Summary of the Invention

[0004] This application provides a request processing method, request processing apparatus, electronic device, computer-readable storage medium, and computer program product to at least solve the problem of low efficiency in bad disk I / O request processing in related technologies.

[0005] This application provides a request processing method applied to a hardware engine, including:

[0006] Receive raw I / O requests from applications on the host and look up the list of disks associated with the raw I / O requests;

[0007] If a bad disk is found in the disk list, the request information and bad disk information of the original IO request are sent to the software engine. The software engine is used to split the original IO request into a first sub-IO request and a second sub-IO request based on the request information and bad disk information. The first sub-IO request is used to indicate IO operations related to the bad disk, and the second sub-IO request is used to indicate IO operations unrelated to the bad disk.

[0008] Receive the request information for the second sub-IO request returned by the software engine;

[0009] Based on the request information of the second sub-IO request, perform IO operations unrelated to the bad disk; based on the request information of the first sub-IO request, the software engine performs IO operations related to the bad disk.

[0010] This application also provides another request processing method for use in software engines, including:

[0011] Receive IO request information and bad disk information sent by the hardware engine. The IO request information is used to indicate the original IO request received by the hardware engine, and the bad disk information is used to indicate the bad disk related to the original IO request.

[0012] Based on the request information and bad disk information, the original IO request is split into a first sub-IO request and a second sub-IO request. The first sub-IO request is used to indicate IO operations related to bad disks, and the second sub-IO request is used to indicate IO operations unrelated to bad disks.

[0013] The request information of the second sub-IO request is sent to the hardware engine so that the hardware engine can perform IO operations unrelated to the bad disk based on the request information of the second sub-IO request.

[0014] Based on the request information of the first sub-IO request, perform IO operations related to the bad disk.

[0015] This application also provides a request processing apparatus, including:

[0016] The request management module is used to receive raw I / O requests issued by applications in the host and look up the list of disks related to the raw I / O requests.

[0017] The request sending module is used to send the request information and bad disk information of the original IO request to the software engine if there is a bad disk in the disk list. The software engine is used to split the original IO request into a first sub-IO request and a second sub-IO request based on the request information and bad disk information. The first sub-IO request is used to indicate IO operations related to the bad disk, and the second sub-IO request is used to indicate IO operations unrelated to the bad disk.

[0018] The request receiving module is used to receive the request information of the second sub-IO request returned by the software engine;

[0019] The second request execution module is used to perform IO operations unrelated to the bad disk based on the request information of the second sub-IO request, while the software engine performs IO operations related to the bad disk based on the request information of the first sub-IO request.

[0020] This application also provides another request processing apparatus, including:

[0021] The information receiving module is used to receive IO request information and bad disk information sent by the hardware engine. The IO request information is used to indicate the original IO request received by the hardware engine, and the bad disk information is used to indicate the bad disk related to the original IO request.

[0022] The request splitting module is used to split the original IO request into a first sub-IO request and a second sub-IO request based on the request information and bad disk information. The first sub-IO request is used to indicate IO operations related to bad disks, and the second sub-IO request is used to indicate IO operations unrelated to bad disks.

[0023] The request processing module is used to send the request information of the second sub-IO request to the hardware engine, so that the hardware engine can perform IO operations unrelated to the bad disk based on the request information of the second sub-IO request.

[0024] The first request execution module is used to perform I / O operations related to the bad disk based on the request information of the first sub-IO request.

[0025] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described request processing methods when executing the computer program.

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

[0027] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described request processing methods.

[0028] In some embodiments of this application, the hardware engine receives a raw I / O request from a host application and searches a disk list related to the raw I / O request. If a bad disk exists in the disk list, the hardware engine sends the raw I / O request to the software engine. Upon receiving the raw I / O request, the software engine splits it into a first sub-I / O request and a second sub-I / O request based on the bad disk information in the disk list, and returns the second sub-I / O request to the hardware engine. Then, the software engine executes the first sub-I / O request, and the hardware engine executes the second sub-I / O request. Finally, the software engine combines the execution results of the two sub-I / O requests and returns them to the host application that issued the raw I / O request. In this way, the raw I / O request involving bad disks is split into a first sub-I / O request involving only bad disks and a second sub-I / O request not involving bad disks, and processed by the software engine and hardware engine respectively. Through this collaborative approach, since hardware is more efficient at handling good I / O but less efficient at handling bad I / O, the splitting process effectively utilizes the advantages of both software and hardware processing, thereby improving the efficiency of bad I / O processing. Attached Figure Description

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

[0030] Figure 1 A flowchart illustrating the request processing method provided in this application embodiment;

[0031] Figure 2 A flowchart illustrating another request processing method provided in an embodiment of this application;

[0032] Figure 3 A flowchart illustrating a request processing method provided in another embodiment of this application;

[0033] Figure 4 A schematic diagram of a request processing apparatus provided for some embodiments of this application;

[0034] Figure 5 Schematic diagrams of a request processing apparatus provided for other embodiments of this application;

[0035] Figure 6 A schematic diagram of the modules of an electronic device provided for some embodiments of this application. Detailed Implementation

[0036] 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 of ordinary skill in the art without creative effort are within the protection scope of this application.

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

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

[0039] Currently, with the rapid development of computer technology and the surge in data processing demands, traditional storage architectures based on SATA hard disk drives (HDDs) are increasingly unable to meet these needs due to performance limitations. In contrast, SSDs (Solid State Drives) based on the NVMe (Non-Volatile Memory Express) protocol offer faster read / write speeds and enhanced security compared to SATA HDDs, thus making NVMe SSD technology increasingly mainstream.

[0040] RAID cards typically handle two types of I / O: simple I / O and bad disk I / O. Simple I / O generally doesn't involve bad disks or background tasks; this is usually handled by the hardware engine, which requires less complex hardware design, is lower in cost, and offers higher I / O efficiency. However, handling I / O involving bad disks in the same way would make the hardware design extremely complex and costly. Therefore, bad disk I / O is usually handled by a software engine. Since the software engine's processing speed is far slower than the hardware engine, this results in lower I / O efficiency, failing to meet customer requirements.

[0041] In view of this, this application provides a request processing method that can solve the above problems. This request processing method can be applied to hardware engines and software engines, or to electronic devices that process requests involving bad disk I / O. Electronic devices may include, but are not limited to, servers, storage arrays, etc.

[0042] See also Figure 1 , Figure 1 A flowchart illustrating the request processing method provided for embodiments of this application is shown below. Figure 1 As shown, the request processing method includes the following steps:

[0043] Step S101: Receive the original IO request issued by the application in the host, and search the disk list related to the original IO request.

[0044] Specifically, after receiving the original I / O request from the application on the host, the hardware engine searches for a list of disks related to the original I / O request. The hardware engine can actively scan the disk devices connected to it via their physical interfaces (such as SATA and NVMe), and can construct a corresponding disk list based on the disk device's status information.

[0045] In step S102, if a bad disk exists in the disk list, the request information and bad disk information of the original IO request are sent to the software engine. The software engine is used to split the original IO request into a first sub-IO request and a second sub-IO request based on the request information and bad disk information. The first sub-IO request is used to indicate IO operations related to the bad disk, and the second sub-IO request is used to indicate IO operations unrelated to the bad disk.

[0046] Specifically, after the hardware engine scans the disk list according to step S101, if it finds a bad disk among the hard drives involved in the original IO request, it sends the request information of the original IO request and the bad disk information to the software engine. Upon receiving the request information and bad disk information, the software engine confirms the location of the bad disk based on the bad disk information and splits the original IO request into a first sub-IO request and a second sub-IO request. The first sub-IO request indicates IO operations related to the bad disk, while the second sub-IO request indicates IO operations unrelated to the bad disk.

[0047] In this embodiment, the hardware engine can periodically monitor the health status of the hard disk device. When it detects that the current value of certain attributes exceeds a preset threshold, it marks the hard disk device as a bad disk. For example, when a hard disk device frequently experiences read / write timeouts or verification errors, the hardware engine will mark it as a bad disk.

[0048] In this embodiment, the bad disk information includes, but is not limited to, the bad disk's identification information, location information, and status information. When the hardware engine sends the request information of the original IO request, it also sends the bad disk information to the software engine so that the software engine can accurately identify the location of the bad disk and perform the subsequent original IO splitting operation.

[0049] Step S103: Receive the request information of the second sub-IO request returned by the software engine.

[0050] Specifically, after the software engine completes the splitting operation of the original IO request in step S102 above, it returns the request information of the first sub-IO request to the hardware engine.

[0051] Step S104: Based on the request information of the second sub-IO request, perform IO operations unrelated to the bad disk; the software engine performs IO operations related to the bad disk based on the request information of the first sub-IO request.

[0052] Specifically, when the hardware engine receives the request information for the second sub-IO request, it performs IO operations unrelated to the bad disk based on the request information of the second sub-IO request. At the same time, the software engine performs IO operations related to the bad disk based on the request information of the first sub-IO request.

[0053] The request processing method provided in this embodiment involves a hardware engine receiving a raw I / O request from a host application and searching a disk list related to the raw I / O request. If a bad disk is found in the disk list, the hardware engine sends the raw I / O request to the software engine. Upon receiving the raw I / O request, the software engine splits it into a first sub-I / O request and a second sub-I / O request based on the bad disk information in the disk list, and returns the second sub-I / O request to the hardware engine. Then, the software engine executes the first sub-I / O request, and the hardware engine executes the second sub-I / O request. Finally, the software engine merges the execution results of the two sub-I / O requests and returns them to the host application that issued the raw I / O request. In this way, raw I / O requests involving bad disks are split into a first sub-I / O request involving only bad disks and a second sub-I / O request not involving bad disks, and processed by the software engine and hardware engine respectively. This collaborative approach between the software and hardware engines significantly improves the processing efficiency of bad disk I / O requests.

[0054] In the request processing method provided in this embodiment, see reference to Figure 2 , Figure 2 A flowchart illustrating another request processing method provided in this application embodiment is shown below. Figure 2 As shown, the request processing method also includes the following steps:

[0055] Step S201: Receive the original IO request issued by the application in the host, and look up the disk list related to the original IO request.

[0056] In some embodiments, when searching the disk list related to the original IO request, step S201 above further includes:

[0057] Step S2011: Obtain the starting address and number of logical blocks of the original IO request.

[0058] Specifically, when the hardware engine receives a raw I / O request from the application on the host, it obtains the Start Logic Block Address (SLBA) and Number Logic Block (NLB) of the raw I / O request. When the host initiates the raw I / O request command, the SLBA and NLB are included in the parameters of that command, and the command structure varies depending on the storage interface protocol. For example, in the NVMe protocol, the SLBA and NLB are included in the command parameters. The host writes an NVMe command to the hardware engine's queue, triggering the hardware engine to read and parse the NVMe command. After parsing the command, the hardware engine can obtain the corresponding SLBA and NLB parameters. As another example, in the SATA protocol, these parameters are included in the FIS (Frame Information Structure). The host sends a specific FIS command to the hardware engine to trigger parameter parsing, thereby obtaining the corresponding SLBA and NLB. Typically, the FIS command contains the values ​​of multiple registers; after the hardware engine reads the values ​​from each register, it needs to combine them to obtain the SLBA.

[0059] Step S2012: Determine the end address of the logical block based on the starting address of the logical block and the number of logical blocks.

[0060] Specifically, after the hardware engine obtains the SLBA and NLB through parsing, the logical block termination address can be calculated according to the following expression (1):

[0061] ELBA = SLBA + NLB - 1 (1)

[0062] Wherein, ELBA represents the logical block termination address, SLBA represents the logical block start address, and NLB represents the number of logical blocks.

[0063] Step S2013: Obtain the disk list related to the original IO request based on the logical block start address and logical block end address.

[0064] Specifically, after the hardware engine calculates the End Logic Block Address (ELBA), it determines the list of disks related to the original IO request by combining the disk configuration information in the electronic device executing the method of this application.

[0065] In the above embodiments, the corresponding disk list is searched based on SLBA, NLB, ELBA and configuration information in the electronic device executing the method of this application, which avoids unnecessary resource consumption during the search process and helps to improve the overall performance of the hardware engine.

[0066] In step S202, if a bad disk exists in the disk list, the request information and bad disk information of the original IO request are sent to the software engine. The software engine is used to split the original IO request into a first sub-IO request and a second sub-IO request based on the request information and bad disk information. The first sub-IO request is used to indicate IO operations related to the bad disk, and the second sub-IO request is used to indicate IO operations unrelated to the bad disk.

[0067] In some embodiments, step S202 above further includes the following steps S2021 to S2022:

[0068] Step S2021: Determine if there are any bad disks in the disk list.

[0069] Specifically, the aforementioned hardware engine searches the disk list for bad disks based on SLBA, NLB, and hard disk configuration information.

[0070] In step S2022, if there are no bad disks in the disk list, the IO operation indicated by the original IO request is executed and the IO operation result is returned to the application.

[0071] Specifically, if the disk list is scanned and the original IO request does not involve a bad disk, the original IO request is processed by the hardware engine, and the processing result is directly returned by the hardware engine to the application in the host that sent the IO request.

[0072] Step S2023: If a bad disk exists in the disk list, the request information and bad disk information of the original IO request are sent to the software engine. The software engine uses this information to split the original IO request into a first sub-IO request and a second sub-IO request. The first sub-IO request indicates IO operations related to the bad disk, and the second sub-IO request indicates IO operations unrelated to the bad disk. See details below. Figure 1 Step S102 of the illustrated embodiment will not be described again here.

[0073] Step S203: Receive the request information for the second sub-IO request returned by the software engine. For details, please refer to [link to relevant documentation]. Figure 1 Step S103 of the illustrated embodiment will not be described again here.

[0074] Step S204: Based on the request information of the second sub-IO request, perform IO operations unrelated to the bad disk; the software engine performs IO operations related to the bad disk based on the request information of the first sub-IO request. For details, please refer to [link to details]. Figure 1 Step S104 of the illustrated embodiment will not be described again here.

[0075] In some embodiments, the request information and bad disk information of the original IO request are sent to the software engine, and the above step S204 further includes the following steps S2041 to S2042.

[0076] Step S2041: Request a first memory space from the host and record a first control page table in the first memory space. The first control page table is used to store the request information and bad disk information of the original IO request.

[0077] Specifically, if a bad disk is found in the disk list scanned by the hardware engine, the hardware engine requests a first memory space from the host and records a first control page table in that memory space. The first control page table stores the request information of the original I / O request and the bad disk information. For example, the hardware engine in the RAID card running on the host requests the first memory space from the host. This first memory space can be a physically contiguous memory region located in the host's main memory, and the allocation of the first memory space is achieved using the DMA (Direct Memory Access) allocation interface provided by the host operating system kernel.

[0078] In this embodiment, the first memory space is used to record a first control page table, which includes, but is not limited to, the request information of the original IO request, SLBA, NLB, and fields to record the bad disk information corresponding to the original IO request. For example, the disk number of the bad disk, the location information of the bad disk, and the status information of the bad disk.

[0079] In step S2042, the address of the first control page table is written to the first handover IO event, and the first handover IO event is written to the first event queue. The software engine is used to read the first handover IO event from the first event queue, and based on the address in the first handover IO event, to obtain the request information and bad disk information of the original IO request from the first control page table.

[0080] Specifically, once the first memory space allocation is completed and the information in the first control page table is recorded, the hardware engine encapsulates the starting address of the first control page table into a first handover I / O event and writes this first handover I / O event into a preset first event queue. Subsequently, the software engine can obtain the first handover I / O event by polling the first event queue. Based on the starting address of the first control page table encapsulated in the first handover I / O event, the software engine can directly access the memory space to obtain the original I / O request information and bad disk information, thereby performing subsequent I / O operations related to the bad disk.

[0081] In the above embodiment, the hardware engine requests a first memory space in the host's main memory. The hardware engine can directly access this first memory space via the PCIe bus. Since this first memory space is located in main memory, it also facilitates access to this memory space by the software engine. The original IO request and bad disk information are then recorded in the first control page table and submitted to the first event queue via a first handover IO event. This allows the software engine to promptly obtain and process the bad disk information, thereby improving overall IO processing efficiency.

[0082] In some embodiments, the data processing method further includes:

[0083] The software engine returns the first I / O operation result, which is not related to the bad disk. After obtaining the second I / O operation result related to the bad disk, the software engine merges the first I / O operation result and the second I / O operation result and returns the merged operation result to the application.

[0084] Specifically, when the software engine receives the original I / O request sent by the hard disk engine, it splits the original I / O request into a first sub-I / O request related to the bad disk and a second sub-I / O request unrelated to the bad disk. The second sub-I / O request is resent by the software engine to the hardware engine for processing, while the first sub-I / O request is processed by the software engine. Since the hardware engine processes I / O requests significantly faster than the software engine, the software engine continues processing the first sub-I / O request even after the hardware engine has processed the second sub-I / O request and obtained the result of the first I / O operation. At this point, the hardware engine sends the result of the first I / O operation to the software engine. Upon receiving this result, the software engine temporarily stores it and continues processing the first sub-I / O request. After the software engine completes processing the first sub-I / O request, it merges the result of the second I / O operation of the first sub-I / O request with the previously stored result of the first I / O operation and returns the final merged result to the application in the host that issued the original I / O request.

[0085] In the above embodiments, the second sub-IO request that does not involve a faulty disk is returned to the hardware engine for processing, while the first sub-IO request that involves a faulty disk is processed by the software engine. This approach, through the cooperation of the hardware and software engines, fully leverages the high processing efficiency of the hardware engine when handling IO operations that do not involve faulty disks, while also utilizing the flexibility and fault tolerance of the software engine when handling IO operations that do involve faulty disks, thereby improving the overall efficiency of processing IO requests.

[0086] See also Figure 3 , Figure 3 A flowchart illustrating a request processing method provided for another embodiment of this application is shown below. Figure 3 As shown, the request method further includes the following steps S301 to S304.

[0087] Step S301: Receive IO request information and bad disk information sent by the hardware engine. The IO request information is used to indicate the original IO request received by the hardware engine, and the bad disk information is used to indicate the bad disk related to the original IO request.

[0088] Specifically, when the hardware engine detects that the original IO request involves a bad disk, the software engine receives the IO request information and bad disk information sent by the hardware engine through the above steps S2041 to S2042.

[0089] Step S302: Based on the request information and bad disk information, the original IO request is split into a first sub-IO request and a second sub-IO request. The first sub-IO request is used to indicate IO operations related to the bad disk, and the second sub-IO request is used to indicate IO operations unrelated to the bad disk.

[0090] Specifically, the software engine identifies the portion of the original I / O request related to the bad disk based on the received bad disk information. The software engine can obtain the first handover I / O event sent by the hardware engine by polling the aforementioned first event queue. Furthermore, the software engine can respond to the first handover I / O event using an interrupt handling mechanism. Then, based on the bad disk information, the original I / O request is split into a first sub-I / O request and a second sub-I / O request. The first sub-I / O request indicates I / O operations related to the bad disk, while the second sub-I / O request indicates I / O operations unrelated to the bad disk.

[0091] Step S303: Send the request information of the second sub-IO request to the hardware engine so that the hardware engine can perform IO operations unrelated to the bad disk based on the request information of the second sub-IO request.

[0092] Specifically, after the software engine completes the splitting of the original IO request, it will resend the second sub-IO request, which does not involve a bad disk, to the hardware engine so that the hardware engine can perform the corresponding IO operation.

[0093] Step S304: Based on the request information of the first sub-IO request, perform IO operations related to the bad disk.

[0094] Specifically, the software engine executes the I / O operation related to the failed disk by splitting the first sub-I / O request from the original I / O request. For example, in RAID-0, the data is divided into blocks and distributed across all disks. When one disk fails, the entire RAID-0 data becomes inaccessible. Therefore, recovery is usually achieved using backup data. In RAID-1, the data is completely copied (i.e., mirrored) to two or more disks. So, when the original I / O request involves a failed disk, the I / O operation can be completed by reading data from the mirror disk. In RAID-5, data and parity information are distributed across all disks, implementing striped and distributed parity storage. Therefore, when the original I / O request involves a failed disk, the required data can be recalculated using the parity information to complete the I / O operation. In RAID-6, a second independent parity block is added to the RAID-5 structure. The two parity blocks are written to different disks. Therefore, when the original I / O request involves a failed disk, data recovery and calculation can be performed using the two independent parity blocks to complete the I / O operation. RAID-10 combines the technical features of RAID-1 and RAID-0 (i.e., mirroring before striping). Therefore, when the original IO request involves a bad disk, as long as the data in the mirror disk is not damaged, the corresponding IO operation can be completed by reading the data in the mirror disk.

[0095] The request processing method provided in this embodiment involves the software engine receiving IO request information and bad disk information from the hardware engine. The software engine then splits the original IO request into a first sub-IO request related to the bad disk and a second sub-IO request unrelated to the bad disk. The second sub-IO request is then returned to the hardware engine, which performs the relevant IO operations. Simultaneously, the software engine processes the first sub-IO request. This method enables the simultaneous processing of both bad disk IO requests and requests for IO requests without bad disks, significantly improving IO processing efficiency.

[0096] In some embodiments, when the request information of the first sub-IO request is sent to the hardware engine, the above step S303 includes the following steps S3031 to S3032:

[0097] Step S3031: Request a second memory space from the host and record a second control page table in the second memory space, wherein the second control page table is used to store the request information of the second sub-IO request.

[0098] Specifically, after the software engine completes the splitting of the original IO request, it allocates a new memory region in the host's main memory as a second memory space and records the second control page table within this second memory space. The second control page table stores request information related to the second sub-IO request, including but not limited to the data address, data length, and operation type corresponding to the second sub-IO request.

[0099] In step S3032, the address of the second control page table is written to the second handover IO event, and the second handover IO event is written to the second event queue. The hardware engine is used to read the second handover IO event from the second event queue and obtain the request information of the second sub-IO request from the second control page table based on the address in the second handover IO event.

[0100] Specifically, after the software engine completes the allocation of the second memory space and the recording of the second control page table, it encapsulates the address information of the second control page table into a second handover I / O event and writes the second handover I / O event into a preset second event queue. Subsequently, the hardware engine can read the second event queue using management commands, obtain the second handover I / O event, and retrieve the corresponding second sub-I / O request information from the second control page table based on the address information within it.

[0101] In the above embodiments, by requesting a second memory space in the host through the software engine and recording the second control page table therein, and then handing it over to the hardware engine, the efficient processing of the second sub-IO request can be effectively achieved.

[0102] In some embodiments, the original I / O request is issued by an application in the host; the request method further includes:

[0103] Receive the first I / O operation result returned by the hardware engine that is unrelated to the bad disk;

[0104] After obtaining the result of the second I / O operation related to the bad disk, the result of the first I / O operation and the result of the second I / O operation are merged, and the merged result is returned to the application.

[0105] Specifically, after the hardware engine completes processing the first sub-IO request unrelated to the bad disk, it returns the corresponding first IO operation result to the software engine. Simultaneously, the software engine continues processing the second sub-IO request related to the bad disk. Once the second sub-IO request is completed, the software engine obtains the corresponding second IO operation result. At this point, the software engine merges the results of the first and second sub-IO operations and returns the merged result to the application.

[0106] In the above embodiments, since the software and hardware engines process I / O operations at different rates, by adopting an asynchronous processing mechanism, the hardware engine can continue to process other tasks without waiting for the software engine to complete all I / O operations, thereby improving the overall efficiency of the system.

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

[0108] Corresponding to the request processing method, this application also provides a request processing apparatus. (See also...) Figure 4 This is a schematic diagram of a request processing apparatus provided in an embodiment of this application. Figure 4 In this context, the request processing device includes:

[0109] The request management module 401 is used to receive the original I / O request issued by the application in the host and look up the disk list related to the original I / O request;

[0110] The request sending module 402 is used to send the request information and bad disk information of the original IO request to the software engine if there is a bad disk in the disk list. The software engine is used to split the original IO request into a first sub-IO request and a second sub-IO request based on the request information and bad disk information. The first sub-IO request is used to indicate IO operations related to the bad disk, and the second sub-IO request is used to indicate IO operations unrelated to the bad disk.

[0111] The request receiving module 403 is used to receive the request information of the second sub-IO request returned by the software engine;

[0112] The second request execution module 404 is used to perform IO operations unrelated to the bad disk based on the request information of the second sub-IO request, while the software engine performs IO operations related to the bad disk based on the request information of the first sub-IO request.

[0113] In some embodiments, when searching for the disk list associated with the original IO request, the request sending module 401 is further configured to:

[0114] Get the starting address and number of logical blocks of the original IO request;

[0115] The end address of a logical block is determined based on the starting address of the logical block and the number of logical blocks.

[0116] Based on the start and end addresses of the logical block, obtain the list of disks related to the original I / O request.

[0117] In some embodiments, the request management module 401 is further configured to:

[0118] If no bad disks are found in the disk list, the I / O operation indicated in the original I / O request is executed, and the result of the I / O operation is returned to the application.

[0119] In some embodiments, when sending the request information and bad disk information of the original IO request to the software engine, the request sending module 402 is further configured to:

[0120] The system requests a first memory space from the host and records a first control page table in the first memory space. The first control page table is used to store the request information and bad disk information of the original IO request.

[0121] The address of the first control page table is written to the first handover I / O event, and the first handover I / O event is written to the first event queue. The software engine reads the first handover I / O event from the first event queue and, based on the address in the first handover I / O event, obtains the request information and bad disk information of the original I / O request from the first control page table.

[0122] In some embodiments, the second request execution module 404 is further configured to:

[0123] The software engine returns the first I / O operation result, which is not related to the bad disk. After obtaining the second I / O operation result related to the bad disk, the software engine merges the first I / O operation result and the second I / O operation result and returns the merged operation result to the application.

[0124] See also Figure 5 This is a schematic diagram of a request processing apparatus provided in some other embodiments of this application. Figure 5 In this context, the request processing device includes:

[0125] The information receiving module 501 is used to receive IO request information and bad disk information sent by the hardware engine. The IO request information is used to indicate the original IO request received by the hardware engine, and the bad disk information is used to indicate the bad disk related to the original IO request.

[0126] The request splitting module 502 is used to split the original IO request into a first sub-IO request and a second sub-IO request based on the request information and bad disk information. The first sub-IO request is used to indicate IO operations related to bad disks, and the second sub-IO request is used to indicate IO operations unrelated to bad disks.

[0127] The request processing module 503 is used to send the request information of the second sub-IO request to the hardware engine, so that the hardware engine can perform IO operations unrelated to the bad disk according to the request information of the second sub-IO request.

[0128] The first request execution module 504 is used to perform I / O operations related to the bad disk based on the request information of the first sub-IO request.

[0129] In other embodiments, when sending the request information of the first sub-IO request to the hardware engine, the request processing module 503 is further configured to:

[0130] The host requests a second memory space and records a second control page table in the second memory space. The second control page table is used to store the request information of the second sub-IO request.

[0131] The address of the second control page table is written to the second handover I / O event, and the second handover I / O event is written to the second event queue. The hardware engine reads the second handover I / O event from the second event queue and obtains the request information of the second sub-I / O request from the second control page table based on the address in the second handover I / O event.

[0132] In other embodiments, the original IO request is issued by an application in the host; the first request execution module 504 is further configured to:

[0133] Receive the first I / O operation result returned by the hardware engine that is unrelated to the bad disk;

[0134] After obtaining the result of the second I / O operation related to the bad disk, the results of the first I / O operation and the second I / O operation are merged, and the merged result is returned to the application.

[0135] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0136] See also Figure 6 Embodiments of this application also provide an electronic device including a memory 10 and a processor 20, wherein the memory 10 stores a computer program and the processor 20 is configured to run the computer program to perform the steps in any of the above-described request processing method embodiments.

[0137] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described request processing method embodiments at runtime.

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

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

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

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

[0142] The foregoing has provided a detailed description of a request processing method, apparatus, device, and storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A request processing method, characterized in that, Applied to a hardware engine; the method includes: Receive the original I / O request issued by the application in the host, and look up the disk list related to the original I / O request; If a bad disk exists in the disk list, the request information and bad disk information of the original IO request are sent to the software engine. The software engine is used to split the original IO request into a first sub-IO request and a second sub-IO request based on the request information and the bad disk information. The first sub-IO request is used to indicate IO operations related to the bad disk, and the second sub-IO request is used to indicate IO operations unrelated to the bad disk. Receive the request information of the second sub-IO request returned by the software engine; Based on the request information of the second sub-IO request, perform IO operations unrelated to the bad disk; based on the request information of the first sub-IO request, perform IO operations related to the bad disk.

2. The method according to claim 1, characterized in that, The process of finding the disk list related to the original IO request includes: Obtain the starting address and number of logical blocks of the original IO request; The end address of the logical block is determined based on the starting address of the logical block and the number of logical blocks; Based on the start address and end address of the logical block, obtain the disk list related to the original IO request.

3. The method according to claim 1 or 2, characterized in that, The method further includes: If there are no bad disks in the disk list, the IO operation indicated by the original IO request is executed, and the IO operation result is returned to the application.

4. The method according to claim 1, characterized in that, Sending the request information and bad disk information of the original IO request to the software engine includes: The host requests a first memory space and records a first control page table in the first memory space, wherein the first control page table is used to store the request information of the original IO request and the bad disk information; The software engine writes the address of the first control page table into the first handover IO event and writes the first handover IO event into the first event queue. The software engine reads the first handover IO event from the first event queue and obtains the request information of the original IO request and the bad disk information from the first control page table based on the address in the first handover IO event.

5. The method according to claim 1, characterized in that, The method further includes: The software engine returns a first I / O operation result that is not related to the bad disk. After obtaining a second I / O operation result that is related to the bad disk, the software engine merges the first I / O operation result and the second I / O operation result and returns the merged operation result to the application.

6. A request processing method, characterized in that, Applied to a software engine, the method includes: Receive IO request information and bad disk information sent by the hardware engine. The IO request information is used to indicate the original IO request received by the hardware engine, and the bad disk information is used to indicate a bad disk related to the original IO request. Based on the request information and the bad disk information, the original IO request is split into a first sub-IO request and a second sub-IO request. The first sub-IO request is used to indicate IO operations related to the bad disk, and the second sub-IO request is used to indicate IO operations unrelated to the bad disk. The request information of the second sub-IO request is sent to the hardware engine, so that the hardware engine performs IO operations unrelated to the bad disk based on the request information of the second sub-IO request; Based on the request information of the first sub-IO request, perform IO operations related to the bad disk.

7. The method according to claim 6, characterized in that, Sending the request information of the first sub-IO request to the hardware engine includes: The host requests a second memory space and records a second control page table in the second memory space, wherein the second control page table is used to store the request information of the second sub-IO request; The address of the second control page table is written to the second handover IO event, and the second handover IO event is written to the second event queue. The hardware engine is used to read the second handover IO event from the second event queue and obtain the request information of the second sub-IO request from the second control page table based on the address in the second handover IO event.

8. The method according to claim 6, characterized in that, The original I / O request was issued by an application in the host; the method further includes: Receive the first I / O operation result returned by the hardware engine that is unrelated to the bad disk; After obtaining the result of the second I / O operation related to the bad disk, the result of the first I / O operation and the result of the second I / O operation are merged, and the merged result is returned to the application.

9. An electronic device, characterized in that, include: Memory: Used to store computer programs; A processor, configured to implement the steps of the request processing method as described in any one of claims 1 to 5, or to perform the steps of the request processing method as described in any one of claims 6 to 8, when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of any one of the data processing methods as claimed in claims 1 to 5, or performs the steps of any one of the request processing methods as claimed in claims 6 to 8.

Images