Snapshot processing method, device, storage medium, and program product

Abstract

Embodiments of the present application provide a snapshot processing method, device, storage medium and program product. In the snapshot data processing method, after uploading the snapshot data corresponding to the current snapshot operation of the target storage volume, the write-in node can delete the shadow file corresponding to the target storage volume in the case that there is no unmerged update data in the target storage volume. Before deleting the shadow file, the first write-in node can create a snapshot mutual exclusion identifier in the target storage volume, which can block the next snapshot operation of the target storage volume within a set time range. Further, other write-in nodes in the distributed file system cannot perform snapshot operation on the target storage volume within the set time range, reducing the probability that the shadow file to be deleted by the write-in node is reused by the next snapshot operation, thereby reducing the risk of data loss caused by the deletion operation of the write-in node on the shadow file, and being beneficial to improving the accuracy of the update data written into the target storage volume during the next snapshot.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a snapshot processing method, device, storage medium, and program product. Background Technology

[0002] In some distributed file system applications, block storage services for storage volumes can be provided based on the Random Access File (RAF) class. RAF allows reading and writing files in a random access manner. Files accessible through the RAF class (hereinafter referred to as RAF files) support update semantics with specified offsets, allowing write nodes to perform write operations at any position within the RAF file. Block storage services can implement read-only snapshots (ROW) based on RAF files. During the implementation of read-only snapshots, after creating a snapshot of the storage volume, write nodes in the distributed file system can write updated data for the storage volume to the RAF file. After performing the storage volume snapshot operation, the write nodes can merge the updated data in the RAF file with the data in the storage volume.

[0003] In scenarios where distributed file systems fail, multiple write nodes may simultaneously operate on the RAF file corresponding to the same storage volume. When multiple write nodes operate on the RAF file concurrently, it can lead to RAF file loss or data corruption within the RAF file, thus affecting the accuracy of newly written data during snapshot operations. Therefore, a new solution is needed. Summary of the Invention

[0004] This application provides a snapshot processing method, apparatus, storage medium, and program product to improve the accuracy of updated data written to a target storage volume after a snapshot.

[0005] This application provides a snapshot processing method applied to a first write node in a distributed file system, comprising: after uploading snapshot data corresponding to the current snapshot operation of a target storage volume, based on the bitmap corresponding to the target storage volume, if it is determined that the target storage volume does not have unmerged data blocks, then adding a snapshot mutual exclusion flag to the target storage volume, the snapshot mutual exclusion flag being used to block the next snapshot operation for the target storage volume within a set time range; within the set time range, deleting the shadow file corresponding to the target storage volume, the shadow file being used to store the updated data of the target storage volume during the current snapshot operation.

[0006] Optionally, it further includes: responding to a snapshot event of the target storage volume, determining whether a historical snapshot mutual exclusion identifier exists on the target storage volume, wherein the historical snapshot mutual exclusion identifier was created after the last snapshot operation of the target storage volume; if no historical snapshot mutual exclusion identifier exists, then creating snapshot data corresponding to the current snapshot operation of the target storage volume, and uploading the snapshot data.

[0007] Optionally, it also includes: if a historical snapshot mutual exclusion flag exists, then blocking the current snapshot operation of the target storage volume.

[0008] Optionally, deleting the shadow file corresponding to the target storage volume includes: determining whether the target storage volume is occupied by the second write node based on the current ownership verification file on the target storage volume; if the target storage volume is not occupied by the second write node, then deleting the shadow file corresponding to the target storage volume.

[0009] Optionally, the method further includes: suspending input / output operations on the target storage volume before deleting the shadow file; and resuming input / output operations on the target storage volume after deleting the shadow file.

[0010] Optionally, it also includes: if the target storage volume is occupied by a second write node, then the deletion operation of the shadow file is turned off.

[0011] Optionally, before deleting the shadow file corresponding to the target storage volume, the method further includes: when occupying the target storage volume, if a first ownership verification file created by a third write node exists on the target storage volume, then the first ownership verification file is deleted, and a second ownership verification file is created on the target storage volume; based on the current ownership verification file on the target storage volume, determining whether the target storage volume is occupied by the second write node includes: determining whether the current ownership verification file on the target storage volume is consistent with the second ownership verification file; if consistent, then determining that the target storage volume is not occupied by the second write node; if inconsistent, then determining that the target storage volume has been occupied by the second write node.

[0012] Optionally, the second ownership verification file is generated based on the unique identification information of the first write node.

[0013] This application also provides a snapshot processing method applied to a first write node in a distributed file system, comprising: after uploading the snapshot data corresponding to the current snapshot operation of the target cloud disk, if it is determined that the target cloud disk does not have unmerged data blocks, then adding a snapshot mutual exclusion flag to the target cloud disk, the snapshot mutual exclusion flag being used to block the next snapshot operation for the target cloud disk within a set time range; within the set time range, deleting the shadow file corresponding to the target cloud disk, the shadow file being used to store the updated data of the target cloud disk during the current snapshot operation.

[0014] This application also provides an electronic device, including: a memory and a processor; the memory is used to store one or more computer instructions; the processor is used to execute the one or more computer instructions to perform the steps in the method provided in this application.

[0015] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the method provided in this application.

[0016] This application also provides a computer program product, including: a computer program / instructions, which, when executed by a processor, can implement the steps in the method provided in this application.

[0017] In this embodiment, after uploading the snapshot data corresponding to the current snapshot operation of the target storage volume, the write node can delete the shadow file corresponding to the target storage volume if there is no unmerged updated data on the target storage volume. Before deleting the shadow file, the first write node can create a snapshot mutual exclusion flag in the target storage volume. The snapshot mutual exclusion flag can block the next snapshot operation of the target storage volume within a set time range. Therefore, other write nodes in the distributed file system cannot perform snapshot operations on the target storage volume within the set time range, reducing the probability that the shadow file to be deleted by the write node will be reused in the next snapshot operation. This reduces the risk of data loss caused by the write node's deletion of the shadow file, and helps improve the accuracy of the updated data written to the target storage volume during the next snapshot period. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0019] Figure 1 A schematic diagram of the structure of a distributed file system provided in an exemplary embodiment of this application;

[0020] Figure 2 A flowchart illustrating the simultaneous operation of a target storage volume by multiple write nodes in a distributed file system;

[0021] Figure 3 A schematic flowchart of a snapshot processing method provided for an exemplary embodiment of this application;

[0022] Figure 4a A schematic diagram illustrating the merge control process performed by a write node as provided in an exemplary embodiment of this application;

[0023] Figure 4b A schematic diagram illustrating the disk opening process and snapshot creation process performed by the write node as provided in an exemplary embodiment of this application;

[0024] Figure 5 A schematic diagram of the structure of an electronic device provided for an exemplary embodiment of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” used in the embodiments of this invention and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. “Multiple” generally includes at least two, but does not exclude the inclusion of at least one.

[0027] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0028] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a product or system. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the product or system that includes said element.

[0029] A distributed file system comprises: clients, management nodes, write nodes, a write cluster, and data nodes. Clients receive read and write requests from users. Management nodes manage the distributed file system's metadata, including file directory structure, file attributes, and data block distribution information. The write cluster distributes write requests across multiple write servers, achieving load balancing and fault tolerance. Write nodes receive and process client write requests, routing them to the appropriate data nodes. Data nodes are responsible for the actual storage of data blocks and provide data read and write services. A volume is a logical storage unit on a data node, used to organize data blocks into logical storage units and supporting snapshot functionality. Block storage services are deployed on data nodes; these services store and manage the allocation, reclamation, and migration of data blocks.

[0030] Block storage services, such as the Elastic Block Store (EBS), have introduced snapshot functionality. Snapshots are a data protection mechanism that allows the creation of a copy of a storage volume's state at a specific point in time. In some distributed file system applications, read-only snapshots (ROW) can be implemented on EBS based on the RAF class. The basic idea of ​​ROW is to preserve the original data in the storage volume after creating a snapshot and redirect all new write operations to the storage volume to another location. This approach can quickly create a point-in-time data copy without interfering with existing data access. When reading data from a snapshot, if the requested data block has not been modified since the snapshot was created, it is read directly from the original volume; if it has been modified, it is read from the newly written location. The RAF class can be used to manage read and write operations on underlying files, ensuring that after a snapshot is created, new write operations to the original file do not overwrite existing data but are redirected to a new location, thus achieving the read-only characteristic of the snapshot.

[0031] In some scenarios, in a distributed file system, user input / output (I / O) data is written to a file accessible through the RAF class (hereinafter referred to as a RAF type file) by a single write node. When the RAF type file supports update semantics with specified offsets, the write node can perform write operations at any position in the RAF type file.

[0032] When a write node creates a snapshot of data in a storage volume, it records the current data block state of the storage volume, generates snapshot metadata, initializes a RAF type file as a shadow file, and initializes a bitmap. The size of the shadow file is the same as the size of the storage volume. After snapshot creation, if new data is written to a data block, the write node can write the new data to the shadow file at the same offset as that data block. The bitmap is used to mark updated data blocks; each bit in the bitmap represents a data block, and if a bit is set to 1, it indicates that the data block has been updated. After the storage volume snapshot is uploaded, the bitmap can be read to identify the updated data blocks, and the corresponding new data for those data blocks can be read from the shadow file. Then, the new data read from the shadow file can be written back to the same offset position in the storage volume. Finally, the bitmap can be updated to clear the markers of merged data blocks.

[0033] RAF (Remote File System) type files lack inline-file protection. Inline-file refers to a mechanism that embeds small files directly into the metadata for storage. This lack of inline-file protection makes RAF files easy to delete individually and difficult to recover using metadata. In some application scenarios, distributed file systems can experience a "split-brain" phenomenon due to network failures, thread congestion, or other reasons. In this scenario, the primary write node in the distributed file system cannot handle client I / O operations on the storage volume, and the distributed file system will schedule other write nodes to handle these operations. After recovering from the failure, the primary write node has the ability to destroy the shadow files corresponding to the snapshot operations performed before the failure. In this situation, multiple write nodes can simultaneously operate on the shadow files corresponding to the same storage volume, leading to the loss of these shadow files.

[0034] For example, in Figure 2In the scenario shown, the cloud disk can be treated as a storage volume. After write node A opens the cloud disk, it can perform the first snapshot. During the first snapshot, updated data for the cloud disk is written to the corresponding position in the shadow file of the cloud disk, and a bitmap is used to mark the updated data blocks. After the first snapshot, the updated data during the snapshot can be merged into the cloud disk based on the shadow file and bitmap. When write node A performs the second snapshot of the cloud disk, it needs to perform a process to delete the shadow file and bitmap generated in the first snapshot. After entering the shadow file deletion process, write node A can rename the bitmap file to a temporary file. During the deletion process, a failure causes the deletion operation of write node A to be stuck. In this case, the write cluster can schedule write node B to continue processing the second snapshot of the cloud disk. After write node B performs the disk opening operation, it can reuse the shadow file and bitmap that were not deleted. Here, the disk opening operation means that the write node opens the cloud disk and is ready to accept read and write operations for the cloud disk. After acquiring new data, write node B can reuse the shadow file to store the new data and reuse the bitmap to mark the updated data blocks in the cloud disk. During the reuse of the shadow file by write node B, if write node A recovers from a failure, it can continue to perform temporary file deletion operations, leading to the loss of the shadow file currently being used by write node B. Consequently, the data newly written by write node B will be lost, causing continuous failures in scheduling disk opening.

[0035] One solution generates a manifest file when a storage volume is created; the manifest file is a special metadata file. Each time a write node opens the storage volume, the manifest file is updated and then deleted when the storage volume is deleted. Each time a write node opens a storage volume, there's no need to delete the volume's shadow files and bitmaps; instead, new shadow files and bitmaps are created directly. Write nodes can add sequence numbers to the newly created shadow files and bitmaps in ascending order and record these sequence numbers in the manifest file. The background service can scan for expired shadow files and bitmaps based on the manifest file and delete them. In this solution, the storage volume's shadow files are not reused, but this approach alters the lifecycle of shadow files and bitmaps, significantly impacting the block storage service architecture. Furthermore, this solution changes the naming convention for shadow files and bitmaps and introduces a new manifest file, leading to significant compatibility issues and making it unsuitable for scenarios involving storage volume replication and migration.

[0036] To address the aforementioned technical problems, a solution is provided in some embodiments of this application. The technical solutions provided by each embodiment of this application are described in detail below with reference to the accompanying drawings.

[0037] Figure 3 This is a flowchart illustrating a snapshot processing method provided in an exemplary embodiment of this application. The method may include, for example: Figure 3 The steps shown are as follows:

[0038] Step 301: After uploading the snapshot data corresponding to this snapshot operation of the target storage volume, if it is determined that there are no unmerged data blocks in the target storage volume, a snapshot mutual exclusion flag is added to the target storage volume. The snapshot mutual exclusion flag is used to block the next snapshot operation for the target storage volume within a set time range.

[0039] Step 302: Within the set time range, delete the shadow file corresponding to the target storage volume. The shadow file is used to store the updated data of the target storage volume during this snapshot operation.

[0040] The execution entity in this embodiment can be a first write node in a distributed file system, and the first write node can be any write node. In the distributed file system, the first write node is used to accept and process read / write requests from clients, and perform read / write operations on the data in the target storage volume according to the client's read / write requests. In this embodiment, the target storage volume can be any storage volume opened by the first write node. The snapshot operation of the target storage volume includes: creating a snapshot of the target storage volume, obtaining snapshot data, and uploading the snapshot data of the target storage volume. The snapshot data can be uploaded to a specified storage space, such as an object storage service in the cloud. When creating a snapshot of the target storage volume, the first write node can initialize the shadow file and bitmap corresponding to the target storage volume.

[0041] The shadow file can be created during the current snapshot operation or during the previous snapshot operation of the target storage volume; this embodiment does not impose any restrictions. The shadow file stores updated data on the target storage volume during the snapshot period. The bitmap corresponding to the target storage volume records data blocks that were updated on the target storage volume during the snapshot period. Each bit in the bitmap corresponds one-to-one with a data block in the target storage volume; if a bit is set to 1, it indicates that the data block has been updated. When a snapshot is created, all bits in the bitmap are initialized to 0, indicating that no data blocks have been updated. During the snapshot of the target storage volume, if a data block on the target storage volume is updated, the updated data corresponding to that data block is written to the shadow file, and the corresponding bit in the bitmap is set to 1.

[0042] In step 301, after uploading the snapshot data of the target storage volume, the first write node can traverse the bitmap corresponding to the target storage volume, find the bit with a value of 1, determine that the data block corresponding to the bit is the updated data block, read the updated data corresponding to the data block from the shadow file, and merge the updated data with the original data in the data block. After the merge is completed, the bit in the bitmap corresponding to the data block will be cleared to indicate that the data block has been merged.

[0043] Based on this, in step 301, the first write node can determine whether there are unmerged data blocks in the target storage volume according to the bitmap corresponding to the target storage volume. Specifically, the first write node can determine whether there are bits with a value of 1 in the bitmap. If not, it is determined that there are unmerged data blocks in the target storage volume. If there are bits with a value of 1, the first write node can perform a merge operation on the data blocks corresponding to the bits with a value of 1 until there are no bits with a value of 1 in the bitmap.

[0044] If it is determined that there are no unmerged data blocks in the target storage volume, the first write node can assume that the updated data written to the shadow file during this snapshot operation has been merged into the target storage volume. In this case, the first write node can delete the shadow file to reduce the data bloat caused by the shadow file.

[0045] In some scenarios, after the first write node creates snapshot data of the target storage volume, the MergeGuard module and the MergeLoop module can be used to perform the merging operation of the updated data on the target node during the snapshot.

[0046] After uploading the snapshot data of the target storage volume, the first write node can periodically execute step 302 via the MergeGuard module to determine whether there are unmerged data blocks on the target storage volume based on the bitmap corresponding to the target storage volume. If unmerged data blocks exist, the MergeGuard module can start the MergeLoop module to perform the merging operation of the data blocks. If there are no unmerged data blocks on the target storage volume, the MergeGuard module can perform the deletion operation of the shadow files. In this scenario, when the MergeGuard module periodically accesses the bitmap corresponding to the target storage volume, the access period can be 30 seconds, 60 seconds, 90 seconds, or other durations determined empirically; this embodiment does not impose any restrictions.

[0047] In some scenarios, before the shadow file is deleted, a write node in the distributed file system, such as a second write node, may perform a snapshot operation on the target storage volume and use the shadow file to store the updated data during the snapshot. After the shadow file is deleted by the first write node, the data written by the second write node in the shadow file will be lost. To mitigate this risk of data loss, in step 302, before deleting the shadow file, the first write node may add a snapshot mutex to the target storage volume. This snapshot mutex is used to block the next snapshot operation on the target storage volume within a set time range. That is, within the set time range, even if the second write node can access the target storage volume, it cannot perform a snapshot operation on the target storage volume, and therefore, the shadow file on the target storage volume will not be reused by the next snapshot operation within the set time range.

[0048] In this embodiment, the set time range is based on the time required to delete the shadow file and the fault recovery time of the first write node. Optionally, the set time range can be greater than the sum of the time required to delete the shadow file and the fault recovery time of the first write node. Therefore, before the shadow file is completely deleted, other write nodes cannot use the shadow file. Even if the first write node fails during the deletion of the shadow file, other write nodes cannot use the shadow file during the fault recovery period. Based on this implementation, the impact of the shadow file deletion operation on the next snapshot operation of the target storage volume is reduced, which helps improve the accuracy of the newly written updated data after the snapshot operation.

[0049] In this embodiment, the snapshot mutex identifier can be a file carrying a mutex keyword. When the first write node adds a snapshot mutex identifier to the target storage volume, it can create a file carrying a mutex keyword in the target storage volume, such as a mutex. A file carrying a mutex keyword is a lightweight snapshot mutex identifier, which can achieve mutual exclusion between the shadow file deletion process and the snapshot process of the target storage volume with a small storage space occupation of the target storage volume and without complex communication between the first write nodes.

[0050] After adding a snapshot mutual exclusion flag to the target storage volume, in step 302, the first write node can delete the shadow file corresponding to the target storage volume within a set time range.

[0051] In this implementation, before deleting the shadow file corresponding to the target storage volume, the first write node adds a snapshot mutual exclusion flag to the target storage volume. The snapshot mutual exclusion flag can block the next snapshot operation of the target storage volume within a set time range. As a result, other write nodes in the distributed file system cannot perform snapshot operations on the target storage volume within the set time range, which reduces the probability that the shadow file that the first write node is about to delete will be reused in the next snapshot operation, and reduces the risk of data loss caused by the deletion operation of the shadow file by the first write node.

[0052] It should be noted that after the first write node adds a snapshot mutex identifier to the target storage volume, if it detects that the shadow file has been closed, it can initiate the snapshot mutex identifier deletion process. After entering the snapshot mutex identifier deletion process, the first write node can obtain the snapshot mutex identifier in the specified directory in the target storage volume, and delete the snapshot mutex identifier after the set time range has expired, so as to release the blockage on snapshot operations on the target storage volume.

[0053] As described in the above embodiments, the snapshot mutex flag created after the current snapshot operation of the target storage volume can be used to block the next snapshot operation of the target storage volume within a set time range. Correspondingly, the snapshot mutex flag created after the previous snapshot operation of the target storage volume can also block the current snapshot operation of the target storage volume within a set time range, so as to reduce the impact of the deletion of the shadow file of the target storage volume on the current snapshot operation of the target storage volume if the shadow file of the target storage volume was deleted during the previous snapshot operation.

[0054] Based on this, in some optional embodiments, the first write node can respond to the snapshot event of the target storage volume and determine whether a historical snapshot mutex exists on the target storage volume. This historical snapshot mutex was created after the last snapshot operation of the target storage volume. If the historical snapshot mutex does not exist on the target storage volume, the first write node can perform the current snapshot operation. When performing this snapshot operation, the first write node can create snapshot data corresponding to the target storage volume and upload the snapshot data. Optionally, if the historical snapshot mutex exists on the target storage volume, the first write node can block the current snapshot operation of the target storage volume until the historical snapshot mutex expires or is deleted.

[0055] Based on this implementation, before performing a snapshot operation on the target storage volume, the first write node can check whether a historical snapshot mutual exclusion flag created after the previous snapshot operation exists on the target storage volume to determine whether a snapshot operation can be performed on the target storage volume. This achieves mutual exclusion between the snapshot process of the target storage volume and the deletion process of the corresponding shadow file of the target storage volume. For the first write node, even if the target storage volume is opened, the snapshot operation on the target storage volume can be blocked or intercepted based on the historical snapshot mutual exclusion flag, reducing the impact of the previous snapshot operation on the data accuracy of the current snapshot operation.

[0056] It is worth noting that the shadow file deletion process executed by the first write node and the snapshot process executed by the second write node on the target storage volume can be performed in parallel. That is, while the first write node is executing the shadow file deletion process corresponding to the target storage volume, the second write node can concurrently execute the snapshot operation on the target storage volume. In some scenarios, the second write node may have already created a snapshot of the target storage volume before the first write node adds a snapshot mutual exclusion flag to the target storage volume. In this case, if the first write node continues to execute the shadow file deletion process, it may cause the data written by the second write node in the shadow file to be lost. Based on this, in this embodiment, before executing the shadow file deletion process, the first write node can further determine whether the target storage volume is occupied by the second write node, and can delete the shadow file if the target storage volume is not occupied by the second write node, so as to reduce the risk of data loss. The shadow file deletion process executed by the first write node will be described exemplarily below.

[0057] In some optional embodiments, before deleting the shadow file corresponding to the target storage volume, the first write node can determine whether the target storage volume is occupied by the second write node based on the current ownership verification file on the target storage volume. If the target storage volume is not occupied by the second write node, the first write node can delete the shadow file corresponding to the target storage volume. Optionally, if the target storage volume is occupied by the second write node, the first write node can disable the deletion operation of the shadow file to retain the shadow file if the second write node reuses it. In this embodiment, the ownership verification file refers to a file created for the target storage volume that records the occupancy information of the write nodes on the target storage volume. This file can identify the current occupancy information of the target storage volume through its content or filename.

[0058] Optionally, before deleting the shadow file corresponding to the target storage volume, the first write node can suspend I / O operations on the target storage volume to ensure that no ongoing I / O operations are in progress when the shadow file is deleted, thus reducing the risk of data inconsistency. This I / O operation can be initiated by a client of the distributed file system. After deleting the shadow file, the first write node can resume input / output operations on the target storage volume to continue providing storage services for the target storage volume.

[0059] Based on this implementation, if the target storage volume is not occupied by the second write node, the first write node can determine that the shadow file has not been reused by the second write node, and therefore, deleting the shadow file will not cause the loss of updated data written by the second write node. In some optional embodiments, the current ownership verification file on the target storage volume may be created by the first write node or by the second write node. When any first write node occupies the target storage volume, it can create an ownership verification file on that storage volume and delete the ownership verification file created by the second write node. Therefore, for any first write node, if the current ownership verification file on the target storage volume was created by the first write node, it means that the first write node has the right to occupy the target storage volume. If the current ownership verification file on the target storage volume was not created by the first write node, it means that the first write node has lost the right to occupy the target storage volume.

[0060] Continuing with the example of the first write node, optionally, before deleting the shadow file corresponding to the target storage volume, the first write node may query whether an ownership verification file created by the third write node exists on the target storage volume. The third write node can be a write node that opened the target storage volume before the first write node. To distinguish it from other ownership verification files described later, the ownership verification file created by the third write node is described as the first ownership verification file. If a first ownership verification file created by the third write node exists on the target storage volume, the first write node may delete the first ownership verification file and create a new ownership verification file on the target storage volume. To further distinguish it, the new ownership verification file created by the first write node can be described as the second ownership verification file.

[0061] Accordingly, when the first write node determines whether the target storage volume is occupied by the second write node based on the current ownership verification file on the target storage volume, it can determine whether the current ownership verification file on the target storage volume is consistent with the second ownership verification file; if they are consistent, it can be determined that the target storage volume is not occupied by the second write node; if they are inconsistent, it can be determined that the target storage volume has been occupied by the second write node.

[0062] In this implementation, for any write node, after opening the target storage volume, it can delete the ownership verification file created by the previous write node on the target storage volume and create its own ownership verification file, thus performing the ownership preemption process for the target storage volume simply and quickly. The ownership verification file can represent the occupancy information of the target storage volume through its content or name. It has a simple structure, small data volume, and simple management, placing less burden on the write nodes. During ownership verification, any write node can directly determine whether the current ownership verification file on the target storage volume is consistent with its own created ownership verification file to achieve ownership verification. This verification method has low operational complexity and does not rely on other nodes to participate in the verification process, making it a low-cost ownership verification method.

[0063] Optionally, the second ownership verification file may be generated based on the unique identification information of the first write node. This unique identification information can be used to generate the filename of the second ownership verification file, so that ownership verification can be performed directly based on the filename. The unique identification information may be the universally unique identifier (UUID) of the first write node, the port number corresponding to the first write node, the network address of the first write node, or other identification information. Alternatively, it may be the timestamp information when the target storage volume was occupied by the first write node; this embodiment does not impose any limitations.

[0064] For example, in some embodiments, the ownership verification file generated by any first write node can be named according to the first write node's UUID. When determining whether the current ownership verification file on the target storage volume is consistent with the second ownership verification file, the first write node can obtain its own UUID from memory and determine whether the name of the current ownership verification file contains the obtained UUID. If it does, it is determined that the current ownership verification file on the target storage volume is consistent with the second ownership verification file; otherwise, it is determined that the current ownership verification file on the target storage volume is inconsistent with the second ownership verification file.

[0065] Based on this implementation, on the one hand, the ownership verification file created by any write node is generated based on the unique identification information of that write node, making the ownership verification file unique and thus accurately identifying the occupancy status of the target storage volume. On the other hand, ownership verification is performed by the name of the ownership verification file, eliminating the need to store a large amount of data related to ownership verification in the ownership verification file, making the ownership verification file very lightweight. Using a lightweight ownership verification file to identify the occupancy status of the target storage volume consumes less storage space on the target storage volume and eliminates the need for communication and interaction between multiple first write nodes, resulting in lower operational complexity and helping to reduce the complexity of snapshot operations.

[0066] In some optional embodiments, the target storage volume can be any target cloud disk provided by the cloud storage platform. After uploading the snapshot data corresponding to the current snapshot operation of the target cloud disk, any first write node in the distributed file system, if it determines that there are no unmerged data blocks in the target cloud disk, adds a snapshot mutual exclusion flag to the target cloud disk. This snapshot mutual exclusion flag is used to block the next snapshot operation for the target cloud disk within a set time range. The first write node can delete the shadow file corresponding to the target cloud disk within a set time range. This shadow file is used to store the updated data of the target cloud disk during the current snapshot operation. Furthermore, other write nodes in the distributed file system cannot perform snapshot operations on the target cloud disk within the set time range, reducing the probability that the shadow file to be deleted by the write node will be reused in the next snapshot operation. This reduces the risk of data loss caused by the write node's deletion of the shadow file, and helps improve the accuracy of the updated data written to the target cloud disk during the next snapshot.

[0067] The following will combine Figure 4a as well as Figure 4b The snapshot processing method provided in this application embodiment will be further illustrated by example. In the snapshot processing method, any write node in the distributed file system can execute... Figure 4a The merged control process shown and Figure 4b The diagram illustrates the opening and snapshot creation processes. The merge control process and the snapshot creation process are mutually exclusive; if the merge control process is in progress, the snapshot creation process cannot be executed, and vice versa. The merge control process can be executed periodically by the MergeGuard module in the write node. The status of the merge control process and the snapshot creation process can be represented by a set global status parameter. For example, a true value for the status parameter indicates that the process is in progress, and a true value for the status parameter indicates that the process is not in progress.

[0068] The following will be combined with the appendix Figure 4aand appendix Figure 4b The above processes will be illustrated by taking any write node as an example.

[0069] like Figure 4a As shown, when executing the merge management process for any storage volume, the MergeGuard module in the write node can determine whether the snapshot creation process corresponding to the storage volume is running. If the snapshot creation process is running, the merge management process can be terminated directly. If the snapshot creation process is not running, the MergeGuard module can set the merge management process status to running, which indicates that the snapshot creation process cannot be executed for this storage volume. Figure 4a As shown, the MergeGuard module can determine whether a merge object exists. A merge object is an object used to call the MergeLoop module. The merge object can be created during the disk opening process or the snapshot creation process. If no merge object exists, the MergeGuard module considers the storage volume merge operation complete and can clean up any remaining expired snapshot mutex files in the storage volume's directory. If a merge object exists, the MergeGuard module can determine whether the merge process is running. If the merge process is running, there is no need to initiate the merge process again; the current merge control process can be terminated directly. If the merge process is not running, the MergeGuard module can determine whether there is data that needs to be merged based on the storage volume's bitmap after the snapshot upload is complete. If there is data that needs to be merged, the MergeLoop module can be called through the merge object to execute the merge process.

[0070] like Figure 4a As shown, when executing the merge process, the MergeLoop module can set the merge process status to running and iterate through the data to be merged in the merge queue, merging the data into the data files of the storage volume. The data in the merge queue is updated data obtained from the shadow file of the storage volume; this updated data is the data written to the storage volume during the storage volume's snapshot period. When the merge queue is empty, the MergeLoop module can set the merge process status to not running and terminate the merge process.

[0071] If no data needs to be merged, the MergeGuard module initiates the deletion process of the shadow files corresponding to the storage volume. For example... Figure 4aAs shown, in the shadow file deletion process, the MergeGuard module can suspend the storage volume's I / O and wait for a timer to finish. This timer refers to the duration required to delete the shadow file. The MergeGuard module can create a snapshot mutex identifier file on the storage volume and check whether the storage volume belongs to this writer node (i.e., the storage volume is not occupied by other writer nodes) based on the ownership verification file on the storage volume. If the storage volume does not belong to this writer node, it may be because other writer nodes have successfully opened the storage volume. The first writer node can end the merge control process and not perform the shadow file deletion operation. If the storage volume belongs to this writer node, the MergeGuard module can close the shadow file, destroy the merge object, and delete the shadow file. Afterward, the MergeGuard module can resume the storage volume's I / O operations and delete the snapshot mutex identifier file after a set time range. Figure 4a As shown, after deleting the snapshot mutex identifier file, the MergeGuard module can set the merge control process to not running, thereby releasing the block on the snapshot creation process of the storage volume.

[0072] Figure 4b The disk opening process of a storage volume is illustrated. During the disk opening process, after a write node opens the storage volume, it can open the data files on the storage volume and obtain the ownership verification file in the storage volume's directory. This ownership verification file is created by other write nodes when performing the disk opening process on the storage volume. The write node can delete all ownership verification files and create a globally unique ownership verification file. As described in the previous embodiment, the write node can use its own UUID to name the ownership verification file it creates. During the disk opening process, the write node can check whether the ownership verification file in the storage volume has been modified to determine whether the storage volume is occupied by other write nodes. If it is not occupied by other write nodes, the write node can determine whether there is data to be merged on the storage volume based on the bitmap corresponding to the storage volume. If there is data to be merged, a merge object is generated. On the write node, the MergeGuard module can periodically execute the merge control process and call the MergeLoop module to execute the merge process through the merge object. For details, please refer to [link / reference]. Figure 4a and Figure 4b The illustrations and descriptions of the foregoing embodiments will not be repeated here.

[0073] Figure 4bThe snapshot creation process for a storage volume is illustrated. In this process, the write node determines whether the merge management process for the storage volume is running based on its status. The merge management process and the snapshot creation process are mutually exclusive. Therefore, if the merge management process for the storage volume is running, the write node can return a snapshot creation failure result. If the merge management process for the storage volume is not running, the write node sets the snapshot creation process status to running, which blocks the execution of the merge management process for that storage volume. Next, the write node can determine if a snapshot mutual exclusion flag file exists on the storage volume. This flag file is created after the last snapshot operation on the storage volume and is used to block snapshot operations on the storage volume within a set time range, preventing the shadow file used in the previous snapshot operation from being reused in the current snapshot operation. If the snapshot mutual exclusion flag file exists, the write node can return a snapshot creation failure result. If the snapshot mutual exclusion flag file does not exist, the write node can separate the snapshot data from the data file and create a shadow file corresponding to the storage volume. This shadow file is used to store the updated data written to the storage volume during the snapshot period. Figure 4b As shown, after creating snapshot data, the write node can set the snapshot creation process to "not running," a state used to release the blockage on the storage volume's merge management process. Figure 4b As shown, in the snapshot creation process, after the write node creates the shadow file, it can create a merge object so that the MergeGuard module can call the MergeLoop module through the merge object to execute the merge process in the merge control process. This will not be elaborated further.

[0074] In the above embodiments, based on the snapshot mutual exclusion identifier file, the operation of deleting shadow files in the merge control process is mutually exclusive with the snapshot creation operation in the snapshot creation process. This reduces the probability that the shadow file used in the previous snapshot operation will be reused in the subsequent snapshot operation, thereby reducing the impact of deleting shadow files after the previous snapshot operation on the subsequent snapshot operation. Based on the ownership verification file, the operation of deleting shadow files in the merge control process is mutually exclusive with the data merging operation in the opening process, further providing fallback data protection. The following will explain this in conjunction with different scenarios.

[0075] Suppose that in a scenario where a first writer node is performing a merge management process on a storage volume, a second writer node initiates a snapshot operation on that volume. Before deleting the shadow file, the first writer node creates a snapshot mutex file on the storage volume. Even if a failure occurs during the deletion of the shadow file by the first writer node, preventing its deletion, the second writer node's snapshot creation will fail because of the snapshot mutex file on the storage volume. Therefore, the shadow file created by the first writer node during its snapshot operation will not be reused by the second writer node. Even if the first writer node recovers from the failure and successfully deletes the shadow file, it will not affect the second writer node's snapshot operation.

[0076] Suppose, in another application scenario, the first write node fails while performing a merge control process on the storage volume. The write cluster will then schedule a second write node to initiate an open process for the storage volume. After opening the storage volume, the second write node will delete the ownership verification file created by the first write node and create its own ownership verification file. When the first write node recovers from the failure, it will find that its ownership verification file has been deleted. At this point, it can end the merge control process without performing the shadow file deletion operation. Then, the second write node can determine whether there is data that needs to be merged based on the storage volume's bitmap. If so, it will execute the merge control process based on the remaining shadow files, thereby ensuring that the updated data generated during the last snapshot of the storage volume can be completely merged.

[0077] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 301 to 302 can be device A; or the execution subject of step 301 can be device A, and the execution subject of step 302 can be device B; and so on.

[0078] Furthermore, in some of the processes described in the above embodiments and accompanying drawings, multiple operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 301, 302, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

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

[0080] Figure 5 This application illustrates a schematic diagram of the structure of an electronic device provided in an exemplary embodiment, as shown below. Figure 5 As shown, the electronic device includes: a memory 501, a processor 502, and a communication component 503.

[0081] Memory 501 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device. Figure 5 The illustrated electronic device may be equipped with at least one write node from a distributed file system, and any one of these write nodes can be used to execute the snapshot data processing methods described in the foregoing embodiments. The following will use the first write node among these at least one write nodes as an example to illustrate... Figure 5 The functions of the illustrated electronic devices will be explained.

[0082] Processor 502, coupled to memory 501, is used to execute a computer program in memory 501 for: after uploading snapshot data corresponding to the current snapshot operation of the target storage volume, if it is determined that the target storage volume does not contain unmerged data blocks, adding a snapshot mutual exclusion flag to the target storage volume, the snapshot mutual exclusion flag being used to block the next snapshot operation for the target storage volume within a set time range; and deleting the shadow file corresponding to the target storage volume within the set time range, the shadow file being used to store the updated data of the target storage volume during the current snapshot operation.

[0083] Optionally, the processor 502 is further configured to: respond to a snapshot event of the target storage volume, determine whether there is a historical snapshot mutual exclusion identifier on the target storage volume, the historical snapshot mutual exclusion identifier being created after the last snapshot operation of the target storage volume; if there is no historical snapshot mutual exclusion identifier, then create snapshot data corresponding to the current snapshot operation of the target storage volume, and upload the snapshot data.

[0084] Optionally, the processor 502 is further configured to: block the current snapshot operation of the target storage volume if a historical snapshot mutex exists.

[0085] Optionally, when deleting the shadow file corresponding to the target storage volume, the processor 502 specifically performs the following: determines whether the target storage volume is occupied by the second write node based on the current ownership verification file on the target storage volume; if the target storage volume is not occupied by the second write node, then deletes the shadow file corresponding to the target storage volume.

[0086] Optionally, the processor 502 is further configured to: suspend input / output operations for the target storage volume before deleting the shadow file; and resume input / output operations for the target storage volume after deleting the shadow file.

[0087] Optionally, the processor 502 is further configured to: disable the deletion operation of the shadow file if the target storage volume is occupied by the second write node.

[0088] Optionally, before deleting the shadow file corresponding to the target storage volume, the processor 502 is further configured to: when occupying the target storage volume, if a first ownership verification file created by a third write node exists on the target storage volume, delete the first ownership verification file and create a second ownership verification file on the target storage volume; determine whether the target storage volume is occupied by the second write node based on the current ownership verification file on the target storage volume, including: determining whether the current ownership verification file on the target storage volume is consistent with the second ownership verification file; if consistent, determine that the target storage volume is not occupied by the second write node; if inconsistent, determine that the target storage volume has been occupied by the second write node.

[0089] Optionally, the second ownership verification file is generated based on the unique identification information of the first write node.

[0090] In addition to the aforementioned embodiments, Figure 5 The illustrated electronic device can also be used to perform the following method, wherein the processor 502 is configured to: after uploading the snapshot data corresponding to the current snapshot operation of the target cloud disk, if it is determined that there are no unmerged data blocks in the target cloud disk, add a snapshot mutual exclusion flag to the target cloud disk, the snapshot mutual exclusion flag being used to block the next snapshot operation for the target cloud disk within a set time range; and within the set time range, delete the shadow file corresponding to the target cloud disk, the shadow file being used to store the updated data of the target cloud disk during the current snapshot operation.

[0091] Furthermore, such as Figure 5 As shown, the electronic device also includes other components such as a power supply component 504, a display component 505, and an audio component 506. Figure 5 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 5The components shown. Figure 5 In this embodiment, the components within the dashed boxes are optional, not mandatory, and their specific requirements depend on the product form of the electronic device. The electronic device in this embodiment can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or a server-side device such as a conventional server, cloud server, or server array. If the electronic device in this embodiment is a terminal device such as a desktop computer, laptop computer, or smartphone, it may include... Figure 5 The components within the dashed box; if the electronic device in this embodiment is implemented as a conventional server, cloud server, or server array, etc., it may be omitted. Figure 5 The component within the dashed box.

[0092] The memory 501 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0093] The communication component 503 is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as Wi-Fi, 2G (e.g., Global System for Mobile Communications (GSM)), 3G (e.g., Wideband Code Division Multiple Access (WCDMA), 4G (e.g., Long Term Evolution (LTE)), 4G+ (e.g., LTE-Advanced (LTE-A)), or 5G (5th Generation Mobile Communication Technology), or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component may be implemented based on Near Field Communication (NFC), Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), and other technologies.

[0094] The power supply component 504 is used to provide power to various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which it resides.

[0095] The display component includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation.

[0096] An audio component may be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals may be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0097] In this embodiment, after uploading the snapshot data corresponding to the current snapshot operation of the target storage volume, the write node can delete the shadow file corresponding to the target storage volume if there is no unmerged updated data on the target storage volume. Before deleting the shadow file, the first write node can create a snapshot mutual exclusion flag in the target storage volume. The snapshot mutual exclusion flag can block the next snapshot operation of the target storage volume within a set time range. Therefore, other write nodes in the distributed file system cannot perform snapshot operations on the target storage volume within the set time range, reducing the probability that the shadow file that the write node is about to delete will be reused in the next snapshot operation. This reduces the risk of data loss caused by the write node's deletion of the shadow file, and helps improve the accuracy of the updated data written to the target storage volume during the next snapshot period.

[0098] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed, can implement the steps that can be performed by an electronic device in the above method embodiments.

[0099] This application also provides a computer program product, including: a computer program / instructions, which, when executed by a processor, can implement the steps in the method provided in this application.

[0100] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM (Compact Disc Read-Only Memory), optical storage, etc.) containing computer-usable program code.

[0101] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0102] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0103] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0104] In a typical configuration, a computing device includes one or more processors (Central Processing Unit, CPU), input / output interfaces, network interfaces, and memory.

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

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

[0107] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, product, or apparatus that includes said element.

[0108] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A snapshot processing method, applied to the first write node in a distributed file system, characterized in that, include: After uploading the snapshot data corresponding to this snapshot operation of the target storage volume, if it is determined that there are no unmerged data blocks in the target storage volume, a snapshot mutual exclusion flag is added to the target storage volume. The snapshot mutual exclusion flag is used to block the next snapshot operation for the target storage volume within a set time range. Within the set time range, delete the shadow file corresponding to the target storage volume. The shadow file is used to store the updated data of the target storage volume during this snapshot operation.

2. The method according to claim 1, characterized in that, Also includes: In response to a snapshot event of the target storage volume, determine whether a historical snapshot mutex exists on the target storage volume, wherein the historical snapshot mutex was created after the last snapshot operation of the target storage volume; If no historical snapshot mutual exclusion identifier exists, then create the snapshot data corresponding to this snapshot operation of the target storage volume and upload the snapshot data.

3. The method according to claim 2, characterized in that, Also includes: If a historical snapshot mutual exclusion flag exists, the current snapshot operation of the target storage volume will be blocked.

4. The method according to claim 1, characterized in that, Delete the shadow file corresponding to the target storage volume, including: Based on the current ownership verification file on the target storage volume, determine whether the target storage volume is occupied by the second write node; If the target storage volume is not occupied by the second write node, then the shadow file corresponding to the target storage volume is deleted.

5. The method according to claim 4, characterized in that, Also includes: Before deleting the shadow file, suspend input / output operations for the target storage volume; And, after deleting the shadow file, resume input / output operations for the target storage volume.

6. The method according to claim 4, characterized in that, Also includes: If the target storage volume is occupied by the second write node, then the deletion operation of the shadow file is turned off.

7. The method according to claim 4, characterized in that, Before deleting the shadow file corresponding to the target storage volume, the method also includes: When occupying the target storage volume, if a first ownership verification file created by a third write node exists on the target storage volume, the first ownership verification file is deleted, and a second ownership verification file is created on the target storage volume. Based on the current ownership verification file on the target storage volume, determine whether the target storage volume is occupied by the second write node, including: Determine whether the current ownership verification file on the target storage volume is consistent with the second ownership verification file; If they match, it is determined that the target storage volume is not occupied by the second write node; If not, then the target storage volume is determined to be occupied by the second write node.

8. The method according to claim 7, characterized in that, The second ownership verification file is generated based on the unique identification information of the first write node.

9. A snapshot processing method, applied to the first write node in a distributed file system, characterized in that, include: After uploading the snapshot data corresponding to this snapshot operation of the target cloud disk, if it is determined that there are no unmerged data blocks in the target cloud disk, a snapshot mutual exclusion flag is added to the target cloud disk. The snapshot mutual exclusion flag is used to block the next snapshot operation for the target cloud disk within a set time range. Within the set time range, delete the shadow file corresponding to the target cloud disk, which is used to store the updated data of the target cloud disk during this snapshot operation.

10. An electronic device, characterized in that, include: Memory and processor; The memory is used to store one or more computer instructions; The processor is configured to execute one or more computer instructions for performing the steps of the method according to any one of claims 1-9.

11. A computer-readable storage medium storing a computer program, characterized in that, When a computer program is executed by a processor, it is able to perform the steps of the method described in any one of claims 1-9.

12. A computer program product, characterized in that, include: A computer program / instruction that, when executed by a processor, enables the implementation of the steps in the method described in any one of claims 1-9.

Images