A file operation method and file operation system for a distributed file system

Abstract

This invention discloses a file operation method and file operating system for distributed file systems. One embodiment of the file operation method includes: in response to the startup of a target business process, loading a dynamically linked library configured based on the LD_PRELOAD mechanism, and obtaining a globally unique process access identifier allocated by the user-space distributed file system server cluster; intercepting system calls related to glibc library files, allocating a unique file descriptor within the process in user space to replace the Linux kernel allocation logic, concatenating the process access identifier and the file descriptor to generate a globally unique file handle, and calling the server cluster interface to complete the file operation; and notifying the server cluster to release access resources when the process exits. This invention relates to the field of distributed storage technology, solves the performance bottleneck problem of existing user-space file systems, effectively eliminates kernel redundancy overhead, and enables an order-of-magnitude improvement in the read and write performance of distributed file systems.

Description

Technical Field

[0001] This invention relates to the field of distributed storage technology, and in particular to a file operation method and file operating system for distributed file systems. Background Technology

[0002] In Linux distributed storage scenarios, user-space distributed file systems based on the FUSE framework are widely used. However, this framework suffers from inherent performance bottlenecks. File operations require redundant data copying between user space and kernel space, and rely on single-channel communication via / dev / fuse, leading to severe blocking and insufficient read / write throughput under high concurrency. To optimize performance, the industry often uses the LD_PRELOAD mechanism to hijack glibc system calls. However, existing solutions have the following problems: when only the read / write interface is hijacked, file descriptors are allocated by the kernel, and the kernel-maintained mapping between file descriptors and file handles is not visible to user space, making optimization solutions unfeasible; when all file-related system calls are hijacked, there is no effective mechanism to ensure a strong one-to-one mapping between file descriptors and handles and the global uniqueness of handles in distributed multi-process and multi-node scenarios, which can easily lead to serious problems such as data corruption and content overwriting.

[0003] Therefore, how to provide a file operation method that can solve the above problems at the same time has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] To address at least one of the aforementioned problems, a first embodiment of the present invention provides a file operation method for a distributed file system, comprising: In response to the startup of the target business process, the dynamic link library is loaded, and communication is established with the server cluster. The process access identifier allocated by the server cluster is obtained and stored in the local memory space of the target business process. The server cluster is a user-space distributed file system server cluster pre-deployed on the Linux operating system. The dynamic link library is loaded by the storage path specified by the LD_PRELOAD environment variable configured on the Linux operating system. It is used to hijack file-related system calls of the glibc library and redirect file operation requests to the server cluster. The process access identifier uniquely represents the target business process in the global scope of the user-space distributed file system. In response to the glibc library file-related system calls initiated by the target business process, the dynamic link library hijacks the glibc library file-related system calls, allocates and maintains a unique file descriptor in the user space of the current process to replace the file descriptor allocation logic of the Linux kernel, concatenates the process access identifier and the file descriptor to generate a globally unique file handle, and uses it as input to call the file operation interface corresponding to the server cluster. After completing the corresponding file operation, the system call execution result is returned to the target business process. In response to the exit of the target business process, the dynamic link library automatically initiates an access disconnection request to the server cluster, so that the server cluster releases the access resources corresponding to the process access identifier and reclaims the resources.

[0005] For example, in the file operation method for a distributed file system provided in some embodiments of this application, the step of establishing communication with the server cluster, obtaining the process access identifier allocated by the server cluster, and storing it in the local memory space of the target business process further includes: The dynamic link library sends a client access request to the server cluster. The client access request carries the unique identifier of the device where the target business process is located and the process ID of the target business process. Receive the process access identifier returned by the server cluster, wherein the process access identifier is a 32-bit unsigned integer allocated by the server cluster through a global bitmap; Write the process access identifier into the local memory space of the target business process.

[0006] For example, in the file operation method for a distributed file system provided in some embodiments of this application, the step of allocating and maintaining a unique file descriptor in the user space of the current process to replace the file descriptor allocation logic of the Linux kernel further includes: A file descriptor bitmap is maintained in the user space of the current process. The file descriptor bitmap is used to record the usage and unused status of all file descriptors in the current process. In response to the glibc library's open system call initiated by the target business process, the dynamic link library hijacks the open system call, extracts the smallest unused 32-bit non-negative integer from the file descriptor bitmap as the unique file descriptor in the current process, and marks the integer as used in the file descriptor bitmap; In response to the close system call of the glibc library initiated by the target business process, the used state of the corresponding file descriptor is released in the file descriptor bitmap and marked as unused.

[0007] For example, in the file operation method for a distributed file system provided in some embodiments of this application, the step of concatenating the process access identifier and the file descriptor to generate a globally unique file handle and using it as an input parameter to call the file operation interface corresponding to the server cluster further includes: Shift the process access identifier, which is in the form of a 32-bit unsigned integer, left by 32 bits to obtain the high-order operation value; Add the 32-bit non-negative integer file descriptor to the high-order operation value to generate a 64-bit non-negative integer globally unique file handle; The file handle is used as the core input parameter of the server cluster file operation interface.

[0008] For example, in the file operation method for a distributed file system provided in some embodiments of this application, the dynamic link library hijacking of the glibc library file-related system calls in response to the glibc library file-related system calls initiated by the target business process further includes: In response to the open system call of the glibc library initiated by the target business process, the dynamic link library hijacks the open system call and obtains the filename, open flag and permission mode parameters of the file to be opened; The system allocates and maintains a unique file descriptor within the user space of the current process, replacing the file descriptor allocation logic of the Linux kernel. The process access identifier and file descriptor are concatenated to generate a globally unique file handle; The file opening interface of the server cluster is called with the file name, open flag, permission mode and file handle as input parameters. The system receives the file open execution result returned by the server cluster, and sends the file descriptor as the return value of the open system call to the target business process.

[0009] For example, in the file operation method for a distributed file system provided in some embodiments of this application, the dynamic link library hijacking of the glibc library file-related system calls in response to the glibc library file-related system calls initiated by the target business process further includes: In response to the read system call of the glibc library initiated by the target business process, the dynamic link library hijacks the read system call and obtains the file descriptor, data buffer address and read length parameters in the system call input parameters; The process access identifier stored in local memory is concatenated with the file descriptor to generate a globally unique file handle; The file read interface of the server cluster is called with the file handle data buffer address and the read length as input parameters. The system receives the file read execution result and read data returned by the server cluster, and sends the file read execution result as the return value of the read system call to the target business process.

[0010] For example, in the file operation method for a distributed file system provided in some embodiments of this application, the dynamic link library hijacking of the glibc library file-related system calls in response to the glibc library file-related system calls initiated by the target business process further includes: In response to the write system call of the glibc library initiated by the target business process, the dynamic link library hijacks the write system call and obtains the file descriptor, the address of the data to be written and the write length parameter in the system call input parameters; The process access identifier stored in local memory is concatenated with the file descriptor to generate a globally unique file handle; The file write interface of the server cluster is called with the file handle, the address of the data to be written and the write length as input parameters. The system receives the file write execution result returned by the server cluster, and sends the file write execution result as the return value of the write system call to the target business process.

[0011] For example, in the file operation method for a distributed file system provided in some embodiments of this application, the dynamic link library hijacking of the glibc library file-related system calls in response to the glibc library file-related system calls initiated by the target business process further includes: In response to the close system call of the glibc library initiated by the target business process, the dynamic link library hijacks the close system call and obtains the file descriptor parameter in the system call input parameters; The process access identifier stored in local memory is concatenated with the file descriptor to generate a globally unique file handle; Using the file handle as input parameter, call the file closing interface of the server cluster; The system receives the file closing execution result returned by the server cluster, releases the maintenance resources of the corresponding file descriptor in the current process's user space, and sends the file closing execution result as the return value of the close system call to the target business process.

[0012] For example, in the file operation method for a distributed file system provided in some embodiments of this application, the step of the dynamic link library automatically initiating an access disconnection request to the server cluster in response to the exit of the target business process, so that the server cluster releases the access resources corresponding to the process access identifier and reclaims the resources, further includes: In response to the exit instruction of the target business process, the dynamic link library reads the process access identifier stored in local memory; Send a client disconnect request carrying the process access identifier to the server cluster; Receive the access disconnection execution result returned by the server cluster and release the storage resources of the process access identifier in the local memory of the current process.

[0013] The second embodiment of the present invention provides a file operating system for a distributed file system, including a user-space distributed file system server cluster, a dynamic link library module, and a target business process module running on a Linux operating system, wherein; The user-space distributed file system server cluster is configured to: assign a globally unique process access identifier to the target business process module to which it is connected; receive file operation requests sent by dynamic link library modules and execute corresponding file operations; and release the access resources of the corresponding process access identifier and complete resource reclamation in response to access disconnection requests. The dynamic link library module is configured to: load via a storage path specified by the LD_PRELOAD environment variable configured in the Linux operating system; intercept file-related system calls of the glibc library; and redirect file operation requests initiated by the target business process module to the user-space distributed file system server cluster. Upon completion of loading of the target business process module, it automatically establishes communication with the user-space distributed file system server cluster, obtains a process access identifier allocated by the user-space distributed file system server cluster, and stores it in the local memory space of the target business process module. This process access identifier uniquely represents the process within the global scope of the user-space distributed file system. The target business process module, in response to system calls related to glibc library files initiated by the target business process module, hijacks the corresponding system calls, allocates and maintains a unique file descriptor within the user space of the current process to replace the file descriptor allocation logic of the Linux kernel; it concatenates the process access identifier and the file descriptor to generate a globally unique file handle, uses the generated file handle as input parameter to call the file operation interface corresponding to the user-space distributed file system server cluster, and returns the system call execution result to the target business process module after completing the corresponding file operation; in response to the exit of the target business process module, it automatically initiates an access disconnection request to the user-space distributed file system server cluster.

[0014] The beneficial effects of this invention are as follows: This invention addresses existing problems by developing a file operation method and file operating system for distributed file systems. It preloads dynamic link libraries using the LD_PRELOAD mechanism, enabling system call hijacking and acquisition of a globally unique process access identifier upon target business process startup. This achieves instance isolation across processes and nodes in distributed scenarios from the access layer. Furthermore, by hijacking all file-related system calls, it autonomously allocates and maintains unique file descriptors within the process in user space, replacing kernel allocation logic and eliminating dependence on kernel-private mapping tables. Simultaneously, it concatenates the globally unique process access identifier with the unique file descriptor within the process to generate a file handle. This two-level unique identifier combination naturally ensures the global uniqueness and strong mapping consistency of the handle, completing the entire user-space closed-loop file operation without additional locking or table lookups. This completely bypasses the performance bottlenecks of the FUSE framework, significantly improving read and write performance, and eliminates the risks of data corruption and resource leaks at the architectural level. It also operates without any intrusion into the business process, allowing for rapid engineering implementation and thus overcoming the problems of existing technologies, demonstrating practical application value. Attached Figure Description

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

[0016] Figure 1 A flowchart illustrating a file operation method for a distributed file system according to an embodiment of the present invention is shown. Figure 2 This diagram illustrates a swimlane diagram of the execution flow for starting the target business process according to an embodiment of the present invention. Figure 3 This diagram illustrates a swimlane diagram of the execution flow of the target business process opening a file, according to an embodiment of the present invention. Figure 4 This diagram illustrates a swimlane diagram of the execution flow of the target business process reading a file, according to an embodiment of the present invention. Figure 5 This diagram illustrates a swimlane diagram of the execution flow of the target business process writing to a file according to an embodiment of the present invention. Figure 6 This diagram illustrates the execution flow swimlane diagram of the target business process closing file according to an embodiment of the present invention; Figure 7 This diagram illustrates a swimlane diagram of the execution flow for exiting a target business process according to an embodiment of the present invention. Figure 8 This diagram illustrates the structural block diagram of a file operating system for a distributed file system according to an embodiment of the present invention. Detailed Implementation

[0017] To more clearly illustrate the present invention, the following description, in conjunction with preferred embodiments and accompanying drawings, further explains the invention. Similar components in the drawings are indicated by the same reference numerals. Those skilled in the art should understand that the specific description below is illustrative rather than restrictive and should not be construed as limiting the scope of protection of the present invention.

[0018] In a prior art embodiment of file operations for a distributed file system, a custom system call interception library is injected through the LD_PRELOAD mechanism to replace the execution entry point of file-related system calls in the glibc library. By replacing the kernel-mode FUSE driver module with a user-mode FUSE Daemon process and replacing the / dev / fuse virtual device with shared memory, the IO processing path that originally needed to be routed to the kernel mode is completely migrated to the user mode. This solves the performance loss problem caused by two context switches between user mode and kernel mode and redundant data copying in the traditional FUSE framework, while maintaining POSIX interface-level compatibility and achieving seamless adaptation of upper-layer applications to the underlying file system optimization. However, this technical solution still has many core flaws. It cannot adapt to the cluster deployment scenario of distributed file systems, nor can it fundamentally solve the practical difficulties after hijacking the full system call of LD_PRELOAD. Specific problems are as follows: First, the file descriptors in this solution are still allocated by the Linux kernel. The kernel-maintained fd-fh mapping relationship is not visible to user space. Its IO request structure even makes file descriptors optional, failing to design a corresponding fd-fh mapping scheme for the full system call hijacking scenario. This results in user space being unable to match the corresponding file handle through the fd in the input parameters after hijacking system calls such as read and write. File operations cannot be executed accurately, and the optimization solution remains only theoretical and cannot be stably implemented in engineering. Second, this solution lacks distributed scenario adaptability and cannot solve the problem of handle duplication conflicts under concurrent access by multiple processes and nodes. Third, this solution cannot guarantee the global uniqueness of file handles and the strong consistency of fd-fh mapping, posing serious resource leakage and data security risks.

[0019] Based on the above questions, such as Figure 1 As shown, one embodiment of the present invention provides a file operation method for a distributed file system, including: In response to the startup of the target business process, the dynamic link library is loaded, and communication is established with the server cluster. The process access identifier allocated by the server cluster is obtained and stored in the local memory space of the target business process. The server cluster is a user-space distributed file system server cluster pre-deployed on the Linux operating system. The dynamic link library is loaded by the storage path specified by the LD_PRELOAD environment variable configured on the Linux operating system. It is used to hijack file-related system calls of the glibc library and redirect file operation requests to the server cluster. The process access identifier uniquely represents the target business process in the global scope of the user-space distributed file system. In response to the glibc library file-related system calls initiated by the target business process, the dynamic link library hijacks the glibc library file-related system calls, allocates and maintains a unique file descriptor in the user space of the current process to replace the file descriptor allocation logic of the Linux kernel, concatenates the process access identifier and the file descriptor to generate a globally unique file handle, and uses it as input to call the file operation interface corresponding to the server cluster. After completing the corresponding file operation, the system call execution result is returned to the target business process. In response to the exit of the target business process, the dynamic link library automatically initiates an access disconnection request to the server cluster, so that the server cluster releases the access resources corresponding to the process access identifier and reclaims the resources.

[0020] This embodiment preloads dynamic link libraries through the LD_PRELOAD mechanism, enabling system call hijacking and acquisition of a globally unique process access identifier upon target business process startup. This achieves instance isolation across processes and nodes in distributed scenarios from the access layer. Furthermore, by hijacking all file-related system calls, it autonomously allocates and maintains unique file descriptors within the process in user space, replacing kernel allocation logic and fundamentally eliminating dependence on kernel-private mapping tables. Simultaneously, it concatenates the globally unique process access identifier with the unique file descriptor within the process to generate a file handle. This combination of two unique identifiers naturally ensures the global uniqueness and strong mapping consistency of the handle. The entire user-space closed-loop file operation can be completed without additional locking or table lookups. This completely bypasses the performance bottlenecks of the FUSE framework, significantly improving read and write performance, and eliminates the risks of data corruption and resource leaks at the architectural level. It also has zero intrusion into the business process, allowing for rapid engineering implementation and thus addressing the problems in existing technologies, demonstrating practical application value.

[0021] Specifically, this embodiment is applied to the field of distributed storage technology, specifically involving the implementation of a user-space distributed file system under the Linux operating system environment. It is adaptable to various business scenarios such as carrier cloud storage services, shared storage for high-performance computing clusters, unstructured data storage for big data analytics platforms, and shared storage for cloud-native containers. It should be noted that this solution is based on the native LD_PRELOAD mechanism of the Linux system. Through a pre-loaded dynamic link library, it intercepts system calls related to glibc library files, redirecting file operation requests initiated by the target business process to a pre-deployed user-space distributed file system server cluster, thus completing the full lifecycle management of files.

[0022] The overall implementation process of this embodiment includes three stages: process access initialization, file operation mapping execution, and process exit resource reclamation. In the process access initialization stage, in response to the startup of the target business process, the dynamic link library is loaded, a communication connection is established with the server cluster, and the process access identifier allocated by the server cluster is obtained and stored in the target business process's local memory space. In the file operation mapping execution stage, in response to system calls related to glibc library files initiated by the target business process, the dynamic link library intercepts the corresponding system calls, allocates and maintains a unique file descriptor within the current process's user space, replacing the Linux kernel's file descriptor allocation logic. The process access identifier and the file descriptor are concatenated to generate a globally unique file handle. The generated file handle is used as input to call the corresponding file operation interface of the server cluster, and after completing the corresponding file operation, the system call execution result is returned to the target business process. In the process exit resource reclamation stage, in response to the exit of the target business process, the dynamic link library automatically initiates an access disconnection request to the server cluster, causing the server cluster to release the access resources corresponding to the process access identifier and complete resource reclamation.

[0023] Compared to the problems existing in the prior art, this embodiment completes the allocation and maintenance of file descriptors in user space, replacing the file descriptor allocation logic of the Linux kernel. This allows dynamic link libraries to master the rules for generating and managing file descriptors, enabling them to complete the correspondence matching between file descriptors and file handles without relying on the mapping relationship maintained by the kernel. Furthermore, this embodiment assigns a globally unique process access identifier to each accessing target business process, and generates a file handle by combining it with a unique file descriptor within the process. This ensures that the generated file handle remains unique globally within the distributed file system, avoiding handle duplication conflicts when multiple processes and nodes access the system concurrently. Moreover, this embodiment achieves a complete closed loop of full system call hijacking through a complete process access, file operation, and process exit design. It does not intrude on the upper-layer target business process and can be adapted without modifying the business process code, thus balancing file operation performance and engineering implementation capabilities in distributed scenarios.

[0024] In an optional embodiment, such as Figure 2 As shown, the process of establishing communication between the dynamic link library and the server cluster, obtaining the process access identifier (connect_id) allocated by the server cluster, and storing it in the local memory space of the target business process further includes: The dynamic link library sends a client access request (client_connect) to the server cluster. The client access request carries the unique identifier of the device where the target business process is located and the process ID of the target business process. Receive the process access identifier returned by the server cluster, wherein the process access identifier is a 32-bit unsigned integer allocated by the server cluster through a global bitmap; Write the process access identifier into the local memory space of the target business process.

[0025] In this embodiment, as Figure 2 As shown, when the target business process starts, it loads a dynamic link library. The dynamic link library sends a client access request (client_connect) carrying the device's unique identifier and process ID to the server cluster. This allows the server cluster to verify the identity of the access process based on these two parameters and to trace the identity of the access process. In case of access anomalies, it can quickly locate the corresponding device and process. The server cluster allocates a 32-bit unsigned integer as the process access identifier (connect_id) through a global bitmap. Each bit in the global bitmap corresponds one-to-one with a 32-bit unsigned integer process access identifier. The value of the bit indicates the usage status of the corresponding process access identifier. The server cluster can quickly obtain the smallest unused integer as the process access identifier by traversing the global bitmap. After allocation, the corresponding bit in the bitmap is marked as used, and the usage status of the process access identifier is synchronized to all nodes in the server cluster through a distributed consistency protocol. The 32-bit unsigned integer is the smallest unused integer currently not occupied in the user-space distributed file system. A value of 0 indicates that the access request execution failed.

[0026] It should be noted that in existing technologies, for multi-process access scenarios in distributed file systems, a centralized hash table is typically used on the server side to record the identity information of the accessing processes, assigning a randomly generated identity identifier to each process. This approach requires the server to maintain complex mapping relationships, and the randomly generated identifiers cannot guarantee global uniqueness under large-scale concurrent access scenarios, easily leading to identifier conflicts. This necessitates additional deduplication and verification logic, increasing the processing overhead on the server side. Furthermore, in existing technologies, the allocation of process access identifiers is not associated with device identifiers or process IDs, making it impossible to trace the identity of accessing processes and hindering the rapid identification of the source of problems when access anomalies occur.

[0027] The allocation method in this embodiment eliminates the need to maintain complex hash tables and additional deduplication logic, ensuring the uniqueness of the allocated process access identifier within the global scope of the distributed file system. This reduces the processing overhead of the server cluster. Furthermore, the 32-bit unsigned integer value range supports concurrent access for 4,294,967,295 processes, which is equivalent to supporting over four billion concurrent processes, thus adapting to the high-concurrency access requirements of ultra-large-scale distributed clusters. The dynamic link library stores the process access identifier in the local memory space of the target business process, allowing subsequent file operations to directly and quickly retrieve the process access identifier from local memory without repeatedly initiating query requests to the server cluster, thereby improving the processing efficiency of file operations.

[0028] In an optional embodiment, the allocation and maintenance of a unique file descriptor (fd) in the user space of the current process, replacing the file descriptor allocation logic of the Linux kernel, further includes: A file descriptor bitmap is maintained in the user space of the current process. The file descriptor bitmap is used to record the usage and unused status of all file descriptors in the current process. In response to the glibc library's open system call initiated by the target business process, the dynamic link library hijacks the open system call, extracts the smallest unused 32-bit non-negative integer from the file descriptor bitmap as the unique file descriptor in the current process, and marks the integer as used in the file descriptor bitmap; In response to the close system call of the glibc library initiated by the target business process, the used state of the corresponding file descriptor is released in the file descriptor bitmap and marked as unused.

[0029] In this embodiment, the dynamic link library maintains a file descriptor bitmap in the user space of the current process. Each bit in the file descriptor bitmap corresponds one-to-one with the usage status of a 32-bit non-negative integer, and each integer corresponds to an available file descriptor. When the target business process initiates an `open` system call, the dynamic link library intercepts the `open` system call, traverses the file descriptor bitmap, extracts the smallest unused 32-bit non-negative integer as the file descriptor corresponding to the opened file, and marks the corresponding bit in the bitmap as used, ensuring that the allocated file descriptor is unique within the current process and preventing duplicate allocation. The 32-bit non-negative integer uniquely corresponds to one opened file instance within the lifecycle of the current target business process. When the target business process initiates a `close` system call, the dynamic link library intercepts the `close` system call, marks the corresponding bit in the file descriptor bitmap as unused, releases the file descriptor, and allows it to be reallocated by subsequent `open` system calls, avoiding file descriptor resource leakage.

[0030] It should be noted that in existing technologies, file descriptors are allocated and maintained by the Linux kernel. The kernel maintains a file descriptor table for each process, recording the correspondence between file descriptors and kernel file structures. This file descriptor table and its corresponding mapping can only be accessed by the kernel; user-space programs cannot obtain its contents. When hijacking system calls of the glibc library using the LD_PRELOAD mechanism, if only system calls such as read and write are hijacked, user-space programs cannot obtain the kernel-maintained mapping between file descriptors and file handles, and cannot match read and write requests to the corresponding file handles, resulting in file operations failing to execute correctly. If all system calls such as open, read, write, and close are hijacked, existing technologies lack a mature and stable user-space file descriptor allocation and maintenance mechanism, which can easily lead to problems such as duplicate file descriptor allocation and resource leaks. Furthermore, it is incompatible with Linux system standards and specifications, causing compatibility issues in upper-layer applications.

[0031] This embodiment, through a user-space file descriptor bitmap, can replace the Linux kernel's file descriptor allocation logic. This allows dynamic link libraries to manage the entire lifecycle of file descriptor allocation, usage, and release without relying on kernel-maintained mapping relationships. It achieves a one-to-one correspondence between file descriptors and file handles, solving the problem of existing technologies where user-space access to kernel mapping relationships prevents implementation. Furthermore, this embodiment uses 32-bit non-negative integers as file descriptors, ensuring compatibility with the standard file descriptor specification of the Linux operating system and avoiding any compatibility issues with the normal operation of upper-layer target business processes.

[0032] In an optional embodiment, the step of concatenating the process access identifier and file descriptor to generate a globally unique file handle (fh) and using it as an input parameter to call the file operation interface corresponding to the server cluster further includes: Shift the process access identifier, which is in the form of a 32-bit unsigned integer, left by 32 bits to obtain the high-order operation value; Add the 32-bit non-negative integer file descriptor to the high-order operation value to generate a 64-bit non-negative integer globally unique file handle; The file handle is used as the core input parameter of the server cluster file operation interface.

[0033] This embodiment generates file handles using a fixed bitwise operation method. The 32-bit process access identifier is left-shifted by 32 bits to form the high 32 bits of the 64-bit file handle, and the 32-bit file descriptor is used as the low 32 bits. The two are then added together to obtain the final 64-bit file handle. Since the process access identifier is unique globally within the distributed file system, and the file descriptor is unique within the current process, the file handle generated using this bitwise operation method is guaranteed to be unique globally within the distributed file system. Mathematically, this avoids handle duplication and hash collisions, eliminating the need for centralized handle allocation and deduplication verification on the server side, reducing server processing overhead, and decreasing interaction latency during the file opening process.

[0034] It should be noted that in existing technologies, file handle generation in distributed file systems typically employs a centralized allocation method on the server side. When a file is opened, the server generates a unique file handle and returns it to the client. This method adds an extra server-side handle allocation interaction to the file opening process, increasing processing latency. Furthermore, the server needs to maintain a global file handle allocation state, which can lead to severe lock contention in high-concurrency scenarios, reducing the system's concurrent processing capabilities. Some existing technologies use client-side local file handle generation, typically employing hash algorithms to calculate file handles based on information such as file path, process identifier, and timestamp. This method cannot mathematically guarantee the global uniqueness of file handles, posing a risk of hash collisions. If a hash collision occurs, different file instances can generate the same file handle, resulting in serious problems such as data corruption and file content overwriting. Additionally, existing technologies cannot establish a deterministic one-to-one mapping between generated file handles and file descriptors, requiring the maintenance of an additional mapping table to store the correspondence between file descriptors and file handles, increasing memory overhead. Moreover, the lookup and update operations of the mapping table require locking, further reducing processing efficiency in high-concurrency scenarios.

[0035] This embodiment uses a fixed-bit operation method to form the final 64-bit file handle by using the 32-bit process access identifier as the high 32 bits and the 32-bit file descriptor as the low 32 bits. This establishes a deterministic, bidirectional, one-to-one mapping between the file handle, process access identifier, and file descriptor. The corresponding file handle can be calculated from the process access identifier and file descriptor, or vice versa. This eliminates the need to maintain an additional mapping table to store the correspondence, reducing memory overhead. It also eliminates the need for locking, querying, and updating the mapping table, improving file operation efficiency in high-concurrency scenarios. The 64-bit non-negative integer file handle generated in this embodiment is compatible with the standard file handle specification of the Linux user-space file system and can be directly recognized and processed by the server cluster without additional format conversion.

[0036] In an optional embodiment, such as Figure 3 As shown, the hijacking of the glibc library file-related system calls initiated by the target business process, in response to such system calls, further includes: In response to the open system call of the glibc library initiated by the target business process, the dynamic link library hijacks the open system call and obtains the filename, open flag and permission mode parameters of the file to be opened; The system allocates and maintains a unique file descriptor within the user space of the current process, replacing the file descriptor allocation logic of the Linux kernel. The process access identifier and file descriptor are concatenated to generate a globally unique file handle; The file opening interface of the server cluster is called with the file name, open flag, permission mode and file handle as input parameters. The system receives the file open execution result returned by the server cluster, and sends the file descriptor as the return value of the open system call to the target business process.

[0037] In this embodiment, as Figure 3As shown, the dynamic link library (DLL) responds to system calls related to glibc library files initiated by the target business process, specifically the `open` system call, by hijacking the corresponding system call. Specifically, after hijacking the `open` system call, the DLL directly allocates file descriptors in user space, replacing the Linux kernel's file descriptor allocation logic. This eliminates the need to request file descriptors from the kernel, avoiding the consumption of kernel file descriptor resources and preventing the exhaustion of kernel file descriptor resources when a large number of files are opened concurrently. After allocating the file descriptor, the DLL directly generates a corresponding file handle using the process access identifier and the file descriptor. This file handle, along with the file open request, is sent to the server cluster. The server cluster can then directly perform the file open operation based on this file handle and establish a mapping between the file handle and file metadata. This eliminates the need to allocate additional file handles for the file instance, simplifying the file open process and reducing processing latency. After receiving a successful file opening result from the server cluster, the dynamic link library returns the user-space allocated file descriptor as the return value of the open system call to the target business process. For the upper-layer target business process, this file descriptor is no different from the file descriptor allocated by the kernel, which conforms to the standard specifications of the Linux system. The upper-layer business process can use it normally without any modification, thus achieving non-intrusive adaptation to the upper-layer business.

[0038] In an optional embodiment, such as Figure 4 As shown, the hijacking of the glibc library file-related system calls initiated by the target business process, in response to such system calls, further includes: In response to the read system call of the glibc library initiated by the target business process, the dynamic link library hijacks the read system call and obtains the file descriptor, data buffer address and read length parameters in the system call input parameters; The process access identifier stored in local memory is concatenated with the file descriptor to generate a globally unique file handle; The file read interface of the server cluster is called with the file handle data buffer address and the read length as input parameters. The system receives the file read execution result and read data returned by the server cluster, and sends the file read execution result as the return value of the read system call to the target business process.

[0039] In this embodiment, as Figure 4As shown, in response to the `read` system call from the glibc library initiated by the target business process, the dynamic link library, after intercepting the `read` system call, directly obtains the file descriptor from the system call input parameters. Combined with the process access identifier stored in local memory, it generates the corresponding file handle through fixed bitwise operations. Without consulting any mapping table, it quickly obtains a unique file handle corresponding to the file descriptor, resulting in extremely low processing overhead and no need for locking operations. It maintains stable processing efficiency even in high-concurrency scenarios. Furthermore, since the file handle is deterministically generated using the process access identifier and the file descriptor, as long as the process access identifier and file descriptor are correct, the generated file handle will inevitably be unique and correct, preventing mapping errors and ensuring the accuracy of file read operations. In this embodiment, the dynamic link library uses the generated file handle as the core input parameter to call the file reading interface of the server cluster. The server cluster can directly locate the corresponding file instance through the file handle, complete the data reading operation, and return the read data and execution result to the dynamic link library. The dynamic link library returns the execution result as the return value of the read system call to the target business process. The entire processing flow is transparent to the upper-layer target business process, and the upper-layer business process is unaware of any changes in processing logic, which conforms to the standard read system call specification of the Linux system.

[0040] In an optional embodiment, such as Figure 5 As shown, the hijacking of the glibc library file-related system calls initiated by the target business process, in response to such system calls, further includes: In response to the write system call of the glibc library initiated by the target business process, the dynamic link library hijacks the write system call and obtains the file descriptor, the address of the data to be written and the write length parameter in the system call input parameters; The process access identifier stored in local memory is concatenated with the file descriptor to generate a globally unique file handle; The file write interface of the server cluster is called with the file handle, the address of the data to be written and the write length as input parameters. The system receives the file write execution result returned by the server cluster, and sends the file write execution result as the return value of the write system call to the target business process.

[0041] In this embodiment, as Figure 5As shown, in response to the write system call of the glibc library initiated by the target business process, the dynamic link library, after hijacking the write system call, directly generates the corresponding file handle through fixed bit operations using the file descriptor in the input parameter and the process access identifier stored locally. The file handle can be generated without querying the mapping table, ensuring that the write request can match the corresponding file instance and avoiding problems such as writing data to the wrong file or overwriting content. The entire write system call process is completed entirely in user space, without kernel-level context switching or request forwarding via the / dev / fuse device. This eliminates redundant data copying overhead, significantly reduces write operation latency, and improves file write throughput performance in high-concurrency scenarios. In this embodiment, the dynamic link library uses the generated file handle, the address of the data to be written, and the write length as input parameters to call the file write interface of the server cluster. The server cluster locates the corresponding file instance through the file handle, completes the data write operation, and returns the write execution result to the dynamic link library. The dynamic link library then returns the execution result as the return value of the write system call to the target business process. The entire process conforms to the standard write system call specification of the Linux system, is non-intrusive to the upper-layer target business process, and can be adapted without modifying any business code.

[0042] In an optional embodiment, the dynamic link library hijacking of the glibc library file-related system calls in response to the glibc library file system calls initiated by the target business process further includes: In response to the close system call of the glibc library initiated by the target business process, the dynamic link library hijacks the close system call and obtains the file descriptor parameter in the system call input parameters; The process access identifier stored in local memory is concatenated with the file descriptor to generate a globally unique file handle; Using the file handle as input parameter, call the file closing interface of the server cluster; The system receives the file closing execution result returned by the server cluster, releases the maintenance resources of the corresponding file descriptor in the current process's user space, and sends the file closing execution result as the return value of the close system call to the target business process.

[0043] In this embodiment, as Figure 6As shown, in response to the `close` system call from the glibc library initiated by the target business process, the dynamic link library, after intercepting the `close` system call, generates a corresponding file handle using the file descriptor in the input parameters and the process access identifier in local storage. It then calls the file close interface of the server cluster, notifying the server cluster to release the file resources corresponding to that file handle, thus completing the file instance closure operation. Simultaneously, upon receiving a successful file closure result from the server cluster, the dynamic link library releases the occupied state of the corresponding file descriptor in the user-space file descriptor bitmap, marking it as unused. This allows the file descriptor to be reallocated by subsequent `open` system calls, achieving full lifecycle management of file descriptor resources, avoiding file descriptor resource leaks, and ensuring long-term stable process operation. Throughout the entire `close` system call processing flow, file descriptor release management is entirely completed in user space, without requiring state synchronization with the kernel. This simplifies the processing flow, avoids inconsistencies between kernel and user-space states, and ensures that the file handle resources of the server cluster are released normally, preventing resource leaks and improving the operational stability of the distributed cluster.

[0044] In an optional embodiment, such as Figure 7 As shown, in response to the exit of the target business process, the dynamic link library automatically initiates an access disconnection request to the server cluster, so that the server cluster releases the access resources corresponding to the process access identifier and reclaims the resources, which further includes: In response to the exit instruction of the target business process, the dynamic link library reads the process access identifier stored in local memory; Send a client disconnect request carrying the process access identifier to the server cluster; Receive the access disconnection execution result returned by the server cluster and release the storage resources of the process access identifier in the local memory of the current process.

[0045] In this embodiment, as Figure 7As shown, when the dynamic link library detects an exit instruction from the target business process, it automatically reads the process access identifier stored in local memory, sends a client disconnect request to the server cluster, and notifies the server cluster to release the access resources corresponding to the process access identifier, including access instance information maintained in the server cluster, file resources corresponding to all file handles opened by the process, etc. Simultaneously, the server cluster marks the binary bit corresponding to the process access identifier in the global bitmap as unused, allowing the process access identifier to be reallocated by subsequently newly connected processes, achieving the recycling of process access identifier resources and avoiding resource leakage on the server side. In this embodiment, after receiving the access disconnect execution result returned by the server cluster, the dynamic link library releases the storage resources of the process access identifier in local memory and simultaneously releases all file descriptors still in use in the user-mode file descriptor bitmap, avoiding file descriptor resource leakage. This implementation, through a robust process exit resource reclamation mechanism, can complete the release and reclamation of access resources regardless of whether the target business process exits normally or abnormally, ensuring the resource utilization and long-term operational stability of the distributed cluster.

[0046] To further illustrate the specific implementation of this application, a complete file operation process is used as an example. This process covers the entire lifecycle from pre-deployment environment, process startup and access, file opening, file reading, file writing, file closing to process exit and resource reclamation. Specifically, it includes: The first step is to deploy a user-space distributed file system server cluster, set up the LD_PRELOAD environment, and specify the storage path for dynamic link libraries.

[0047] In this embodiment, the deployment of a user-space distributed file system server cluster is first completed. The server cluster is deployed across multiple physical servers running Linux operating systems. Each server runs one server process, and these server processes form a distributed cluster, completing cluster networking, metadata synchronization, and high availability configuration. Each process in the server cluster has complete file operation processing capabilities. The cluster synchronizes metadata internally through a distributed consistency protocol, including the allocation status of process access identifiers and file metadata information, ensuring data consistency across all nodes in the cluster. When one server node fails, the cluster can automatically switch the services of that node to other normally operating nodes, ensuring service continuity and achieving high availability of the cluster.

[0048] The server cluster provides standardized interfaces, including client access, client disconnection, file open, file read, file write, and file close interfaces. The input and return values ​​of each interface follow predefined specifications. Internally, the server cluster maintains a global process access identifier bitmap, a 4294967296-bit binary bitmap. Each bit corresponds to a 32-bit unsigned integer process access identifier. A value of 0 indicates the corresponding process access identifier is unused, and a value of 1 indicates it is in use. Upon server cluster startup, all bits in the bitmap are initialized to 0. After initialization, all interfaces are ready to be called and can receive client access requests and file operation requests.

[0049] After deploying the server cluster, in the Linux operating system environment where the business processes need to run, set the LD_PRELOAD environment variable. The value of this environment variable is the absolute storage path of the pre-compiled dynamic link library. This ensures that the Linux system's dynamic linker prioritizes loading the dynamic link library specified by this environment variable when starting the target business process. The dynamic link library is pre-written in C and compiled based on the CPU architecture and glibc library version of the target business process's runtime environment. This generates a shared library file in .so format that is fully compatible with the runtime environment. This file is placed in a specified directory of the runtime environment, has read and execute permissions, and can be normally loaded into the process's address space by the dynamic linker.

[0050] In this embodiment, the pre-deployment of the server cluster and the configuration of the LD_PRELOAD environment variable provide a basic runtime environment for the subsequent access and file operations of target business processes. There is no need to repeatedly deploy the server cluster and configure environment variables for each business process; deployment and configuration only need to be completed once, and it can be used long-term. When adding new business processes, they only need to inherit the configured LD_PRELOAD environment variable in the environment in which the business process is started. This allows for rapid support for the batch access and deployment of large-scale business processes; it supports the access and use of all business processes in that environment, reducing the deployment and maintenance costs of the solution. In containerized deployment scenarios, the configuration of the LD_PRELOAD environment variable and the dynamic link library file can be written into the container image. All container instances started based on this image will automatically load the dynamic link library and complete the access with the server cluster, eliminating the need for separate configuration for each container instance, further improving the efficiency of large-scale deployment.

[0051] The second step is to start the target business process, load the dynamic link library, establish communication with the server cluster, obtain the process access identifier allocated by the server cluster, and store it in the local memory space of the target business process.

[0052] In this embodiment, the user initiates a startup command for the target business process through the shell terminal of the Linux system. After receiving the process startup command, the Linux system's execve system call invokes the system's dynamic linker to complete the loading and linking of the target business process. The dynamic linker first reads the LD_PRELOAD environment variable configured in the system, obtains the absolute path of the dynamic link library specified in the environment variable, and prioritizes loading the dynamic link library into the virtual address space of the target business process, completing the relocation and symbol resolution of the dynamic link library. Function symbols defined in the dynamic link library with the same names as those in the glibc library are preferentially resolved by the dynamic linker, overriding the corresponding function symbols in the system's native glibc library, thus hijacking the glibc library file-related system calls. After the hijacking takes effect, all subsequent file-related system calls initiated by the target business process will be automatically redirected to the corresponding hijacked functions in the dynamic link library, rather than the native kernel system calls. The entire hijacking process is completely transparent to the target business process.

[0053] After the dynamic link library completes loading and the hijacking takes effect, its internal initialization function is automatically executed. This initialization function establishes a communication connection with the load balancing address of the pre-deployed server cluster via the TCP network protocol. After completing the TCP three-way handshake, it sends a client access request to the server cluster. This request carries the unique device identifier of the server where the target business process resides, as well as the process ID of the target business process. The unique device identifier can be information that uniquely identifies the device, such as the server's motherboard serial number or network card MAC address. The process ID is a unique process identifier assigned by the Linux system to the target business process launched this time. The server cluster can use these two parameters to uniquely identify an accessing process instance, complete identity verification, and simultaneously enable the traceability of the accessing process.

[0054] After receiving a client access request, the load balancer node in the server cluster forwards the request to an available server node within the cluster. This server node verifies the device identifier and process ID in the request. If the verification passes, it iterates through the internally maintained global process access identifier bitmap, finding the first bit with a value of 0 from the least significant bit to the most significant bit. The corresponding 32-bit unsigned integer is used as the process access identifier for this access, and the value of that bit in the bitmap is changed to 1, marking it as used. After allocating the process access identifier, the server node synchronizes this allocation status to all other nodes in the cluster using a distributed consistency protocol. This ensures that all nodes in the cluster can recognize the ownership and usage status of the process access identifier, avoiding duplicate allocation issues. After completing the status synchronization, the server node sends the allocated process access identifier as the return value of the client access request to the dynamic link library through the established TCP connection.

[0055] After receiving the process access identifier returned by the server cluster, the dynamic link library writes the identifier to a specified global variable location in the local memory space of the target business process, thus completing the storage of the process access identifier. In all subsequent file operations, the process access identifier can be quickly read directly from the memory location of this global variable without repeatedly querying the server cluster, thereby improving the processing efficiency of file operations.

[0056] In this embodiment, the target business process's access initialization is completed through dynamic link library loading and process access identifier allocation at process startup. This establishes a globally unique identity for subsequent file operations, achieving isolation between different business processes at the access layer and avoiding resource conflicts between them. Simultaneously, the entire access process is transparent to the target business process; it requires no code modification and is unaware of the access process's existence. It can initiate file operations normally upon startup, achieving non-intrusive adaptation. Even if the target business process is a pre-compiled binary program that cannot be modified, this solution can still achieve adaptation and access to the distributed file system, demonstrating good compatibility and engineering feasibility.

[0057] The third step is to respond to system calls related to the glibc library file initiated by the target business process by hijacking the system calls related to the glibc library file using dynamic link libraries.

[0058] In this embodiment, after the target business process completes startup and access initialization, it begins to execute business logic, sequentially initiating file-related system calls from the glibc library such as open, read, write, and close. The dynamic link library intercepts each system call and completes the corresponding file operation.

[0059] First, the processing of the `open` system call: When the target business process executes its business logic, it needs to open a file at a specified path. Therefore, it initiates an `open` system call, passing in the filename, open flag, and permission mode parameters. The `open` hijacking function in the dynamic link library captures this system call. It first extracts the filename, open flag, and permission mode parameters from the input parameters, and then accesses the file descriptor bitmap maintained in the current process's user space. This bitmap is created during dynamic link library initialization, and initially all bits are 0, indicating that all file descriptors are unused. The dynamic link library traverses the file descriptor bitmap, finding the first bit with a value of 0 from the least significant bit to the most significant bit. It uses the corresponding 32-bit non-negative integer as the file descriptor for this file opening and simultaneously modifies the value of that bit in the bitmap to 1, marking it as used, thus completing the file descriptor allocation.

[0060] After allocating the file descriptor, the dynamic link library (DLL) reads the pre-stored process access identifier from a global variable in local memory, performs bitwise operations, shifts the 32-bit process access identifier left by 32 bits to obtain the high-order bit value, and adds the 32-bit file descriptor to the high-order bit value to generate a 64-bit globally unique file handle. The DLL uses the extracted filename, open flag, permission mode, and generated file handle as input parameters and calls the server cluster's file open interface through a pre-established TCP connection. Upon receiving the file open request, the server cluster uniquely identifies the file instance to be opened using the file handle from the input parameters. Based on the filename, open flag, and permission mode, it performs the file open or creation operation, establishes a mapping between the file handle and the file's physical storage location, file offset, access permissions, and other metadata in the metadata, and returns the file open execution result to the DLL after the operation is complete. If the operation fails, it also returns the corresponding error code.

[0061] After receiving the execution result returned by the server cluster, the dynamic link library returns the allocated file descriptor as the return value of the open system call to the target business process if the file is opened successfully. If the file is opened unsuccessfully, the library returns the corresponding error code as the return value to the target business process, and at the same time modifies the binary bit of the corresponding file descriptor in the file descriptor bitmap to 0, releases the file descriptor, and marks it as unused to avoid resource leaks.

[0062] In this embodiment, the processing of the `open` system call is entirely completed in user space. File descriptors are autonomously allocated by the dynamic link library in user space, effectively replacing the Linux kernel's file descriptor allocation logic. This allows the dynamic link library to fully control the correspondence between file descriptors and file handles, eliminating reliance on a kernel-maintained mapping table. This solves the problem in existing technologies where the user space cannot obtain the mapping relationship, preventing the implementation of solutions. Furthermore, the file handles generated through the process access identifier and file descriptor are unique globally within the distributed cluster, avoiding handle duplication conflicts when multiple processes concurrently open files, and ensuring the accuracy of file operations.

[0063] Next, regarding the processing of the `read` system call, after the target business process receives the file descriptor returned by the `open` system call, it needs to read data from the opened file. Therefore, it initiates the `read` system call, passing in the file descriptor, data buffer address, and read length parameters. The data buffer address is the memory space address allocated by the target business process in memory to store the read data, and the read length is the length of the data in bytes to be read. After the `read` hijacking function in the dynamic link library captures this system call, it extracts the file descriptor, data buffer address, and read length parameters from the input parameters, reads the process access identifier from a global variable in local memory, and adds it to the file descriptor to generate the corresponding 64-bit file handle.

[0064] The dynamic link library (DLL) takes the generated file handle, data buffer address, and read length as input parameters and calls the file read interface of the server cluster through an established TCP connection. Upon receiving the file read request, the server cluster uses the file handle in the input parameters to locate the corresponding file metadata, pinpoints the file's physical storage location, reads the corresponding data from the specified location according to the read length parameter, and returns the read data and the read execution result to the DLL via the TCP connection. The read execution result is the length of bytes successfully read; if the operation fails, it is the corresponding error code.

[0065] After receiving the return result, if the read operation is successful, the dynamic link library writes the read data to the data buffer address specified by the target business process and returns the length of the successfully read bytes as the return value of the read system call to the target business process; if the read operation fails, the corresponding error code is returned as the return value to the target business process.

[0066] In this embodiment, during the processing of the `read` system call, the dynamic link library only needs to use the file descriptor in the input parameters and the process access identifier stored locally to generate the corresponding file handle through fixed bitwise operations. No mapping table needs to be consulted, resulting in extremely low processing overhead. Furthermore, no locking operations are required, maintaining stable processing efficiency even in high-concurrency read scenarios. Simultaneously, the entire read process is completed entirely in user space, without kernel-level context switching or ` / dev / fuse` device forwarding. This eliminates redundant data copying overhead between user space and kernel space, significantly reducing file read processing latency and improving file read throughput performance in high-concurrency scenarios.

[0067] Next, regarding the processing of the `write` system call, after the target business process completes data reading and processing, it needs to write the processed data to the opened file. Therefore, it initiates a `write` system call, passing in the file descriptor, the address of the data to be written, and the write length parameter. The address of the data to be written is the memory space address in the target business process's memory where the data to be written is stored, and the write length is the length of the data in bytes to be written. After the `write` hijacking function in the dynamic link library captures this system call, it extracts the file descriptor, the address of the data to be written, and the write length parameter from the input parameters, reads the process access identifier from local memory, and generates the corresponding 64-bit file handle using the same bitwise operations.

[0068] The dynamic link library (DLL) takes the generated file handle, the address of the data to be written, and the write length as input parameters and calls the file write interface of the server cluster. Upon receiving the file write request, the server cluster locates the corresponding file instance and physical storage location using the file handle, writes the data to be written to the specified offset position in the file, updates the file's metadata, and returns the file write execution result to the DLL after completing the write operation. The execution result is the length of bytes successfully written; if the operation fails, it is the corresponding error code. After receiving the return result, the DLL uses the write execution result as the return value of the `write` system call and returns it to the target business process.

[0069] In this embodiment, the processing of the `write` system call is consistent with that of the `read` system call. A file handle is generated through fixed bitwise operations, ensuring that the write request matches the correct file instance and avoiding the problem of writing data to the wrong file. Simultaneously, the entire write process eliminates redundant data copying between user space and kernel space, significantly reducing write operation latency and improving throughput performance in high-concurrency write scenarios. It is adaptable to various business scenarios such as large file writing and writing massive amounts of small files.

[0070] Next, regarding the processing of the `close` system call, after the target business process completes all read and write operations on the file, it needs to close the opened file and release the corresponding resources. Therefore, it initiates a `close` system call, passing in the file descriptor parameter. The `close` hijacking function in the dynamic link library captures this system call, extracts the file descriptor parameter from the input parameters, reads the process access identifier from local memory, and generates the corresponding file handle through bitwise operations.

[0071] The dynamic link library takes the generated file handle as input and calls the file closing interface of the server cluster. After receiving the file closing request, the server cluster locates the corresponding file instance through the file handle, completes the file closing operation, updates the file's metadata, releases the memory resources corresponding to the file handle, and returns the file closing execution result to the dynamic link library after the operation is completed.

[0072] After receiving the return result, the dynamic link library modifies the corresponding binary bit of the file descriptor in the file descriptor bitmap to 0, releases the occupied state of the file descriptor, marks it as unused, so that the file descriptor can be reallocated by the subsequent open system call. At the same time, the file closing execution result is used as the return value of the close system call and returned to the target business process.

[0073] In this embodiment, the `close` system call process releases the file handle resources on the server cluster and also releases the user-space file descriptor, achieving the recycling of file descriptor resources, avoiding resource leaks, and ensuring the long-term stability of the process. Even if the target business process frequently opens and closes a large number of files, there will be no problem of file descriptor resource exhaustion, supporting the long-term stable operation of the business process.

[0074] The fourth step is to respond to the exit of the target business process by automatically sending a disconnection request to the server cluster to complete resource reclamation.

[0075] In this embodiment, after the target business process completes all business logic, it initiates a process exit command, and the process exit handling function registered in the dynamic link library will be automatically triggered and executed. This handling function first reads the process access identifier stored in the local memory global variable, and then sends a client disconnect request carrying the process access identifier to the server cluster through the established TCP connection.

[0076] After receiving a client's disconnect request, the server cluster releases all access resources corresponding to the process access identifier in the input parameters, including the access instance information of that process maintained in the cluster. Simultaneously, it iterates through all open and unclosed file handles of that process to release corresponding file resources, preventing resource leaks. After completing resource release, the server cluster modifies the binary bit corresponding to the process access identifier in the global process access identifier bitmap to 0, marking it as unused, allowing the identifier to be reallocated by subsequently newly connected processes. After completing resource reclamation, it returns the access / disconnect execution result to the dynamic link library. At the same time, the server cluster synchronizes the release status of the process access identifier to all nodes in the cluster, ensuring consistency of the state within the cluster.

[0077] After receiving the access disconnection execution result returned by the server cluster, the dynamic link library releases the storage resources of the process access identifier in local memory, closes the TCP connection established with the server cluster, and at the same time traverses the file descriptor bitmap, modifies the binary bits corresponding to all file descriptors that are still in use to 0, and completes the unified release of file descriptor resources to avoid resource leaks.

[0078] In this embodiment, an automatic resource reclamation mechanism upon process exit ensures that the server cluster is promptly notified to release corresponding access resources regardless of whether the target business process exits normally or abnormally. This avoids the problems of zombie access instances and resource leaks in the server cluster, improving the long-term operational stability of the distributed cluster. Simultaneously, the unified release of user-space file descriptor resources prevents file descriptor resource leaks from affecting other processes on the host machine, ensuring the stable operation of the host environment.

[0079] This completes the entire file operation process, from process access to file operation and process exit resource reclamation, forming a complete closed loop. By managing the entire lifecycle of file descriptors autonomously in user space, it replaces the Linux kernel's file descriptor allocation logic, solving the problem of existing technologies where user space cannot access the kernel-maintained fd-fh mapping relationship, making the solutions unworkable. By generating file handles using a globally unique process access identifier combined with a unique file descriptor within the process, the uniqueness of file handles across the distributed cluster is mathematically guaranteed, resolving handle duplication conflicts during concurrent access by multiple processes and nodes. Through the hijacking of all system calls, a user-space closed loop for the entire file operation process is achieved, eliminating redundant data copying and communication bottlenecks between user space and kernel space in the traditional FUSE framework, thus improving file operation performance. Furthermore, the entire solution is completely non-intrusive to the target business process at the upper layer, requiring no modification to any business code for adaptation, demonstrating strong engineering feasibility and wide applicability to various distributed storage business scenarios.

[0080] The file operation method for distributed file systems based on the above embodiments, such as Figure 8 As shown, one embodiment of the present invention provides a file operating system for a distributed file system, including: a user-space distributed file system server cluster, a dynamic link library module, and a target business process module running on a Linux operating system, wherein; The user-space distributed file system server cluster is configured to: assign a globally unique process access identifier to the target business process module to which it is connected; receive file operation requests sent by dynamic link library modules and execute corresponding file operations; and release the access resources of the corresponding process access identifier and complete resource reclamation in response to access disconnection requests. The dynamic link library module is configured to: load via a storage path specified by the LD_PRELOAD environment variable configured in the Linux operating system; intercept file-related system calls of the glibc library; and redirect file operation requests initiated by the target business process module to the user-space distributed file system server cluster. Upon completion of loading of the target business process module, it automatically establishes communication with the user-space distributed file system server cluster, obtains a process access identifier allocated by the user-space distributed file system server cluster, and stores it in the local memory space of the target business process module. This process access identifier uniquely represents the process within the global scope of the user-space distributed file system. The target business process module, in response to system calls related to glibc library files initiated by the target business process module, hijacks the corresponding system calls, allocates and maintains a unique file descriptor within the user space of the current process to replace the file descriptor allocation logic of the Linux kernel; it concatenates the process access identifier and the file descriptor to generate a globally unique file handle, uses the generated file handle as input parameter to call the file operation interface corresponding to the user-space distributed file system server cluster, and returns the system call execution result to the target business process module after completing the corresponding file operation; in response to the exit of the target business process module, it automatically initiates an access disconnection request to the user-space distributed file system server cluster.

[0081] This embodiment deploys a user-space distributed file system server cluster on a Linux operating system, configures the LD_PRELOAD environment variable and specifies the dynamic link library storage path for loading dynamic link library modules. Utilizing the LD_PRELOAD mechanism, dynamic link libraries are preloaded, and system call hijacking and the acquisition of a globally unique process access identifier are completed when the target business process starts. This achieves instance isolation across processes and nodes in a distributed scenario from the access layer. Furthermore, by hijacking all file-related system calls, a unique file descriptor is autonomously allocated and maintained within the process in user space, replacing kernel allocation logic and fundamentally eliminating dependence on kernel-private mapping tables. Simultaneously, the globally unique process access identifier and the unique file descriptor within the process are concatenated to generate a file handle. This combination of two unique identifiers naturally ensures the global uniqueness of the handle and strong mapping consistency. The entire user-space closed-loop file operation can be completed without additional locking or table lookups. This completely bypasses the performance bottleneck of the FUSE framework, significantly improving read and write performance, and eliminates the risk of data corruption and resource leakage at the architectural level. Moreover, it has zero intrusion into the business process, enabling rapid engineering implementation.

[0082] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. For those skilled in the art, other variations or modifications can be made based on the above description. It is impossible to exhaustively list all the implementation methods here. All obvious variations or modifications derived from the technical solutions of the present invention are still within the protection scope of the present invention.

Claims

1. A file operation method for a distributed file system, characterized by, include: In response to the startup of the target business process, a dynamic link library is loaded, and communication is established with the server cluster. A process access identifier allocated by the server cluster is obtained and stored in the local memory space of the target business process. The server cluster is a user-space distributed file system server cluster pre-deployed on a Linux operating system. The dynamic link library is loaded by a storage path specified by the LD_PRELOAD environment variable configured on the Linux operating system. It is used to hijack file-related system calls of the glibc library and redirect file operation requests to the server cluster. The process access identifier uniquely represents the target business process globally within the user-space distributed file system. Further, it includes: The dynamic link library sends a client access request to the server cluster. The client access request carries the unique identifier of the device where the target business process is located and the process ID of the target business process. Receive the process access identifier returned by the server cluster, wherein the process access identifier is a 32-bit unsigned integer allocated by the server cluster through a global bitmap; Write the process access identifier into the local memory space of the target service process; In response to system calls related to glibc library files initiated by the target business process, the dynamic link library hijacks these system calls, allocates and maintains a unique file descriptor within the current process's user space to replace the Linux kernel's file descriptor allocation logic, further including: A file descriptor bitmap is maintained in the user space of the current process. The file descriptor bitmap is used to record the usage and unused status of all file descriptors in the current process. In response to the glibc library's open system call initiated by the target business process, the dynamic link library hijacks the open system call, extracts the smallest unused 32-bit non-negative integer from the file descriptor bitmap as the unique file descriptor in the current process, and marks the integer as used in the file descriptor bitmap; In response to the close system call of the glibc library initiated by the target business process, the used state of the corresponding file descriptor is released in the file descriptor bitmap and marked as unused; The process access identifier and file descriptor are concatenated to generate a globally unique file handle, which is then used as input to call the file operation interface corresponding to the server cluster. This further includes: Shift the process access identifier, which is in the form of a 32-bit unsigned integer, left by 32 bits to obtain the high-order operation value; Add the 32-bit non-negative integer file descriptor to the high-order operation value to generate a 64-bit non-negative integer globally unique file handle; The file handle is used as the core input parameter of the server cluster file operation interface; After completing the corresponding file operation, the system call execution result is returned to the target business process. In response to the exit of the target business process, the dynamic link library automatically initiates an access disconnection request to the server cluster, so that the server cluster releases the access resources corresponding to the process access identifier and reclaims the resources.

2. The file operation method for a distributed file system according to claim 1, wherein, The hijacking of the glibc library file-related system calls initiated by the target business process in response to the dynamic link library further includes: In response to the open system call of the glibc library initiated by the target business process, the dynamic link library hijacks the open system call and obtains the filename, open flag and permission mode parameters of the file to be opened; The system allocates and maintains a unique file descriptor within the user space of the current process, replacing the file descriptor allocation logic of the Linux kernel. The process access identifier and file descriptor are concatenated to generate a globally unique file handle; The file opening interface of the server cluster is called with the file name, open flag, permission mode and file handle as input parameters. The system receives the file open execution result returned by the server cluster, and sends the file descriptor as the return value of the open system call to the target business process.

3. The file operation method for a distributed file system according to claim 2, wherein, The hijacking of the glibc library file-related system calls initiated by the target business process in response to the dynamic link library further includes: In response to the read system call of the glibc library initiated by the target business process, the dynamic link library hijacks the read system call and obtains the file descriptor, data buffer address and read length parameters in the system call input parameters; The process access identifier stored in local memory is concatenated with the file descriptor to generate a globally unique file handle; The file read interface of the server cluster is called with the file handle data buffer address and the read length as input parameters. The system receives the file read execution result and read data returned by the server cluster, and sends the file read execution result as the return value of the read system call to the target business process.

4. The file operation method for a distributed file system according to claim 2, wherein, The hijacking of the glibc library file-related system calls initiated by the target business process in response to the dynamic link library further includes: In response to the write system call of the glibc library initiated by the target business process, the dynamic link library hijacks the write system call and obtains the file descriptor, the address of the data to be written and the write length parameter in the system call input parameters; The process access identifier stored in local memory is concatenated with the file descriptor to generate a globally unique file handle; The file write interface of the server cluster is called with the file handle, the address of the data to be written and the write length as input parameters. The system receives the file write execution result returned by the server cluster, and sends the file write execution result as the return value of the write system call to the target business process.

5. The file operation method for a distributed file system according to claim 2, wherein, The hijacking of the glibc library file-related system calls initiated by the target business process in response to the dynamic link library further includes: In response to the close system call of the glibc library initiated by the target business process, the dynamic link library hijacks the close system call and obtains the file descriptor parameter in the system call input parameters; The process access identifier stored in local memory is concatenated with the file descriptor to generate a globally unique file handle; Using the file handle as input parameter, call the file closing interface of the server cluster; The system receives the file closing execution result returned by the server cluster, releases the maintenance resources of the corresponding file descriptor in the current process's user space, and sends the file closing execution result as the return value of the close system call to the target business process.

6. The file operation method for a distributed file system according to claim 1, wherein, In response to the exit of the target business process, the dynamic link library automatically initiates an access disconnection request to the server cluster, so that the server cluster releases the access resources corresponding to the process access identifier and reclaims the resources, which further includes: In response to the exit instruction of the target business process, the dynamic link library reads the process access identifier stored in local memory; Send a client disconnect request carrying the process access identifier to the server cluster; Receive the access disconnection execution result returned by the server cluster and release the storage resources of the process access identifier in the local memory of the current process.

7. A file operating system oriented to a distributed file system, characterized by, This includes a user-space distributed file system server cluster, dynamic link library modules, and target business process modules running on the Linux operating system. The user-space distributed file system server cluster is configured to: assign a globally unique process access identifier to the target business process module to which it is connected; receive file operation requests sent by dynamic link library modules and execute corresponding file operations; and release the access resources of the corresponding process access identifier and complete resource reclamation in response to access disconnection requests. The dynamic link library module is configured to: load via a storage path specified by the LD_PRELOAD environment variable configured in the Linux operating system; hijack file-related system calls of the glibc library; redirect file operation requests initiated by the target business process module to the user-space distributed file system server cluster; and, in response to the completion of loading of the target business process module, automatically establish communication with the user-space distributed file system server cluster, obtain the process access identifier allocated by the user-space distributed file system server cluster, and store it in the local memory space of the target business process module, further including: The dynamic link library sends a client access request to the server cluster. The client access request carries the unique identifier of the device where the target business process is located and the process ID of the target business process. Receive the process access identifier returned by the server cluster, wherein the process access identifier is a 32-bit unsigned integer allocated by the server cluster through a global bitmap; Write the process access identifier into the local memory space of the target service process; The process access identifier uniquely represents the target business process module within the global scope of the user-space distributed file system; in response to glibc library file-related system calls initiated by the target business process module, the corresponding system call is hijacked, and a unique file descriptor is allocated and maintained in the user-space space of the current process to replace the file descriptor allocation logic of the Linux kernel, further including: A file descriptor bitmap is maintained in the user space of the current process. The file descriptor bitmap is used to record the usage and unused status of all file descriptors in the current process. In response to the glibc library's open system call initiated by the target business process, the dynamic link library hijacks the open system call, extracts the smallest unused 32-bit non-negative integer from the file descriptor bitmap as the unique file descriptor in the current process, and marks the integer as used in the file descriptor bitmap; In response to the close system call of the glibc library initiated by the target business process, the used state of the corresponding file descriptor is released in the file descriptor bitmap and marked as unused; The process access identifier and file descriptor are concatenated to generate a globally unique file handle. The generated file handle is then used as input to call the file operation interface corresponding to the user-space distributed file system server cluster. This further includes: Shift the process access identifier, which is in the form of a 32-bit unsigned integer, left by 32 bits to obtain the high-order operation value; Add the 32-bit non-negative integer file descriptor to the high-order operation value to generate a 64-bit non-negative integer globally unique file handle; The file handle is used as the core input parameter of the server cluster file operation interface; After completing the corresponding file operation, the system call execution result is returned to the target business process module; in response to the exit of the target business process module, an access disconnection request is automatically initiated to the user-space distributed file system server cluster.

Images