Block device snapshot method, device, computer device and computer readable storage medium

Abstract

The application relates to a block device snapshot method and device, computer equipment and a computer readable storage medium, relates to the technical field of computer data backup and disaster recovery protection, and can guarantee the concurrent performance of a write path and realize zero-copy snapshot. The method comprises the following steps: intercepting a write request for a block device at a kernel block layer; determining a to-be-written block in the block device according to the write request, and determining an active bitmap in two change bitmaps allocated in a continuous virtual memory area; determining bit information corresponding to the to-be-written block as a target write identifier in the active bitmap; the target write identifier is used for indicating that the to-be-written block has been written; in response to a snapshot creation request initiated by a user space process, determining the active bitmap as a snapshot bitmap, and switching the active bitmap from a current change bitmap to another change bitmap; and the user space process is used for reading the snapshot bitmap to obtain block writing conditions of the block device according to the mapping of the continuous virtual memory area to a virtual address space of the user space process.

Description

Technical Field

[0001] This application relates to the field of computer data backup and disaster recovery technology, and in particular to a block device snapshot method, apparatus, computer equipment, computer-readable storage medium and computer program product. Background Technology

[0002] In traditional block device snapshot technology, write operations are typically intercepted and change bitmaps are maintained on the I / O (Input / Output) path. When a snapshot is created, the active bitmap is copied to the snapshot area via memory copy, and then the bitmap is copied from kernel mode to user mode via system call.

[0003] However, memory copy operations can take milliseconds for large-capacity storage devices, directly impacting the accuracy of backup and recovery points. Furthermore, newly arriving write I / O operations during the copy process may modify areas that haven't yet been copied, leading to snapshot inconsistencies. Using a locking mechanism to block writes sacrifices I / O concurrency performance. This results in significant accumulated overhead from the additional system calls and memory copies required for user space to obtain snapshot data in periodic snapshot scenarios, and the overall solution lacks an efficient kernel-user space zero-copy coordination mechanism. Summary of the Invention

[0004] Therefore, it is necessary to provide a block device snapshot method, apparatus, computer device, computer-readable storage medium, and computer program product to address the above-mentioned technical problems.

[0005] In a first aspect, this application provides a block device snapshot method, including:

[0006] At the kernel block level, intercept write requests to block devices;

[0007] Based on the write request, determine the block to be written in the block device, and determine the active bitmap in two change bitmaps allocated in a contiguous virtual memory region;

[0008] In the active bitmap, the bit information corresponding to the block to be written is determined as the target write identifier; the target write identifier is used to indicate that the block to be written has been written.

[0009] In response to a snapshot creation request initiated by a user-space process, the active bitmap is determined as the snapshot bitmap, and the active bitmap is switched from the current change bitmap to another change bitmap; the user-space process is used to read the snapshot bitmap to obtain the block write status of the block device based on the mapping of the contiguous virtual memory region to the virtual address space of the user-space process.

[0010] In one embodiment, determining the active bitmap as a snapshot bitmap and switching the active bitmap from the current change bitmap to another change bitmap includes:

[0011] Obtain the checkpoint occupancy identifier; the checkpoint occupancy identifier is used to indicate the current status of the checkpoint resource;

[0012] If the checkpoint occupancy flag indicates that the checkpoint resource is currently idle, the checkpoint occupancy flag is updated to the target occupancy flag; the target occupancy flag is used to indicate that the checkpoint resource is currently occupied.

[0013] The active bitmap is determined as a snapshot bitmap, and the active bitmap is switched from the current change bitmap to another change bitmap to obtain the switched active bitmap;

[0014] Clear the bit information in the switched active bitmap.

[0015] In one embodiment, the two change bitmaps and the shared header are allocated in the contiguous virtual memory region; the shared header includes a shared snapshot index.

[0016] The step of determining the active bitmap as a snapshot bitmap and switching the active bitmap from the current change bitmap to another change bitmap to obtain the switched active bitmap includes:

[0017] The kernel active index of the active bitmap is determined as the kernel snapshot index; the kernel active index is used to indicate the address information of the active bitmap in the contiguous virtual memory region;

[0018] The active bitmap is switched from the current change bitmap to another change bitmap to obtain the switched active bitmap;

[0019] The kernel snapshot index is written into the shared snapshot index to obtain a new shared snapshot index; the new shared snapshot index is used to indicate that the snapshot bitmap is the active bitmap before the switch.

[0020] In one embodiment, the step of reading the snapshot bitmap to obtain the block write status of the block device based on the mapping from the contiguous virtual memory region to the virtual address space of the user space process includes:

[0021] Based on the mapping from the contiguous virtual memory region to the virtual address space of the user space process, the new shared snapshot index and bitmap offset field are read from the shared header; the bitmap offset field is used to characterize the position offset of the two changed bitmaps;

[0022] Based on the new shared snapshot index and the bitmap offset field, the snapshot bitmap is located and traversed to obtain the bit setting information; the bit setting information is used to characterize the block write status of the block device.

[0023] If the preset backup and copy conditions are met, the blocks that have been written to the block device are read according to the setting information.

[0024] In one embodiment, the two change bitmaps and the shared header are allocated in the contiguous virtual memory region; the shared header includes a base disk capacity.

[0025] The process of obtaining the checkpoint occupancy identifier includes:

[0026] Compare the current disk capacity of the block device with the baseline disk capacity;

[0027] If the current disk capacity is inconsistent with the baseline disk capacity, the block device is determined to be in a fault state, and an error indication message is returned to the user space process; the user space process is used to determine that the block device is in a fault state based on the error indication message;

[0028] If the current disk capacity is the same as the baseline disk capacity, read the checkpoint occupancy flag.

[0029] In one embodiment, clearing the bit information in the switched active bitmap includes:

[0030] Upon receiving a snapshot consumption request initiated by a user space process, after verifying that the checkpoint sequence number carried in the snapshot consumption request is consistent with the current checkpoint sequence number, the checkpoint occupancy flag is released, and the switched active bitmap is cleared.

[0031] In one embodiment, the two change bitmaps and the shared header are allocated in the contiguous virtual memory region; the shared header includes a mapping sequence number;

[0032] After switching the active bitmap from the current change bitmap to another change bitmap, the method further includes: updating the mapping sequence number to obtain the updated mapping sequence number;

[0033] The step of reading the snapshot bitmap to obtain the block write status of the block device based on the mapping from the contiguous virtual memory region to the virtual address space of the user space process includes:

[0034] The initial mapping number is compared with the updated mapping number; the initial mapping number is determined when establishing the mapping from the contiguous virtual memory region to the virtual address space of the user space process.

[0035] If the initial mapping sequence number is inconsistent with the updated mapping sequence number, the block write status of the block device is obtained by reading the snapshot bitmap based on the mapping from the contiguous virtual memory region to the virtual address space of the user space process.

[0036] In one embodiment, intercepting write requests to block devices at the kernel block layer includes:

[0037] If the version corresponding to the kernel block layer belongs to the first kernel version range, the first function pointer in the request queue structure of the block device is stored in the snapshot tracking device structure, and the first function pointer in the request queue structure of the block device is replaced with a custom write interception function.

[0038] If the version corresponding to the kernel block layer belongs to the second kernel version range, copy the block device operation structure of the block device to obtain a structure copy, and replace the second function pointer in the structure copy with a custom write interception function;

[0039] Based on the custom write interception function, write requests for the block device are intercepted at the kernel block layer.

[0040] Secondly, this application also provides a block device snapshot apparatus, comprising:

[0041] The interception module is used to intercept write requests to block devices at the kernel block layer;

[0042] The first determining module is used to determine the block to be written in the block device according to the write request, and to determine the active bitmap in two change bitmaps allocated in a contiguous virtual memory region;

[0043] The second determining module is used to determine the bit information corresponding to the block to be written as the target write identifier in the active bitmap; the target write identifier is used to indicate that the block to be written has been written.

[0044] The switching module is used to respond to a snapshot creation request initiated by the user space process, determine the active bitmap as the snapshot bitmap, and switch the active bitmap from the current change bitmap to another change bitmap; the user space process is used to read the snapshot bitmap to obtain the block write status of the block device according to the mapping of the contiguous virtual memory region to the virtual address space of the user space process.

[0045] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0046] At the kernel block level, intercept write requests to block devices;

[0047] Based on the write request, determine the block to be written in the block device, and determine the active bitmap in two change bitmaps allocated in a contiguous virtual memory region;

[0048] In the active bitmap, the bit information corresponding to the block to be written is determined as the target write identifier; the target write identifier is used to indicate that the block to be written has been written.

[0049] In response to a snapshot creation request initiated by a user-space process, the active bitmap is determined as the snapshot bitmap, and the active bitmap is switched from the current change bitmap to another change bitmap; the user-space process is used to read the snapshot bitmap to obtain the block write status of the block device based on the mapping of the contiguous virtual memory region to the virtual address space of the user-space process.

[0050] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0051] At the kernel block level, intercept write requests to block devices;

[0052] Based on the write request, determine the block to be written in the block device, and determine the active bitmap in two change bitmaps allocated in a contiguous virtual memory region;

[0053] In the active bitmap, the bit information corresponding to the block to be written is determined as the target write identifier; the target write identifier is used to indicate that the block to be written has been written.

[0054] In response to a snapshot creation request initiated by a user-space process, the active bitmap is determined as the snapshot bitmap, and the active bitmap is switched from the current change bitmap to another change bitmap; the user-space process is used to read the snapshot bitmap to obtain the block write status of the block device based on the mapping of the contiguous virtual memory region to the virtual address space of the user-space process.

[0055] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0056] At the kernel block level, intercept write requests to block devices;

[0057] Based on the write request, determine the block to be written in the block device, and determine the active bitmap in two change bitmaps allocated in a contiguous virtual memory region;

[0058] In the active bitmap, the bit information corresponding to the block to be written is determined as the target write identifier; the target write identifier is used to indicate that the block to be written has been written.

[0059] In response to a snapshot creation request initiated by a user-space process, the active bitmap is determined as the snapshot bitmap, and the active bitmap is switched from the current change bitmap to another change bitmap; the user-space process is used to read the snapshot bitmap to obtain the block write status of the block device based on the mapping of the contiguous virtual memory region to the virtual address space of the user-space process.

[0060] The aforementioned block device snapshot method, apparatus, computer device, computer-readable storage medium, and computer program product, at the kernel block layer, intercept write requests for the block device; based on the write request, determine the block to be written in the block device, and determine the active bitmap in two change bitmaps allocated in a contiguous virtual memory region; in the active bitmap, determine the bit information corresponding to the block to be written as the target write identifier; the target write identifier is used to indicate that the block to be written has been written; in response to a snapshot creation request initiated by a user-space process, determine the active bitmap as the snapshot bitmap, and switch the active bitmap from the current change bitmap to another change bitmap; the user-space process is used to read the snapshot bitmap to obtain the block write status of the block device according to the mapping from the contiguous virtual memory region to the virtual address space of the user-space process. Compared with traditional technologies, on the one hand, this application does not need to copy the bitmap data block byte by byte during snapshot creation, but completes the snapshot bitmap marking by switching the active bitmap from the current change bitmap to another change bitmap, and after the switch, the original active bitmap no longer receives newly arriving write requests, and there is no need to maintain the snapshot bitmap. Figure 1 By blocking subsequent write I / O, the efficiency of snapshot creation can be improved while ensuring the concurrent performance of the write path. On the other hand, this application utilizes the direct mapping from contiguous virtual memory regions to the virtual address space of user space processes, so that user space processes can directly access kernel-mode bitmap data through the mapping when reading snapshot bitmaps, without having to execute additional data copy system calls from kernel mode to user mode. Thus, in both single and periodic snapshot scenarios, the overhead of data movement and context switching required when user space reads snapshot bitmaps can be effectively eliminated. Attached Figure Description

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

[0062] Figure 1 This is a diagram illustrating the application environment of the block device snapshot method in one embodiment;

[0063] Figure 2 This is a flowchart illustrating a block device snapshot method in one embodiment;

[0064] Figure 3 This is a diagram showing the relationship between the dual bitmap memory layout and mmap mapping in one embodiment;

[0065] Figure 4 This is a flowchart illustrating the bitmap switching steps in one embodiment;

[0066] Figure 5 This is a block diagram of a block device change tracking zero-copy snapshot system in one embodiment;

[0067] Figure 6 This is a timing diagram illustrating the pointer swapping before and after CHECKPOINT in one embodiment;

[0068] Figure 7 This is a performance comparison chart of multiple block device snapshot schemes in one embodiment;

[0069] Figure 8 This is a structural block diagram of a block device snapshot device in one embodiment;

[0070] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0071] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0072] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various objects, but these objects are not limited by these terms. These terms are only used to distinguish the first object from the second object. The term "comprising" and any variations thereof, as used in this application, are intended to cover non-exclusive inclusion. The term "multiple" as used in this application refers to two or more.

[0073] The block device snapshot method provided in this application embodiment can be applied to, for example, Figure 1The application environment is illustrated. The terminal communicates with the server via a network. The data storage system stores the data the server needs to process. The data storage system can be integrated onto the server or located on the cloud or other network servers. The terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted displays, etc. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0074] In one exemplary embodiment, such as Figure 2 As shown, a block device snapshot method is provided. This method can be applied to a computer device running an operating system (such as Linux). The computer device can be... Figure 1 The terminal in the middle can also be Figure 1 Taking the server in the example of applying this method to a terminal, the method may include the following steps:

[0075] Step S201: At the kernel block layer, intercept write requests for block devices.

[0076] Write requests for block devices can refer to write I / O requests issued by user-space processes or the operating system to the block device. The kernel block layer can refer to the software layer in the operating system used to manage write I / O requests for block devices (such as solid-state drives and embedded storage cards); the kernel block layer can deploy kernel modules used to implement CDP (Continuous Data Protection) business logic.

[0077] For example, the terminal can set up an interception mechanism at the Linux kernel block level to intercept all write requests (such as write I / O requests) to the protected block device.

[0078] Step S202: Based on the write request, determine the block to be written in the block device, and determine the active bitmap in two change bitmaps allocated in a contiguous virtual memory region.

[0079] In this context, the block to be written in the block device refers to the disk block in the block device for which content needs to be written in this write operation. A contiguous virtual memory region refers to a contiguous segment of the operating system kernel's virtual address space. A change bitmap refers to a memory region composed of multiple bits. An active bitmap refers to a change bitmap used to record write activity.

[0080] For example, such as Figure 3 As shown, the terminal can pre-allocate two change bitmaps of equal size (denoted as bitmap[0] and bitmap[1]) and a shared header in a contiguous virtual memory region (vmalloc). After intercepting a write I / O request, the terminal can use the kernel module to determine the block to be written in the block device based on the information carried by the write I / O request (such as the starting sector address and data length). Moreover, the terminal can use the kernel module to determine the bitmap currently used to record the block write status of the block device (i.e., the active bitmap) in bitmap[0] and bitmap[1] based on the kernel active index (active_idx).

[0081] Step S203: In the active bitmap, the bit information corresponding to the block to be written is determined as the target write identifier; the target write identifier is used to indicate that the block to be written has been written.

[0082] The bit information corresponding to the block to be written can refer to the information carried by the bit corresponding to the block to be written in the active bitmap.

[0083] For example, after determining the block to be written and the active bitmap in the block device, the terminal can, through the kernel module, set the bit information corresponding to the block to be written as the target write identifier, for example, setting the bit corresponding to the block to be written to 1, thereby indicating that the block to be written has been written with data. When a new dirty block marker is added (such as when the dirty block count changes from zero to non-zero), the user space process blocked in the waiting queue is woken up to notify it of the change that can trigger a checkpoint; the poll operation returns a readable event when a dirty block marker exists (dirty block count is greater than zero).

[0084] Step S204: In response to the snapshot creation request initiated by the user space process, the active bitmap is determined as the snapshot bitmap, and the active bitmap is switched from the current change bitmap to another change bitmap; the user space process is used to read the snapshot bitmap to obtain the block write status of the block device based on the mapping of the contiguous virtual memory region to the virtual address space of the user space process.

[0085] Here, a snapshot creation request initiated by a user-space process can refer to a request signal issued by the user-space process through a system call to the kernel. The block write status of a block device can refer to whether each block in the block device has been written.

[0086] For example, when a user-space process needs to create a snapshot, it sends a snapshot creation request to the Linux kernel of the terminal. In response to this snapshot creation request, the terminal can implement a zero-copy atomic snapshot through a ping-pong switching mechanism, i.e., perform a CHECKPOINT ping-pong switching operation. Specifically, in response to the snapshot creation request initiated by the user-space process, the terminal can, through the kernel module, freeze the current active bitmap (bitmap[active_idx]) as the snapshot bitmap (i.e., snap_idx=active_idx), and switch the kernel active index (i.e., active_idx^=1), making another changed bitmap the new active bitmap; that is, the active bitmap switches from the current changed bitmap to another changed bitmap. In this embodiment, the user-space process maps a contiguous virtual memory region to its virtual address space via the mmap system call at startup, i.e., a shared mapping (MAP_SHARED). Based on this shared mapping, it can be guaranteed that subsequent kernel modifications to the shared header (e.g., snap_index flip) are immediately visible to the user-space process without additional system calls. User-space processes can read the shared snapshot index (snap_index) within a contiguous virtual memory region through this shared mapping. Using this index, they can locate the current snapshot bitmap and then directly read the bitmap to determine which data blocks have been written to the block device (i.e., the block write status of the block device). This process only involves switching and reading the index assignment; the bitmap data is never copied to user space, achieving zero-copy reading.

[0087] In this embodiment, during the device initialization phase, the terminal's kernel module can access the character device ( / dev / cdp_ <name>The mmap file operation maps a contiguous virtual memory region to the virtual address space of a user-space process. This mapping is read-only, rejecting writable mapping requests; it is also a shared mapping, ensuring that subsequent kernel modifications to the shared header are immediately visible to the user-space process. The mapping also has flags set to prevent copying via fork and to prevent expansion. The mapping establishment process only involves page table entry binding and does not involve any data copying.

[0088] In the aforementioned block device snapshot method, at the kernel block layer, write requests to the block device are intercepted; based on the write request, the block to be written in the block device is determined, and the active bitmap is determined from two change bitmaps allocated in a contiguous virtual memory region; in the active bitmap, the bit information corresponding to the block to be written is determined as the target write identifier; the target write identifier is used to indicate that the block to be written has been written; in response to a snapshot creation request initiated by a user-space process, the active bitmap is determined as the snapshot bitmap, and the active bitmap is switched from the current change bitmap to another change bitmap; the user-space process is used to read the snapshot bitmap to obtain the block write status of the block device based on the mapping from the contiguous virtual memory region to the virtual address space of the user-space process. Compared with traditional technologies, this embodiment does not require byte-by-byte copying of the bitmap data block during snapshot creation, but completes the snapshot bitmap marking by switching the active bitmap from the current change bitmap to another change bitmap. Moreover, after the switch, the original active bitmap no longer receives newly arriving write requests, and there is no need to maintain the snapshot bitmap. Figure 1 By blocking subsequent write I / O, the efficiency of snapshot creation can be improved while ensuring the concurrent performance of the write path. On the other hand, this embodiment utilizes the direct mapping from contiguous virtual memory regions to the virtual address space of user space processes, so that user space processes can directly access kernel-mode bitmap data through the mapping when reading snapshot bitmaps, without having to execute additional data copy system calls from kernel mode to user mode. Thus, in both single and periodic snapshot scenarios, the overhead of data movement and context switching required when user space reads snapshot bitmaps can be effectively eliminated.

[0089] In one exemplary embodiment, such as Figure 4 As shown, in step S204, determining the active bitmap as the snapshot bitmap and switching the active bitmap from the current change bitmap to another change bitmap may include:

[0090] Step S401: Obtain the checkpoint occupancy identifier; the checkpoint occupancy identifier is used to indicate the current status of the checkpoint resource.

[0091] For example, after a user-space process initiates a snapshot creation request to the Linux kernel of the terminal, the terminal's kernel module can respond to the snapshot creation request by using an atomic comparison exchange operation (atomic_cmpxchg) to obtain the checkpoint occupancy flag (checkpoint_active). This checkpoint occupancy flag indicates whether the checkpoint resource (i.e., the critical section for performing the snapshot switch) is currently occupied. For example, checkpoint_active=1 indicates that the checkpoint resource is currently occupied, and checkpoint_active=0 indicates that the checkpoint resource is currently idle.

[0092] Step S402: If the checkpoint occupancy flag indicates that the checkpoint resource is currently idle, update the checkpoint occupancy flag to the target occupancy flag; the target occupancy flag is used to indicate that the checkpoint resource is currently occupied.

[0093] For example, when checkpoint_active=1, it indicates that the checkpoint resource is currently occupied. In this case, the terminal's kernel module can directly return a busy state (-EBUSY) to the user-space process, avoiding data inconsistency caused by concurrent switching. When checkpoint_active=0, it indicates that the checkpoint resource is currently idle. In this case, the terminal's kernel module can first set checkpoint_active to 1, successfully occupying the checkpoint resource, and then perform subsequent operations such as snapshot freezing and active bitmap switching. By setting the checkpoint occupancy flag, it can be ensured that only one CHECKPOINT operation enters the critical section at a time, thereby guaranteeing the atomicity of snapshot switching.

[0094] Step S403: Determine the active bitmap as the snapshot bitmap, and switch the active bitmap from the current change bitmap to another change bitmap to obtain the switched active bitmap.

[0095] For example, when checkpoint_active=0 (i.e., the checkpoint resource is currently idle), the terminal can perform a dual bitmap ping-pong switching operation after successfully occupying the checkpoint resource. Specifically, the terminal can freeze the current active bitmap (bitmap[active_idx]) as a snapshot bitmap (i.e., snap_idx=active_idx) and switch the kernel active index (active_idx) from its current value to another value (i.e., active_idx^=1), so that the active bitmap is switched from the current changed bitmap to another changed bitmap, and the switched active bitmap is obtained. For example, if the current active bitmap is bitmap[0], and the current value of the kernel active index is 0 (i.e., active_idx=0), after the terminal's kernel module successfully occupies the checkpoint resource, it can set snap_idx=0 to freeze the current bitmap[0] as a snapshot bitmap, and then switch active_idx from 0 to 1, at which point the active bitmap is switched to bitmap[1]. The above process does not involve copying bitmap data to the user space process, achieving zero-copy reading, and takes about 80~120 nanoseconds.

[0096] Step S404: Clear the bit information in the switched active bitmap.

[0097] For example, after the active bitmap switch is completed, the terminal can clear all bits in the switched active bitmap through the kernel module to prevent residual historical marker data from remaining in the switched active bitmap. Specifically, the terminal's kernel module can use a kernel bitmap clearing function (e.g., bitmap_zero) to set all bits in the switched active bitmap to 0, and simultaneously clear the dirty block counter (dirty_count). After the clearing operation is completed, the terminal does not release the checkpoint occupancy flag. After receiving a CONSUMED initiated by the user side, the terminal can release the checkpoint occupancy flag through the kernel module (e.g., by setting the checkpoint occupancy flag to 0). Here, the user side initiating CONSUMED indicates that the current user side has completed the consumption of the snapshot bitmap.

[0098] In this embodiment, the operations of obtaining the kernel active index, switching bitmaps, clearing the new active bitmap, and updating the shared snapshot index are performed under spinlock protection to ensure the continuity and indivisibility of these operations. After the bitmap switching is completed, the kernel module switches the block device's state from the tracking state to the consuming state.

[0099] In an exemplary embodiment, two change bitmaps and a shared header are allocated in a contiguous virtual memory region; the shared header includes a shared snapshot index. In step S403, the active bitmap is determined as the snapshot bitmap, and the active bitmap is switched from the current change bitmap to another change bitmap to obtain the switched active bitmap. This may include:

[0100] The kernel active index of the active bitmap is determined as the kernel snapshot index; the kernel active index is used to indicate the address information of the active bitmap in a contiguous virtual memory region; the active bitmap is switched from the current change bitmap to another change bitmap to obtain the switched active bitmap; the kernel snapshot index is written to the shared snapshot index to obtain the new shared snapshot index; the new shared snapshot index is used to indicate that the snapshot bitmap is the active bitmap before the switch.

[0101] For example, such as Figure 3 As shown, two change bitmaps (bitmap[0] and bitmap[1]) and a shared header are allocated in a contiguous virtual memory region; the fields in the shared header include the shared snapshot index (snap_index), checkpoint sequence number (checkpoint_seq), and mapping sequence number (mmap_seq); the shared snapshot index is used to indicate the offset address or index of the current snapshot bitmap in the contiguous virtual memory region. During the CHECKPOINT ping-pong switch, the terminal can, through the kernel module, first assign the kernel active index of the current active bitmap to the kernel snapshot index (i.e., snap_idx=active_idx), so that the current active bitmap is frozen as a snapshot bitmap; then perform pointer swapping, that is, switch the kernel active index from the current value to another value (i.e., active_idx^=1), so that the active bitmap is switched from the current change bitmap to another change bitmap, and the switched active bitmap is obtained; after the switch is completed, the shared header is updated. The update process of the shared header is as follows: First, the previously saved kernel snapshot index (snap_idx) is written into the snap_index field in the shared header (that is, header->snap_index=snap_idx). For example, if snap_idx=0, the snap_index in the updated shared header is set to 0, indicating that the current snapshot bitmap is bitmap[0]. Then, the checkpoint sequence number (checkpoint_seq) and the mapping sequence number (mmap_seq) in the shared header are each incremented by 1 (that is, header->checkpoint_seq+=1; header->mmap_seq+=1) to mark the snapshot bitmap version and detect mapping changes.

[0102] In an exemplary embodiment, step S204, which involves reading a snapshot bitmap to obtain the block write status of the block device based on the mapping from contiguous virtual memory regions to the virtual address space of user-space processes, may include:

[0103] Based on the mapping from contiguous virtual memory regions to the virtual address space of user-space processes, a new shared snapshot index and bitmap offset field are read from the shared header. The bitmap offset field is used to characterize the position offset of two changed bitmaps. Based on the new shared snapshot index and bitmap offset field, the snapshot bitmaps are located and traversed to obtain the bit information. The bit information is used to characterize the block write status of the block device. If it is determined that the preset backup replication conditions are met, the blocks that have been written to the block device are read based on the bit information.

[0104] For example, after a user-space process maps a contiguous virtual memory region to its own address space using mmap, it obtains a pointer to the shared header. When the user-space process needs to read a snapshot (e.g., after receiving a poll event or actively triggering it), it first reads the new shared snapshot index (snap_index) and bitmap offset fields (bitmap_0_offset, bitmap_1_offset, and bitmap_bytes) from the shared header based on this pointer. Then, it calculates the starting virtual address (snap_bm) of the snapshot bitmap based on this information, for example, snap_bm=(unsigned long*)((char*)hdr+hdr->bitmap_0_offset+hdr->snap_index*hdr->bitmap_bytes). Subsequently, the user-space process iterates through each bit in the snapshot bitmap to obtain the bit setting information for each bit. For each bit set to 1, the corresponding block is the data block that has been written since the last snapshot. When the preset backup replication conditions are met, such as being at the target time, at the target location, experiencing a target event, or receiving a signal from the user to trigger backup replication, the user space process can sequentially read these blocks of data that have been written and perform backup replication operations, such as replicate_block(block*block_size,block_size).

[0105] In this embodiment, since the mapping from contiguous virtual memory regions to the virtual address space of user-space processes is a shared mapping (MAP_SHARED), modifications to the snap_index by the kernel during CHECKPOINT are immediately reflected in the address space of the user-space process. Therefore, the user-space process can obtain the latest snapshot bitmap location without any system calls. The entire reading process involves only memory access and does not involve data copying, enabling efficient change block enumeration.

[0106] In an exemplary embodiment, two change bitmaps and a shared header are allocated in a contiguous virtual memory region; the shared header includes a base disk capacity. Step S401, obtaining the checkpoint occupancy identifier, may include:

[0107] The current disk capacity of the block device is compared with the baseline disk capacity. If the current disk capacity is inconsistent with the baseline disk capacity, the block device is determined to be in a fault state, and an error indication message is returned to the user space process. The user space process is used to determine that the block device is in a fault state based on the error indication message. If the current disk capacity is consistent with the baseline disk capacity, the checkpoint occupancy flag is read.

[0108] For example, such as Figure 3 As shown, two change bitmaps (bitmap[0] and bitmap[1]) and a shared header are allocated in a contiguous virtual memory region; the fields in the shared header include the base disk capacity (disk_size). This base disk capacity is initialized based on the disk capacity when the block device starts tracing. Before performing the CHECKPOINT ping-pong switch operation, the terminal's kernel module can read the current disk capacity of the block device through get_capacity(bdev->bd_disk)<<9, and then compare the current disk capacity with the base disk capacity in the shared header. If the two are inconsistent, it indicates that the disk capacity of the block device has changed (such as disk expansion or replacement). At this time, the mapping relationship corresponding to the bitmap has failed, and the device enters the FAULT state. Therefore, the terminal can return -EIO to the user space process through the kernel module. The user space process can determine the block device failure and take corresponding measures accordingly. If the two are consistent, the subsequent steps continue, such as reading the checkpoint occupancy flag (checkpoint_active) and performing atomic gating detection.

[0109] In an exemplary embodiment, step S404, clearing the bit information in the switched active bitmap, may include:

[0110] Upon receiving a snapshot consumption request initiated by a user-space process, after verifying that the checkpoint sequence number carried in the snapshot consumption request matches the current checkpoint sequence number, the checkpoint occupancy flag is released, and the active bitmap after the switch is cleared.

[0111] For example, after the user-space process completes reading and traversing the snapshot bitmap, it initiates a snapshot consumption request to the terminal's kernel module, for instance, via the iotcl system call, carrying the CDP_IOC_CONSUMED command. Upon receiving this snapshot consumption request, the terminal's kernel module verifies whether the checkpoint sequence number carried in the request matches the checkpoint sequence number stored in the current shared header. If they match, it releases the checkpoint occupancy flag (i.e., performs the checkpoint_active release operation) to allow the system to trigger the next snapshot creation process, and clears the switched active bitmap to zero (i.e., performs the bitmap_zero operation), enabling it to start tracking write operations after the next snapshot from a completely zero state. Subsequently, the terminal's kernel module can also switch the block device's state from CONSUMING back to TRACKING to restore normal dirty block tracking and snapshot creation capabilities.

[0112] In an exemplary embodiment, two change bitmaps and a shared header are allocated in a contiguous virtual memory region; the shared header includes a mapping sequence number. After step S204, the method may further include updating the mapping sequence number to obtain an updated mapping sequence number.

[0113] In step S204, based on the mapping from contiguous virtual memory regions to the virtual address space of user-space processes, the block write status of the block device is obtained by reading the snapshot bitmap, which may include:

[0114] The initial mapping sequence number is compared with the updated mapping sequence number. The initial mapping sequence number is determined when the mapping from the contiguous virtual memory region to the virtual address space of the user space process is established. If the initial mapping sequence number and the updated mapping sequence number are inconsistent, the block write status of the block device is obtained by reading the snapshot bitmap based on the mapping from the contiguous virtual memory region to the virtual address space of the user space process.

[0115] For example, such as Figure 3 As shown, two change bitmaps (bitmap[0] and bitmap[1]) and a shared header are allocated in a contiguous virtual memory region. The fields in the shared header include a shared snapshot index (snap_index) and a mapping sequence number (mmap_seq). The shared snapshot index is used to indicate the offset address or index of the current snapshot bitmap in the contiguous virtual memory region. The mapping sequence number is incremented with each CHECKPOINT operation (i.e., header->mmap_seq+=1). When the user space process establishes a mapping through mmap, it reads the current mmap_seq value from the shared header and saves it as the initial mapping sequence number. After that, when the user space process is ready to read the snapshot bitmap (e.g., after CHECKPOINT is triggered), the user space process first reads the current mmap_seq value from the shared header and compares the value with the locally saved initial mapping sequence number. If the two values ​​match, it means that no CHECKPOINT operation has occurred since the process established the mapping (or although it has occurred, the sequence number has not changed; in fact, each CHECKPOINT increments, so a discrepancy indicates a new snapshot). In this case, the user-space process can directly read the current snapshot bitmap. If the two values ​​match, it means that the kernel has executed one or more CHECKPOINT operations since the mapping was established, and the snapshot bitmap may have changed. The user-space process needs to read the snap_index based on the mapping from the contiguous virtual memory region to the user-space process's virtual address space, relocate and read the snapshot bitmap based on the snap_index, and then read the snapshot bitmap to obtain the block write status of the block device, avoiding reading outdated data.

[0116] In an exemplary embodiment, step S201, at the kernel block layer, intercepting write requests for block devices, may include:

[0117] If the version corresponding to the kernel block layer belongs to the first kernel version range, the first function pointer in the request queue structure of the block device is saved in the snapshot tracking device structure, and the first function pointer in the request queue structure of the block device is replaced with a custom write interception function; if the version corresponding to the kernel block layer belongs to the second kernel version range, the block device operation structure of the block device is copied to obtain a structure copy, and the second function pointer in the structure copy is replaced with a custom write interception function; based on the custom write interception function, write requests for the block device are intercepted at the kernel block layer.

[0118] In one specific implementation of this embodiment, the terminal can first determine whether the version corresponding to the kernel block layer belongs to the first kernel version range (e.g., Linux 3.10~5.8 kernel) or the second kernel version range (e.g., Linux 5.9 and above kernel) through the compile-time macro (CDP_USE_SUBMIT_BIO_HOOK). The core write tracing logic (e.g., parsing bio, calculating block number, setting bits in the active bitmap, etc.) is encapsulated in a unified function (e.g., cdp_track_bio_write), which is completely reused and unaware of the underlying hook type. When the version corresponding to the kernel block layer belongs to the first kernel version range, the block device's request_queue structure includes a pointer to the make_request_fn function. To address this, the terminal can store the `make_request_fn` function pointer from the `request_queue` structure of the block device in the `orig_make_request_fn` field of the `cdp_device` (snapshot tracking device) structure (for passthrough calls). The terminal can then replace the `make_request_fn` function pointer in the `request_queue` structure of the block device with a custom write interception function, such as injecting a custom `cdp_make_request_fn` into the I / O path. When a write I / O request arrives, the terminal's Linux kernel will call this custom function, thus intercepting the write request. For block device lookups, the `make_request_fn` function pointer can be used to perform an O(n) search in the global RCU (Read-Copy-Update) protection list. If the search fails, it will fall back to the queuedata fast path.

[0119] In another specific implementation of this embodiment, the terminal can first determine whether the version corresponding to the kernel block layer belongs to the first kernel version range (e.g., Linux 3.10~5.8 kernel) or the second kernel version range (e.g., Linux 5.9 and above kernel) through the compile-time macro (CDP_USE_SUBMIT_BIO_HOOK). The core write tracing logic (e.g., parsing bio, calculating block number, setting bits in the active bitmap, etc.) is encapsulated in a unified function (e.g., cdp_track_bio_write), which is completely reused and unaware of the underlying hook type. If the version corresponding to the kernel block layer belongs to the second kernel version range, this kernel version has removed the make_request_fn function pointer and instead uses the submit_bio function pointer. The terminal can obtain a copy of the gendisk block device operations (block_device_operations) structure (which can be denoted as bdev_fops_copy). When a write I / O request is submitted, the kernel calls the replaced submit_bio to intercept the write request.

[0120] In the field of computer data backup and disaster recovery, Change Block Tracking (CBT) technology is widely used to support continuous data protection and incremental backup. This technology intercepts write operations and records change block bitmaps on the block device I / O path, allowing the backup system to copy only data blocks that have changed since the last backup, thus significantly reducing I / O overhead and network traffic for incremental backups. Block devices include local disks (SATA / SAS / NVMe), Logical Volume Managers (LVM), device-mapper devices, multipath devices, and other storage devices that provide block-level I / O interfaces through request queues. SATA stands for Serial Advanced Technology Attachment; SAS stands for Serial Attached SCSI; SCSI stands for Small Computer System Interface; and NVMe stands for Non-Volatile Memory Express.

[0121] Currently, common CBT implementations fall into several categories. One approach maintains an active bitmap and a read-only bitmap at the operating system driver layer. When a snapshot is generated, the active bitmap is frozen and switched to read-only mode via specific control operations. Then, logical merging of the bitmaps of the original volume and the snapshot volume is performed to generate the master change bitmap. Another approach maintains a double-buffered area at the Linux kernel block layer. When switching snapshots, write mappings are copied to read mappings via memory copying. User space reads the snapshot bitmap using ioctl (input / output control, system call) combined with copy_to_user. Yet another approach implements write tracing by replacing the block device request handling function, but only maintains a single bitmap and lacks snapshot freezing and generational differentiation capabilities. Additionally, some approaches persistently store the change bitmap and manage multiple copies using counters, or maintain bitmap files at the Hypervisor layer for virtualization platforms, or implement dirty bitmap management in user space (such as QEMU) and provide operations through an API (Application Programming Interface). QEMU stands for Quick Emulator.

[0122] However, the aforementioned CBT implementations generally suffer from the following technical drawbacks. First, snapshot operations require data copying—whether it's a full memory copy of the bitmap or logical bitmap merging. For large-capacity storage devices (such as those at the tens of TB level), a single bitmap can reach hundreds of megabytes, with copying time reaching milliseconds, becoming a bottleneck for snapshot latency and directly affecting the accuracy of the Recovery Point Objective (RPO). Second, during bitmap copying or merging, new write I / O requests may concurrently arrive and modify unprocessed memory areas, leading to inconsistent snapshot results—the copied portion may not contain new writes, while the uncopied portion may contain them. Therefore, either lock synchronization is used, sacrificing concurrency performance, or fuzzy snapshots are accepted, sacrificing consistency. Third, when user space obtains snapshot data, it relies on system calls and data copying from the kernel to user space. Each snapshot consumption generates additional memory copying and context switching, accumulating significant overhead in periodic snapshot scenarios. Fourth, there is a lack of a unified and lock-free kernel-user space snapshot coordination mechanism. Kernel notifications to user space that a snapshot is ready typically require additional query interfaces or independent notification channels. User space must maintain its own snapshot version number and synchronize it with the kernel, increasing implementation complexity and the probability of errors. Fifth, solutions that partially rely on newer kernel features are difficult to be compatible with long-term support kernel versions (such as the 3.x and 4.x series) widely used in enterprise Linux distributions. There is a lack of a unified, compile-time adaptable dual-hook strategy, resulting in insufficient portability across kernel versions.

[0123] In this regard, in one exemplary embodiment, such as Figure 5 As shown, a block device change tracking zero-copy snapshot system is also provided. This system may include: a write request interception module 501, a dual bitmap management module 502, a memory mapping module 503, a checkpoint control module 504, a device lifecycle management module 505, and a cross-version compatibility layer 506. Wherein:

[0124] The write request interception module 501 is used to intercept write requests to block devices at the kernel block layer of the Linux operating system.

[0125] For example, the write request interception module 501 employs two optional interception mechanisms. These two mechanisms are automatically selected through a compile-time macro (CDP_USE_SUBMIT_BIO_HOOK). The upper-layer tracing logic (e.g., cdp_track_bio_write) is fully reused, and the underlying hook type is not recognized, ensuring that intercepted write requests can be processed uniformly. Wherein:

[0126] Mechanism 1 (make_request_fn replacement): Applicable to Linux kernels 3.10~5.8. By replacing the make_request_fn function pointer in the request_queue structure of the block device with a custom cdp_make_request_fn, the custom cdp_make_request_fn is injected into the I / O path. The original function pointer (i.e., the make_request_fn function pointer) is stored in the orig_make_request_fn field of the cdp_device structure for passthrough calls. Block device lookups can be performed in O(n) time using the make_request_fn function pointer in the global RCU protection list; if the lookup fails, it falls back to the queuedata fast path.

[0127] Mechanism 2 (submit_bio replacement): Applicable to Linux kernels 5.9 and above, which have removed the make_request_fn function pointer. By copying the gendisk's block_device_operations structure, the submit_bio function pointer is replaced with a custom cdp_submit_bio, and the cdp_device structure is associated via gendisk->private_data. The block device's commit entry identifier (e.g., bd_has_submit_bio) is set, causing the block layer to route write requests to the replaced commit function.

[0128] The dual bitmap management module 502 is used to maintain two change bitmaps of equal size and a shared header, and allocates these two change bitmaps and the shared header in a contiguous virtual memory region.

[0129] For example, the dual bitmap management module 502 uses the vmalloc_user interface to allocate a shared header and two equally sized change bitmaps (which can be denoted as bitmap[0] and bitmap[1]) in a contiguous virtual memory region, such as... Figure 3 As shown, this ensures that the contiguous virtual memory region can be mapped to the virtual address space of the user space process via remap_vmalloc_range. The memory layout of the contiguous virtual memory region is as follows: a shared header filled with page alignment (PAGE_ALIGN) at the beginning, followed by bitmap[0] and bitmap[1] in sequence.

[0130] Each bit corresponds to a block on the disk (64KB by default), and the length of the unsigned long array is calculated using the BITS_TO_LONGS macro. The shared header includes the following key fields: magic (magic number, value 0x43445001, used for memory verification), snap_index (shared snapshot index, value 0 or 1, used to indicate the current snapshot bitmap), bitmap_0_offset / bitmap_1_offset (indicating the offsets of the two bitmaps within a contiguous region, for user-space processes to locate the bitmap), checkpoint_seq (checkpoint sequence number), mmap_seq (mapping sequence number, used to detect whether CHECKPOINT occurs after mmap), and fields such as disk_size (base disk capacity), block_size (base block size), nr_blocks (number of base blocks), and bitmap_bytes (number of bytes in the base bitmap), which record disk and bitmap geometry parameters. Each bit corresponds to a data block on the disk (the default block size is 64KB), and the bitmap length is calculated as the length of an unsigned long integer array using the BITS_TO_LONGS macro. This module also maintains an active_idx (kernel active index) to identify which bitmap is currently active (i.e., the target bitmap for write markers).

[0131] The memory mapping module 503 is used to map contiguous virtual memory regions at the kernel level to the virtual address space of user-space processes.

[0132] For example, the memory mapping module 503 is used to map data to a character device (device node is / dev / cdp_). <name>The `mmap` file operation maps the aforementioned contiguous virtual memory region in the kernel to the virtual address space of the user-space process. The specific workflow of this module includes: responding to the `mmap(NULL, total_size, PROT_READ, MAP_SHARED, fd, 0)` call initiated by the user process; performing mapping range verification in the kernel-side `cdp_mmap` callback; rejecting writable mapping requests (returning -EPERM if `VM_WRITE` is set); and setting the `VM_DONTCOPY` and `VM_DONTEXPAND` flags (disabling copy-on-write during fork and disabling extension). Subsequently, `remap_vmalloc_range` is called to bind the physical pages in the `vmalloc` region page by page to page table entries (PTEs) in the user process's virtual address space. Because of the `MAP_SHARED` shared mapping, subsequent kernel modifications to shared header fields (such as `snap_index` flipping) are immediately visible to user space without any system calls. The entire mapping process only binds page table entries and does not generate any data copy, achieving zero-copy memory sharing.

[0133] The checkpoint control module 504 is used to respond to snapshot creation requests initiated by user-space processes and to achieve atomic switching of snapshots.

[0134] For example, the checkpoint control module 504 is used to perform atomic snapshot switching in response to a CHECKPOINT (i.e., CDP_IOC_CHECKPOINT) ioctl request initiated by a user-space process. Specifically, as... Figure 6 As shown, firstly, a status check is performed to confirm that the current device status must be TRACKING; otherwise, -EINVAL is returned. Then, a health check is performed, which reads the current disk capacity using get_capacity(bdev->bd_disk)<<9 and compares it with header->disk_size in the shared header. If they are inconsistent, the device enters the FAULT state and -EIO is returned. After the health check passes, the checkpoint occupancy flag is obtained through an atomic comparison swap operation (atomic_cmpxchg(&checkpoint_active,0,1)). If the current value is not 0 (indicating that it is occupied), -EBUSY is returned; if it is 0, it is atomically updated to 1 (occupancy status) and the device enters the critical section. A ping-pong switch is performed under spinlock protection: the current active index `active_idx` is saved as the snapshot index `snap_idx`, then the active index is flipped (`active_idx^=1`), freezing the old active bitmap as the snapshot bitmap, and the other becomes the new active bitmap; after the switch is complete, `bitmap_zero` is called to clear all bits in the new active bitmap and set the dirty block counter `dirty_count` to zero; then the shared header field is updated, and the code `header->snap_index=snap_idx;header->checkpoint_seq+=1;header->mmap_seq+=1;` is executed sequentially, and finally the device state is switched from `TRACKING` to `CONSUMING`. This embodiment avoids data copying of the snapshot bitmap by switching between the two bitmap roles, thereby reducing snapshot calibration overhead; the snapshot processing time no longer increases linearly with the amount of snapshot bitmap copied.

[0135] To further illustrate the correctness of this system in concurrent scenarios, the atomicity and race-free properties of the two-bitmap ping-pong switching are formally demonstrated below. For ease of description, three core operations are defined:

[0136] Write operation W: Triggered by write request interception module 501, execute set_bit(bitmap[active_idx], block_no), which always operates on the bitmap pointed to by the current active index (active_idx).

[0137] Checkpoint operation C: Executed by checkpoint control module 504, under spinlock protection, the code "snap_idx=active_idx;active_idx^=1;header->snap_index=snap_idx;" is executed sequentially, which atomically freezes the current active bitmap into a snapshot bitmap and flips the active index.

[0138] Read operation R: The user space process reads header->snap_index through memory mapping module 503 and iterates through the set bits in bitmap[snap_index].

[0139] The three concurrent scenarios of this system are as follows:

[0140] Scenario 1: Write operation W and checkpoint operation C occur concurrently. Write operation W always operates on the bitmap currently pointed to by active_idx, while checkpoint C atomically swaps active_idx. Consider two sub-timing sequences:

[0141] Sub-scenario 1a: If W executes before C, W will be set in the old active bitmap (such as bitmap[0]). Then C will flip active_idx from 0 to 1, and the old active bitmap bitmap[0] will become the snapshot bitmap. W's mark will be correctly preserved in the snapshot bitmap.

[0142] Sub-scenario 1b: C executes before W. After C completes the swap, active_idx has become 1. W is then set in bitmap[1], while the snapshot bitmap (original bitmap[0]) is unaffected.

[0143] Conclusion: Regardless of timing, writes always enter the correct active bitmap, and snapshots always freeze the correct historical bitmap.

[0144] Scenario 2: Concurrent write operation W and read operation R. Write operation W operates on bitmap[active_idx], and read operation R operates on bitmap[snap_idx]. Because ping-pong switching ensures that active_idx and snap_idx are always different, W and R operate on different physical memory regions, thus safe concurrency is possible without any lock synchronization. The only boundary case is when checkpoint operation C is in progress (active_idx is being flipped). In this case, the snap_index read by R is either the old value (previous snapshot) or the new value (new snapshot), both consistent snapshot states, avoiding any intermediate inconsistent states.

[0145] Scenario 3: Read operation R and checkpoint operation C run concurrently. Read operation R reads header->snap_index without locking, while checkpoint operation C modifies snap_index under spinlock protection. User space locates the snapshot bitmap through snap_index and can confirm the snapshot version by combining it with checkpoint_seq. Therefore, the snap_index value seen by R is always the complete value before or after C's execution, and it will not see partially flipped intermediate bit patterns.

[0146] Based on the above analysis of concurrent scenarios, this system possesses the following formal properties:

[0147] Property 1 (Snapshot Consistency): For any checkpoint operation C_i, the frozen snapshot bitmap contains only the dirty blocks marked by all write operations after C_{i-1} and before C_i.

[0148] Property 2 (Write Isolation): The scope of any write operation W's set_bit is uniquely limited to the currently active bitmap and does not share storage with any snapshot bitmap.

[0149] Property 3 (No need for long-term blocking of write I / O for copying snapshot bitmaps): No global locks are required between write operation W and read operation R, between write operation W and checkpoint operation C, and between read operation R and checkpoint operation C. The only spinlock used in checkpoint operation C protects only active_idx swapping and header updates. The critical section only protects lightweight operations such as index swapping and header updates, which take very short time and have a negligible impact on write latency.

[0150] Property 4 (Zero-copy invariance): Throughout the entire data path from snapshot creation at a checkpoint to snapshot reading in user space, bitmap data is never copied in physical memory. Snapshot "creation" is a logical operation (pointer assignment), and snapshot "reading" is a direct memory access (mmap page table entry binding); neither of these operations moves the data.

[0151] The Device Lifecycle Management Module 505 is used to manage the complete lifecycle of block devices.

[0152] For example, the device lifecycle management module 505 is used to employ a root device ( / dev / cdp) plus a child device ( / dev / cdp_ <name>This module employs a two-tiered model to manage the complete lifecycle of block devices. The root device only accepts SETUPioctl and module-level STATUS queries; sub-devices provide all operation interfaces, including mmap, poll, CHECKPOINT, CONSUMED, RESET_TRACKING, DESTROY, STATUS, and INFO. poll returns a readable event when dirty blocks are marked (dirty block count greater than zero). This module maintains a device state machine, with states including STAGING (preparation phase), TRACKING (normal tracking state, CHECKPOINT can be executed), CONSUMING (consuming state, indicating that a snapshot is being read by the user), and FAULT (failure state, entered when the disk is removed or expanded). Devices on abnormal paths can enter the FAULT state from any state and subsequently recover via DESTROY or RESET_TRACKING. This module also defines device naming rules: remove the / dev / prefix from the target block device path and replace any remaining / with -; for / dev / mapper / devices, remove the / dev / mapper / prefix. For example, / dev / sda1 will be renamed to cdp_sda1 and a device node / dev / cdp_sda1 will be created, while / dev / mapper / mpatha will be renamed to cdp_mpatha and a device node / dev / cdp_mpatha will be created.

[0153] Cross-version compatibility layer 506 is used to detect macros through compile-time features to achieve cross-Linux kernel version compatibility.

[0154] For example, the `CDP_USE_SUBMIT_BIO_HOOK` macro is used to detect the kernel version (using the `submit_bio` hook when the kernel version is Linux 5.9 or higher, and the `make_request_fn` hook when the kernel version is below Linux 5.9); the `CDP_HAVE_BDEV_HANDLE` macro is used to detect the availability of the `bdev_open_by_path` interface (applicable to kernel versions greater than or equal to 6.5); the `CDP_HAVE_BLOCK_NOTIFIER` macro is used to detect the availability of `register_block_notifier`; in addition, conditional compilation is performed on `proc_ops` and `file_operations`, and conditional compilation adaptation is provided for the `vm_flags_set` macro. Through the above compatibility layer, this system can cover all major kernel versions from Linux 3.10 to 6.x, including mainstream enterprise distributions such as CentOS 7 / 8 / 9 and Ubuntu 14.04 / 18.04 / 20.04 / 22.04, ensuring that the upper-layer logic runs stably and behaves consistently in different kernel environments.

[0155] To more clearly illustrate the collaborative effect of the above modules, the following description provides an example of the application of this system in a specific scenario.

[0156] Application Example 1: Performance Comparison under Multiple Disk Scale

[0157] The snapshot performance of this system under different disk capacities is as follows. Assuming the block size is fixed at 64KB:

[0158] (a) For a 1TB disk: the total number of data blocks (nr_blocks) is 16,777,216, and the size of a single bitmap is 2MB. The system takes approximately 80 to 120 nanoseconds to perform a single CHECKPOINT operation; while using a traditional method (such as blksnap) to copy 2MB of bitmap data using memcpy takes approximately 30 to 50 microseconds. This represents a performance improvement of approximately 250 to 400 times.

[0159] (b) For a 10TB disk: the total number of data blocks is 167,772,160, the size of a single bitmap is 20MB, and the total size mapped via mmap (including two bitmaps and a shared header) is approximately 40MB. The system's execution time for CHECKPOINT remains approximately 80 to 120 nanoseconds (including only spinlock acquisition, pointer assignment, and spinlock release); while the traditional solution takes approximately 300 to 500 microseconds to copy 20MB of bitmap data using memcpy. This system represents a performance improvement of approximately 3000 to 4000 times.

[0160] (c) For a 64TB disk: the total number of data blocks is 1,073,741,824, and the size of a single bitmap is 128MB. The execution time of CHECKPOINT in this system is still in the nanosecond range, independent of the bitmap size. Figure 7 The example shown is Solution 1; while the traditional solution takes approximately 2 to 3 milliseconds to copy 128MB of bitmap data using memcpy. This system achieves a performance improvement of approximately 20,000 to 30,000 times. Figure 7 Schemes 2 and 3 are shown.

[0161] As can be seen from the above data, the snapshot time of this system is independent of the disk capacity and has a time complexity of O(1); while the snapshot time of the traditional scheme increases linearly with the disk capacity and has a time complexity of O(n).

[0162] Application Example 2: Typical Flow of a User-Space Process Reading a Snapshot Bitmap

[0163] In an exemplary use case, a user-space process implements zero-copy reading of a snapshot bitmap using the following pseudocode flow:

[0164] int fd = open(" / dev / cdp_sda", O_RDWR);

[0165] struct cdp_info info = { .query_items = CDP_INFO_MMAP_SIZE};

[0166] ioctl(fd, CDP_IOC_INFO, &info);

[0167] struct cdp_tracking_header *hdr = mmap(NULL, info.mmap_size,

[0168] PROT_READ, MAP_SHARED, fd, 0);

[0169] while (running) {

[0170] poll(fd, EPOLLIN, timeout_ms);

[0171] ioctl(fd, CDP_IOC_CHECKPOINT, 0); / / Atomic snapshot (pointer swapping in nanoseconds), CHECKPOINT returns the sequence number of this checkpoint.

[0172] ioctl(fd, CDP_IOC_CONSUMED, checkpoint_seq); / / Carries the checkpoint sequence number to confirm that the snapshot being consumed is the same snapshot.

[0173] unsigned long *snap_bm = (unsigned long *)((char *)hdr

[0174] + hdr->bitmap_0_offset + hdr->snap_index * hdr->bitmap_bytes);

[0175] for_each_set_bit(block, snap_bm, hdr->nr_blocks)

[0176] replicate_block(block * hdr->block_size, hdr->block_size);

[0177] ioctl(fd, CDP_IOC_CONSUMED);

[0178] }

[0179] In this process: the user process first opens the character device file of the target device, obtains the size of the mapped region via the INFO ioctl, and then calls mmap to map the entire contiguous region (header + double bitmap) into its own address space. In the loop, the user process waits for changes to occur or for conditions to trigger a checkpoint via poll; when poll returns a ready event, the user process initiates a CHECKPOINT ioctl to trigger an atomic snapshot switch, generating a new snapshot version; subsequently, by reading the snap_index field in the shared header and combining it with bitmap_0_offset and bitmap_bytes, it calculates the virtual address of the current snapshot bitmap, directly traverses all set bits in the bitmap, and performs a copy operation on each changed block; finally, it notifies the kernel via the CONSUMED ioctl that the snapshot has been consumed.

[0180] Application Example 3: Cross-kernel version deployment example

[0181] This system, through cross-version compatibility layer 506, can be seamlessly deployed on different Linux distributions and kernel versions. For example, on CentOS 7 (kernel version 3.10), the macro `CDP_USE_SUBMIT_BIO_HOOK` is not defined during compilation, and the system automatically uses the `make_request_fn` replacement scheme (i.e., scheme A in write request interception module 501) for I / O interception. On Ubuntu 22.04 (kernel version 5.15), this macro is automatically defined, and the system uses the `submit_bio` replacement scheme (i.e., scheme B in write request interception module 501) for I / O interception. Under both deployment methods, the upper-layer tracing logic (`cdp_track_bio_write`) remains completely unchanged, ensuring consistent behavior without any code modification.

[0182] This embodiment proposes a block device change tracking zero-copy snapshot system. By using dual bitmap ping-pong switching in conjunction with the flipping of the shared header snap_index pointer, the snapshot operation completely eliminates the traditional bitmap data copying, reducing the time consumption from milliseconds to nanoseconds. In large-capacity disk scenarios, this can reduce snapshot processing overhead, and the snapshot time is completely decoupled from the disk capacity, exhibiting O(1) complexity. The set_bit operation in the write path always operates on the currently active bitmap, while the snapshot path only freezes the old active bitmap and flips the pointer. The two operate on different areas in physical memory, requiring no locks to protect snapshot consistency. Role switching and necessary cleanup are completed through short critical sections, avoiding long-term lock holding caused by bitmap copying. The user space maps the header and dual bitmaps to its own address space in a single mmap. After CHECKPOINT, it is only necessary to reread the snap_index in the mapped memory to locate the new snapshot bitmap, without needing copy_to_us. The `er` or `read` system call shares the `snap_index` header as a key positioning field between the kernel and user space, working in conjunction with fields such as the checkpoint sequence number and status, without requiring additional notification channels or version number negotiation. The system covers all versions of Linux from 3.10 to 6.x through compile-time feature detection and a dual-hook strategy (`make_request_fn` + `submit_bio`), ensuring consistent behavior of upper-layer tracing logic across different kernel environments. Memory management employs `vmalloc_user` in conjunction with an on-demand page fault allocation strategy, allocating physical memory only when a write request first sets its bit, and avoiding copying of the snapshot bitmap between kernel and user space through shared mapping. Furthermore, each `CHECKPOINT` operation embeds a disk capacity comparison mechanism, automatically detecting disk expansion or removal events and triggering the `FAULT` state, without requiring a separate monitoring thread or periodic polling.

[0183] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0184] Based on the same inventive concept, this application also provides a block device snapshot apparatus for implementing the block device snapshot method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more block device snapshot apparatus embodiments provided below can be found in the limitations of the block device snapshot method described above, and will not be repeated here.

[0185] In one exemplary embodiment, such as Figure 8 As shown, a block device snapshot apparatus is provided, comprising the following modules:

[0186] Interception module 801 is used to intercept write requests to block devices at the kernel block layer.

[0187] The first determining module 802 is used to determine the block to be written in the block device according to the write request, and to determine the active bitmap in two change bitmaps allocated in a contiguous virtual memory region.

[0188] The second determining module 803 is used to determine the bit information corresponding to the block to be written as the target write identifier in the active bitmap; the target write identifier is used to indicate that the block to be written has been written.

[0189] The switching module 804 is used to respond to a snapshot creation request initiated by the user space process, determine the active bitmap as the snapshot bitmap, and switch the active bitmap from the current change bitmap to another change bitmap; the user space process is used to read the snapshot bitmap to obtain the block write status of the block device based on the mapping of the contiguous virtual memory region to the virtual address space of the user space process.

[0190] In an exemplary embodiment, the switching module 804 is further configured to obtain a checkpoint occupancy identifier; the checkpoint occupancy identifier is used to indicate the current state of the checkpoint resource; if the checkpoint occupancy identifier indicates that the checkpoint resource is currently in an idle state, the checkpoint occupancy identifier is updated to a target occupancy identifier; the target occupancy identifier is used to indicate that the checkpoint resource is currently in an occupied state; the active bitmap is determined as a snapshot bitmap, the active bitmap is switched from the current change bitmap to another change bitmap to obtain the switched active bitmap; and the bit information in the switched active bitmap is cleared.

[0191] In an exemplary embodiment, two change bitmaps and a shared header are allocated in a contiguous virtual memory region; the shared header includes a shared snapshot index. The switching module 804 is further configured to determine the kernel active index of the active bitmap as the kernel snapshot index; the kernel active index indicates the address information of the active bitmap within the contiguous virtual memory region; switch the active bitmap from the current change bitmap to another change bitmap to obtain the switched active bitmap; write the kernel snapshot index to the shared snapshot index to obtain a new shared snapshot index; the new shared snapshot index indicates that the snapshot bitmap is the active bitmap before the switch.

[0192] In an exemplary embodiment, the switching module 804 is further configured to read a new shared snapshot index and bitmap offset field from the shared header based on the mapping from the contiguous virtual memory region to the virtual address space of the user space process; the bitmap offset field is used to characterize the position offset of two changed bitmaps; based on the new shared snapshot index and bitmap offset field, locate and traverse the snapshot bitmap to obtain setting information; the setting information is used to characterize the block write status of the block device; and if it is determined that the preset backup replication conditions are met, read the blocks that have been written in the block device based on the setting information.

[0193] In an exemplary embodiment, two change bitmaps and a shared header are allocated in a contiguous virtual memory region; the shared header includes a base disk capacity. The switching module 804 is further configured to compare the current disk capacity of the block device with the base disk capacity; if the current disk capacity is inconsistent with the base disk capacity, determine that the block device has entered a fault state and return error indication information to the user space process; the user space process is configured to determine that the block device has entered a fault state based on the error indication information; if the current disk capacity is consistent with the base disk capacity, read the checkpoint occupancy identifier.

[0194] In an exemplary embodiment, the switching module 804 is further configured to, upon receiving a snapshot consumption request initiated by a user space process, verify that the checkpoint sequence number carried in the snapshot consumption request is consistent with the current checkpoint sequence number, release the checkpoint occupancy flag, and clear the active bitmap after the switch.

[0195] In an exemplary embodiment, two change bitmaps and a shared header are allocated in a contiguous virtual memory region; the shared header includes a mapping sequence number. The switching module 804 is further configured to update the mapping sequence number after switching the active bitmap from the current change bitmap to another change bitmap, obtaining an updated mapping sequence number. The switching module 804 is also configured to compare the initial mapping sequence number with the updated mapping sequence number; the initial mapping sequence number is determined when establishing the mapping from the contiguous virtual memory region to the virtual address space of the user space process; if the initial mapping sequence number and the updated mapping sequence number are inconsistent, the block write status of the block device is obtained by reading the snapshot bitmap according to the mapping from the contiguous virtual memory region to the virtual address space of the user space process.

[0196] In an exemplary embodiment, the interception module 801 is further configured to: when the version corresponding to the kernel block layer belongs to the first kernel version range, save the first function pointer in the request queue structure of the block device in the snapshot tracking device structure, and replace the first function pointer in the request queue structure of the block device with a custom write interception function; when the version corresponding to the kernel block layer belongs to the second kernel version range, copy the block device operation structure of the block device to obtain a structure copy, and replace the second function pointer in the structure copy with a custom write interception function; and based on the custom write interception function, intercept write requests for the block device at the kernel block layer.

[0197] Each module in the aforementioned block device snapshot device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0198] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 9 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a block device snapshot method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0199] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0200] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0201] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0202] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0203] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0204] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0205] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0206] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.< / name> < / name> < / name>

Claims

1. A block device snapshot method, characterized in that, The method includes: At the kernel block level, intercept write requests to block devices; Based on the write request, determine the block to be written in the block device, and determine the active bitmap in two change bitmaps allocated in a contiguous virtual memory region; In the active bitmap, the bit information corresponding to the block to be written is determined as the target write identifier; the target write identifier is used to indicate that the block to be written has been written. In response to a snapshot creation request initiated by a user-space process, the active bitmap is determined as the snapshot bitmap, and the active bitmap is switched from the current change bitmap to another change bitmap; the user-space process is used to read the snapshot bitmap to obtain the block write status of the block device based on the mapping of the contiguous virtual memory region to the virtual address space of the user-space process.

2. The method according to claim 1, characterized in that, The step of determining the active bitmap as a snapshot bitmap and switching the active bitmap from the current change bitmap to another change bitmap includes: Obtain the checkpoint occupancy identifier; the checkpoint occupancy identifier is used to indicate the current status of the checkpoint resource; If the checkpoint occupancy flag indicates that the checkpoint resource is currently idle, the checkpoint occupancy flag is updated to the target occupancy flag; the target occupancy flag is used to indicate that the checkpoint resource is currently occupied. The active bitmap is determined as a snapshot bitmap, and the active bitmap is switched from the current change bitmap to another change bitmap to obtain the switched active bitmap; Clear the bit information in the switched active bitmap.

3. The method according to claim 2, characterized in that, The two change bitmaps and the shared header are allocated in the contiguous virtual memory region; the shared header includes a shared snapshot index. The step of determining the active bitmap as a snapshot bitmap and switching the active bitmap from the current change bitmap to another change bitmap to obtain the switched active bitmap includes: The kernel active index of the active bitmap is determined as the kernel snapshot index; the kernel active index is used to indicate the address information of the active bitmap in the contiguous virtual memory region; The active bitmap is switched from the current change bitmap to another change bitmap to obtain the switched active bitmap; The kernel snapshot index is written into the shared snapshot index to obtain a new shared snapshot index; the new shared snapshot index is used to indicate that the snapshot bitmap is the active bitmap before the switch.

4. The method according to claim 3, characterized in that, The step of reading the snapshot bitmap to obtain the block write status of the block device based on the mapping from the contiguous virtual memory region to the virtual address space of the user space process includes: Based on the mapping from the contiguous virtual memory region to the virtual address space of the user space process, the new shared snapshot index and bitmap offset field are read from the shared header; the bitmap offset field is used to characterize the position offset of the two changed bitmaps; Based on the new shared snapshot index and the bitmap offset field, the snapshot bitmap is located and traversed to obtain the bit setting information; the bit setting information is used to characterize the block write status of the block device. If the preset backup and copy conditions are met, the blocks that have been written to the block device are read according to the setting information.

5. The method according to claim 2, characterized in that, The two change bitmaps and the shared header are allocated in the contiguous virtual memory region; the shared header includes the base disk capacity. The process of obtaining the checkpoint occupancy identifier includes: Compare the current disk capacity of the block device with the baseline disk capacity; If the current disk capacity is inconsistent with the baseline disk capacity, the block device is determined to be in a fault state, and an error indication message is returned to the user space process; the user space process is used to determine that the block device is in a fault state based on the error indication message; If the current disk capacity is the same as the baseline disk capacity, read the checkpoint occupancy flag.

6. The method according to claim 2, characterized in that, The step of clearing the bit information in the switched active bitmap includes: Upon receiving a snapshot consumption request initiated by a user space process, after verifying that the checkpoint sequence number carried in the snapshot consumption request is consistent with the current checkpoint sequence number, the checkpoint occupancy flag is released, and the switched active bitmap is cleared.

7. The method according to claim 1, characterized in that, The contiguous virtual memory region is allocated with the two change bitmaps and a shared header; the shared header includes a mapping sequence number. After switching the active bitmap from the current change bitmap to another change bitmap, the method further includes: updating the mapping sequence number to obtain the updated mapping sequence number; The step of reading the snapshot bitmap to obtain the block write status of the block device based on the mapping from the contiguous virtual memory region to the virtual address space of the user space process includes: The initial mapping number is compared with the updated mapping number; the initial mapping number is determined when establishing the mapping from the contiguous virtual memory region to the virtual address space of the user space process. If the initial mapping sequence number is inconsistent with the updated mapping sequence number, the block write status of the block device is obtained by reading the snapshot bitmap based on the mapping from the contiguous virtual memory region to the virtual address space of the user space process.

8. The method according to any one of claims 1 to 7, characterized in that, The interception of write requests to block devices at the kernel block layer includes: If the version corresponding to the kernel block layer belongs to the first kernel version range, the first function pointer in the request queue structure of the block device is stored in the snapshot tracking device structure, and the first function pointer in the request queue structure of the block device is replaced with a custom write interception function. If the version corresponding to the kernel block layer belongs to the second kernel version range, copy the block device operation structure of the block device to obtain a structure copy, and replace the second function pointer in the structure copy with a custom write interception function; Based on the custom write interception function, write requests for the block device are intercepted at the kernel block layer.

9. A block device snapshot device, characterized in that, The device includes: The interception module is used to intercept write requests to block devices at the kernel block layer; The first determining module is used to determine the block to be written in the block device according to the write request, and to determine the active bitmap in two change bitmaps allocated in a contiguous virtual memory region; The second determining module is used to determine the bit information corresponding to the block to be written as the target write identifier in the active bitmap; the target write identifier is used to indicate that the block to be written has been written. The switching module is used to respond to a snapshot creation request initiated by the user space process, determine the active bitmap as the snapshot bitmap, and switch the active bitmap from the current change bitmap to another change bitmap; the user space process is used to read the snapshot bitmap to obtain the block write status of the block device according to the mapping of the contiguous virtual memory region to the virtual address space of the user space process.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.

Images