A method for optimizing performance of a distributed file system recycle bin

Abstract

This invention relates to a performance optimization method for a distributed file system recycle bin. During the execution of the Linux file system unlink interface, the method sequentially performs recycle bin functionality activation checks, file deletability verification, and recycle bin storage compatibility checks, obtaining metadata of the parent directory of the target deleted file from the server. A globally unified root recycle bin directory is generated synchronously during file system creation. When a file is deleted, a corresponding recycle bin subdirectory is created in the target MDS based on the parent directory's inode number. An atomic operation is performed using the Linux standard rename interface to move the file to the corresponding recycle bin subdirectory; this operation is limited to a single MDS. When restoring a file, the parent directory's inode number is extracted, and the original complete path is reconstructed by iteratively querying the metadata. During batch restoration, if the original directory does not exist or needs to be restored to a new directory, the entire recycle bin directory is moved; otherwise, restoration is performed file-by-file. This significantly improves file deletion and restoration performance, reduces resource overhead, and ensures data consistency.

Description

Technical Field

[0001] This invention belongs to the field of recycle bin performance optimization technology, and in particular relates to a method for optimizing the performance of a distributed file system recycle bin. Background Technology

[0002] With the widespread application of distributed file systems in big data, cloud computing, and other fields, file deletion and recovery operations have become one of the core scenarios in daily system operation and maintenance. As a crucial function for ensuring data security, the design of the recycle bin directly impacts the performance and user experience of the distributed file system.

[0003] In existing technologies, there are two main ways to implement the recycle bin in a distributed file system: one is to move files to the recycle bin when they are deleted and record the original file path in the file attributes for later recovery; the other is to store the file path information in a separate database and rely on database queries to complete the recovery operation. However, distributed file systems typically deploy multiple metadata servers (MDS), each managing a portion of the file system metadata. The above-mentioned existing solutions have significant drawbacks:

[0004] High latency in deletion operations: Moving files to the recycle bin requires coordination across multiple MDSs, which significantly increases the response latency of deletion operations, especially in high-concurrency deletion scenarios, making the system performance bottleneck prominent.

[0005] The recovery process is complex and inefficient: When recovering files, it is necessary to read the file's extended attributes or the path information stored in the database, which increases the complexity of metadata operations and further prolongs the recovery time; for directory-level batch recovery scenarios, recovery operations need to be performed on each file, and the time consumption increases linearly, which cannot meet the needs of rapid recovery of large-scale files.

[0006] High resource overhead: Relying on database storage of path information or appending records to file attributes not only consumes additional storage resources, but also increases the difficulty of maintaining data consistency, and is prone to problems such as loss or disorder of path information leading to unrecoverable files;

[0007] Insufficient compatibility and atomicity: Some solutions do not adopt the Linux file system standard interface, resulting in poor compatibility with the existing system ecosystem. Furthermore, the file movement process lacks atomicity guarantees, which may lead to intermediate states such as file corruption and path loss.

[0008] Therefore, optimizing the deletion and restoration process of the recycle bin under the distributed file system architecture, reducing cross-MDS coordination operations, reducing metadata operation overhead, improving batch recovery performance, and ensuring the atomicity of operations and data consistency have become urgent technical problems to be solved. Summary of the Invention

[0009] The purpose of this invention is to provide a performance optimization method for the recycle bin in a distributed file system, which optimizes the deletion and recovery process of the recycle bin under the distributed file system architecture, reduces cross-MDS coordination operations, reduces metadata operation overhead, improves batch recovery performance, and ensures the atomicity of operations and data consistency.

[0010] The technical solution adopted in this invention is as follows:

[0011] A method for optimizing the performance of a distributed file system recycle bin includes the following steps:

[0012] S1: During the execution of the unlink standard processing interface of the Linux file system, it sequentially determines whether the directory where the file is located has the recycle bin function enabled, whether the file can be deleted, and whether the file needs to be put into the recycle bin. It obtains the metadata of the parent directory of the target file to be deleted from the server through the file path, including the inode number of the parent directory.

[0013] S2: When the file system is created, a globally unified root recycle bin directory for storing all deleted files is generated synchronously; when a file deletion operation is detected, a directory creation request is sent to the target MDS with the parent directory inode number as the directory name and the index number of the MDS to which the parent directory metadata belongs as the orientation parameter.

[0014] S3: The client initiates an atomic move operation based on the Linux file system standard rename interface, directly moving the target deleted file to the recycle bin directory;

[0015] S4: When a file recovery operation is initiated, based on the path of the target file in the recycle bin, the parent directory name, i.e. the parent directory inode number, is extracted from the path. The corresponding metadata is queried through the inode number, and then the inode number of the parent directory is obtained. The complete path from the original directory to the root directory is obtained by iterative traversal.

[0016] S5: Obtain the original directory of the deleted file. If the original directory path does not exist or needs to be restored to a specified new directory, initiate the rename atomic operation to move the corresponding directory in the recycle bin to the target location. If the original directory path exists, repeat step S4 for each file in the directory.

[0017] Preferably, the specific process of determining whether the directory where the file is located has the recycle bin function enabled, whether the file can be deleted, and whether the file needs to be put into the recycle bin in step S1 is as follows:

[0018] S11: Determine whether the recycle bin function is enabled in the directory where the file is located by querying and configuring directory metadata;

[0019] S12: Confirm whether the file is allowed to be deleted by verifying permissions, detecting file occupancy status, and detecting locked status;

[0020] S13: Confirm whether the files need to be included in the recycle bin management by detecting critical system files and matching storage policies;

[0021] S14: Output the final judgment result: If the system critical file detection, lock status detection, and storage policy matching detection are passed, it is determined that "the file needs to be put into the recycle bin", and the subsequent recycle bin directory creation and file movement process is entered; if any of the detections are not passed, the recycle bin process is terminated, and the file is deleted according to the normal unlink logic.

[0022] Preferably, the specific process of step S12 is as follows:

[0023] S121: User permission verification: Obtain the user account and user group to which the user initiated the unlink operation, query the permission control list of the target file, and confirm whether the user has deletion permission;

[0024] S122: File occupancy status detection: The file occupancy status is determined by checking whether the file reference count is 0. 0 indicates that the file is not occupied, and 1 indicates that the file is occupied by the system or application. If there is no occupancy, proceed to the verification in S123.

[0025] S123: Special attribute verification: Check if the file has a non-deletable special attribute set. If so, it is determined to be non-deletable regardless of permissions. If the attribute is not set and the file passes the above permission and occupancy checks, it is determined to be deletable and proceeds to the next step.

[0026] Preferably, the specific process of obtaining the metadata of the parent directory of the target deleted file from the server via the file path in step S1 is as follows:

[0027] S15: Parse file paths and locate parent directories, including file path standardization, extracting parent directory paths, and generating parent directory path check codes;

[0028] S16: Route to the target MDS and query metadata;

[0029] S17: The target MDS performs integrity verification on the metadata. After the verification is successful, the target MDS uses the node's private key to digitally sign the metadata. Then, it encapsulates the signed metadata, signature information, and response timestamp into a response packet and returns it to the client.

[0030] Preferably, the specific process of step S16 is as follows:

[0031] S161: Locate the MDS node responsible for the parent directory through path routing;

[0032] S162: Initiate a parent directory metadata query request to the target MDS;

[0033] S163: Target MDS performs metadata query.

[0034] Preferably, the specific process of synchronously generating a globally unified root recycle bin directory for storing all deleted files during file system creation in step S2 is as follows:

[0035] S21: Preset configuration of root recycle bin directory parameters, including directory path, directory identifier, MDS node policy, and storage quota limit;

[0036] S22: Creation and registration of the root recycle bin directory, including cluster initialization coordination, determination of the root directory master management MDS, execution of root directory initialization creation by the master MDS node, synchronization and consistency verification of master and slave node metadata, and registration of full cluster directory reachability.

[0037] S23: Permission Configuration and Function Activation: This includes permission policy binding, storage policy activation, function availability verification, and creation result feedback.

[0038] Preferably, the specific process of step S3 is as follows:

[0039] S31: The client summarizes the key data from the preceding steps, clarifies the core parameters of the rename operation, including the source path, target path, target MDS index, and performs atomic operation pre-configuration;

[0040] S32: Initiation and execution of atomic rename operations;

[0041] S33: The result feedback and status synchronization of the atomic rename operation.

[0042] Preferably, the specific process of step S32 is as follows:

[0043] S321: Establish a dedicated communication channel with the target MDS;

[0044] S322: Construct and send a rename atomic operation request;

[0045] S323: The target MDS performs an atomic move operation.

[0046] Preferably, the specific process in step S4 is as follows:

[0047] S41: Parse the recycle bin path and extract the core inode number: When the client receives a file recovery request, it obtains the complete path of the target file in the recycle bin and extracts the original parent directory inode number;

[0048] S42: Iteratively query metadata to trace the complete original path;

[0049] S43: Bind the restored original complete path to the corresponding recycle bin path and cache it locally on the client. If the same file is restored again in the future, the cached path can be reused directly, reducing the overhead of repeated iteration queries.

[0050] Preferably, the specific process of step S42 is as follows:

[0051] S421: Initialize traceability parameters: including the current inode number to be queried, the list of path components, the termination identifier, and the location of the MDS node to which it belongs;

[0052] S422: Iterate through the parent inodes and concatenate the path:

[0053] S423: Perform concatenation and verify the original complete path.

[0054] The beneficial effects of this invention include:

[0055] 1. Significantly reduces deletion operation latency and improves concurrent processing capabilities: During the file deletion phase, this invention parses the metadata of the file's parent directory and creates the recycle bin subdirectory on the same MDS node as the original parent directory. The client performs an atomic move operation through the Linux standard rename interface. This operation is a single MDS internal transaction, eliminating the need for coordination across multiple MDS nodes and completely avoiding the time-consuming cross-node scheduling issues in existing technologies. Simultaneously, it eliminates the need to record additional information in file attributes or rely on database storage paths, reducing metadata operation overhead and significantly improving the response speed of deletion operations. In high-concurrency deletion scenarios, system throughput can be increased by more than 30%.

[0056] 2. Simplify the recovery process and improve recovery efficiency, especially optimizing batch recovery performance: High efficiency in single file recovery: During recovery, the original parent directory inode number is directly extracted through the recycle bin path. The original complete path can be restored by iteratively querying the metadata based on the inode number. There is no need to read external databases or file extended attributes. The process is simplified and the query is directed to the target MDS, reducing recovery latency compared to existing technologies.

[0057] Significant performance improvement in batch recovery: For directory-level batch recovery, if the original directory does not exist or needs to be restored to a new directory, the corresponding directory in the recycle bin is directly renamed. Only the directory node metadata is modified, without the need to process each file individually. The batch recovery time is reduced from "number of files × single file recovery time" to a fixed time (milliseconds). Especially in the scenario of directory recovery containing thousands or even tens of thousands of files, the efficiency improvement can be more than 100 times.

[0058] 3. Ensures atomicity of operations and data consistency, reducing resource overhead: Relying on the atomicity of the Linux file system standard rename interface, file move operations either execute completely or roll back entirely, without intermediate states, avoiding data consistency issues such as file corruption and path loss. No additional database storage of path information is required, nor are records appended to file extended attributes, reducing storage resource consumption and avoiding the additional overhead of database maintenance and attribute synchronization, thus lowering system operation and maintenance complexity.

[0059] 4. Enhanced access control and policy management improve system security and availability:

[0060] By performing recycle bin enable checks, file deletability verification, and recycle bin storage policy matching before file deletion, it ensures that only files that meet the rules are included in the recycle bin management, avoiding the accidental storage of critical system files and locked files into the recycle bin, and preventing recycle bin malfunctions due to storage overflow; path validity verification and permission verification during the recovery process further ensure the security of data recovery, avoiding unauthorized operations or recovery to invalid paths. Attached Figure Description

[0061] Figure 1 This is a flowchart illustrating the distributed file system recycling station performance optimization method of the present invention.

[0062] Figure 2 This is a schematic diagram illustrating the file deletion identification process of this invention. Detailed Implementation

[0063] The following is in conjunction with the appendix Figure 1-2 The present invention will be further described in detail below:

[0064] Example 1

[0065] See appendix Figure 1 As shown, a method for optimizing the performance of a distributed file system recycle bin includes the following steps:

[0066] S1: Identifying Deletion Operations and Parent Directory Information of the Deleted File: During the execution of the unlink standard processing interface of the Linux file system, the system sequentially checks whether the directory containing the file has the recycle bin enabled, whether the file is deletable, and whether the file needs to be placed in the recycle bin. The determination of whether a file needs to be placed in the recycle bin includes checking whether the file is a critical system file, whether it is locked, and whether it meets the recycle bin storage policy. If the preset conditions are met, it is determined that the file needs to be placed in the recycle bin. After all checks pass, the system obtains the metadata of the target deleted file's parent directory from the server through the file path. The metadata includes the parent directory's inode number, the index number of the metadata server (MDS) to which the parent directory's metadata belongs, and the inode number of the parent directory at the next higher level. The inode number is a unique identifier for the file or directory, and the corresponding metadata information can be directly queried through this number. Simultaneously, the obtained metadata is verified to confirm its completeness and validity. If the metadata is missing or invalid, the recycle bin storage process is terminated and an error message is returned.

[0067] The metadata verification includes uniqueness verification of the parent directory inode number, validity verification of the MDS index number, and correlation verification of the inode number of the higher-level parent directory, ensuring that the metadata can support subsequent directory creation and path restoration.

[0068] S2: Create a specific directory in the recycle bin based on parent directory information: A globally unified root recycle bin directory for storing all deleted files is generated synchronously during file system creation. The access permissions and storage quotas of the root recycle bin directory are pre-configured and support dynamic adjustment. When a file deletion operation is detected, the parent directory inode number obtained in step S1 is used as the directory name, and the index number of the MDS to which the parent directory metadata belongs is used as the directional parameter to send a directory creation request to the target MDS. After receiving the request, the target MDS first checks whether its own node resources meet the directory creation requirements. If the resources are sufficient, it creates the corresponding directory metadata in its own node, forming a two-level directory structure of "root recycle bin directory - parent directory inode number directory". The two-level directories correspond one-to-one with the original parent directory of the deleted file and belong to the same MDS.

[0069] The storage quota of the root recycle bin directory can be dynamically adjusted based on the remaining storage space of the file system. When the quota is insufficient, a cleanup strategy is triggered to automatically clean up some files according to the order of file deletion time or file priority.

[0070] S3: Move the deleted file to the corresponding directory in the recycle bin: The client initiates an atomic move operation based on the Linux file system standard rename interface, directly migrating the target deleted file to the recycle bin directory created in step S2. This operation belongs to a single-node transaction within the MDS corresponding to the index number, without the need for coordination across multiple MDSs. During the move, only the file's location-related metadata is modified, without the need to record additional information in the file's extended attributes or add new database records. At the same time, an operation log is generated to record the file move status in real time, ensuring that the operation is traceable.

[0071] The operation log contains key information such as file identifier, move time, source path, target path, execution node, and operation result. The log data is stored in a distributed manner to ensure that it is not lost.

[0072] S4: Recover a Single Target File: When initiating a file recovery operation, based on the target file's path in the recycle bin, the parent directory name (i.e., the parent directory's inode number) is extracted from the path. The corresponding metadata is then queried using this inode number to obtain the inode number of the parent directory. This process iterates through the entire path from the original directory to the root directory, verifying the validity of the original path. If permission restrictions or conflicts exist, a permission verification and conflict resolution mechanism is triggered. After successful verification, an atomic move operation based on the Linux file system standard rename interface is initiated, moving the target file from the recycle bin directory to the original directory. This operation is a single-node transaction within the same MDS, preventing data loss or inconsistency during migration. The conflict resolution mechanism includes three modes: file renaming, overwrite confirmation, and temporary storage. Users can pre-configure the default processing strategy or select a mode in real-time when a conflict occurs.

[0073] S5: Batch recovery of all files in a single directory: Following the method in step S4, obtain the original directory of the deleted files. If the original directory path does not exist or needs to be restored to a specified new directory, initiate a rename atomic operation to move the corresponding directory from the recycle bin to the target location. Only the directory node metadata is modified; no metadata modification is required for individual files within the directory. If the original directory path exists, repeat step S4 for each file within the directory. All recovery operations are completed within the same MDS, eliminating the need for cross-MDS coordination. Real-time progress information is provided during batch recovery, supporting interactive operations such as pause and cancel. An automatic rollback mechanism is triggered in case of abnormalities. The progress feedback for batch recovery includes the number of recovered files, the number of remaining files, the current recovery rate, and the estimated completion time. After pausing the operation, recovery can resume from the breakpoint.

[0074] The above method is applicable to distributed file systems containing multiple metadata servers (MDS). By limiting operations to be executed within the same MDS, adopting atomic rename operations, optimizing directory structure design, and adding metadata verification and exception handling mechanisms, it reduces cross-MDS scheduling and coordination and additional metadata operations, thereby improving the concurrent performance, response speed, and data security of file deletion and recovery.

[0075] In this embodiment, see Figure 2 The specific process of determining whether the recycle bin function is enabled in the directory where the file is located, whether the file can be deleted, and whether the file needs to be put into the recycle bin in step S1 is as follows:

[0076] S11: Determine if the recycle bin function is enabled in the directory where the file is located: Confirm the function's enabled status through directory metadata query and configuration verification. The specific process is as follows:

[0077] Locate the directory to which the target file belongs: The file path passed in through the unlink interface (which can be / user / docs / file.txt) is parsed to obtain the direct parent directory path of the file, such as / user / docs.

[0078] Query the recycle bin switch flag in the directory metadata: Obtain the metadata of the parent directory from the server (metadata server MDS). The metadata contains a preset "recycle bin function enable flag" (binary bit, 0 indicates not enabled, 1 indicates enabled).

[0079] The function inheritance rules for verifying directory hierarchy are as follows: If the enable flag of the parent directory is 1, it is directly determined that the recycle bin function is enabled; if the flag is 0, the recycle bin function status of the parent directory (up to the root directory) is further queried, following the rule that "if the parent directory is enabled, the subdirectory will inherit the enable by default" (unless the subdirectory is explicitly configured to be disabled).

[0080] Output the judgment result: If there is an enabled record in the configuration of the directory where the target file is located and its parent directory, it is determined that "the recycle bin function is enabled in the directory where the file is located", and proceed to the next judgment; if the function is not enabled in all directories, terminate the recycle bin related process and perform file deletion according to the normal unlink logic.

[0081] S12: Determine if a file can be deleted: Confirm whether the file is allowed to be deleted by verifying permissions, checking file usage status, and checking locked status.

[0082] File lock status detection: Read the "lock flag" in the file metadata. If it is 1 (actively locked), it is determined that "no need to put it in the recycle bin"; if the flag is 0, it means that it is not locked.

[0083] S13: Determine if a file needs to be moved to the recycle bin: Confirm whether a file needs to be included in the recycle bin management by filtering critical system files and matching storage policies.

[0084] Recycle Bin storage policy matching check: Verify whether the file size meets the recycle bin's preset threshold (e.g., a maximum of 10GB for a single file); verify whether the file type is within the recycle bin's "allowed storage list" (excluding temporary files, log fragments, etc.); verify whether the initiating user's recycle bin storage quota is sufficient; verify whether the file's historical deletion frequency exceeds the threshold, such as being deleted more than 3 times within 24 hours.

[0085] If all strategies match, this test passes.

[0086] S14: Output the final judgment result:

[0087] If all the above checks are passed, namely lock status check and storage policy matching check, it is determined that the file needs to be placed in the recycle bin, and the subsequent recycle bin directory creation and file moving process will begin.

[0088] If any check fails, the recycle bin process is terminated, and the file is deleted according to the normal unlink logic.

[0089] The above process first confirms whether the directory supports the recycle bin function, second confirms whether the file meets the deletion criteria, and third confirms whether the file conforms to the recycle bin storage rules. Only when all three steps are passed will the subsequent processes such as "obtaining parent directory metadata, creating recycle bin directory, and moving files" be triggered to ensure the legality and rationality of the recycle bin operation.

[0090] The specific process of step S12 is as follows:

[0091] S121: User permission verification:

[0092] Get the user account (such as a regular user or an administrator user) and the user group to which the unlink operation was initiated;

[0093] Query the Access Control List (ACL) of the target file to confirm whether the user has "delete permission", which is the "w" permission in the file permission bits, and the permission configuration for the file owner, group users, or other users.

[0094] If the user is an administrator account, they have mandatory deletion permissions by default, unless the file is configured with a special attribute that "prevents administrators from deleting"; if the user is a regular user, the deletion permissions in the ACL must be strictly matched, and if the user does not have the permission, the file will be judged as "cannot be deleted".

[0095] S122: File occupancy status detection: The file occupancy status is determined by checking whether the file reference count is 0. 0 indicates that the file is not occupied, and 1 indicates that the file is occupied by the system or application. If there is no occupancy, proceed to the verification in S123.

[0096] S123: Special attribute verification: Check if the file has a "non-deletable" special attribute, such as the immutable attribute in Linux systems, which can be set using chattr+i; if the file has this special attribute, it is determined to be "non-deletable" regardless of permissions; if the attribute is not set, and the file passes the above permission and occupancy checks, it is determined to be "deletable", and proceed to the next step of judgment.

[0097] In this embodiment, the specific process of obtaining the metadata of the parent directory of the target deleted file from the server through the file path in step S1 is as follows:

[0098] S15: Parsing file paths and locating parent directories:

[0099] File path standardization: The client receives the target file path from the unlink interface, supporting relative paths such as .. / docs / file.txt or absolute paths such as / user / docs / file.txt. First, a path standardization operation is performed, that is, redundant identifiers such as "." (current directory) and ".." (parent directory) in the path are removed, and it is converted into an absolute path of uniform format to clarify the complete storage path of the target file.

[0100] Extracting the parent directory path: Based on the standardized absolute path, the path components are split by the path separator ( / ). The last component (the target file name, which can be file.txt) is removed, and the remaining part is the absolute path of the direct parent directory of the target file to be deleted (which can be / user / docs).

[0101] Generate parent directory path verification code: Perform a hash operation on the absolute path of the parent directory to generate a unique verification code, which is used for consistency verification of subsequent metadata queries to prevent tampering during path transmission or parsing.

[0102] S16: Route to the target MDS and query metadata:

[0103] S161: Locate the MDS node responsible for the parent directory via path routing:

[0104] Distributed file system routing rule matching: The distributed file system is pre-configured with "directory path-MDS index" routing mapping rules, supporting static hash mapping or dynamic consistent hashing algorithm. The client passes the absolute path of the parent directory or its hash value to the routing module.

[0105] Calculate the target MDS index number: The routing module calculates the index number of the target MDS based on the parent directory path according to preset rules. If static hash mapping is used, the parent directory path is hashed directly and modulo the number of MDS cluster nodes to obtain the index number of the target MDS. If dynamic consistent hashing is used, the corresponding MDS node is located on the hash ring through the path hash value and its index number is extracted.

[0106] Establish a connection with the target MDS: Based on the calculated MDSindex number, the client queries the locally cached "MDSindex-node address" mapping table, which is updated periodically and contains the IP address, port number, and communication protocol of each MDS, to establish a TCP / IP connection with the target MDS and ensure the reliability of data transmission.

[0107] S162: Initiate a parent directory metadata query request to the target MDS:

[0108] Constructing a query request packet: The client constructs a metadata query request packet according to the communication protocol preset by the distributed file system, which can be a custom binary protocol or the Protobuf protocol. The packet body contains the core fields:

[0109] Operation type: Parent directory metadata query, identified as QUERY_PARENT_DIR_METADATA;

[0110] Absolute path to the parent directory;

[0111] Parent directory path verification code;

[0112] Client identifier (IP + port + session ID);

[0113] The list of metadata fields to be queried should explicitly specify "parent directory inode number, MDSindex number, and parent directory inode number".

[0114] Request packet encryption and transmission: The query request packet is encrypted to prevent metadata leakage. It is then sent to the target MDS node through the established connection, and a timeout retransmission mechanism is initiated. The default timeout is 100ms, and the number of retransmissions is ≤3 to ensure that the request is reachable.

[0115] S163: Perform a metadata query on the target MDS;

[0116] Request packet decryption and verification: After receiving the query request packet, the target MDS first decrypts it using a preset key, then verifies the legitimacy of the client identifier (checking whether the client is in the MDS's authorized access list), and compares the parent directory path checksum with the locally calculated result. If the verification fails, an "illegal request" response is returned.

[0117] Query the MDS local metadata storage engine: The target MDS has a built-in metadata storage engine, which can be an in-memory hash table + disk persistent database. The query operation is performed within the storage engine using the absolute path of the parent directory as the search key.

[0118] First, query the memory hash table (caching hot directory metadata). If a matching record is found, directly extract the metadata.

[0119] If no matching record is found in memory, a disk database query is triggered, such as LevelDB or RocksDB, to quickly locate the corresponding metadata entry in the parent directory using the path index.

[0120] Extracting target metadata fields: From the retrieved metadata entries, accurately extract three core fields:

[0121] Parent directory inode number: A unique identifier for the parent directory, a 64-bit or 128-bit integer, automatically assigned during file system initialization, and globally unique;

[0122] The index number of the MDS to which the parent directory metadata belongs: The unique index of the current MDS node in the cluster, such as 0, 1, 2...N-1, where N is the number of nodes in the MDS cluster, used to confirm the node to which the metadata belongs;

[0123] S17: Metadata Validation and Result Return:

[0124] Metadata integrity verification: The target MDS performs integrity verification on the three core metadata items extracted—checking whether the fields are empty, whether the inode number format conforms to the file system specification (numerical range, check bit verification, etc.), and whether the MDSindex number is consistent with the current node index. If any abnormality is found, an "invalid metadata" response is returned.

[0125] Metadata signing and encapsulation: After verification, the target MDS uses the node's private key to digitally sign the metadata, which can be an RSA signature, to ensure that the metadata is not tampered with during data transmission; then the signed metadata, signature information, and response timestamp are encapsulated into a response packet in a unified format.

[0126] Response packet encryption and return: After encrypting the response packet, it is returned to the client through the original connection; after receiving the response packet, the client first decrypts it, and then uses the public key of the target MDS to verify the digital signature to confirm the integrity and authenticity of the metadata;

[0127] Local metadata caching: The client caches the verified metadata to the local "path-metadata" cache pool. If there is a file deletion operation in the same parent directory later, the cache can be reused directly to reduce the overhead of repeated queries.

[0128] Exception handling mechanism:

[0129] MDS node unavailable: If the target MDS node is offline or the communication timeout occurs, the client routing module automatically triggers the failover mechanism, locates the backup MDS node based on the consistent hashing algorithm, and repeats the above query process.

[0130] Metadata not found: If the target MDS query does not find the corresponding metadata for the parent directory, such as if the parent directory has been deleted, the "parent directory not found" response is returned, the client terminates the recycle bin process and executes according to the normal unlink logic.

[0131] Network transmission error: If the request or response packet is lost during transmission, the client will resend the request based on the timeout retransmission mechanism. If the retransmission fails after a total of 3 attempts, an operation error will be returned.

[0132] Example 2

[0133] Based on Example 1, the specific process of synchronously generating a globally unified root recycle bin directory for storing all deleted files during file system creation in step S2 is as follows:

[0134] S21: Root Recycle Bin Directory Parameter Preset Configuration:

[0135] Predefined core parameters: Key parameters for the root recycle bin directory are predefined in the file system deployment configuration file to ensure global consistency. These key parameters include:

[0136] Directory path: Fixed to a preset path under the root directory of the file system, such as / global / recyclebin, which cannot be customized to ensure that the access path is consistent across all nodes;

[0137] Directory Identifier: Assign a globally unique root recycle bin directory identifier, such as RECYCLE_BIN_ROOT_ID=000000, to distinguish it from ordinary directories;

[0138] MDS Node Strategy: The "master-slave backup" mode is adopted. A master MDS node is designated and selected by the load balancing algorithm during cluster initialization. For example, the MDS with the smallest node ID and sufficient resources is selected as the master management node of the root recycle bin directory. At the same time, 1-2 backup MDS nodes are configured for quick switchover in case of master node failure.

[0139] Storage quota limit: The preset global storage quota for the root recycle bin directory can be 5% of the total file system capacity, and can be dynamically adjusted later.

[0140] Configuration parameter consistency synchronization: Through the file system cluster configuration center, the above predefined parameters are synchronized to all metadata servers (MDS), data storage nodes and clients to ensure that all nodes have a consistent understanding of the configuration of the root recycle bin directory and avoid subsequent operation conflicts;

[0141] S22: Creation and registration of the root recycle bin directory:

[0142] Step 1: Cluster initialization coordination, determining the root directory master management MDS:

[0143] After the file system is created and started, the cluster starts the coordination module and sends a "root recycle bin directory master node election request" to all MDS nodes.

[0144] Each MDS node responds to the request and reports its own node status, including remaining memory, disk space, load rate, and network bandwidth.

[0145] The cluster controller selects the master MDS node (denoted as MDS_Master) and the standby MDS nodes (denoted as MDS_Slave1 and MDS_Slave2) according to preset rules, which can be based on the lowest load rate and sufficient resources, and broadcasts the master-slave node allocation results to the entire cluster.

[0146] After the master and slave MDS nodes confirm receipt of the allocation results, they establish a synchronization channel, such as a log synchronization channel based on the Raft protocol, to ensure that the metadata of the root recycle bin directory is synchronized in real time between the master and slave nodes.

[0147] Step 2: The main MDS node performs root directory initialization and creation:

[0148] After receiving the "Create root recycle bin directory" instruction from the cluster controller, MDS_Master calls the local directory creation interface and performs the following operations:

[0149] Allocate a unique inode number for the root recycle bin directory, such as inode=100000. This number is reserved in the global inode allocation of the file system and will not conflict with ordinary directories / files.

[0150] In the local metadata storage engine (such as an in-memory hash table + disk persistent database), create metadata entries for the root recycle bin directory. The metadata includes:

[0151] Basic information: directory name (recyclebin), absolute path ( / global / recyclebin), inode number, creation timestamp, and the MDS index to which it belongs (the index number of the MDS_Master).

[0152] Status information: Directory status (normal availability), storage quota (preset global quota), master / slave node identifier (MDS_Master is "master", MDS_Slave1 / 2 is "slave");

[0153] Association information: parent directory inode number (root directory inode=0, i.e., the root directory of the file system), subdirectory default storage rules (subsequently created subdirectories inherit the MDS association strategy of the main directory).

[0154] After the directory metadata is created, MDS_Master creates a corresponding root recycle bin directory storage directory on the local disk, such as / mnt / mds_data / recyclebin_root, to store the metadata and associated indexes of subsequent subdirectories.

[0155] Step 3: Master-slave node metadata synchronization and consistency verification:

[0156] MDS_Master synchronizes the complete metadata of the root recycle bin directory to MDS_Slave1 and MDS_Slave2 through the established synchronization channel;

[0157] After receiving the metadata, the standby MDS node creates the same metadata entry in its own metadata storage engine and creates a local storage directory to complete the data redundancy backup.

[0158] After the standby nodes complete synchronization, they return a "synchronization successful" response to MDS_Master. After receiving the responses from all standby nodes, MDS_Master performs a metadata consistency check (comparing the hash values ​​of the master and slave node metadata) to ensure that the metadata is consistent.

[0159] If the verification passes, MDS_Master sends a "Root recycle bin directory creation complete" notification to the cluster controller; if the verification fails, a resynchronization process is triggered, and if the synchronization fails three times, the system switches to a standby node to recreate the directory.

[0160] Step 4: Register reachability of the entire cluster directory:

[0161] After receiving the completion notification from MDS_Master, the cluster controller updates the cluster routing table, binding the absolute path of the root recycle bin directory ( / global / recyclebin) with the addresses (IP + port) of the master and slave MDS nodes, forming a "path-node" routing mapping.

[0162] The route mapping is synchronized to the local route cache of all clients, as well as the directory access list of each data storage node, to ensure that when a client initiates a recycle bin-related operation, it can quickly locate the main MDS node;

[0163] In the global directory tree of the file system management node, register the root recycle bin directory node, making it a fixed subdirectory under the root directory of the file system, and support querying the directory through the regular directory traversal interface (such as ls / global);

[0164] S23: Permission Configuration and Function Activation:

[0165] Permission policy binding: MDS_Master configures a default access control list (ACL) for the root recycle bin directory:

[0166] Administrator users (root / administrator group): have full permissions including read, write, execute, delete (subdirectories / files), and quota modification;

[0167] Ordinary users (ordinary user group): have read (view the contents of the recycle bin), write (put files in), and execute (access subdirectories) permissions, but no permissions to delete the root directory or modify quotas;

[0168] Guest users: Only have read permissions, no write or modify permissions;

[0169] Permission configurations are synchronized to all MDS nodes to ensure unified management of access permissions.

[0170] Storage policy activation: Enables the storage quota monitoring mechanism for the root recycle bin directory, which calculates the storage space occupied by the directory in real time. When the occupied space reaches 90% of the quota limit, an alert notification is triggered; when it reaches 100%, files are automatically cleaned up according to the preset cleanup policy (such as "earliest deletion time priority").

[0171] Functional availability verification: The cluster controller initiates a full-link test, simulating client operations such as "creating subdirectories", "moving files", and "querying directory information" to the root recycle bin directory, to verify the accessibility of the directory, the atomicity of operations, and the reliability of master-slave node switching;

[0172] Creation result feedback: After the test is passed, the cluster controller returns a "Root recycle bin directory created successfully" message to the file system deployment terminal. The file system enters normal operation, and the root recycle bin directory can receive storage requests for deleted files at any time.

[0173] Exception handling mechanism:

[0174] Master MDS node creation failure: If disk failure, insufficient memory, or other abnormalities occur when creating the directory for MDS_Master, the cluster controller will automatically switch to the standby node (MDS_Slave1), repeat the above creation process, and re-elect a new standby node.

[0175] Master-slave synchronization failure: If the master-slave node metadata synchronization times out or the verification is inconsistent, the incremental synchronization mechanism is triggered, and only the difference data is synchronized; if the synchronization fails 5 times in total, the standby node is determined to be unavailable and a new standby node is elected.

[0176] Configuration parameter conflict: If some nodes are not synchronized with the preset configuration parameters, the cluster configuration center will trigger a forced synchronization to ensure that all nodes are configured consistently before continuing the creation process.

[0177] In step S3, the client initiates an atomic move operation based on the Linux file system standard rename interface to directly migrate the target deleted file to the recycle bin directory created in step S2. The specific process is as follows:

[0178] S31: Operation Parameter Verification and Target Path Confirmation

[0179] Core Parameter Summary: The client summarizes key data from previous steps to clarify the core parameters of the rename operation:

[0180] Source path (oldpath): The standardized absolute path of the target file to be deleted, such as / user / docs / file.txt, which is the original path of the file after path resolution in step S1;

[0181] Target path (newpath): The absolute path of the recycle bin directory created in step S2 + the target file name, in the format of "root recycle bin directory path / parent directory inode number directory / file name", such as / global / recyclebin / 123456 / file.txt, where 123456 is the parent directory inode number obtained in step S1;

[0182] Target MDS Index: The index number of the MDS to which the parent directory metadata obtained in step S1 belongs, denoted as MDS_Index_Target, to ensure that the operation is directed to the target MDS node.

[0183] Path validity verification:

[0184] The client verifies the validity of the source path: it checks the local cache by inode number or performs a light verification with the server to confirm that the file corresponding to the source path exists and that the file status is movable (not locked and not occupied by any active process).

[0185] Verify the reachability of the target path: Based on the cluster routing table, confirm that the target recycle bin directory ( / global / recyclebin / 123456) has been successfully created on the MDS node corresponding to MDS_Index_Target by querying the directory metadata cache of the MDS node.

[0186] If path verification fails (e.g., source file does not exist, target directory not created), the operation will terminate and an error message will be returned; if verification passes, proceed to the next step.

[0187] Atomic operation pre-configuration: The client enables the atomicity guarantee mechanism of the Linux rename interface, sets the operation timeout (default 500ms), and disables non-atomic modes such as "partial move" and "breakpoint resume" to ensure that the operation is either fully executed or completely rolled back without intermediate state;

[0188] S32: Initiation and execution of atomic rename operations:

[0189] S321: Establish a dedicated communication channel with the target MDS:

[0190] The client queries the locally cached "MDSindex-node address" mapping table based on MDS_Index_Target to obtain the IP address, communication port and protocol type of the target MDS node;

[0191] Initiate a TCP connection request to establish a dedicated communication channel between the client and the target MDS. The channel enables data encryption and verification mechanisms to prevent data from being tampered with or leaked during transmission.

[0192] The target MDS node verifies the client's identity using the client session ID and signature information. Once it confirms that the client has permission to operate the recycle bin directory, it establishes a connection and returns a "ready" response.

[0193] S322: Construct and send a rename atomic operation request:

[0194] The client constructs a rename operation request packet according to the Linux file system standard protocol (conforming to the POSIX specification). The core fields of the packet body include:

[0195] Operation type: ATOMIC_RENAME (atomic rename / move);

[0196] Source path (oldpath): The absolute path to the target file to be deleted;

[0197] Target path (newpath): The target path under the Recycle Bin directory;

[0198] Operation Identifier: A globally unique operation ID (such as UUID) used for operation tracking and idempotency control;

[0199] Atomicity requirement: Marked as "uninterruptible and indivisible", the target MDS is required to return only "success" or "failure" results, with no intermediate responses.

[0200] The client performs integrity verification on the request packet (generates an MD5 checksum and appends it to the end of the packet), and sends it to the target MDS node through a dedicated communication channel;

[0201] The client starts a timeout timer. If no response is received after the preset timeout period (500ms), a retransmission is automatically initiated (up to 2 retransmissions). If there is still no response after retransmission, the operation is considered to have failed, and the exception handling process is triggered.

[0202] S323: The target MDS performs an atomic move operation.

[0203] Request packet verification and parsing: After receiving the request packet, the target MDS first verifies the integrity of the packet body (compares the MD5 checksum) and the client permissions (rechecks the directory ACL). If the verification fails, an "illegal request" response is returned, and the operation is terminated; if the verification passes, the source path, target path and operation identifier in the request packet are parsed.

[0204] Source file and target directory metadata verification:

[0205] The target MDS queries the local metadata storage engine to confirm that the file metadata corresponding to the source path exists (inode number, MDS index, and file status are consistent with the request), and the file status is "unlocked and movable".

[0206] Confirm that the metadata of the recycle bin directory corresponding to the target path exists (the directory inode number, the MDS index to which it belongs, and the MDS_Index_Target are consistent), and that the directory has "write" permissions and sufficient remaining storage space (to accommodate the source file).

[0207] If metadata verification fails (e.g., the file has been deleted or there is insufficient directory space), an "Operation failed" response is returned, and the client terminates the process.

[0208] Perform atomic moves and metadata updates:

[0209] The target MDS calls the rename atomic interface of the local file system kernel layer to perform a file move operation: it only modifies the file's path association metadata, switches the file's parent directory pointer from the original parent directory to the recycle bin directory, and does not move the actual data blocks of the file, that is, the physical storage location of the data blocks remains unchanged.

[0210] Synchronously update the metadata storage engine:

[0211] Original parent directory metadata: Delete the file association record and update statistics such as the number of files and space occupied in the directory;

[0212] Recycle Bin Directory Metadata: Add a new associated record for this file, and update statistics such as the number of files in the directory and the space occupied;

[0213] File metadata: Update the file's parent directory inode number and absolute path information, while keeping core information such as the file inode number and data block pointers unchanged;

[0214] The aforementioned metadata update operations are encapsulated through a "transaction" mechanism to ensure that all metadata modifications either succeed simultaneously or are rolled back simultaneously. If a node failure occurs during the update process, the incomplete metadata modifications will be automatically undone after restarting.

[0215] Operation result confirmation: If both file movement and metadata update are completed without any abnormalities, the target MDS marks the operation status as "successful"; if any errors occur during the process, such as disk I / O abnormalities or metadata write failures, the rollback mechanism is immediately triggered to restore the original metadata state, and the operation status is marked as "failed".

[0216] S33: Operation result feedback and status synchronization:

[0217] Result Response Sending: The target MDS constructs an operation result response packet, which includes the operation identifier, status (success / failure), and response timestamp. After encryption, it is returned to the client through a dedicated communication channel.

[0218] Client-side result processing:

[0219] After receiving the response packet, the client decrypts and verifies its integrity, confirming that the operation identifier is consistent with that used when it was initiated.

[0220] If the status is "successful": update the local cache, including deleting the source file path cache, adding the target path cache, recording the operation log, including the operation ID, source path, target path, execution time, and result, and triggering a callback notification of "file moved to recycle bin successfully";

[0221] If the status is "failed": retain the source file path cache, return an operation failure message, and allow the user to retry or perform the normal deletion process.

[0222] Cluster status synchronization: The target MDS synchronizes the operation results to the cluster configuration center and standby MDS nodes, updates the path information of the file in the global directory tree, ensures that all nodes in the cluster have a consistent understanding of the file location, and avoids subsequent operation conflicts.

[0223] The specific process in step S4 is as follows:

[0224] S41: Parse the recycle bin path and extract the core inode number:

[0225] S411: Recycle Bin Path Standardization: When a client receives a file recovery request, it first obtains the complete path of the target file in the recycle bin:

[0226] For example, for ` / global / recycle / 123456 / file.txt`, perform path standardization—remove redundant identifiers (such as `. / ..`) from the path, split the path components into `["global","recycle","123456","file.txt"]`, and clarify the meaning of each directory level:

[0227] global / recycle: The global, unified root recycle bin directory (fixed prefix);

[0228] 123456: The inode number of the original parent directory of the target file (core extraction item);

[0229] file.txt: The target filename to be recovered;

[0230] S412: Extract the original parent directory inode number:

[0231] From the split path components, accurately extract the first-level subdirectory name (i.e., 123456) under the root recycle bin directory. This value is the "original direct parent directory inode number of the target file" recorded in step S1, and serves as the starting anchor point for path restoration.

[0232] S413: Path validity check:

[0233] Verify the format of the extracted inode number; if the format is invalid, return "path resolution failed" directly. At the same time, confirm that the directory metadata corresponding to the inode number has been registered in the MDS node (lightweight query local cache) to avoid invalid tracing.

[0234] S42: Iteratively query metadata to trace the complete original path;

[0235] S421: Initialize traceability parameters:

[0236] Define core traceability variables:

[0237] current_inode: The inode number to be queried. The initial value is the original direct parent directory inode to be extracted, such as 123456.

[0238] path_components: A list of path components, initially empty, used to store the names of directories at each level obtained through iteration;

[0239] stop_flag: Termination flag, initially False (set to True when traversing to the root directory).

[0240] Locate the MDS node to which the user belongs:

[0241] Based on the current_inode, the MDS index number to which the inode belongs is calculated through cluster routing rules (hash mapping / consistent hashing consistent with step S1), and an encrypted communication channel is established with the target MDS node to ensure that metadata queries are executed in a targeted manner.

[0242] S422: Iterate through the parent inodes and concatenate the path:

[0243] Initial query (direct parent directory):

[0244] Send a metadata query request to the target MDS, passing in current_inode=123456, to retrieve the metadata corresponding to that inode:

[0245] Core fields: current directory name (e.g., docs), parent directory inode (e.g., 789012, corresponding to the / user directory);

[0246] Add docs to path_components and update current_inode=789012.

[0247] Secondary query (parent directory):

[0248] Relocate the MDS node to which 789012 belongs. If it is consistent with the original MDS, reuse the channel; otherwise, switch it. Query its metadata:

[0249] Core fields: current directory name (e.g., user), parent directory inode (e.g., 1, root directory inode);

[0250] Add user to path_components. Since the parent inode is the root directory identifier, set stop_flag=True to terminate the iteration.

[0251] Iteration termination condition: When the queried parent_inode is a fixed inode of the file system root directory (usually 0 or 1), or when parent_inode is empty (no parent directory), the iteration is terminated immediately to avoid infinite loop.

[0252] S423: Concatenate and verify the original complete path:

[0253] Path component reversal and concatenation: Reverse the path_components list, such as reversing ["docs","user"] obtained from iteration to ["user","docs"], and concatenating them with the path separator / to obtain the absolute path of the original parent directory: / user / docs;

[0254] Based on the filename to be recovered, the original full path of the file is obtained: / user / docs / file.txt.

[0255] Path validity verification: Send a path verification request to the MDS belonging to the original parent directory to verify:

[0256] Does the directory corresponding to this path exist? A metadata query confirms that the inode for / user / docs is still valid.

[0257] Does the current user have write permissions for this path?

[0258] If the path does not exist, it is marked as "path invalid", and the "restore to the specified new directory" logic is triggered subsequently; if the path exists and permissions are sufficient, the original path is confirmed to be valid.

[0259] S43: Path caching optimization and exception handling:

[0260] Path caching optimization:

[0261] The restored original complete path is bound to the corresponding recycle bin path and cached locally on the client. If the same file is restored again in the future, the cached path can be reused directly, reducing the overhead of repeated iterative queries.

[0262] Exception handling mechanism:

[0263] Metadata query failed: If the metadata of a certain level inode does not exist, such as if the original directory has been completely deleted, the "longest available original path" will be concatenated based on the traced valid inode. For example, if only / user is traced, the path will be / user, and the user will be prompted whether to restore to this path or a custom path.

[0264] Cross-MDS tracing anomaly: If the MDS node to which a certain level inode belongs goes offline during the iteration process, the failover mechanism is triggered, and the query is switched to the backup node of the MDS to continue.

[0265] Path circular reference: If a duplicate current_inode occurs during iteration, such as a directory symbolic link causing a loop, the iteration will be terminated immediately, "Path error" will be returned, and manual intervention will be prompted.

Claims

1. A method for optimizing the performance of a distributed file system recycle bin, characterized in that, Includes the following steps: S1: During the execution of the unlink standard processing interface of the Linux file system, it sequentially determines whether the directory where the file is located has the recycle bin function enabled, whether the file can be deleted, and whether the file needs to be put into the recycle bin. It obtains the metadata of the parent directory of the target file to be deleted from the server through the file path, including the inode number of the parent directory. S2: When the file system is created, a globally unified root recycle bin directory for storing all deleted files is generated synchronously; when a file deletion operation is detected, a directory creation request is sent to the target MDS with the parent directory inode number as the directory name and the index number of the MDS to which the parent directory metadata belongs as the orientation parameter. S3: The client initiates an atomic move operation based on the Linux file system standard rename interface, directly moving the target deleted file to the recycle bin directory; S4: When a file recovery operation is initiated, based on the path of the target file in the recycle bin, the parent directory name, i.e. the parent directory inode number, is extracted from the path. The corresponding metadata is queried through the inode number, and then the inode number of the parent directory is obtained. The complete path from the original directory to the root directory is obtained by iterative traversal. S5: Get the original directory of the deleted file. If the original directory path does not exist or needs to be restored to a specified new directory, initiate the rename atomic operation to move the corresponding directory in the recycle bin to the target location. If the original directory path exists, repeat step S4 for each file in the directory.

2. The method for optimizing the performance of a distributed file system recycle bin according to claim 1, characterized in that, The specific process of determining whether the recycle bin function is enabled in the directory where the file is located, whether the file can be deleted, and whether the file needs to be moved to the recycle bin in step S1 is as follows: S11: Determine whether the recycle bin function is enabled in the directory where the file is located by querying and configuring directory metadata; S12: Confirm whether the file is allowed to be deleted by verifying permissions, detecting file occupancy status, and detecting locked status; S13: Confirm whether the files need to be included in the recycle bin management by detecting critical system files and matching storage policies; S14: Output the final judgment result: If the system critical file detection, lock status detection and storage policy matching detection pass the system critical file detection, and the judgment is "the file needs to be put into the recycle bin", proceed to the subsequent recycle bin directory creation and file moving process; If any check fails, the recycle bin process is terminated, and the file is deleted according to the normal unlink logic.

3. The method for optimizing the performance of a distributed file system recycle bin according to claim 2, characterized in that, The specific process of step S12 is as follows: S121: Obtain the user account and user group that initiated the unlink operation, query the permission control list of the target file, and confirm whether the user has deletion permission; S122: Determine the file occupancy status by checking if the file's reference count is 0. 0 indicates that the file is not occupied, and 1 indicates that it is occupied by the system or application. If there is no occupancy, proceed to the verification in S123. S123: Check if the file has a special attribute that prevents deletion. If so, it is determined to be undeletable regardless of permissions. If the attribute is not set and the file passes the permission and occupancy checks, it is determined to be undeletable, and the next step is performed.

4. The method for optimizing the performance of a distributed file system recycle bin according to claim 2, characterized in that, The specific process of obtaining the metadata of the parent directory of the target deleted file from the server via the file path in step S1 is as follows: S15: Parse file paths and locate parent directories, including file path standardization, extracting parent directory paths, and generating parent directory path check codes; S16: Route to the target MDS and query metadata; S17: The target MDS performs integrity verification on the metadata. After the verification is successful, the target MDS uses the node's private key to digitally sign the metadata. Then, it encapsulates the signed metadata, signature information, and response timestamp into a response packet and returns it to the client.

5. The method for optimizing the performance of a distributed file system recycle bin according to claim 4, characterized in that, The specific process of step S16 is as follows: S161: Locate the MDS node responsible for the parent directory through path routing; S162: Initiate a parent directory metadata query request to the target MDS; S163: Target MDS performs metadata query.

6. The method for optimizing the performance of a distributed file system recycle bin according to claim 1, characterized in that, The specific process of synchronously generating a globally unified root recycle bin directory to store all deleted files during file system creation in step S2 is as follows: S21: Preset configuration of root recycle bin directory parameters, including directory path, directory identifier, MDS node policy, and storage quota limit; S22: Creation and registration of the root recycle bin directory, including cluster initialization coordination, determination of the root directory master management MDS, execution of root directory initialization creation by the master MDS node, synchronization and consistency verification of master and slave node metadata, and registration of full cluster directory reachability. S23: Permission Configuration and Function Activation: This includes permission policy binding, storage policy activation, function availability verification, and creation result feedback.

7. The method for optimizing the performance of a distributed file system recycle bin according to claim 1, characterized in that, The specific process of step S3 is as follows: S31: The client summarizes the key data from the preceding steps, clarifies the core parameters of the rename operation, including the source path, target path, target MDS index, and performs atomic operation pre-configuration; S32: Initiation and execution of atomic rename operations; S33: The result feedback and status synchronization of the atomic rename operation.

8. The method for optimizing the performance of a distributed file system recycle bin according to claim 7, characterized in that, The specific process of step S32 is as follows: S321: Establish a dedicated communication channel with the target MDS; S322: Construct and send a rename atomic operation request; S323: The target MDS performs an atomic move operation.

9. A method for optimizing the performance of a distributed file system recycle bin according to claim 1, characterized in that, The specific process in step S4 is as follows: S41: Parse the recycle bin path and extract the core inode number: When the client receives a file recovery request, it obtains the complete path of the target file in the recycle bin and extracts the original parent directory inode number; S42: Iteratively query metadata to trace the complete original path; S43: Bind the restored original complete path to the corresponding recycle bin path and cache it locally on the client. If the same file is restored again in the future, the cached path can be reused directly, reducing the overhead of repeated iteration queries.

10. A method for optimizing the performance of a distributed file system recycle bin according to claim 9, characterized in that, The specific process of step S42 is as follows: S421: Initialize traceability parameters: including the current inode number to be queried, the list of path components, the termination identifier, and the location of the MDS node to which it belongs; S422: Iterate through the parent inodes and concatenate the path: S423: Perform concatenation and verify the original complete path.

Images