Method for managing shared directory under distributed file system and electronic device

Abstract

The application discloses a kind of management method and electronic equipment of shared directory under distributed file system, it is related to distributed file system technical field, including: partition identification is created when shared directory is created in protocol layer;Metadata management object of shared directory is created in file system layer and is bound with partition identification;First target thread and target metadata management object corresponding to directory operation request are determined, and directory operation request is handled according to first target thread and target metadata management object.Solve when exporting or accessing shared directory, all shared directory export or access blockage can be caused due to a request blockage, affect the problem that upper application accesses shared directory.The method uses metadata management object to carry out metadata partition management to shared directory, sets first target thread for target shared directory to handle directory operation request, realizes resource management and request access isolation between different shared directories, and a request blockage cannot affect access other shared directories.

Description

Management methods and electronic devices for shared directories in a distributed file system Technical Field

[0001] This invention relates to the field of distributed file system technology, and more specifically to a method and electronic device for managing shared directories under a distributed file system. Background Technology

[0002] Distributed file systems are used to store massive amounts of unstructured data. NFS (Network File System) is a file system access protocol that allows a distributed file system to be shared with a large number of clients. By creating a shared directory in the distributed file system and then sharing the shared directory through the NFS protocol, clients can mount the shared directory for access.

[0003] Distributed file systems (NFS) feature a globally unified namespace. These shared directories are essentially subdirectories within the same NFS file system. The metadata and data generated by these shared directories are managed uniformly throughout the entire NFS, without physical or logical isolation. Currently, exporting a shared directory exports the metadata and data of the entire NFS file system, causing prolonged blocking times for shared directory export requests and impacting the export or access of other shared directories. When accessing a shared directory, a thread pool is started at the NFS protocol layer. All threads in the pool process client requests in a round-robin fashion. When a request for a particular shared directory is blocked, and all threads are processing that request, there are no spare threads to handle requests for other shared directories, causing all shared directory access to be blocked and directly affecting access to upper-layer applications.

[0004] Therefore, the relevant technologies have the problem that when exporting or accessing a shared directory, a blocking request can cause all shared directory exports or accesses to be blocked, affecting upper-layer applications' access to the shared directory. Summary of the Invention

[0005] In view of this, the present invention provides a method and electronic device for managing shared directories under a distributed file system, in order to solve the problem that when exporting or accessing a shared directory, the export or access of all shared directories may be blocked due to the blocking of a certain request, which affects the access of upper-layer applications to the shared directory.

[0006] Firstly, this application provides a method for managing shared directories under a distributed file system. This method is applied at the file system layer and includes:

[0007] Obtain the shared directory created by the protocol layer and determine the partition identifier of the shared directory;

[0008] A metadata management object for the shared directory is created based on the shared directory's metadata, and the metadata management object is bound to the partition identifier to obtain the first binding relationship. The metadata management object is used to manage the shared directory's metadata.

[0009] Upon receiving a directory operation request sent by the protocol layer, the target shared directory corresponding to the directory operation request and the first target thread corresponding to the target shared directory are determined. The directory operation request is obtained by the protocol layer after injecting the target partition identifier into the initial directory operation request.

[0010] The target metadata management object is determined based on the target partition identifier and the first binding relationship in the directory operation request, and the directory operation request is processed based on the first target thread and the target metadata management object.

[0011] Secondly, this application provides a method for managing shared directories under a distributed file system. This method is applied at the protocol layer and includes:

[0012] A shared directory is created in the file system layer, and the partition identifier of the shared directory is determined so that the file system layer binds the partition identifier to the metadata management object of the shared directory to obtain the first binding relationship. The metadata management object is created by the file system layer based on the metadata of the shared directory and is used to manage the metadata of the shared directory.

[0013] Upon receiving an initial directory operation request from the client, determine the target partition identifier corresponding to the initial directory operation request;

[0014] The target partition identifier is injected into the initial directory operation request to obtain the directory operation request, and the directory operation request is sent to the file system layer. The file system layer is used to determine the target shared directory corresponding to the directory operation request and the first target thread corresponding to the target shared directory. The target metadata management object is determined according to the target partition identifier and the first binding relationship, and the directory operation request is processed according to the first target thread and the target metadata management object.

[0015] Thirdly, this application provides a management device for a shared directory under a distributed file system, which is deployed at the file system layer and includes:

[0016] The first information determination module is used to obtain the shared directory created by the protocol layer and determine the partition identifier of the shared directory;

[0017] The binding module is used to create a metadata management object for the shared directory based on the shared directory's metadata, and bind the metadata management object to the partition identifier to obtain the first binding relationship. The metadata management object is used to manage the metadata of the shared directory.

[0018] The second information determination module is used to determine the target shared directory corresponding to the directory operation request and the first target thread corresponding to the target shared directory when a directory operation request is received from the protocol layer. The directory operation request is obtained by the protocol layer after injecting the target partition identifier into the initial directory operation request.

[0019] The request processing module is used to determine the target metadata management object based on the target partition identifier and the first binding relationship in the directory operation request, and to process the directory operation request based on the first target thread and the target metadata management object.

[0020] Fourthly, this application provides a management device for a shared directory under a distributed file system. This device is deployed at the protocol layer and includes:

[0021] The directory creation module is used to create shared directories in the file system layer and determine the partition identifier of the shared directory so that the file system layer can bind the partition identifier to the metadata management object of the shared directory to obtain the first binding relationship. The metadata management object is created by the file system layer based on the metadata of the shared directory and is used to manage the metadata of the shared directory.

[0022] The third information determination module is used to determine the target partition identifier corresponding to the initial directory operation request when it receives the initial directory operation request sent by the client.

[0023] The request sending module is used to inject the target partition identifier into the initial directory operation request, obtain the directory operation request, and send the directory operation request to the file system layer. The file system layer is used to determine the target shared directory corresponding to the directory operation request and the first target thread corresponding to the target shared directory, determine the target metadata management object according to the target partition identifier and the first binding relationship, and process the directory operation request according to the first target thread and the target metadata management object.

[0024] Fifthly, this application provides an electronic device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the management method of a shared directory under a distributed file system according to the first aspect or any corresponding embodiment described above, or to perform the management method of a shared directory under a distributed file system according to the second aspect or any corresponding embodiment described above.

[0025] In a sixth aspect, this application provides a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the management method of a shared directory under a distributed file system according to the first aspect or any corresponding embodiment described above, or to execute the management method of a shared directory under a distributed file system according to the second aspect or any corresponding embodiment described above.

[0026] In a seventh aspect, this application provides a computer program product, including computer instructions, which are used to cause a computer to execute the management method of a shared directory under a distributed file system according to the first aspect or any corresponding embodiment described above, or to execute the management method of a shared directory under a distributed file system according to the second aspect or any corresponding embodiment described above.

[0027] This application addresses the issue that when exporting or accessing a shared directory, a blocking request can cause all shared directories to be blocked due to the blocking of a single request, thus affecting upper-layer applications' access to the shared directory. This method utilizes a metadata management object to manage the metadata partitions of the shared directory, adds a file system thread pool, and sets a corresponding first target thread for the target shared directory. The first target thread only handles directory operation requests bound to the shared directory, achieving resource management and request access isolation between different shared directories. When a request to one shared directory is blocked, it will not affect access to other shared directories, improving the overall robustness and stability of the system. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this application, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0029] Figure 1 is a schematic diagram of the traditional export and access of a shared directory in a distributed file system according to an embodiment of this application;

[0030] Figure 2 is a flowchart illustrating a method for managing a shared directory under a distributed file system applied to the file system layer according to an embodiment of this application;

[0031] Figure 3 is a schematic diagram of metadata partition management according to an embodiment of this application;

[0032] Figure 4 is a schematic diagram of thread scheduling isolation according to an embodiment of this application;

[0033] Figure 5 is a flowchart illustrating a method for managing a shared directory under a distributed file system applied to the protocol layer according to an embodiment of this application;

[0034] Figure 6 is a structural block diagram of a management device for a shared directory deployed under a distributed file system layer according to an embodiment of this application;

[0035] Figure 7 is a structural block diagram of a management device for a shared directory deployed under a distributed file system at the protocol layer according to an embodiment of this application;

[0036] Figure 8 is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0037] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0038] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0039] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0040] The specific application environment architecture or specific hardware architecture on which the execution of the management method of shared directories under the distributed file system depends is described here.

[0041] With the rapid development of technologies such as big data and artificial intelligence, distributed file systems have become the core infrastructure for storing massive amounts of unstructured data. NFS is a file system access protocol that allows a distributed file system to be shared with a large number of clients. An exported directory is created in the distributed file system, and then shared via the NFS protocol, allowing clients to mount and access this shared directory. In production applications, the NFS protocol is typically used to access the file system, and multiple shared directories are exported and accessed simultaneously. Unmounting an exported directory triggers an fsync operation on the shared directory. fsync is a metadata and data flushing interface, and the fsync operation includes the export of the shared directory. When exporting shared directories, dozens or hundreds of shared directories may be exported depending on the actual business type and workload. Distributed file systems have a globally unified namespace; these shared directories are actually subdirectories within the same file system. The metadata and data generated by these directories are managed uniformly within the entire file system, without physical or logical isolation. For example, the file index nodes (INODEs) accessed through any shared directory are managed by a unified linked list, as shown in part ① of Figure 1. When performing an `fsync` operation on a shared directory, the intended meaning is to flush the metadata and data of the current shared directory's subfiles to the backend storage. However, since all shared directories belong to the same file system, `fsync` actually flushes the metadata and data of the entire file system, including other shared exported directories. This is equivalent to flushing a large amount of additional metadata and data, causing the `fsync` command to block for a considerable time. If `fsync` is triggered by a higher-level command line (e.g., unmounting or loading a shared exported directory), it will cause that command line to time out. In Figure 1, exporting A refers to shared directory A. The file system created three directories: A, B, and C. Then, the NFS protocol layer exports these three directories, namely shared directory A, shared directory B, and shared directory C. Exporting A allows you to see the metadata and data of all subfiles under shared directory A.

[0042] After exporting the shared directory, the mounted shared directory can be accessed by the client. Taking NFS-Ganesha as an example, NFS-Ganesha is an NFS protocol server process that can seamlessly connect to a distributed file system and share the distributed file system via the NFS protocol. This software is widely used in production environments. When accessing a shared directory, a thread pool is started at the NFS protocol layer. All threads in the thread pool process client requests in a round-robin manner, as shown in part ② of Figure 1. When a request for a certain shared directory is blocked, such as during the fsync operation mentioned above, the default way to obtain a thread from the NFS thread pool is to find the currently idle thread or the thread with the least business load. Multiple shared directories share the same NFS thread pool. When a request for a certain shared directory is blocked or the processing latency is very high, and the front-end host has a large number of access operations to that shared directory, then most or all threads in the thread pool will be processing the request for that shared directory. Furthermore, when all threads are processing the request for that shared directory, all threads are blocked, and there are no spare threads to process requests for other shared directories, resulting in blocked access to all shared directories, directly affecting access to upper-layer applications.

[0043] In summary, the drawbacks of these technologies include: all shared exported metadata and data are globally and uniformly managed at the file system layer without physical or logical isolation; fsync flushing requests for a specific shared export can affect access to other shared exports. The current thread model uses global polling without isolating shared directories; when a request for a particular shared directory is blocked, all threads are processing requests for that shared directory, exacerbating the impact on access to other shared exported directories.

[0044] Based on the above, this application provides a method for managing shared directories under a distributed file system. It changes the original file system-wide management of metadata and data to a shared directory-based management approach. Simultaneously, it modifies the NFS thread model by adding a task queue between the NFS protocol and the file system. NFS submits tasks to the queue, the file system starts a new thread pool, and tasks are retrieved from the queue for execution. The file system internally determines the task scheduling method and priority, achieving thread scheduling isolation and preventing requests to a single shared directory from blocking other shared directories.

[0045] According to an embodiment of this application, a method for managing a shared directory under a distributed file system is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0046] This embodiment provides a method for managing shared directories under a distributed file system. This method is applied to the file system layer. Figure 2 is a flowchart of the method for managing shared directories under a distributed file system according to an embodiment of this application. As shown in Figure 2, the process includes the following steps:

[0047] This embodiment provides a method for managing shared directories under a distributed file system. This method is applied to the file system layer. Figure 2 is a flowchart of the method for managing shared directories under a distributed file system according to an embodiment of this application. As shown in Figure 2, the process includes the following steps:

[0048] Step S201: Obtain the shared directory created by the protocol layer and determine the partition identifier of the shared directory.

[0049] Specifically, this embodiment changes the original file system-wide management of metadata and data to a shared directory-based management approach. For example, the NFS protocol layer in Figure 3.

[0050] When the protocol layer creates a shared directory, it generates a unique partition identifier for each shared directory. For example, the partition ID in Figure 3. Shared directory A has a unique partition ID, and shared directories B and C also have unique partition IDs. Furthermore, the protocol layer permanently binds the partition identifier of the shared directory to the root INODE of the shared directory. The shared directories created by the NFS protocol layer are actually subdirectories created at the file system layer. A shared export actually points to a specific directory within the file system, and all shared directories belong to the same file system. In Figure 3, ROOT refers to the file system as a whole; ROOT is the root directory of the file system, and A, B, and C are subdirectories within the file system. The shared exports of the NFS protocol point to specific file system directories.

[0051] The file system layer obtains the shared directory created by the protocol layer and determines the partition identifier of the shared directory.

[0052] Step S202: Create a metadata management object for the shared directory based on the metadata of the shared directory, and bind the metadata management object to the partition identifier to obtain the first binding relationship. The metadata management object is used to manage the metadata of the shared directory.

[0053] Specifically, the file system layer creates a metadata management object for the shared directory based on its metadata. This metadata management object can be a global data structure such as a memory linked list or a Map. The file system layer creates and maintains a global metadata management object, which can be quickly located using its INODE number. Each shared directory has its own separate metadata management object, which manages the metadata of subdirectories and subfiles within that shared directory. The INODE object can also be quickly located using its INODE number.

[0054] The file system layer binds the metadata management object to the partition identifier in step S201 to obtain the first binding relationship. The first binding relationship can determine the metadata management object corresponding to the partition identifier, and also determine the partition identifier corresponding to the metadata management object.

[0055] In addition, the INODE metadata generated by accessing a shared directory is added to the memory linked list bound to the partition ID. This includes the addition, modification, and deletion of metadata when accessing a specific shared directory. The generated metadata belongs to this shared directory (pointing to a subdirectory of the file system). All metadata changes in this shared directory are recorded in the metadata management linked list or Map of this partition, which can be queried by the partition ID.

[0056] Step S203: Upon receiving a directory operation request sent by the protocol layer, determine the target shared directory corresponding to the directory operation request and the first target thread corresponding to the target shared directory. The directory operation request is obtained by the protocol layer after injecting the target partition identifier into the initial directory operation request.

[0057] Specifically, this embodiment modifies the NFS thread model by adding a task queue between the NFS protocol layer and the file system layer. When NFS submits a directory operation request, the file system layer starts a new thread pool to retrieve the directory operation request from the task queue. The file system layer then determines the request scheduling method and priority, and processes the directory operation request. Examples of directory operation requests include directory export requests and directory access requests.

[0058] After receiving the initial directory operation request sent by the client, the protocol layer determines the target partition identifier of the shared directory corresponding to the initial directory operation request, injects the target partition identifier into the initial directory operation request to obtain the directory operation request, and sends the directory operation request to the file system layer.

[0059] The file system layer determines the target shared directory corresponding to the directory operation request. For example, each directory operation request has a request context. The file system layer can obtain information such as the target partition identifier and the owned shared directory from this request context, and determine the target shared directory based on the information of the owned shared directory.

[0060] The file system layer determines the first target thread corresponding to the target shared directory. For example, the file system layer establishes a mapping relationship between the threads in the thread pool and the shared directory. The mapping relationship is a kind of thread scheduling method. It can bind a group of threads to each shared directory to avoid competition with other shared directories. That is, it binds a corresponding first target thread to each target shared directory. The first target thread only handles directory operation requests bound to the shared directory.

[0061] Step S204: Determine the target metadata management object based on the target partition identifier and the first binding relationship in the directory operation request, and process the directory operation request based on the first target thread and the target metadata management object.

[0062] Specifically, the file system layer resolves the request context in the directory operation request through function pointers, thereby obtaining the target partition identifier in the directory operation request. Based on the target partition identifier in the directory operation request and the first binding relationship, the target metadata management object is determined, that is, the metadata management object bound to the target shared directory.

[0063] The file system layer processes directory operation requests based on the first target thread and the target metadata management object. For example, when the NFS protocol layer initiates a directory export request for a shared directory, the file system layer determines the first target thread and the target metadata management object for the directory export request. It then uses the first target thread to flush metadata and data to each INODE on the target metadata management object. This process only occurs within the current shared directory and will not affect the request processing of other shared directories, nor will it flush metadata for other unrelated INODEs.

[0064] This embodiment provides a method for managing shared directories under a distributed file system. When creating a shared directory at the protocol layer, a partition identifier is created. At the file system layer, a metadata management object for the shared directory is created and bound to the partition identifier. A first target thread and a target metadata management object are determined for each directory operation request, and the directory operation request is processed based on these parameters. This method utilizes the metadata management object to manage metadata partitions in the shared directory, adds a file system thread pool, and sets a corresponding first target thread for each target shared directory. The first target thread only processes directory operation requests bound to the shared directory, achieving resource management and request access isolation between different shared directories. When a request to a certain shared directory is blocked, it will not affect access to other shared directories, improving the overall robustness and stability of the system. This solves the problem that when exporting or accessing a shared directory, a blocked request can cause all shared directories to be blocked, affecting upper-layer applications' access to the shared directory.

[0065] As an optional embodiment, processing directory operation requests based on a first target thread and a target metadata management object includes:

[0066] When the directory operation request is a directory export request, the first target thread is used to obtain the first file index node corresponding to the data in the target shared directory and the second file index node corresponding to the metadata in the target metadata management object.

[0067] Based on the first file index node, the data of the target shared directory is flushed to the backend storage, where the backend storage is determined according to the directory operation request;

[0068] Based on the second file index node, the metadata of the target shared directory is flushed to the backend storage.

[0069] Specifically, a directory operation request can be an fsync flush request for a specific shared export, i.e., a directory export request.

[0070] When the directory operation request is a directory export request, the first target thread retrieves the first file index node corresponding to the data and the second file index node corresponding to the metadata in the target shared directory from the target metadata management object. For example, if the directory export request needs to export shared directory A, and the target metadata management object for shared directory A is determined to be a memory linked list A, the first target thread for shared directory A begins traversing the memory linked list A, reading the first file index node corresponding to the data and the second file index node corresponding to the metadata from the memory linked list A. The first file index node corresponding to the data is, for example, the INODE of the subfile containing the data. The second file index node corresponding to the metadata is, for example, the INODE of the metadata.

[0071] The file system layer determines the backend storage based on the directory operation request. Based on the first file inode, the file system layer flushes the data of the target shared directory to the backend storage, and based on the second file inode, flushes the metadata of the target shared directory to the backend storage. This process only occurs within the current shared directory and does not affect request processing for other shared directories, nor does it flush other unrelated INODE metadata.

[0072] In this embodiment, the target directory data and metadata INODE are accurately obtained by matching the metadata management object through the first target thread, and then flushed to the backend storage respectively. This achieves data and metadata isolation between shared directories, does not interfere with the processing of requests to other shared directories, avoids redundant INODE flushing, and improves flushing efficiency and resource utilization.

[0073] As an optional embodiment, determining the target shared directory corresponding to the directory operation request and the first target thread corresponding to the target shared directory includes:

[0074] Parse the request context in the directory operation request to obtain the target shared directory;

[0075] Idle threads are obtained from the thread pool at the file system layer. A mapping relationship is established between the idle threads and the target shared directory. The idle threads are used as the first target threads. The mapping relationship is used to indicate that the idle threads are occupied by the target shared directory.

[0076] Specifically, each directory operation request has a request context. By resolving the context in the directory operation request using a function pointer, information such as the partition ID and the owned shared directory can be obtained. Based on the resolved owned shared directory, the target shared directory of the directory operation request can be determined.

[0077] As shown in Figure 4, a thread pool and a task queue are added to the file system layer. The threads in the thread pool are used to handle directory operation requests in the task queue.

[0078] Idle threads are obtained from the thread pool at the file system layer. A mapping relationship is established between the idle threads and the target shared directories. The idle threads are used as the first target threads. The mapping relationship can indicate that the idle threads are occupied by the target shared directories. In addition, the mapping relationship is a thread scheduling method that can bind a group of threads to each shared directory to avoid competition with other shared directories. That is, each target shared directory is bound to a corresponding first target thread. The first target thread only handles directory operation requests bound to the shared directory.

[0079] As an optional embodiment, before determining the target shared directory corresponding to the directory operation request and the first target thread corresponding to the target shared directory, the method further includes:

[0080] A task queue is created in the file system layer so that the file system layer can retrieve directory operation requests from the task queue according to a preset priority. The task queue is used to cache directory operation requests.

[0081] Create an asynchronous task submission interface, which is used to receive directory operation requests sent by the protocol layer and cache the directory operation requests in the task queue;

[0082] Create a thread pool in the file system layer and create a preset number of threads to put into the thread pool.

[0083] Specifically, this embodiment will be described with reference to Figure 4. This embodiment modifies the NFS thread model by adding a task queue between the NFS protocol layer and the file system layer. The NFS layer caches directory operation requests in the task queue. The file system layer starts a new thread pool, using threads in the thread pool to retrieve and process directory operation requests from the task queue. The file system layer internally determines the task scheduling method and priority, achieving thread scheduling isolation and preventing the blocking of requests to a single shared directory (e.g., fsync) from affecting other shared directories.

[0084] A task queue is created in the file system layer to cache directory operation requests. The file system layer can retrieve directory operation requests from the task queue according to preset priorities. Preset priorities include queuing I / O operations for the same shared directory and the same file for processing, achieving thread resource balancing in scenarios with a large number of concurrent file accesses; small I / O writes to the cache can be prioritized to reduce response latency, while large I / O operations that need to directly write to the backend can be delayed to ensure that bandwidth is not reduced. In addition, a high priority can be set for certain types of files, and requests for these types of files will be processed first. The file system has its own thread pool and a task queue, which allows for flexible scheduling, whereas previously tasks could only be processed synchronously according to NFS scheduling.

[0085] An asynchronous task submission interface is created at the file system layer. This interface receives directory operation requests from the protocol layer and caches these requests in the task queue. Furthermore, after the protocol layer asynchronously caches the directory operation request in the file system layer's task queue via the asynchronous task submission interface, it returns immediately. The protocol layer can then continue processing other tasks, such as submitting requests, returning to the client, or reclaiming resources.

[0086] A thread pool is created in the file system layer, and a preset number of threads are added to the pool. The file system layer handles requests using its own threads. The preset number of threads can be set according to the number of CPU cores in the operating system. When using the threads in the thread pool to handle directory operation requests, the shared directory to which the request belongs is first identified. A mapping relationship is established between the thread and the shared directory, and the thread is then partitioned and processed according to the shared directory.

[0087] In this embodiment, a task queue is used to cache directory operation requests, and these requests are processed according to preset priorities, which balances concurrent resources and optimizes request processing efficiency. An asynchronous interface is used to allow immediate return after the protocol layer submits, improving protocol layer processing efficiency. Thread pool partitioning ensures scheduling isolation, preventing single directory requests from blocking and affecting other directories, thus improving overall processing performance.

[0088] As an optional embodiment, after processing the directory operation request based on the first target thread and the target metadata management object, the method further includes:

[0089] Generate request callback information, which indicates that the directory operation request has been processed.

[0090] Call the request callback interface of the protocol layer, and send the request callback information to the protocol layer through the request callback interface.

[0091] Specifically, this embodiment enables the protocol layer to asynchronously cache directory operation requests in the task queue of the file system layer and then return. However, if the directory operation request is not fully processed, a request callback interface needs to be added. After the file system layer finishes processing the directory operation request, the request callback interface is called to continue subsequent processing.

[0092] Add a request callback interface to the NFS protocol layer. After the file system layer processes the request, it generates request callback information and uses this information to notify the protocol layer that the directory operation request has been processed. The file system layer then calls the protocol layer's request callback interface to send the request callback information to the protocol layer, which then handles the request return to the client and resource reclamation.

[0093] This embodiment provides a method for managing shared directories under a distributed file system. This method is applied at the protocol layer. Figure 5 is a flowchart of the method for managing shared directories under a distributed file system according to an embodiment of this application. As shown in Figure 5, the process includes the following steps:

[0094] Step S501: Create a shared directory in the file system layer and determine the partition identifier of the shared directory so that the file system layer binds the partition identifier to the metadata management object of the shared directory to obtain the first binding relationship. The metadata management object is created by the file system layer based on the metadata of the shared directory and is used to manage the metadata of the shared directory.

[0095] Specifically, when the protocol layer creates a shared directory, it generates a unique partition identifier for each shared directory. For example, the partition ID in Figure 3; shared directory A has a unique partition ID, and shared directories B and C also have unique partition IDs. Furthermore, the protocol layer permanently binds the partition identifier of the shared directory to the root INODE of the shared directory. The shared directories created by the NFS protocol layer are actually subdirectories created at the file system layer. A shared export actually points to a specific directory within the file system, and all shared directories belong to the same file system. In Figure 3, ROOT refers to the file system as a whole; ROOT is the root directory of the file system, and A, B, and C are subdirectories within the file system. The shared exports of the NFS protocol point to specific file system directories.

[0096] The file system layer obtains the shared directory created by the protocol layer and determines the partition identifier of the shared directory.

[0097] The NFS layer maintains shared directory information, with each shared directory pointing to a specific subdirectory within the file system layer. When creating a shared directory, the NFS layer also needs to maintain the attributes of each shared directory, such as its root INODE and name. File system metadata management has been changed from a global map to management at the shared directory level. This is equivalent to changing the original global metadata to partition management. Each shared directory's corresponding subdirectory and its internal metadata belong to a specific partition. Each partition has its own partition ID, which is stored in the root INODE of the shared directory. When processing a request, this ID is retrieved and placed into the request context. When the file system layer processes a request, it retrieves the ID from the request context to find the corresponding map information. The request context is a memory object associated with a function pointer, which the file system layer passes as a parameter when processing requests. The function pointer allows the access to internal information such as the ID.

[0098] Step S502: Upon receiving an initial directory operation request from the client, determine the target partition identifier corresponding to the initial directory operation request.

[0099] Specifically, after receiving the initial directory operation request sent by the client, the protocol layer determines the target partition identifier of the shared directory corresponding to the initial directory operation request, injects the target partition identifier into the initial directory operation request to obtain the directory operation request, and sends the directory operation request to the file system layer.

[0100] The file system layer determines the target shared directory corresponding to the directory operation request. For example, each directory operation request has a request context. The file system layer can obtain information such as the target partition identifier and the owned shared directory from this request context, and determine the target shared directory based on the information of the owned shared directory.

[0101] The file system layer determines the first target thread corresponding to the target shared directory. For example, the file system layer establishes a mapping relationship between the threads in the thread pool and the shared directory. The mapping relationship is a kind of thread scheduling method. It can bind a group of threads to each shared directory to avoid competition with other shared directories. That is, it binds a corresponding first target thread to each target shared directory. The first target thread only handles directory operation requests bound to the shared directory.

[0102] Step S503: Inject the target partition identifier into the initial directory operation request to obtain the directory operation request, and send the directory operation request to the file system layer. The file system layer is used to determine the target shared directory corresponding to the directory operation request and the first target thread corresponding to the target shared directory, determine the target metadata management object according to the target partition identifier and the first binding relationship, and process the directory operation request according to the first target thread and the target metadata management object.

[0103] Specifically, the file system layer resolves the request context in the directory operation request through function pointers, thereby obtaining the target partition identifier in the directory operation request. Based on the target partition identifier in the directory operation request and the first binding relationship, the target metadata management object is determined, that is, the metadata management object bound to the target shared directory.

[0104] The file system layer processes directory operation requests based on the first target thread and the target metadata management object. For example, when the NFS protocol layer initiates a directory export request for a shared directory, the file system layer determines the first target thread and the target metadata management object for the directory export request. It then uses the first target thread to flush metadata and data to each INODE on the target metadata management object. This process only occurs within the current shared directory and will not affect the request processing of other shared directories, nor will it flush metadata for other unrelated INODEs.

[0105] This embodiment provides a method for managing shared directories under a distributed file system. When creating a shared directory at the protocol layer, a partition identifier is created. At the file system layer, a metadata management object for the shared directory is created and bound to the partition identifier. A first target thread and a target metadata management object are determined for each directory operation request, and the directory operation request is processed based on these parameters. This method utilizes the metadata management object to manage metadata partitions in the shared directory, adds a file system thread pool, and sets a corresponding first target thread for each target shared directory. The first target thread only processes directory operation requests bound to the shared directory, achieving resource management and request access isolation between different shared directories. When a request to a certain shared directory is blocked, it will not affect access to other shared directories, improving the overall robustness and stability of the system. This solves the problem that when exporting or accessing a shared directory, a blocked request can cause all shared directories to be blocked, affecting upper-layer applications' access to the shared directory.

[0106] As an optional embodiment, sending the directory operation request to the file system layer includes:

[0107] The second target thread is determined from the idle threads included in the protocol layer;

[0108] By utilizing the second target thread and the asynchronous task submission interface of the file system layer, directory operation requests are cached in the task queue of the file system layer;

[0109] Release the second target thread.

[0110] Specifically, an asynchronous task submission interface is created at the file system layer. This interface receives directory operation requests from the protocol layer and caches them in the task queue. Furthermore, after the protocol layer asynchronously caches the directory operation request in the file system layer's task queue via the asynchronous task submission interface, it returns immediately, allowing the protocol layer to continue processing other tasks, such as submitting requests, returning to the client, or reclaiming resources.

[0111] The protocol layer identifies an idle thread from among the included idle threads as the second target thread, and uses the second target thread to call the asynchronous task submission interface of the file system layer to cache the directory operation request to the task queue of the file system layer.

[0112] After caching the directory operation request to the task queue, the second target thread does not need to wait for the file system layer to process the directory operation request and returns directly. The protocol layer releases the second target thread, which can then be used to process other tasks, such as submitting requests, returning to the client, or recycling resources.

[0113] As an optional embodiment, determining the target partition identifier corresponding to the initial directory operation request includes:

[0114] Retrieve the shared directory to be operated on corresponding to the initial directory operation request;

[0115] Obtain the root file index node of the shared directory to be operated on. Based on the root file index node and the second binding relationship, obtain the target partition identifier. The second binding relationship is obtained by binding the partition identifier with the root file index node of the shared directory.

[0116] Specifically, after receiving the initial directory operation request sent by the client, the protocol layer can obtain information such as the owned shared directory by parsing the context in the initial directory operation request through function pointers. Based on the parsed owned shared directory, the shared directory to be operated corresponding to the initial directory operation request can be determined.

[0117] After creating the shared directory, the protocol layer permanently binds the partition identifier of the shared directory to the root file inode of the shared directory, thus obtaining a second binding relationship. The protocol layer obtains the root file inode of the shared directory to be operated on, and retrieves the target partition identifier from the root file inode based on the second binding relationship. The target partition identifier is injected into the request context of the initial directory operation request to obtain the directory operation request, ensuring that the partition ID can be accessed when calling the file system interface.

[0118] In this embodiment, the shared directory to be operated on is obtained by parsing the initial request. By combining the relationship between the root file inode and the pre-bound partition identifier, the target partition can be accurately located. Injecting the partition identifier into the request context ensures the accuracy of the partition ID accessed by the file system interface, improving the efficiency and reliability of partition determination.

[0119] As an optional embodiment, the method further includes:

[0120] Create a request callback interface;

[0121] Upon receiving request callback information through the request callback interface, a request completion response is generated and sent to the client. The request callback information indicates that the directory operation request processing is complete.

[0122] Determine the resources used by the directory operation request and reclaim the resources used by the directory operation request.

[0123] Specifically, this embodiment uses an asynchronous task submission interface to allow the protocol layer to asynchronously cache directory operation requests in the file system layer's task queue and then return. However, since the directory operation requests are not yet fully processed, a request callback interface needs to be added. This callback interface is invoked after the file system layer has finished processing the directory operation request to continue subsequent processing. Therefore, a request callback interface is added to the NFS protocol layer.

[0124] After the file system layer processes the request, it generates a request callback message and uses this message to notify the protocol layer that the directory operation request has been completed. The file system layer then calls the protocol layer's request callback interface to send the request callback message to the protocol layer.

[0125] Upon receiving request callback information through the request callback interface, the protocol layer generates a request completion response and sends it to the client. The request callback information indicates that the directory operation request has been processed. The protocol layer also determines the resources used by the directory operation request and reclaims those resources.

[0126] As an optional embodiment, the specific process of the above step "when receiving request callback information through the request callback interface, generating a request completion response and sending the request completion response to the client; determining the resources occupied by the directory operation request and reclaiming the resources occupied by the directory operation request" may include steps A1 to A8.

[0127] Step A1: The protocol layer receives the request callback information and performs a validity check.

[0128] Specifically, the protocol layer queries the request context cached locally in the NFS protocol layer based on the request ID in the request callback information. This context includes client information, protocol header data, and resource allocation records saved when the request was submitted. The validity of all resource handles in the request callback information is verified based on the request context to determine if they are legitimate resources allocated for the current request.

[0129] Step A2: The protocol layer generates a request completion response and sends it to the client.

[0130] Specifically, based on the processing result carried in the request callback information, a response message is constructed according to the NFS protocol specification. For example, if the processing result is successful, the response message carries the processing result data, such as the content of the file read and the attributes of the created file; if the processing result is unsuccessful, the response message carries the standard error code (such as insufficient permissions or file not found) and descriptive information. The response message is then sent to the client.

[0131] Step A3: The protocol layer releases the temporary protocol buffer.

[0132] Specifically, after the response message is sent, the temporary protocol buffers allocated for the directory operation request are released, such as the input buffer and the output buffer. The input buffer is the protocol header cache or parameter cache used by the user when parsing the NFS request, and the output buffer is the cache used when creating the response message.

[0133] Step A4: Clean up the shared directory mapping relationship at the protocol layer.

[0134] Specifically, if the protocol layer thread no longer handles requests for the shared directory, it deletes the corresponding entry in the mapping table and releases the temporary resources associated with the mapping (such as directory permission cache, partition lock, and directory attribute cache). If the thread still needs to handle other requests for the shared directory: the mapping relationship is retained, and only the temporary cache of directory attributes corresponding to the current request is cleared.

[0135] Step A5: The protocol layer thoroughly cleans up the request context.

[0136] Specifically, the protocol layer deletes the locally cached request context, including client IP:port, request type, protocol version, resource allocation records, etc. It releases context-associated memory structures, such as hash table entries, linked list nodes, and protocol header copies. All temporary state data associated with the request is cleared.

[0137] Step A6: The protocol layer releases the handle resources.

[0138] Specifically, the protocol layer initiates a separate handle recycling thread, which periodically scans for handles to be recycled. It determines whether a handle exists without client connections based on the client session state, and if the handle has no unprocessed callbacks or retry requests associated with it, it is designated as a handle to be recycled. The kernel-mode interface is then invoked to destroy the handle structure of the handle to be recycled, reclaiming the kernel resources occupied by the handle.

[0139] Step A7: The protocol layer cleans up the resources associated with the thread pool.

[0140] Specifically, if the protocol layer thread occupies temporary resources of the thread pool, such as request data in thread-local storage or task queue nodes, when processing directory operation requests,

[0141] The protocol layer clears all data related to the directory operation request, such as resource manifest copies and callback status flags. It releases the node corresponding to the request from the task queue, resets the thread's status flags, and ensures the thread can be reused to handle other requests.

[0142] Step A8: The protocol layer reclaims resources for abnormal scenarios.

[0143] Specifically, if the request callback information carries processing failure information, the protocol layer forcibly releases resources such as buffers and handles to avoid resource leaks. An exception reclamation log (including the Request ID, the reason for the exception, and the type of resource reclaimed) is recorded to facilitate troubleshooting.

[0144] In this embodiment, based on callback triggering, after legality verification, the buffer is released in layers, the handle count is updated, and the mapping and context are cleaned up. Combined with delayed recycling, abnormal forced release and monitoring, resource leakage can be prevented, handle reuse can be promoted, the stable and efficient operation of the NFS protocol layer can be guaranteed, and the risk of failure can be reduced.

[0145] This embodiment also provides a management device for a shared directory under a distributed file system. This device is used to implement the above embodiments and preferred embodiments, and details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0146] This embodiment provides a management device for shared directories under a distributed file system. This device is deployed at the file system layer, as shown in Figure 6, and includes:

[0147] The first information determination module 601 is used to obtain the shared directory created by the protocol layer and determine the partition identifier of the shared directory;

[0148] Binding module 602 is used to create a metadata management object for the shared directory based on the metadata of the shared directory, and bind the metadata management object to the partition identifier to obtain the first binding relationship. The metadata management object is used to manage the metadata of the shared directory.

[0149] The second information determination module 603 is used to determine the target shared directory corresponding to the directory operation request and the first target thread corresponding to the target shared directory when a directory operation request is received from the protocol layer. The directory operation request is obtained by the protocol layer after injecting the target partition identifier into the initial directory operation request.

[0150] The request processing module 604 is used to determine the target metadata management object based on the target partition identifier and the first binding relationship in the directory operation request, and to process the directory operation request based on the first target thread and the target metadata management object.

[0151] As an optional embodiment, the request processing module 604 includes:

[0152] The acquisition unit is used to, when the directory operation request is a directory export request, use the first target thread to acquire the first file index node corresponding to the data in the target shared directory and the second file index node corresponding to the metadata in the target metadata management object;

[0153] The first data writing unit is used to write the data of the target shared directory to the backend storage according to the first file index node, wherein the backend storage is determined according to the directory operation request;

[0154] The second data flushing unit is used to flush the metadata of the target shared directory to the backend storage based on the second file index node.

[0155] As an optional embodiment, the second information determination module 603 includes:

[0156] The parsing unit is used to parse the request context in a directory operation request to obtain the target shared directory;

[0157] The establishment unit is used to obtain idle threads from the thread pool of the file system layer, establish a mapping relationship between idle threads and target shared directories, and use the idle threads as the first target threads. The mapping relationship is used to indicate that the idle threads are occupied by the target shared directory.

[0158] As an optional embodiment, the device further includes:

[0159] The first creation module is used to create a task queue in the file system layer so that the file system layer can extract directory operation requests from the task queue according to a preset priority. The task queue is used to cache directory operation requests.

[0160] The second creation module is used to create an asynchronous task submission interface. The asynchronous task submission interface is used to receive directory operation requests sent by the protocol layer and cache the directory operation requests in the task queue.

[0161] The third creation module is used to create a thread pool in the file system layer and create a preset number of threads to put into the thread pool.

[0162] As an optional embodiment, the device further includes:

[0163] The generation module is used to generate request callback information, which indicates that the directory operation request processing is complete.

[0164] The calling module is used to call the request callback interface of the protocol layer and send the request callback information to the protocol layer through the request callback interface.

[0165] This embodiment provides a management device for shared directories under a distributed file system. This device is deployed at the protocol layer, as shown in Figure 7, and includes:

[0166] The directory creation module 701 is used to create a shared directory in the file system layer and determine the partition identifier of the shared directory so that the file system layer binds the partition identifier to the metadata management object of the shared directory to obtain the first binding relationship. The metadata management object is created by the file system layer based on the metadata of the shared directory and is used to manage the metadata of the shared directory.

[0167] The third information determination module 702 is used to determine the target partition identifier corresponding to the initial directory operation request when receiving the initial directory operation request sent by the client.

[0168] The request sending module 703 is used to inject the target partition identifier into the initial directory operation request to obtain the directory operation request, and send the directory operation request to the file system layer. The file system layer is used to determine the target shared directory corresponding to the directory operation request and the first target thread corresponding to the target shared directory, determine the target metadata management object according to the target partition identifier and the first binding relationship, and process the directory operation request according to the first target thread and the target metadata management object.

[0169] As an optional embodiment, the request sending module 703 includes:

[0170] A determining unit is used to determine the second target thread among the idle threads contained in the protocol layer;

[0171] The caching unit is used to cache directory operation requests to the task queue of the file system layer by utilizing the second target thread and the asynchronous task submission interface of the file system layer;

[0172] The release unit is used to release the second target thread.

[0173] As an optional embodiment, the third information determination module 702 includes:

[0174] The acquisition unit is used to acquire the shared directory to be operated on corresponding to the initial directory operation request.

[0175] The acquisition unit is used to acquire the root file index node of the shared directory to be operated on, and obtain the target partition identifier based on the root file index node and the second binding relationship. The second binding relationship is obtained by binding the partition identifier with the root file index node of the shared directory.

[0176] As an optional embodiment, the device further includes:

[0177] Create a module for creating request callback interfaces;

[0178] The generation module is used to generate a request completion response and send it to the client when a request callback information is received through the request callback interface. The request callback information indicates that the directory operation request processing is complete.

[0179] The resource reclamation module is used to determine the resources occupied by directory operation requests and to reclaim the resources occupied by directory operation requests.

[0180] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0181] In this embodiment, the management device for the shared directory under the distributed file system is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0182] Figure 8 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0183] Referring specifically to Figure 8, a schematic diagram of a suitable electronic device for implementing embodiments of the present invention is shown below. The electronic device may include a processor (e.g., a central processing unit, a graphics processing unit, etc.) 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from memory 808 into random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the electronic device. The processor 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0184] Typically, the following devices can be connected to I / O interface 805: input devices 806 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 807 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 808 including, for example, magnetic tapes, hard disks, etc.; and communication devices 809. Communication device 809 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although FIG8 shows an electronic device with various devices, it should be understood that it is not required to implement or have all the devices shown, and more or fewer devices may be implemented or have alternatively.

[0185] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 809, or installed from a memory 808, or installed from a ROM 802. When the computer program is executed by the processor 801, it performs the functions defined in the method for managing a shared directory under a distributed file system according to embodiments of the present invention.

[0186] The electronic device shown in Figure 8 is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0187] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the method for managing a shared directory under a distributed file system shown in the above embodiments is implemented.

[0188] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0189] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A method for managing shared directories under a distributed file system, characterized in that, The method is applied to the file system layer and includes: obtaining a shared directory created by the protocol layer and determining the partition identifier of the shared directory; creating a metadata management object for the shared directory based on its metadata and binding the metadata management object to the partition identifier to obtain a first binding relationship, wherein the metadata management object is used to manage the metadata of the shared directory; creating a task queue in the file system layer so that the file system layer extracts directory operation requests from the task queue according to a preset priority, wherein the task queue is used to cache the directory operation requests; creating an asynchronous task submission interface, wherein the asynchronous task submission interface is used to receive the directory operation requests sent by the protocol layer and cache the directory operation requests in the task queue; creating a thread pool in the file system layer and creating a preset number of threads and placing them in the thread pool; and receiving a directory operation request sent by the protocol layer. In the case of a directory operation request, the target shared directory and the first target thread corresponding to the target shared directory are determined, wherein the directory operation request is obtained after the protocol layer injects the target partition identifier into the initial directory operation request; determining the target shared directory and the first target thread corresponding to the directory operation request includes: parsing the request context in the directory operation request to obtain the target shared directory; obtaining an idle thread from the thread pool of the file system layer, establishing a mapping relationship between the idle thread and the target shared directory, and using the idle thread as the first target thread, wherein the mapping relationship is used to indicate that the idle thread is occupied by the target shared directory; determining the target metadata management object according to the target partition identifier in the directory operation request and the first binding relationship, and processing the directory operation request according to the first target thread and the target metadata management object.

2. The method according to claim 1, characterized in that, The step of processing the directory operation request according to the first target thread and the target metadata management object includes: when the directory operation request is a directory export request, using the first target thread to obtain the first file index node corresponding to the data in the target shared directory and the second file index node corresponding to the metadata in the target metadata management object; according to the first file index node, flushing the data of the target shared directory to the backend storage, wherein the backend storage is determined according to the directory operation request; and according to the second file index node, flushing the metadata of the target shared directory to the backend storage.

3. The method according to claim 1, characterized in that, After processing the directory operation request according to the first target thread and the target metadata management object, the method further includes: generating request callback information, wherein the request callback information indicates that the directory operation request processing is complete; and calling the request callback interface of the protocol layer to send the request callback information to the protocol layer through the request callback interface.

4. A method for managing shared directories under a distributed file system, characterized in that, The method is applied at the protocol layer and includes: creating a shared directory in a file system layer and determining a partition identifier of the shared directory, such that the file system layer binds the partition identifier to a metadata management object of the shared directory to obtain a first binding relationship, wherein the metadata management object is created by the file system layer based on the metadata of the shared directory and is used to manage the metadata of the shared directory; upon receiving an initial directory operation request sent by a client, determining a target partition identifier corresponding to the initial directory operation request; injecting the target partition identifier into the initial directory operation request to obtain a directory operation request, and sending the directory operation request to the file system layer, wherein the file system layer is used to create a task queue, such that the file system layer extracts directory operation requests from the task queue according to a preset priority, wherein the task queue is used to cache the directory operation requests; and creating an asynchronous task submission interface, wherein the asynchronous task submission interface... The file system layer is used to receive the directory operation request sent by the protocol layer and cache the directory operation request in the task queue; create a thread pool in the file system layer and create a preset number of threads and put them into the thread pool; the file system layer is used to determine the target shared directory corresponding to the directory operation request and the first target thread corresponding to the target shared directory, determine the target metadata management object according to the target partition identifier and the first binding relationship, and process the directory operation request according to the first target thread and the target metadata management object; the file system layer determines the target shared directory corresponding to the directory operation request and the first target thread corresponding to the target shared directory by: parsing the request context in the directory operation request to obtain the target shared directory; obtaining an idle thread in the thread pool of the file system layer, establishing a mapping relationship between the idle thread and the target shared directory, and using the idle thread as the first target thread, wherein the mapping relationship is used to indicate that the idle thread is occupied by the target shared directory.

5. The method according to claim 4, characterized in that, Sending the directory operation request to the file system layer includes: determining a second target thread among the idle threads included in the protocol layer; using the second target thread and the asynchronous task submission interface of the file system layer to cache the directory operation request to the task queue of the file system layer; and releasing the second target thread.

6. The method according to claim 4, characterized in that, Determining the target partition identifier corresponding to the initial directory operation request includes: obtaining the shared directory to be operated corresponding to the initial directory operation request; obtaining the root file index node of the shared directory to be operated, and obtaining the target partition identifier based on the root file index node and the second binding relationship, wherein the second binding relationship is obtained by binding the partition identifier with the root file index node of the shared directory.

7. The method according to claim 4, characterized in that, The method further includes: creating a request callback interface; upon receiving request callback information through the request callback interface, generating a request completion response and sending the request completion response to the client, wherein the request callback information indicates that the directory operation request processing is complete; determining the resources occupied by the directory operation request and reclaiming the resources occupied by the directory operation request.

8. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the method for managing a shared directory under a distributed file system as described in any one of claims 1 to 7.

Images