Cloud disk read-write path recovery method and device, equipment, storage medium and program product

Abstract

The invention discloses a cloud disk read-write path recovery method and device, equipment, a storage medium and a program product, and the method comprises the steps: receiving a data read-write request sent by terminal equipment through a virtual storage module, and sending the data read-write request to a shared memory ring for temporary storage; when it is detected that the SPDK process is abnormal, the data storage state of the shared memory ring is kept unchanged, and a new data read-write request is continuously received and temporarily stored to the shared memory ring; after detecting that the SPDK process is restarted, reconstructing a data access link with the SPDK process; and obtaining an uncompleted data read-write request from the shared memory ring, and sending the uncompleted data read-write request to the SPDK process by using a data access link. By adopting the embodiment of the invention, the loss of the data read-write request when the SPDK process is abnormal or the data source fails can be effectively avoided, the original path of the cloud disk is ensured to be unchanged and the data is ensured to be consistent, the non-perception quick recovery is realized, and the DPU cloud storage reliability is improved.

Description

Technical Field

[0001] This invention relates to the field of cloud storage, and more particularly to a method, apparatus, device, storage medium, and program product for restoring cloud disk read / write paths. Background Technology

[0002] With the surge in demand for cloud computing and large-scale data processing, Data Processing Units (DPUs) have become a popular technology widely used in public clouds. Supporting bare metal and cloud host services, they offer extreme computing performance, complete network offloading, and powerful cloud disk storage capabilities. In application, DPUs can be deployed as PCIe (Peripheral Component Interconnect Express) devices in servers, exposing storage resources to the host to maximize the release of host CPU resources. Whether local or remote storage, the cloud disk front-end is a device running in a VM (Guest Virtual Machine) or container on the host side, while the back-end is built using user-space software such as the Storage Performance Development Kit (SPDK) within the DPU. Data is transferred between the front-end and back-end through a shared ring queue.

[0003] When the read / write path is normal, the Guest VM initiates a read / write request and passes it to the Host. The Host forwards the request to the DPU. After receiving the request, the SPDK in the DPU connects to the local NVMe SSD (Non-Volatile Memory Express SolidState Drive) or remote storage resources to complete the data processing, and finally returns the result to the Guest VM through the original path. However, when the SPDK process on the DPU side restarts, crashes, or the data source fails, Inflight IOs (read / write requests submitted to the DPU but not yet processed) sent to the DPU are very likely to be lost. For example, if multiple sets of Inflight IOs have been sent to the storage device but no results have been received, an SPDK process failure will cause these IO information to be completely lost. The Guest VM cannot confirm whether this part of the IO was successfully executed, and cannot retry incomplete requests or roll back partially processed operations, which will lead to problems such as data inconsistency and business interruption. Summary of the Invention

[0004] The purpose of this invention is to provide a cloud disk read / write path recovery method, device, equipment, storage medium, and program product that can effectively avoid the loss of data read / write requests when the SPDK process is abnormal or the data source fails, ensure that the original cloud disk path remains unchanged and the data is consistent, achieve seamless and rapid recovery, and improve the reliability of DPU cloud storage.

[0005] To achieve the above objectives, embodiments of the present invention provide a method for restoring cloud disk read / write paths, including: The virtual storage module receives data read / write requests from terminal devices and sends the data read / write requests to a shared memory ring for temporary storage. When an abnormality is detected in the SPDK process, the data storage state of the shared memory ring is maintained unchanged, and new data read / write requests are continuously received and temporarily stored in the shared memory ring. After detecting that the SPDK process has restarted, rebuild the data access link with the SPDK process; Unfinished data read / write requests are retrieved from the shared memory ring and sent to the SPDK process using the data access link.

[0006] As an improvement to the above solution, before receiving data read / write requests sent by the terminal device through the virtual storage module, the method further includes: Create a virtual storage module and configure the virtual storage module; Expose the functionality of the virtual storage module to the terminal device so that the terminal device can perform protocol adaptation to the virtual storage module; Establish a basic transmission link with the terminal device so that the virtual machine of the terminal device can access the virtual storage module based on the basic transmission link.

[0007] As an improvement to the above scheme, the shared memory ring includes an interaction area, a command area, and a data area; wherein, The interaction area is used to maintain the processing index and status identifier of the data read and write requests; The command area pre-allocates a fixed number of request descriptor storage units, which are used to record at least one of the following information: the type, address, and length of the data read / write request. The data area is used to store the business payload data corresponding to the data read / write request.

[0008] As an improvement to the above solution, sending the data read / write request to the shared memory ring for temporary storage includes: A Uvdev process is generated through a preset dynamic link library; wherein, the Uvdev process is used to bind to the backend storage system, establish a direct memory access address mapping relationship, and form a contiguous memory region, and the backend storage system is the physical storage resource cluster bound to the virtual storage module; Based on the address mapping relationship and the contiguous memory region, the polling mechanism for direct memory access is initiated; Using the polling mechanism, data read / write requests from the backend storage system are temporarily moved to the shared memory ring for storage.

[0009] As an improvement to the above scheme, the address mapping relationship includes the conversion relationship between the virtual machine physical address of the back-end storage system and the virtual address of the Uvdev process, and the mapping relationship between the virtual address of the Uvdev process and the physical address of the host machine; wherein, the shared memory ring is deployed in the memory space corresponding to the physical address of the host machine; The contiguous memory region is formed by the Uvdev process after receiving the handle of the big page file and mapping the big page file to its own virtual address; wherein, the handle of the big page file is passed by the virtual machine emulator process through an inter-process communication mechanism.

[0010] As an improvement to the above solution, the reconstruction of the data access link between the SPDK process includes: Obtain the restart type of the SPDK process; If the SPDK process restarts after a normal exit, control the SPDK process to load the fixed memory address of the shared memory ring, and restore the data access link with the shared memory ring based on the fixed memory address; If the SPDK process restarts after an abnormal exit, it requests the shared memory address of the shared memory ring from the Uvdev process and rebuilds the data access link with the shared memory ring based on the shared memory address.

[0011] To achieve the above objectives, embodiments of the present invention also provide a cloud disk read / write path recovery device, comprising: The data read / write request receiving module is used to receive data read / write requests sent by the terminal device through the virtual storage module. The read / write request temporary storage module is used to send the data read / write request to the shared memory ring for temporary storage; and when an abnormality is detected in the SPDK process, to maintain the data storage state of the shared memory ring unchanged, and to continuously receive and temporarily store new data read / write requests to the shared memory ring. The data access link reconstruction module is used to rebuild the data access link with the SPDK process after detecting that the SPDK process has restarted. The data read / write request sending module is used to obtain incomplete data read / write requests from the shared memory ring and send the incomplete data read / write requests to the SPDK process using the data access link.

[0012] To achieve the above objectives, embodiments of the present invention also provide a cloud disk read / write path recovery device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements the cloud disk read / write path recovery method as described in any of the above embodiments.

[0013] To achieve the above objectives, embodiments of the present invention also provide a computer-readable storage medium, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the cloud disk read / write path recovery method as described in any of the above embodiments.

[0014] To achieve the above objectives, embodiments of the present invention also provide a computer program product, including computer instructions, which, when executed by a processor, implement the cloud disk read / write path recovery method as described in any of the above embodiments.

[0015] Compared to existing technologies, the cloud disk read / write path recovery method, apparatus, device, storage medium, and program products disclosed in this invention can effectively avoid the loss of data read / write requests when the SPDK process is abnormal or the data source fails, ensuring that the original cloud disk path remains unchanged and the data is consistent, achieving seamless and rapid recovery, and improving the reliability of DPU cloud storage. Furthermore, when the SPDK process is abnormal, the data receiving link remains uninterrupted. The virtual storage module can continuously temporarily store the read / write requests from the terminal device in the shared memory ring, and the data storage state of the shared memory ring remains stable. This avoids the request loss or service interruption problems caused by process abnormalities in traditional solutions, and supports online upgrades and fault restarts of the SPDK process, all without the user's awareness. After the SPDK process restarts, the data access link can be rebuilt. After the link is rebuilt, the temporarily stored incomplete read / write requests can continue to be accurately retrieved from the shared memory ring and sent to the SPDK process for processing, ensuring that all requests during the link interruption period can be fully executed. This improves the reliability of cloud disk data read / write and reduces the risk of service interruption and the burden of user operation and maintenance. Attached Figure Description

[0016] Figure 1 This is the I / O state diagram of the Virtio solution for block storage devices in the existing technology; Figure 2 This is the IO flow graph provided in the embodiments of the present invention; Figure 3 This is a simplified communication model diagram of the virtual storage module provided in an embodiment of the present invention; Figure 4 This is a flowchart of a cloud disk read / write path recovery method provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of memory mapping provided in an embodiment of the present invention; Figure 6 This is a structural diagram of the shared memory ring (SMR) provided in an embodiment of the present invention; Figure 7 This is a timing diagram of process communication provided in an embodiment of the present invention; Figure 8 This is a flowchart of the SPDK process disconnection and restart process provided in this embodiment of the invention; Figure 9 This is another flowchart of the cloud disk read / write path recovery method provided in this embodiment of the invention; Figure 10 This is a structural block diagram of a cloud disk read / write path recovery device provided in an embodiment of the present invention; Figure 11 This is a structural block diagram of a cloud disk read / write path recovery device provided in an embodiment of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] See Figure 1 , Figure 1 This is an I / O state diagram for the Virtio block storage device solution in existing technology. It illustrates the processing flow of I / O requests under the traditional Virtio protocol, including two key data structures: the Available Ring and the Used Ring. The Available Ring stores I / O requests from the Guest (virtual machine) to the device, such as IO1 to IO6 in the diagram. The available ring uses the available queue index `avail_idx` to mark the position of the next write request, and the used queue uses the read request index `last_idx` to mark the position of requests already read by the device. The used queue stores the I / O results returned to the Guest after processing by the device, and the used queue uses the completed request index `used_idx` to mark the position of the next write result.

[0019] Figure 1The process can be divided into two stages: request submission and request processing. In stage ①, request submission, the Guest has written IO1 to IO6 into the available queue, and available_idx points to the end of the queue, indicating that the request to be processed has been submitted, but the device has not yet started processing, so the used queue is empty. In stages ②-③, request processing, the device reads IO1 to IO4 from the available queue and starts processing. At this time, last_idx advances to the IO6 position. After IO1 to IO4 are processed, the results are written into the used queue, and used_idx advances to the IO4 position. Then, the Guest is notified through the notification mechanism.

[0020] In actual DPU cloud disk scenarios, this process has a significant risk of Inflight IO loss (Inflight IO refers to IO requests that have been sent to the DPU for processing but have not yet been completed, including device interaction operations such as reading and writing). For example... Figure 1 As shown in stage ②, if IO1 to IO4 have been sent to the storage device but have not yet returned results, and the DPU-side SPDK process restarts, crashes, or the data source fails, these Inflight IOs that are being processed will most likely be completely lost. At this time, the Guest cannot know whether IO1 to IO4 have been successfully processed, which may lead to data inconsistency.

[0021] To address the aforementioned Inflight IO loss issue, SPDK and QEMU (Quick Emulator) have provided patches to support online recovery of the SPDK vhost process. However, this mechanism cannot be directly applied to the DPU cloud disk scenario for the following reasons: 1) The recovery path is not the original path: To achieve SPDK Live recovery, the vhost process needs to be started first, and then QEMU needs to be started. QEMU must be configured with the reconnect parameter. Although this method shortens the data link recovery time at the software level, in the DPU cloud disk scenario, from the perspective of the VM, the backend storage device has actually changed, and it is not a true recovery of the original path. 2) Performance and resource consumption issues: After restarting, the vhost process needs to renegotiate virtio device features and vhost-user protocol features with QEMU, and also needs to complete the configuration of memory table and virtqueue base address. Due to the core-binding polling feature of SPDK, the operation of reconfiguring virtio devices will consume a large amount of SoC CPU core resources in the DPU (originally used for I / O processing), causing the VM cloud disk performance to drop sharply during this period, which is clearly felt by guest users; moreover, this process takes a long time and there is additional overhead of copying data back and forth. 3) Inability to guarantee IO continuity: SPDK programs may crash at any point in the code, and the existing mechanism of SPDK vhost-user cannot guarantee that Inflight IO will not be lost in all scenarios. After restarting, it may not be possible to restore to the consistent state before the crash. It is difficult to guarantee the continuity of IO operation and cannot achieve seamless recovery of the Guest. 4) Incompatible with the characteristics of DPU cloud disks: The cloud disks provided by DPU are divided into system disks (require BIOS scan and boot) and data disks (support dynamic addition, deletion and modification). The data cloud disk is simulated by SPDK at the software level through PCIe. When the SPDK process crashes, the backend of the cloud disk will be lost directly. At this time, it is meaningless to restart the vhost process and simulate the device, because the VM will experience a disk failure, and the user's data security cannot be guaranteed.

[0022] To address the aforementioned issues, this invention provides a cloud disk read / write path recovery method. This method aims to resolve technical shortcomings in existing solutions, such as device software simulation, IO loss, and inflexible VM cloud disk configuration, enabling rapid online recovery of the original path of the DPU cloud disk. The method must meet two criteria: first, regardless of any anomalies occurring on the DPU side, as long as the Guest does not crash, any cloud disk managed by the Guest will not be lost and will maintain its original device (i.e., the cloud disk maintains its original path); second, all Inflight IOs can be captured 100% in any scenario, and the data channel can be quickly rebuilt and the original IO information processed after the SPDK process restarts, achieving rapid online recovery of the cloud disk. This invention utilizes a custom PCIe TLP module, HVPE (Hardware Virtio Processing Engine), user-space DMA (Direct Memory Access) polling and transport component, SMR (Sharing Memory Ring), and open-source user-space drivers on the DPU to collaboratively construct a stable and efficient IO processing link.

[0023] See Figure 2 , Figure 2 This is the IO flow diagram provided in this embodiment of the invention. The interaction flow and functions of each component are as follows: Step ① corresponds to the PCIe communication link. At this time, the external request is transmitted to the endpoint component of the DPU through the PCIe TLP. The data is received by the PCIe read bus driver, providing a hardware-level transmission channel for communication between the DPU and the outside world, ensuring the stability of data transmission; Step ② corresponds to HVPE. The HVPE built into the DPU is responsible for handling Virtio / NVMe protocol-related logic, including two sub-modules: Virtio optimization queue / NVMe submission queue and back-end storage system. The former realizes hardware-level simulation of Virtio devices on the virtual machine side, replacing the traditional software simulation method. The latter provides underlying support for storage resources, which avoids the performance loss of software simulation and also ensures the original device attributes of the cloud disk; Step ③ corresponds to the user-mode DMA polling and transport component. The DPU's SoC The CPU runs the Uvdev dynamic link library, which uses a user-mode DMA polling mechanism to move IO requests received by HVPE to the shared memory ring SMR for temporary storage. This process does not require kernel involvement, which improves data transfer efficiency and ensures that IO requests are not lost when the DPU malfunctions. SMR is an independent memory area and is not affected by process state. Step ④ corresponds to SPDK processing and interaction with the cloud disk. The SPDK host poller reads the temporarily stored IO requests from SMR, processes them through the block device abstraction layer and the network-based NVMe storage protocol, and then completes data interaction with the backend cloud disk through the kernel-port link. After processing, the result is written back to SMR and then fed back to HVPE and Guest by the Uvdev module.

[0024] When the SPDK process on the DPU side restarts or crashes, SMR will completely preserve all Inflight IO information. After the SPDK restarts, the original IO requests can be obtained directly through SMR and the data channel can be quickly rebuilt. At the same time, the hardening simulation mechanism of HVPE ensures the original path attributes of the cloud disk on the Guest side, ultimately achieving a fast online recovery effect with no cloud disk loss and no IO omission.

[0025] Before receiving data read / write requests, this embodiment of the invention requires the construction of a virtual storage module. This virtual storage module, jointly constructed by the PCIe TLP module and the HVPE module, completes the hardened management plane and data plane of the device backend. It is used to expose the hardened backend of virtual devices such as Virtio devices and NVMe devices to the terminal device (Host). The HVPE module faces the Host side externally, realizing the instantiation function of SR-IOV and Virtio / NVMe emulated devices, and internally manages the PCIe link to realize data transmission with the Host. The PCIe TLP module is responsible for the data transmission task between the Host CPU and the PCIe device, and maintains the data transmission path between the CPU storage domain and the PCIe bus domain.

[0026] Furthermore, the above process specifically includes the following steps 1 to 3.

[0027] Step 1: The DPU creates a virtual storage module and configures the virtual storage module.

[0028] For example, the HVPE module creates virtual storage modules, including Virtio devices, NVMe devices, etc., configures all the features of the device, the number and size of queues and other information, and completes register resource allocation to simulate that the device backend is still based on the virtio framework structure. At the same time, the transport layer is built, which is divided into two cases: Virtio devices and NVMe devices.

[0029] For Virtio devices, the transport layer corresponds to the vring, which consists of three parts: 1) vring_desc (Virtqueue Descriptor Table): This table stores the HPA (Host Physical Address) of the shared buffer. It serves as the address carrier for data transfer between the driver and the device (unlike the GPA implementation used in QEMU). In the Virtio device communication model, the driver and device are a pair of opposing roles that work together to complete the I / O interaction between the virtual machine and the hardware / virtual hardware. 2) vring_avail (Virtqueue Available Ring): Records the buffer index of the data to be processed that the driver has submitted to the device, informing the device which data is available for processing; 3) vring_used (Virtqueue Used Ring): Records the index of the data buffer that the device has finished processing, informing the driver which data has been processed.

[0030] For NVMe devices, the transport layer corresponds to a queue pair, which includes a Submission Queue and a Completion Queue. The Submission Queue is a storage queue for I / O commands issued by the host to the NVMe device, and the Completion Queue is a storage queue for the command processing results returned by the NVMe device to the host.

[0031] It should be noted that the essence of the virtual storage module is that HVPE enables PF (Physical Function) / VF (Virtual Function) to convert PCI (Peripheral Component Interconnect) devices into virtio-pci devices. Since the PCI specification requires PCI devices to have independent address spaces, this invention encodes all PCI devices using a BDF (Bus-Device-Function) code composed of Bus Number, Device Number, and Function Number to distinguish PCI devices. Each PCI device corresponds to a unique BDF, and all information is stored in its own register, ensuring the uniqueness of the backend physical resources.

[0032] Step 2: The DPU exposes the functionality of the virtual storage module to the terminal device so that the terminal device can perform protocol adaptation for the virtual storage module.

[0033] For example, the PCIe TLP module demonstrates the PCIe functionality of the host-side virtual storage module through the PCIe channel, including device scanning, plugging / unplugging, request processing, and interrupt reporting. This custom TLP module supports two types of TLPs to adapt to multi-VM virtualization scenarios: Control plane TLP: Corresponds to the host side's scanning, identification, and configuration operations for the device, including types such as cfgrd (ConfigurationRead, configuration space read operation) / cfgwr (Configuration Write, configuration space write operation), BAR (BaseAddress Register) space mrd (Memory Read, memory read operation) / mwr (MemoryWrite, memory write operation); Data plane TLP: corresponds to network forwarding, data transfer and other operations, including types such as mrd / mwr.

[0034] For example, see Virtio devices. Figure 3 , Figure 3 This is a simplified communication model diagram of the virtual storage module provided in this embodiment of the invention. The process of protocol adaptation on the Host side is as follows: 1. On the DPU side, first create a net (Network, network device) / blk (Block, block storage device) of virtio v0.9.5 / 1.0 / 1.1 as a virtual storage module; on the DPU side, complete the instantiation and protocol compatibility of the virtual storage module to provide recognizable virtualized storage for the Host side; 2. On the host side, the virtual memory module is scanned via TLP, and BUS and BAR spaces are allocated to the virtual memory module. This completes the allocation and mapping of the underlying address space and interrupt resources between the host and the DPU virtual memory module, establishing the hardware foundation link for device communication. The process is as follows: (1) BUS allocation; assign a unique PCIe bus number to the virtual storage module to ensure that the virtual storage module has an independent identifier in the PCIe bus architecture and avoid address conflicts with other devices; (2) The BAR0 space is used for driver negotiation. It provides dedicated memory space for driver negotiation and stores device configuration information for different virtio protocol versions; for example, the first 24 bytes of device configuration space in the 0.9.5 protocol; and the data area and layout for capability in the 1.0 / 1.1 protocol. (3) The BAR2 space is used to allocate memory space for the MSIX (Message-Signaled Interrupts Extended) interrupt vector, thereby supporting a multi-queue, high-concurrency interrupt reporting mechanism, replacing the traditional shared interrupt line mode, reducing interrupt processing latency, and improving I / O response efficiency.

[0035] 3. The Host scans the virtual storage module via TLP, loads the net / blk driver, and completes the hardware and software adaptation and initialization between the Host-side driver and the DPU virtual storage module, establishing the logical communication link between the Host virtual machine and the virtual storage module. The process is as follows: (1) Scan the PCI space to identify whether the device is net or blk; (2) Load the corresponding driver, perform hardware-software negotiation, and complete hardware resource allocation and initialization.

[0036] 4. The host uses a virtual storage module for data communication.

[0037] Step 3: The DPU establishes a basic transmission link with the terminal device so that the virtual machine of the terminal device can access the virtual storage module based on the basic transmission link.

[0038] For example, after the host completes driver loading, it can use the virtual storage module for data communication via the basic transmission link. From the host's VM perspective, the DPU side presents a real virtio-blk / net-pci hardware device. This PCI device contains a virtio bus, which connects to the virtio-blk / net device. The original backend on the vhost target side is replaced by this hardware device, realizing backend hardware offloading from the management plane to the data plane. This embodiment of the invention is neither equivalent to the software (SPDK) simulation implementation of the general solution, nor is it equivalent to vDPA's method of only offloading the data plane. Instead, it realizes backend hardware offloading from both the management plane and the data plane.

[0039] It should be noted that the backend full hardening scheme in this embodiment of the invention is not equivalent to the Virtio full uninstallation scheme. The backend model implemented by the Virtio full uninstallation scheme is rigid and fixed, and cannot accommodate the addition of new models. The HVPE module proposed in this embodiment of the invention is a unified abstract implementation of the Virtio model, supports topology simulation, can customize the device application scenarios required by the user online, and has a layered architecture. When adding a new device type, only the corresponding device-specific code needs to be added, and the module can automatically identify the specific type, greatly improving the flexibility of backend configuration. The real hardware device can ensure that when the SPDK process crashes, the disk in the VM remains unaffected, always existing and still the original device. At this time, if the FIO tool is used to perform read and write tests on the disk in the VM, it will be found that the FIO process is abnormal and cannot perform normal read and write operations. The process abnormality here is not the common I / O error caused by the interruption of the entire link communication. Figure 2As can be seen from the data link, with the backend storage system as the dividing point, the data plane and management plane from the VM device to the backend still exist and are normal. The real reason for the inability of FIO to read and write is that the data link between the backend and the SPDK process is broken in the latter half. Therefore, the above process only completes the first indicator of DPU cloud disk recovery, namely, maintaining the original path. The data path between the front-end VM and the backend is built by the HVPE module. At this time, the two can be abstracted as a producer-consumer model. When the Guest VM initiates a data request, it generates IO and sends it to the backend. In the virtio framework, this means writing the descriptor into the descriptor table and the available ring. The backend is actually a hardware device. From the perspective of the backend, the IO request issued by the front end is a change in hardware resources such as the doorbell register status bits and the ring buffer.

[0040] See Figure 4 , Figure 4 This is a flowchart of a cloud disk read / write path recovery method provided by an embodiment of the present invention. The cloud disk read / write path recovery method includes steps S1 to S4, which are executed by the DPU.

[0041] S1. Receive data read / write requests sent by the terminal device through the virtual storage module, and send the data read / write requests to the shared memory ring for temporary storage.

[0042] For example, the terminal device (Host-side VM) initiates a data read / write request to the virtual storage module on the DPU side through the established PCIe TLP communication link. The virtual storage module receives and parses the request based on its own vring (Virtio device) or queue pair (NVMe device). For Virtio devices, the VM-side driver writes the buffer information corresponding to the request into vring_desc (descriptor table) and records the buffer index into vring_avail (available ring). After the virtual storage module detects the index update of the available ring through hardware polling, it reads the HPA address and request parameters from the descriptor table to complete the request reception. For NVMe devices, the VM-side driver writes the command entry into the commit queue (SQ) and triggers the doorbell register notification. The virtual storage module reads the command entry in the SQ to complete the request reception. A shared memory ring refers to an independent shared memory area deployed on the DPU side. It adopts a circular queue data structure design and has the characteristics of high-concurrency read and write and non-loss data temporary storage. It is used to temporarily store all data read and write requests received by the virtual storage module, providing a data carrier for subsequent SPDK process to process requests, while ensuring that Inflight IO requests are not lost when the SPDK process restarts abnormally.

[0043] Further, in step S1, sending the data read / write request to the shared memory ring for temporary storage includes: generating a Uvdev process through a preset dynamic link library; wherein, the Uvdev process is used to bind the backend storage system, establish a direct memory access (DMA) address mapping relationship, and form a contiguous memory region, and the backend storage system is the physical storage resource cluster bound to the virtual storage module; based on the address mapping relationship and the contiguous memory region, starting the direct memory access polling mechanism; using the polling mechanism, moving the data read / write request from the backend storage system to the shared memory ring for temporary storage. The address mapping relationship includes the conversion relationship from the virtual machine physical address (Guest Physical Address, GPA) of the back-end storage system to the virtual address (Uvdev Virtual Address, UVA) of the Uvdev process, and the mapping relationship from the virtual address (UVA) of the Uvdev process to the host physical address (HPA); wherein, the shared memory ring is deployed in the memory space corresponding to the host physical address; the contiguous memory region is formed by the Uvdev process after receiving the handle of the large page file and mapping the large page file to its own virtual address; wherein, the handle of the large page file is passed by the virtual machine emulator process through an inter-process communication mechanism.

[0044] For example, the SoC CPU runs a custom dynamic link library Libuvdev.so to generate a Uvdev process. This process needs to complete three preparatory tasks: bind the back-end storage system corresponding to the virtual storage module, obtain the transport layer information of the Virtio / NVMe device (such as queue structure and memory address), and establish the address mapping relationship and contiguous memory region required for DMA.

[0045] Furthermore, the process of address mapping and construction of contiguous memory regions is as follows: The virtual machine emulator process (such as QEMU) creates a large page file under the path / dev / hugepages / through the large page file mechanism, thereby requesting a block of physical memory on the host machine; QEMU obtains the file descriptor (FD) of the large page file as a handle to identify and access the physical memory; QEMU passes the large page file handle to the Uvdev process through the UNIX domain socket inter-process communication (IPC) mechanism; After receiving the handle, the Uvdev process calls the mmap (Memory Map) system call to map the large page file into its own virtual address space, forming a contiguous virtual memory region.

[0046] Furthermore, the implementation of address mapping relies on a memory mapping mechanism, see [link to relevant documentation]. Figure 5 , Figure 5 This is a memory mapping diagram provided by an embodiment of the present invention. The diagram illustrates the mapping relationship of three types of address spaces: the first address space corresponds to the physical address space used by the Guest VM, with an upper limit of MAX_GUEST-1; the second address space includes the QEMU virtual address space QVA and the Uvdev virtual address space UVA, with the same upper limit of MAX_VirtualAddress-1; the physical memory space corresponds to the actual physical memory of the host machine, with an upper limit of MAX_PHYSICAL-1, where the memory segments are the actual storage carriers. The specific mapping logic is as follows: GPA is converted to HPA through Extended Page Tables (EPT), completing the mapping from the virtual machine physical address to the host machine physical address; QEMU maps the memory segment corresponding to HPA to its own QVA space (through the QEMU page table), realizing access to the backend memory; the Uvdev process maps the same memory segment to its own UVA space through mmap (through the Uvdev page table), ultimately realizing the complete address translation link of "GPA→HPA→UVA".

[0047] After completing the above preparations, the Uvdev process initiates a DMA polling mechanism. By polling the transport layer of the virtual storage module, such as the vring of the Virtio device and the queue pairs of the NVMe device, it detects data read and write requests in the backend storage system. Utilizing the established address mapping relationship, the payload data corresponding to the request is directly moved from the GPA address of the backend storage system to the HPA memory space corresponding to the shared memory ring via DMA for temporary storage. This process does not require CPU participation in data copying, achieving zero I / O path loss while ensuring that the requested data is not lost.

[0048] The data payload being moved still originates from the virtqueue, requiring its hardware resources to be cleared. Due to the active DMA mechanism and the fact that the source address, destination address, and transmission parameters are all determined—meaning regardless of whether the SPDK process exists or the backend actively triggers an interrupt—the request descriptor information will be polled by the user-space Uvdev process. At this point, another mechanism from the link library is needed: allocating a separate memory block within Libuvdev.so, for example, 512MB, to store the moved data. This separate memory block is directly acquired CPU memory, maintained by the Uvdev process, and shared with the SPDK process. In this embodiment, this separate memory resource is provided to the shared memory ring (SMR) and allocated into an interaction area, a command area, and a data area.

[0049] Further, see Figure 6 , Figure 6 This is a structural diagram of a shared memory ring (SMR) provided in an embodiment of the present invention. The shared memory ring includes an interaction area, a command area, and a data area. The interaction area is used to maintain the processing index and status identifier of the data read / write request. The command area pre-allocates a fixed number of request descriptor storage units, which are used to record at least one of the following information: the type, address, and length of the data read / write request. The data area is used to store the service payload data corresponding to the data read / write request.

[0050] For example, the interaction area is located at the top layer of SMR and serves as the synchronization control hub between the Uvdev process and the SPDK-side modules. It contains four key pieces of information: cmd_size, cmd_offset, tail_index, and head_index. Specifically, cmd_size records the size in bytes of a single request descriptor storage unit, used by the SPDK side to accurately locate each command entry (request descriptor storage unit) in the command area; cmd_offset records the starting offset address of the command area in SMR, used for quickly locating the storage location of the command area; tail_index, updated by the Uvdev process, identifies the position of the last request descriptor submitted to the command area, informing the SPDK side which requests are ready for processing; and head_index, updated by the SPDK side, identifies the position of the last request descriptor that has been processed, informing the Uvdev process which request descriptor units are idle and reusable. The information in the interaction area directly interacts with the SPDK-side SPDK timer poller (the module that polls the SMR status) and SPDK Vhost (the module that interfaces with virtual devices), achieving synchronization of request processing and status transmission.

[0051] For example, the command area is located below the interaction area and adopts a design with pre-allocated fixed resources. For instance, the number of command queues is set to 4096, corresponding to N=4096 command entries in the diagram. Each command entry records the control information for a single data read / write request, including: request type (read / write); storage address of the corresponding business payload in the data area; and data length of the business payload. The Uvdev process fills the parsed request control information into the command entry and updates the tail_index of the interaction area to identify the position of the new request. The SPDK side reads the command entry to be processed through the head_index to obtain the request control information.

[0052] For example, the data area is located at the bottom layer of SMR and is the storage area for service payload data. Its design features dynamic growth; when the Uvdev process acquires data via DMA, it extracts the specific payload and stores it in the data area. The size of the data area is not fixed; memory space is dynamically allocated and released based on the actual requested payload size. In this embodiment, an upper limit threshold is also set for the data area to avoid excessive resource allocation and waste. In the diagram, the data area is represented by multiple data blocks, each corresponding to the service payload data of a command entry in the command area. The address information in the command entry allows for precise location.

[0053] It's important to note that, through the independent memory mechanism, all Inflight I / O resides naturally in independent memory, while data is transferred via a shared memory structure. When the upper-layer Guest needs to write data, Libuvdev.so is first enabled to parse the data and add it to the data area. The command descriptor to be written is then populated into the command area, and the head and tail indices in the interaction area are updated. Finally, an event mechanism notifies the SPDK side for processing. Since the Uvdev process itself does not have the ability to consume data, it relies on SPDK to connect to the actual physical storage source to complete I / O and disk writing.

[0054] S2. When an abnormality is detected in the SPDK process, the data storage state of the shared memory ring remains unchanged, and new data read / write requests are continuously received and temporarily stored in the shared memory ring.

[0055] For example, in scenarios where the SPDK process malfunctions (such as process crashes, restarts, freezes, network disconnections, etc.), ensuring uninterrupted I / O request links and no data loss relies on the independent memory mechanism of the Shared Memory Ring (SMR) to achieve uninterrupted request reception and unchanged data state. The Uvdev process can perceive the running status of the SPDK process in real time through a preset heartbeat detection mechanism or process status monitoring interface. For example, the Uvdev process sends heartbeat packets to the SPDK process at fixed intervals (e.g., 10ms). If no response is received for several consecutive intervals, the SPDK process is determined to be malfunctioning. Alternatively, the process status query interface of the operating system (such as the ps or proc file system in Linux) can be used to check whether the SPDK process's PID exists and whether the process status is running. If the PID disappears or the status changes to stopped, an malfunction is determined. When any of the above malfunctions is detected, the Uvdev process immediately triggers the malfunction protection logic and executes subsequent shared memory ring state maintenance and new request reception operations.

[0056] The shared memory ring is deployed in an independent memory region, unaffected by the SPDK process state. Therefore, in the event of an SPDK failure, the Inflight IO data already stored in the shared memory ring (including the 4096 request descriptors in the command area and the payload data in the data area) will not be destroyed, overwritten, or released, maintaining its storage state before the failure. The head_index (index of requests processed by SPDK), tail_index (index of requests submitted by Uvdev), and request status indicators (pending / processing) in the interaction area remain unchanged, ensuring that unfinished requests can be accurately resumed after the SPDK process recovers. The fixed resources in the command area (4096 request descriptor storage units) and the dynamic memory in the data area (including allocated payload storage blocks) maintain their original memory mapping relationships, without triggering any memory release or reallocation operations. This design avoids the loss of received request data due to SPDK failure, ensuring the integrity of Inflight IO.

[0057] While maintaining the original data state of SMR, the Uvdev process does not interrupt the process of receiving new requests. At this time, the Uvdev process continues to obtain new data read and write requests issued by the upper-layer Guest from the backend storage system through the DMA polling mechanism, parses the new requests, extracts payload data, records control information such as request type, address, and length, and writes the new requests into SMR according to the original logic. If the data area has reached the upper limit threshold, the Uvdev process can pause receiving new requests (instead of rejecting them) and continue to receive and temporarily store them after SPDK recovers and the data area memory is released.

[0058] In this embodiment of the invention, the SPDK process is the consumer of I / O requests, which connects to the real physical storage source to complete the disk write. However, the Uvdev process itself does not have the ability to consume requests, and is only responsible for receiving and temporarily storing requests. Therefore, the design of step S2 ensures that the I / O request sending link on the Guest side is not interrupted, and the upper layer application does not need to be aware of SPDK abnormalities, thus avoiding errors such as request timeouts and connection failures. All new requests and existing unprocessed requests are securely temporarily stored in the independent memory of SMR. After the SPDK process restarts / recovers, all temporarily stored requests can be processed in sequence through the index and status flag of the interaction area, realizing seamless continuity of I / O services and ensuring data integrity and business continuity.

[0059] It's important to note that the SPDK process doesn't passively detect changes in the interaction area. It provides a timer-based Poller to actively check the resource status of the interaction area. When new data is added, the customizer triggers an event mechanism to notify the associated thread to consume the data. Specifically, the SPDK thread first retrieves the corresponding command entry from the command area based on the information in the interaction area, then copies the data area information. After copying, it updates the state information of the command entry (maintained by a state machine) and then sends it to the bdev layer, where it handles subsequent I / O processing.

[0060] Further, see Figure 7 , Figure 7 This is a timing diagram of process communication provided in an embodiment of the present invention. The diagram illustrates the interaction process between the Uvdev process and the SPDK process based on the SMR+FIFO (First-In First-Out) mechanism, including the following steps: Step 1: After the Guest VM sends a data read / write request to the backend storage system, the Uvdev process first obtains the location index of the available ring (the available ring of the Virtio device) and completes the shared memory address mapping corresponding to the request (i.e., the conversion from GPA to HPA to UVA) to prepare for subsequent data transfer. Step 2: The Uvdev process initiates the active DMA (Direct Memory Access) mechanism, which moves the requested data that has completed address mapping in the backend storage system to the shared memory ring SMR in batches. No CPU is required to participate in data copying, achieving zero-loss transmission. Step 3: The SPDK process continuously checks the resource status of the shared memory ring interaction area (such as the difference between tail_index and head_index) through the timer poller (timed polling component) to detect in real time whether there are new requests to write. Step 4: The Uvdev process parses the data transferred by DMA, extracts the business payload corresponding to the request, and stores it in the data area of ​​the shared memory ring, while recording the storage address of the payload in the data area. Step 5: After the batch of data is transferred, the Uvdev process marks the request status as "pending write" and synchronously updates the tail_index (identifying the position of the new request) of the shared memory ring interaction area, informing the SPDK process that there is a new request to be processed; Step 6: When the SPDK timer poller detects an update to the tail_index in the interaction area (index change), it immediately triggers its own event loop mechanism and notifies the associated spdk_thread to start processing the request. Step 7: Based on the information in the shared memory ring interaction area, spdk_thread reads the command descriptor corresponding to the command area and obtains the corresponding payload data from the data area; then it sends the request to the bdev layer (block device layer) of SPDK, and the bdev layer connects to the physical data source to complete the I / O disk write operation. Step 8: After data processing is complete, the SPDK process updates the command status (marked as "complete") and data information of the corresponding request in the shared memory ring; at the same time, a FIFO FD (named pipe file descriptor) is generated to pass the processing completion event to the Uvdev process; Step 9: The Uvdev process is interrupted by the FIFO FD passed by SPDK, receives the event notification that the SPDK write is complete, and synchronously informs its child processes to prepare for the subsequent process. Step 10: The Uvdev child process obtains the callback function of the corresponding request command in the shared memory ring, and performs cleanup processing on the data area and the entry area of ​​the command area through the callback function, such as marking it as free and releasing temporary resources. Step 11: The Uvdev process writes the processing result (success / failure) of the request to the used_ring (the used ring of the Virtio device), and then waits for the Guest VM to obtain the processing result by passively polling the used_ring, thus completing the closed loop of the entire request chain.

[0061] In this embodiment of the invention, by Figure 7 The process reveals that the two communication methods between the Uvdev process and the SPDK process are inconsistent. The first communication involves the SPDK process's timer actively triggering data processing, which the Uvdev process is unaware of. The second communication involves the SPDK using a named pipe (FIFO) to notify the Uvdev process that data processing is complete; in this case, the Uvdev process passively receives this event. This proposal introduces a FIFO mechanism on top of the original shared memory mechanism, offering two advantages: 1. The Uvdev process and the SPDK process are two independent processes that read and write data through shared memory. The IO data stream is maintained by an independent shared memory ring. This method is more efficient than other communication methods (such as pipes) because the data is directly transferred in the shared memory without the need for copying or serialization, which reduces the transmission overhead. 2. The FIFO mechanism requires switching from user space to kernel space, incurring context switching costs. Therefore, the frequency of FIFO FD triggering should be minimized. After the SPDK process finishes consuming data, SMR, as an independent memory block, cannot actively notify the Uvdev process. Of course, the Uvdev process can monitor the state machine in SMR through a timer, just like SPDK. Since SPDK is originally a core-bound polling + event triggering mechanism, there are already many mechanism optimization methods. Replicating an equivalent while 1 mechanism in the Uvdev process would have a much higher resource overhead than a passive FIFO FD acquisition. Moreover, this FD does not transmit data streams but only transmits an event state. The data stream obtained by the Uvdev process still comes from within the shared memory ring, rather than the pipeline built by FIFO FD.

[0062] Furthermore, by leveraging the Shared Memory Ring (SMR), this embodiment of the invention achieves a separate design: Libuvdev.so serves as the head portion, while SPDK and its backend Ceph or ESSD cluster constitute the body portion. Since SMR is independent memory located on the CPU and is unaffected by other processes, when SPDK experiences a connection failure, Libuvdev.so continues to operate. Its generated Uvdev process continuously stores the IOs in the Inflight state into the SMR. Therefore, during SPDK program restarts, all Inflight IOs are not lost. The dynamically expandable data area provides data redundancy, enabling the body portion to perform uninterrupted online upgrades without user awareness.

[0063] S3. After detecting that the SPDK process has restarted, rebuild the data access link between the SPDK process and the SPDK process.

[0064] Further, step S3 specifically includes: obtaining the restart type of the SPDK process; if the SPDK process restarts after a normal exit, controlling the SPDK process to load the fixed memory address of the shared memory ring, and restoring the data access link with the shared memory ring based on the fixed memory address; if the SPDK process restarts after an abnormal exit, using the SPDK process to request synchronization of the shared memory address of the shared memory ring from the Uvdev process, and rebuilding the data access link with the shared memory ring based on the shared memory address.

[0065] For example, see Figure 8 , Figure 8This is a flowchart illustrating the SPDK process disconnection and restart process provided in this embodiment of the invention. The Uvdev process uses DMA to move request data from the backend storage system to the shared memory ring (SMR), parses out the service payload and stores it in the SMR's data area. After completing the data operation, Uvdev updates the request status in the command area and modifies the index in the SMR interaction area to identify new requests. If the SPDK suddenly crashes at this time, some I / O has not yet been processed, causing the index in the SMR interaction area to not be updated. The status of the corresponding request in the command area is marked as Inflight (incomplete), and the request data in the SMR retains its original storage state.

[0066] The SMR data area then enters the resource management phase. If the data area memory has reached the threshold limit set by the solution, the data area will expand its memory and mark the command status of new requests as Inflight to wait for SPDK to restart. If the threshold has not been reached, new requests will continue to be received and stored in SMR, ensuring uninterrupted request reception. When SPDK is ready to restart and completes its environment self-check, the custom SMR memory detection submodule will take over the process first. This module is not included in the open-source driver and requires the corresponding patch to be added to the SPDK program and compiled. Its function is to complete the addressing of the SMR memory ring, scan and locate the shared memory address of SMR, and determine whether there are Inflight IO (unprocessed requests) in SMR.

[0067] If there are no unprocessed requests in SMR, the corresponding SPDK will exit and restart normally. During normal exit, its own mechanism will ensure that all IO processing is completed. SPDK will directly send a FIFO notification to the Uvdev process, which will then rewrite the data into shared memory and wait for SPDK to process it. If there are inflight IOs, the corresponding SPDK will exit and restart abnormally. SPDK will notify the Uvdev process of its restart via the FIFO mechanism and request synchronization of the SMR shared memory address. After receiving the notification, Uvdev will mark the requests in the Inflight state in the command area as ready_complete and update the index in the SMR interaction area. After the SPDK's timer poller detects the index change, it will rebuild the event notification channel with SMR, reprocess the incomplete IOs based on the request data in SMR, and finally send the requests to the BDEV layer to interface with the physical storage source, complete the IO write to disk, and restore the complete data link.

[0068] This process not only reflects the design of actively synchronizing shared memory addresses during abnormal restarts, but also ensures priority addressing of SMR through custom submodules, achieving seamless continuation of unprocessed requests and complete recovery of the data link.

[0069] S4. Obtain unfinished data read / write requests from the shared memory ring, and send the unfinished data read / write requests to the SPDK process using the data access link.

[0070] For example, after reconstructing the data access link with SMR, the SPDK process first scans the index difference (tail_index - head_index) of the interaction area based on the located SMR memory address to quickly locate the range of request descriptors in the command area with the status "Inflight". This range identifies the incomplete data read / write requests. Subsequently, the SPDK process directly reads the corresponding payload data from the SMR data area based on the address information recorded in these request descriptors, without requiring the Uvdev process to re-transfer or parse the data, maximizing the reuse of the stored request data. For data transmission, the SPDK process, relying on the reconstructed memory access link, encapsulates the control information and payload data of the incomplete requests into a standard I / O request packet and sends it to the BDEV layer through its own spdk_thread. During this process, the data is directly transmitted from the independent memory space of SMR to the BDEV layer without additional memory copying or format conversion, maintaining the zero-loss characteristic of the I / O path. If there are many uncompleted requests, the SPDK process will process them in batches according to the order of requests in the command area. After each batch of requests is processed, the head_index of the interaction area is updated in real time, and the processing progress is fed back to the Uvdev process through the FIFO mechanism. The Uvdev process then releases the corresponding data area memory space accordingly, realizing the dynamic reclamation and reuse of SMR resources.

[0071] In this embodiment of the invention, steps S1-S4 effectively prevent the loss of data read / write requests when the SPDK process is abnormal or the data source fails, ensuring that the original path of the cloud disk remains unchanged and the data is consistent, achieving seamless and rapid recovery, and improving the reliability of DPU cloud storage. Furthermore, when the SPDK process is abnormal, the data receiving link remains uninterrupted. The virtual storage module can continuously temporarily store the read / write requests from the terminal device in the shared memory ring, and the data storage state of the shared memory ring remains stable. This avoids the request loss or service interruption problems caused by process abnormalities in traditional solutions, and supports online upgrades and fault restarts of the SPDK process, all without the user's awareness. After the SPDK process restarts, the data access link can be rebuilt. After the link is rebuilt, the temporarily stored incomplete read / write requests can continue to be accurately retrieved from the shared memory ring and sent to the SPDK process for processing, ensuring that all requests during the link interruption period can be fully executed. This improves the reliability of cloud disk data read / write and reduces the risk of service interruption and the burden of user operation and maintenance.

[0072] See Figure 9 , Figure 9This is another flowchart of the cloud disk read / write path recovery method provided in this embodiment of the invention. It is the complete process of the cloud disk read / write path from device initialization to abnormal recovery, covering four stages: virtual device creation, data link establishment, shared memory collaboration, and abnormal recovery. It fully presents the overall logic of the solution. Phase 1, Virtual storage module initialization and negotiation, including processes 101-102: 101. The HVPE module creates a virtual storage module for Virtio / NVMe and completes the allocation of device register resources, providing a hardware-level virtual carrier for the cloud disk; 102. The Host side scans and identifies the virtual storage module through the TLP module, allocates BUS and BAR space for it, loads the corresponding driver, completes the hardware and software negotiation of the virtual device, and establishes the basic communication link between the Host and the virtual storage module. Phase 2, data link establishment and memory mapping, including process 201: 201. The custom dynamic link library Libuvdev.so obtains the buffer address from the device's ring queue and moves the data to the SoC CPU's buffer via DMA. Subsequently, the Uvdev process takes over the IO processing, automatically completes the memory mapping from the backend storage system's GPA to the user-mode process's virtual address, and opens up the data path from the virtual storage module to the user-mode process. Phase 3, Construction and Collaboration of Shared Memory Ring (SMR), including process 202: 202. Libuvdev.so allocates independent memory and divides it into an interaction area, a command area, and a data area (i.e., a shared memory ring). The Uvdev process maintains this memory space and stores control information and business data for I / O requests according to the area. At the same time, the Uvdev process and the SPDK process share this memory ring to realize event communication and data interaction under normal conditions and complete the data transfer of the cloud disk read and write path. Phase 4, path recovery after SPDK link loss, including process 203: 203. When the SPDK process experiences a disconnection, it distinguishes between normal and abnormal exit scenarios. After restarting, it prioritizes relying on the information in the shared memory ring to rebuild the event notification channel, prioritizes processing unfinished Inflight IO, and finally restores the complete data link to ensure the continuity of the cloud disk read and write path.

[0073] Compared to existing technologies, the cloud disk read / write path recovery method disclosed in this invention combines the flexibility and adaptability of software simulation devices with the path acceleration advantages of hardware simulation devices, proposing a layered hardware simulation backend mechanism that combines the advantages of both. Furthermore, this invention provides independent memory for data redundancy, improving the robustness and maintainability of the user-space storage driver. Compared to existing technical solutions, this invention employs a layered hardware simulation device, which better meets the subjective needs of different users while ensuring performance, combining strong applicability and high performance. The control plane and data plane of the cloud disk are completely decentralized to the DPU level, eliminating the need for user-defined images. The user system and storage service are completely isolated, ensuring a clean environment and convenient management. Independent memory resources can cover all idle I / O in most scenarios, providing better protection for user data security. The designed technology stack is mainly concentrated on the DPU side, including hardware I / O path offloading, user-mode drivers on the SoC, and shared memory, completely moving the storage function to the DPU. This completely releases the resource constraints of bare metal and cloud host servers, and does not occupy too many host resources except for standard drivers, satisfying the high sellability of host CPU resources. The backend process separation design enables system-level separation deployment, improves the data recoverability of routine development work, decouples the correlation between processes, and facilitates regular performance evaluation and optimization.

[0074] See Figure 10 , Figure 10 This is a structural block diagram of a cloud disk read / write path recovery device 100 provided in an embodiment of the present invention. The cloud disk read / write path recovery device 100 includes: The data read / write request receiving module 11 is used to receive data read / write requests sent by the terminal device through the virtual storage module; The read / write request temporary storage module 12 is used to send the data read / write request to the shared memory ring for temporary storage; and when an abnormality is detected in the SPDK process, to maintain the data storage state of the shared memory ring unchanged, and to continuously receive and temporarily store new data read / write requests to the shared memory ring. The data access link reconstruction module 13 is used to rebuild the data access link with the SPDK process after the SPDK process is detected to be restarted. The data read / write request sending module 14 is used to obtain incomplete data read / write requests from the shared memory ring and send the incomplete data read / write requests to the SPDK process using the data access link.

[0075] Specifically, the cloud disk read / write path recovery device 100 further includes: A virtual storage module configuration module is used to create virtual storage modules and configure them. A virtual storage module protocol adaptation module is used to expose the functions of the virtual storage module to the terminal device so that the terminal device can perform protocol adaptation to the virtual storage module. The transmission infrastructure link construction module is used to construct a transmission infrastructure link with the terminal device, so that the virtual machine of the terminal device can access the virtual storage module based on the transmission infrastructure link.

[0076] It is worth noting that the working process of each module in the cloud disk read / write path recovery device 100 described in the embodiments of the present invention can refer to the working process of the cloud disk read / write path recovery method described in the above embodiments, and will not be repeated here.

[0077] See Figure 11 , Figure 11 This is a structural block diagram of a cloud disk read / write path recovery device 200 provided in an embodiment of the present invention. The cloud disk read / write path recovery device 200 includes a processor 21, a memory 22, and a computer program stored in the memory 22 and executable on the processor 21. When the processor 21 executes the computer program, it implements the steps in the above-described embodiments of the various cloud disk read / write path recovery methods.

[0078] For example, the computer program can be divided into one or more modules / units, which are stored in the memory 22 and executed by the processor 21 to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the cloud disk read / write path recovery device 200.

[0079] The cloud disk read / write path recovery device 200 may include, but is not limited to, a processor 21 and a memory 22. Those skilled in the art will understand that the schematic diagram is merely an example of the cloud disk read / write path recovery device 200 and does not constitute a limitation on the device. It may include more or fewer components than illustrated, or combine certain components, or use different components. For example, the cloud disk read / write path recovery device 200 may also include input / output devices, network access devices, buses, etc.

[0080] The processor 21 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. The processor 21 is the control center of the cloud disk read / write path recovery device 200, connecting all parts of the device via various interfaces and lines.

[0081] The memory 22 can be used to store the computer programs and / or modules. The processor 21 implements various functions of the cloud disk read / write path recovery device 200 by running or executing the computer programs and / or modules stored in the memory 22 and calling the data stored in the memory 22. The memory 22 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0082] The modules / units integrated into the cloud disk read / write path recovery device 200, if implemented as software functional units and sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by the processor 21, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0083] Furthermore, the present invention also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the cloud disk read / write path recovery method as described in any of the above embodiments.

[0084] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A cloud disk read-write path recovery method, characterized in that, The method comprises the following steps: receiving a data read-write request sent by a terminal device through a virtual storage module, and sending the data read-write request to a shared memory ring for temporary storage; when an exception of an SPDK process is detected, maintaining a data storage state of the shared memory ring unchanged, and continuously receiving and temporarily storing new data read-write requests in the shared memory ring; after detecting that the SPDK process is restarted, rebuilding a data access link between the SPDK process; obtaining an unfinished data read-write request from the shared memory ring, and sending the unfinished data read-write request to the SPDK process by using the data access link.

2. The cloud disk read-write path recovery method of claim 1, wherein, Before the step of receiving the data read-write request sent by the terminal device through the virtual storage module, the method further comprises the following steps: creating a virtual storage module, and configuring the virtual storage module; exposing a function of the virtual storage module to the terminal device, so that the terminal device performs protocol adaptation on the virtual storage module; building a transmission basic link with the terminal device, so that a virtual machine of the terminal device accesses the virtual storage module based on the transmission basic link. 3.The cloud disk read-write path recovery method of claim 1, wherein, The shared memory ring comprises an interaction area, a command area and a data area; wherein the interaction area is used for maintaining a processing index and a state identifier of the data read-write request; the command area pre-allocates a fixed number of request descriptor storage units, and the request descriptor storage units are used for recording at least one of a type, an address and a length of the data read-write request; the data area is used for storing service load data corresponding to the data read-write request. 4.The cloud disk read-write path recovery method of claim 1, wherein, The step of sending the data read-write request to the shared memory ring for temporary storage comprises the following steps: generating a Uvdev process through a preset dynamic link library; wherein the Uvdev process is used for binding a backend storage system, establishing an address mapping relationship of direct memory access, and forming a continuous memory area, the backend storage system being a physical storage resource cluster bound to the virtual storage module; based on the address mapping relationship and the continuous memory area, starting a polling mechanism of the direct memory access; by using the polling mechanism, the data read-write request in the backend storage system is carried to the shared memory ring for temporary storage.

5. The cloud disk read-write path recovery method of claim 4, wherein, The address mapping relationship comprises a conversion relationship from a virtual machine physical address of the backend storage system to a Uvdev process virtual address, and a mapping relationship from the Uvdev process virtual address to a host machine physical address; wherein the shared memory ring is deployed in a memory space corresponding to the host machine physical address; the continuous memory area is formed after the Uvdev process receives a handle of a large page file, and maps the large page file to a virtual address of the Uvdev process; wherein the handle of the large page file is transmitted by a virtual machine emulator process through an inter-process communication mechanism. 6.The cloud disk read-write path recovery method of claim 1, wherein, The step of rebuilding the data access link between the SPDK process comprises the following steps: obtaining a restart type of the SPDK process; If the SPDK process is restarted after normal exit, the SPDK process is controlled to load the fixed memory address of the shared memory ring, and to resume the data access link with the shared memory ring based on the fixed memory address; If the SPDK process is restarted after abnormal exit, the SPDK process is used to request the Uvdev process to synchronize the shared memory address of the shared memory ring, and to rebuild the data access link with the shared memory ring based on the shared memory address.

7. A cloud disk read-write path recovery apparatus, characterized by comprising: Comprise: A data read-write request receiving module configured to receive a data read-write request sent by a terminal device through a virtual storage module; A read-write request temporary storage module configured to send the data read-write request to a shared memory ring for temporary storage, and to maintain the data storage state of the shared memory ring unchanged and continuously receive and temporarily store new data read-write requests in the shared memory ring when detecting that the SPDK process is abnormal; A data access link rebuilding module configured to rebuild the data access link between the SPDK process after detecting that the SPDK process is restarted; A data read-write request sending module configured to obtain an unfinished data read-write request from the shared memory ring, and to send the unfinished data read-write request to the SPDK process using the data access link.

8. A cloud disk read-write path recovery device, characterized in that, A computer readable storage medium comprising a computer program stored therein, wherein the computer program, when executed, controls a device in which the computer readable storage medium is located to implement the cloud disk read-write path recovery method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium comprises a stored computer program, wherein when the computer program is executed, the computer readable storage medium controls a device in which the computer readable storage medium is located to implement the cloud disk read-write path recovery method according to any one of claims 1 to 6.

10. A computer program product, characterised in that, The computer readable storage medium comprises a stored computer program, wherein when the computer program is executed, the computer readable storage medium controls a device in which the computer readable storage medium is located to implement the cloud disk read-write path recovery method according to any one of claims 1 to 6.

Images