Virtual block device implementation methods, apparatus, media, and computer program products

Abstract

This disclosure provides a method, apparatus, medium, and computer program product for implementing a virtual block device. The method includes: creating a virtual block device located between a file system and a physical block device, the virtual block device being used to forward a first block input / output request submitted by the file system to a physical block device bound to the virtual block device, and performing callback management on the first block input / output request; in response to a fault, maintaining the virtual block device's ability to receive the first block input / output request submitted by the file system, and unbinding the virtual block device from the physical block device; and in response to fault recovery, rebinding the virtual block device to the physical block device.

Description

Technical Field

[0001] This disclosure relates to the field of storage technology, and in particular to a method and apparatus for implementing a virtual block device, a medium, and a computer program product. Background Technology

[0002] With the rapid development of cloud computing and big data, block storage technology is being used more and more widely. Block storage technology is a technology that manages and accesses storage in units of fixed-size data blocks, characterized by high read and write efficiency. The kernel implements data read and write operations on storage devices by upper-layer applications through its file system, block devices, and driver control layer. If the storage device loses power and restarts, all services need to be stopped, which can have a significant negative impact on the user experience. Summary of the Invention

[0003] This disclosure provides a method, apparatus, medium, and computer program product for implementing a virtual block device.

[0004] In a first aspect, embodiments of this disclosure provide a method for implementing a virtual block device, comprising: creating a virtual block device located between a file system and a physical block device, the virtual block device being used to forward a first block input / output request submitted by the file system to a physical block device bound to the virtual block device, and performing callback management on the first block input / output request; in response to a fault, maintaining the virtual block device in receiving the first block input / output request submitted by the file system, and unbinding the virtual block device from the physical block device; and in response to fault recovery, rebinding the virtual block device to the physical block device.

[0005] In one possible implementation, forwarding the first block input / output request submitted by the file system to the physical block device bound to the virtual block device includes: receiving the first block input / output request submitted by the file system; encapsulating the first block input / output request into a first scheduling request; adding the first scheduling request to a first request queue; distributing the first scheduling request through a distribution end of the first request queue, where the first request queue represents a request queue established in the virtual block device; modifying the first block input / output request corresponding to the first scheduling request to generate a second block input / output request, the second block input / output request pointing to the physical block device bound to the virtual block device; storing the first scheduling request in the private data of the second block input / output request; and sending the second block input / output request to the physical block device bound to the virtual block device.

[0006] In one possible implementation, the callback management of the first block input / output request includes: receiving a callback response of the second block input / output request returned by the physical block device bound to the virtual block device; retrieving a first scheduling request corresponding to the second block input / output request from the private data of the second block input / output request based on the callback response of the second block input / output request, and using the callback response of the second block input / output request as the callback response of the first block input / output request corresponding to the first scheduling request, wherein the callback response of the second block input / output request indicates successful read / write; and returning the callback response of the first block input / output request to the file system.

[0007] In one possible implementation, the callback management of the first block input / output request further includes: receiving a callback response of the second block input / output request returned by the physical block device bound to the virtual block device; and re-adding the first scheduling request to the first request queue according to the callback response of the second block input / output request, wherein the callback response of the second block input / output request indicates a read / write failure.

[0008] In one possible implementation, the method further includes: determining a fault in response to the first scheduling request entering the first request queue a preset number of times, and / or determining a fault in response to the first block of input / output requests not being completed within a preset time.

[0009] In one possible implementation, unbinding the virtual block device from the physical block device includes: freezing the distribution end of the first request queue; in response to freezing the distribution end of the first request queue, stopping the distribution of the first scheduling request in the first request queue; and in response to the completion callback of the distributed first scheduling request, deleting the pointer of the physical block device from the virtual block device and dereferencing the physical block device.

[0010] In one possible implementation, binding the virtual block device to the physical block device includes: assigning a pointer of the physical block device to the virtual block device and referencing the physical block device; unfreezing the dispatch end of the first request queue; and, in response to unfreezing the dispatch end of the first request queue, initiating the dispatch of the first scheduling request in the first request queue.

[0011] In one possible implementation, the method further includes: in response to freezing the distribution end of the first request queue, storing the superblock data of the current storage device in the memory of the virtual block device; in response to fault recovery, reading the superblock data of the storage device; and in response to the inconsistency between the read superblock data and the stored superblock data, storing the read superblock data in the memory of the virtual block device.

[0012] In one possible implementation, the inconsistency between the read superblock data and the stored superblock data includes one or more of the following: the checksum of the read superblock data and the stored superblock data is inconsistent; the checksum of the read superblock data and the stored superblock data is consistent but the fields are inconsistent; and the timestamp of the read superblock data and the stored superblock data is inconsistent.

[0013] In one possible implementation, the creation of the virtual block device includes:

[0014] Receive user control commands through the kernel communication interface;

[0015] In response to the user control command, the virtual block device is created between the file system and the physical block device, and the virtual block device is bound to the physical block device.

[0016] Secondly, embodiments of this disclosure provide a virtual block device implementation apparatus, which includes a memory and a processor; the memory stores a computer program that can be executed by the processor, and when the computer program is executed by the processor, it implements any one of the virtual block device implementation methods of this disclosure.

[0017] Thirdly, embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements any of the virtual block device implementation methods of embodiments of this disclosure.

[0018] Fourthly, embodiments of this disclosure provide a computer program product, which includes a computer program that, when executed by a processor, implements any of the virtual block device implementation methods of embodiments of this disclosure.

[0019] In this embodiment, the kernel establishes a virtual block device between the file system and the physical block device. The virtual block device forwards block I / O requests submitted by the file system to the physical block device and manages callbacks for these requests. In the event of a failure, the virtual block device continues to receive block I / O requests from the file system, but it is unbound from the physical block device, preventing it from forwarding requests. Upon recovery, the virtual block device is rebound to the physical block device, resuming forwarding of block I / O requests. Thus, from the occurrence of a failure to recovery, block I / O requests submitted by the file system can be received normally without user-space program interaction, achieving seamless failure recovery for the user, improving user experience, and reducing the impact of failures on CPU utilization and performance degradation. Attached Figure Description

[0020] In the accompanying drawings of the embodiments disclosed herein:

[0021] Figure 1 A schematic diagram of the user-mode block device architecture is shown.

[0022] Figure 2 A schematic diagram of the system architecture of the block storage system provided in this embodiment is shown;

[0023] Figure 3 A flowchart illustrating a method for implementing a virtual block device according to an embodiment of this disclosure;

[0024] Figure 4 A block diagram illustrating the composition of a virtual block device implementation apparatus provided in this disclosure embodiment;

[0025] Figure 5 An interactive schematic diagram illustrating a virtual block device implementation method provided in an embodiment of this disclosure;

[0026] Figure 6 This is a schematic diagram illustrating the implementation process of a virtual block device implementation method provided in an embodiment of this disclosure. Detailed Implementation

[0027] To enable those skilled in the art to better understand the technical solutions of this disclosure, the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings.

[0028] The present disclosure will be described more fully below with reference to the accompanying drawings; however, the embodiments shown may be embodied in different forms, and the present disclosure should not be construed as limited to the embodiments set forth below. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will enable those skilled in the art to fully understand the scope of the disclosure.

[0029] The accompanying drawings are provided to further illustrate this disclosure and form part of the specification. They are used together with the detailed embodiments to explain this disclosure and do not constitute a limitation thereof. These and other features and advantages will become more apparent to those skilled in the art from the description of detailed embodiments with reference to the accompanying drawings.

[0030] Unless otherwise specified, each embodiment and feature of this disclosure may be used individually or in combination with other embodiments and features thereof.

[0031] Those skilled in the art will understand that various changes in form and detail may be made to the embodiments of this disclosure without departing from the scope of this disclosure as set forth by the appended claims.

[0032] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the disclosure. The term "and / or" as used in this disclosure includes any and all combinations of one or more of the associated enumerated entries. The singular forms "a" and "the" as used in this disclosure are also intended to include the plural forms, unless the context clearly indicates otherwise. The terms "comprising," "made of," etc., as used in this disclosure specify the presence of the stated feature, integral, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof.

[0033] Unless otherwise specified, all terms used in this disclosure (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined in this disclosure.

[0034] This disclosure is not limited to the embodiments shown in the accompanying drawings, but includes modifications to the configuration based on the manufacturing process. Therefore, the areas illustrated in the drawings are schematic, and the shapes of the areas shown illustrate specific shapes of the areas of an element, but are not intended to be limiting.

[0035] The kernel consists of a file system, block devices, and a driver control layer. The file system connects to user-space programs, while the driver control layer connects to storage devices. User-space programs perform data read / write operations via file handles to the kernel. Upon receiving the file handle, the kernel processes the data through the file system, block devices, and driver control layer to complete the data read / write operation on the storage device.

[0036] When a storage device experiences a recoverable failure such as a power outage and restart, the high coupling of the kernel's processing flow means that if the storage device is restarted after a power outage, all services must be stopped, all file handles must be released, and the entire processing flow must be rebuilt, which can have a significant impact.

[0037] In some related technologies, a user-space block device (ublk) architecture is used for fault recovery. In the ublk framework, user-space programs communicate with the kernel through input / output control (ioctl) or shared memory, receive block input / output (bio) requests from the kernel, process them, and then return the results to the kernel; ultimately, the kernel provides standard block device interfaces such as / dev / ublkbX to the upper layers.

[0038] Figure 1A schematic diagram of the user-space block device architecture is shown. For example... Figure 1 As shown, in the ublk architecture, user-space programs (such as the Flexible I / O Tester, fio) send bio requests to the kernel's block device interface ( / dev / ublkbX). The block device queue (Blk-mq) then efficiently processes these bio requests through a multi-queue mechanism. Next, the user-space block device driver control layer establishes the connection between the kernel and the user-space program, coordinating the bio request interactions between them. The kernel uses a high-performance asynchronous I / O framework provided by the input / output circular queue (io_uring) to efficiently interact with the user-space program's user-space block device service library (Libublksrv). After receiving the bio request forwarded by the kernel, the user-space program's target backend implements a specific callback function, such as one or more of the following: null device, loop device, Quick EmulatorCopy On Write (qcow), socket, distributed storage system (ceph), and remote procedure call (RPC).

[0039] In the UBLK architecture, all read and write logic for bio requests on ` / dev / ublkbX` is written in user-space code, such as positional reads or writes (pread / pwrite) to a specific file (e.g., loop). UBLK can provide storage devices like Ceph to upper-layer applications, which only need to perform standard read and write operations on ` / dev / ublkbX`. If the upper-layer applications use containers or virtual machines, they can expose ` / dev / ublkbX` as their disk, and reading and writing to ` / dev / ublkbX` will result in actual I / O passthrough to storage devices like Ceph. Even without storage devices, UBLK can still be used because the UBLK service library can run a daemon locally to handle actual read and write operations, such as running as a backend for a qcow2 format image to provide qcow disks to containers or virtual machines.

[0040] In related technologies, ublk utilizes the kernel's newly added user-mode recovery flag (UBLK_F_USER_RECOVERY) mechanism. By preserving device nodes in a silent kernel state and performing a two-stage reboot of startup recovery (START_RECOVERY) and end recovery (END_RECOVERY), it achieves self-healing after a crash by ensuring that the virtual disk does not disappear from the foreground, read and write requests are only blocked without errors, the foreground file system / virtual machine does not receive input / output errors (EIO), and only pauses briefly in the Uninterruptible Sleep state (also known as the D state).

[0041] However, in the ublk architecture, the underlying read / write (I / O) processing is done by user-space programs. In the ublk fault recovery solution, frequent user-space program interactions are required, which leads to high CPU utilization and significant performance loss.

[0042] In this embodiment, the kernel establishes a virtual block device between the file system and the physical block device. The virtual block device forwards block I / O requests submitted by the file system to the physical block device and manages callbacks for these requests. In the event of a failure, the virtual block device continues to receive block I / O requests from the file system, but it is unbound from the physical block device, preventing it from forwarding requests. Upon recovery, the virtual block device is rebound to the physical block device, resuming forwarding of block I / O requests. Thus, from the occurrence of a failure to recovery, block I / O requests submitted by the file system can be received normally without user-space program interaction, achieving seamless failure recovery for the user, improving user experience, and reducing the impact of failures on CPU utilization and performance degradation.

[0043] Figure 2 A schematic diagram of the system architecture of a block storage system provided in an embodiment of this disclosure is shown. Figure 2 As shown, a block storage system can include at least user-space programs, kernel, memory, and storage devices.

[0044] User-mode programs are applications that run in the user space of the operating system. They cannot directly access storage devices and need to request services from the kernel through system calls (such as file reading and writing, network communication, etc.) to read and write data in the storage devices.

[0045] The kernel resides between user-mode programs and storage devices. It can respond to service requests from user-mode programs, access storage devices, and thus read or write data to them. In this embodiment, the kernel may include a file system, a virtual block device, a physical block device, and a driver control layer.

[0046] The file system within the kernel interacts directly with user-mode programs. The file system can submit block input / output requests based on the operations performed by user-mode programs.

[0047] A virtual block device can represent a virtual block device. The virtual block device is created according to the virtual block device implementation method provided in the embodiments of this disclosure. The virtual block device resides between the file system and the physical block device, thus decoupling the file system from the physical block device. The virtual block device can receive block input / output requests submitted by the file system, forward the block input / output requests to the physical block device, and manage callbacks for the block input / output requests. The implementation process of the virtual block device will be described in detail later and will not be repeated here.

[0048] A physical block device can refer to the actual block device, or it can also be called the underlying block device. The physical block device is a module in the kernel responsible for managing storage devices. It provides a unified block device interface, shielding the hardware differences between different storage devices and optimizing I / O performance through mechanisms such as request merging and scheduling.

[0049] In this embodiment, the physical block device can receive block input / output requests sent by the virtual block device and perform callback management on these requests. The processing procedure for block input / output requests by the physical block device can refer to the processing procedure for block input / output requests by block devices in related technologies, and will not be repeated here. The interaction process between the physical block device and the driver control layer can refer to the interaction process between block devices and the driver control layer in related technologies, and will not be repeated here.

[0050] In this embodiment of the disclosure, the virtual block device can be bound to or unbound from the physical block device. When the virtual block device is bound to the physical block device, it can receive block I / O requests submitted by the file system and forward these requests to the physical block device. When the virtual block device is unbound from the physical block device, it can still receive block I / O requests submitted by the file system, but it will suspend forwarding these requests to the physical block device. When the virtual block device is rebound from the physical block device, it can continue forwarding block I / O requests to the physical block device.

[0051] The driver control layer is a module within the kernel that directly connects to the storage device. It is responsible for translating abstract operation instructions into hardware-recognizable signals, while also monitoring the storage device status and feeding it back to the kernel. The driver control layer can shield hardware differences and simplify access to higher layers.

[0052] Storage devices are the final carriers of data and form the hardware foundation of block storage. They read and write data in units of fixed-size blocks (such as 512 bytes, 4KB, etc.). Common storage devices include solid-state drives (SSDs) or hard disks.

[0053] In a first aspect, embodiments of this disclosure provide a method for implementing a virtual block device. This method can be applied to the kernel, for example... Figure 2 The kernel shown. (Refer to...) Figure 3 The virtual block device implementation method provided in this disclosure embodiment may include:

[0054] S101, Create a virtual block device.

[0055] The virtual block device is located between the file system and the physical block device. The virtual block device is used to forward the first block input / output request submitted by the file system to the physical block device bound to the virtual block device, and to perform callback management on the first block input / output request.

[0056] In this embodiment, the kernel creates a virtual block device between the file system and the physical block device, thus decoupling the file system and the physical block device. Since the virtual block device is created internally by the kernel, user-mode programs still interact with the kernel's file system, and storage devices still interact with the kernel's driver control layer; therefore, user-mode programs and storage devices are unaware of the virtual block device.

[0057] In this embodiment, a virtual block device can represent a virtual block device, and a physical block device can represent an actual block device. A file system can submit block input / output requests (BIO requests) to the virtual block device. When the kernel binds the virtual block device and the physical block device, the virtual block device can forward the BIO requests submitted by the file system to the physical block device for processing. For ease of description and understanding, this embodiment uses a first BIO request (referred to as a first BIO request) to represent a block input / output request submitted by the file system to the virtual block device, and a second BIO request (referred to as a second BIO request) to represent a block input / output request forwarded by the virtual block device to the physical block device. The virtual block device can manage callbacks for the first BIO request, and the physical block device can manage callbacks for the second BIO request.

[0058] S102, in response to a failure, the virtual block device continues to receive the first block input / output request submitted by the file system, and the virtual block device is unbound from the physical block device.

[0059] In the event of a failure, the kernel keeps the virtual block device accepting block I / O requests and unbinds the virtual block device from the physical block device. This allows the file system to submit the first block I / O request to the virtual block device, but the virtual block device will no longer send a second block I / O request to the physical block device.

[0060] S103, in response to fault recovery, the virtual block device is re-bound to the physical block device.

[0061] In the event of a fault recovery, the kernel rebinds the virtual block device to the physical block device. This allows the file system to submit its first block I / O request to the virtual block device, and the virtual block device to continue sending its second block I / O request to the physical block device.

[0062] In this embodiment, the file system directly submits Bio requests to the virtual block device, which then forwards the Bio requests to the physical block device. In the event of a fault, the virtual block device unbinds from the physical block device; after recovery, the virtual block device rebinds to the physical block device. Since the virtual block device can consistently receive Bio requests from the file system throughout the entire process from fault occurrence to recovery, the file system is unaware of the fault and can continue using the original file system after recovery. Because the file system remains unchanged before and after recovery, user-space programs are also unaware of the fault.

[0063] In this embodiment, the kernel establishes a virtual block device between the file system and the physical block device. The virtual block device forwards bio requests submitted by the file system to the physical block device and manages callbacks for these requests. In the event of a failure, the virtual block device continues to receive bio requests from the file system, but it is unbound from the physical block device, preventing it from forwarding bio requests to the physical block device. Upon recovery, the virtual block device is rebound to the physical block device, resuming forwarding of bio requests. Thus, from the occurrence of a failure to recovery, bio requests submitted by the file system can be received normally without user-space program interaction, achieving seamless failure recovery for the user and reducing the impact of failures on CPU utilization and performance degradation.

[0064] In some embodiments, the structure of a block device (including virtual block devices and physical block devices) includes block input / output (bio) requests, scheduling requests, and request queues, etc.

[0065] The bio request is the most basic structure in a block device that describes a single input / output request, directly corresponding to a read / write operation initiated by the upper-level file system. The bio request structure is created by the upper-level file system, processed by the block device, and then passed to the driver control layer. Upon completion of the bio request, a callback response notifies the upper-level file system.

[0066] In this context, a scheduling request is the smallest unit of block device scheduling, representing a scheduling-level encapsulation of a bio request by the block device. A block device can merge multiple consecutive or adjacent bio requests into a single request to reduce the number of physical read / write operations on the storage device and improve efficiency. A request is associated with one or more bio requests, representing a group of read / write operations that can be processed in batches by the storage device. In this embodiment, the scheduling request in the virtual block device is referred to as the first scheduling request (or simply the first request), and the scheduling request in the physical block device is referred to as the second scheduling request (or simply the second request).

[0067] The request queue serves as the request management center for the block devices. Each block device corresponds to one request queue, responsible for managing the requests within that block device. In this embodiment, the first request queue represents the request queue established in the virtual block device, and the second request queue represents the request queue established in the physical block device.

[0068] Block devices can manage the dispatch order of requests in the request queue and send requests. For example, a virtual block device can manage the dispatch order of the first request in the first request queue and send the first request to the physical block device. Similarly, a physical block device can manage the dispatch order of the second request in the second request queue and send the second request to the driver control layer.

[0069] Block devices can freeze the dispatch end of the request queue, at which point the dispatch of requests in the request queue is not allowed.

[0070] The block device converts the bio request into a request, adds the request to the request queue, and distributes the requests in the request queue. The process of the request triggering a callback can be found in relevant technologies, which will not be elaborated here.

[0071] After the bio request is completed, the block device can release the resources occupied by the bio request and the request itself.

[0072] The following describes the forwarding process of the first block I / O request by the virtual block device. In some embodiments, the virtual block device forwarding the first block I / O request submitted by the file system to the physical block device bound to the virtual block device may include:

[0073] S201, Receive the first block input / output request submitted by the file system.

[0074] S202, encapsulate the first block of input / output request into a first scheduling request.

[0075] S203, add the first scheduling request to the first request queue.

[0076] S204, the first scheduling request is distributed through the distribution end of the first request queue.

[0077] S205, modify the first block input / output request corresponding to the first scheduling request to generate a second block input / output request, the second block input / output request pointing to the physical block device bound to the virtual block device.

[0078] S206, save the first scheduling request in the private data of the second block of input / output requests.

[0079] S207, send the second block input / output request to the physical block device bound to the virtual block device.

[0080] In this embodiment of the disclosure, the virtual block device first receives a first block input / output request submitted by the file system and encapsulates the first block input / output request into a first scheduling request. Then, the virtual block device adds the first scheduling request to a first request queue and distributes the first scheduling request through the distribution end of the first request queue.

[0081] Because physical block devices can process block input / output requests but not scheduling requests, in order to maintain the original physical block device structure and functionality, when distributing the first scheduling request, the virtual block device does not directly send the first scheduling request to the physical block device. Instead, it first generates a second block input / output request based on the first scheduling request and then sends the second block input / output request to the physical block device.

[0082] For any first scheduling request distributed by the dispatcher of the first request queue, the virtual block device can modify the first block input / output request corresponding to the first scheduling request to generate a second block input / output request. In one example, the virtual block device can modify the execution of the first block input / output request to the physical block device bound to the virtual block device to obtain the second block input / output request, and then send the second block input / output request to the physical block device.

[0083] Additionally, the virtual block device can also store the first scheduling request within the private data of the second input / output request. Since the first input / output request is encapsulated as a first scheduling request, a correspondence exists between the first input / output request and the first scheduling request. The first input / output request is modified to obtain the second input / output request, thus establishing a correspondence between the first and second input / output requests. The private data of the second input / output request can store the corresponding first scheduling request.

[0084] As one embodiment of this disclosure, when the virtual block device receives the first block input / output request submitted by the file system, it encapsulates the first block input / output request into a first scheduling request and enqueues the first scheduling request. During the process of distributing the first scheduling request downwards, it copies and modifies the first block input / output request to obtain a second block input / output request, makes the second block input / output request point to the physical block device, saves the first scheduling request in the private data of the second block input / output request, and then sends the second block input / output request to the physical block device to perform actual read and write operations.

[0085] The callback management process for the first block input / output request by the virtual block device is described below. In some embodiments, the callback management of the first block input / output request by the virtual block device may include:

[0086] S301, receive a callback response to the second block input / output request returned by the physical block device bound to the virtual block device.

[0087] S302, based on the callback response of the second input / output request, retrieve the first scheduling request corresponding to the second input / output request from the private data of the second input / output request, and use the callback response of the second input / output request as the callback response of the first input / output request corresponding to the first scheduling request, wherein the callback response of the second input / output request indicates that the read / write was successful.

[0088] S303, return a callback response to the first block input / output request to the file system.

[0089] S304, based on the callback response of the second block of input / output request, the first scheduling request is re-added to the first request queue, wherein the callback response of the second block of input / output request indicates a read / write failure.

[0090] The virtual block device sends a second block I / O request to the physical block device. The physical block device can encapsulate the second block I / O request to obtain a second scheduling request and add the second scheduling request to a second request queue. The physical block device can then distribute the second scheduling requests in the second request queue to the driver control layer for actual read / write operations. Afterward, the physical block device can return a callback response (end_io) for the second block I / O request to the virtual block device.

[0091] The virtual block device can execute S302 and S303, or execute S304, based on the callback response to the second block input / output request.

[0092] If the callback response of the second input / output request indicates that the read / write operation was successful, the virtual block device can find the first scheduling request from the private data of the second input / output request, then find the first input / output request corresponding to the first scheduling request, then use the callback response of the second input / output request as the callback response of the first input / output request, and return the callback response of the first input / output request to the file system to inform the file system that the read / write operation was successful.

[0093] If the callback response of the second input / output request indicates a read / write failure, the virtual block device can read the first scheduling request from the private data of the second input / output request and re-add the first scheduling request to the first request queue for retry.

[0094] As one embodiment of this disclosure, after the physical block device completes the second I / O request, the virtual block device receives a callback response to the second I / O request. In the callback process, the virtual block device finds the corresponding first scheduling request using the private data of the second I / O request. If the callback response of this second I / O request indicates a successful read / write, the virtual block device directly returns the callback response of the second I / O request as the callback response to the first I / O request corresponding to the first scheduling request to the file system, informing the file system of a successful read / write. If the callback response of the local second I / O request indicates a read / write failure, the virtual block device re-adds the first scheduling request to the first request queue. In this way, read / write errors caused by storage device failures are not directly returned to the file system but are frozen on the virtual block device, achieving fault tolerance for the virtual block device.

[0095] In some embodiments, the virtual block device implementation method provided in this disclosure may further include:

[0096] S104, in response to the first scheduling request entering the first request queue a preset number of times, a fault is determined to have occurred, and / or, in response to the first block of input / output requests not being completed within a preset time, a fault is determined to have occurred.

[0097] If the number of times the first scheduling request enters the first request queue reaches a preset number, it indicates that read / write operations are continuously failing, and a fault can be confirmed. The kernel will pause retries and unbind the virtual block device from the physical block device, preventing the virtual block device from generating new second block input / output requests, in order to perform fault recovery.

[0098] The preset number of times can be used to determine the number of times the first scheduling request enters the first request queue. The preset number of times can be set as needed. It should be understood that a larger preset number of times results in better fault tolerance; a smaller preset number of times results in a shorter fault recovery waiting time. This embodiment does not limit the preset number of times.

[0099] If the first I / O request fails to complete within the preset time, it indicates that read / write operations are continuously failing, and a fault has occurred. The kernel will unbind the virtual block device from the physical block device and temporarily suspend processing of the first I / O request in order to perform fault recovery.

[0100] In some embodiments, unbinding the virtual block device from the physical block device in step S102 may include:

[0101] S1021, Freeze the distribution end of the first request queue.

[0102] S1022, in response to freezing the distribution end of the first request queue, stop distributing the first scheduling request in the first request queue.

[0103] S1023, in response to the distributed first scheduling request completion callback, the pointer to the physical block device is deleted from the virtual block device, and the physical block device is dereferenced.

[0104] As one embodiment of this disclosure, the virtual block device can freeze the distribution end of the first request queue. In this case, the virtual block device stops distributing the first scheduling request in the first request queue, but waits for the already distributed first scheduling request to complete the callback.

[0105] For any dispatched first scheduling request, if the callback response indicates a successful read / write operation, then the first scheduling request has completed its callback. If the callback response indicates a failed read / write operation, the first scheduling request can be added to the first request queue, and its callback completion can be confirmed. After waiting for the dispatched first scheduling requests to complete their callbacks, the kernel can remove the pointer to the physical block device from the virtual block device and dereference the physical block device. This prevents the virtual block device from pointing generated second block I / O requests to the failed physical block device.

[0106] In some embodiments, binding a virtual block device to a physical block device may include:

[0107] S1031, assign the pointer of the physical block device to the virtual block device and reference the physical block device.

[0108] S1032, Unfreeze the distribution end of the first request queue.

[0109] S1033, in response to unfreezing the distribution end of the first request queue, start distributing the first scheduling request in the first request queue.

[0110] As one embodiment of this disclosure, in response to the creation of a virtual block device or in response to fault recovery, the kernel can bind a virtual block device to a physical block device. The kernel can bind the virtual block device and the physical block device by assigning a pointer to the physical block device to the virtual block device and having the virtual block device reference the physical block device. If the dispatch end of the first request queue of the virtual block device was previously frozen, the process of binding the virtual block device to the physical block device also needs to include unfreezing the dispatch end of the first request queue to trigger the virtual block device to dispatch the first scheduling request in the first request queue.

[0111] In this embodiment, read / write (I / O) errors generated when the storage device fails are not directly returned to the upper-layer file system. Instead, they are frozen at the underlying virtual block device for fault tolerance. This includes storing and taking over the first request queue, disk drive letter, and status-related information. This information is stored in the device structure of the virtual block device, and can be directly restored after unfreezing. Simultaneously, during the period from the occurrence of the failure to recovery (i.e., the freeze period), the storage device is restarted and restored by powering on and off. The virtual block device automatically performs the unbinding and rebinding process, during which no user intervention is required.

[0112] In some embodiments, the virtual block device implementation method provided in this disclosure may further include:

[0113] S105, in response to freezing the distribution end of the first request queue, the superblock data of the current storage device is stored in the memory of the virtual block device.

[0114] S106, in response to fault recovery, reads the superblock data from the storage device.

[0115] S107, in response to the inconsistency between the read superblock data and the stored superblock data, the read superblock data is stored in the memory of the virtual block device.

[0116] In one example, inconsistency between the read superblock data and the stored superblock data includes one or more of the following: the checksum of the read superblock data and the stored superblock data are inconsistent; the checksum of the read superblock data and the stored superblock data are consistent but the fields are inconsistent; and the timestamp of the read superblock data and the stored superblock data are inconsistent.

[0117] In the event of a failure, a scenario may occur where the memory believes the data has been committed, but the storage device actually only has a partially completed product. This means that the superblock data stored in memory at the time of the failure is inconsistent with the superblock data read from the storage device after recovery. As one embodiment of this disclosure, a data consistency check mechanism is provided. After the storage device recovers from a failure, the virtual block device compares the superblock data stored in memory at the time of the freeze with the superblock data read from the storage device after recovery. If they are inconsistent, the superblock data read after recovery is stored in memory to correct the erroneous data read at the time of the freeze, thus completing the seamless data consistency check operation. If they are consistent, the superblock data stored in memory is released.

[0118] In some embodiments, step S101, creating a virtual block device, may include:

[0119] S1011 receives user control commands through the kernel communication interface.

[0120] S1012, in response to the user control instruction, create the virtual block device between the file system and the physical block device and bind the virtual block device to the physical block device.

[0121] The kernel communication interface represents the communication interface between the external system and the kernel. User control commands generated by user-mode programs can be sent to the kernel through this interface. In one example, the kernel communication interface could be the ` / dev / rlbd-control` write interface. Correspondingly, the kernel can receive user control commands through this interface. In another example, the kernel communication interface could be the `ioctl` interface. Similarly, the kernel can receive user control commands through this interface. It's important to note that the ` / dev / rlbd-control` write interface is the entry point for device control commands, while the `ioctl` interface is a multi-functional device management interface.

[0122] As one embodiment of this disclosure, the creation of a virtual block device can be achieved by receiving external user control commands, thereby determining whether to use the virtual block device according to user needs and improving flexibility.

[0123] In this embodiment of the disclosure, user control commands can also be used to trigger operations such as deleting the virtual block device and unbinding the virtual block device from the physical block device.

[0124] In some embodiments, the virtual block device implementation method provided in this disclosure may further include: receiving a device information read instruction through a kernel communication interface; and providing device information of the virtual block device in response to the device information read instruction. In one example, the kernel communication interface may be / sys / block / rlbd. <n>The / info read interface. Device information read commands can be obtained via / sys / block / rlbd. <n>The ` / info` read interface receives device information; the device information read command is used to read device information from the virtual block device. It should be noted that `sys / block / rlbd`... <n>The / info read interface is a device information query interface. In one example, device information includes, but is not limited to, device number, device status flags, etc.

[0125] As one embodiment of this disclosure, external information reading instructions can facilitate users' understanding of virtual block devices and improve user experience.

[0126] It should be understood that the above user control commands and device information reading commands are user operation commands to the kernel, realizing the interaction between the user and the kernel.

[0127] In this embodiment of the disclosure, when a fault occurs, there is no need to unload the file system, and the file system can be used normally after restarting the storage device; for the case of lost read and write requests and long-term non-return, blocking fault tolerance can be performed in the kernel's virtual block device; compatibility can be maintained for the case of drive letter change after restarting the physical block device; and reliability recovery can be performed for the case of data inconsistency before and after power failure, achieving seamless recovery and seamless data consistency check.

[0128] In addition, the virtual block device in this embodiment has a read / write cache. Users are unaware of asynchronous operations, while users will be blocked and wait for the disk to recover during synchronous operations.

[0129] In this embodiment of the disclosure, the loading of physical block devices is supported, that is, the binding of virtual block devices with physical block devices, and the online reloading of physical block devices is supported, that is, the online rebinding of virtual block devices with physical block devices is supported, read and write fault tolerance is supported, and data consistency checks are supported.

[0130] Secondly, referring to Figure 4 This disclosure provides a virtual block device implementation apparatus, which includes a memory and a processor; the memory stores a computer program that can be executed by the processor, and when the computer program is executed by the processor, it implements any one of the virtual block device implementation methods of this disclosure.

[0131] Thirdly, embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements any of the virtual block device implementation methods of embodiments of this disclosure.

[0132] Fourthly, embodiments of this disclosure provide a computer program product, which includes a computer program that, when executed by a processor, implements any one of the virtual block device implementation methods of this disclosure.

[0133] Among them, the processor is a device with data processing capabilities, including but not limited to the central processing unit (CPU); the memory is a device with data storage capabilities, including but not limited to random access memory (RAM), more specifically such as SDRAM, DDR, etc., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH); I / O interface, or read-write interface, is connected between the processor and the memory, enabling information exchange between the memory and the processor, including but not limited to the data bus (Bus).

[0134] The implementation method of the virtual block device provided in this disclosure is described below with reference to application examples.

[0135] Example 1

[0136] Reference Figure 5 This disclosure also provides an interactive schematic diagram of a virtual block device implementation method.

[0137] S600 binds virtual block devices to physical block devices.

[0138] S601, the file system submits its first input / output request.

[0139] S602, the virtual block device encapsulates the first block input / output request submitted by the file system into a first scheduling request.

[0140] S603, the virtual block device adds the first scheduling request to the first request queue.

[0141] S604, the virtual block device distributes the first scheduling request through the distribution end of the first request queue.

[0142] S605, the virtual block device modifies the first block input / output request corresponding to the first scheduling request and generates a second block input / output request.

[0143] S606, the virtual block device stores the first scheduling request in the private data of the second block input / output request.

[0144] S607, the virtual block device sends a second block input / output request to the physical block device.

[0145] S608, the physical block device generates a callback response based on the second block input / output request.

[0146] S609, the physical block device sends a callback response to the virtual block device for a second block input / output request.

[0147] S610, the virtual block device determines whether the callback response to the second block I / O request indicates a successful read / write operation. If yes, executes S611 and S612; otherwise, executes S613.

[0148] S611, the virtual block device reads the first scheduling request corresponding to the second input / output request from the private data of the second input / output request according to the callback response of the second input / output request, and uses the callback response of the second input / output request as the callback response of the first input / output request corresponding to the first scheduling request.

[0149] S612, the virtual block device returns a callback response to the file system for the first block I / O request.

[0150] S613, the virtual block device re-adds the first scheduling request to the first request queue.

[0151] Example 2

[0152] Reference Figure 6 This disclosure also provides a schematic diagram illustrating the implementation process of a virtual block device implementation method.

[0153] like Figure 6 As shown, the user performs read and write operations on the file system through a user-mode program. The file system submits a first block I / O request to the virtual block device. The virtual block device encapsulates the first block I / O request into a first scheduling request and adds the first scheduling request to a first request queue; the virtual block device distributes the first scheduling request from the first request queue; the virtual block device generates a second block I / O request based on the first block I / O request and stores the first scheduling request in the private data of the second block I / O request; the virtual block device sends the second block I / O request to the physical block device. The physical block device encapsulates the second block I / O request into a second scheduling request and adds the second scheduling request to a second request queue; the physical block device distributes the second scheduling request to the driver control layer.

[0154] The driver control layer performs data read / write operations on the storage device according to the second scheduling request. The storage device sends a data read / write callback response to the driver control layer. Based on the data read / write callback response, the driver control layer sends a callback response for the second scheduling request to the physical block device. The physical block device generates a callback response for the second block I / O request based on the callback response for the second scheduling request and sends the callback response for the second block I / O request to the virtual block device. The virtual block device performs callback management based on the callback response for the second block I / O request, including: if the callback response for the second block I / O request indicates a successful read / write operation, the virtual block device sends a callback response for the first block I / O request to the file system; if the callback response for the second block I / O request indicates a read / write failure, the virtual block device re-adds the first scheduling request corresponding to the second block I / O request to the first request queue.

[0155] In response to a failure, the virtual block device can unbind from the physical block device. In response to recovery from the failure, the virtual block device can bind back to the physical block device. In response to recovery from the failure, the virtual block device can re-distribute the first scheduling request in the first request queue.

[0156] In response to fault recovery, virtual block devices can also perform data consistency checks. The virtual block device can read the superblock device of the storage device from the physical block device and compare the data. If the read superblock data is inconsistent with the stored superblock data, the inconsistent data is updated through the file system.

[0157] In this embodiment, the file system does not need to be unmounted in the event of a failure, and it can still be used normally after restarting the storage device. When the storage device can recover via restart, read / write errors caused by a storage device failure are not directly returned to the upper-layer file system and upper-layer user-space programs. Instead, fault tolerance is handled at the underlying virtual block device, and retrying occurs after the storage device recovers. For cases where read / write requests (such as the first block I / O request) are lost or do not return for an extended period, fault tolerance can be achieved through read / write timeouts; for cases where drive letters change after restarting the physical block device, compatibility can be ensured; and for scenarios where data inconsistency is caused by hardware unreliability, seamless recovery is possible.

[0158] When a storage device experiences a power failure that can be recovered by restarting, the embodiments of this disclosure can achieve seamless recovery of the storage device, which greatly improves the user experience, saves energy, and reduces costs.

[0159] Those skilled in the art will understand that all or some of the steps, systems, and devices disclosed above, as functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0160] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be executed by several physical components working together.

[0161] Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit (CPU), digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media and communication media. In embodiments of this disclosure, computer storage media include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, and any other media that can be used to store desired information and can be accessed by a computer. In embodiments of this disclosure, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.< / n> < / n> < / n>

Claims

1. A method for implementing a virtual block device, the method comprising: The method comprises: creating a virtual block device between a file system and a physical block device, the virtual block device being configured to forward a first block input / output request submitted by the file system to a physical block device bound to the virtual block device, and to manage callback of the first block input / output request; in response to a failure, keeping the virtual block device receiving the first block input / output request submitted by the file system, and unbinding the virtual block device from the physical block device; in response to recovery from the failure, rebinding the virtual block device to the physical block device.

2. The method of claim 1, wherein, The forwarding of the first block input / output request submitted by the file system to the physical block device bound to the virtual block device comprises: receiving the first block input / output request submitted by the file system; encapsulating the first block input / output request into a first dispatch request; adding the first dispatch request to a first request queue; distributing the first dispatch request through a distribution end of the first request queue, the first request queue representing a request queue established in the virtual block device; modifying the first block input / output request corresponding to the first dispatch request to generate a second block input / output request, the second block input / output request being directed to the physical block device bound to the virtual block device; storing the first dispatch request in private data of the second block input / output request; and sending the second block input / output request to the physical block device bound to the virtual block device.

3. The method of claim 2, wherein, The managing of callback of the first block input / output request comprises: receiving a callback response of the second block input / output request returned by the physical block device bound to the virtual block device; according to the callback response of the second block input / output request, taking out the first dispatch request corresponding to the second block input / output request from the private data of the second block input / output request, and taking the callback response of the second block input / output request as a callback response of the first block input / output request corresponding to the first dispatch request, wherein the callback response of the second block input / output request represents a read / write success; returning the callback response of the first block input / output request to the file system.

4. The method of claim 2, wherein, The managing of callback of the first block input / output request further comprises: receiving a callback response of the second block input / output request returned by the physical block device bound to the virtual block device; according to the callback response of the second block input / output request, re-adding the first dispatch request to the first request queue, wherein the callback response of the second block input / output request represents a read / write failure.

5. The method of claim 4, wherein, The method further comprises: in response to a number of times that the first dispatch request enters the first request queue reaching a preset number of times, determining that the failure occurs, and / or in response to the first block input / output request not being completed within a preset time, determining that the failure occurs.

6. The method of claim 2, wherein, The unbinding of the virtual block device from the physical block device comprises: freezing a distribution end of the first request queue; in response to the freezing of the distribution end of the first request queue, stopping distribution of the first dispatch request in the first request queue; In response to a first scheduling request completion callback, deleting a pointer of the physical block device from the virtual block device, and dereferencing the physical block device.

7. The method of claim 2, wherein, The binding the virtual block device with the physical block device comprises: assigning a pointer of the physical block device to the virtual block device, and referencing the physical block device; unfreezing a dispatch end of the first request queue; In response to unfreezing the dispatch end of the first request queue, starting to dispatch a first scheduling request in the first request queue.

8. The method of claim 6, wherein, The method further comprises: In response to freezing the dispatch end of the first request queue, storing superblock data of a current storage device in a memory of the virtual block device; In response to a failure recovery, reading superblock data of a storage device; In response to the read superblock data being inconsistent with the stored superblock data, storing the read superblock data in the memory of the virtual block device.

9. The method of claim 8, wherein, The read superblock data being inconsistent with the stored superblock data comprises one or more of the read superblock data being inconsistent with the stored superblock data in checksum, the read superblock data being consistent with the stored superblock data in checksum but inconsistent in field, and the read superblock data being inconsistent with the stored superblock data in timestamp.

10. The method of claim 1, wherein, The creating a virtual block device comprises: receiving a user control instruction through a kernel communication interface; In response to the user control instruction, creating the virtual block device between the file system and the physical block device and binding the virtual block device with the physical block device.

11. A virtual block device implementation apparatus, characterized by A computer readable storage medium having stored thereon a computer program, the computer program being executable by a processor to implement the method of any one of claims 1 to 10.

12. A computer readable medium characterized by A computer readable storage medium having stored thereon a computer program, the computer program being executable by a processor to implement the method of any one of claims 1 to 10.

13. A computer program product, characterised in that, A computer readable storage medium having stored thereon a computer program, the computer program being executable by a processor to implement the method of any one of claims 1 to 10.

Images