A method for optimizing user-mode file system framework FUSE

Abstract

The present invention relates to a method for optimizing a user-mode file system framework FUSE, which includes deploying an rcFUSE driver in a kernel and deploying an rcFUSE daemon in a user space; loading the rcFUSE driver, creating a ring channel, receiving a request, and allocating each ring channel to a memory on a NUMA node with the same CPU core ID; the user mounts an rcFUSE-based file system, and maps the memory area of ​​the ring channel to the user's virtual address space; queuing synchronous requests directly to a pending ring buffer, initially adding asynchronous requests to a background queue, and then moving the asynchronous requests to the pending ring buffer; and adopting a polling mechanism in the rcFUSE driver. The parallelism of request processing is maximized to achieve high scalability; and context switching and request copying overhead are effectively reduced.

Description

Technical Field

[0001] The present invention belongs to the technical field of user-mode file system frameworks, and in particular relates to a method for optimizing a user-mode file system framework FUSE. Background Art

[0002] In the development process of developers, it is very difficult to develop a file system based on the kernel. Developers must have a deep understanding of the complex kernel subsystems, including page cache, memory management, block layer, and device drivers. There is also the risk of misusing complex kernel interfaces. This inherent complexity usually leads to low maintainability and reliability of the kernel file system, and the system is vulnerable to critical issues such as system crashes.

[0003] User space file systems have three significant advantages. First, user space file systems provide higher reliability and security because programming errors will not endanger the entire system. Second, user space file systems can also take advantage of mature user-level libraries and debugging tools to simplify file system maintenance. Finally, unlike kernel file systems that are bound to a specific operating system kernel interface, user space file systems can be easily ported to different operating systems.

[0004] FUSE is a user-mode file system framework that allows users to develop custom file systems without kernel-level modifications. FUSE makes it easier to develop and maintain specialized file systems for various purposes, and has gained wide popularity due to its flexibility and compatibility. However, the complex structure of the FUSE software stack makes its operation complex. Each FUSE request, originating from the virtual file system (VFS) layer, must go through multiple steps before it can finally reach the user space implementation. In this process, FUSE incurs extremely heavy overhead due to multiple context switches and memory copies between the kernel and user space. In addition, the single queue used by the FUSE driver to dispatch file system requests to the user space FUSE daemon prevents FUSE from achieving scalable performance, and the high overhead becomes particularly prominent in modern hardware environments with a large number of CPU cores and high-performance devices.

[0005] See also Figure 1 , FUSE consists of two main parts: the FUSE driver in the Linux kernel and the user space FUSE daemon created when mounting a FUSE-based file system, such as Figure 1As shown. When the FUSE driver is loaded, it creates a specific device / dev / fuse that serves as an intermediary between the virtual file system (VFS) and the FUSE-based file system. There are five types of queues inside the FUSE driver: background, pending, processing, forget, and interrupt. The first three are used to route file system operation requests to the FUSE daemon. The forget queue is used to interact with the directory cache (dcache), while the interrupt queue handles requests that interrupt ongoing file system operations. When an application initiates a file operation on a FUSE-based file system, the VFS sends the request to the FUSE driver. The driver then queues it to the appropriate queue depending on whether the request is synchronous or asynchronous. Synchronous requests are immediately added to the pengding queue. In contrast, asynchronous requests, such as read-ahead or write-back requests, are initially placed in the background queue and then enter the pengding queue. The FUSE driver limits the number of asynchronous requests in the pending queue to prevent interference from a large number of asynchronous requests. This strategy is particularly beneficial for maintaining the responsiveness of synchronous requests, which are usually latency-sensitive. The FUSE driver and the FUSE daemon exchange this information by executing read() and write() system calls on / dev / fuse. The FUSE daemon can have multiple worker threads, and the number of worker threads is limited by the number of asynchronous requests in the pengding queue.

[0006] There are currently three ways to solve the technical problem of high overhead in FUSE. One is to introduce the FUSE transparent transmission function, and the FUSE driver directly forwards the READ / WRITE request to the underlying file system. This method bypasses the FUSE daemon and reduces the overhead, but sacrifices FUSE's ability to support custom user space file system functions, and does not solve the problem of FUSE's single-queue communication.

[0007] Another approach uses the general-purpose execution engine eBPF to extend the FUSE framework, which enables user-space file systems to register simple eBPF code snippets in the kernel. This allows various file system functions to be executed directly in a secure sandbox environment in the kernel, avoiding expensive context switches between the kernel and user space and reducing overhead. However, this approach requires file system developers to develop new functions within the constraints of eBPF, including limited code size, bounded loops, restricted access to kernel data, and restricted pointer usage.

[0008] Another approach is to increase parallelism in FUSE by using multiple communication channels. However, simply adding more queues does not completely solve the lock contention problem, and the context switching overhead in the FUSE design still exists.

[0009] Therefore, how to improve the existing user-space file system framework FUSE to reduce the inherent overhead of FUSE, enhance FUSE's ability to support customized user-space file system functions, remove FUSE's single-queue-based communication drawbacks, and solve the development of new functions within constraints and lock contention are technical problems that need to be solved urgently. Summary of the invention

[0010] The purpose of the present invention is to improve the existing user-space file system framework FUSE to reduce the inherent overhead of FUSE, enhance the ability of FUSE to support customized user-space file system functions, remove the communication disadvantages of FUSE based on a single queue, and solve the problem of formulating new functions within constraints and lock contention.

[0011] In order to solve the above technical problems, the technical solution adopted by the present invention is as follows:

[0012] A method for optimizing a user-mode file system framework FUSE comprises the following steps:

[0013] S1: deploy the rcFUSE driver in the computer kernel and deploy the rcFUSE daemon in the user space;

[0014] S2: Load the rcFUSE driver, and create a ring channel and a specified device / dev / rcfuse for each CPU core of each server through the rcFUSE driver, wherein the ring channel sets a ring buffer, an independent buffer, and a background queue;

[0015] Wherein, the ring buffer includes a pending ring buffer, a forgotten ring buffer and an interrupted ring buffer;

[0016] S3: The rcFUSE driver receives a request from the application to allocate memory for the ring channel, and the rcFUSE driver allocates each ring channel to memory on the same NUMA node as the corresponding CPU core ID;

[0017] S4: The user mounts the rcFUSE-based file system, and the rcFUSE daemon uses mmap() to map the memory area of ​​the ring channel to the user's virtual address space;

[0018] S5: the rcFUSE daemon creates a dedicated worker thread for each ring channel to process requests from the application received from the corresponding ring channel;

[0019] S6: Requests from the application are divided into synchronous requests and asynchronous requests. Synchronous requests are directly queued to the pending ring buffer, and asynchronous requests are initially added to the background queue and then moved to the pending ring buffer.

[0020] S7: A polling mechanism is adopted in the rcFUSE daemon, where its worker thread polls the head pointer of the pending ring buffer in the user space to obtain incoming requests, and the application monitors the completion flag of its submitted request and waits for a response.

[0021] Preferably, in step S3, the following specific processes are included:

[0022] The rcFUSE driver receives a request from an application and forwards the corresponding request to the rcFUSE daemon. The rcFUSE driver matches the corresponding ring channel according to the CPU core ID assigned to the current working thread. The rcFUSE driver allocates memory to the ring channel and its related components, and allocates each ring channel to the memory on the same NUMA node as the corresponding CPU core ID.

[0023] Preferably, when the application thread that issues the file system operation runs on CPU core 1, CPU core 1 represents CPU core ID 1, and the rcFUSE driver transmits the corresponding request to the rcFUSE daemon through ring channel #1, and ring channel #1 represents the ring channel that matches CPU core ID 1.

[0024] Preferably, in step S6, the following specific steps are also included:

[0025] The rcFUSE driver determines whether there is congestion in the ring channel. If so, the rcFUSE driver dispatches the incoming asynchronous requests to different ring channels in a polling manner. If not, the rcFUSE driver continues to allocate working threads to the ring channels according to the requests;

[0026] The process by which the rcFUSE driver determines whether there is congestion in the ring channel is as follows: obtain the number of working threads for each ring channel and compare it with the preset threshold number of working threads for each ring channel. When the number of working threads in a certain ring channel is greater than the preset threshold number of working threads for the ring channel or when a thread in the rcFUSE daemon process is in a sleep state due to long execution time, it is determined that the ring channel is congested.

[0027] Preferably, at the same time as step S1, the FUSE kernel driver and the low-level layer of libfuse that handles message communication are modified, and all FUSE APIs exposed to user space file system developers are retained.

[0028] Preferably, the designated device / dev / rcfuse in step S2 is a communication channel between the virtual file system and the file system based on rcFUSE, that is, a communication medium between the rcFUSE kernel driver and the rcFUSE user space daemon. All users access the file system based on the rcFUSE framework through the designated device / dev / rcfuse. The subsequent rcFUSE driver and the rcFUSE daemon communicate based on the designated device / dev / rcfuse.

[0029] Preferably, the polling mechanism in step S7 is a general mechanism for implementing Linux asynchronous IO, and the specific process is as follows:

[0030] S71: submitting the request from the application to the queue;

[0031] S72: monitor whether the completion queue has a completion mark, if so, execute step S73;

[0032] S73: Process the request from the application.

[0033] The beneficial effects of the present invention include:

[0034] The method for optimizing the user-mode file system framework FUSE provided by the present invention comprises the following steps: deploying an rcFUSE driver in a kernel and deploying an rcFUSE daemon process in a user space; loading the rcFUSE driver, creating a ring channel, receiving a request from the rcFUSE driver, and allocating each ring channel to a memory on a NUMA node having the same ID as a CPU core; the user mounts a file system based on rcFUSE, and maps a memory area of ​​the ring channel to a virtual address space of the user; the rcFUSE daemon process creates a request for processing the ring channel; queuing synchronous requests directly to a pending ring buffer, initially adding asynchronous requests to a background queue, and then moving the asynchronous requests to the pending ring buffer; adopting a polling mechanism in the rcFUSE driver, and a working thread polls a head pointer of a pending ring buffer in a user space to obtain an incoming request.

[0035] First, a ring channel containing a set of ring buffers is used to communicate between the kernel FUSE driver and the user space FUSE daemon, each CPU core is allocated a set of ring buffers, and each set of ring buffers is allocated memory from the same NUMA node as the corresponding CPU core. The invention ensures that requests through different ring buffers are delivered without lock contention, maximizing the parallelism of request processing, thereby achieving high scalability and high performance.

[0036] Secondly, by mapping the ring buffer as shared memory between the kernel and user space, and using hybrid polling, that is, the worker thread polls the head pointer of the pending ring buffer in the user space to obtain incoming requests, while the application thread monitors the completion flag of its submitted request and waits for the response to effectively transmit requests and replies, the context switching and request copying overhead are effectively reduced, greatly improving the performance of FUSE.

[0037] Thirdly, the load overload detection mechanism and the mutual scheduling and processing of requests between different ring channels can effectively prevent the asynchronous request blocking of the application.

[0038] Finally, we only optimize on the existing FUSE framework, which is fully compatible with FUSE-based file systems, allowing existing FUSE-based file systems to run seamlessly on the new framework without any modifications, thus reducing the difficulty of optimization operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 It is a schematic diagram of the technical solution of FUSE in the prior art of the present invention.

[0040] Figure 2 It is a schematic diagram of the technical solution of rcFUSE of the present invention.

[0041] Figure 3 It is a schematic diagram of the pending ring buffer structure in the ring channel of rcFUSE of the present invention. DETAILED DESCRIPTION

[0042] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. The components of the embodiments of the present application usually described and shown in the drawings here can be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present application.

[0043] The following is combined with Figure 1-Figure 3 The present invention is further described in detail:

[0044] Example 1

[0045] See also Figure 2 and Figure 3 A method for optimizing a user-mode file system framework FUSE, a method for optimizing a user-mode file system framework FUSE, comprising the following steps:

[0046] S1: deploy the rcFUSE driver in the computer kernel and deploy the rcFUSE daemon in the user space;

[0047] S2: Load the rcFUSE driver, and create a ring channel and a specified device / dev / rcfuse for each CPU core of each server through the rcFUSE driver, wherein the ring channel sets a ring buffer, an independent buffer, and a background queue;

[0048] Wherein, the ring buffer includes a pending ring buffer, a forgotten ring buffer and an interrupted ring buffer;

[0049] S3: The rcFUSE driver receives a request from the application to allocate memory for the ring channel, and the rcFUSE driver allocates each ring channel to memory on the same NUMA node as the corresponding CPU core ID;

[0050] S4: The user mounts the rcFUSE-based file system, and the rcFUSE daemon uses mmap() to map the memory area of ​​the ring channel to the user's virtual address space;

[0051] S5: the rcFUSE daemon creates a dedicated worker thread for each ring channel to process requests from the application received from the corresponding ring channel;

[0052] S6: Divide the requests from the application into synchronous and asynchronous requests, queue the synchronous requests directly to the pending ring buffer, and initially add the asynchronous requests to the background queue, and then move the asynchronous requests to the pending ring buffer;

[0053] S7: A polling mechanism is adopted in the rcFUSE daemon, where its worker thread polls the head pointer of the pending ring buffer in the user space to obtain incoming requests, and the application monitors the completion flag of its submitted request and waits for a response.

[0054] The method for optimizing the user-mode file system framework FUSE of the present invention, wherein rcFUSE refers to the optimized FUSE. Communication is performed between the kernel FUSE driver and the user-space FUSE daemon through a ring channel, a set of ring buffers is allocated to each CPU core, and each set of ring buffers allocates memory from the same NUMA node as the corresponding CPU core. It can ensure that requests through different ring buffers are delivered without lock contention, maximize the parallelism of request processing, and thus achieve high scalability. Then, by mapping the ring buffer as shared memory between the kernel and the user space, and using hybrid polling to transmit requests and replies, the context switching and request replication overhead are effectively reduced, and the performance of FUSE is greatly improved. By setting a load congestion detection mechanism and mutual scheduling and processing requests between different ring channels, asynchronous request blocking of the application is effectively prevented.

[0055] Unlike the prior art FUSE which relies on a single queue for communication between the kernel and the user space, the present invention adopts a message passing mechanism based on a ring buffer and creates a ring buffer for each CPU core. This architecture aims to improve throughput by enabling parallel processing of file system operation requests while allowing the user space file system to exchange messages with the kernel without any context switching.

[0056] Example 2

[0057] Based on Example 1, step S3 includes the following specific process:

[0058] The rcFUSE driver receives the request and forwards the corresponding request to the rcFUSE daemon. The rcFUSE driver matches the corresponding ring channel according to the CPU core ID assigned to the current working thread. The rcFUSE driver allocates memory for the ring channel and its related components, and allocates each ring channel to the memory on the NUMA node with the same CPU core ID as the corresponding CPU core. For example, when the application thread that issues the file system operation runs on CPU core 1, CPU core 1 indicates that the CPU core ID is 1, and the rcFUSE driver transmits the corresponding request to the rcFUSE daemon through ring channel #1, and ring channel #1 indicates the ring channel that matches the CPU core ID of 1.

[0059] The rcFUSE driver considers NUMA locality when allocating memory for the ring and its associated components. When the rings are assigned to different NUMA nodes, each access during request submission and completion incurs the penalty of remote NUMA memory access, causing considerable latency. To mitigate this, rcFUSE allocates each ring to memory on the same NUMA node as the corresponding CPU core, thus ensuring that the rcFUSE daemon does not access memory from different NUMA nodes when processing a request.

[0060] Example 3

[0061] Based on Example 1 or Example 2, step S6 further includes the following specific steps:

[0062] The rcFUSE driver determines whether there is congestion in the ring channel. If so, the rcFUSE driver dispatches the incoming asynchronous requests to different ring channels in a polling manner. If not, it continues to allocate working threads to the ring channels according to the requests. The process of the rcFUSE driver determining whether there is congestion in the ring channel is as follows: obtaining the number of working threads of each ring channel and comparing it with the preset threshold number of working threads of each ring channel. When the number of working threads of a certain ring channel is greater than the preset threshold number of working threads of the ring channel or when there is a thread in the rcFUSE daemon process that is in a sleep state due to a long execution time, it is determined that the ring channel is congested.

[0063] Since rcFUSE selects a ring channel based on the CPU core ID, a large number of asynchronous requests may overwhelm a single ring channel. In addition, considering the limited number of worker threads allocated to each ring channel, the throughput of asynchronous operations may be significantly affected. In order to solve the uneven distribution of asynchronous requests, rcFUSE implements a load balancing strategy when congestion occurs. When queuing asynchronous requests to the background queue, rcFUSE identifies congestion and attempts to load balance based on the following two criteria: first, when the number of requests waiting in the background queue exceeds the maximum number of asynchronous requests that can be accommodated by the pending ring buffer. Second, when a thread in the rcFUSE daemon is in a sleeping state due to a long execution time, it is judged as a ring channel congestion. If ring channel congestion is detected, rcFUSE will dispatch incoming asynchronous requests to different ring channels in a round-robin manner. This processing method helps to reduce the load of congested ring channels and maximize the utilization of multiple ring channels, thereby improving the overall throughput of the system.

[0064] In the FUSE of the prior art, the communication between the FUSE driver and the FUSE daemon relies on the read() / write() system call to the / dev / fuse device. When the worker thread of the FUSE daemon has no incoming requests to process, or the application thread is waiting for the response of the FUSE daemon, it will automatically enter a sleep state until an event wakes them up. The use of system calls will result in frequent context switches, and the event waiting mechanism between processes will add obvious microsecond delays, which will in turn result in significant overhead, especially for metadata operations that usually require short delays. The rcFUSE of the present invention adopts a polling mechanism: in rcFUSE, the worker thread polls the head pointer of the pending ring buffer in the user space to obtain incoming requests, while the application thread monitors the completion flag of its submitted request and waits for a response. The use of a polling mechanism not only eliminates the context switches caused by system calls, but also eliminates the delay in waking up threads from a sleep state.

[0065] At the same time as step S1, the FUSE kernel driver and the low-level layer of libfuse that handles message communication are modified, and all FUSE APIs exposed to user space file system developers are retained. Users do not need to rewrite FUSE-based file system code. The only operation required is to relink their file system with the new libfuse library.

[0066] The designated device / dev / rcfuse in step S2 is the communication channel between the virtual file system and the file system based on rcFUSE, that is, the communication medium between the rcFUSE kernel driver and the rcFUSE user space daemon. All users access the file system based on the rcFUSE framework through the designated device / dev / rcfuse. The subsequent rcFUSE driver and the rcFUSE daemon communicate based on the designated device / dev / rcfuse.

[0067] The polling mechanism in step S7 is a general mechanism for implementing Linux asynchronous IO. The specific process is as follows:

[0068] S71: submitting a request from an application to a queue;

[0069] S72: monitor whether the completion queue has a completion mark, if so, execute step S73;

[0070] S73: Process the request from the application.

[0071] In summary, the method for optimizing the user-mode file system framework FUSE provided by the present invention deploys the rcFUSE driver in the kernel and deploys the rcFUSE daemon in the user space; loads the rcFUSE driver, creates a ring channel, the rcFUSE driver receives requests from the application, and allocates each ring channel to the memory on the NUMA node with the same CPU core ID; the user mounts the rcFUSE-based file system and maps the memory area of ​​the ring channel to the user's virtual address space; the rcFUSE daemon creates and processes the requests from the application received by the ring channel; the synchronous requests from the application are directly queued to the pending ring buffer, the asynchronous requests from the application are initially added to the background queue, and then the asynchronous requests are moved to the pending ring buffer; a polling mechanism is adopted in the rcFUSE driver, and the working thread polls the head pointer of the pending ring buffer in the user space to obtain the incoming request.

[0072] By utilizing a ring channel containing a set of ring buffers to communicate between the kernel FUSE driver and the user space FUSE daemon, each CPU core is allocated a set of ring buffers, and each set of ring buffers allocates memory from the same NUMA node as the corresponding CPU core. The invention ensures that requests through different ring buffers are delivered without lock contention, maximizes the parallelism of request processing, and thus achieves high scalability and high performance. By mapping the ring buffer as shared memory between the kernel and the user space, and using hybrid polling, that is, the worker thread polls the head pointer of the pending ring buffer in the user space to obtain incoming requests, while the application thread monitors the completion flag of its submitted request and waits for the response to effectively transmit the request and reply, the context switching and request copying overhead are effectively reduced, and the performance of FUSE is greatly improved. Through the load overload detection mechanism and the mutual scheduling and processing of requests between different ring channels, the asynchronous request blocking of the application is effectively prevented. It is only optimized on the existing FUSE framework and is fully compatible with the FUSE-based file system, allowing the existing FUSE-based file system to run seamlessly on the new framework without any modification, reducing the difficulty of optimization operations.

[0073] The above-mentioned embodiments only express the specific implementation method of the present application, and the description thereof is relatively specific and detailed, but it cannot be understood as limiting the protection scope of the present application. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the technical solution concept of the present application, and these all belong to the protection scope of the present application.

Claims

1. A method for optimizing a user-mode file system framework FUSE, characterized in that: The following steps are involved: S1: Deploy the rcFUSE driver in the computer kernel and deploy the rcFUSE daemon in the user space; S2: Load the rcFUSE driver, and create a ring channel and a specified device / dev / rcfuse for each CPU core of each server through the rcFUSE driver, wherein the ring channel sets a ring buffer and a background queue; Wherein, the ring buffer includes a pending ring buffer, a forgotten ring buffer and an interrupted ring buffer; S3: The rcFUSE driver receives a request from the application to allocate memory for the ring channel, and the rcFUSE driver allocates each ring channel to memory on the same NUMA node as the corresponding CPU core ID; S4: The user mounts the rcFUSE-based file system, and the rcFUSE daemon uses mmap() to map the memory area of ​​the ring channel to the user's virtual address space; S5: the rcFUSE daemon creates a dedicated worker thread for each ring channel to process requests from the application received from the corresponding ring channel; S6: Divide the requests from the application into synchronous and asynchronous requests, queue the synchronous requests directly to the pending ring buffer, and initially add the asynchronous requests to the background queue, and then move the asynchronous requests to the pending ring buffer; S7: A polling mechanism is adopted in the rcFUSE daemon, where its worker thread polls the head pointer of the pending ring buffer in the user space to obtain incoming requests, and the application monitors the completion flag of its submitted request and waits for a response.

2. A method for optimizing a user-mode file system framework FUSE according to claim 1, characterized in that: In step S3, the following specific processes are included: The rcFUSE driver receives the request and forwards the corresponding request to the rcFUSE daemon. The rcFUSE driver matches the corresponding ring channel according to the CPU core ID assigned to the current working thread. The rcFUSE driver allocates memory to the ring channel and its related components, and allocates each ring channel to the memory on the same NUMA node as the corresponding CPU core ID.

3. A method for optimizing the user-mode file system framework FUSE according to claim 2, characterized in that: When the application thread that issues the file system operation runs on CPU core 1, CPU core 1 indicates that the CPU core ID is 1, and the rcFUSE driver transmits the corresponding request to the rcFUSE daemon through ring channel #1, and ring channel #1 indicates the ring channel matching the CPU core ID 1.

4. The method for optimizing the user-mode file system framework FUSE according to claim 1, characterized in that: In step S6, the following specific steps are also included: The rcFUSE driver determines whether there is congestion in the ring channel. If so, the rcFUSE driver dispatches the incoming asynchronous requests to different ring channels in a polling manner. If not, the rcFUSE driver continues to allocate working threads to the ring channels according to the requests; The process by which the rcFUSE driver determines whether there is congestion in the ring channel is as follows: obtain the number of working threads for each ring channel and compare it with the preset threshold number of working threads for each ring channel. When the number of working threads in a certain ring channel is greater than the preset threshold number of working threads for the ring channel or when a thread in the rcFUSE daemon process is in a sleep state due to long execution time, it is determined that the ring channel is congested.

5. The method for optimizing the user-mode file system framework FUSE according to claim 1, characterized in that: At the same time as step S1, the FUSE kernel driver and the low-level layer of libfuse that handles message communication are modified, and all FUSE APIs exposed to user space file system developers are retained.

6. The method for optimizing the user-mode file system framework FUSE according to claim 1, characterized in that: The designated device / dev / rcfuse in step S2 is the communication channel between the virtual file system and the file system based on rcFUSE, that is, the communication medium between the rcFUSE kernel driver and the rcFUSE user space daemon. All users access the file system based on the rcFuse framework through the designated device / dev / rcfuse. Subsequently, the rcFUSE driver and the rcFUSE daemon communicate based on the designated device / dev / rcfuse.

7. The method for optimizing the user-mode file system framework FUSE according to claim 1, characterized in that: The polling mechanism in step S7 is a general mechanism for implementing Linux asynchronous IO. The specific process is as follows: S71: submitting a request from an application to a queue; S72: monitor whether the completion queue has a completion mark, if so, execute step S73; S73: Process the request from the application.

Images