File processing method, file system in user space, device, and computer program product

Abstract

Provided in the embodiments of the present disclosure are a file processing method, a file system in user space, a device, and a computer program product. The file processing method is applied to a file system in user space, wherein the user state file system comprises a file system process and a file system in user space (fuse) process which is in communication connection with the file system process. The file processing method comprises: a fuse process acquiring a file processing request; the fuse process caching the file processing request, wherein the fuse process comprises a caching request queue used for caching the file processing request; and when a file system process exits, the fuse process determining a request processing state of the file processing request to be a suspension state, such that a file processing link where the fuse process is located maintains a normal state. In the embodiment, when a file system process exits, a fuse process may cache a file processing request, thereby ensuring the normal operation of a user process.

Description

[0001] File Processing Method, User-Mode File System, Device, and Computer Program Product This disclosure claims priority to Chinese patent application number 202410160379.6, filed with the Patent Office of China on February 4, 2024, entitled "File Processing Method, User-Mode File System, Device, and Computer Program Product," the entire contents of which are incorporated herein by reference. Technical Field This disclosure relates to the field of computer technology, and more particularly to a file processing method, user-mode file system, device, and computer program product. Background: With the increasing complexity of file systems, many new file systems operating in user mode have emerged. Common file systems in the industry may be user-mode file systems implemented based on a file system in user space (fuse). Fuse is a software interface or software mechanism for Unix-like computer operating systems. Based on the fuse mechanism, users can implement user-mode file systems based on user permissions. Current user-mode file systems include a file system and Ibfuse running in the same process. This presents the following problem: When a file system process experiences an exception or undergoes a version upgrade, it triggers the file system process to exit. This exiting file system process renders open files unavailable, spreading the fault from the file system process to the user process, and in severe cases, even causing the user process to terminate. SUMMARY OF THE INVENTION Embodiments of the present disclosure provide a file processing method, user-mode file system, device, and computer program product. When a file system process exits, the fuse process can cache file processing requests, ensuring the normal operation of the user process. In a first aspect, an embodiment of the present disclosure provides a file processing method, applied to a user-space file system, wherein the user-space file system includes: a file system process and a user-space file system fuse process communicatively connected to the file system process; the method includes: the fuse process obtaining a file processing request; the fuse process caching the file processing request, wherein the fuse process includes: a cache request queue for caching the file processing request; and when the file system process exits, the fuse process determines the request processing state of the file processing request as a suspended state, so that the file processing link where the fuse process is located remains in a normal state.In a second aspect, embodiments of the present disclosure provide a user-mode file system, comprising: a file system process and a user-space file system fuse process communicatively connected to the file system process; the fuse process is configured to: obtain file processing requests; and cache the file processing requests, wherein the fuse process includes a cache request queue for caching file processing requests; and, when the file system process exits, to determine the request processing status of the file processing request as suspended, thereby maintaining a normal file processing link in which the fuse process resides. In a third aspect, embodiments of the present disclosure provide an electronic device, comprising: a memory and a processor; the memory is configured to store one or more computer instructions, wherein the one or more computer instructions, when executed by the processor, implement the file processing method of the first aspect. In a fourth aspect, embodiments of the present disclosure provide a computer storage medium, configured to store a computer program, wherein the computer program, when executed by a computer, causes the computer to implement the file processing method of the first aspect. In a fifth aspect, embodiments of the present disclosure provide a computer program product, comprising: a computer program, which, when executed by a processor of an electronic device, causes the processor to perform the steps of the file processing method of the first aspect. The file processing method, user-mode file system, device, and computer program product provided in this embodiment obtain file processing requests through a fuse process in the user-mode file system. When the file system process exits, the fuse process caches the file processing requests. Furthermore, because the fuse process includes a cache request queue for caching file processing requests, the fuse process can still normally receive and store file processing requests even when the file system process exits. Furthermore, the request processing status of the file processing request can be set to a suspended state until the file system process returns to normal. This prevents the spread of faults from the file system process to the user process, allowing the user process to maintain a normal processing state, thereby improving the user experience of using the user-mode file system and further ensuring the practicality of the method. BRIEF DESCRIPTION OF THE DRAWINGS To more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the following briefly introduces the drawings required in the embodiments or the prior art description. Obviously, the drawings described below represent some embodiments of the present disclosure. Persons skilled in the art can derive other drawings based on these drawings without inventive effort.Figure 1 is a schematic diagram of the principle of a file processing method provided in the related art; Figure 2 is a schematic diagram of the scenario of a file processing method provided in an embodiment of the present disclosure; Figure 3 is a flow chart of a file processing method provided in an embodiment of the present disclosure; Figure 4 is a flow chart of another file processing method provided in an embodiment of the present disclosure; Figure 5 is a flow chart of yet another file processing method provided in an embodiment of the present disclosure; Figure 6 is a schematic diagram of the principle of a solution for improving the availability of a fuse user-mode file system restart scenario provided in an application embodiment of the present disclosure; Figure 7 is a schematic diagram of the principle of a solution for improving the availability of a fuse user-mode file system restart scenario provided in an application embodiment of the present disclosure; Figure 8 is a schematic diagram of the interaction between the fuse process and the file system process provided in an application embodiment of the present disclosure;. It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a product or system comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such product or system. Without further limitation, an element defined by the phrase "comprising a..." does not preclude the presence of other identical elements in the product or system comprising the element. Furthermore, the sequence of steps in the following method embodiments is provided as an example only and is not a strict limitation. Definitions of Terms: Userspace File System: A file system in userspace, also known as fuse, implements a communication mechanism that allows users to implement a user-mode file system based on user permissions, for communication operations between kernel mode and user mode.

[0002] Iibfuse is a user-space library for the fuse file system, providing a set of functions and tools for developing and implementing fuse-based file systems. A file descriptor (fd) is a non-negative integer that identifies an open file or I / O device reference. A user-mode file system runs in user space, isolated from kernel space. This allows users to implement their own file systems without modifying kernel code, without worrying about system crashes or boot failures caused by erroneous changes. A user-mode file system restart restarts a file system process, for example, when a process is killed and a segmentation fault occurs. A user-mode file system upgrade upgrades the user-mode file system binary to a new version. To understand the specific implementation of the technical solution in this embodiment, the following briefly describes the relevant technologies: With the increasing complexity of file systems, many new file systems running in user mode have emerged. Common file systems in the industry are user-mode file systems implemented based on the file system in user space (fuse). Fuse is a software interface or mechanism for Unix-like computer operating systems. Using the fuse mechanism, users can implement user-mode file systems based on user permissions. Currently, three common file systems (e.g., cephfs, juicefs, and giusterfs) are all fuse-based user-mode file systems. The file system kernel and Iibfuse in these systems reside within the same user-mode process. As shown in Figure 1, the file system process runs in user mode and relies on the Iibfuse library. Specifically, the file system process and Iibfuse library reside within the same process. After the file system process is started, it is mounted to the mount point / mnt / f via the Iibfuse library. Taking the file opening scenario as an example, a user process can access a file using the following steps:

[0003] 1) The user process initiates a file open request to the mount point; 2) The mount point sends the file open request to the kernel-mode fuse module; 3) The file system process receives the file open request through the Iibfuse library, transferring it from kernel mode to user mode; 4) The file system process processes the file open request, opens the file within the file system process, and obtains the request processing result (including: successful file open result, file open failure result); 5) The processing result is returned to the kernel-mode fuse module; 6) The kernel-mode fuse module returns the request processing result to user mode; 7) The user process receives the file identifier (FD) of the open file. Next, the user process can read and write to the open file using the FD. However, because the file system process and Iibfuse run within the same process, the above access operation has the following disadvantages:

[0004] (1) After the file system process exits abnormally (e.g., restart, upgrade), the file fd of the processed file becomes unavailable, and the mount point becomes unavailable. Specifically, after the file system process exits abnormally, the kernel-mode fuse module invalidates the old mount point, rendering the file fd of the processed file unavailable. At this point, an EBADF error is returned, indicating an invalid or illegal file descriptor. Even if the file system process is restarted and recovered within a short period of time, the user process still occupies the old mount point, causing the restarted file system process to return an EBUSY error, indicating that the mount point is occupied and cannot be operated. (2) Upgrading the file system requires restarting the file system process, which affects the user process. When a file system version upgrade is required, the file system process needs to be restarted in order to apply the new version of binary data. Specifically, the umount command can be used to unbind the mount point from the old channel. When the user process occupies the mount point, if the old channel has files being processed, the unbinding operation of the umount command fails, and an EBUSY error is returned. If the process is forced to restart without waiting for umount to succeed, the first disadvantage (1) will be triggered, which will also affect the user process. In general, for user-mode file systems, when an exception occurs in the file system process or the version upgrade triggers the file system process to exit, the mount point will be invalidated, and the opened files will also be unavailable. Even if the file system process is restarted immediately, the fault will spread to the user process, and in serious cases, the user process will be terminated. To reduce the impact on user processes, this embodiment provides a file processing method, a user-mode file system, a device, and a computer program product. Referring to FIG2 , the file processing method provided in this embodiment may be executed by a file processing device. It should be noted that the file processing device may be implemented as a user-mode file system, a personal computer, a tablet computer, a local server, or a cloud server. When the file processing device is implemented as a cloud server, the file processing method may be executed in the cloud. The cloud may include several computing nodes (cloud servers), each of which has computing, storage, and other processing resources. In the cloud, multiple computing nodes may be organized to provide a service, and a single computing node may also provide one or more services. The cloud may provide the service by providing an external service interface, which users invoke to access the corresponding service.Service interfaces include software development kits (SDKs) and application programming interfaces (APIs). The file processing device is communicatively connected to a client, where the client is used by users to perform file processing operations. The client can be any computing device with a certain data transmission capability. In specific implementations, the client can be a mobile phone, a personal computer (PC), a tablet computer, a configuration application, and the like. Furthermore, the basic structure of the client may include at least one processor. The number of processors depends on the configuration and type of the client. The client may also include memory, which may be volatile, such as random access memory (RAM), non-volatile, such as read-only memory (ROM), flash memory, or both. The memory typically stores an operating system (OS), one or more application programs, and may also store program data. In addition to a processing unit and memory, the client also includes some basic configurations, such as a network card chip, an I / O bus, a display component, and some peripheral devices. Optionally, some peripheral devices may include, for example, a keyboard, a mouse, a stylus, a printer, etc. Other peripheral devices are well known in the art and are not described in detail here. A file processing device refers to a device that can provide file processing operations in a network virtual environment, typically a device that utilizes a network for information planning and file processing operations. In physical implementation, a file processing device can be any device that can provide computing services, respond to file processing requests, and perform file processing operations based on file processing requests. For example, it can be a cluster server, a conventional server, a cloud server, a cloud host, a virtual center, etc. The file processing device is primarily composed of a processor, a hard disk, memory, a system bus, etc., similar to a general computer architecture. In the above embodiment, the client and the file processing device are connected via a network, which can be a wireless or wired network connection.If the client can be communicatively connected to the file processing device, the mobile network standard may be any one of 2G (GSM), 2.5G (GPRS), 3G (WCDMA, TD-SCDMA, CDMA2000, UTMS), 4G (LTE), 4G+ (LTE+), Wi-Fi, 5G, and 6G. In an embodiment of the present disclosure, the client is configured to generate or obtain a file processing request. Specifically, the client may display a human-computer interaction interface, obtain an execution operation input by a user in the human-computer interaction interface, generate or obtain a file processing request based on the execution operation, and send the file processing request to the file processing device to implement the file processing operation. The file processing device can be implemented as a user-mode file system. Specifically, the file processing method can be applied to a user-mode file system. This user-mode file system can include a file system process and a user-space file system fuse process that is communicatively connected to the file system process. When a client sends a file processing request to the file processing device, the fuse process in the file processing device can obtain the file processing request. If the file system process exits, the fuse process still operates normally, so the fuse process caches the file processing request. Specifically, the fuse process includes a cache request queue for caching file processing requests. File processing requests can then be cached in the cache request queue, thereby maintaining the normal state of the file processing link where the fuse process resides. This effectively ensures that even if the file system process exits, the fuse process can still normally receive file processing requests. Furthermore, the request processing state of the file processing request can be set to a suspended state until the file system process returns to normal. This effectively prevents the spread of faults from the file system process to the user process, ensures a good user experience when using the user-mode file system, and further enhances the practicality of the method. Some embodiments of the present disclosure are described in detail below with reference to the accompanying drawings. In the absence of conflicts between the various embodiments, the following embodiments and features thereof may be combined with each other. In addition, the sequence of steps in the following method embodiments is merely an example and not a strict limitation.FIG3 is a flow chart illustrating a file processing method provided by an embodiment of the present disclosure. Referring to FIG3 , this embodiment provides a file processing method. The method may be executed by a file processing device. It is understood that the file processing device may be implemented as software or a combination of software and hardware. Specifically, when the file processing device is implemented as hardware, it may be various electronic devices capable of performing file processing operations, including but not limited to tablet computers, personal computers (PCs), servers, user-space file systems, and the like. When the file processing device is implemented as a user-space file system, the file processing method can be applied to the user-space file system. The user-space file system may include a file system process and a user-space file system fuse process that communicates with the file system process. When the file processing device is implemented as software, it may be installed in the electronic devices exemplified above. Based on the aforementioned file processing device, the file processing method in this embodiment may include the following steps: Step S301: The fuse process obtains a file processing request. Step S302: The fuse process caches the file processing request. The fuse process includes a cache request queue for caching the file processing request. Step S303: When the file system process exits, the fuse process sets the request processing status of the file processing request to a suspended state, thereby maintaining the normal state of the file processing link in which the fuse process resides. The specific implementation principles and effects of each of the above steps are described in detail below: Step S301: The fuse process obtains a file processing request. When a user requests file processing, the fuse process in the user-mode file system may obtain the file processing request to implement the file processing operation. In some instances, the file processing request may be obtained through human-computer interaction. In this case, the fuse process obtaining the file processing request may include: the user-mode file system may display a human-computer interaction interface; obtaining an execution operation entered by the user in the human-computer interaction interface; and, based on the execution operation, causing the fuse process to obtain the file processing request.In other instances, the file processing request may be obtained not only through human-computer interaction but also through a client or a third device. In this case, the user-mode file system further includes: a kernel-mode fuse communicatively connected to the fuse process, the fuse process including a user-space library Iibfuse for communicating with the kernel-mode fuse; and the fuse process obtaining the file processing request may include: the kernel-mode fuse obtaining the file processing request through a mount point; and the kernel-mode fuse sending the file processing request to Iibfuse, so that the fuse process obtains the file processing request through Iibfuse. The kernel-state fuse can obtain the file processing request sent by the user process through the mount point. Specifically, the mount point is communicatively connected to the user process (corresponding to the above-mentioned client or third device). The user process is communicatively connected to the mount point. When the user has a file processing demand, the user process can generate a file processing request and send the file processing request to the mount point. The above-mentioned mount point can be implemented as mnt or fs. After the mount point obtains the file processing request, the file processing request can be sent to the kernel-state fuse, so that the kernel-state fuse can obtain the file processing request through the mount point. In order to enable the fuse to stably obtain the file processing request, the kernel-state fuse can send the file processing request to the Iibfuse in the fuse process, so that the fuse process obtains the file processing request through the Iibfuse, thereby effectively ensuring the accuracy and reliability of obtaining the file processing request. It should be noted that different application scenarios correspond to different file processing request types. For example, in a file opening application scenario, the file processing request obtained is a file open request; in a file editing application scenario, the file processing request obtained is a file edit request; in a file deletion application scenario, the file processing request obtained may be a file delete request, and so on. Those skilled in the art may flexibly adjust the file processing request type based on specific application scenarios or application requirements. Step S302: The fuse process caches the file processing request. The fuse process includes a cache request queue for caching file processing requests. After obtaining the file processing request, the fuse process may cache the file processing request to ensure stable file processing operations.To enable the fuse process to receive and store file processing requests, the fuse process may include a cache request queue for caching file processing requests. Acquired file processing requests can then be sent to the cache request queue for caching. It should be noted that the fuse process may include not only a cache request list for caching file processing requests, but also a file information list for caching file information of processed files. The file information of processed files includes at least a file descriptor. It is understood that file information may include not only file descriptors but also file metadata corresponding to the processed files. File metadata may refer to characteristic system data describing the processed files, such as the location of file read and write operations, access permissions, file owner, and file data block distribution information (i-nodes, etc.). Step S303: If the file system process exits, the fuse process sets the request processing status of the file processing request to a suspended state, thereby maintaining the normal state of the file processing link where the fuse process resides. The file system process in a user-mode file system can have two operating states: exit and normal operation. When the file system process is in the normal operating state, if the fuse process receives a file processing request, it can send the file processing request to the file system process for processing, obtaining the file processing result corresponding to the file processing request. The fuse process can then return the file processing result corresponding to the file processing request to the fuse process. The fuse process can then return the file processing result to the user process via the kernel-mode fuse and mount point, allowing the user process to obtain the file processing result. If the file system process exits, it means that the file system process cannot perform normal file processing operations. To avoid affecting the processing operations of the user process or even causing the user process to terminate, the fuse process can be deployed separately from the file system process. That is, the fuse process and the file system process can be communicated and connected. This allows the fuse process to receive and cache file processing requests even if the file system process exits. When the file system process exits, the fuse process generates a restart instruction corresponding to the file system process and attempts to restart the file system process based on the restart instruction. When the file system process restarts successfully, the fuse process sends the obtained file processing request to the file system process. When the file system process restart fails, the fuse process caches the file processing request.In addition, when the file system process exits, the file system process cannot directly analyze and process the file processing requests in the request shared memory queue. To avoid a significant impact on the user process, the fuse process can determine the request processing status of the file processing request to be suspended. That is, when the user has a file processing demand for a processed file, the request processing status of the file processing request can be determined to be suspended, and the file processing link where the fuse process is located can remain in a normal state. The suspended state of the file processing request can be adjusted according to the state of the file system process. For example, when the file system process returns to normal, the suspended state of the file processing request can be released. In addition, with respect to the file system process and the fuse process, this embodiment does not limit the communication connection method between the file system process and the fuse process. In some instances, the file system process and the fuse process may be communicated through a memory queue, a network communication channel, or a pipe. Taking the communication connection between the file system process and the fuse process through a memory queue as an example, in this case, the file system process and the fuse process may be communicated through a request shared memory queue. In this case, after the fuse process obtains a file processing request, it may send the file processing request to the request shared memory queue. In this case, the method in this embodiment may include: the fuse process sending the file processing request to the request shared memory queue. The file processing method provided in this embodiment obtains a file processing request through a fuse process in a user-mode file system. When the file system process exits, the fuse process caches the file processing request. Furthermore, because the fuse process includes a cache request queue for caching file processing requests, the fuse process can still normally receive and store file processing requests even when the file system process exits. Furthermore, the fuse process can determine the request processing status of the file processing request as suspended, thereby maintaining a normal file processing link formed by the fuse process and the user process. This prevents the fault from spreading from the file system process to the user process, thereby maintaining a normal processing status for the user process. This not only ensures a good user experience when using the user-mode file system, but also ensures the practicality of the method.FIG4 is a flowchart of another file processing method provided by an embodiment of the present disclosure. Based on the above embodiment, and referring to FIG4 , after the request processing status of a file processing request is determined to be in a pending state, the request processing status of the file processing request can be flexibly adjusted based on the system operation status. In this case, the method in this embodiment may include: Step S401: Obtaining the system operation status of a file system process. Since a file system process can correspond to different system operating states, for example, a file system process can be in an exited state or a normal operating state, and there is a correlation between the system operating state of the file system process and the request processing operation of a file processing request, the system operating state of the file system process can be obtained to flexibly adjust the request processing state of the file processing request based on the system operating state of the file system process. In some instances, the system operating state of the file system process can be determined by sending a test signal to the file system process. In this case, obtaining the system operating state of the file system process may include: generating a processing signal corresponding to the file system process; sending the processing signal to the file system process; detecting whether feedback information corresponding to the processing signal from the file system process is received within a preset time period; if feedback information corresponding to the processing signal from the file system process is received within the preset time period, determining that the file system process is in a startup state or a resumed startup state; if feedback information corresponding to the processing signal from the file system process is not received within the preset time period, determining that the file system process is in an exited state or an abnormal state, thereby effectively ensuring stable and reliable acquisition of the system operating state of the file system process. In other instances, the system operating status can be determined not only by sending a test signal to the file system process, but also based on a preset status identifier of the file system process. In this case, obtaining the system operating status of the file system process may include: obtaining a preset status identifier corresponding to the file system process; determining that the file system process is in a normal operating state when the preset status identifier is a preset first status identifier; and determining that the file system process is in an exited state or an abnormal state when the preset status identifier is a preset second status identifier. This also effectively ensures stable and reliable acquisition of the system operating status of the file system process. Step S402: Adjusting the request processing status of the file processing request based on the system operating status.Because there is a correlation between the system operating status of the file system process and the request processing status of the file processing request, after obtaining the system operating status of the file system process, the request processing status of the file processing request can be adjusted based on the system operating status. Adjusting the request processing status of the file processing request based on the system operating status may include: controlling the file processing request to remain in a suspended state if the system operating status indicates that the file system process is in an exited state, meaning that the file system process is still unable to perform normal file processing operations; and controlling the file processing request to be released from the suspended state if the system operating status indicates that the file system process is in a normal state, meaning that the file system process can perform normal file processing operations. It should be noted that the request processing status of a file processing request can be adjusted not only based on a preset mapping relationship and the system operating status, but also based on a pre-trained machine learning model that combines the system operating status and the request processing status of the file processing request. This is sufficient as long as the request processing status of the file processing request can be adjusted promptly and effectively based on the system operating status. This will not be further elaborated here. In this embodiment, by obtaining the system operating status of the file system process and then promptly and effectively adjusting the request processing status of the file processing request based on the system operating status, not only can the request processing status of the file processing request be accurately expressed, but the quality and efficiency of analyzing and processing the file processing request can also be improved. FIG5 is a flowchart of another file processing method provided by an embodiment of the present disclosure. Based on the above embodiment, as shown in FIG5 , in this embodiment, the file system process and the fuse process can communicate not only through the request shared memory queue but also through the response shared memory queue. In this case, when the file system process resumes operation, file processing operations can be implemented through the request shared memory queue and the response shared memory queue. Specifically, the method in this embodiment may include: Step S501: When the file system process resumes operation, unprocessed file processing requests are determined through the request shared memory queue, the response shared memory queue, and the cache request queue.When the file system process resumes operation, it means that the file system process can perform normal file processing operations. Since the cache request queue in the fuse process includes processed file processing requests and unprocessed file processing requests, there is no need to perform file processing operations again for processed file processing requests, while file processing operations need to be continued for unprocessed file processing requests. In order to improve the quality and efficiency of file processing operations, the unprocessed file processing requests can be determined first. Specifically, during the time period when the file system process exits, the fuse process can continuously receive file processing requests sent by the user process through the mount point and the kernel-state fuse. After obtaining the file processing requests, the fuse process can not only cache the file processing requests in the cache request queue, but also send the file processing requests to the request shared memory queue for storage. Since file processing requests are related to the request shared memory queue, the response shared memory queue, and the cache request queue, in order to accurately determine unprocessed file processing requests, the request shared memory queue, the response shared memory queue, and the cache request queue may be analyzed and processed. In some instances, unprocessed file processing requests may be determined by analyzing and processing the request shared memory queue, the response shared memory queue, and the cache request queue using a pre-trained machine learning model. In this case, determining unprocessed file processing requests using the request shared memory queue, the response shared memory queue, and the cache request queue may include: obtaining a pre-trained machine learning model, inputting the request shared memory queue, the response shared memory queue, and the cache request queue into the machine learning model, and obtaining unprocessed file processing requests output by the machine learning model. In other instances, unprocessed file processing requests may be determined not only by using a pre-trained machine learning model, but also by analyzing and processing the request shared memory queue, the response shared memory queue, and the cache request queue. In this case, determining the unprocessed file processing requests using the request shared memory queue, the response shared memory queue, and the cache request queue may include: obtaining a first request list corresponding to the request shared memory queue, a response information list corresponding to the response shared memory queue, and a second request list corresponding to the cache request list; obtaining a total request list based on the first request list and the second request list; and determining the unprocessed file processing requests based on the total request list and the response information list.Because requests in the request shared memory queue are sent by the fuse process, file processing requests obtained by the fuse process can be cached in a cached request list. Therefore, the following two situations are likely to occur for requests in the request shared memory queue and the cached request queue: Scenario 1: The requests in the cached request queue are identical to those in the request shared memory queue; and Scenario 2: The requests in the request shared memory queue are a subset of the requests in the cached request queue. Therefore, to accurately determine unprocessed file processing requests, a first request list corresponding to the request shared memory queue, a response information list corresponding to the response shared memory queue, and a second request list corresponding to the cached request list can be obtained. Since both the first request list and the second request list store file processing requests, and the response information list stores response information corresponding to processed requests, to accurately identify unprocessed file processing requests, the first request list and the second request list can be analyzed and processed to obtain a total request list. Specifically, if the first request list and the second request list are the same, the total request list can be either the first request list or the second request list; if the first request list and the second request list are different, the total request list can be a combination of the first request list and the second request list. After obtaining the total request list, since the total request list may include both processed and unprocessed text processing requests, and the response information list includes response information corresponding to processed file processing requests, the total request list and the response information list can be processed. In some instances, a pre-trained machine learning model can be used to process the total request list and the response information list to identify unprocessed file processing requests. In other instances, unprocessed file processing requests may be determined not only through a pre-trained machine learning model but also by directly analyzing and processing the total request list and the response information list. In this case, determining the unprocessed file processing requests based on the total request list and the response information list may include: identifying whether the response information list contains response information corresponding to the request in the total request list; if so, determining that the file processing request in the total request list is a processed file processing request; if not, determining that the file processing request in the total request list is an unprocessed file processing request.For example, when the total request list includes request 1, request 2, request 3, request 4, and request 5, and the response information list includes response information 2 corresponding to request 2 and response information 4 corresponding to request 4, by comparing the total request list and the response information list, it can be found that the response information corresponding to request 1, request 3, and request 5 does not exist in the response information list, and thus it can be determined that the above-mentioned requests 1, request 3, and request 5 are unprocessed file processing requests; and the response information 2 corresponding to request 2 and the response information 4 corresponding to request 4 exist in the response information list, and thus it can be determined that the above-mentioned requests 2 and request 4 are processed file processing requests. In this way, the operation of accurately determining the unprocessed file processing requests is effectively achieved. Furthermore, to improve the practicality of this method, the fuse process also includes a file information list for caching file information of processed files. The file information includes at least a file descriptor. In this case, before determining unprocessed file processing requests through the request shared memory queue, the response shared memory queue, and the cache request queue, the file system process in this embodiment can perform a file recovery operation based on the fuse process. Specifically, the method in this embodiment can further include: the file system process obtaining file metadata of the processed file through the file information list in the fuse process; and the file system process performing a file recovery operation based on the file metadata and file descriptor of the processed file to obtain and store the processed file. The fuse process stores a file information list including the file metadata of the processed file. To implement the file recovery operation, when the file system process returns to normal, the file metadata and file descriptor fd of the processed file can be obtained through the file information list in the fuse process. The file metadata can include characteristic system data describing the processed file, such as access rights, file owner, and file data block distribution information (i-node, etc.). When the file system process returns to normal, in order to stably implement file processing operations, the file system process can obtain the file metadata and file descriptor fd of the processed file from the file information list in the fuse process. After obtaining the file metadata and file descriptor fd of the processed file, the file system process can perform a file recovery operation based on the file metadata and file descriptor fd of the processed file, thereby obtaining the processed file and storing the processed file. This effectively implements the file recovery operation, and then the corresponding processing operation can be performed based on the recovered file.Step S502: The fuse process sends the unprocessed file processing request to the file system process to implement the file processing operation. To implement the file processing operation, after determining the unprocessed file processing request, the fuse process may send the unprocessed file processing request to the file system process. After the file system process obtains the unprocessed file processing request, it may perform the corresponding file processing operation based on the unprocessed file processing request, thereby obtaining a file processing result corresponding to the file processing request, effectively improving the practicality of the method. In this embodiment, when the file system process resumes operation, the unprocessed file processing request is determined through the request shared memory queue, the response shared memory queue, and the cache request queue. The fuse process then sends the unprocessed file processing request to the file system process to implement the file processing operation, effectively improving the practicality of the method. In a specific application, taking a file open request as an example of a file processing request, as shown in FIG6 , this application embodiment provides a user-mode file system. The user-mode file system may include a fuse process and a file system process. The fuse process and the file system process communicate via a request shared queue and a response shared queue. Specifically, the fuse process, the file system process, the request shared queue, and the response shared queue in this embodiment can be used to implement the following functions: a bfuse library, a cache request queue for caching file open requests. The file system process manages file system data and metadata. The management logic within this process is relatively complex and more prone to failure than the fuse process. The request shared queue stores file open requests sent by the fuse process. File open requests can be stored in the request shared queue. The request shared queue is a circular buffer structure. Specifically, the fuse process, as a producer, submits requests to the queue, and the file system process, as a consumer, consumes requests from the queue. The response shared queue stores request responses. This response shared queue also has a circular buffer structure. Specifically, the file system process, as a producer, submits replies to the queue, and the fuse process, as a consumer, consumes replies from the queue. Based on the above-mentioned user-mode file system, when the file system process is running normally, the file processing flow may include the following steps: Step 1: The user process initiates a file open request to the mount point. Step 2: The mount point sends the file open request to the kernel-mode fuse module, which caches the request in the kernel-mode request queue. Step 3: The kernel-mode fuse module may send the file open request to the fuse process via the Iibfuse library. The fuse process includes Iibfuse, a cache request list, and a file information list. After the fuse process receives the file open request, it may cache the request in the cache request list. The file information list stores file metadata of opened files for file recovery operations. After the kernel-mode fuse module sends the file open request to the fuse process, the fuse process can stably receive the file open request via the Iibfuse library. Step 4: After the fuse process receives the file open request, it may add the request to the request shared memory queue to wake up the file system process.The fuse process and the file system process can communicate via a request shared memory queue and a response shared memory queue. After the fuse process receives a file open request, it can add the file open request to the request shared memory queue to wake up the file system process. Specifically, the file system process can be woken up using preset parameters (e.g., semaphores) in the inter-process communication mechanism. Step 5: The file system process reads the file open request from the request shared memory queue. Step 6: The file system process processes the file open request and performs the corresponding file open operation within the file system process. Step 7: The file system process obtains the file open result and then writes the file open result to the response shared memory queue to wake up the fuse process. Step 8: The fuse process reads the request processing result from the response shared memory queue and stores the file open information in the file information list. Step 9: The fuse process sends the file open result to the kernel-mode fuse module. Step 10: The kernel-mode fuse module returns the request processing result to the user process. Step 11: The user process obtains the file descriptor (fd) of the open file. The user process can then perform read and write operations on the open file using fd. When the file system process exits and then resumes normal operation, as shown in FIG7 , the file processing flow may include the following steps: Step 21: File information previously opened by the user process remains in the file information list in the fuse process. Step 22: When the user process initiates a new file open request, the fuse process, after receiving the newly initiated file open request, may cache the file open request in the cache request list and send the file open request to the request shared memory queue for storage. However, these newly initiated file open requests are not consumed. Step 23: During the period from the restart of the file system process to the completion of recovery, the file open request issued by the user process is in a pending state, meaning that the file open request is not responded to.As can be seen from the above, regardless of whether the file system process exits normally or abnormally, the user process is not affected by the file system process exit. That is, the file FDs of already opened files remain valid, and newly initiated file open requests remain pending until the file system process is restarted and restored, and the file open requests are released from the pending state. This reduces the impact on user processes to seconds. Referring to FIG8 , the process of resuming file open request processing between the fuse process and the restarted file system process may include the following steps: Step 31: When the fuse process detects that the file system process has exited, it restarts the file system process. Step 32: When the file system process is successfully restarted, it sends a prompt message to the fuse process indicating the successful restart of the file system process. Step 33: The fuse process recovers unprocessed requests based on its cached request queue and two shared memory queues (request shared memory queue and response shared memory queue) with the file system process. Step 34: The processed files of the previous life cycle are recovered based on the metadata and file device (FD) information included in the file system list in the fuse process. Step 35: When the cultural system process successfully recovers the processed file from the previous lifecycle, it may send a prompt message to the fuse process indicating the successful file recovery. Step 36: After receiving the prompt message, the fuse process may send an unprocessed file open request to the file system process. Step 37: The file system process performs the corresponding file processing operation on the unprocessed file open request, obtains the file open result, and returns the file open result to the fuse process. Step 38: The file open result is returned to the kernel-mode fuse module so that the user process can obtain the file open result.This application embodiment implements a solution for deploying the libfuse library and the file system process separately. This can reduce the impact on user processes in the scenario of abnormal exit, version upgrade, or restart of the file system process. In addition, for processed files, it will not affect the user process to perform file opening operations, thereby effectively improving the availability of the user-mode file system. In addition, when the file system process is restored, the file processing request of the user process is released from the suspended state. In this way, the user process will not be suspended due to the restart of the file system process. In this way, when the file system process exits, the fuse process can still normally receive file processing requests. This can avoid the spread of the fault from the file system process to the user process, and can enable the user process to maintain a normal processing state, thereby improving the good experience of using the user-mode file system and further improving the practicality of the solution. FIG9 is a schematic diagram of the structure of a user-space file system provided by an embodiment of the present disclosure. Referring to FIG9 , this embodiment provides a user-space file system that can be used to execute the file processing method shown in FIG3 . The user-space file system may include a file system process 11 and a user-space file system fuse process 12 in communication with the file system process 11. The fuse process 12 is configured to: obtain file processing requests; cache the file processing requests. The fuse process 12 includes a cache request queue for caching file processing requests; and, if the file system process 11 exits, set the request processing state of the file processing request to a suspended state to maintain a normal file processing link where the fuse process resides. In some instances, the user-mode file system further includes a kernel-mode fuse 13 communicatively connected to the fuse process 12. The fuse process 12 includes a user-space library, Iibfuse, for communicating with the kernel-mode fuse 13. In this embodiment, the kernel-mode fuse 13 is configured to: obtain a file processing request through a mount point; and send the file processing request to Iibfuse, so that the fuse process 12 obtains the file processing request through Iibfuse. In some instances, the file system process 11 and the fuse process 12 communicate via a request shared memory queue. In this embodiment, the fuse process 12 is configured to: send the file processing request to the request shared memory queue.In some instances, after determining that the request processing status of a file processing request is suspended, the fuse process 12 in this embodiment is configured to perform the following steps: obtain the system operating status of the file system process; and adjust the request processing status of the file processing request based on the system operating status. In some instances, when the fuse process 12 adjusts the request processing status of the file processing request based on the system operating status, the fuse process 12 is configured to perform the following steps: if the system operating status indicates that the file system process is in an exited state, control the file processing request to remain in a suspended state; and if the system operating status indicates that the file system process is in a normal state, control the file processing request to be released from the suspended state. In some instances, the file system process 11 and the fuse process 12 are further connected in communication via a response shared memory queue. In this embodiment, the fuse process 12 is configured to perform the following steps: when the file system process resumes operation, determine unprocessed file processing requests via the request shared memory queue, the response shared memory queue, and the cache request queue; and send the unprocessed file processing requests to the file system process to implement the file processing operation. In some instances, the fuse process also includes a file information list for caching file information of processed files, where the file information includes at least file descriptors. Before determining unprocessed file processing requests through the request shared memory queue, the response shared memory queue, and the cache request queue, the file system process 11 in this embodiment is configured to perform the following steps: obtain file metadata of processed files through the file information list in the fuse process; perform a file recovery operation based on the file metadata and file descriptors of the processed files to obtain and store the processed files. In some instances, when the fuse process 12 determines unprocessed file processing requests through the request shared memory queue, the response shared memory queue, and the cache request queue, the fuse process 12 is configured to perform the following steps: obtain a first request list corresponding to the request shared memory queue, a response information list corresponding to the response shared memory queue, and a second request list corresponding to the cache request list; obtain a total request list based on the first request list and the second request list; and determine unprocessed file processing requests based on the total request list and the response information list.In some instances, when the fuse process 12 determines an unprocessed file processing request based on the request list and the response information list, the fuse process 12 is configured to perform the following steps: identifying whether the response information list contains a corresponding response to the request in the request list; if so, determining that the file processing request in the request list is a processed file processing request; if not, determining that the file processing request in the request list is an unprocessed file processing request. The user-mode file system shown in FIG9 can implement the method of the embodiments shown in FIG2-FIG8. For portions not described in detail in this embodiment, reference is made to the relevant description of the embodiments shown in FIG2-FIG8. The execution process and technical effects of this technical solution are described in the embodiments shown in FIG2-FIG8 and will not be repeated here. In one possible design, the user-mode file system structure shown in FIG9 can be implemented as an electronic device, wherein the user-mode file system includes a file system process and a user-space file system fuse process communicatively connected to the file system process. As shown in FIG10, the electronic device may include a first processor 21 and a first memory 22. The first memory 22 is used to store a program for the electronic device to execute the file processing method provided in the embodiment shown in FIG. 2 . The first processor 21 is configured to execute the program stored in the first memory 22. The program includes one or more computer instructions. When executed by the first processor 21, the one or more computer instructions can implement the following steps: a fuse process obtains a file processing request; the fuse process caches the file processing request, wherein the fuse process includes a cache request queue for caching the file processing request; and when the file system process exits, the fuse process sets the request processing status of the file processing request to a suspended state to maintain the normal state of the file processing link where the fuse process resides. Furthermore, the first processor 21 is further configured to execute all or part of the steps in the embodiments shown in FIG. 2 to FIG. 8 . The electronic device may also include a first communication interface 23 for communicating with other devices or a communication network. Furthermore, embodiments of the present disclosure provide a computer storage medium for storing computer software instructions used by the electronic device, including the program for executing the file processing method in the embodiments shown in FIG. 2 to FIG. 8 . In addition, an embodiment of the present disclosure provides a computer program product, including: a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, causes the one or more processors to execute the steps of the file processing method in the method embodiments shown in Figures 2 to 8 above.The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one location or distributed across multiple network units. Some or all of these modules may be selected based on actual needs to achieve the objectives of the present embodiments. Those skilled in the art will be able to understand and implement the present embodiments without inventive effort. Through the description of the above embodiments, those skilled in the art will clearly understand that each embodiment can be implemented using a necessary general-purpose hardware platform, or alternatively, through a combination of hardware and software. Based on this understanding, the essence of the above technical solutions, or the portion that contributes to the prior art, can be embodied in the form of a computer product. The present disclosure may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The present disclosure is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present disclosure. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable device to produce a machine, such that the instructions executed by the processor of the computer or other programmable device produce means for implementing the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams. These computer program instructions can also be stored in a computer-readable memory capable of directing the computer or other programmable device to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means, which implement the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams. These computer program instructions can also be loaded onto a computer or other programmable device, causing the computer or other programmable device to execute a series of operational steps to produce a computer-implemented process, such that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams. In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.Memory may include non-volatile memory in computer-readable media, random access memory (RAM), and non-volatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media. Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented using any method or technology for information storage. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change RAM (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves. Finally, it should be noted that the above embodiments are intended only to illustrate the technical solutions of the present disclosure and are not intended to limit them. Although the present disclosure has been described in detail with reference to the aforementioned embodiments, those skilled in the art will appreciate that modifications may be made to the technical solutions described in the aforementioned embodiments, or that some of the technical features may be replaced with equivalents. Such modifications or replacements do not deviate from the spirit and scope of the technical solutions of the various embodiments of the present disclosure.

Claims

Claims 1. A file processing method, applied to a user-mode file system, wherein the user-mode file system comprises: A file system process and a user space file system fuse process in communication with the file system process; The method includes: the fuse process obtaining a file processing request; the fuse process caching the file processing request, wherein the fuse process includes: a cache request queue for caching the file processing request; when the file system process exits, the fuse process determines the request processing state of the file processing request as a suspended state, so that the file processing link where the fuse process is located remains in a normal state.

2. The method according to claim 1, wherein: The user-state file system further includes: a kernel-state fuse communicatively connected to the fuse process, wherein the fuse process includes a user-space library Iibfuse for communicating with the kernel-state fuse; the fuse process obtaining a file processing request includes: the kernel-state fuse obtaining the file processing request through a mount point; and the kernel-state fuse sending the file processing request to Iibfuse, so that the fuse process obtains the file processing request through Iibfuse.

3. The method according to claim 1 or 2, wherein: After determining that the request processing state of the file processing request is a suspended state, the method further includes: acquiring a system operation state of the file system process; and adjusting the request processing state of the file processing request based on the system operation state.

4. The method according to claim 3, wherein: Adjusting the request processing status of the file processing request based on the system operation status includes: controlling the file processing request to remain in a suspended state when the system operation status is used to identify that the file system process is in an exit state; and controlling the file processing request to release the suspended state when the system operation status is used to identify that the file system process is in a normal state.

5. The method according to any one of claims 1 to 4, wherein: The file system process and the fuse process are communicatively connected via a request shared memory queue. The method further includes: the fuse process sending the file processing request to the request shared memory queue.

6. The method according to claim 5, wherein: The file system process and the fuse process are further communicatively connected via a response shared memory queue. The method further includes: when the file system process is recovered and restarted, determining unprocessed file processing requests via the request shared memory queue, the response shared memory queue, and the cache request queue; and the fuse process sending the unprocessed file processing requests to the file system process, so that the file system process performs a file processing operation.

7. The method according to claim 6, wherein: The fuse process also includes a file information list for caching file information of processed files, where the file information includes at least a file descriptor. Before determining an unprocessed file processing request through the request shared memory queue, the response shared memory queue, and the cache request queue, the method further includes: the file system process obtaining file metadata of the processed file through the file information list in the fuse process; and the file system process performing a file recovery operation based on the file metadata and file descriptors of the processed file to obtain and store the processed file.

8. The method according to claim 6 or 7, wherein: By requesting shared memory queues, responding to shared The memory queue and the cache request queue determine the unprocessed file processing requests, including: obtaining a first request list corresponding to the request shared memory queue, a response information list corresponding to the response shared memory queue, and a second request list corresponding to the cache request list; obtaining a total request list based on the first request list and the second request list; and determining the unprocessed file processing requests based on the total request list and the response information list.

9. The method according to claim 8, wherein: Determining an unprocessed file processing request based on the total request list and the response information list includes: identifying whether there is response information corresponding to the request in the total request list in the response information list; if so, determining that the file processing request in the total request list is a processed file processing request; if not, determining that the file processing request in the total request list is an unprocessed file processing request.

10. A user-mode file system, comprising: A file system process and a user space file system fuse process in communication with the file system process; The fuse process is used to: obtain a file processing request; The file processing request is cached, wherein the fuse process includes: a cache request queue for caching the file processing request; when the file system process exits, the request processing state of the file processing request is determined to be a suspended state, so that the file processing link where the fuse process is located remains in a normal state.

11. An electronic device, comprising: A memory, a processor; wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions, when executed by the processor, implement the method of any one of claims 1-9.

12. A computer storage medium for storing a computer program, wherein the computer program enables a computer to implement the method of any one of claims 1 to 9 when executed.

13. A computer program product comprising: A computer program, which, when executed by a processor of an electronic device, causes the processor to perform the steps of the method according to any one of claims 1 to 9.

Images