A block storage-based IO access method and device, electronic equipment and medium

Abstract

This specification provides an I / O access method based on block storage, comprising: receiving an I / O request from a user program using block storage for a target logical block device mounted by a front-end driver, parsing the I / O request, and obtaining the address of a buffer; determining the target physical block device corresponding to the target logical block device based on the maintained association relationship between the logical block devices mounted by the front-end driver and the physical block devices mounted by the back-end driver, and mapping the address of the buffer to a DMA address through the I / O memory management unit corresponding to the target physical block device; transmitting the DMA address to the back-end driver, which then performs DMA access on the buffer based on the DMA address to execute the I / O processing operation corresponding to the I / O request. Through the address mapping mechanism, data copying between the front-end and back-end is eliminated, achieving high-performance transmission and reducing resource consumption; implemented in software, it is not limited by hardware constraints. It also has versatility.

Description

Technical Field

[0001] This specification relates to the field of storage technology, and in particular to an I / O access method, apparatus, electronic device and medium based on block storage. Background Technology

[0002] In recent years, with the rapid development of the internet, the total amount of data on the internet has shown an exponential growth trend. This has placed high demands on storage systems, requiring them not only to meet the storage needs of massive amounts of data, but also to meet the requirements of data read / write speeds and throughput, as well as high data reliability. Currently, traditional storage devices are struggling to meet these demands, and the management of traditional storage devices is becoming increasingly complex, requiring huge operational and maintenance costs.

[0003] The emergence of Software Defined Storage (SDS) technology has met the above needs. SDS refers to the separation of storage hardware and software. By decoupling the storage software that was originally fixed on proprietary hardware, it runs on standardized hardware (such as x86 servers) and integrates resources through virtualization technology, reorganizing the physical hardware into a unified logical resource pool, thereby building storage products and services through software.

[0004] In SDS (Software as a Service), there are two typical architectures: a decoupled architecture and a hyperconverged architecture. In this architecture, compute and storage resources reside on different servers or clusters. The compute side accesses storage resources entirely via a cross-network approach. The advantage of this architecture is that compute and storage resources are physically independent and easily scalable. A typical example of this architecture is the cloud storage in the public clouds of major cloud computing companies. The other architecture is hyperconverged, where compute and storage resources reside on the same physical server or cluster. Compute and storage resources are managed separately through software, achieving storage pooling and sharing. The advantages of this architecture are lower cost and better performance than the decoupled architecture. A typical example of this architecture is hyperconverged products in private / hybrid clouds.

[0005] In a hyperconverged architecture, when the compute side accesses storage resources, two scenarios may occur: one is that the storage resource to be accessed is on another server (i.e., cross-network access), and the other is that the storage resource to be accessed is on a local server. Optimizing the latter can greatly improve storage performance and is a key area of ​​focus. Summary of the Invention

[0006] In view of the above, one or more embodiments of this specification provide a block storage-based I / O access method, apparatus, electronic device, and medium to solve the problems existing in the related art.

[0007] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions:

[0008] According to a first aspect of the embodiments of this specification, a block storage-based I / O access method is provided, applied to a block storage service client; wherein, a block storage transport protocol runs on the block storage service client; the block storage transport protocol includes a front-end driver and a back-end driver; the method includes:

[0009] The front-end driver receives an I / O request from a user program using block storage for a target logical block device mounted on the front-end driver, and parses the I / O request to obtain the address of the buffer; wherein the I / O request includes the address of the buffer allocated to the user program;

[0010] The front-end driver determines the target physical block device corresponding to the target logical block device based on the maintained association relationship between the logical block device mounted by the front-end driver and the physical block device mounted by the back-end driver, and maps the address of the buffer to the DMA address corresponding to the buffer through the IO memory management unit corresponding to the target physical block device.

[0011] The front-end driver transmits the DMA address to the back-end driver, which then performs DMA access on the buffer based on the DMA address to execute the IO processing operation corresponding to the IO request.

[0012] According to a second aspect of the embodiments of this specification, a block storage-based I / O access system is provided, applied to a block storage service client; wherein, a block storage transport protocol runs on the block storage service client; the block storage transport protocol includes a front-end driver and a back-end driver; the system includes:

[0013] The user program is used to issue I / O requests to the target logical block device mounted by the front-end driver.

[0014] The front-end driver is configured to receive an I / O request from a user program using block storage for a target logical block device mounted on the front-end driver; and to parse the I / O request to obtain the address of a buffer; wherein the I / O request includes the address of a buffer allocated to the user program.

[0015] The front-end driver includes:

[0016] The address mapping submodule of the front-end driver is used to determine the target physical block device corresponding to the target logical block device based on the maintained association relationship between the logical block device mounted by the front-end driver and the physical block device mounted by the back-end driver, and to map the address of the buffer to the DMA address corresponding to the buffer through the IO memory management unit corresponding to the target physical block device;

[0017] The command transmission submodule of the front-end driver transmits the DMA address to the back-end driver;

[0018] The backend driver is used to perform DMA access on the buffer based on the DMA address in order to perform IO processing operations corresponding to the IO request.

[0019] According to a second aspect of the embodiments of this specification, a block storage-based I / O access device is provided, applied to a block storage service client; wherein a block storage transport protocol runs on the block storage service client; the block storage transport protocol includes a front-end driver and a back-end driver; the device includes:

[0020] The front-end driver module receives I / O requests from user programs using block storage for target logical block devices mounted by the front-end driver, and parses the I / O requests to obtain the address of the buffer; wherein the I / O request includes the address of the buffer allocated to the user program;

[0021] The address mapping submodule of the front-end driver determines the target physical block device corresponding to the target logical block device based on the maintained association relationship between the logical block device mounted by the front-end driver and the physical block device mounted by the back-end driver, and maps the address of the buffer to the DMA address corresponding to the buffer through the IO memory management unit corresponding to the target physical block device.

[0022] The command transmission submodule of the front-end driver transmits the DMA address to the back-end driver, which then performs DMA access on the buffer based on the DMA address to execute the IO processing operation corresponding to the IO request.

[0023] According to a fourth aspect of the embodiments of this specification, an electronic device is provided, including a communication interface, a processor, a memory, and a bus, wherein the communication interface, the processor, and the memory are interconnected via the bus;

[0024] The memory stores machine-readable instructions, and the processor executes the above method by invoking the machine-readable instructions.

[0025] According to a fifth aspect of the embodiments of this specification, a machine-readable storage medium is provided, the machine-readable storage medium storing machine-readable instructions, which, when invoked and executed by a processor, implement the above-described method.

[0026] The technical solutions provided in the embodiments of this specification may include the following beneficial effects:

[0027] Through the above technical solution, the front-end driver determines the target physical block device corresponding to the target logical block device for the I / O request by maintaining the association between logical block devices and physical block devices. Then, through the I / O memory management unit corresponding to the target physical block device, it maps the address of the buffer to the corresponding DMA address. This allows the back-end driver to perform DMA access on the buffer based on this DMA address to execute the I / O processing operation corresponding to the I / O request. In this process, on the one hand, by mapping the address of the buffer to the DMA address, the data transmission path between the front-end and back-end does not require data copying, achieving high-performance data transmission and reducing resource consumption. On the other hand, since this solution is implemented in software, it does not depend on specific hardware and is not limited by hardware bandwidth. Furthermore, this solution is applicable to various block storage transmission protocols and has universality. Attached Figure Description

[0028] Figure 1 A hyperconverged architecture provided for an exemplary embodiment of this specification;

[0029] Figure 2 This is a schematic diagram of data transmission based on NVME over TCP technology provided in an exemplary embodiment of this specification;

[0030] Figure 3 This is a schematic diagram of data transmission based on NVME over RDMA technology provided in an exemplary embodiment of this specification;

[0031] Figure 4 This diagram illustrates an exemplary embodiment of an I / O access method based on block storage.

[0032] Figure 5 A flowchart illustrating an exemplary embodiment of this specification for a block-based I / O access method;

[0033] Figure 6 This diagram illustrates the initialization process of a block-based I / O access system as provided in an exemplary embodiment of this specification.

[0034] Figure 7 This is a schematic diagram of an exemplary embodiment of an I / O access system based on block storage provided in this specification;

[0035] Figure 8 This is a schematic diagram of the structure of an electronic device containing a block storage-based I / O access device, provided as an exemplary embodiment of this specification.

[0036] Figure 9 This is a block diagram of a block storage-based I / O access device provided for an exemplary embodiment of this specification. Detailed Implementation

[0037] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0038] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0039] Hyper-Converged Infrastructure (HCI) refers to a single x86 unit device that not only possesses resources and technologies such as computing, networking, storage, and server virtualization, but also includes elements such as caching acceleration, storage tiering, deduplication, online data compression, and snapshot technology. Furthermore, multiple nodes can be aggregated through a network to achieve modular and seamless horizontal scaling, forming a unified resource pool.

[0040] Hyperconverged infrastructure (HCI) merges the compute resource layer, storage network layer, and storage resource layer into a single layer at the hardware level, enhancing the flexibility and reducing the complexity of data center infrastructure. Simultaneously, at the software level, it leverages software-defined technologies such as virtualization and distributed storage to achieve distributed resource scheduling.

[0041] The essence of hyperconverged infrastructure is to include computing and storage resources at the hardware layer and to pool resources in the software layer through software definition, providing decentralized and flexible infrastructure support for upper-layer applications.

[0042] by Figure 1 For example, Figure 1 This specification provides an exemplary embodiment of a hyperconverged architecture. For example... Figure 1 As shown, for computing resources (such as processors and memory) and storage resources (such as mechanical hard drives and solid-state drives) in x86 servers, in order to achieve cluster management and distributed access, software-defined storage technology can be used to pool and distribute the storage resources.

[0043] In related technologies, access to storage resources in a hyperconverged architecture is usually achieved through a unified network protocol. Even if storage resources and computing resources are on the same physical server, access to storage resources still requires a network protocol.

[0044] The following uses the Non-Volatile Memory Express (NVME) protocol as an example, combined with... Figure 2 and Figure 3 This paper describes the block storage access scheme under the hyperconverged architecture in related technologies.

[0045] Please see Figure 2 , Figure 2 This is a schematic diagram illustrating data transmission based on NVME over TCP technology, provided in an exemplary embodiment of this specification. TCP (Transmission Control Protocol) is a connection-oriented, reliable, byte-stream-based transport layer communication protocol. NVME over TCP is a TCP-based NVME remote access protocol defined by the NVME standardization organization. It enables the deployment and use of Non-Volatile Memory Express over Fabrics (NVME-oF) in a TCP network environment, thereby allowing NVME-oF to be used in ordinary network environments and increasing the application scope of NVME-oF.

[0046] like Figure 2 As shown, in the Linux system, the TCP protocol is implemented in the Linux kernel space. When a user program needs to transfer data, it can first copy the data in the user space to the TCP socket buffer in the kernel space, then copy the data in the TCP socket buffer to the corresponding buffer of the backend driver, and then transfer the data to the storage device through Direct Memory Access (DMA).

[0047] However, due to the inherent complexity of the TCP protocol, which requires switching between user-mode and kernel-mode contexts during data transmission, significant delays occur during the transmission of store commands. Furthermore, according to... Figure 2 As can be seen, data is copied twice during TCP transmission, and data copying consumes computing resources. Therefore, when the amount of data transmitted is large, it will significantly consume computing resources.

[0048] As can be seen, when storage resources and computing resources are located on the same physical server, the above-mentioned NVME over TCP solution still needs to be accessed through the TCP protocol, resulting in low access efficiency and significant performance loss and waste of computing resources.

[0049] Please see Figure 3 , Figure 3 This is a schematic diagram of data transmission based on NVME over RDMA technology provided in an exemplary embodiment of this specification. RDMA (Remote Direct Memory Access) is a high-performance data transmission method that relies on network interface card (NIC) hardware. NVME over RDMA is an NVME remote access protocol based on RDMA defined by the NVME standardization organization. It enables the aforementioned NVME-oF to achieve extremely low transmission latency and extremely high performance in a network environment that supports RDMA, making the performance of NVME over RDMA approach that of local NVME.

[0050] like Figure 3 As shown, the RDMA transmission protocol requires special hardware support, such as an RDMA network card. Through the PCIe (Peripheral Component Interconnect Express) interface of the RDMA network card, memory can be read and written directly. User-mode data can be read and copied to the RDMA network card via RDMA, and then written to the corresponding buffer in the back-end driver via RDMA. Finally, the data is transferred to the storage device via Direct Memory Access (DMA).

[0051] While RDMA can avoid the data copying between kernel and user space in TCP, its widespread use is limited by hardware constraints. Furthermore, RDMA transmission consumes hardware bandwidth resources, and its bandwidth cannot exceed the hardware's maximum capacity.

[0052] It is evident that when storage and computing resources reside on the same physical server, the NVME over RDMA solution described above, due to the consumption of hardware bandwidth resources, can actually hinder normal network transmission and easily reach hardware transmission bottlenecks.

[0053] In view of this, this specification provides a technical solution applicable to block storage transport protocols that maps the address of a buffer to a DMA address through an IO memory management unit to achieve storage access in a hyperconverged architecture.

[0054] In implementation, it can be applied to a block storage service client, which runs a block storage transport protocol, including a front-end driver and a back-end driver.

[0055] by Figure 4 For example, Figure 4 This diagram illustrates an exemplary embodiment of an I / O access method based on block storage. Figure 4 As shown, the block storage transport protocol running on the server defines a front-end driver and a back-end driver, and data transmission in the hyperconverged architecture is achieved through the interaction between the front-end driver and the back-end driver.

[0056] The front-end driver can receive I / O requests from user programs using block storage for target logical block devices mounted on the front-end driver, and parse the I / O requests to obtain the address of the buffer; wherein, the I / O request includes the address of the buffer allocated to the user program;

[0057] For example, in Figure 4 In this context, user programs using block storage can issue I / O requests to the target logical block device mounted by the front-end driver. Furthermore, in response to the received I / O request, the front-end driver can parse the I / O request and obtain the address of the buffer allocated to the user program, which is included in the I / O request.

[0058] The front-end driver can determine the target physical block device corresponding to the target logical block device based on the maintained association between the logical block device mounted by the front-end driver and the physical block device mounted by the back-end driver, and map the address of the buffer to the DMA address corresponding to the buffer through the IO memory management unit corresponding to the target physical block device.

[0059] For example, in Figure 4In this context, the front-end driver can maintain the association between the logical block devices mounted by the front-end driver and the physical block devices mounted by the back-end driver. The front-end driver can use this association to determine the target physical block device corresponding to the target logical block device. Furthermore, the front-end driver can use the I / O memory management unit corresponding to the target physical block device to map the address of the buffer to the DMA address corresponding to that buffer.

[0060] The front-end driver can transmit the DMA address to the back-end driver, which then performs DMA access on the buffer based on the DMA address to execute the IO processing operation corresponding to the IO request.

[0061] For example, in Figure 4 In this context, the front-end driver can transfer the DMA address to the back-end driver. Furthermore, the back-end driver can use this DMA address to perform DMA access on the buffer to execute the IO processing operations corresponding to the IO request.

[0062] Through the above technical solutions, the front-end driver determines the target physical block device corresponding to the target logical block device of the IO request by maintaining the association between logical block devices and physical block devices. Then, through the IO memory management unit corresponding to the target physical block device, the address of the buffer is mapped to the DMA address corresponding to the buffer, so that the back-end driver can perform DMA access on the buffer based on the DMA address to perform IO processing operations corresponding to the IO request.

[0063] according to Figure 4 It can be seen that, with Figure 2 Compared to the previous solution, this solution does not require multiple copies between user space and kernel space, nor does it require TCP access. Figure 3 Compared to the previous solution, this solution does not depend on specific hardware, nor is it limited by hardware bandwidth.

[0064] Therefore, in the above process, on the one hand, by using an address mapping mechanism to map the address of the buffer to a DMA address, the data transmission path between the front end and the back end does not require data copying, achieving high-performance data transmission and reducing resource consumption; on the other hand, since this solution is implemented in software, it does not depend on specific hardware and is not limited by hardware bandwidth. Furthermore, this solution is applicable to various block storage transmission protocols, possessing universality.

[0065] The block-based I / O access method described in this specification will be explained in detail below with reference to the accompanying drawings.

[0066] Please see Figure 5 , Figure 5This document provides a flowchart of an exemplary embodiment of an I / O access method based on block storage. The method is applied to a block storage service client; wherein, the block storage service client runs a block storage transport protocol; the block storage transport protocol includes a front-end driver and a back-end driver. Figure 5 As shown, the method includes the following execution steps:

[0067] Step 501: The front-end driver receives an I / O request from a user program using block storage for a target logical block device mounted on the front-end driver, and parses the I / O request to obtain the address of the buffer; wherein, the I / O request includes the address of the buffer allocated to the user program.

[0068] Step 502: The front-end driver determines the target physical block device corresponding to the target logical block device based on the maintained association relationship between the logical block device mounted by the front-end driver and the physical block device mounted by the back-end driver, and maps the address of the buffer to the DMA address corresponding to the buffer through the IO memory management unit corresponding to the target physical block device.

[0069] Step 503: The front-end driver transmits the DMA address to the back-end driver, which then performs DMA access on the buffer based on the DMA address to execute the IO processing operation corresponding to the IO request.

[0070] The aforementioned block storage refers to the block device provided by the block storage service provider, which may include logical block devices based on a distributed architecture storage system and physical block devices based on the local hard disk of a physical machine. The aforementioned physical block device can be a hard disk drive (HDD) or a solid-state drive (SSD). The aforementioned block storage service provider can be one or more servers, or a cluster of multiple servers. This application does not impose any limitations on this.

[0071] For example, the aforementioned block storage service client can be a cloud server, which presents itself as a cloud disk for users by mounting logical block devices on the front-end driver, while the data is stored on the local solid-state drive device corresponding to the cloud disk, that is, the physical block device mounted on the back-end driver.

[0072] When performing I / O access, the aforementioned block storage needs to be accessed based on a block storage transport protocol. For example, the block storage transport protocol can be Non-Volatile Memory Express over Fabrics (NVME-oF), or it can be an Internet Small Computer System Interface (iSCSI) protocol, or other industry-standard block storage remote transport protocols. This application does not limit the specific protocol used.

[0073] The aforementioned block storage transmission protocol can define the interactive commands, steps, and message formats during transmission. The main components involved include at least a front-end driver and a back-end driver. For ease of explanation, the front-end driver can be simply referred to as the front-end, and the back-end driver as the back-end; these will not be elaborated upon further in the following text.

[0074] In one embodiment shown, the block storage service client is a block storage service client employing a hyperconverged architecture.

[0075] For example, the aforementioned block storage service client can be a block storage service client that adopts a hyperconverged architecture. In this architecture, computing resources and storage resources are located on the same physical server or the same cluster. Computing resources and storage resources are managed separately through software to achieve storage pooling and sharing.

[0076] In one embodiment shown, in response to an initialization command, a control information interaction path between the front-end driver and the back-end driver can be created based on a preset transmission method.

[0077] The backend driver creates a logical object corresponding to the physical block device;

[0078] The front-end driver obtains the device information of the logical object of the back-end driver through the control information interaction path, and mounts the logical block device corresponding to the logical object based on the device information; and creates and maintains the association relationship between the logical block device and the physical block device of the back-end driver; wherein, the device information includes at least the correspondence between the logical object and the physical block device, and the PCIeID of the physical block device.

[0079] The above-mentioned transmission method can be through establishing a Socket connection, through a pipe, or through shared memory. Those skilled in the art can choose according to their needs, and this application does not limit this method.

[0080] Taking a Socket connection as an example, the backend driver can create a Socket socket, and the frontend driver can connect to the created Socket socket to establish a Socket connection, thus building a slow path interaction between the frontend and the backend, which is also a control path interaction, mainly responsible for the exchange of control information.

[0081] It's worth noting that the aforementioned slow paths refer to execution paths that occur infrequently and do not affect normal read / write I / O performance. These slow paths facilitate the initialization interaction process and the exchange of control information without impacting subsequent normal I / O read / write speeds.

[0082] Please see Figure 6 , Figure 6 This diagram illustrates the initialization process of a block-based I / O access system, provided as an exemplary embodiment of this specification. Figure 6 As shown, the storage transmission protocol can define a control module and a command transmission module, including a front-end control submodule 602 and a front-end command transmission submodule 603 in the front-end driver 601, and a back-end control submodule 605 and a back-end command transmission submodule 606 in the back-end driver 604. It can also define a back-end device simulation submodule 607 in the back-end driver. The initialization process includes the following steps:

[0083] S601, backend control submodule 605, responds to initialization instructions and creates Socket socket 608.

[0084] For example, the backend driver 604 can load in response to an initialization command, initialize the transmission protocol of the present invention, create a Socket 608 based on the backend control submodule 605, and listen to the port corresponding to the Socket 608 to receive control information from the frontend driver.

[0085] S602, the front-end control submodule 602, connects to the Socket socket 608 and creates a control information interaction path.

[0086] For example, the front-end driver 601 can load in response to the initialization command, initialize the transmission protocol of the present invention, establish a Socket connection with the back-end driver 604 based on the port corresponding to the Socket 608 connected to the front-end control submodule 602, create a control information interaction path, and write control information into the Socket 608 through the path.

[0087] The aforementioned control information may include, but is not limited to, interactive commands such as obtaining device information or protocol version information.

[0088] S603, Backend Device Simulation Submodule 607, Create Logical Object.

[0089] For example, in response to the above initialization command, the backend device simulation submodule 607 can be used to simulate the physical block device mounted on the backend, create a logical object, and establish a binding relationship between the logical object and its corresponding physical block device on the backend.

[0090] It should be noted that this logical object corresponds to the logical block device that the front-end driver 601 needs to mount. In related technologies, although the front-end can mount logical block devices corresponding to the back-end physical block devices, the front-end does not maintain the device information of the physical block devices, and therefore does not maintain the association between logical block devices and physical block devices. However, in this application, through the aforementioned back-end device simulation submodule 607, the front-end can be provided with complete information about the logical block devices, as well as the device information of the physical block devices associated with the logical block devices.

[0091] S604, the front-end control submodule 602, obtains device information via a Socket connection.

[0092] For example, the front-end control submodule 602 can obtain the association between the logical object maintained by the back-end device simulation submodule 607 and its corresponding physical block device by writing an interactive command to the Socket socket 608 to obtain device information, thereby obtaining the device information of the physical block device corresponding to the logical object, such as PCIe ID, register space information, memory mapping information and queue number.

[0093] The aforementioned device information may include at least the correspondence between logical objects and physical block devices, as well as the PCIe ID of the physical block devices. Additionally, the device information may also include descriptions of the external component interconnect bus (PCIe BUS), descriptions of devices connected to the external component interconnect bus (PCIe Device), and descriptions of internal functional devices within devices still connected to the external component interconnect bus (PCIe Function).

[0094] S605, Front-end control submodule 602, mounts the logical block device corresponding to the logical object based on the above device information.

[0095] For example, the front-end control submodule 602 can mount the logical block device corresponding to the logical object one by one based on the obtained device information of the logical object.

[0096] S606, Front-end control submodule 602, creates and maintains the association between the logical block device and the physical block device of the back-end driver.

[0097] For example, the front-end control submodule 602 can create and maintain the association between logical block devices and physical block devices based on the obtained correspondence between logical objects and physical block devices.

[0098] In one embodiment shown, the front-end driver can create shared memory, establish a mapping between the back-end driver and the shared memory, and create a queue transfer channel in the shared memory.

[0099] Continue with Figure 6 For example, the above initialization process also includes the following steps:

[0100] S607, the front-end command transmission submodule 603, creates shared memory 609 and establishes a mapping between the back-end driver 604 and shared memory 609.

[0101] For example, the front-end command transmission submodule 603 can allocate and create shared memory 609, and inform the back-end driver 604 through the aforementioned Socket connection, thereby establishing a mapping between the back-end driver 604 and shared memory 609, so that the front-end and back-end can share the same shared memory 609 for subsequent command transmission.

[0102] S608, the front-end command transmission submodule 603, creates a queue transmission channel in shared memory 609.

[0103] For example, the front-end command transmission submodule 603 can create a command transmission queue on shared memory 609 according to queue attribute requirements, such as the queue's starting address and queue length.

[0104] Through the above steps, the initialization interaction between the front-end driver and the back-end driver can be completed. Since block storage generates read / write commands during I / O access, these commands contain information such as the address, offset, and size of the data being read or written, as well as the memory address information for the user program to receive or send data. Typically, read / write commands are only a few tens of bytes long. These commands need to be transmitted from the front-end to the back-end. However, under the traditional TCP protocol, these commands need to be encapsulated into TCP packets before being sent to the back-end. This application uses shared memory to implement the transmission of read / write commands, eliminating the need for complex protocol encapsulation and command copying, and also eliminating the need to switch between kernel mode and user mode, thus improving command transmission efficiency and reducing latency.

[0105] After the above initialization steps are completed, the IO access process will be described next.

[0106] In this embodiment, the front-end driver can receive I / O requests from a user program using block storage for a target logical block device mounted on the front-end driver, and parse the I / O requests to obtain the address of the buffer; wherein, the I / O request includes the address of the buffer allocated to the user program.

[0107] The aforementioned user program refers to a user program that uses block storage. It generally runs in the user space of the system and issues read / write I / O access requests through standard system calls. When issuing I / O requests, it requests the allocation of a buffer address to read and write data from the backend physical block device.

[0108] For example, a user program using block storage can issue an I / O request to the target logical block device mounted by the front-end driver. After receiving the I / O request, the front-end driver can parse the I / O request and obtain the address of the buffer allocated for the user program included in the I / O request.

[0109] Please see Figure 7 , Figure 7 This diagram illustrates an exemplary embodiment of an I / O access system based on block storage. Figure 7 As shown, the system includes a user program 701, a front-end driver 702, a back-end driver 703, a physical block device 704, an I / O memory management unit 705, and shared memory 706. Figure 7 In this context, the IO access process includes the following steps:

[0110] S701, the user program 701 issues an I / O request to the target logical block device mounted by the front-end driver 702.

[0111] S702, the front-end driver 702 parses the received I / O request and obtains the address of the buffer.

[0112] The aforementioned IO request may include the size of the buffer, the address of the buffer offset, and the logical block device object that the user needs to access.

[0113] In this embodiment, the front-end driver can determine the target physical block device corresponding to the target logical block device based on the maintained association relationship between the logical block device mounted by the front-end driver and the physical block device mounted by the back-end driver, and map the address of the buffer to the DMA address corresponding to the buffer through the IO memory management unit corresponding to the target physical block device.

[0114] Continue with Figure 7For example, the block storage transfer protocol in this application can define a front-end address mapping submodule 707 and a front-end command transfer submodule 708 in the front-end driver 702, and a back-end command transfer submodule 709 in the back-end driver 703. The description of the shared memory 706 established by the front-end command transfer submodule 708 and the back-end command transfer submodule 709 can be found in the foregoing. Figure 6 The relevant descriptions in the text will not be repeated here.

[0115] S703, Front-end address mapping submodule 707, based on the maintained association relationship between the logical block device mounted by the front-end driver and the physical block device mounted by the back-end driver, determines the target physical block device corresponding to the target logical block device.

[0116] For example, the front-end address mapping submodule 707 can query the target physical block device corresponding to the target logical block device targeted by the IO request based on the association between the logical block device mounted by the front-end driver and the physical block device mounted by the back-end driver, which is created and maintained during the initialization process.

[0117] In one embodiment shown, it can be determined whether the target physical block device corresponding to the target logical block device is a local physical block device of the block storage service client; if so, the address of the buffer is mapped to the DMA address corresponding to the buffer through the IO memory management unit corresponding to the target physical block device.

[0118] For example, the front-end address mapping submodule 707 can determine whether the target physical block device corresponding to the target logical block device is a local physical block device on the block storage service client; if so, it means that the storage resource to be accessed is stored on the local server, as mentioned above. Figure 2 and Figure 3 As described above, in the traditional approach, when storage and computing resources are on the same physical server, access to storage resources still requires network protocols. However, in this application, cross-network access is not required. By continuing to execute subsequent steps, the DMA address corresponding to the buffer is determined and sent to the backend driver, so that the data transmission path between the frontend and backend does not require data copying, thus achieving high-performance data transmission.

[0119] S704, the front-end address mapping submodule 707 maps the address of the buffer to the DMA address corresponding to the buffer through the IO memory management unit 705 corresponding to the target physical block device.

[0120] The aforementioned I / O Memory Management Unit (IOMMU) is used to control DMA access of I / O devices to the machine's physical memory area while ensuring security.

[0121] In one embodiment shown, step S704 above may include the following process:

[0122] The address of the buffer is parsed to determine the physical address corresponding to the address of the buffer;

[0123] The memory management page table corresponding to the target physical block device is determined by the IO memory management unit corresponding to the target physical block device;

[0124] The mapping interface of the IO memory management unit is invoked to register the physical address corresponding to the buffer in the memory management page table, and a mapping relationship between the physical address corresponding to the buffer and the DMA address is established, mapping the address of the buffer to the DMA address corresponding to the buffer.

[0125] For example, the front-end address mapping submodule 707 can parse the address of the buffer in the IO request and convert the virtual address of the buffer into the corresponding physical address. Then, based on the target physical block device corresponding to the target logical block device of the IO request, it can determine the memory management page table corresponding to the target physical block device through the IO memory management unit 705 corresponding to the target physical block device. After that, it can call the mapping interface of the IO memory management unit to register the physical address corresponding to the buffer in the memory management page table, and map the address of the buffer to the DMA address corresponding to the buffer. This DMA address is the address where the DMA operation needs to be performed.

[0126] The aforementioned IO memory management unit can perform address translation during DMA read / write operations between external devices and host memory, translating the physical address of the buffer into a DMA address. Alternatively, it can query the memory management page table based on the DMA address to translate the DMA address back into the physical address of the buffer, thus achieving address translation.

[0127] It's important to note that kernel mode and user mode are two runtime levels of the operating system. When executing in user mode, a process's access to memory space and objects is limited, and its allocated processor can be preempted. Conversely, when executing in kernel mode, a process can access all memory space and objects, and its allocated processor cannot be preempted. Therefore, the aforementioned front-end address mapping submodule 707 is deployed at the front end, not the back end, to avoid the problem of frequent access to kernel mode during address mapping in user mode, which would lead to a severe performance degradation.

[0128] In this embodiment, the front-end driver can transmit the DMA address to the back-end driver, which then performs DMA access on the buffer based on the DMA address to execute the IO processing operation corresponding to the IO request.

[0129] For example, after the front-end address mapping submodule 707 maps the address of the buffer to the DMA address corresponding to the buffer, the front-end command transfer submodule 708 can transfer the DMA address to the back-end driver 703. Then, the back-end driver 703 can perform DMA access on the buffer based on the DMA address to execute the IO processing operation corresponding to the IO request.

[0130] In one embodiment shown, the front-end driver can generate an IO command corresponding to the IO request, encapsulate the IO command and the DMA address into a first storage command for the target logical block device; and write the first storage command into a command transfer queue pre-created in shared memory and update the doorbell register of the command transfer queue.

[0131] S705, the front-end command transmission submodule 708 generates an IO command corresponding to the IO request, and encapsulates the IO command and the DMA address into a first storage command for the target logical block device.

[0132] For example, the front-end command transmission submodule 708 can generate IO commands corresponding to different storage protocols based on IO requests, such as standard NVME commands; and encapsulate the generated IO commands and DMA addresses to obtain the first storage command for the target logical block device corresponding to the IO request.

[0133] S706, the front-end command transmission submodule 708 writes the first stored command into a command transmission queue pre-created in shared memory and updates the doorbell register of the command transmission queue.

[0134] For example, the front-end command transmission submodule 708 can write the encapsulated first stored command into the command transmission queue in the shared memory created during the initialization phase, transmit it through the queue transmission channel created during initialization, and update the doorbell register of the command transmission queue so that the back-end driver can be aware that there are commands to be processed in the command transmission queue.

[0135] In one embodiment shown, the backend driver responds to an update of the doorbell register by parsing a first stored command in the command transfer queue in the shared memory to determine the IO command and the DMA address;

[0136] Based on the target physical block device corresponding to the target logical block device, the IO command and the DMA address are encapsulated into a second storage command for the target physical block device;

[0137] The second storage command is sent to the target physical block device, so that the target physical block device can perform IO processing operations on the data in the buffer according to the DMA address, corresponding to the IO request.

[0138] S707, the backend command transmission submodule 709, in response to the update of the doorbell register, parses the first stored command in the command transmission queue in the shared memory, determines the IO command and the DMA address; and, according to the target physical block device corresponding to the target logical block device, encapsulates the IO command and the DMA address into a second stored command for the target physical block device.

[0139] For example, the backend command transmission submodule 709 can respond to the detection of an update to the doorbell register, sense a new command issued by the frontend driver, parse the first storage command in the command transmission queue of shared memory, and determine the IO command and DMA address encapsulated in the first storage command. However, since the first storage command is for the target logical block device, in order for the target physical block device to execute the second storage command, it is necessary to encapsulate the IO command and DMA address into a second storage command for the target physical block device, based on the target physical block device corresponding to the target logical block device.

[0140] It is worth noting that, unlike the control submodules which are responsible for establishing slow paths, the command transmission submodules mentioned above play the role of fast paths. Through the shared memory mechanism, the front end and back end do not need to perform multiple copies during the interaction process, as TCP and other protocol commands do. They can directly see the same data through shared memory, thus achieving zero copying of read and write IO commands.

[0141] S708, the backend command transmission submodule 709 sends the second storage command to the target physical block device, so that the target physical block device can perform IO processing operations on the data in the buffer according to the DMA address, corresponding to the IO request.

[0142] For example, the backend command transmission submodule 709 can send the second storage command to the target physical block device, so that the target physical block device can perform IO processing operations on the data in the buffer according to the DMA address, corresponding to the IO request.

[0143] In one embodiment shown, the target physical block device sends a DMA message to the I / O memory management unit;

[0144] The IO memory management unit determines whether the DMA address exists in the memory management page table based on the DMA address in the DMA message;

[0145] If it exists, determine the physical address corresponding to the buffer according to the memory management page table, and perform IO processing operations corresponding to the IO request on the data at the physical address corresponding to the buffer using DMA.

[0146] S709, the target physical block device can send a DMA message to the IO memory management unit 705.

[0147] For example, the target physical hard drive can initiate DMA data transfer after receiving the NVME command by sending a DMA message to the IO memory management unit.

[0148] S710, the IO memory management unit 705 determines whether the DMA address exists in the memory management page table based on the DMA address in the DMA message; if it exists, it determines the physical address corresponding to the buffer based on the memory management page table, and performs IO processing operation corresponding to the IO request on the data at the physical address corresponding to the buffer through DMA.

[0149] For example, the aforementioned DMA message can be received by the I / O memory management unit. The I / O memory management unit can determine whether the DMA address exists in the memory management page table based on the DMA address in the DMA message. If it exists, it translates the DMA address into the physical address corresponding to the buffer according to the memory management page table, and performs the I / O processing operation corresponding to the I / O request on the data at the physical address corresponding to the buffer using DMA. If it does not exist, the I / O memory management unit can discard the DMA message and refuse I / O access based on the interrupt function of the I / O memory management unit.

[0150] S711, the target physical block device notifies the backend driver 703 that the second storage command has been executed.

[0151] In one embodiment shown, the backend driver, in response to the target physical block device completing the IO processing operation, notifies the frontend driver via the shared memory that the IO request processing is complete.

[0152] S712, the backend command transmission submodule 709 can respond to the target physical block device completing the IO processing operation and notify the frontend command transmission submodule 708 that the IO request processing is complete through shared memory 706.

[0153] Through the above technical solution, the front-end driver determines the target physical block device corresponding to the target logical block device for the I / O request by maintaining the association between logical block devices and physical block devices. Then, through the I / O memory management unit corresponding to the target physical block device, it maps the address of the buffer to the corresponding DMA address. This allows the back-end driver to perform DMA access on the buffer based on this DMA address to execute the I / O processing operation corresponding to the I / O request. In this process, on the one hand, by mapping the address of the buffer to the DMA address, the data transmission path between the front-end and back-end does not require data copying, achieving high-performance data transmission and reducing resource consumption. On the other hand, since this solution is implemented in software, it does not depend on specific hardware and is not limited by hardware bandwidth. Furthermore, this solution is applicable to various block storage transmission protocols and has universality.

[0154] In an exemplary embodiment of this specification, an apparatus capable of implementing the above-described method is also provided.

[0155] Figure 8 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 8 At the hardware level, the device includes a processor 802, an internal bus 804, a network interface 806, memory 808, and non-volatile memory 810, and may also include other necessary hardware. One or more embodiments of this specification can be implemented in software, such as the processor 802 reading the corresponding computer program from the non-volatile memory 810 into memory 808 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0156] Please refer to Figure 9 In one software implementation, a block storage-based I / O access device 900 is provided, applied to a block storage service client; wherein, a block storage transport protocol runs on the block storage service client; the block storage transport protocol includes a front-end driver and a back-end driver; such as Figure 9 As shown, the device 900 includes:

[0157] The front-end driver module 901 receives an I / O request from a user program using block storage for a target logical block device mounted by the front-end driver, and parses the I / O request to obtain the address of the buffer; wherein the I / O request includes the address of the buffer allocated to the user program.

[0158] The address mapping submodule 902 of the front-end driver determines the target physical block device corresponding to the target logical block device based on the maintained association relationship between the logical block device mounted by the front-end driver and the physical block device mounted by the back-end driver, and maps the address of the buffer to the DMA address corresponding to the buffer through the IO memory management unit corresponding to the target physical block device.

[0159] The command transmission submodule 903 of the front-end driver transmits the DMA address to the back-end driver, which then performs DMA access on the buffer based on the DMA address to execute the IO processing operation corresponding to the IO request.

[0160] Optionally, the device 900 further includes:

[0161] The judgment module 904 (not shown in the figure) determines whether the target physical block device corresponding to the target logical block device is a local physical block device of the block storage service client; if so, the address of the buffer is mapped to the DMA address corresponding to the buffer through the IO memory management unit corresponding to the target physical block device.

[0162] Optionally, the device 900 further includes:

[0163] Initialization module 905 (not shown in the figure) responds to the initialization command and creates a control information interaction path between the front-end driver and the back-end driver based on a preset transmission method;

[0164] The device emulation submodule 906 of the backend driver (not shown in the figure) creates a logical object corresponding to the physical block device.

[0165] The control submodule 907 of the backend driver (not shown in the figure) allows the frontend driver to obtain device information of the logical object of the backend driver through the control information interaction path, and mount the logical block device corresponding to the logical object based on the device information; and to create and maintain the association relationship between the logical block device and the physical block device of the backend driver; wherein, the device information includes at least the correspondence between the logical object and the physical block device, and the PCIe ID of the physical block device.

[0166] Optionally, the device 900 further includes:

[0167] Shared memory module 908 (not shown in the figure): The front-end driver creates shared memory, establishes a mapping between the back-end driver and the shared memory, and creates a queue transmission channel in the shared memory.

[0168] Optionally, the address mapping submodule 902 further includes:

[0169] The address of the buffer is parsed to determine the physical address corresponding to the address of the buffer;

[0170] The memory management page table corresponding to the target physical block device is determined by the IO memory management unit corresponding to the target physical block device;

[0171] The mapping interface of the IO memory management unit is invoked to register the physical address corresponding to the buffer in the memory management page table, and a mapping relationship between the physical address corresponding to the buffer and the DMA address is established, mapping the address of the buffer to the DMA address corresponding to the buffer.

[0172] Optionally, the command transmission submodule 903 further includes:

[0173] The front-end driver generates an IO command corresponding to the IO request, and encapsulates the IO command and the DMA address into a first storage command for the target logical block device;

[0174] The first storage command is written to a command transmission queue that has been created in shared memory, and the doorbell register of the command transmission queue is updated.

[0175] Optionally, the backend driver performs DMA access on the buffer based on the DMA address to perform IO processing operations corresponding to the IO request, including:

[0176] In response to the update of the doorbell register, the backend driver parses the first stored command in the command transmission queue in the shared memory to determine the IO command and the DMA address;

[0177] Based on the target physical block device corresponding to the target logical block device, the IO command and the DMA address are encapsulated into a second storage command for the target physical block device;

[0178] The second storage command is sent to the target physical block device, so that the target physical block device can perform IO processing operations on the data in the buffer according to the DMA address, corresponding to the IO request.

[0179] Optionally, the target physical block device performs an I / O processing operation corresponding to the I / O request on the data in the buffer based on the DMA address, including:

[0180] The target physical block device sends a DMA message to the I / O memory management unit;

[0181] The IO memory management unit determines whether the DMA address exists in the memory management page table based on the DMA address in the DMA message;

[0182] If it exists, determine the physical address corresponding to the buffer according to the memory management page table, and perform IO processing operations corresponding to the IO request on the data at the physical address corresponding to the buffer using DMA.

[0183] Optionally, the device 900 further includes:

[0184] Notification module 909 (not shown in the figure): In response to the target physical block device completing the IO processing operation, the backend driver notifies the frontend driver through the shared memory that the IO request processing is complete.

[0185] Optionally, the block storage service client is a block storage service client that adopts a hyper-converged architecture.

[0186] The implementation process of the functions and roles of each module in the above-mentioned device 900 is detailed in the implementation process of the corresponding steps in the above-mentioned block storage-based IO access method. For relevant details, please refer to the description of the method implementation method. It will not be repeated here.

[0187] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the units or modules can be selected to achieve the purpose of the solution described in this specification, depending on actual needs. Those skilled in the art can understand and implement this without any inventive effort.

[0188] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0189] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0190] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0191] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0192] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0193] It should also be noted that 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. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0194] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0195] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” used in one or more embodiments of this specification and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0196] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to a determination," or "when," or "in the event of a determination."

[0197] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A method for IO access based on block storage, applied to a block storage server; wherein, The block storage service client runs the block storage transport protocol; The block storage transport protocol includes a front-end driver and a back-end driver; the method includes: The front-end driver receives an I / O request from a user program using block storage for a target logical block device mounted on the front-end driver, and parses the I / O request to obtain the address of the buffer; wherein the I / O request includes the address of the buffer allocated to the user program; The front-end driver determines the target physical block device corresponding to the target logical block device based on the maintained association relationship between the logical block device mounted by the front-end driver and the physical block device mounted by the back-end driver, and maps the address of the buffer to the DMA address corresponding to the buffer through the IO memory management unit corresponding to the target physical block device. The front-end driver transmits the DMA address to the back-end driver, which then performs DMA access on the buffer based on the DMA address to execute the IO processing operation corresponding to the IO request.

2. The method according to claim 1, further comprising, before mapping the address of the buffer to the DMA address corresponding to the buffer: Determine whether the target physical block device corresponding to the target logical block device is a local physical block device of the block storage service client; If so, the address of the buffer is mapped to the DMA address corresponding to the buffer through the IO memory management unit corresponding to the target physical block device.

3. The method according to claim 1, further comprising: In response to the initialization command, a control information interaction path between the front-end driver and the back-end driver is created based on a preset transmission method; The backend driver creates a logical object corresponding to the physical block device; The front-end driver obtains the device information of the logical object of the back-end driver through the control information interaction path, and mounts the logical block device corresponding to the logical object based on the device information; and creates and maintains the association relationship between the logical block device and the physical block device of the back-end driver; wherein, the device information includes at least the correspondence between the logical object and the physical block device, and the PCIe ID of the physical block device.

4. The method according to claim 3, further comprising: The front-end driver creates shared memory, establishes a mapping between the back-end driver and the shared memory, and creates a queue transfer channel in the shared memory.

5. The method according to claim 1, wherein mapping the address of the buffer to a DMA address corresponding to the buffer via an I / O memory management unit corresponding to the target physical block device comprises: The address of the buffer is parsed to determine the physical address corresponding to the address of the buffer; The memory management page table corresponding to the target physical block device is determined by the IO memory management unit corresponding to the target physical block device; The mapping interface of the IO memory management unit is invoked to register the physical address corresponding to the buffer in the memory management page table, and a mapping relationship between the physical address corresponding to the buffer and the DMA address is established, mapping the address of the buffer to the DMA address corresponding to the buffer.

6. The method according to claim 5, wherein the front-end driver transmits the DMA address to the back-end driver, comprising: The front-end driver generates an IO command corresponding to the IO request, and encapsulates the IO command and the DMA address into a first storage command for the target logical block device; The first storage command is written to a command transmission queue that has been created in shared memory, and the doorbell register of the command transmission queue is updated.

7. The method according to claim 6, wherein the backend driver performs DMA access on the buffer based on the DMA address to perform IO processing operations corresponding to the IO request, including: In response to the update of the doorbell register, the backend driver parses the first stored command in the command transmission queue in the shared memory to determine the IO command and the DMA address; Based on the target physical block device corresponding to the target logical block device, the IO command and the DMA address are encapsulated into a second storage command for the target physical block device; The second storage command is sent to the target physical block device, so that the target physical block device can perform IO processing operations on the data in the buffer according to the DMA address, corresponding to the IO request.

8. The method according to claim 7, wherein the target physical block device performs an I / O processing operation corresponding to the I / O request on the data in the buffer according to the DMA address, comprising: The target physical block device sends a DMA message to the I / O memory management unit; The IO memory management unit determines whether the DMA address exists in the memory management page table based on the DMA address in the DMA message; If it exists, determine the physical address corresponding to the buffer according to the memory management page table, and perform IO processing operations corresponding to the IO request on the data at the physical address corresponding to the buffer using DMA.

9. The method according to claim 8, further comprising: The backend driver, in response to the target physical block device completing the IO processing operation, notifies the frontend driver via the shared memory that the IO request processing is complete.

10. The method according to claim 1, wherein the block storage service client is a block storage service client adopting a hyperconverged architecture. 11.A block storage based IO access system, applied to a block storage server; wherein, The block storage service client runs a block storage transport protocol; the block storage transport protocol includes a front-end driver and a back-end driver; the system includes: The user program is used to issue I / O requests to the target logical block device mounted by the front-end driver. The front-end driver is configured to receive an I / O request from a user program using block storage for a target logical block device mounted on the front-end driver; and to parse the I / O request to obtain the address of a buffer; wherein the I / O request includes the address of a buffer allocated to the user program. The front-end driver includes: The address mapping submodule of the front-end driver is used to determine the target physical block device corresponding to the target logical block device based on the maintained association relationship between the logical block device mounted by the front-end driver and the physical block device mounted by the back-end driver, and to map the address of the buffer to the DMA address corresponding to the buffer through the IO memory management unit corresponding to the target physical block device; The command transmission submodule of the front-end driver transmits the DMA address to the back-end driver; The backend driver is used to perform DMA access on the buffer based on the DMA address in order to perform IO processing operations corresponding to the IO request.

12. A block storage based IO access apparatus, applied to a block storage server; wherein, The block storage service client runs the block storage transport protocol; The block storage transport protocol includes a front-end driver and a back-end driver; the device includes: The front-end driver module receives I / O requests from user programs using block storage for target logical block devices mounted by the front-end driver, and parses the I / O requests to obtain the address of the buffer; wherein the I / O request includes the address of the buffer allocated to the user program; The address mapping submodule of the front-end driver determines the target physical block device corresponding to the target logical block device based on the maintained association relationship between the logical block device mounted by the front-end driver and the physical block device mounted by the back-end driver, and maps the address of the buffer to the DMA address corresponding to the buffer through the IO memory management unit corresponding to the target physical block device. The command transmission submodule of the front-end driver transmits the DMA address to the back-end driver, which then performs DMA access on the buffer based on the DMA address to execute the IO processing operation corresponding to the IO request.

13. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-10 by executing the executable instructions.

14. A machine-readable storage medium having stored thereon machine-readable instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-10.

Images