Network file system nfs thread redundancy processing method and device, and electronic equipment

Abstract

The application provides a network file system (NFS) thread redundancy processing method and device and electronic equipment. A backup thread pool cooperating with a main thread pool is pre-configured, and client requests are distributed based on a flow control strategy and a connection state marker. When a client request accesses a shared directory that has activated the flow control strategy, the connection is marked as a specified service type, so that all subsequent requests of the client are distributed to the backup thread pool for processing, and client requests that have not activated the flow control strategy or have not been marked are still processed in the main thread pool. Therefore, client requests with slow processing can be isolated to the backup thread pool, and independent NFSD threads in the backup thread pool can process slow services affected by the flow control, so as to avoid the spread of thread blocking caused by slow services to the main thread pool, thereby affecting the performance of other clients, and ensuring the efficient response of the main thread pool to regular services.

Description

Technical Field

[0001] This application relates to the field of NFS thread redundancy processing technology, and in particular to a method, apparatus and electronic device for NFS thread redundancy processing in a network file system. Background Technology

[0002] NFS (Network File System) enables different machines and operating systems to share files over a network. Different client applications access data located on the server's disk via the network to achieve disk file sharing. The basic process of an NFS shared directory is as follows: The NFS client initiates an RPC (Remote Procedure Call), encapsulates the operation and parameters into a request message, and sends it to the NFS server via TCP (Transmission Control Protocol); the NFS server listens on a specified socket, and upon receiving the RPC request, wakes up an idle NFSD thread to process the request; the NFSD thread receives the request data, performs the corresponding operation according to the request parameters, and waits for the underlying file system to return the execution result; subsequently, the NFSD thread encapsulates the result into a response message and returns it to the NFS client, then enters a sleep state, waiting to be woken up again.

[0003] Currently, the NFS server uses a thread pool formed by creating multiple NFSD kernel threads to concurrently handle client requests. During request processing, the NFSD thread calls the underlying file system's operation interfaces, such as sending read / write I / O (Input / Output) requests to the file system, which then performs the actual disk read / write operations. During this process, the NFSD thread waits for the underlying I / O operations to complete and remains in an uninterruptible state. Once the underlying file system completes the read / write operation and returns the result, the NFSD thread resumes execution, sends the result to the NFS client, and then enters a sleep state that can be woken up, waiting to process the next client request.

[0004] However, once the NFSD thread dispatches read / write I / O to the underlying file system, if the file system fails, the disk is damaged, or the storage device malfunctions, preventing the I / O operation from completing normally, the NFSD thread will remain in an uninterruptible state for an extended period, unable to be interrupted by signals or forcibly terminated. In high-concurrency, high-traffic business scenarios, if multiple clients simultaneously request access to the faulty shared directory, all NFSD threads in the thread pool may fall into an uninterruptible state, unable to respond to any new client requests, resulting in the overall unavailability of the NFS service and all client operations being stuck. This, in turn, leads to service paralysis, impacting the reliability of the NFS service and business continuity. Summary of the Invention

[0005] To overcome the problems existing in related technologies, this application provides a method, apparatus and electronic device for handling NFS thread redundancy.

[0006] The first aspect of this application provides a method for handling NFS thread redundancy. The method is applied to the NFS server, which locally configures a second NFS service thread pool to cooperate with a first NFS service thread pool created in the original GLOBAL global shared thread pool mode. Initially, the first NFS service thread pool serves as the primary thread pool, and the second NFS service thread pool serves as a backup thread pool. The method includes: When a request is received from the first NFS client, if the shared directory that the first NFS client requests to access has an activated traffic control policy, and the connection from the first NFS client to this server is not marked as a specified service type, then the connection is marked as a specified service type. When an NFS request is subsequently received from the first NFS client through the connection, the NFS request is distributed to the backup thread pool for processing, so as to use the backup thread pool to isolate the business of the NFS client from the business of other NFS clients. When a request is received from a second NFS client, if the shared directory that the second NFS client requests to access has not had its traffic control policy activated, or if the connection from the second NFS client to this server has not been marked as a specified service type, the NFS request is distributed to the main thread pool for processing.

[0007] In some embodiments, the method further includes: Monitor the configuration status of the underlying file system; When a traffic control policy for the target shared directory is detected to be activated, the NFS configuration file is automatically updated, and a QoS flag is added to the configuration item corresponding to the target shared directory. The provision that if the shared directory requested by the first NFS client has an activated traffic control policy includes: the shared directory requested by the first NFS client contains the QoS flag in the NFS configuration file.

[0008] In some embodiments, the method further includes: When it is detected that the traffic control policy for the target shared directory is suspended or canceled, clear the QoS flag corresponding to the target shared directory in the NFS configuration file. When a request is received on a connection marked with a specified service type, if it is detected that the shared directory corresponding to the request is not marked with a QoS flag, the specified service type flag of the connection is cleared, so that subsequent requests are distributed to the main thread pool for processing.

[0009] In some embodiments, the flow control policy is used to limit the read and write bandwidth of the underlying file system to the shared directory; The step of distributing the NFS request to the backup thread pool for processing includes: distributing NFS requests whose processing time is increased due to bandwidth limitations to the backup thread pool for processing.

[0010] In some embodiments, the method further includes: Time the process of each NFSD thread in the main thread pool handling an NFS request. When any NFSD thread times out processing a request, add a busy flag to the shared directory corresponding to that request and count the number of NFSD threads that have timed out. When the number of NFSD threads that have timed out is equal to the total number of NFSD threads in the main thread pool, the second NFS service thread pool, which was originally the backup thread pool, will be switched to the new main thread pool, and the first NFS service thread pool, which was originally the main thread pool, will be switched to the new backup thread pool. When the new main thread pool receives an NFS request, if the shared directory corresponding to the request has the busy flag, it returns an error code indicating that the resource is busy to the NFS client; if the shared directory corresponding to the request does not have the busy flag, it processes the request normally.

[0011] In some embodiments, the method further includes: Monitor the status of timed-out NFSD threads in the new backup thread pool; When all NFSD threads are not in an uninterruptible state, the busy flag of the corresponding shared directory is cleared. The uninterruptible state is the state in which the NFSD thread waits for the read / write operation to complete and cannot be terminated by an external signal while processing the read / write operation of the underlying file system.

[0012] A second aspect of this application provides a network file system (NFS) thread redundancy processing device. The device is applied to the NFS server, which locally configures a second NFS service thread pool that works in conjunction with a first NFS service thread pool created in the original globally shared thread pool (GLOBAL) mode. Initially, the first NFS service thread pool serves as the primary thread pool, and the second NFS service thread pool serves as a backup thread pool. The device includes: The marking module is configured to mark the connection as a specified service type when it receives a request from the first NFS client, if the shared directory that the first NFS client requests to access has an activated traffic control policy, and the connection from the first NFS client to this server has not been marked as a specified service type. The first distribution module is configured to, upon receiving an NFS request from the first NFS client via the connection, distribute the NFS request to the backup thread pool for processing, thereby using the backup thread pool to isolate the NFS client's business from the business of other NFS clients. The second distribution module is configured to, when receiving a request from a second NFS client, distribute the NFS request to the main thread pool for processing if the shared directory requested by the second NFS client has not been activated by a traffic control policy, or if the connection from the second NFS client to this server has not been marked as a specified service type.

[0013] In some embodiments, the apparatus further includes: The first monitoring module is configured to monitor the configuration status of the underlying file system; The first addition module is configured to automatically update the NFS configuration file and add a QoS flag to the configuration item corresponding to the target shared directory when it is detected that the traffic control policy for the target shared directory is activated. The provision that if the shared directory requested by the first NFS client has an activated traffic control policy includes: the shared directory requested by the first NFS client contains the QoS flag in the NFS configuration file; And / or, The device further includes: The first clearing module is configured to clear the QoS flag corresponding to the target shared directory in the NFS configuration file when it is detected that the traffic control policy for the target shared directory is suspended or canceled. The second clearing module is configured to, when receiving a request on a connection marked with a specified service type, if it is detected that the shared directory corresponding to the request is not marked with a QoS flag, clear the specified service type flag of the connection, so that subsequent requests are distributed to the main thread pool for processing.

[0014] In some embodiments, the flow control policy is used to limit the read and write bandwidth of the underlying file system to the shared directory; The step of distributing the NFS request to the backup thread pool for processing includes: distributing NFS requests whose processing time is increased due to bandwidth limitations to the backup thread pool for processing; And / or, The device further includes: The timing module is configured to time the process of each NFSD thread in the main thread pool handling an NFS request. The second addition module is configured to add a busy flag to the shared directory corresponding to the request when any NFSD thread times out, and to count the number of NFSD threads that have timed out. The switching module is configured to switch the second NFS service thread pool, which is the backup thread pool, to the new main thread pool when the number of NFSD threads that have timed out is equal to the total number of NFSD threads in the main thread pool, and switch the first NFS service thread pool, which was originally the main thread pool, to the new backup thread pool. When the new main thread pool receives an NFS request, if the shared directory corresponding to the request has the busy flag, it returns an error code indicating that the resource is busy to the NFS client; if the shared directory corresponding to the request does not have the busy flag, it processes the request normally. And / or, The device further includes: The second monitoring module is configured to monitor the status of timed-out NFSD threads in the new backup thread pool. The third clearing module is configured to clear the busy flag of the corresponding shared directory when all the NFSD threads are not in an uninterruptible state. The uninterruptible state is the state in which the NFSD thread waits for the read / write operation to complete and cannot be terminated by an external signal when processing the read / write operation of the underlying file system.

[0015] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the steps of the method described in any of the first aspects.

[0016] The technical solutions provided by the embodiments of this application may include the following beneficial effects: This application embodiment pre-configures a backup thread pool that works in conjunction with the main thread pool, and distributes client requests based on traffic control policies and connection status markings. When a client requests access to a shared directory with activated traffic control policies, the connection is marked as a specified service type, causing all subsequent requests from that client to be distributed to the backup thread pool for processing. Client requests without activated traffic control policies or with unmarked connections are still processed in the main thread pool. This isolates slow-processing client requests to the backup thread pool, using independent NFSD threads in the backup thread pool to handle slow services affected by traffic control, preventing thread blocking caused by slow services from spreading to the main thread pool. This prevents the NFSD threads in the main thread pool from entering an uninterruptible sleep state, which could affect the performance of other clients, ensuring efficient response of the main thread pool in handling regular services. This improves the reliability, business continuity, and service quality of the NFS service.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this application, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] Figure 1 This is a flowchart illustrating an NFS thread redundancy handling method with some exemplary embodiments; Figure 2 This is a flowchart illustrating an NFS thread redundancy handling method, as shown in some other exemplary embodiments; Figure 3 This is a flowchart illustrating an NFS thread redundancy handling method with some exemplary embodiments; Figure 4 These are schematic diagrams illustrating the structure of an NFS thread redundancy processing device, as shown in some exemplary embodiments. Figure 5 These are schematic diagrams illustrating the hardware structure of an electronic device through some exemplary embodiments. Detailed Implementation

[0020] NFS enables different machines and operating systems to share files over a network. Different clients use applications to access data located on the server's disk over the network to achieve disk file sharing.

[0021] NFS uses RPC for communication. RPC is a service request made from a remote computer program over a network. RPC does not need to understand the underlying network technology; it assumes the existence of certain transport protocols, such as TCP or UDP (User Datagram Protocol), to carry information between communicating programs. In the OSI (Open Systems Interconnection Reference Model) network communication model, RPC spans the transport and application layers. NFS relies on the RPC protocol during file or data transfer. The specific process of NFS shared directories is as follows: (1) The NFS client program initiates an RPC call, encapsulates different operations and parameters into a request message, and sends it to the NFS server based on the TCP protocol.

[0022] (2) The NFS server listens on a socket. When it receives an RPC request from the NFS client, it will wake up the idle NFSD thread to process the request. The awakened NFSD thread starts to receive the request data, and then performs the corresponding operation according to the received request and the parameters passed by it, and waits for the underlying file system to return the actual operation result to the NFSD thread.

[0023] (3) The NFSD thread on the NFS server encapsulates the execution result returned by the underlying file system into a response message, and then returns it to the NFS client via the TCP / IP protocol. After completion, the NFSD thread enters a sleep state and waits for the next wake-up.

[0024] (4) The NFS client receives the RPC response information and obtains the operation result.

[0025] The NFSD thread's processing flow involves invoking operations on the underlying file system, such as read and write operations. It dispatches read and write I / O to the file system, allowing the file system to complete the actual read and write operations. During this process, the NFSD thread waits for the underlying read and write operations to complete, remaining in an uninterruptible state. After the file system completes the read and write operations and returns the results to the NFSD thread, the NFSD thread sends the operation results to the NFS client and enters a sleep state. This sleep state can be awakened by the next NFS client request. However, if the file system fails or the disk is damaged after the NFSD thread has dispatched read and write I / O to the file system, causing the NFSD thread to remain in an uninterruptible state, under high traffic conditions, this can easily lead to all NFSD threads entering the D state, thus preventing them from responding to NFS client requests and causing NFS client operations to freeze.

[0026] To address the aforementioned problems, this application proposes a method, apparatus, and electronic device for handling NFS thread redundancy. The following embodiments are provided to further illustrate this application: Please see Figure 1 , Figure 1 This is a flowchart illustrating an NFS thread redundancy handling method with some exemplary embodiments. The method is applied to an NFS server, which locally configures a second NFS service thread pool to cooperate with a first NFS service thread pool created in the original GLOBAL global shared thread pool mode. Initially, the first NFS service thread pool serves as the primary thread pool, and the second NFS service thread pool serves as the backup thread pool. The method may include the following steps: Step S110: When a request is received from the first NFS client, if the shared directory that the first NFS client requests to access has an activated traffic control policy, and the connection from the first NFS client to this server is not marked as a specified service type, then mark the connection as a specified service type.

[0027] In this system, the NFS server can create a first NFS service thread pool and a second NFS service thread pool when the system or NFS service starts. It can also configure NFSD threads in each thread pool. The number of NFSD threads in the two thread pools can be the same or different; for example, the first NFS service thread pool can be configured with 8 NFSD threads, and the second NFS service thread pool with 4 NFSD threads. Specifically, in this embodiment, the first and second NFS service thread pools both have the same number of NFSD threads: 8. The NFS server binds to a specified port number via a socket and listens for TCP connection requests on that port. When the NFS client needs to perform file operations, such as reading a file, writing data, or obtaining file attributes, the client program encapsulates the operation type and corresponding operation parameters into a request message conforming to the RPC protocol and sends the request message to the listening port of the NFS server via the TCP protocol.

[0028] After receiving the TCP packet, the protocol stack of the server-side operating system kernel delivers it to the NFS service process listening on that port, based on the destination port number carried in the packet. The NFS server reads the request packet from the socket's receive buffer, parses the packet header to obtain information such as the request type, file handle, and operation parameters. To facilitate subsequent processing, the server can temporarily store the received request packet in a request queue or directly trigger the thread pool's wake-up mechanism.

[0029] For example, when the NFS server receives an I / O request from the first NFS client, it first parses the shared directory configuration corresponding to the request and monitors in real time whether a flow control policy has been activated. The flow control policy limits the read and write bandwidth of the underlying file system to the shared directory. If the server detects that the shared directory has activated a flow control policy due to limited underlying storage bandwidth, it immediately extracts the network connection identifier of the first NFS client that initiated the request. If it confirms that the current connection from this client to the server has not yet been marked as a specified service type (e.g., no specific second-level traffic flag is set), the server marks it as such. Through this marking operation, the system can accurately identify slow service connections affected by flow control, thus laying the foundation for subsequently distributing all NFS read and write requests on that connection to an independent backup thread pool for isolated processing, effectively preventing such high-latency requests from consuming the main thread pool's computing resources.

[0030] Step S120: When the first NFS client sends an NFS request through the connection again, the NFS request is distributed to the backup thread pool for processing, so as to use the backup thread pool to isolate the business of the NFS client from the business of other NFS clients.

[0031] For example, when the NFS server receives a subsequent read / write operation request from the first NFS client through an established connection, it will directly distribute the request, carrying the specified service type flag set in the previous steps, to the pre-configured second NFS service thread pool, i.e., the task waiting queue of the backup thread pool. Distributing the NFS request to the backup thread pool for processing includes distributing NFS requests whose processing time is increased due to bandwidth limitations to the backup thread pool. Idle NFSD threads in the backup thread pool will retrieve the request from their dedicated queue and call the underlying file system interface to perform the actual disk I / O processing and data return. Through this forced traffic splitting, slow services that are affected by flow control and are expected to have long processing times can be restricted to execution within the backup thread pool, thereby ensuring that the main thread pool can continuously and efficiently respond to other regular client requests not affected by flow control, achieving resource isolation between services of different priorities or performance characteristics.

[0032] Step S130: When a request is received from the second NFS client, if the shared directory that the second NFS client requests to access has not had its traffic control policy activated, or if the connection from the second NFS client to this server has not been marked as a specified business type, the NFS request is dispatched to the main thread pool for processing.

[0033] For example, when the NFS server receives any NFS request initiated by a second NFS client, the NFS server will confirm whether the directory currently has a traffic control policy activated and determine whether it carries a traffic distribution tag for a specified service type. If the shared directory requested by the second NFS client does not have a traffic control policy activated, or if the connection from the second NFS client to this server is not marked as a specified service type, the NFS request will be directly distributed to the original first NFS service thread pool, i.e., the main thread pool. This step ensures that normal business traffic not affected by the underlying storage bandwidth limitations can still be efficiently responded to by the main thread pool, thereby guaranteeing the throughput and low latency experience of core services.

[0034] The NFS thread redundancy handling method in this embodiment pre-configures a backup thread pool that works in conjunction with the main thread pool. It then distributes client requests based on flow control policies and connection status markings. When a client requests access to a shared directory with activated flow control policies, the connection is marked as a specific service type. All subsequent requests from this client are then distributed to the backup thread pool for processing. Client requests without activated flow control policies or whose connections are not marked remain processed in the main thread pool. This isolates slow-processing client requests due to flow control policies to the backup thread pool. The independent NFSD thread in the backup thread pool handles slow services affected by flow control, preventing thread blocking caused by slow services from spreading to the main thread pool. This prevents the NFSD thread in the main thread pool from entering an uninterruptible state, thus avoiding impacting the performance of other clients and ensuring efficient response of the main thread pool for regular services. This improves the reliability, business continuity, and service quality of the NFS service.

[0035] In one embodiment, see Figure 2 , Figure 2 This is a flowchart illustrating an NFS thread redundancy handling method according to some other exemplary embodiments. The method may also include the following steps: Step S210: Monitor the configuration status of the underlying file system.

[0036] For example, the NFS server scans and monitors the configuration status of the underlying file system in real time, primarily targeting the core configuration files of the NFS service, such as / etc / exports, to detect whether there are any additions, modifications, or deletions to specific shared directories. By continuously monitoring the configuration files, the server can promptly detect whether the underlying file system has issued instructions for new traffic control policies, thus providing accurate and real-time triggering basis for subsequent dynamic updates to the NFS configuration and adjustments to business traffic distribution.

[0037] Step S220: When it is detected that the traffic control policy for the target shared directory is activated, automatically update the NFS configuration file and add the QoS flag to the configuration item corresponding to the target shared directory; if the traffic control policy for the shared directory that the first NFS client requests to access has been activated, the traffic control policy includes: the shared directory that the first NFS client requests to access contains the QoS flag in the NFS configuration file.

[0038] For example, when the underlying file system detects an instruction that has activated a traffic control policy for a specific target shared directory, the NFS server will automatically trigger a configuration update operation. This is achieved by directly modifying the core configuration file of the NFS service at the application layer, such as ` / etc / exports`, by appending a dedicated QoS flag option to the export configuration line corresponding to the target shared directory. Subsequently, when the first NFS client initiates an access request, the server reads and parses this configuration file to accurately identify whether the target shared directory's configuration items contain this QoS flag. Once the presence of this flag is detected, the system can determine that the directory has currently had a traffic control policy activated, thereby marking subsequent client connections as the specified service type and diverting their requests to the backup thread pool.

[0039] The NFS thread redundancy handling method in this embodiment monitors the configuration status of the underlying file system and automatically updates the NFS configuration file and adds a QoS flag to the target shared directory when a traffic control policy is activated. This ensures that the activation information of the traffic control policy is persistently stored in the NFS configuration file. When processing client requests, the NFS server only needs to read the configuration file to determine whether the shared directory is subject to traffic control constraints, without needing to interact with the underlying file system in real time, thus avoiding the overhead of frequent status queries. Furthermore, the automated configuration update process does not require manual intervention from the administrator, reducing the possibility of human error and improving the system's automated operation and maintenance capabilities. In addition, using the QoS flag as a criterion ensures that subsequent business separation logic can be executed in a unified and efficient manner, providing a reliable prerequisite for the entire thread redundancy handling scheme.

[0040] In one embodiment, see Figure 3 , Figure 3 This is a flowchart illustrating an NFS thread redundancy handling method with some exemplary embodiments. The method may also include the following steps: Step S310: When it is detected that the traffic control policy for the target shared directory is suspended or canceled, clear the QoS flag corresponding to the target shared directory in the NFS configuration file.

[0041] For example, the NFS server monitors the traffic control policy status of the underlying file system. When it detects that the traffic control policy of a target shared directory is suspended (e.g., by an administrator executing a pause command) or canceled (e.g., by the traffic control policy expiring or being actively deleted), the server automatically locates the NFS exported configuration file, such as the configuration entry for the shared directory in / etc / exports, and removes the previously added QoS flags. After the cleanup operation is complete, the NFS server reloads the configuration file.

[0042] Step S320: When a request is received on a connection marked as a specified service type, if it is detected that the shared directory corresponding to the request is not marked with a QoS flag, the specified service type flag of the connection is cleared, so that subsequent requests are distributed to the main thread pool for processing.

[0043] For example, when any NFS client requests access to the shared directory, since there is no QoS flag in the configuration file, the server will no longer mark the client's connection as the specified service type. The already marked connections will be cleaned up and switched back according to the new configuration status when subsequent requests are received.

[0044] The NFS thread redundancy handling method in this embodiment monitors the suspension or cancellation events of traffic control policies, automatically clears the QoS flags in the NFS configuration file, and clears the specified service type flag of the connection when a request on a tagged connection is received and a missing flag is detected. This ensures that when the traffic control policy is no longer in effect, client requests that were originally diverted to the backup thread pool can automatically resume processing by the main thread pool without manual intervention from the administrator or restarting the NFS service, ensuring reasonable resource utilization and flexible business processing. It also guarantees that subsequent requests will be naturally diverted to the main thread pool without interrupting ongoing business operations, maintaining business continuity.

[0045] In one embodiment, the method further includes: timing the process of each NFSD thread in the main thread pool handling NFS requests; when any NFSD thread times out, adding a busy flag to the shared directory corresponding to the request, and counting the number of NFSD threads that have timed out; when the number of NFSD threads that have timed out is equal to the total number of NFSD threads in the main thread pool, switching the second NFS service thread pool, which was originally a backup thread pool, to the new main thread pool, and switching the first NFS service thread pool, which was originally the main thread pool, to the new backup thread pool; when the new main thread pool receives an NFS request, if the shared directory corresponding to the request has a busy flag, returning an error code indicating that the resource is busy to the NFS client; if the shared directory corresponding to the request does not have a busy flag, processing the request normally.

[0046] For example, the NFS server sets a timer and a timeout threshold for each NFSD thread in the main thread pool to process a single NFS request. When the request completes normally, the timer is canceled; if the timer times out, a timeout handling function is triggered, adding the name of the shared directory accessed by the request to a busy flag. A counter is also set to count the number of NFSD threads currently in a timeout state. The server continuously checks the number of NFSD threads in a timeout state. When the count equals the total number of NFSD threads configured in the main thread pool, the server determines that the main thread pool has completely failed. At this point, the server performs a thread pool role switch, marking the second NFS service thread pool (formerly a backup thread pool) as the new main thread pool and the first NFS service thread pool (formerly the main thread pool) as the new backup thread pool. Subsequently, each time the NFSD thread in the new main thread pool receives an NFS request, it first extracts the shared directory path from the request and checks if the shared directory has a "busy" flag. If the "busy" flag exists, it directly returns an error code to the NFS client. This error code can be a custom error code indicating that the resource is busy or the shared directory is faulty, and I / O to the underlying file system will no longer be sent. If the flag does not exist, the request is processed normally. In this way, even if the original main thread pool is completely blocked due to a shared directory failure, the new main thread pool can continue to respond to requests from other healthy shared directories, thus ensuring partial availability of the NFS service.

[0047] In a feasible embodiment, the method may further include: monitoring the status of timed-out NFSD threads in the new backup thread pool; and clearing the busy flag of the corresponding shared directory when all NFSD threads are not in an uninterruptible state. The uninterruptible state refers to the state in which an NFSD thread, while processing read / write operations on the underlying file system, waits for the read / write operation to complete and cannot be terminated by an external signal. It is understood that after the NFS server completes the role swap between the primary and backup thread pools, it monitors the current status of each NFSD thread in the new backup thread pool, reads the task status field of each NFSD thread, and determines whether it is still in an uninterruptible state (TASK_UNINTERRUPTIBLE, i.e., state D). When it is detected that all NFSD threads have exited the uninterruptible state, it indicates that the underlying file system failure or disk problem that caused the timeout has been recovered, and the previously blocked requests have been processed. At this time, the server automatically clears the busy flag of the corresponding shared directory. Afterward, if an NFS client requests access to the shared directory again, since the busy flag no longer exists, the NFSD threads in the new primary thread pool will normally receive and process the request without returning an error code.

[0048] The NFS thread redundancy handling method in this embodiment sets timeout and statistics strategies for each NFSD thread in the main thread pool, and automatically switches the backup thread pool to the new main thread pool when all NFSD threads in the main thread pool are in an uninterruptible state. Simultaneously, it rejects requests for faulty shared directories carrying the "busy" flag. This allows the system to automatically switch between main and backup roles when a failure in the underlying file system or disk causes all threads in the original main thread pool to enter an uninterruptible state. The new main thread pool rejects requests to the faulty shared directory while continuing to process requests to other normal shared directories, thus preventing a complete paralysis of the NFS service, ensuring business continuity, and improving the system's fault tolerance. Furthermore, by monitoring the status of threads in the new backup thread pool, the "busy" flag is automatically cleared after the fault is recovered, allowing previously rejected shared directories to resume normal service without manual intervention. This automatic fault repair solves the problem of overall service unavailability caused by the anomalies of some shared directories.

[0049] It should be noted that, in one specific embodiment of the present invention, when client requests affected by traffic control policies are allocated to the backup thread pool and the roles of the primary and backup thread pools are switched through timeout detection, the following process is adopted: First, under normal circumstances, client requests accessing shared directories with QoS flags are marked as specified service types and distributed to the backup thread pool for processing; other client requests are distributed to the primary thread pool for processing. When the primary thread pool causes all NFSD threads to enter an uninterruptible state due to underlying file system or disk failure, the server performs the following operations: (1) Switch the original backup thread pool to the new main thread pool, and switch the original main thread pool to the new backup thread pool.

[0050] (2) After the switch is completed, the new main thread pool needs to handle two types of requests at the same time: the first type is slow client requests that are pre-assigned to the thread pool due to business separation, i.e. requests on connections marked with a specified business type; the second type is other client requests that are transferred from the original main thread pool due to business migration.

[0051] (3) For any NFS request received by the new main thread pool, first determine whether the shared directory corresponding to the request has a busy flag: if it has a busy flag, that is, the shared directory is the fault directory that caused the original main thread pool to fail, then return an error code to the NFS client and refuse to process it; if it does not have a busy flag, then process the request normally.

[0052] (4) For connections that were originally marked as having a specific business type, after the primary and backup thread pools are switched, requests on those connections will continue to be handled by the new primary thread pool, and the processing logic will be the same as for ordinary requests: normal processing when accessing a non-faulty shared directory, and an error code will be returned when accessing a faulty shared directory. Optionally, the server can clear the designated business type markings of all connections after the business migration is triggered, so that all client requests are processed uniformly according to the logic after the business migration; or the marking can be retained, but the marking itself will no longer affect the distribution target (because at this time only one primary thread pool is running the business).

[0053] (5) When all NFSD threads in the new backup thread pool exit the uninterruptible state, it indicates that the fault has been recovered, and the server clears the busy flag of the corresponding shared directory. Afterwards, if the QoS flag of the shared directory still exists, meaning the flow control policy is still active, subsequent client requests will still be marked as the specified service type and distributed to the current backup thread pool for processing; if the QoS flag has been cleared, all requests will be processed by the current main thread pool. It should be noted that the main and backup roles will not be swapped back to their initial states after service migration to maintain the simplicity of the system state.

[0054] For a second aspect of the embodiments of this application, please refer to Figure 4 , Figure 4 These are structural schematic diagrams illustrating an NFS thread redundancy processing device through exemplary embodiments. An NFS thread redundancy processing device is provided, applied to an NFS server. The NFS server is locally configured with a second NFS service thread pool that cooperates with a first NFS service thread pool created in the original GLOBAL global shared thread pool mode. Initially, the first NFS service thread pool serves as the primary thread pool, and the second NFS service thread pool serves as the backup thread pool. The device includes: The marking module 410 is configured to mark the connection as a specified service type when it receives a request from the first NFS client, if the shared directory that the first NFS client requests to access has an activated traffic control policy, and the connection from the first NFS client to this server is not marked as a specified service type. The first distribution module 420 is configured to distribute the NFS request to the backup thread pool for processing when it receives the NFS request sent by the first NFS client through the connection, so as to use the backup thread pool to isolate the business of the NFS client from the business of other NFS clients. The second distribution module 430 is configured to, when receiving a request from a second NFS client, if the shared directory requested by the second NFS client is not subject to an activated traffic control policy, or if the connection from the second NFS client to this server is not marked as a specified business type, distribute the NFS request to the main thread pool for processing.

[0055] In some embodiments, the apparatus further includes: The first monitoring module is configured to monitor the configuration status of the underlying file system; The first module is configured to automatically update the NFS configuration file and add a QoS flag to the configuration item corresponding to the target shared directory when it is detected that the traffic control policy for the target shared directory is activated. If the shared directory requested by the first NFS client has an activated traffic control policy, the policy includes: the shared directory requested by the first NFS client contains a QoS flag in the NFS configuration file. And / or, The device also includes: The first clearing module is configured to clear the QoS flag corresponding to the target shared directory in the NFS configuration file when it is detected that the traffic control policy for the target shared directory is suspended or canceled. The second clearing module is configured to, when receiving a request on a connection marked with a specified service type, if it is detected that the shared directory corresponding to the request is not marked with a QoS flag, clear the specified service type flag of the connection, so that subsequent requests are distributed to the main thread pool for processing.

[0056] In some embodiments, the flow control policy is used to limit the read and write bandwidth of the underlying file system to the shared directory; Distributing the NFS request to the backup thread pool for processing includes: distributing NFS requests whose processing time is increased due to bandwidth limitations to the backup thread pool for processing; And / or, The device also includes: The timing module is configured to time the process of each NFSD thread in the main thread pool handling an NFS request. The second addition module is configured to add a busy flag to the shared directory corresponding to the request when any NFSD thread times out, and to count the number of NFSD threads that have timed out. The switching module is configured to switch the second NFS service thread pool, which is currently the backup thread pool, to the new main thread pool when the number of timed-out NFSD threads is equal to the total number of NFSD threads in the main thread pool, and switch the first NFS service thread pool, which was originally the main thread pool, to the new backup thread pool. When the new main thread pool receives an NFS request, if the shared directory corresponding to the request has the busy flag, it returns an error code indicating that the resource is busy to the NFS client; if the shared directory corresponding to the request does not have the busy flag, it processes the request normally. And / or, The device also includes: The second monitoring module is configured to monitor the status of timed-out NFSD threads in the new backup thread pool. The third cleanup module is configured to clear the busy flag of the corresponding shared directory when all NFSD threads are not in an uninterruptible state. The uninterruptible state is the state in which NFSD threads wait for the read and write operations of the underlying file system to complete and cannot be terminated by external signals.

[0057] This application can be implemented by executing several computer program code flows using an electronic device. The electronic device loads the computer program into non-volatile memory and uses its processor to read these computer program instructions into memory for execution. A hardware structure diagram of the electronic device, besides... Figure 5 In addition to the processor, memory, network interface, and non-volatile memory shown, electronic devices may also include other hardware depending on their actual functions, which will not be elaborated further.

Claims

1. A method for handling thread redundancy in a Network File System (NFS), wherein the method is applied to the NFS server, characterized in that, The NFS server is locally configured with a second NFS service thread pool that works in conjunction with the first NFS service thread pool created in the original global shared thread pool GLOBAL mode. Initially, the first NFS service thread pool is used as the main thread pool and the second NFS service thread pool is used as the backup thread pool. The method includes: When a request is received from the first NFS client, if the shared directory that the first NFS client requests to access has an activated traffic control policy, and the connection from the first NFS client to this server is not marked as a specified service type, then the connection is marked as a specified service type. When an NFS request is subsequently received from the first NFS client through the connection, the NFS request is distributed to the backup thread pool for processing, so as to use the backup thread pool to isolate the business of the NFS client from the business of other NFS clients. When a request is received from a second NFS client, if the shared directory that the second NFS client requests to access has not had its traffic control policy activated, or if the connection from the second NFS client to this server has not been marked as a specified service type, the NFS request is distributed to the main thread pool for processing.

2. The method according to claim 1, characterized in that, The method further includes: Monitor the configuration status of the underlying file system; When a traffic control policy for the target shared directory is detected to be activated, the NFS configuration file is automatically updated, and a QoS flag is added to the configuration item corresponding to the target shared directory. The condition that the shared directory requested by the first NFS client has an activated traffic control policy includes: the shared directory requested by the first NFS client contains the QoS flag in the NFS configuration file.

3. The method according to claim 2, characterized in that, The method further includes: When it is detected that the traffic control policy for the target shared directory is suspended or canceled, the QoS flag corresponding to the target shared directory in the NFS configuration file is cleared; when a request is received on a connection marked with a specified service type, if it is detected that the shared directory corresponding to the request is not marked with a QoS flag, the specified service type flag of the connection is cleared, so that subsequent requests are distributed to the main thread pool for processing.

4. The method according to claim 1, characterized in that, The flow control policy is used to limit the read and write bandwidth of the underlying file system to the shared directory; the step of distributing the NFS request to the backup thread pool for processing includes: distributing NFS requests whose processing time is increased due to bandwidth limitation to the backup thread pool for processing.

5. The method according to claim 1, characterized in that, The method further includes: Time the process of each NFSD thread in the main thread pool handling an NFS request. When any NFSD thread times out processing a request, add a busy flag to the shared directory corresponding to that request and count the number of NFSD threads that have timed out. When the number of NFSD threads that have timed out is equal to the total number of NFSD threads in the main thread pool, the second NFS service thread pool, which was originally the backup thread pool, will be switched to the new main thread pool, and the first NFS service thread pool, which was originally the main thread pool, will be switched to the new backup thread pool. When the new main thread pool receives an NFS request, if the shared directory corresponding to the request has the busy flag, it returns an error code indicating that the resource is busy to the NFS client; if the shared directory corresponding to the request does not have the busy flag, it processes the request normally.

6. The method according to claim 5, characterized in that, The method further includes: Monitor the status of timed-out NFSD threads in the new backup thread pool; When all NFSD threads are not in an uninterruptible state, the busy flag of the corresponding shared directory is cleared. The uninterruptible state is the state in which the NFSD thread waits for the read / write operation to complete and cannot be terminated by an external signal while processing the read / write operation of the underlying file system.

7. A network file system (NFS) thread redundancy processing device, the device being applied to the NFS server, characterized in that, The NFS server is locally configured with a second NFS service thread pool that works in conjunction with the first NFS service thread pool created in the original global shared thread pool GLOBAL mode. Initially, the first NFS service thread pool is used as the main thread pool and the second NFS service thread pool is used as the backup thread pool. The device includes: The marking module is configured to mark the connection as a specified service type when it receives a request from the first NFS client, if the shared directory that the first NFS client requests to access has an activated traffic control policy, and the connection from the first NFS client to this server has not been marked as a specified service type. The first distribution module is configured to, upon receiving an NFS request from the first NFS client via the connection, distribute the NFS request to the backup thread pool for processing, thereby using the backup thread pool to isolate the NFS client's business from the business of other NFS clients. The second distribution module is configured to, when receiving a request from a second NFS client, distribute the NFS request to the main thread pool for processing if the shared directory requested by the second NFS client has not been activated by a traffic control policy, or if the connection from the second NFS client to this server has not been marked as a specified service type.

8. The apparatus according to claim 7, characterized in that, The device further includes: The first monitoring module is configured to monitor the configuration status of the underlying file system; The first addition module is configured to automatically update the NFS configuration file and add a QoS flag to the configuration item corresponding to the target shared directory when it is detected that the traffic control policy for the target shared directory is activated. The condition that the shared directory requested by the first NFS client has an activated traffic control policy includes: the shared directory requested by the first NFS client contains the QoS flag in the NFS configuration file. And / or, The device further includes: The first clearing module is configured to clear the QoS flag corresponding to the target shared directory in the NFS configuration file when it is detected that the traffic control policy for the target shared directory is suspended or canceled. The second clearing module is configured to, when receiving a request on a connection marked with a specified service type, if it is detected that the shared directory corresponding to the request is not marked with a QoS flag, clear the specified service type flag of the connection, so that subsequent requests are distributed to the main thread pool for processing.

9. The apparatus according to claim 7, characterized in that, The flow control strategy is used to limit the read and write bandwidth of the underlying file system to the shared directory; The step of distributing the NFS request to the backup thread pool for processing includes: distributing NFS requests whose processing time is increased due to bandwidth limitations to the backup thread pool for processing; And / or, The device further includes: The timing module is configured to time the process of each NFSD thread in the main thread pool handling an NFS request. The second addition module is configured to add a busy flag to the shared directory corresponding to the request when any NFSD thread times out, and to count the number of NFSD threads that have timed out. The switching module is configured to switch the second NFS service thread pool, which is the backup thread pool, to the new main thread pool when the number of NFSD threads that have timed out is equal to the total number of NFSD threads in the main thread pool, and switch the first NFS service thread pool, which was originally the main thread pool, to the new backup thread pool. When the new main thread pool receives an NFS request, if the shared directory corresponding to the request has the busy flag, it returns an error code indicating that the resource is busy to the NFS client; if the shared directory corresponding to the request does not have the busy flag, it processes the request normally. And / or, The device further includes: The second monitoring module is configured to monitor the status of timed-out NFSD threads in the new backup thread pool. The third clearing module is configured to clear the busy flag of the corresponding shared directory when all the NFSD threads are not in an uninterruptible state. The uninterruptible state is the state in which the NFSD thread waits for the read / write operation to complete and cannot be terminated by an external signal when processing the read / write operation of the underlying file system.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 6.

Images