File read / write method, device and equipment in distributed file system
By requesting only non-full path snapshot read/write locks in the distributed file system's parent directory and waiting for all non-full path lock IOs to complete before snapshot processing, the performance degradation caused by snapshot lock mutual exclusion contention is resolved, improving file read/write performance and ensuring the reliability of snapshot configuration.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- XINHUASAN INFORMATION TECH CO LTD
- Filing Date
- 2022-12-22
- Publication Date
- 2026-05-05
AI Technical Summary
In distributed file systems, snapshot lock mutex contention leads to low file read/write performance, especially in application scenarios with frequent small file overwrites. Increased mutex contention in the metadata service (MDS) results in greater IO process latency and impacts performance.
During snapshot processing on a client without a snapshot, read/write IO for files in the root directory only requests non-full path snapshot read/write locks on the parent directory of the file being read/written. Snapshot processing is only performed after all non-full path snapshot read/write lock IO processing is completed, through mechanisms such as snapshot lock marking and non-snapshot request counting.
It reduces mutex lock contention for file reading/writing in the directory involved in snapshot processing, reduces IO latency, improves file reading/writing performance, especially for small files, and ensures the reliability of snapshot configuration.
Smart Images

Figure CN116226041B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of communication and cloud computing technologies, and in particular to a file read / write method, apparatus, and device in a distributed file system. Background Technology
[0002] Currently, many manufacturers are gradually adopting all-flash storage. For example, in the storage subsystem, they use solid-state drives (SSDs) or other flash media connected via the Non-Volatile Memory Express (NVMe) interface to replace traditional hard disk drives (HDDs). Therefore, in all-flash storage versions, the underlying disk is no longer a performance bottleneck. Moreover, the file system client is switched from kernel-mode cephfs to user-mode libcephfs, and the nfsd (the basic NFS daemon) is also switched from kernel-mode nfsd to user-mode ganesha-nfsd. This can reduce the problem of entire nodes crashing due to kernel-mode software defects (bugs). However, the performance of user-mode will be lower than that of kernel-mode.
[0003] A snapshot can be considered a copy or replica of data. For a file system, a file system snapshot is an immediate copy of the file system, containing all the information of the file system at the time the snapshot is generated; it is itself a complete and usable copy. Snapshots are typically configured through the cluster management page, allowing settings such as the snapshot directory, snapshot name, and expiration time.
[0004] To ensure the reliability of its snapshot feature, the Ceph file system (Cephfs) requires acquiring a full-path distributed snapshot lock (snaplock) read lock during all related input / output (IO) processes, and a snaplock write lock is required for snapshot configuration processes. In the current multi-threaded architecture of the MetaDataService (MDS), processes involving snaplock state machine changes are protected by mutex locks. In application scenarios with frequent small file overwrites, contention for mutex locks in MDS becomes intense, leading to increased IO latency and most threads being in an idle waiting state, significantly impacting performance. Summary of the Invention
[0005] In view of this, the present invention provides a file read / write method, apparatus and device in a distributed file system to solve the technical problem of low file read / write performance caused by snapshot lock mutual exclusion contention in a distributed system.
[0006] Based on one aspect of the embodiments of the present invention, the present invention provides a file read / write method in a distributed file system, the method comprising:
[0007] During snapshot processing on a client without a snapshot, read / write I / O on files in the root directory only requests non-full path snapshot read / write locks on the parent directory of the file being read / written;
[0008] During snapshot processing by the snapshot client, all read / write I / O operations on files in the root directory require a full-path snapshot read / write lock.
[0009] Before the snapshot client executes snapshot processing, it must wait for all read / write IO operations that acquire non-full path snapshot read / write locks to be completed before starting snapshot processing.
[0010] Furthermore, the file read / write I / O uses a snapshot locking flag (snaplocking) to determine whether snapshot processing is currently in progress; the snapshot locking flag (snaplocking) is set to true by the snapshot client before snapshot processing is performed and set to false after snapshot processing is completed; the snapshot locking flag (snaplocking) is a global variable.
[0011] Furthermore, the file read / write I / O uses the non-snapshot request count (nosnapreq) to indicate that there are currently read / write I / Os that have acquired non-full path snapshot read / write locks and are being executed. The non-snapshot request count (nosnapreq) is a global variable.
[0012] The file read / write I / O increments the non-snapshot request count (nosnapreq) by one after successfully acquiring a non-full path snapshot read / write lock, and decrements the non-snapshot request count (nosnapreq) by one after releasing the non-full path snapshot read / write lock.
[0013] Furthermore, the method of waiting for all read / write IOs acquiring non-full path snapshot read / write locks to be processed before starting the snapshot processing step is as follows:
[0014] Before performing snapshot preparation (do_prepare), the snapshot client initiates a precheck process to set a snapshot lock flag (snaplocking) to notify that file read / write IO is currently undergoing snapshot processing, and waits for the read / write IO that has acquired a non-full path snapshot read / write lock to complete through a non-snapshot request count (nosnapreq).
[0015] Furthermore, the precheck process includes:
[0016] Before performing snapshot preparation (do_prepare), the snapshot client (snapclient1) initiates a precheck process, which includes:
[0017] The snapshot client (snapclient1) notifies the snapshot server (snapserver) to initiate a pre-check step;
[0018] The snapshot server notifies all snapshot clients (snapclient1, snapclient2) in the distributed file system to perform a pre-check;
[0019] After receiving the notification to perform a pre-check, the snapshot clients (snapclient1, snapclient2) update the snapshot locking flag to true.
[0020] The snapshot clients (snapclient1, snapclient2) cyclically check whether the non-snapshot request count (nosnapreq) is 0. When it is determined that the non-snapshot request count (nosnapreq) is 0, a pre-check response is sent back to the snapshot server.
[0021] When the snapshot server receives the pre-check responses from all snapshot clients, it notifies the snapshot client (snapclient1) that initiated the pre-check step to execute the snapshot preparation (do_prepare) step.
[0022] Furthermore, the method also includes:
[0023] After receiving a notification from the snapshot server to reset the snapshot label (TABLECLIENT_OP_RESETSNAP), the snapshot client (snapclient1) updates the snapshot locking flag (snaplocking) to false to indicate that the file read / write IO snapshot processing flow has been completed.
[0024] Based on another aspect of the embodiments of the present invention, the present invention also provides a file read / write device in a distributed file system, the device comprising:
[0025] The first lock request module is used to request non-full path snapshot read / write locks on the parent directory of the file being read / written during snapshot processing on a client without a snapshot.
[0026] The second lock request module is used to request a full-path snapshot read / write lock for all file read / write I / O operations in the root directory during snapshot processing by the snapshot client.
[0027] Based on another aspect of the embodiments of the present invention, the present invention also provides a snapshot processing device in a distributed file system, which is applied to the snapshot client. This device can be implemented in software, hardware, or a combination of both. When implemented as a software module, when the program code of the software module is loaded into the storage medium of the device, the processor reads the program code from the storage medium and executes it, thereby realizing the functions of each component module in the device. The device includes:
[0028] The pre-check module is used by the snapshot client to set a snapshot lock flag (snaplocking) by initiating a pre-check process before performing snapshot preparation (do_prepare) to notify that file read / write IO is currently undergoing snapshot processing, and to wait for the read / write IO that has acquired a non-full path snapshot read / write lock to complete by using the non-snapshot request count (nosnapreq);
[0029] The global tag update module is used by the snapshot client (snapclient1) to update the snapshot locking tag (snaplocking) to false after receiving the snapshot tag reset notification (TABLECLIENT_OP_RESETSNAP) sent by the snapshot server, so as to notify that the file read / write IO snapshot processing flow has been completed.
[0030] It should be noted that the method of this invention can be executed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of the multiple devices may execute only one or more steps of the method of this invention. The multiple devices interact with each other to jointly complete the method and achieve the purpose of this invention, forming a mutual command and control relationship. Attached Figure Description
[0031] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments of the present invention or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained from these drawings of the embodiments of the present invention.
[0032] Figure 1 This is a flowchart illustrating the steps of a file read / write method in a distributed file system according to an embodiment of the present invention.
[0033] Figure 2 This is a schematic diagram illustrating the process of snapshot processing performed by a distributed file system in one embodiment of the present invention;
[0034] Figure 3 This is a schematic diagram of an electronic device structure for implementing the file read / write method in the distributed file system provided by the present invention, according to an embodiment of the present invention. Detailed Implementation
[0035] The terminology used in this embodiment of the invention is for the purpose of describing specific embodiments only and is not intended to limit the embodiments of the invention. The singular forms “a,” “the,” and “the” used in this embodiment are also intended to include the plural forms unless the context clearly indicates otherwise. It should be understood that although the terms first, second, third, etc., may be used to describe various information in this embodiment, this information should not be limited to these terms. These terms are only used to distinguish similar information, entities, or steps, and not to describe a specific order or sequence. For example, without departing from the scope of this embodiment, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Furthermore, the word “if” used can be interpreted as “when…”, “when…”, or “in response to a determination.” The term “and / or” in this invention 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 alone, A and B simultaneously, and B alone, where A and B can be singular or plural. And, in the description of this invention, unless otherwise stated, “multiple” means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can be expressed as: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.
[0036] To maintain the reliability of snapshot features, traditional read / write IO and snapshot configuration processes require acquiring a full-process snaplock read / write lock, which increases the contention of related mutex locks in the metadata service (MDS), causing increased input / output IO latency and thus affecting business performance.
[0037] In a distributed storage system using all-flash memory, this invention optimizes the file overwrite process for the core MetaData Service (MDS) and the user-space client (libcephfs) for the file system. For the user-space environment, it improves write permissions and snapshot locking mechanisms to enhance the performance of ordinary read / write I / O while ensuring the security of snapshot configuration (including snapshot generation and configuration). This invention's technical solution does not distinguish between snapshot types and is applicable to all types of snapshots.
[0038] The core idea of this invention is that, without snapshot processing, ordinary read / write IO no longer requests full-path snaplocks; instead, it only requests read / write locks on the parent directory of the file being read / written. This effectively reduces mutex lock contention and IO latency involved in snapshot processing. Furthermore, to ensure the reliability of snapshot services, a pre-check process is added to the snapshot configuration process. This pre-check ensures that no read / write requests requesting non-full-path snaplocks are being executed before snapshot processing begins. This invention reduces mutex lock contention for snapshots in MDS, thereby improving file read / write performance in the distributed file system, especially for small files, and ensuring the reliability of snapshot configuration.
[0039] Based on the basic idea of this invention, the specific implementation process of this invention will be described below in conjunction with the accompanying drawings and specific embodiments.
[0040] The technical solution proposed in this invention optimizes the snapshot locking mechanism of distributed file systems. This optimization includes two parts: optimization of the file read / write process and optimization of the snapshot processing process. In fact, this invention can also be viewed as an optimization of the file read / write process of distributed file systems, because the main objective of this invention is to improve the file read / write performance of distributed file systems, and the optimization of the snapshot processing process serves this objective. The optimization of the file read / write process will be described in detail below.
[0041] After analyzing and summarizing the performance influencing factors and the main use cases of the cluster, it was found that the use cases and scale of ordinary read / write IO are far greater than those of snapshot configuration services. Ordinary read / write IO refers to IO that performs normal business read / write operations on file content, and does not involve snapshot processing, system configuration, or other operations. However, in existing solutions, both ordinary read / write IO and snapshot processing (including snapshot configuration, creation, deletion, and other snapshot-related operations) require acquiring a read / write lock for the entire directory. To optimize performance, this invention will no longer acquire a read / write lock for the entire path in ordinary read / write IO processes.
[0042] For example, in the existing scheme, assuming there are files file1 and file2 under the root directory " / ", and the path of file1 is / data / dir1 / dir2 / file1, to read file1, a full path read lock on the entire root directory path is required. If file2 ( / data / dir1 / dir3 / file2) is to be read at the same time, the full path read lock can only be released after file1 is read. This process severely impacts normal I / O performance. To improve file read / write performance, in this invention, without snapshot handling conflicts, file read / write I / O only needs to acquire non-full path snapshot read / write locks. Therefore, in the example above, for normal I / O processes, when reading / writing file1 and file2, this invention only needs to acquire non-full path snapshot read / write locks on the parent directories dir2 and dir3 respectively, without needing to acquire full path snapshot read / write locks.
[0043] Figure 1 This is a flowchart illustrating the steps of a file read / write method in a distributed file system according to an embodiment of the present invention. The method includes:
[0044] Step 101. During snapshot processing on a client without a snapshot, read / write I / O on files in the root directory only requests non-full path snapshot read / write locks on the parent directory of the file being read / written;
[0045] A snapshot client is a metadata service MDS node that provides metadata services. In a distributed file system, there may be multiple MDS nodes providing metadata services. During snapshot processing (such as generating snapshots, configuring snapshots, etc.), each MDS node acts as a snapshot client, and the snapshot client executes the snapshot processing flow under the control of the snapshot server.
[0046] The root directory can refer to the root directory of the entire distributed file system, or it can refer to the target directory configured to perform snapshot processing. The read / write I / O for files under the root directory refers to read / write I / O operations on any file under the root directory, including any file in subdirectories under the root directory and any file in subdirectories within subdirectories of subdirectories.
[0047] In this invention, a full-path snapshot read / write lock refers to applying a full-directory snapshot read / write lock that applies to the entire root directory. A non-full-path snapshot read / write lock refers to applying a snapshot read / write lock that applies only to the parent directory of the file being read / written. The two types of locks have different scopes. Non-full-path snapshot read / write locks are only used when no snapshot processing has been performed, in order to reduce lock mutual exclusion and improve file read / write performance.
[0048] Step 102. During snapshot processing in the snapshot client, all file read / write I / O operations in the root directory require a full-path snapshot read / write lock;
[0049] To prevent conflicts arising when a snapshot client is performing snapshot processing on a directory, other file read / write I / O operations may attempt to read / write files in the directory by acquiring non-full path snapshot read / write locks. This invention employs a mechanism to ensure that the distributed file system can only perform normal file read / write I / O operations during snapshot processing if it has acquired a full path snapshot read / write lock.
[0050] Step 103. Before the snapshot client executes snapshot processing, it is necessary to wait for all read / write IOs that acquire non-full path snapshot read / write locks to be processed before starting snapshot processing.
[0051] In one embodiment of the present invention, the snapshot client sets a global variable `snaplocking` during the snapshot processing flow to indicate whether file read / write I / O is currently undergoing snapshot processing. `snaplocking` can be a boolean value, defaulting to `false`, indicating no snapshot processing is occurring, and `true`, indicating that snapshot processing is in progress. When the snapshot client starts executing the snapshot processing flow, it sets the snapshot locking flag `snaplocking` to `true`, and when the snapshot processing flow is completed, it sets `snaplocking` to `false`.
[0052] To avoid conflicts between regular read / write I / O and snapshot processing, the snapshot client must wait for the read / write I / O that has acquired a non-full path snapshot read / write lock to complete before it can begin the snapshot processing. In one embodiment of this invention, a global variable (nosnapreq) is provided to count regular read / write I / O. After the read / write I / O lock acquisition (acquire_lock) process is completed, the non-snapshot request count (nosnapreq) is incremented. After the I / O request is completed, the lock release (drop_locks) process is performed, and the nosnapreq count is decremented. The global nosnapreq count can be used to determine whether there are any requests that have not acquired a full path snapshot read / write lock, i.e., whether there are any read / write I / Os that have acquired a non-full path snapshot read / write lock, before the snapshot processing is executed. If so, nosnapreq will be greater than 0. Snapshot processing can only begin when all read / write I / O requests are completed and nosnapreq is set to 0, to prevent data from being modified during the snapshot process.
[0053] Figure 2This is a schematic diagram illustrating the snapshot processing flow of a distributed file system in one embodiment of the present invention. If the IO process no longer acquires the full directory's snaplock read / write lock, the snapshot will be unreliable. To ensure the reliability of snapshot characteristics, the present invention optimizes the snapshot processing flow.
[0054] In the traditional snapshot processing flow, upon receiving a snapshot creation request (i.e., an mksnap request), the client requests a lock, and the snapshot client (snapclient) processes the prepare_create request. During the prepare phase, the snapclient sends a TABLESEVER_OP_PREPARE request to the snapshot server (snapserver), and the snapserver performs handle_prepare processing, which involves allocating the snapid, logging, and other operations. Subsequently, the snapserver sends the snapid and other information to the client to initiate the mksnap request to create the snapshot.
[0055] In this invention, a precheck process is added to the prepare check stage of the snapshot processing flow, such as... Figure 2 The flowchart of the precheck process.
[0056] 1) The snapclient sends a precheck request, i.e., TABLESERVER_OP_PRECHECK, to the snapserver. Then, the snapserver notifies all MDS nodes of the precheck, i.e., the TABLESERVER_OP_PRECHECK sent by the snapserver to snapclient1 and snapclient2 in the diagram.
[0057] 2) After receiving the precheck notification, the Snapclient checks the count of the global variable nosnapreq and sets the snapplocking tag to true (indicating that snapshot processing is in progress), ensuring that subsequent requests acquire full-path snapshot read / write locks. When the nosnapreq count reaches zero (meaning that normal IO has released the read lock and the global count is 0; if the global nosnapreq count is not zero, it continues to retry until the count reaches zero, then proceeds to the next step), it returns the precheck request response, TBLECLIENT_OP_PRECHECKACK, to the snapserver.
[0058] 3) After the snapshot client completes the precheck, it sends a TBLECLIENT_OP_PRECHECKACK message to the snapserver. The snapserver then performs a hadle_precheckack, which checks if all snapshot clients have completed the precheck. Once all clients have responded with TBLECLIENT_OP_PRECHECKACK, the snapserver proceeds with further operations, checking if all clients have responded. Upon receiving a response, the snapserver deletes the corresponding rank. After all clients have responded, the gather size becomes 0, indicating that the precheck is complete. The snapserver then replies to the snapshot client with TABLESERVER_OP_PRECHECKACK (indicating that the precheck is complete), and the snapshot configuration process continues according to the original procedure.
[0059] 4) In the snapshot processing callback function, when the snapshot processing transaction is committed, the snapserver sends a resetsnap request (i.e., a request to reset the snapshot tag) to the corresponding snapclient. The snapclient resets the snapplocking tag, i.e., marks it as false, indicating that the snapshot processing has ended. Subsequent normal read / write IO processes will then follow the optimized normal IO process design of this invention. This part corresponds to... Figure 2 The TABLECLIENT_OP_RESETSNAP process.
[0060] Beneficial effects of the technical solution of this invention
[0061] 1. In user-space environment, normal read / write IO processes no longer require the full directory's snaplock read / write lock. Under the MDS multi-threaded architecture, the contention of related mutex locks caused by snaplock state machine changes is reduced, IO process latency is reduced, and file read / write performance is effectively improved.
[0062] 2. This invention improves business performance while ensuring the reliability of snapshot configuration by adding snapcking, nosnapreq tags and precheck process.
[0063] Figure 3This is a schematic diagram of an electronic device 300 for implementing the file read / write method in the distributed file system provided by the present invention, according to an embodiment of the present invention. The device 300 includes a processor 310, such as a central processing unit (CPU), a communication bus 320, a communication interface 340, and a memory 330. The processor 310 and the memory 330 can communicate with each other via the communication bus 320. The memory 330 stores a computer program, which, when executed by the processor 310, implements one or more steps of the file read / write method in the distributed file system provided by the present invention.
[0064] Memory refers to a device based on a storage medium used to store computer programs and / or data. It can be volatile memory (VM, often called main memory) or non-volatile memory (NVM). Main memory refers to internal storage that directly exchanges data with the processor. It can read and write data at any time and at high speed, serving as a storage medium for temporary data of the operating system and other running programs. Main memory can be Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), etc. Non-volatile memory refers to memory that uses persistent storage media, characterized by large capacity and persistent data retention. It can be Storage Class Memory (SCM), Solid State Drive (SSD), NAND flash memory, hard disks, etc. SCM is an industry term for a new type of storage medium that falls between main memory and flash memory. It is a composite storage technology that combines the characteristics of persistent storage and main memory, with access speeds slower than DRAM but faster than SSDs.
[0065] The processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0066] It should be recognized that embodiments of the present invention can be implemented or carried out by computer hardware, a combination of hardware and software, or by computer instructions stored in non-transitory (or non-persistent) memory. The method can be implemented using standard programming techniques, including a non-transitory storage medium configured with a computer program within the computer program, wherein such a storage medium causes the computer to operate in a specific and predefined manner. Each program can be implemented in a high-level procedural or object-oriented programming language to communicate with the computer system. However, if desired, the program can be implemented in assembly or machine language. In any case, the language can be a compiled or interpreted language. Furthermore, for this purpose, the program can run on a programmed application-specific integrated circuit. Moreover, the operations of the processes described in this invention can be performed in any suitable order unless otherwise indicated by the invention or otherwise clearly contradicted by the context. The processes (or variations and / or combinations thereof) described in this invention can be executed under the control of one or more computer systems configured with executable instructions and can be implemented by hardware or a combination thereof as code (e.g., executable instructions, one or more computer programs, or one or more applications) that commonly executes on one or more processors. The computer program includes a plurality of instructions executable by one or more processors.
[0067] Furthermore, the method can be implemented in any suitable type of computing platform, including but not limited to personal computers, minicomputers, mainframes, workstations, networked or distributed computing environments, standalone or integrated computer platforms, or in communication with charged particle tools or other imaging devices. Aspects of the invention can be implemented as machine-readable code stored on a non-transitory storage medium or device, whether removable or integrated into a computing platform, such as a hard disk, optical read and / or write storage medium, RAM, ROM, etc., such that it is readable by a programmable computer, and when the storage medium or device is read by the computer, it can be used to configure and operate the computer to perform the processes described herein. Furthermore, the machine-readable code, or portions thereof, can be transmitted via wired or wireless networks. The invention includes these and other different types of non-transitory computer-readable storage media when such media comprises instructions or programs that implement the steps described above in conjunction with a microprocessor or other data processor. When programmed according to the methods and techniques described in the invention, the invention also includes the computer itself.
[0068] The above description is merely an embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of protection of the present invention.
Claims
1. A file read / write method in a distributed file system, characterized in that, The methods include: During snapshot processing on a client without a snapshot, read / write I / O on files in the root directory only requests non-full path snapshot read / write locks on the parent directory of the file being read / written; During snapshot processing by the snapshot client, all read / write I / O operations on files in the root directory require a full-path snapshot read / write lock. Before the snapshot client executes snapshot processing, it must wait for all read / write IO operations that acquire non-full path snapshot read / write locks to be completed before starting snapshot processing. The file read / write I / O uses a snapshot lock flag to determine whether a snapshot is currently being processed; The snapshot lock flag is set to true by the snapshot client before snapshot processing is performed and set to false after snapshot processing is performed. The snapshot lock flag is a global variable.
2. The method according to claim 1, characterized in that, The file read / write I / O is indicated by the non-snapshot request count, which indicates that there are currently read / write I / O operations that have acquired non-full path snapshot read / write locks. The non-snapshot request count is a global variable. The file read / write I / O increments the non-snapshot request count by one after successfully acquiring a non-full path snapshot read / write lock, and decrements the non-snapshot request count by one after releasing the non-full path snapshot read / write lock.
3. The method according to claim 1, characterized in that, The method of waiting for all read / write IOs that acquired non-full path snapshot read / write locks to be processed before starting the snapshot processing step is as follows: Before performing snapshot preparation, the snapshot client initiates a pre-check process to set a snapshot lock flag to notify that file read / write IO is currently undergoing snapshot processing, and waits for the read / write IO that has acquired a non-full path snapshot read / write lock to complete by using a non-snapshot request count.
4. The method according to claim 3, characterized in that, The pre-inspection process includes: Before performing snapshot preparation, the snapshot client initiates a pre-check process, which includes: The snapshot client notifies the snapshot server to initiate a pre-check step. The snapshot server notifies all snapshot clients in the distributed file system to perform a pre-check. Upon receiving a notification to perform a pre-check, the snapshot client updates the snapshot lock flag to true. The snapshot client cyclically checks whether the non-snapshot request count is 0. When it determines that the non-snapshot request count is 0, it sends a pre-check response to the snapshot server. When the snapshot server receives the pre-check responses from all snapshot clients, it notifies the snapshot client that initiated the pre-check step to perform the snapshot preparation step.
5. The method according to claim 3, characterized in that, The method further includes: After receiving a notification from the snapshot server to reset the snapshot tag, the snapshot client updates the snapshot lock flag to false to indicate that the file read / write IO snapshot processing flow has been completed.
6. A file read / write device in a distributed file system, characterized in that, The device includes: The first lock request module is used to request non-full path snapshot read / write locks on the parent directory of the file being read / written during snapshot processing on a client without a snapshot. The second lock request module is used to request a full-path snapshot read / write lock for all file read / write I / O operations in the root directory during snapshot processing by the snapshot client. The file read / write I / O operation is used to determine whether snapshot processing is currently in progress by using a snapshot lock flag. The snapshot lock flag is set to true by the snapshot client before snapshot processing is performed and set to false after snapshot processing is completed. The snapshot lock flag is a global variable.
7. A snapshot processing device in a distributed file system, characterized in that, The device is used in the snapshot client, and the device includes: The pre-check module is used by the snapshot client to set a snapshot lock flag by initiating a pre-check process before performing snapshot preparation, so as to notify that file read / write IO is currently being processed for snapshot, and to wait for the read / write IO that has acquired a non-full path snapshot read / write lock to be completed by using a non-snapshot request count. The global tag update module is used by the snapshot client to update the snapshot lock tag to false after receiving a notification from the snapshot server to reset the snapshot tag, so as to notify that the file read / write IO snapshot processing flow has been completed.
8. An electronic device, characterized in that, It includes a processor, a communication interface, a storage medium, and a communication bus, wherein the processor, the communication interface, and the storage medium communicate with each other through the communication bus; Storage medium used to store computer programs; A processor, when executing a computer program stored on a storage medium, performs the method steps of any one of claims 1-5.
9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it performs the method as described in any one of claims 1 to 5.
Citation Information
Patent Citations
IO speed optimization method and system for distributed storage, terminal and storage medium
CN113485639A