Single file reading and writing method and system of distributed file system

Abstract

The invention discloses a single-file concurrent read-write method and system of a distributed file system. The method comprises the steps that S1, a conservative write range lock application request of a preset interval is sent to a metadata server; the range lock takes a block as the minimum granularity; s2, segmenting to-be-written data into a plurality of data blocks according to a preset block length, and applying for a corresponding locking interval in a local memory lock table according to a starting position and an ending position of each data block in a target file; judging whether the currently applied locking interval is overlapped with the registered locking interval or not; s3, if the data block is not in the write range lock, applying for an interval for expanding the write range lock from the metadata server; s4, distributing the segmented data block write-in requests to block engines of corresponding storage nodes, so that the block engines add data block mutual exclusion locks at corresponding positions; and S5, in response to a request of closing or refreshing the target file by the user, sending a request of releasing the write range lock interval. According to the method and the device, the performance is not reduced on the premise of improving the strong consistency.

Description

Technical Field

[0001] This application relates to the field of file locking technology, and in particular to a method and system for concurrent single-file read and write of a distributed file system. Background Technology

[0002] Range locking in distributed file systems (FS) is a crucial feature in high-performance computing (HPC) scenarios, designed to address the challenge of multiple applications concurrently reading and writing to the same file. FS typically uses file locks to ensure data consistency in this environment. This means that if an application wants to modify only one record (perhaps just a few hundred bytes) in a 100GB database file, it needs to lock the entire 100GB file, forcing all other applications attempting to modify or query different records to wait in a queue. To overcome this bottleneck, byte-range locking, or range locking for short, was developed.

[0003] The core idea of ​​range locks is to refine the lock granularity from the file level to the byte range to improve concurrency. However, implementing range locks with high concurrency, strong consistency, and a simple architecture in a distributed environment remains a challenge for the industry.

[0004] Currently, most mainstream open-source systems use centralized lock management, including the following solutions:

[0005] (1) To avoid complex distributed processing logic, CephFS supports the POSIX interface fcntl at the protocol level to implement range locking. It is not a range locking function provided by the FS core software in a strict sense, so the concurrency performance is very poor. However, its client caching based on Caps, centralized lock management of MDS, and IO mechanism allow CephFS to meet the requirement of strong data consistency. Thus, this approach can significantly improve the performance of multi-file concurrency. However, when strong consistency is required, it will increase the code implementation complexity of single-file concurrency, resulting in poor single-file concurrency performance. It cannot effectively solve the performance bottleneck problem of multiple applications concurrently reading and writing the same file in HPC.

[0006] (2) DeepSeek-3FS adopts an end-to-end cacheless architecture, so there is no need to negotiate client-side cached data. At the same time, it weakens the requirement for strong data consistency, only performing mutual exclusion at the data slicing granularity on the server side, and directly removing file locks through private clients. This requires the upper-layer application to handle business mutual exclusion, otherwise it will lead to semantic-level out-of-order operations when a single client or multiple clients operate on the same file; this method does not guarantee strong data consistency, especially in the case of multiple clients, which requires the upper-layer application to avoid or handle it. Therefore, the application generally needs to be customized and cannot be simple and easy to use.

[0007] (3) In Lustre, the range lock is requested from the centralized lock manager through the storage service process (a client that is not a FS mount point). This is combined with client-side cached aggregation of IO (at the file level) to reduce the number of range lock interactions, thereby reducing the overall performance degradation caused by the introduction of range locks and meeting the range lock requirements in HPC scenarios. In addition, Lustre's default configuration relies on external storage for redundancy rather than the file system's built-in multiple replicas, resulting in a lack of reliability. Furthermore, there is only one storage service process per storage node, which allows the storage service process to act as a client requesting range locks, further aggregating IO and reducing the number of range lock requests. This approach relies on the integration and optimization of the entire product, resulting in strong architectural coupling and complex code implementation.

[0008] In summary, existing methods lack a distributed file system range locking solution that simultaneously achieves "high concurrency for single files, strong data consistency, high reliability, and simplicity and universality". Summary of the Invention

[0009] Based on this, and in response to the aforementioned technical problems, a single-file concurrent read / write method and system for a distributed file system is provided to address the lack of existing technologies that simultaneously achieve "high concurrency of single files, strong data consistency, high reliability, and simplicity and universality".

[0010] Firstly, a single-file concurrent read / write method for a distributed file system, applied to a client, the method comprising:

[0011] Step S1: When opening the target file, send a conservative write range lock request for a preset range to the metadata server, and execute step S2 after successfully receiving the request; the range lock is in blocks as the smallest granularity.

[0012] Step S2: In response to the user's request to write data to be written, the data to be written is divided into multiple data blocks according to a predetermined block length, and the start and end positions of each data block in the target file are used as independent locking units. The corresponding locking intervals are sequentially requested in the local memory lock table. If the currently requested locking interval does not overlap with the registered locking interval, then proceed to step S3.

[0013] Step S3: Determine whether the start and end positions of the data block in the target file are within the write range lock. If yes, proceed to step S4. If no, apply to the metadata server for an extended write range lock based on the start and end positions of the data block in the target file. If successful, proceed to step S4.

[0014] Step S4: Distribute the write requests of the multiple data blocks to the block engines of the corresponding storage nodes according to the cluster disk layout algorithm, so that the block engine adds a data block mutex lock at the corresponding position before writing the data block, and releases it after writing; and waits for the write completion information sent by the data storage server;

[0015] Step S5: In response to the user's request to close or refresh the target file, send a request to the metadata server to release the write range lock interval.

[0016] Optionally, in the above scheme, after sending a write range lock request for a preset range to the metadata server, the method further includes:

[0017] Upon receiving a failed application message, the server continues to wait for a set time so that the metadata server can reclaim the write range lock from the client occupying the preset range.

[0018] If a successful application message is received within the set time, step S2 is executed; if a successful application message is not received within the set time, a write range lock application request for the preset range is resent to the metadata server.

[0019] Optionally, in the above scheme, after requesting an extended write range lock interval from the metadata server based on the start and end positions of the data block in the target file, the scheme further includes:

[0020] Upon receiving a failed application message, the server continues to wait for a set time so that the metadata server can reclaim the write range lock from the client occupying the preset range.

[0021] If a successful application message is received within the set time, step S4 is executed; if a successful application message is not received within the set time, a new request for an extended write range lock is sent to the metadata server.

[0022] Optionally, in the above scheme, after applying for the corresponding locking interval in the local memory lock table, the process further includes: if the currently applied locking interval overlaps with the registered locking interval, then wait until the overlap is eliminated, and then execute step S3.

[0023] Optionally, when opening the target file, the method further includes: sending a conservative read range lock request for a preset range to the metadata server and waiting for the response from the metadata server; the metadata server will determine whether the read range lock is within the range of internally stored and already occupied write range locks; if so, it is determined that there is a conflict; if the read range lock is only within the range of internally stored and already occupied read range locks, it is determined that there is no conflict.

[0024] Optionally, in the above scheme, the client adopts a cache-free architecture, where the data to be written is directly written to the target file, and no copy of the data to be written is kept in local memory.

[0025] In the above scheme, optionally, waiting for the write completion information sent by the data storage server specifically includes: after receiving the write completion response from all replicas or erasure coding fragments, outputting a success message for this write operation.

[0026] Secondly, a single-file concurrent read / write system for a distributed file system, the system comprising:

[0027] Write range lock request module: When opening a target file, it sends a write range lock request request for a preset range to the metadata server, and after successfully receiving the request, it executes the local memory lock table to lock the range request module; the range lock is in blocks as the smallest granularity;

[0028] The local memory lock table lock interval application module is used to respond to the user's write request for data to be written, divide the data to be written into multiple data blocks according to a predetermined block length, and use the start and end positions of each data block in the target file as independent locking units to apply for corresponding lock intervals in the local memory lock table in sequence; if the currently applied lock interval does not overlap with the registered lock interval, the write range lock interval expansion module is used.

[0029] Write range lock interval extension module: used to determine whether the offset range of the data block in the target file is within the write range lock. If yes, the write range lock interval release module is executed. If no, the metadata server is requested to extend the write range lock interval according to the start and end positions of the data block in the target file. If successful, the data writing module is executed.

[0030] The data writing module is used to distribute the write requests of the multiple data blocks to the block engine of the corresponding storage node according to the cluster disk layout algorithm. Before writing the data block, the block engine adds a data block mutex lock at the corresponding position and releases it after writing. It also waits for the write completion information sent by the data storage server.

[0031] Write range lock interval release module: In response to a user's request to close or refresh the target file, it sends a request to the metadata server to release the write range lock interval.

[0032] Thirdly, a computer device includes a memory and a processor, the memory storing a computer program, the processor executing the computer program to perform the steps of the single-file concurrent read / write method of a distributed file system described in the first aspect above.

[0033] Fourthly, a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the single-file concurrent read / write method of a distributed file system described in the first aspect.

[0034] This application has at least the following beneficial effects:

[0035] This invention applies a conservative write range lock that is applied for block alignment once during the file opening stage. When writing data, only a single remote expansion is needed for out-of-bounds blocks, and local sequential locking is performed with blocks as the smallest locking unit. At the same time, the storage node applies a mutex lock to the physical block instance, forming a three-level conflict control of "local client filtering first, metadata cluster server verification second, and mutual exclusion within the storage node". This improves the strong consistency premise by reducing the number of lock interactions from each write operation to only when expanding, allowing a single file to be read and written in parallel by multiple clients without performance degradation. At the same time, the architecture is loosely coupled, has no cache dependency, and combines high concurrency, high reliability and simplicity. Attached Figure Description

[0036] Figure 1 A flowchart illustrating a single-file concurrent read / write method for a distributed file system provided in one embodiment of this application;

[0037] Figure 2 This is a detailed flowchart illustrating a single-file concurrent read / write method for a distributed file system, as provided in one embodiment of this application.

[0038] Figure 3 This is a schematic diagram of the range lock in a single-file concurrent write method of a distributed file system provided in one embodiment of this application, involving the client, metadata server, and data storage service server.

[0039] Figure 4 This is a flowchart illustrating a single-file concurrent write method for a distributed file system provided in one embodiment of this application, where one client performs read-only operations and another client performs write-only operations. Detailed Implementation

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

[0041] To improve concurrency, file lock granularity is refined to range lock granularity. The core challenge is to reduce the number of distributed lock interactions in the cluster while ensuring data consistency, achieving significant performance improvement in single-file concurrency without substantial performance degradation in non-profitable scenarios. Therefore, this invention aims to address the following four technical challenges simultaneously under a specific concurrent read / write model (with most writes being sequential):

[0042] 1. Whether mounting a file system with a single client or multiple clients, range locking can significantly improve performance in scenarios with concurrent read and write operations on a single file.

[0043] 2. In non-single-file concurrent read / write scenarios (non-benefit scenarios), the overall performance loss caused by the introduction of range locks in the IO path is almost zero;

[0044] 3. After range locking supports concurrent operations on a single file, the distributed file system can achieve strong distributed consistency.

[0045] 4. The technical architecture is loosely coupled, the solution is simple, the implementation complexity is low, and complex distributed processing logic is avoided as much as possible, so as to make it simple and easy to use.

[0046] In one embodiment, such as Figure 1 and Figure 2 As shown, a single-file concurrent read / write method for a distributed file system is provided, applied to a client. The method includes:

[0047] Step S1: When opening the target file, send a conservative write range lock request for a preset range to the metadata server, and execute step S2 after successfully receiving the request; the range lock is in blocks as the smallest granularity.

[0048] In step S1, as Figure 3 As shown, the FS client aligns the sliced ​​data to the chunk size and uses read / write range locks instead of regular file locks. Figure 3 The converted write range lock of Client-1 is 10MB-13MB. If Client-1 also has a converted read range lock of the same file with a range of 9MB-10MB, then these two read and write operations can be sent in parallel.

[0049] In the centralized management cluster of the metadata server, the range lock information currently held by multiple mount point clients is persisted to a shared key-value database along with the inode (file ID). This is combined with requesting a conservative lock range during open file read / write mode, flushing the file to refresh the lock range, and releasing the file to release the lock. The lock range is then checked as needed during read / write operations to reduce the frequency of distributed lock information synchronization. For example... Figure 3If Client-1 is writing to a region beyond 10MB (10MB - MAX), then Client-2's attempt to write to a region beyond 12MB will fail and wait. However, Client-3 can successfully read a range of 9MB-10MB (if the read data does not include a termination offset, it can be set to the maximum offset already written, or the maximum block size in a single write operation; alternatively, the MAX value of the write range can be conservatively set to the current write position to the end of the file, or to the write start offset plus the maximum block size in a single VFS write operation). This method enables concurrent writing by Client-1 and reading by Client-3 across multiple clients on a single file.

[0050] Step S2: In response to the user's request to write data to be written, the data to be written is divided into multiple data blocks according to a predetermined block length, and the start and end positions of each data block in the target file are used as independent locking units. The corresponding locking intervals are sequentially requested in the local memory lock table. If the currently requested locking interval does not overlap with the registered locking interval, then proceed to step S3.

[0051] In step S2, the local client now checks whether the start and end positions of the data block exceed the registered locking range, and the local client performs initial conflict control.

[0052] Step S3: Determine whether the start and end positions of the data block in the target file are within the write range lock. If yes, proceed to step S4. If no, apply to the metadata server for an extended write range lock based on the start and end positions of the data block in the target file. If successful, proceed to step S4.

[0053] In step S3, it is determined whether the start and end positions of the data block in the target file are within the write range lock. If not, the range lock is extended. Conflict control is then performed a second time.

[0054] Step S4: Distribute the write requests of the multiple data blocks to the block engines of the corresponding storage nodes according to the cluster disk layout algorithm, so that the block engine adds a data block mutex lock at the corresponding position before writing the data block, and releases it after writing; and waits for the write completion information sent by the data storage server.

[0055] In step S4, on the data storage service side: the Chunk engine shares Chunk resources across the cluster, and Chunk access is handled with mutex locks to manage foreground / background mutual exclusion (asynchronous deletion & read / write), COW, etc. Data blocks are distributed to the corresponding storage node's block engine on the storage server, ensuring that a mutex lock is added before writing. This is the third time conflict control is performed.

[0056] Step S5: In response to the user's request to close or refresh the target file, send a request to the metadata server to release the write range lock interval.

[0057] In this embodiment, the core point of this application is:

[0058] 1. Both the FS client and data storage end handle file read and write data at the file slice (chunk) granularity: the client splits file data into chunks, and the byte-level range is converted into a range aligned to the chunk size for lock acquisition and release. At the same time, according to the cluster disk layout algorithm, chunks are distributed across all disks, and data redundancy protection is performed on the disks in chunk units using multiple replicas or erasure coding;

[0059] 2. The FS client adopts a data-cache-free technical solution, which simplifies the logic of parallel file read and write consistency processing while effectively improving concurrency by leveraging high-speed networks;

[0060] 3. The client uses a local runtime range read-write lock instead of a regular file lock, supporting concurrent read and write operations for a single file at a single mount point;

[0061] 4. Centralized Lock Management for Metadata Services: When handling range locks, it's typically necessary to request a range lock for each data read / write operation. This patent optimizes this by combining file-level opcode granularity with range lock requests, reducing the number of range lock requests during actual data read / write operations and supporting concurrent read / write of a single file across multiple mount points.

[0062] 5. In the data storage service, each chunk on the disk is protected by a mutex lock and supports modification and writing; it implements basic data protection in the most basic chunk-level processes such as foreground read and write, background migration, asynchronous deletion, etc.

[0063] In other words, on a data-slicing-based, cacheless distributed FS architecture, a lock mutual exclusion mechanism is customized at three levels: client, metadata server, and data storage service. This enables efficient implementation of a simple, distributed, strongly consistent file range lock function, meeting the requirements for high-concurrency read and write of a single file, especially in scenarios where most write operations are sequential.

[0064] In this embodiment, the key process of the range locking mechanism of this application is as follows:

[0065] 1. When the client opens a file, it accesses the metadata service and sets a conservative write range in the metadata service (which may cause registration conflicts).

[0066] 2. After receiving a write IO, the client first performs data slicing based on the set chunk size, turning a single IO into a batch of chunk requests;

[0067] 3. The client requests a local range read / write lock with a range aligned to a chunk, checks for range conflicts within the same client, and waits if a conflict is found.

[0068] 4. Since the client already has Inode and metadata service cluster lock information locally, if the write range belongs to a subset of the lock range already acquired on this client, there is no need to request a cluster range lock from the metadata service; otherwise, a cluster range lock needs to be requested.

[0069] 5. Request a range lock from the metadata service for the cluster. At this time, the metadata service has the conservative file read / write ranges for all clients, used to check for conflicts between multiple clients. If a conflict is found, wait for the metadata service to actively reclaim the published lock range until a timeout occurs, triggering an IO retry. After successfully acquiring the lock, the range lock information in the metadata service needs to be refreshed.

[0070] 6. The client distributes chunk write requests to the corresponding node's chunk engine according to the cluster disk layout algorithm, and adds a chunk mutex lock before the chunk engine operates on the chunk.

[0071] 7. Once all chunks in the storage service cluster have been processed, the write operation is complete.

[0072] 8. After the operation is completed, when the client receives a file flush / close / release command, it notifies the metadata server to release the lock information.

[0073] In practice, the mutual exclusion locks used for intervals are implemented using a read-write lock mechanism (the requested interval has read / write attributes). Therefore, the main difference between writing and reading simultaneously in a single file and concurrent writing in a single file is in the conditions for determining whether there is a conflict (for the same interval segment, writing and reading are conflicting, but reading is not conflicting). All other processes are the same.

[0074] The metadata service process in the cluster needs to record the distribution of intervals published by multiple clients in the cluster. This interval is registered initially and then expanded on demand. It doesn't need to interact with the metadata service with every I / O operation, thus improving performance. This means that the contiguous interval requested each time an interval is registered / expanded is larger than the interval used for that I / O operation. This is called a conservative interval. The size of the conservative interval is generally set manually. It can be estimated using the following method and optimized based on actual testing:

[0075] 1. It is recommended to set the value to an integer multiple of the slice size. For example, if the chunk size is 512KB, then set it to an integer multiple of 512KB.

[0076] 2. It needs to be able to handle at least a larger IO size than a single Write / Read call from the file system client. For example, in the default kernel file system client, the maximum write IO issued by VFS generally does not exceed 1MB, so the conservative range for a single expansion should be at least larger than 1MB.

[0077] 3. The greater the number of clients operating on the same file or the higher the concurrency of reading and writing to the same file, the smaller the conservative range should be defined; conversely, it can be defined larger.

[0078] 4. The greater the proportion of sequential writes in concurrent operations, the larger the conservative interval can be defined, and vice versa.

[0079] Based on actual testing, with a slice chunk size of 1MB, two kernel FS clients, and a real-world application scenario of sequential bandwidth writes, performance was good with 10-16 chunks (i.e., expanding by 10MB-16MB at a time). This is for reference only.

[0080] In the above-mentioned method for concurrent single-file read / write in a distributed file system, this invention requests a conservative write range lock with block alignment in one go during the file opening phase. When writing data, only a single remote expansion is needed for out-of-bounds blocks, and local sequential locking is performed with blocks as the smallest locking unit. At the same time, the storage node adds a mutex lock to the physical block instance, forming a three-level conflict control of "local client filtering first, metadata cluster server verification second, and mutual exclusion within the storage node". This improves the performance under the premise of strong consistency by reducing the number of lock interactions from each write operation to only when expanding, allowing a single file to be read and written in parallel by multiple clients without performance degradation. At the same time, the architecture is loosely coupled, has no cache dependency, and combines high concurrency, high reliability, and simplicity and versatility.

[0081] In one embodiment, after sending a write range lock request request for a preset range to the metadata server, the method further includes:

[0082] Upon receiving a failed application message, the server continues to wait for a set time so that the metadata server can reclaim the write range lock from the client occupying the preset range.

[0083] If a successful application message is received within the set time, step S2 is executed; if a successful application message is not received within the set time, a write range lock application request for the preset range is resent to the metadata server.

[0084] In one embodiment, after requesting an extended write range lock interval from the metadata server based on the start and end positions of the data block in the target file, the method further includes:

[0085] Upon receiving a failed application message, the server continues to wait for a set time so that the metadata server can reclaim the write range lock from the client occupying the preset range.

[0086] If a successful application message is received within the set time, step S4 is executed; if a successful application message is not received within the set time, a new request for an extended write range lock is sent to the metadata server.

[0087] In one embodiment, after the sequence requests the corresponding locking interval in the local memory lock table, the method further includes: if the currently requested locking interval overlaps with the registered locking interval, then wait until the overlap is eliminated, and then execute step S3.

[0088] In one embodiment, opening the target file further includes: sending a conservative read range lock request for a preset range to the metadata server and waiting for the response from the metadata server; the metadata server will determine whether the read range lock is within the range of internally stored already occupied write range locks, and if so, it will determine that there is a conflict; if the read range lock is only within the range of internally stored already occupied read range locks, it will determine that there is no conflict.

[0089] In this embodiment, such as Figure 4 As shown, when a client performs a read-only operation, it sends a conservative read range lock request for a preset range to the metadata server. The metadata server then checks whether the request falls within a write range lock already held by other clients to determine if there is a conflict. If the request falls within an already held read range lock range, then no conflict is considered. In other words, reads and writes are mutually exclusive, but multiple reads are allowed.

[0090] In one embodiment, the client adopts a cache-free architecture, where the data to be written is directly written to the target file, and no copy of the data to be written is kept in local memory.

[0091] In one embodiment, waiting for the write completion information sent by the data storage server specifically includes: after receiving write completion responses from all replicas or erasure code fragments, outputting a success message for this write operation.

[0092] In one embodiment, a single-file concurrent read / write system for a distributed file system includes:

[0093] Write range lock request module: When opening a target file, it sends a write range lock request request for a preset range to the metadata server, and after successfully receiving the request, it executes the local memory lock table to lock the range request module; the range lock is in blocks as the smallest granularity;

[0094] The local memory lock table lock interval application module is used to respond to the user's write request for data to be written, divide the data to be written into multiple data blocks according to a predetermined block length, and use the start and end positions of each data block in the target file as independent locking units to apply for corresponding lock intervals in the local memory lock table in sequence; if the currently applied lock interval does not overlap with the registered lock interval, the write range lock interval expansion module is used.

[0095] Write range lock interval extension module: used to determine whether the offset range of the data block in the target file is within the write range lock. If yes, the write range lock interval release module is executed. If no, the metadata server is requested to extend the write range lock interval according to the start and end positions of the data block in the target file. If successful, the data writing module is executed.

[0096] The data writing module is used to distribute the write requests of the multiple data blocks to the block engine of the corresponding storage node according to the cluster disk layout algorithm. Before writing the data block, the block engine adds a data block mutex lock at the corresponding position and releases it after writing. It also waits for the write completion information sent by the data storage server.

[0097] Write range lock interval release module: In response to a user's request to close or refresh the target file, it sends a request to the metadata server to release the write range lock interval.

[0098] The advantages of this application are:

[0099] 1. It can significantly improve the performance of concurrent read and write of a single file, especially when the write operation in the IO model is sequential (i.e., writing to the file in a streaming append manner), the improvement effect is very obvious.

[0100] 2. Since there is no overhead for client-side distributed synchronization caching, the range lock information of the metadata server can be persisted to the key-value store along with the inode. For non-profitable scenarios, the added range lock mechanism has almost negligible impact on overall performance due to the absence of lock conflicts and frequent metadata cluster lock interactions.

[0101] 3. The technical solution of this patent has strong data consistency guarantee, and its architecture is simple and easy to implement. Compared with Lustre's range locking mechanism, it is simpler, more secure than DeepSeek-3FS for concurrent data access, and can better solve the performance bottleneck problem of multiple applications concurrently reading and writing the same file, which CephFS cannot solve.

[0102] The core points of this application are:

[0103] 1. This invention achieves fine-grained concurrency control by using a three-layer collaboration of client-side range read / write locks, metadata server-side cluster lock management, and data storage-side chunk mutex locks to apply for and release range locks with slices as the alignment granularity.

[0104] 2. This invention does not rely on FS client caching for acceleration. Instead, it combines file operation characteristics and unique metadata service cluster lock management to reduce the number of cluster lock requests and improve the unlocking and unlocking efficiency of range locks.

[0105] 3. In this invention, cluster-range lock information and Inode information are synchronously and batch-persistently stored, reducing the frequency of operations on the key-value database.

[0106] For specific limitations regarding a single-file concurrent read / write system of a distributed file system, please refer to the limitations of a single-file concurrent read / write method of a distributed file system mentioned above, which will not be repeated here. Each module in the aforementioned single-file concurrent read / write method of a distributed file system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0107] In one embodiment, a computer device, which may be a server, is provided. The computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a single-file concurrent write method of a distributed file system as described above.

[0108] In one embodiment, a computer-readable storage medium is also provided, on which a computer program is stored relating to all or part of the processes in the methods of the above embodiments.

[0109] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

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

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

Claims

1. A single-file concurrent read / write method for a distributed file system, characterized in that, Applied to a client, the method includes: Step S1: When opening the target file, send a conservative write range lock request for a preset range to the metadata server, and execute step S2 after successfully receiving the request; the range lock is in blocks as the smallest granularity. Step S2: In response to the user's request to write data to be written, the data to be written is divided into multiple data blocks according to a predetermined block length, and the start and end positions of each data block in the target file are used as independent locking units. The corresponding locking intervals are sequentially requested in the local memory lock table. If the currently requested locking interval does not overlap with the registered locking interval, then proceed to step S3. Step S3: Determine whether the start and end positions of the data block in the target file are within the write range lock. If yes, proceed to step S4. If no, apply to the metadata server for an extended write range lock based on the start and end positions of the data block in the target file. If successful, proceed to step S4. Step S4: Distribute the write requests of the multiple data blocks to the block engines of the corresponding storage nodes according to the cluster disk layout algorithm, so that the block engine adds a data block mutex lock at the corresponding position before writing the data block, and releases it after writing; and waits for the write completion information sent by the data storage server; Step S5: In response to the user's request to close or refresh the target file, send a request to the metadata server to release the write range lock interval.

2. The single-file concurrent read / write method for a distributed file system according to claim 1, characterized in that, After sending a write range lock request request for a preset range to the metadata server, the process further includes: Upon receiving a failed application message, the server continues to wait for a set time so that the metadata server can reclaim the write range lock from the client occupying the preset range. If a successful application message is received within the set time, step S2 is executed; if a successful application message is not received within the set time, a write range lock application request for the preset range is resent to the metadata server.

3. The single-file concurrent read / write method for a distributed file system according to claim 1, characterized in that, After requesting an extended write range lock from the metadata server based on the start and end positions of the data block in the target file, the process also includes: Upon receiving a failed application message, the server continues to wait for a set time so that the metadata server can reclaim the write range lock from the client occupying the preset range. If a successful application message is received within the set time, step S4 is executed; if a successful application message is not received within the set time, a new request for an extended write range lock is sent to the metadata server.

4. The single-file concurrent read / write method for a distributed file system according to claim 1, characterized in that, The sequence of requesting the corresponding locking interval in the local memory lock table further includes: if the currently requested locking interval overlaps with the registered locking interval, then wait until the overlap is eliminated, and then execute step S3.

5. The single-file concurrent read / write method for a distributed file system according to claim 1, characterized in that, When opening the target file, the process also includes: sending a conservative read range lock request for a preset range to the metadata server and waiting for the response from the metadata server; the metadata server will determine whether the read range lock is within the range of internally stored already occupied write range locks. If so, it is determined that there is a conflict; if the read range lock is only within the range of internally stored already occupied read range locks, it is determined that there is no conflict.

6. The single-file concurrent read / write method for a distributed file system according to claim 1, characterized in that, The client adopts a cache-free architecture, where data to be written is directly written to the target file, and no copy of the data to be written is kept in local memory.

7. The single-file concurrent read / write method for a distributed file system according to claim 1, characterized in that, Waiting for the write completion information sent by the data storage server specifically includes: after receiving write completion responses from all replicas or erasure code fragments, outputting a success message for this write operation.

8. A single-file concurrent read / write system for a distributed file system, characterized in that, The system includes: Write range lock request module: When opening a target file, it sends a write range lock request request for a preset range to the metadata server, and after successfully receiving the request, it executes the local memory lock table to lock the range request module; the range lock is in blocks as the smallest granularity; The local memory lock table lock interval application module is used to respond to the user's write request for data to be written, divide the data to be written into multiple data blocks according to a predetermined block length, and use the start and end positions of each data block in the target file as independent locking units to apply for corresponding lock intervals in the local memory lock table in sequence; if the currently applied lock interval does not overlap with the registered lock interval, the write range lock interval expansion module is used. Write range lock interval extension module: used to determine whether the offset range of the data block in the target file is within the write range lock. If yes, the write range lock interval release module is executed. If no, the metadata server is requested to extend the write range lock interval according to the start and end positions of the data block in the target file. If successful, the data writing module is executed. The data writing module is used to distribute the write requests of the multiple data blocks to the block engine of the corresponding storage node according to the cluster disk layout algorithm. Before writing the data block, the block engine adds a data block mutex lock at the corresponding position and releases it after writing. It also waits for the write completion information sent by the data storage server. Write range lock interval release module: In response to a user's request to close or refresh the target file, it sends a request to the metadata server to release the write range lock interval.

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

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

Images