Unified protocol based file system kernel service and high concurrency scheduling method

Abstract

This invention relates to the field of computer file system technology, and in particular to a file system kernel service and high-concurrency scheduling method based on a unified protocol. The method includes the following steps: Step 1: Starting a receiving thread and a file operation thread on the server side, the file operation thread including a lightweight thread and a heavyweight thread; Step 2: Listening to the network port through the receiving thread to receive JSON-formatted requests sent by clients, the requests containing timestamps and operation types; operation types include copy, move, create directory, delete, list, and restore; Step 3: Storing the received requests in a receiving queue; Step 4: Retrieving requests from the receiving queue and distributing them according to the operation type; Step 5: Executing the operation; This invention exposes file operation capabilities through independent processes and a unified JSON protocol. The six types of operation semantics, as well as the semantics of abort and recoverable deletion, are all uniformly defined at the protocol layer. The dual-type threads and request queue improve throughput and stability under multiple clients and large-scale tasks.

Description

Technical Field

[0001] This invention relates to the field of computer file system technology, specifically to a file system kernel service based on a unified protocol and a high-concurrency scheduling method. Background Technology

[0002] In scenarios such as data centers, edge computing, big data analytics, and log and file auditing, there is a need to perform batch operations such as copying, moving, listing, deleting, and restoring massive amounts of files. The industry currently faces the following pain points:

[0003] Firstly, there is a lack of protocol-first approach and semantic abstraction. Modern distributed and edge file systems emphasize protocol semantics as the core, defining operational contracts before implementation. However, the underlying system calls of different operating systems and hardware are inconsistent (such as Windows' ReadFile and Linux's sys_read), and the path and permission models are different. The application layer often relies on the APIs of each platform or barely unifies them through conditional compilation. There is a lack of protocol-based interfaces that are "based on semantic verbs" and decoupled from implementation.

[0004] Secondly, the need for recoverable deletion and compliance is urgent. International standards such as ISO / IEC 27555 are establishing data deletion governance standards. Enterprise-level tombstoning, recoverable deletion, and operation auditing (who performed what operation on which file, when, and what) have become rigid requirements. However, the behavior of the system's built-in recycle bin is inconsistent with the APIs of various languages, and there is a lack of recoverable deletion semantics and metadata records that are integrated with file operation protocols.

[0005] Third, insufficient high concurrency and observability—cloud-native and edge scenarios require services to be lightweight and not dependent on heavy RPC / DFS components; remote large file copying is prone to instability, and WebDAV and other services have memory and single query limitations when enumerating a large number of files; time-consuming operations lack unified, programmable progress feedback and abort capability. The system's native interface does not perform layered scheduling for multi-task concurrency, task queues, and load types (lightweight / heavyweight); high concurrency can easily cause handle and scheduling problems, and time-consuming operations lack real-time progress feedback and abort capability, making it difficult to meet the throughput and observability requirements of large-scale file operations.

[0006] The file capabilities provided by mainstream operating systems such as Windows and Linux are mainly bound to local APIs and shell commands. If the application layer wants to perform programmable, observable, and recoverable control over the file system, it can only rely directly on the above interfaces. Therefore, mainstream operating systems such as Windows and Linux need to provide a file system kernel service and a high-concurrency scheduling method at the application layer that is decoupled from the system API and has unified protocol semantics and recoverable deletion semantics as its core. Summary of the Invention

[0007] The purpose of this invention is to provide a file system kernel service and a high-concurrency scheduling method based on a unified protocol. It provides a programmable file system kernel service at the application layer, independent of specific operating system APIs. Through a unified protocol layer, it standardizes six types of operation semantics and recoverable deletion semantics, enabling any client to complete operations such as copying, moving, enumerating, deleting, and restoring using only the same protocol. It also features observable progress, the ability to abort, and rollback capabilities in case of a single failure. It employs dual-type threads (lightweight / heavyweight) and request queues to schedule multiple clients and multiple tasks; and improves throughput and stability under multi-tasking conditions through task classification and concurrency limit control.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a file system kernel service and high-concurrency scheduling method based on a unified protocol, comprising the following steps:

[0009] Step 1: Start the accept thread and file operation thread on the server side. The file operation thread includes a lightweight thread and a heavyweight thread.

[0010] Step 2: Listen on the network port using the receiving thread to receive JSON format requests sent by the client. The requests include timestamps and operation types. Operation types include copy, move, create directory, delete, list, and restore.

[0011] Step 3: Store the received requests in the receiving queue. When the receiving queue reaches the preset limit, return a response to the client indicating that the queue is full.

[0012] Step 4: Retrieve requests from the receiving queue and distribute them according to the operation type. Send directory creation, deletion, list creation, and restoration to the lightweight thread queue, and send copying and moving to the heavyweight thread queue.

[0013] Step 5: When performing a copy or move operation, push progress information to the client and detect abort requests. If an abort request is detected, stop immediately. When deleting, rename the file in its original location and record metadata to a dedicated directory. When listing, if the parameter is a recycle bin identifier, return the metadata list. When restoring, move the file back to its original path based on the metadata.

[0014] Preferably, when the operation type is deletion, a recoverable deletion process is executed, specifically: the file to be deleted is renamed to a file with a hidden tag in its original location, and a metadata file is created in the dedicated recycle bin directory to record the original path, the marked path, and the deletion time; during recovery, the metadata file in the dedicated recycle bin directory is enumerated, parsed, and the entry information containing metadata identifier, original file name, file type, and file size is returned; when performing a normal directory listing, files with internal tags containing preset suffixes are automatically filtered out.

[0015] Preferably, when the operation type is a copy operation or a move operation, specifically, during the execution process, progress information including the completion percentage and transmission speed is pushed to the client at preset time intervals, and the client can respond to the stop operation request sent by the client to stop the currently executing task; after the copy is completed, the client can list the target directory again to verify the result and update the interface; after the move is completed, the client can list the new location and the original location again to achieve a visual update of "the file has moved to the new location and the original location is gone".

[0016] Preferably, the copy operation adopts the method of first writing a temporary file and then renaming it to a formal file after completion. If a single item fails, it will automatically roll back, delete the target that has been written or the recovery source, and ensure data consistency.

[0017] Preferably, when the operation type is a recovery operation, the metadata identifier in the request message is parsed, the corresponding marker file is moved back to the original path according to the original path recorded in the metadata file, the hidden marker is cleared, and the metadata file is deleted.

[0018] Preferably, when the operation type is a list operation, it specifically means returning a list of logical drives, a list of files in a specified directory, or a list of recoverable deleted items in a dedicated recycle bin directory based on the request parameters.

[0019] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0020] 1. This invention exposes file operation capabilities through independent processes and a unified JSON protocol. The six types of operation semantics, as well as abort termination and recoverable deletion semantics, are all uniformly defined at the protocol layer. Any client only needs to send a request through Socket to complete copying, moving, listing, deleting, and restoring, without directly relying on the different system APIs and shells of each platform. This effectively addresses the industry challenge of "difficulty in establishing a unified cross-platform file operation interface." Mainstream systems such as Windows and Linux did not previously provide this type of file system kernel service with semantics as the core and decoupled from APIs at the application layer.

[0021] 2. This invention first obtains the source or target status through a list, then sends copy / move / rm commands, receives progress information during the operation and can stop it, and finally verifies the results through a list and updates the interface after the operation. This closed loop is uniformly implemented within the protocol, facilitating the upper layer to achieve visualization and automation of "see first, then act, then see again".

[0022] 3. This invention improves throughput and stability for multi-client, large-batch tasks by using dual-type thread pools (lightweight / heavyweight) and request queues; it provides progress information (sequence number, percentage, speed) for long-term operations and supports abort, alleviating the pain points of instability, lack of breakpoints and progress visibility in remote large file operations; it automatically rolls back when a single item fails to ensure data consistency, and does not rely on heavy system components such as RPC / DFS, making deployment and maintenance lighter.

[0023] 4. The deletion operation of this invention is "renaming and adding metadata records, not direct permanent deletion" at the protocol layer. When listdata=recycle, recoverable items can be listed, and recover can be restored to the original path by meta. It is decoupled from the system's built-in recycle bin, meets the enterprise-level requirements for accidental deletion recovery and secure deletion, and the metadata and operation flow in the protocol can be naturally extended to operation logs and auditing. Attached Figure Description

[0024] Figure 1 This is an architectural diagram of the present invention;

[0025] Figure 2 This is a flowchart of the method in this invention;

[0026] Figure 3 This is a timing diagram for the high-concurrency scheduling in this invention;

[0027] Figure 4 This is a flowchart of the dual-thread scheduling process in this invention;

[0028] Figure 5 This is a flowchart of the copying operation in this invention;

[0029] Figure 6 This is a flowchart of the movement operation in this invention;

[0030] Figure 7 This is a flowchart of the recoverable deletion operation in this invention;

[0031] Figure 8 This is an optional transaction and crash recovery extension architecture diagram in this invention. Detailed Implementation

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

[0033] The core of this invention lies in adopting a protocol-first and semantic abstraction design philosophy. Centered on unified protocol semantics and recoverable deletion semantics, it provides a programmable file system kernel service at the application layer that is independent of specific operating system APIs. All file operations are expressed through the same set of JSON protocols as six types of operation verbs (copy / move / mkdir / rm / list / recover). Moreover, "deletion" is defined at the protocol layer as recoverable semantics with metadata records (lightweight tombstoning). This forms a "semantics-centric" file system capability that can be reused across clients and scenarios, which aligns with industry needs in terms of protocol-first, recoverable deletion compliance, edge / lightweight deployment, and observability.

[0034] Example 1

[0035] Please see Figure 1 The diagram below illustrates the architecture of this invention, which adopts a "file system kernel service + unified protocol" approach: a kernel service process, independent of the operating system GUI and shell, is deployed on the target host. This process receives requests from any client via a TCP listening port (default 10080). Both requests and responses are in JSON format, with each message ending with a newline character. Clients can be local or remote scripts, desktop applications, or data analysis pipelines. File operations can be completed by sending requests conforming to the protocol via Socket, thus decoupling from the native APIs of mainstream operating systems.

[0036] Please see Figures 2-8 The file system kernel service and high-concurrency scheduling method based on a unified protocol includes the following steps:

[0037] Step 1: Start the accept thread and file operation thread on the server side. The file operation thread includes a lightweight thread and a heavyweight thread.

[0038] The AcceptThread is responsible for accepting client connections and pushing the socket into the receive queue (recvQueue); the file operation thread (FsHandler) is divided into two types: light and heavy.

[0039] Step 2: Listen on the network port using the receiving thread to receive JSON format requests sent by the client. The requests include timestamps and operation types. Operation types include copy, move, create directory, delete, list, and restore.

[0040] The request body contains the required fields timestamp (uint64, Unix 64-bit unsigned millisecond timestamp, used for request identification and association) and op (operation type, with values ​​of copy / move / mkdir / rm / list / recover and abort, all in lowercase).

[0041] During long-running operations (copy / move), the client can send an abort request to stop the current operation. `copy / move` uses a list array, where each item contains `src` (absolute path of the source file) and `dst` (absolute path of the target directory). Before execution, the existence of the source file, the validity of the target directory, and the remaining space on the target volume are verified. If insufficient, the operation is rejected and the required and available space information is returned. `mkdir`, `rm`, and `recover` use the `data` field to pass the directory path or the `meta` (metadata filename) identifier of the recycle bin entry. When `data` in the list is empty, logical drives are listed; when it is a directory path, files and subdirectories within that directory are listed, returning `name` (filename or directory name), `type` (0 for file; 1 for directory), and `size` (file size). When `data` is "recycle", recoverable deleted items are listed and an entry is returned, containing `meta` (metadata filename), `name`, `type`, and `size`. The `meta` is used by `recover` later.

[0042] The response body contains a response object: status: -1 indicates failure, 0 indicates processing, and 1 indicates success; reason indicates a status description or error description. For long-running operations (copy / move), the response may optionally include a progress object, including total (total number of files), current (current file number), name (current file name), percentage (percentage completed), and speed (transfer speed), used for long-running task progress and cancellation capabilities; the response also echoes the complete request to facilitate client association of requests and responses.

[0043] The following is a specific message format example of the Unified JSON protocol. All requests and responses are in JSON format, sent via TCP Socket, and each message ends with a newline character (\n).

[0044] Example 1, Copy request (op="copy");

[0045] {

[0046] "timestamp": 1741590000000,

[0047] "op":"copy",

[0048] "list":[

[0049] {

[0050] "src": "D: / My Movies / MovieA.mkv",

[0051] "dst": "E: / Movie Backup"

[0052] },

[0053] {

[0054] "src":"D: / My Movies / MovieB.mkv",

[0055] "dst":"E: / Movie Backup"

[0056] } ]

[0058] }

[0059] The protocol uses forward slashes ( / ) for all paths, and the server performs path standardization internally. Before execution, the server verifies each item: the existence of the source file, the validity of the target directory, and the remaining space on the target volume.

[0060] Example 2, List Request (op="list");

[0061] List the specified directories:

[0062] {

[0063] "timestamp": 1741590000004,

[0064] "op": "list",

[0065] "data": "D: / My Movies"

[0066] }

[0067] List the logical drivers (data is empty):

[0068] {

[0069] "timestamp": 1741590000005,

[0070] "op": "list",

[0071] "data": ""

[0072] }

[0073] List recoverable deleted items (data = "recycle"):

[0074] {

[0075] "timestamp": 1741590000006,

[0076] "op": "list",

[0077] "data": "recycle

[0078] }

[0079] Example 3: Copy / move progress report response (status=0);

[0080] During the copy / move process, the server pushes progress to the client at intervals of one second:

[0081] {

[0082] "response": {

[0083] "status": 0,

[0084] "reason": ""

[0085] },

[0086] "progress": {

[0087] "total": 5,

[0088] "current": 2,

[0089] "name": "movieA.mkv",

[0090] "percentage": "45.23%",

[0091] "speed": "128.500 MB / s"

[0092] }

[0093] }

[0094] Example 4, List response (including an array of entries);

[0095] Response when listing directory contents:

[0096] {

[0097] "response": {"status": 1, "reason": ""},

[0098] "entry": [

[0099] {"meta": "", "name": "movieA.mkv", "type": 0, "size":21474836480},

[0100] {"meta": "", "name": "subfolder", "type": 1, "size": 0} ]

[0102] }

[0103] Response when listing logical drivers:

[0104] {

[0105] "response": {"status": 1, "reason": ""},

[0106] "entry": [

[0107] {"meta": "", "name": "C: / ", "type": 1, "size": 0},

[0108] {"meta": "", "name": "D: / ", "type": 1, "size": 0},

[0109] {"meta": "", "name": "E: / ", "type": 1, "size": 0} ]

[0111] }

[0112] List the responses when deleted items can be recovered:

[0113] {

[0114] "response": {"status": 1, "reason": ""},

[0115] "entry": [

[0116] {

[0117] "meta": "133523456789012345.recyclemeta",

[0118] "name": "D: / My Movies / Movie A.mkv",

[0119] "type": 0,

[0120] "size": 0

[0121] } ]

[0123] }

[0124] Step 3: Store the received requests in the receiving queue. When the receiving queue reaches the preset limit, return a response to the client indicating that the queue is full.

[0125] The receive queue (recvQueue) has a maximum length (e.g., 100). When the queue is full, new requests are rejected and a busy response of "Queueis full" is returned. The number of the two types of threads can be configured through startup parameters (light_thread, heavy_thread), with a maximum total number of threads (e.g., 20) to avoid resource exhaustion. The listen backlog (listening queue) can be set to a large value (e.g., 2000) to handle peak connection times. This design improves throughput and stability when multiple clients initiate batch tasks simultaneously, facilitating operation and maintenance optimization. Please refer to [link to relevant documentation]. Figure 3 The figure shown is a timing diagram for the high-concurrency scheduling of the present invention.

[0126] Step 4: Retrieve requests from the receiving queue and distribute them according to the operation type. Send directory creation, deletion, list creation, and restoration to the lightweight thread queue, and send copying and moving to the heavyweight thread queue.

[0127] Please see Figure 4 The diagram shows the dual-thread scheduling flowchart of this invention. Lightweight threads handle short-term operations such as list, mkdir, rm, and recover, while heavyweight threads handle I / O-intensive operations such as copy and move. Each thread receives type assignments (e.g., PostThreadMessage notification WM_THREAD_SETTYPE) in the message loop and retrieves tasks from the corresponding lightQueue or heavyQueue. Newly arrived sockets are decoded into OpTasks and then distributed to the corresponding queue according to task_priority. If the types do not match, the task is automatically switched to another queue. The task priority allocation rules are shown in Table 1.

[0128] Table 1 Task Priority Allocation Rules

[0129] Operation type (op) task_priority Thread type allocation illustrate copy 2 Heavy (heavy thread) I / O-intensive long-term operation move 2 Heavy (heavy thread) Copy first, then delete the source; I / O intensive. mkdir 1 Light (Lightweight Threading) Short-term metadata operations rm 1 Light (Lightweight Threading) Rename + Write Metadata, Short-Term Operation list 1 Light (Lightweight Threading) Directory enumeration, short-time operation recover 1 Light (Lightweight Threading) Rename and restore + delete metadata, short-term operation

[0130] Step 5: When performing a copy or move operation, push progress information to the client and detect abort requests; stop immediately upon detection. When deleting, rename the file in its original location and record metadata to a dedicated directory. When listing, return the metadata list if the parameter is a recycle bin identifier. When restoring, move the file back to its original path based on the metadata. Specifically:

[0131] (1) Progress feedback, abortability, and atomic rollback for long-running operations: For long-running operations such as copy / move, the server pushes progress (total, current, name, percentage, speed) to the client at certain intervals (e.g., per second) during execution. The client can display the progress or send an abort request to abort the current operation. The server detects abort requests from the client through non-blocking polling in the copy loop. Upon detection, the server stops immediately and appends "operation aborted" to the response. Copying adopts the method of "first writing a temporary file (marking the target path with .winfsproc), and then renaming it to the official file after completion". Automatic rollback (deleting the written target or restoring the source) is performed when a single item fails to ensure data consistency. The copy buffer adopts an adaptive strategy: when the file is less than 100MB, the file size is used as the buffer; when the file is greater than or equal to 100MB, a fixed 100MB buffer is used to balance the efficiency of small files and the memory usage of large files. Forward slashes are used uniformly in the protocol path to decouple the path from the platform. The semantics of the move operation are: copy to the target first, then delete the source file.

[0132] (2) Integrated Recycle Bin and Metadata-Based Recovery – Separation of Metadata and Data: The deletion operation does not directly and permanently delete the data, but adopts a “separation of metadata and data” design: the file is renamed in its original location to a marked file (e.g., the original path is modified to include .winfsdel) and the hidden attribute is set. At the same time, a metadata file (e.g., .recyclemeta) is generated for each deleted file in a dedicated directory maintained on the server (e.g., WinFsRecycleBin), recording the original path, the marked path, and the deletion time. The data is still retained in the original path, and the metadata is centrally stored in the dedicated directory for easy auditing and compliance traceability. When data is “recycle”, list enumerates the metadata files in the dedicated directory and returns meta / name / type / size. When list is a normal directory, it automatically filters out internal marked files such as .winfsdel, .winfsproc, and .recyclemeta to keep the user view clean. recover locates the metadata and corresponding marked files based on data (i.e., the meta returned by list), moves the file back to the original path, removes the hidden attribute, and deletes the corresponding metadata file. This mechanism is integrated with the protocol and is independent of the system's built-in recycle bin, forming an application-layer programmable "recoverable deletion" capability, and can be connected to enterprise-level tombstoning and deletion management needs.

[0133] The file content is plain text, with one field per line, separated by newline characters: the first line is the absolute path of the original file, the second line is the renamed path (original path + .winfsdel), and the third line is the deletion timestamp (Windows FILETIME format, 100ns precision). An example is shown below:

[0134] D: / My Movies / MovieA.mkv

[0135] D: / My Movies / MovieA.mkv.winfsdel 133523456789012345

[0137] (3) The present invention can achieve a closed loop through listing → operation → verification.

[0138] Copying Scenario: The client first retrieves the current file list in the source directory using a list request, then sends a copy request (specifying src and dst in the list). When copying large files, the server pushes progress updates to the client at intervals (current item number, total number of items, current filename, completion percentage, and transfer speed). The client can use this information to display the progress or send an abort request to stop the copying process. After copying is complete, the client can relist the target directory to verify the results and update the interface. Please refer to [link to relevant documentation]. Figure 5 This is a flowchart of the copying operation of the present invention.

[0139] In a mobile scenario: the client first lists the original directory and then sends a move request; the server first copies the file to the target, and upon successful copying, deletes the source file. The client can then list the new and original locations again, providing a visual update that shows "the file has moved to the new location and is no longer in the original location." Please refer to [link / reference]. Figure 6 This is a flowchart of the mobile operation of the present invention.

[0140] Deletion scenario: The client sends an `rm` request. The server renames the file to a tagged file and records the original location metadata. The client can then check the original directory to confirm the file is gone and can use `list data=recycle` to retrieve recoverable items for the user to choose from for recovery. Please refer to [link to relevant documentation]. Figure 7 This is a flowchart of the recoverable deletion operation of the present invention.

[0141] The aforementioned closed loop of "listing first, then operating, observing and pausing during operation, and listing and verifying after operation" is uniformly implemented at the protocol layer. The native file APIs of mainstream operating systems do not provide such an integrated programmable process.

[0142] Example 2: Optional transaction and crash recovery extensions.

[0143] Please see Figure 8 The diagram below illustrates an optional transaction and crash recovery extended architecture for this invention. The currently implemented server-side architecture includes: API routing (request parsing and op distribution), service core (implementation logic for six types of operations and abort mechanisms), recycle bin manager (dedicated recycle bin directory and metadata read / write, list recycle and recover), and file system engine (interacting with the operating system file system). The persistence layer includes a temporary file storage area, recycle bin file storage, and recycle bin metadata storage. As an optional further improvement, the server can add a transaction manager, an operation log system, and a crash recovery mechanism: assigning batch_ids to batch operations and recording the status of each sub-operation in the operation log; supporting chunked copying and breakpoint resumption during copying; scanning for incomplete operations and resuming from breakpoints after service restart; and performing consistency recovery and continuing with remaining items after a crash for moves and deletions. On the client side, corresponding guardian components such as an operation status manager, automatic retry, timeout detection, heartbeat monitoring, and a batch operation manager can be added.

[0144] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0145] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A file system kernel service and high-concurrency scheduling method based on a unified protocol, including the following steps: Step 1: Start the accept thread and file operation thread on the server side. The file operation thread includes a lightweight thread and a heavyweight thread. Step 2: Listen on the network port using the receiving thread to receive JSON format requests sent by the client. The requests include timestamps and operation types. Operation types include copy, move, create directory, delete, list, and restore. Step 3: Store the received requests in the receiving queue. When the receiving queue reaches the preset limit, return a response to the client indicating that the queue is full. Step 4: Retrieve requests from the receiving queue and distribute them according to the operation type. Send directory creation, deletion, list creation, and restoration to the lightweight thread queue, and send copying and moving to the heavyweight thread queue. Step 5: When performing a copy or move operation, push progress information to the client and detect abort requests. If an abort request is detected, stop immediately. When deleting, rename the file in its original location and record metadata to a dedicated directory. When listing, if the parameter is a recycle bin identifier, return the metadata list. When restoring, move the file back to its original path based on the metadata.

2. The file system kernel service and high-concurrency scheduling method based on a unified protocol according to claim 1, characterized in that: When the operation type is deletion, a recoverable deletion process is executed, specifically: the file to be deleted is renamed to a file with a hidden tag in its original location, and a metadata file is created in the dedicated recycle bin directory to record the original path, the marked path, and the deletion time; during recovery, the metadata file in the dedicated recycle bin directory is enumerated, parsed, and the entry information containing metadata identifier, original file name, file type, and file size is returned; when performing a normal directory listing, files with internal tags containing preset suffixes are automatically filtered out.

3. The file system kernel service and high-concurrency scheduling method based on a unified protocol according to claim 1, characterized in that: When the operation type is a copy operation or a move operation, specifically: during the execution process, progress information including the completion percentage and transmission speed is pushed to the client at preset time intervals, and the operation can be stopped in response to the client's request to stop the operation. After copying is complete, the client can list the target directory again to verify the results and update the interface. After moving is complete, the client can list the new location and the original location again.

4. The file system kernel service and high-concurrency scheduling method based on a unified protocol according to claim 3, characterized in that: The copy operation uses a method of first writing a temporary file and then renaming it to a formal file after completion. If a single item fails, it will automatically roll back, delete the target that has been written or restore the source, and ensure data consistency.

5. The file system kernel service and high-concurrency scheduling method based on a unified protocol according to claim 1, characterized in that: When the operation type is a recovery operation, the metadata identifier in the request message is parsed, and the corresponding marker file is moved back to the original path according to the original path recorded in the metadata file, the hidden marker is cleared, and the metadata file is deleted.

6. The file system kernel service and high-concurrency scheduling method based on a unified protocol according to claim 1, characterized in that: When the operation type is a list operation, it specifically means: returning a list of logical drives, a list of files in a specified directory, or a list of recoverable deleted items in a dedicated recycle bin directory based on the request parameters.

Images