Data access method and device

Abstract

The embodiments of this specification provide a data access method and apparatus. The method includes: receiving a data access request sent by a virtual user mode, where the virtual user mode accesses the stored data of the host according to the data access request; determining the access type of the data access request, and when the access type is a bidirectional read-write type, extracting the read address information and write address information in the data access request; encapsulating the read address information and write address information according to a preset driver protocol to obtain a driver read-write request; writing the driver read-write request into a preset description array to obtain a target description array, where the host performs a data access operation corresponding to the data access request on the stored data according to the target description array. Allowing a single read-write request to contain both a read operation and a write operation simultaneously reduces the performance overhead caused by read-write requests in a virtualized environment and can also improve the read-write access efficiency.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of computer technologies, and particularly to a data access method and apparatus. Background Art

[0002] Virtualization technologies have been widely applied in data centers and cloud computing environments to improve the flexibility and utilization rate of resources. In a virtualized environment, virtual machines usually need to perform I / O operations frequently, including reading and writing data to block storage devices. Due to the overly long I / O access path, traditional virtualization methods usually introduce relatively large I / O access latency, reducing the performance of virtual machines and no longer meeting the current I / O performance requirements for cloud computing and big data processing. Therefore, how to reduce the performance overhead brought by I / O read and write requests in a virtualized environment and improve I / O access efficiency is an urgent problem to be solved currently. Summary of the Invention

[0003] In view of this, the embodiments of this specification provide a data access method. One or more embodiments of this specification also relate to a data access apparatus, a computing device, a computer-readable storage medium, and a computer program product to solve the technical defects existing in the prior art.

[0004] According to a first aspect of the embodiments of this specification, a data access method is provided, which is applied to a virtual kernel mode and includes:

[0005] Receiving a data access request sent by a virtual user mode, where the virtual user mode accesses the storage data of a host according to the data access request;

[0006] Determining the access type of the data access request, and extracting read address information and write address information in the data access request when the access type is a bidirectional read-write type;

[0007] Encapsulating the read address information and the write address information according to a preset driver protocol to obtain a driver read-write request;

[0008] Writing the driver read-write request into a preset description array to obtain a target description array, where the host performs a data access operation corresponding to the data access request on the storage data according to the target description array.

[0009] According to a second aspect of the embodiments of this specification, a data access apparatus is provided, which is applied to a virtual kernel mode and includes:

[0010] A receiving module, configured to receive a data access request sent by a virtual user mode, where the virtual user mode accesses the storage data of a host according to the data access request;

[0011] An extraction module, configured to determine an access type of the data access request, and extract read address information and write address information in the data access request when the access type is a two-way read-write type;

[0012] An encapsulation module, configured to encapsulate the read address information and the write address information according to a preset driver protocol to obtain a driver read-write request;

[0013] A generation module, configured to write the driver read-write request into a preset description array to obtain a target description array, wherein the host performs a data access operation corresponding to the data access request on the stored data according to the target description array.

[0014] According to a third aspect of the embodiments of the present specification, a computing device is provided, including:

[0015] A memory and a processor;

[0016] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, and when the computer-executable instructions are executed by the processor, the steps of the above data access method are implemented.

[0017] According to a fourth aspect of the embodiments of the present specification, a computer-readable storage medium is provided, which stores computer-executable instructions, and when the instructions are executed by a processor, the steps of the above data access method are implemented.

[0018] According to a fifth aspect of the embodiments of the present specification, a computer program product is provided, including a computer program or instructions, and when the computer program or instructions are executed by a processor, the steps of the above data access method are implemented.

[0019] An embodiment of the present specification realizes determining the access type of a data access request sent in the virtual user state. When the access type is a two-way read-write type, the read address information and the write address information are extracted, and the read address information and the write address information are encapsulated according to a preset driver protocol to obtain a driver read-write request, so that the device driver layer in the virtual kernel state can support encapsulating and parsing two-way read-write requests. Subsequently, by writing the driver read-write request into a preset description array to obtain a target description array, the host can perform corresponding data access operations on the stored data according to the target description array. Through the parsing of the two-way read-write request by the device driver layer in the virtual kernel state, it is allowed that a single read-write request can simultaneously include a read operation and a write operation, reducing the performance overhead brought by read-write requests in a virtualized environment and also improving the read-write access efficiency. Description of the Drawings

[0020] Figure 1Shows a flowchart of a data access method provided according to an embodiment of this specification;

[0021] Figure 2A Shows a schematic diagram of a user-mode specified read / write buffer provided by this specification;

[0022] Figure 2B Shows a schematic diagram of the format of a virtblk_req structure provided by this specification;

[0023] Figure 2C Shows a schematic diagram of the conversion relationship of a descriptor table provided by this specification;

[0024] Figure 3A Shows a schematic diagram of the request structure of a data access request in an embodiment of this specification;

[0025] Figure 3B Shows a schematic diagram of a preset description array corresponding to a unidirectional read / write request in an embodiment of this specification;

[0026] Figure 3C Shows a schematic diagram of a preset description array corresponding to a bidirectional read / write request in an embodiment of this specification;

[0027] Figure 4 Shows a flowchart of the processing process of a data access method provided according to an embodiment of this specification;

[0028] Figure 5 Shows a schematic diagram of the structure of a data access device provided according to an embodiment of this specification;

[0029] Figure 6 Shows a block diagram of the structure of a computing device 600 provided according to an embodiment of this specification. Detailed implementation manners

[0030] In the following description, many specific details are set forth in order to provide a thorough understanding of this specification. However, this specification can be implemented in many other ways different from those described herein, and those skilled in the art can make similar generalizations without departing from the connotation of this specification. Therefore, this specification is not limited by the specific implementations disclosed below.

[0031] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a", "the", and "said" used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly dictates otherwise. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and encompasses any and all possible combinations of one or more of the associated listed items.

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

[0033] In addition, 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 for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data that have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of the relevant data need to comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entrances are provided for the user to choose to authorize or refuse.

[0034] First, the noun terms involved in one or more embodiments of this specification are explained.

[0035] VirtIO-blk: VirtIO-blk is a type of block device defined in the VirtIO specification, an efficient driver for handling block device I / O. It provides an efficient way for a virtual machine (VM) to interact with the storage resources of the host. VirtIO-blk belongs to the device driver layer and acts as a disk in a virtualized environment and can be used to simulate a hard disk, SSD (Solid State Disk), or other forms of persistent storage.

[0036] blk-mq: Block Multi-Queue is a multi-queue I / O scheduling framework for block devices in the Linux kernel. It aims to improve the efficiency of high-performance storage devices and large-scale parallel I / O operations, especially for modern storage devices that support multi-queues such as NVMe (Non-Volatile Memory Express, a high-performance, low-latency storage protocol) and VirtIO. Compared with the traditional single-queue model, blk-mq allows multiple hardware queues to process I / O requests in parallel, thus significantly improving the system's throughput and response speed.

[0037] Currently, VirtIO-blk is based on the general VirtIO framework and is a device driver for virtualization environments. Through this driver, the I / O requests inside the virtual machine are packaged and sent to the backend handler on the host through the VirtIO protocol, and then forwarded to the actual I / O system for processing. However, the current VirtIO-blk driver cannot meet the actual usage needs. There is no system call in the current VFS (Virtual File System) layer that contains both out and in semantics, that is, a single I / O command contains both write and read operations. It is expected to implement this function in the VirtIO-blk device driver to reduce the performance overhead caused by I / O reading and writing and improve the efficiency of I / O request processing.

[0038] In this specification, a data access method is provided. This specification also relates to a data access device, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail one by one in the following embodiments.

[0039] See Figure 1 , Figure 1 which shows a flowchart of a data access method provided according to an embodiment of this specification, specifically including the following steps.

[0040] Step 102: Receive a data access request sent by the virtual user state, where the virtual user state accesses the storage data of the host according to the data access request.

[0041] Among them, the virtual user mode can be understood as the state in which application programs run in the operating system of the virtual machine. In this state, the program cannot directly access the hardware or execute privileged instructions. Opposite to the virtual user mode is the virtual kernel mode, which refers to the state in which the operating system kernel of the virtual machine runs. In this state, the code can access all hardware resources without restriction and can execute task instructions, including privileged instructions, in order to ensure the efficient and reliable operation of key operating system functions and services. A data access request can be understood as a request from an application program in the virtual user mode to access a storage device. The data access request includes read and / or write operation requests. Therefore, the virtual user mode can access the stored data of the host according to the data access request. Specifically, it accesses the stored data on the storage device of the host, such as the data on a disk.

[0042] In practical applications, the application program in the virtual machine initiates an I / O request through system calls such as writev or readv, providing a struct iovec array containing virtual address information. See Figure 2A , Figure 2A shows a schematic diagram of specifying a read / write buffer in the user mode provided in this specification. Among them, the struct iovec array is the buffer specified by the user, which is used to store the "read result" / "write content" buffer. iov_base points to the starting address of the buffer, and iov_len indicates the number of buffers. The iovec array is composed of multiple discrete spaces and can be passed to the file system layer and the VirtIO-blk layer later. After being parsed and converted into physical address information, it is saved as multiple physical_seg physical segments. At the driver level in the virtual kernel mode, each I / O request usually needs to pass all the information related to the operation type and address to the backend driver, including page + offset + len, sector, type. Among them, page refers to the physical memory page in the virtual machine, which is the actual memory page after the virtual address to physical address conversion; offset refers to the offset in this physical page, indicating the starting position of the data in this page; len represents the length of the data to be read or written; sector refers to the logical sector number on the backend block device, which can determine the exact position of the data on the disk; type represents the operation type, such as reading, writing, etc.

[0043] Specifically, when a user application program initiates an I / O request (such as using readv or writev), the kernel driver will go through the following steps to process this request:

[0044] 1. Receive the I / O request: The kernel receives the readv or writev system call with the iovec array.

[0045] 2. Analyze user-space buffer information: Based on iov_base and iov_len in the iovec array, the kernel converts the virtual address in user space to a physical address in kernel space and calculates page, offset, and len.

[0046] 3. Map logical offset to physical sector: The file system layer is responsible for converting the logical offset of the file to the corresponding physical sector number sector.

[0047] 4. Build an I / O request structure: Create an I / O request structure that contains all the necessary information (page + offset + len, sector, type).

[0048] 5. Pass to the device driver layer: Pass the built I / O request to the device driver layer (such as the VirtIO-blk driver), which is responsible for communicating with the backend storage device.

[0049] 6. Execute the I / O operation: The device driver layer converts the general I / O request into a format that conforms to the VirtIO protocol and writes it to the shared ring buffer. The hypervisor fetches the descriptor from the shared ring buffer, and the corresponding read / write operation is executed by the backend handler or the actual storage device.

[0050] 7. Return the result: After the operation is completed, the result is fed back to the file system layer, which then notifies the VFS layer, and finally returns to the user application.

[0051] As can be seen from the above, the processing of an I / O request in the virtual kernel layer includes converting the virtual address to a physical address, creating an I / O request structure in the file system layer, converting it to a general I / O request structure, encapsulating it into a virtblk_req structure, and generating a vring_descriptor descriptor. Among them, encapsulating it into a virtblk_req structure is processed by the VirtIO-blk driver layer. The request format of the virtblk_req structure includes out_hdr that describes the request header, information that describes the I / O read / write area, and status that represents the return value. See Figure 2B , Figure 2BThe format schematic diagram of a virtblk_req structure provided in this specification is shown. Among them, the struct virtio_blk_outhdr request header is used to describe the basic information of the I / O request, such as the operation type, data length, etc. The struct virtio_blk_outhdr request header includes the operation type type, priority ioprio, and logical sector number sector. The information describing the I / O read / write area is used to describe the position and size of the data buffer to be read or written, and is represented by multiple physical seg physical pages. status is used to represent the result status of the requested operation.

[0052] Since the VirtIO-blk driver layer complies with the virtio framework. Virtio has a general descriptor convention. Each virtio device has one or more virtqueues (circular queues) to save descriptor information and realize the information exchange between the front end (such as the VirtIO-blk driver) and the back end (the actual handler on the host). See Figure 2C , Figure 2C The schematic diagram of the descriptor table conversion relationship provided in this specification is shown. Among them, Descriptor Table is the descriptor table, and the table structure includes the index idx of the descriptor, the memory address addr pointed to by the descriptor, the data length len represented by the descriptor, the flag bit flags of the descriptor, which is used to indicate the operation type and other information, and next represents the index of the next descriptor. In Figure 2C the descriptor table in, the flags fields of descriptors such as idx0 and idx1 contain the R|NXT flags, indicating that this is a read operation and there are subsequent descriptors; idxn+1: the flags field of this descriptor contains the W flag, indicating that this is a write operation; idxn+2: this is the last descriptor, usually used to represent status or completion information. Each descriptor points to a specific memory area through the addr field, and this area can contain the following types of structures, the struct virtio_blk_outhdr request header; le32 type: the request type (such as read, write, etc.); le32 ioprio: the priority; le64 sector: the sector number; Physical Segments: these are the actual data segments, and each segment contains a part of the data to be transmitted; u8 status: the status information, usually used to represent the completion status of the request.

[0053] In summary, after a read request or a write request is initiated in the user space, the kernel space needs to perform the above operations before forwarding the request to the host, where the host performs the corresponding read and write operations. However, the current VirtIO-blk device driver layer does not support bidirectional read and write requests. Therefore, it is necessary to transform the VirtIO-blk device driver layer by wrapping an I / O request process with bidirectional semantics.

[0054] In a specific embodiment of this specification, a data access request sent by the virtual user space is received. The data access request is used for an application in the virtual user space to access the stored data of the storage device of the host.

[0055] In practical applications, when a user opens a file and initiates a data access request based on the writev / readv system call, these system calls only support the generation of unidirectional requests. When the user wants to initiate a bidirectional read and write request, it can be initiated in the following ways. Specifically, receiving the data access request sent by the virtual user space includes: receiving the data access request sent by the virtual user space according to the target call field, where the target call field is the call field corresponding to the request of the bidirectional read and write type; or, receiving the data access request sent by the virtual user space through the target read / write interface, where the target read / write interface is the read / write interface corresponding to the request of the bidirectional read and write type.

[0056] Among them, the target call field can be understood as the call field corresponding to the request of the bidirectional read-write type, that is, a special call field set for the bidirectional read-write request, which is different from the existing unidirectional read-write request. By implementing a new system call, different from the system calls of write / read / writev / readv, the target call field is the type information. When parsing the data access request subsequently, if the target call field is recognized, it can be determined that the access type of the data access request is the bidirectional access type. The target read-write interface can be understood as the read-write interface corresponding to the request of the bidirectional read-write type. The target read-write interface is an ioctl (input / output control) interface added to the VirtIO-blk device driver layer. The ioctl interface is a commonly used system call in device driver programs for performing device-specific operations that cannot be completed through standard system calls such as write or read. Therefore, by adding the target read-write interface, a bidirectional call command is implemented. In both of the above two methods, multiple parameters need to be passed in, including type: the request type, and a bidirectional command type needs to be customized; addr: the address of the backend device (the backend device refers to the physical or emulated device responsible for processing I / O requests issued by the virtual machine in the virtual machine environment); iov_base: the starting address of the vector describing the user-space buffer; iov_len: the length of the vector describing the user-space buffer; write_iov_count: the number of write vectors (the remaining are read vectors).

[0057] In practical applications, the direct-pass mode of io_uring can also be used to wrap a complete VirtIO-blk layer command in the user space, directly encapsulate it into the io_uring request, and directly pass it to the VirtIO-blk driver layer for parsing.

[0058] Based on this, the generation and sending of bidirectional read-write requests are realized through the target call field and the target read-write interface, so that a single access request can include operations with both read and write attributes, reducing the I / O performance overhead and improving the access efficiency.

[0059] Step 104: Determine the access type of the data access request. When the access type is the bidirectional read-write type, extract the read address information and write address information in the data access request.

[0060] Among them, the access type of the data access request can be understood as the type of the data access request. By parsing the request header of the data access request, the access type of the data access request is determined according to the type field in the request header. When it is determined that the data access request is of the bidirectional read-write type, it means that the buffer in the data access request includes a write buffer and a read buffer. See Figure 3A ,Figure 3A The figure shows a schematic diagram of the request structure of a data access request in an embodiment of this specification. Among them, the data access request includes a type request type, an addr address of the backend device, an iov_base starting address, and an iov_len buffer length. And since the data access request is a bidirectional read / write request, an additional field write_iov_count is required to indicate the write buffer and the read buffer, as Figure 3A shown in [figure reference]. According to write_iov_count, it can be known that the number of write buffers is 2, and the remaining ones are read buffers, and the number of read buffers is 1.

[0061] In practical applications, the struct iovec array includes the starting addresses and lengths of each buffer. The write buffer and the read buffer are distinguished based on the write_iov_count field. However, the address fields in both the write buffer and the read buffer are virtual address fields. In order to be able to extract the read address information and write address information in the data access request, it is also necessary to perform a conversion of the physical address for the virtual address field. The read address information is the converted read physical address, and the write address information is the converted write physical address. Specifically, when implementing, if it is determined that the data access request is a unidirectional read / write type according to the access type, it means that the data access request is a data write request or a data read request. At this time, the data access request can be processed according to the steps of the above kernel driver for processing requests, which will not be elaborated here.

[0062] Furthermore, in order to be able to correctly distinguish the access type of the data access request, it is necessary to first determine the request header field of the data access request. Specifically, determining the access type of the data access request includes: parsing the data access request to obtain the request header field of the data access request; and determining the access type of the data access request according to the request header field.

[0063] Among them, after parsing the data access request, the request header field of the data access request can be obtained, and the access type of the data access request can be analyzed according to the request header field.

[0064] In practical applications, the access type of the data access request can be determined according to the type field in the request header field of the data access request. Since the bidirectional read / write request defines a bidirectional command type, after determining that the type field is the bidirectional command type, it can be determined that the data access request is a bidirectional command request.

[0065] In a specific embodiment of this specification, the data access request is parsed to obtain the request header field of the data access request, and the type field is determined from the request header field. If the type field is "w&r", the access type of the data access request can be determined as the two-way read-write type based on the type field. Correspondingly, in other cases, the data access request can also be determined as the read request type or the write request type based on the type field, such as "writev or readv".

[0066] Based on this, by parsing the data access request to obtain the request header field of the data access request, the access type of the data access request can be accurately determined through the request header field, which is convenient for subsequent parsing and processing of the data access request according to the corresponding parsing method of the access type.

[0067] Furthermore, in order to extract the physical address of the data access request, it is necessary to first determine the virtual address in the data access request. Specifically, the read address information and write address information in the data access request are extracted, including: determining the buffer address corresponding to the data access request according to the data field in the data access request; splitting the buffer address according to the write vector field in the data access request to obtain the read virtual address and the write virtual address; and determining the read address information and write address information of the data access request according to the read virtual address and the write virtual address.

[0068] Among them, the data field in the data access request can be understood as the field describing the user-mode buffer. The data field includes iov_base and iov_len. The starting address of the vector of the user-mode buffer can be determined through the iov_base field, and the length of the vector of the user-mode buffer can be determined through the iov_len field. The write vector field in the data access request can be understood as the field describing the number of write vectors. The write vector field is write_iov_count. Since the buffer address in the data access request is filled in the format of writing first and then reading, after determining the number of write vectors according to the write vector field, the remaining number of read vectors can be determined.

[0069] In a specific embodiment of this specification, the starting address of the buffer is determined according to the iov_base field, and the length of the buffer is determined according to the iov_len field. Thus, the buffer address can be determined based on the iov_base and iov_len fields. Then, the number of write vectors is determined using the write vector field. After that, the buffer can be split into the read virtual address and the write virtual address, and the read address information and write address information are determined according to the read virtual address and the write virtual address subsequently.

[0070] Based on this, by adding a write vector field to the data access request, the buffer address is split based on the write vector field, enabling the accurate acquisition of the read virtual address and the write virtual address in the bidirectional read-write request, which facilitates the subsequent determination of the read address information and the write address information of the data access request according to the read virtual address and the write virtual address.

[0071] During specific implementation, determining the read address information and the write address information according to the read virtual address and the write virtual address involves the creation of a general I / O request. In the traditional file and block storage access modes, a general I / O request is created at the blk-mq (Block Multi-Queue) layer, and the buffer address is converted into physical address information and saved in the general I / O request. In addition, adjacent buffers are also attempted to be merged to improve efficiency. Determining the read address information and the write address information of the data access request according to the read virtual address and the write virtual address includes: performing a linked list conversion on the read virtual address and the write virtual address to obtain a physical address linked list; determining the read address information and the write address information of the data access request based on the physical address linked list.

[0072] Among them, since the buffer address information in the user space may not be continuous, it needs to be stored in the form of a linked list. During the conversion process, if the end address of the previous buffer is the same as the start address of the next buffer, it indicates that the two buffers can be described by a larger buffer, which is called the "merge" behavior here. To avoid the merge between the read and write ranges, the read virtual address and the write virtual address need to be respectively subjected to linked list conversion to obtain a physical address linked list.

[0073] In practical applications, since the buffer address information includes the read virtual address and the write virtual address, to avoid merging buffers with opposite read-write attributes, during the linked list conversion process, the process of converting the virtual address of the user-space buffer into physical address information and saving it can be divided into two stages, and the conversion of the write buffer and the conversion of the read buffer are respectively executed.

[0074] Before performing the conversion, add a temporary direction to the general I / O request to identify the read-write attribute of the current buffer. When it is found that the read-write attribute of the current buffer is opposite to the direction of the buffer information finally saved in the general I / O request, even if the buffers are adjacent, the merge is prohibited.

[0075] During specific implementation, the blk-mq layer creates a general I / O request structure (struct request), converts the page + offset + len provided by the file system layer into physical address information, i.e., physical segments (bio_vec), saves the physical address information to the general I / O request, manages the scattered buffers in the form of a linked list, and attempts to merge adjacent buffers. After the operation is completed, a complete general I / O request structure is created and passed to the specific device driver.

[0076] Based on this, by performing linked list conversion on the read virtual address and the write virtual address, adjacent buffers are merged to improve the read and write efficiency.

[0077] Furthermore, performing linked list conversion on the read virtual address and the write virtual address to obtain a physical address linked list includes: determining the read flag information corresponding to each sub-read virtual address in the read virtual address, and the write flag information corresponding to each sub-write virtual address in the write virtual address; performing linked list conversion on the read virtual address according to the read flag information corresponding to each sub-read virtual address to obtain a read physical address linked list, and performing linked list conversion on the write virtual address according to the write flag information corresponding to each sub-write virtual address to obtain a write physical address linked list; generating a physical address linked list based on the read physical address linked list and the write physical address linked list.

[0078] Among them, since the buffer address information includes two buffer addresses with different attributes, when performing linked list conversion, the read flag information corresponding to each sub-read virtual address in the read virtual address and the write flag information corresponding to each sub-write virtual address in the write virtual address can be determined. A sub-read virtual address can be understood as a certain virtual address in the read virtual address, and the read flag information can be understood as the read and write attributes of each sub-read virtual address. The read and write attributes of each sub-read virtual address can be determined according to the read flag information. Correspondingly, the read and write attributes of each sub-write virtual address can be determined according to the write flag information. Subsequently, when performing linked list conversion, two-stage linked list conversion can be performed on the read virtual address and the write virtual address respectively, or linked list conversion can be performed according to the read and write attribute directions. By these methods, the situation where the read and write attributes are different but adjacent buffers are merged is avoided.

[0079] In practical applications, after performing linked list conversion on the read tag information for the read virtual address, a read physical address linked list can be obtained. The read physical address linked list can be understood as a management linked list corresponding to the read physical addresses generated after the conversion of the read virtual address. Correspondingly, the write physical address linked list can be understood as a management linked list corresponding to the write physical addresses generated after the conversion of the write virtual address. Based on the read physical address linked list and the write physical address linked list, a physical address linked list corresponding to the general I / O request can be generated, and there will be no situation where physical addresses with different read and write attributes but adjacent addresses are merged.

[0080] Step 106: Encapsulate the read address information and the write address information according to a preset driver protocol to obtain a driver read-write request.

[0081] Among them, the preset driver protocol can be understood as the VirtIO-blk protocol. After receiving the general I / O request, the VirtIO-blk driver program in the device driver layer encapsulates it into a request format that conforms to the VirtIO protocol to obtain a driver read-write request. The driver read-write request can be understood as the virtblk_req request structure after being encapsulated by the VirtIO protocol. Subsequently, the driver read-write request can be further transformed into a descriptor and finally filled into the virtqueue.

[0082] In practical applications, the driver read-write request is used to represent the I / O request inside the VirtIO-blk driver layer. In order to adapt to the VirtIO protocol, the VirtIO-blk driver layer will first create a virtblk_req structure and initialize it to conform to the VirtIO protocol format. This structure contains all the information required to perform I / O operations, including the request header, data buffer, and status fields.

[0083] During the encapsulation process, the request header includes type: the operation type, such as read, write, or obtain the device status; sector: the starting sector number, indicating the specific location where the data should be read or written; ioprio: the priority of the I / O request. In the data buffer, the pointers and lengths of the data buffer are set according to the read address information and the write address information in the general I / O request. Usually, it is set in a traversal manner. During the setting process, since there are two types of information with different read and write attribute directions, it is necessary to first determine the attribute information of each data segment. Specifically, encapsulating the read address information and the write address information according to the preset driver protocol to obtain a driver read-write request includes: creating a request structure according to the preset driver protocol; determining the read attribute information of the read data segment according to the read address information, and determining the write attribute information of the write data segment according to the write address information; encapsulating the read data segment and the write data segment into the request structure respectively according to the read attribute information and the write attribute information to obtain a driver read-write request.

[0084] Among them, creating a request structure according to a preset drive protocol can be understood as creating a virtblk_req structure, and determining the read attribute information of the read data segment according to the read address information can be understood as determining the pointer and length of the read data segment; correspondingly, determining the write attribute information of the write data segment can be understood as determining the pointer and length of the write data segment. After determining the read attribute information of the read data segment and the write attribute information of the write data segment, the read data segment and the write data segment can be encapsulated into the request structure, so as to obtain a drive read / write request.

[0085] In practical applications, it also includes initializing the status field in the request structure. After obtaining the drive read / write request, the drive read / write request contains all the information required by the VirtIO protocol, such as the operation type (read / write), the starting sector number, the data buffer location, etc. Subsequently, one or more scatterlist entries can be created according to the drive read / write request to describe the data segment. This is because the VirtIO device may need to access data segments scattered in different memory areas.

[0086] Based on this, by encapsulating the read data segment and the write data segment into the request structure respectively according to the read attribute information and the write attribute information, a drive read / write request is obtained, so as to realize the support for bidirectional commands in the VirtIO-blk drive layer, allowing a single I / O request to contain both read and write buffers at the same time.

[0087] Step 108: Write the drive read / write request into a preset description array to obtain a target description array, where the host performs the data access operation corresponding to the data access request according to the target description array for the stored data.

[0088] Among them, the preset description array can be understood as the description array corresponding to the scatterlist intermediate structure, see Figure 3B , Figure 3BThe figure shows a schematic diagram of a preset description array corresponding to a unidirectional read / write request in an embodiment of this specification. In this array, sgs[0] stores out_hdr, sgs[1] stores buffer address information, and sgs[2] reserves space for the status return information. The VirtIO-blk driver layer indicates these directions by counting. For example, the length of the sgs[] array is fixed at 3. When sending a read request, num_in = 2 and num_out = 1; when sending a write request, num_in = 1 and num_out = 2. Among them, num_in + num_out = 3 indicates that the data access request is a unidirectional read / write request. When num_in = 2 and nim_out = 1, it means that the data access request is a read request; when num_in = 1 and nim_out = 2, it means that the data access request is a write request. However, when the data access request is a bidirectional read / write request, the direction information cannot be distinguished by traditional technical methods. Therefore, the preset description array can be extended for the bidirectional read / write request.

[0089] In practical applications, the VirtIO-blk driver layer uses struct scatterlist as an intermediate structure to convert the driver read / write request virtblk_req into a vring_descriptor that conforms to the VirtIO protocol. Subsequently, these vring_descriptor descriptors will be added to the shared circular buffer (i.e., virtqueue) for the host (backend driver) to process.

[0090] Furthermore, when extending the preset description array for the bidirectional read / write request, it is necessary to extend the array for the read / write direction. Refer to Figure 3C , Figure 3C The figure shows a schematic diagram of a preset description array corresponding to a bidirectional read / write request in an embodiment of this specification. Extend sgs[3] to sgs[4]. By means of the special identifier of the general I / O request, when it is found that it is a bidirectional I / O request, the length of the sgs array is 4, and num_out = num_in = 2. During the process of converting the physical segments into struct scatterlist, according to the direction of the physical segment, it is placed into the corresponding data_sg[], realizing the division of the read / write buffer.

[0091] Specifically, writing the drive read / write request into a preset description array to obtain a target description array includes: determining a first description array and a second description array in the preset description array; writing the read data segment into the first description array to generate a read address description array, and writing the write data segment into the second description array to generate a write address description array; and obtaining the target description array according to the read address description array and the write address description array.

[0092] Among them, the first description array can be understood as Figure 3C sgs[1] in, which is used to write the read data segment and generate the read address description array data_sg[0]; the second description array can be understood as Figure 3C sgs[2] in, which is used to write the write data segment and generate the write address description array data_sg[1]. Correspondingly, sgs[0] is still used to write the request header information, and sgs[3] is used to write the status information status.

[0093] In practical applications, the read / write attributes of the first description array and the second description array can be determined according to actual settings. For example, the first description array writes the write data segment, and the second description array writes the read data segment.

[0094] Based on this, by writing the read data segment into the first description array and the write data segment into the second description array respectively, it is realized that the target description array contains description arrays with two read / write attributes.

[0095] Correspondingly, after obtaining the target description array, the method further includes: generating a request descriptor corresponding to the data access request according to the target description array; adding the request descriptor to a shared circular queue, where the shared circular queue is used for communication between the virtual kernel mode and the host.

[0096] Among them, the request descriptor can be understood as a vring_descriptor that conforms to the VirtIO protocol. These vring_descriptor descriptors will be added to the shared circular buffer (i.e., virtqueue) for processing by the host (backend driver). The vring_descriptor contains all the necessary information to enable the VirtIO device to understand how to perform specific I / O operations.

[0097] In actual applications, since the target description array includes the read address description array and the write address description array, the request descriptor also includes the descriptors corresponding to the read address description array and the write address description array, so that the backend driver can perform corresponding read and write operations according to the request descriptor. Specifically, when a new request is added to the virtqueue, the driver layer usually calls the vring_kick() function to notify the host that there is a new request to be processed. This causes the VirtIO device to poll its virtqueue and start processing the requests in the queue.

[0098] Based on this, by adding a special parsing method for bidirectional read and write requests in the VirtIO-blk driver layer, it is finally converted into the request descriptor format specified by the VirtIO protocol and written to the shared ring queue virtqueue, so that a single access request can include operations of both read and write attributes, reducing the I / O performance overhead and improving access efficiency.

[0099] Furthermore, after the host machine completes the corresponding operation according to the request descriptor, the result of the request operation can be returned to the shared ring queue. Specifically, after the request descriptor is added to the shared ring queue, the method also includes: in response to the execution completion request of the host machine, obtaining the status information corresponding to the request descriptor according to the shared ring queue; updating the driver read and write request based on the status information and returning to the virtual user state.

[0100] Among them, the execution completion request can be understood as a feedback request after the host completes the read and write request. According to the feedback request, the status information stored in the shared ring queue by the host can be obtained, and the driver read and write request is updated based on the status information and notified to the virtual user state.

[0101] In actual applications, the backend driver on the host is responsible for actually reading the request in the virtqueue and performing the corresponding I / O operation (such as reading or writing data) according to the vring_descriptor. After the processing is completed, the host updates the status field to indicate the result of the operation and puts the completion notification back into the shared ring buffer. After the VirtIO-blk driver layer detects the completion notification, it extracts the information in the status field and feeds the result back to the blk-mq layer. Finally, the blk-mq layer returns the operation result to the file system layer, which then passes it to the user-mode application.

[0102] A data access method provided in this specification includes receiving a data access request sent by a virtual user mode. Among them, the virtual user mode accesses the stored data of the host according to the data access request; determines the access type of the data access request. When the access type is a two-way read-write type, extracts the read address information and write address information in the data access request; encapsulates the read address information and the write address information according to a preset driver protocol to obtain a driver read-write request; writes the driver read-write request into a preset description array to obtain a target description array. Among them, the host performs a data access operation corresponding to the data access request on the stored data according to the target description array. It realizes determining the access type of the data access request sent by the virtual user mode. When the access type is a two-way read-write type, extracts the read address information and write address information, and encapsulates the read address information and the write address information according to a preset driver protocol to obtain a driver read-write request, enabling the device driver layer in the virtual kernel mode to support encapsulating and parsing two-way read-write requests. Subsequently, the driver read-write request is written into a preset description array through a device driver program to obtain a target description array, enabling the host to perform corresponding data access operations on the stored data according to the target description array. Through the parsing of two-way read-write requests by the device driver layer, it allows a single read-write request to simultaneously include a read operation and a write operation, reducing the performance overhead brought by read-write requests in a virtualized environment and also improving the read-write access efficiency.

[0103] The following combines the attached Figure 4 , taking the application of the data access method provided in this specification in processing two-way read-write requests as an example, further illustrates the data access method. Among them, Figure 4 shows a process flow chart of a data access method provided by an embodiment of this specification, specifically including the following steps.

[0104] Step 402: Receive a data access request sent by the virtual user mode according to the target call field.

[0105] In an implementable manner, an application program in the virtual user mode sends a data access request including a read operation and a write operation through a target system call.

[0106] Step 404: Parse the data access request to obtain the request header field of the data access request, and determine the access type of the data access request according to the request header field.

[0107] In an implementable manner, the driver layer in the kernel mode parses the data access request to obtain the request header field, and determines that the access type of the data access request is a two-way read-write type based on the type field in the request header field.

[0108] Step 406: Determine the buffer address corresponding to the data access request according to the data fields in the data access request.

[0109] In an implementable manner, the kernel converts the virtual address provided in the user mode into a physical address (page + offset + len). The file system layer calculates the corresponding physical sector number sector according to the logical offset of the file, creates an I / O request structure at the file system layer, and prepares the necessary metadata.

[0110] Step 408: Split the buffer address according to the write vector field in the data access request to obtain the read virtual address and the write virtual address.

[0111] In an implementable manner, the blk-mq layer further converts the I / O request at the file system layer into a general I / O request structure (such as bio), and converts the page + offset + len provided by the file system layer into a specific physical segment (bio_vec).

[0112] Step 410: Perform a linked list conversion on the read virtual address and the write virtual address to obtain a physical address linked list.

[0113] Performing a linked list conversion on the read virtual address and the write virtual address to obtain a physical address linked list can be understood as performing an address conversion on the read virtual address and the write virtual address to respectively obtain a read area physical address linked list and a write area physical address linked list; in an implementable manner, determine the read address information and the write address information of the data access request based on the physical address linked list. Determine the read flag information corresponding to each sub-read virtual address in the read virtual address, and the write flag information corresponding to each sub-write virtual address in the write virtual address; perform a linked list conversion on the read virtual address according to the read flag information corresponding to each sub-read virtual address to obtain a read physical address linked list, and perform a linked list conversion on the write virtual address according to the write flag information corresponding to each sub-write virtual address to obtain a write physical address linked list; generate a physical address linked list based on the read physical address linked list and the write physical address linked list.

[0114] Step 412: Create a request structure according to a preset driver protocol, determine the read attribute information of the read data segment according to the read address information, and determine the write attribute information of the write data segment according to the write address information.

[0115] Step 414: Encapsulate the read data segment and the write data segment into the request structure respectively according to the read attribute information and the write attribute information to obtain a driver read / write request.

[0116] Step 416: Determine the first description array and the second description array in the preset description array, write the read data segment into the first description array to generate a read address description array, and write the write data segment into the second description array to generate a write address description array.

[0117] Step 418: Obtain a target description array according to the read address description array and the write address description array.

[0118] Step 420: Generate a request descriptor corresponding to the data access request according to the target description array, and add the request descriptor to the shared circular queue.

[0119] Corresponding to the above method embodiment, this specification also provides an embodiment of a data access device. Figure 5 The structural schematic diagram of a data access device provided by an embodiment of this specification is shown. As Figure 5 shown, the device includes:

[0120] A receiving module 502, configured to receive a data access request sent by a virtual user mode, where the virtual user mode accesses stored data of a host according to the data access request;

[0121] An extraction module 504, configured to determine an access type of the data access request, and extract read address information and write address information in the data access request when the access type is a bidirectional read-write type;

[0122] An encapsulation module 506, configured to encapsulate the read address information and the write address information according to a preset driver protocol to obtain a driver read-write request;

[0123] A generation module 508, configured to write the driver read-write request into a preset description array to obtain a target description array, where the host performs a data access operation corresponding to the data access request on the stored data according to the target description array.

[0124] Optionally, the receiving module 502 is further configured to receive a data access request sent by the virtual user mode according to a target call field; or receive a data access request sent by the virtual user mode through a target read-write interface.

[0125] Optionally, the extraction module 504 is further configured to parse the data access request to obtain a request header field of the data access request; determine the access type of the data access request according to the request header field.

[0126] Optionally, the extraction module 504 is further configured to determine a buffer address corresponding to the data access request according to a data field in the data access request; split the buffer address according to a write vector field in the data access request to obtain a read virtual address and a write virtual address; and determine read address information and write address information of the data access request according to the read virtual address and the write virtual address.

[0127] Optionally, the extraction module 504 is further configured to perform linked list conversion on the read virtual address and the write virtual address to obtain a physical address linked list; and determine read address information and write address information of the data access request based on the physical address linked list.

[0128] Optionally, the extraction module 504 is further configured to determine read tag information corresponding to each sub-read virtual address in the read virtual address, and write tag information corresponding to each sub-write virtual address in the write virtual address; perform linked list conversion on the read virtual address according to the read tag information corresponding to each sub-read virtual address to obtain a read physical address linked list, and perform linked list conversion on the write virtual address according to the write tag information corresponding to each sub-write virtual address to obtain a write physical address linked list; and generate a physical address linked list based on the read physical address linked list and the write physical address linked list.

[0129] Optionally, the encapsulation module 506 is further configured to create a request structure according to a preset driver protocol; determine read attribute information of a read data segment according to the read address information, and determine write attribute information of a write data segment according to the write address information; and encapsulate the read data segment and the write data segment into the request structure according to the read attribute information and the write attribute information respectively to obtain a driver read / write request.

[0130] Optionally, the generation module 508 is further configured to determine a first description array and a second description array in the preset description array; write the read data segment into the first description array to generate a read address description array, and write the write data segment into the second description array to generate a write address description array; and obtain a target description array according to the read address description array and the write address description array.

[0131] Optionally, the apparatus further includes an addition module, configured to generate a request descriptor corresponding to the data access request according to the target description array; and add the request descriptor to a shared circular queue, where the shared circular queue is used for communication between the virtual kernel mode and the host.

[0132] Optionally, the adding module is further configured to, in response to an execution completion request of the host computer, obtain status information corresponding to the request descriptor according to the shared circular queue; update the drive read / write request based on the status information and return it to the virtual user state.

[0133] The above is a schematic solution of a data access device according to this embodiment. It should be noted that the technical solution of this data access device and the technical solution of the above data access method belong to the same concept. For the details not described in detail in the technical solution of the data access device, reference can be made to the description of the technical solution of the above data access method.

[0134] Figure 6 FIG. 6 shows a block diagram of a computing device 600 according to an embodiment of the present specification. The components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is connected to the memory 610 through a bus 630, and a database 650 is used to store data.

[0135] The computing device 600 further includes an access device 640, and the access device 640 enables the computing device 600 to communicate via one or more networks 660. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 640 may include one or more of any type of wired or wireless network interfaces (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC).

[0136] In an embodiment of the present specification, the above components of the computing device 600 and Figure 6 other components not shown in the figure may also be connected to each other, for example, through a bus. It should be understood that Figure 6The block diagram of the computing device shown is for illustrative purposes only and is not a limitation on the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0137] The computing device 600 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 600 can also be a mobile or stationary server.

[0138] Among them, the processor 620 is used to execute the following computer-executable instructions, and when the computer-executable instructions are executed by the processor, the steps of the above data access method are implemented.

[0139] The above is a schematic solution of a computing device in this embodiment. It should be noted that the technical solution of the computing device and the technical solution of the above data access method belong to the same concept. For the details not described in detail in the technical solution of the computing device, reference can be made to the description of the technical solution of the above data access method.

[0140] An embodiment of this specification also provides a computer-readable storage medium, which stores computer-executable instructions, and when the computer-executable instructions are executed by the processor, the steps of the above data access method are implemented.

[0141] The above is a schematic solution of a computer-readable storage medium in this embodiment. It should be noted that the technical solution of the storage medium and the technical solution of the above data access method belong to the same concept. For the details not described in detail in the technical solution of the storage medium, reference can be made to the description of the technical solution of the above data access method.

[0142] An embodiment of this specification also provides a computer program product, including a computer program or instructions, and when the computer program or instructions are executed by the processor, the steps of the above data access method are implemented.

[0143] The above is a schematic solution of a computer program product in this embodiment. It should be noted that the technical solution of the computer program product and the technical solution of the above data access method belong to the same concept. For the details not described in detail in the technical solution of the computer program product, reference can be made to the description of the technical solution of the above data access method.

[0144] The above describes 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 can be performed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0145] The computer instructions include computer program code, which can be in the form of source code, object code, executable files, or some intermediate form, etc. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, external hard drives, magnetic disks, optical disks, computer memories, read-only memories (ROMs), random access memories (RAMs), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately increased or decreased according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0146] It should be noted that for the foregoing method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations. However, those skilled in the art should know that the embodiments of this specification are not limited by the described order of actions, because according to the embodiments of this specification, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments of this specification.

[0147] In the above embodiments, the descriptions of the various embodiments have their own focuses. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0148] The preferred embodiments of this specification disclosed above are only used to help explain this specification. The alternative embodiments do not elaborate on all the details and do not limit the invention to only the specific embodiments described. Obviously, many modifications and variations can be made according to the content of the embodiments of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the embodiments of this specification, so that those skilled in the art can well understand and utilize this specification.

Claims

1. A data access method, applied to a virtual kernel state, comprising: Receiving a data access request sent by a virtual user state, wherein the virtual user state accesses storage data of a host machine according to the data access request; Determine the access type of the data access request. When the access type is a bidirectional read-write type, the data access request includes a read attribute operation and a write attribute operation, and extract the read address information and the write address information in the data access request. Encapsulating the read address information and the write address information according to a preset drive protocol to obtain a drive read and write request; The drive read / write request is written into a preset description array to obtain a target description array, wherein the host machine performs a data access operation corresponding to the data access request on the stored data according to the target description array.

2. The method according to claim 1, receiving a data access request sent by a virtual user state, comprises: receiving a data access request sent by the virtual user state according to a target call field, wherein the target call field is a call field corresponding to the request of the bidirectional read-write type; or, A data access request sent by the virtual user state through a target read-write interface is received, wherein the target read-write interface is a read-write interface corresponding to the request of the bidirectional read-write type.

3. The method according to claim 1, determining the access type of the data access request, comprising: Parsing the data access request to obtain a request header field of the data access request; An access type of the data access request is determined according to the request header field.

4. The method according to claim 1, extracting the read address information and the write address information in the data access request, comprising: Determining a buffer address corresponding to the data access request according to a data field in the data access request; Splitting the buffer address according to the write vector field in the data access request to obtain a read virtual address and a write virtual address; The read address information and the write address information of the data access request are determined according to the read virtual address and the write virtual address.

5. The method according to claim 4, determining the read address information and the write address information of the data access request according to the read virtual address and the write virtual address, comprising: Performing linked list conversion on the read virtual address and the write virtual address to obtain a physical address linked list; The read address information and the write address information of the data access request are determined based on the physical address linked list.

6. The method according to claim 5, performing linked list conversion on the read virtual address and the write virtual address to obtain a physical address linked list, comprising: Determine the read mark information corresponding to each sub-read virtual address in the read virtual address, and the write mark information corresponding to each sub-write virtual address in the write virtual address; According to the read tag information corresponding to each sub-read virtual address, the read virtual address is converted into a linked list to obtain a read physical address linked list; according to the write tag information corresponding to each sub-write virtual address, the write virtual address is converted into a linked list to obtain a write physical address linked list; A physical address linked list is generated based on the read physical address linked list and the write physical address linked list.

7. The method according to claim 1, encapsulating the read address information and the write address information according to a preset drive protocol to obtain a drive read and write request, comprising: Create a request structure according to the preset driver protocol; Determine the read attribute information of the read data segment according to the read address information, and determine the write attribute information of the write data segment according to the write address information; The read data segment and the write data segment are respectively encapsulated into the request structure according to the read attribute information and the write attribute information to obtain a drive read and write request.

8. The method according to claim 7, writing the drive read / write request into a preset description array to obtain a target description array, comprising: Determine a first description array and a second description array in the preset description array; Writing the read data segment into the first description array to generate a read address description array, and writing the write data segment into the second description array to generate a write address description array; A target description array is obtained according to the read address description array and the write address description array.

9. The method according to claim 1, after obtaining the target description array, the method further comprises: Generate a request descriptor corresponding to the data access request according to the target description array; The request descriptor is added to a shared ring queue, wherein the shared ring queue is used for the virtual kernel state to communicate with the host machine.

10. The method according to claim 9, after adding the request descriptor to the shared ring queue, the method further comprises: In response to the execution completion request of the host machine, obtaining status information corresponding to the request descriptor according to the shared ring queue; The drive read / write request is updated based on the status information and returned to the virtual user state.

11. A data access device, applied to a virtual kernel state, comprising: A receiving module is configured to receive a data access request sent by a virtual user state, wherein the virtual user state accesses storage data of the host machine according to the data access request; an extraction module, configured to determine an access type of the data access request, and when the access type is a bidirectional read-write type, the data access request includes a read attribute operation and a write attribute operation, and extract the read address information and the write address information in the data access request; A packaging module, configured to package the read address information and the write address information according to a preset drive protocol to obtain a drive read and write request; The generation module is configured to write the drive read / write request into a preset description array to obtain a target description array, wherein the host machine performs a data access operation corresponding to the data access request on the stored data according to the target description array.

12. A computing device comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the steps of the method according to any one of claims 1 to 10 are implemented.

13. A computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the steps of the method according to any one of claims 1 to 10.

14. A computer program product, comprising a computer program or instructions, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 10.

Images