Storage object recovery method, electronic equipment and storage medium

Abstract

The invention relates to the technical field of distributed storage systems, and provides a storage object recovery method, electronic equipment and a storage medium, and the method comprises the following steps: receiving a deletion request for a target object sent by a client; in response to the deletion request, judging whether a recycle bin function of a path where the target object is located is enabled or not, if so, intercepting the deletion request, and converting the deletion request into a renaming operation pointing to a preset recycle bin directory; synchronously marking the metadata of the target object as a deleted state based on the renaming operation, and returning response information for the deletion request to the client; and generating an asynchronous task, and moving the target object into the recycle bin directory through the asynchronous task. According to the method, the opening state of the recycle bin is flexibly judged according to the path, and in combination with the processing mechanism of the server transparent interception request, the synchronous marking metadata and the asynchronous mobile data, efficient data recycling which is low in storage cost, free of client upgrading and free of blocking is achieved.

Description

Technical Field

[0001] This invention relates to the field of distributed storage system technology, and in particular to a method for recycling storage objects, an electronic device, and a storage medium. Background Technology

[0002] With the development of cloud computing and big data technologies, distributed storage systems are widely used to provide highly available and scalable shared storage services. In the daily use of distributed file storage, accidental deletion of files or directories is a common and serious problem that significantly impacts data security.

[0003] Currently, several methods are commonly used to address the issue of accidental file or directory deletion. For example, some existing technologies attempt to avoid accidental deletion by configuring fine-grained access permissions for mounted users. However, this approach relies heavily on client settings. When different users access file storage using the same machine or the same mounted account, user-based access control may fail, making it impossible to truly prevent accidental deletion.

[0004] For example, some distributed systems provide a global file recycle bin. However, this approach has several problems in practical applications. First, a global recycle bin lacks flexibility; once enabled, it blocks all deletion operations, forcibly retaining a large amount of temporary or non-critical data, resulting in significant waste of storage space and increased storage costs. Manual cleanup of the recycle bin may be necessary later to reduce actual storage space usage. Second, most existing distributed storage systems require simultaneous client upgrades to support the recycle bin functionality, leading to extremely high client upgrade and maintenance costs. Furthermore, some systems use a mechanism to synchronously move data during deletion operations, which can severely disrupt normal user operations in scenarios involving the deletion of large numbers of files or directories, causing overall system slowdown and negatively impacting user experience. Summary of the Invention

[0005] This invention provides a storage object recycling method, electronic device, and storage medium to address the shortcomings of existing distributed storage system recycling solutions, such as high storage costs, excessive client upgrade and maintenance costs, and severe obstruction of user operations.

[0006] This invention provides a method for recycling storage objects, comprising: Receive a deletion request from a client for a target object, wherein the target object includes at least one of a file or a directory; In response to the deletion request, it is determined whether the recycle bin function is enabled in the path where the target object is located. If the recycle bin function is enabled, the deletion request is intercepted and the deletion request is converted into a renaming operation pointing to a preset recycle bin directory. Based on the renaming operation, the metadata of the target object is synchronously marked as deleted, and response information for the deletion request is returned to the client. An asynchronous task is generated, and the target object is moved to the recycle bin directory through the asynchronous task.

[0007] According to a storage object recycling method provided by the present invention, after the step of moving the target object to the recycle bin directory via the asynchronous task, the method further includes: If it is determined that the target object has been successfully moved to the recycle bin directory, delete the metadata corresponding to the target object in its original path.

[0008] According to a storage object recycling method provided by the present invention, the recycling bin directory includes a dedicated directory independently allocated to each metadata server instance, and the dedicated directory is divided into subdirectories according to date; Moving the target object to the recycle bin directory via the asynchronous task includes: Extract the parent node index information, the self node index information, and the original name of the target object; The parent node index information, the self node index information, and the original name are concatenated according to a preset format to generate a new name for the target object in the recycle bin directory; Determine the corresponding target-specific directory and the target date corresponding to when the metadata of the target object is marked as deleted, and store the target object named according to the new name in the subdirectory under the target-specific directory corresponding to the target date.

[0009] A method for recycling storage objects according to the present invention further includes: Receive recovery instructions and parse the recovery parameters carried in the recovery instructions to determine the recovery type and target recovery path; According to the recovery type, retrieve the objects to be recovered from the recycle bin directory, and summarize the retrieved objects to be recovered to generate a list of objects to be recovered; For each object in the list of objects to be recovered, parse the new name of each object in the recycle bin directory to obtain the parent node index information and the self node index information corresponding to each object; Using the target recovery path as the root directory, the original data directory structure of each object to be recovered is reconstructed based on the parent node index information and the self node index information; Each object in the list of objects to be restored is restored to the reconstructed data directory structure.

[0010] According to a storage object recycling method provided by the present invention, the step of obtaining the object to be recovered from the recycle bin directory according to the recovery type includes: When the recovery type is path-based recovery, the object to be recovered is found in the recycle bin directory that matches the specified path carried in the recovery instruction. If the recovery type is recovery by date, locate the subdirectory in the recycle bin directory that matches the specified date carried in the recovery instruction, and retrieve the object to be recovered from the subdirectory; When the recovery type is recovery by mode, the object to be recovered is obtained by matching the wildcard carried in the recovery instruction in the recycle bin directory.

[0011] According to a storage object reclamation method provided by the present invention, the step of restoring each object to be recovered in the list of objects to be recovered to the reconstructed data directory structure includes: Detect whether there is an object with the same name as any object to be recovered in the reconstructed data directory structure; If it exists, create an object with a different name at the specified location of the target recovery path to recover any of the objects to be recovered, and output an exception report after the recovery operation is completed; If it does not exist, then the original name of any object to be recovered is used to restore any object to be recovered to the data directory structure.

[0012] A method for recycling storage objects according to the present invention further includes: The background thread periodically scans each subdirectory under the recycle bin directory; Calculate the data retention time for each subdirectory and check whether the data retention time exceeds the preset retention period; If the data retention time corresponding to any subdirectory exceeds the preset retention period, the subdirectory is determined to be an expired subdirectory and marked as pending deletion. Batch delete and release storage space for each expired subdirectory that is in a pending deletion state and the data contained within each expired subdirectory.

[0013] According to a storage object recycling method provided by the present invention, the step of moving the target object to the recycle bin directory through the asynchronous task includes: Obtain the target storage pool associated with the recycle bin directory, wherein the storage medium cost of the target storage pool is lower than the storage medium cost of the original storage pool where the target object is located; The asynchronous task moves the target object from the original storage pool to the recycle bin directory in the target storage pool.

[0014] A method for recycling storage objects according to the present invention further includes: Receive a rename request for any object sent by the client; The target path and source path corresponding to the rename request are verified; If the target path is the recycle bin directory, or the source path is located within the recycle bin directory, the rename request is rejected and an error message is returned to the client.

[0015] According to a storage object recycling method provided by the present invention, after the step of determining whether the path where the target object is located has the recycle bin function enabled, the method further includes: If the recycle bin function is not enabled, the deletion request is executed directly to delete the target object, and the processing result corresponding to the deletion request is returned to the client.

[0016] The present invention also provides a storage object recycling device, comprising: A request receiving unit is used to receive a deletion request for a target object sent by a client, wherein the target object includes at least one of a file or a directory; The request interception unit is used to respond to the deletion request, determine whether the recycle bin function is enabled in the path where the target object is located, and if the recycle bin function is enabled, intercept the deletion request and convert the deletion request into a renaming operation pointing to a preset recycle bin directory; A synchronization marking unit is used to synchronously mark the metadata of the target object as deleted based on the renaming operation, and return response information for the deletion request to the client; An asynchronous movement unit is used to generate an asynchronous task and move the target object to the recycle bin directory through the asynchronous task.

[0017] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the storage object recycling method as described above.

[0018] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the storage object reclamation method as described above.

[0019] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the storage object reclamation method as described above.

[0020] The storage object recycling method, electronic device, storage medium, and program product provided by this invention, upon receiving a deletion request from a client, determines whether the recycle bin function is enabled on the path containing the target object. This breaks the limitation of the traditional global recycle bin forcibly retaining all data, enabling fine-grained control to flexibly enable anti-accidental deletion protection on demand for specific directory paths. This effectively avoids a large amount of unprotected temporary data occupying space, significantly reducing storage costs. After confirming that the recycle bin function is enabled, this invention directly intercepts the deletion request at the underlying level and converts it into a rename operation. This mechanism is completely transparent to the upper-layer client, requiring no synchronous upgrade of the client software, significantly reducing client operation and maintenance costs and compatibility risks. Furthermore, this invention employs a processing mechanism combining synchronous metadata marking and asynchronous actual data movement. During the synchronization phase, the system only needs to lightweightly mark the metadata as deleted and immediately return response information to the client, ensuring the user receives rapid deletion operation feedback. In the background, the system generates asynchronous tasks to perform the time-consuming operation of migrating the target object to the recycle bin directory. This front-end and back-end decoupling design solves the serious blocking problem caused by the traditional synchronous data movement mechanism when deleting a large number of files, effectively ensuring the overall high-efficiency response speed and concurrent processing performance of the distributed storage system. Attached Figure Description

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

[0022] Figure 1 This is a flowchart illustrating the storage object reclamation method provided by the present invention; Figure 2 This is a schematic diagram of the process for deleting a storage object provided by the present invention; Figure 3 This is a schematic diagram of the structure of the recycling bin catalog provided by the present invention; Figure 4 This is a schematic diagram of the process for restoring a stored object provided by the present invention; Figure 5 This is a schematic diagram of the process for cleaning up recycle bin objects provided by the present invention; Figure 6 This is a schematic diagram of the storage object recycling device provided by the present invention; Figure 7 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0024] To facilitate understanding of the technical solutions provided by this invention, some key terms involved in this invention will first be explained.

[0025] Ceph File System (CephFS) is a distributed file system that provides highly available and scalable shared file storage services.

[0026] The Metadata Server (MDS) is responsible for managing the file metadata of CephFS.

[0027] unlink is a Linux system call used to delete files.

[0028] rmdir is a Linux system call used to delete empty directories.

[0029] `rename` is a Linux system call used to rename or move files or directories.

[0030] An inode is a structure in a file system that describes file metadata, including information such as permissions, size, and location.

[0031] A data storage pool is a logical storage unit in Ceph used to define data redundancy strategies and storage media.

[0032] Asynchronous operation refers to a non-blocking processing method that responds to requests first and then executes time-consuming tasks.

[0033] Metadata refers to data that describes data, such as filenames, file sizes, timestamps, etc.

[0034] With the rapid development of technologies such as cloud computing, big data, and artificial intelligence, distributed storage systems play a crucial role in providing highly available and scalable shared storage services for massive amounts of data. Ceph File System (CephFS), as a widely used distributed file system, provides stable and reliable storage services for massive amounts of data. However, in the daily use cases of distributed file storage, accidental deletion of files or directories is a relatively frequent and impactful security risk. To ensure the security of files and directories, the industry typically employs a recycle bin mechanism for data protection.

[0035] Currently, existing distributed storage systems (such as CephFS and JuiceFS in the industry) mainly have the following solutions for preventing accidental deletion and implementing a recycle bin, but all of them have certain defects.

[0036] The first approach is a client-side permission configuration-based mechanism to prevent accidental deletion. The official CephFS architecture does not directly implement the function to recover accidentally deleted files or directories. This necessitates that users employ additional restrictions when using CephFS storage to prevent accidental deletion. For example, fine-grained access permissions can be configured for mounting users (such as restricting read and write permissions for specific directories) to minimize the risk of accidental deletion. Specifically, different users with different permissions are used to mount and access CephFS for different clients. When designing the data directory structure, different permissions need to be configured for different users and associated with corresponding data storage directories. For instance, in the permission allocation below, UserA only has write permissions for the directory / User / A and read permissions for other directories, while UserB only has write permissions for the directory / User / B and read permissions for other directories. However, since this is client-side configuration, all users logged into the file storage mounted using UserA will have write permissions for / User / A. This can lead to accidental deletion when different users are using the same machine, a situation that the existing CephFS architecture does not provide a solution for, meaning it cannot prevent accidental deletion.

[0037] The second approach is based on a global recycle bin mechanism that utilizes special processing on the Metadata Server (MDS) side or collaboration between the client and metadata. For example, the community-provided CephFS recycle bin solution directly migrates files and directories to be deleted to a global recycle bin directory on the MDS side. Another example is JuiceFS, which, through collaboration between the client and metadata service, stores data in a specific directory that is accessible to the client. Users can directly manipulate the data in this directory using commands such as `ls` (list directory contents) and `mv` (move). Here, the data refers to the recycled files or empty directories within that specific directory. However, these existing technologies have several drawbacks, specifically as follows: First, a global recycle bin leads to a sharp increase in storage costs and poor flexibility. Most existing recycle bin implementations in the industry are global. However, in distributed storage scenarios, there are often a large amount of temporary or non-critical data that does not require protection. Enabling a global recycle bin means that the deletion of any file or directory will trigger copying or migration, resulting in high costs for distributed storage. Furthermore, manual intervention is usually required to clean up the data (also known as objects, i.e., files or empty directories) in the recycle bin to free up storage space.

[0038] Secondly, there is a lack of data management and cleanup strategies for the recycle bin. Most current solutions lack a systematic data management strategy. On the one hand, due to the simple directory structure of the recycle bin, it is impossible to quickly retrieve and locate a list of mistakenly deleted files by a specific date or attribute, resulting in low data recovery efficiency. On the other hand, there is a lack of automated cleanup mechanisms based on retention periods, usually requiring manual periodic cleanup. Furthermore, existing solutions cannot achieve tiered data management based on storage media costs. Theoretically, data entering the recycle bin could be stored on lower-performance and lower-cost storage devices, such as hard disk drives (HDDs), to save costs. However, current technology still mixes it with the original data, such as data on solid-state drives (SSDs) or non-volatile memory express (NVME), resulting in a serious waste of high-performance hardware costs.

[0039] Secondly, client upgrades and maintenance costs are high. In many existing distributed storage systems, supporting or integrating recycle bin functionality usually requires synchronous upgrades to the client software. This introduces the issue of maintenance costs for client upgrades, which can be enormous for business systems with numerous clients.

[0040] Furthermore, the asynchronous processing mechanism is inadequate. Some existing CephFS recycle bin alternatives use synchronous data movement when handling deletion requests. In scenarios involving large-scale file deletions, this approach severely blocks normal user operations, significantly impacting system input / output (I / O) response speed and concurrent processing capabilities, posing serious security and performance risks. Simultaneously, allowing users to directly manipulate recycle bin directory data using commands like `mv` easily corrupts the internal file structure of the recycle bin, compromising data consistency and management security.

[0041] To address this, the present invention provides a storage object reclamation method. By intercepting and transforming deletion requests on the metadata server side, and combining a mechanism of synchronously marking metadata and asynchronously moving data, a storage object reclamation scheme is provided that can be flexibly started by directory, supports asynchronous low-cost processing, and is transparently compatible with all clients, thereby overcoming the above-mentioned defects.

[0042] It should be noted that the method provided in this embodiment of the invention can be applied to distributed storage systems (such as CephFS). CephFS is widely used in scenarios such as cloud computing, big data, and artificial intelligence, and can provide highly available and scalable shared storage services for multiple terminals. The execution entity of the method of this invention is the core component in the system, namely the metadata server (MDS), which is mainly responsible for managing the metadata structure and directory tree of the file system and controlling the access permissions of clients.

[0043] The technical solution provided by this invention will be described in detail below. It should be understood that all actions involving the acquisition of instructions, information, or data in this invention are carried out in accordance with the relevant data protection laws and policies of the country where the invention is located, and with authorization from the owner of the relevant device.

[0044] Figure 1 This is a flowchart illustrating the storage object reclamation method provided by the present invention, as shown below. Figure 1 As shown, the method includes: Step 110: Receive a deletion request for a target object sent by the client, wherein the target object includes at least one of a file or a directory.

[0045] Specifically, in real-world business scenarios, due to the large number of clients and overlapping access permissions (e.g., multiple users accessing the same machine), accidental data deletion is highly likely. To provide an efficient and low-cost fallback solution for preventing accidental deletion, the metadata server of this invention first receives deletion requests from clients targeting specific objects, which can be files or directories.

[0046] It is understood that the aforementioned clients cover terminals with various mounting methods, such as user-mode clients or kernel-mode clients. Since the core logic of the method provided in this embodiment is implemented on the server side, it is fully compatible with existing and historical versions of various clients without requiring any modification or upgrade of the client software.

[0047] The received deletion request will have different underlying system call forms depending on the type of the target object. For example, when the client is a Linux user-space client or a kernel-space client, if the target object is a file, the client will usually initiate a file deletion request by calling the unlink command; if the target object is an empty directory, the client will usually initiate a directory deletion request by calling the rmdir command.

[0048] Step 120: In response to the deletion request, determine whether the recycle bin function is enabled in the path where the target object is located. If the recycle bin function is enabled, intercept the deletion request and convert the deletion request into a renaming operation pointing to a preset recycle bin directory.

[0049] Specifically, upon receiving a deletion request from a client, the metadata server responds by first determining whether the recycle bin is enabled on the path containing the target object. Unlike the industry-standard global recycle bin (which affects all files in the system once enabled), this invention supports fine-grained directory-level recycle bin enabling. Only deletions within specified directories will enter the recycle bin, thus avoiding the storage space waste associated with a global recycle bin. In distributed storage scenarios, there is often a large amount of temporary data. Using a global recycle bin would lead to a significant increase in storage costs and cumbersome subsequent cleanup. Through the path determination mechanism, the system can perform recycling protection only on specific directories configured with important data.

[0050] If the path containing the target object does not have a recycle bin enabled, the system will directly perform the deletion operation according to the normal procedure, delete the target object, and return the processing result to the client. If the path containing the target object has a recycle bin enabled, the system will intercept the received deletion request on the MDS side to prevent it from actually deleting the data, and further convert the intercepted deletion request into a renaming operation pointing to the preset recycle bin directory.

[0051] Specifically, MDS inserts interception logic into its request processing layer (e.g., in the Server::handle_client_request method) and implicitly replaces the original delete operation with a rename operation by identifying the request's op operation type. The rename operation here specifically refers to a system call used to modify the name of a file or directory, or to move a file or directory from one storage path to another. For example, this can be achieved by calling the Linux system's rename command. The essence of renaming is to change the link relationship of the target object in the file system directory tree, removing it from its original parent directory node and remounting it to a preset recycle bin directory. This forces the logical flow of the target object to be directed to a pre-reserved recycle bin directory within the system (e.g., a special directory named .trash), thereby achieving the interception and protection of valid data. It should be understood that in this embodiment of the invention, by intercepting and converting requests on the MDS side, no modification to the client software is required, ensuring compatibility with multiple clients and greatly reducing the system's operation, maintenance, and upgrade deployment costs.

[0052] Step 130: Based on the renaming operation, synchronously mark the metadata of the target object as deleted and return response information for the deletion request to the client.

[0053] Specifically, after the system converts the deletion request into a rename operation pointing to the recycle bin directory, it does not immediately perform a time-consuming data move or a complete rename directory tree update on the front end. Instead, based on the execution intent of the rename operation, the system synchronously marks the target object's metadata as deleted. Here, metadata refers to information describing data attributes, such as filename, file size, creation or modification timestamps, and inode information. Marking it as deleted logically simulates the original deletion process, making the client believe that the deletion operation has been completed.

[0054] Once the marking is complete, the system immediately returns a response to the client regarding the deletion request, such as a message indicating successful deletion. This synchronous marking and immediate response mechanism ensures that the deletion operation perceived by the user on the front end is very fast, without being blocked by background data movement, thus significantly improving the system's response speed, especially in scenarios involving a large number of deletion requests.

[0055] Understandably, the renaming operation determines the final destination of the target object (i.e., the preset recycle bin directory), while synchronizing metadata markers makes the target object invisible to the original path without actual data migration, thus simulating the effect of the original deletion process. In other words, the system uses changes in metadata marker status to hide the target object from the user, making the client believe that the deletion operation is complete, and then immediately sends a response message to the client regarding the deletion request (such as a message returning a success message). This mechanism, based on the renaming intent but only synchronizing the metadata marker status, decouples the rapid response of the front end from the actual data migration in the back end, avoiding blocking user requests due to directly synchronizing renaming or moving large amounts of data.

[0056] Step 140: Generate an asynchronous task and move the target object to the recycle bin directory through the asynchronous task.

[0057] Specifically, to avoid the massive data migration process blocking the user interface, the system employs a non-blocking asynchronous processing mechanism. Specifically, while returning a response to the client, the system generates asynchronous tasks in the background. Here, an asynchronous task refers to a non-blocking task processing method that allows the system to quickly respond to user requests and then slowly execute time-consuming tasks in the background. In other words, the actual data migration work is placed in the background. The system gradually moves the target object (the data itself in a file or empty directory) to the designated recycle bin directory through asynchronous tasks (such as background asynchronous threads), thereby completing the entire object recycling process. It should be understood that through this mechanism combining synchronous mark-and-delete and asynchronous data movement, this embodiment of the invention effectively places the time-consuming data migration process in the background, further ensuring the smoothness of front-end user operations.

[0058] The method provided in this invention, upon receiving a deletion request from a client, determines whether the target object's path has a recycle bin enabled. This breaks the traditional limitation of a global recycle bin forcibly retaining all data, enabling fine-grained control to flexibly enable anti-accidental deletion protection for specific directory paths as needed. This effectively avoids a large amount of unprotected temporary data occupying space, significantly reducing storage costs. After confirming the recycle bin is enabled, this invention directly intercepts the deletion request at the underlying level and converts it into a rename operation. This mechanism is completely transparent to the upper-layer client, requiring no synchronous upgrades to the client software, significantly reducing client maintenance costs and compatibility risks. Furthermore, this invention employs a processing mechanism combining synchronous metadata marking and asynchronous actual data movement. During the synchronization phase, the system only needs to lightweightly mark the metadata as deleted and immediately return response information to the client, ensuring the user receives rapid deletion operation feedback. In the background, the system generates asynchronous tasks to perform the time-consuming operation of migrating the target object to the recycle bin directory. This decoupled front-end and back-end design solves the serious blocking problem caused by traditional synchronous data movement mechanisms when deleting a large number of files, effectively ensuring the overall high-efficiency response speed and concurrent processing performance of the distributed storage system.

[0059] Based on the above embodiments, since the present invention employs synchronous marker deletion and asynchronous data movement, the actual physical migration of data is completed in the background over a time-consuming process. Therefore, after step 140, the method further includes: If it is determined that the target object has been successfully moved to the recycle bin directory, delete the metadata corresponding to the target object in its original path.

[0060] Specifically, when the background asynchronous thread takes over and executes the data migration task, the system continuously monitors the transfer status of the target object (i.e., the file or empty directory itself). Once it is confirmed that the data of the target object has been completely and correctly migrated to the designated recycle bin directory, the metadata server will trigger standard data metadata cleanup behavior, and actually destroy and release the original path metadata (including its inode in the original directory tree, permission information, etc.) marked as deleted.

[0061] The method provided in this invention deletes metadata in the original path only after confirming that the underlying data has been safely and completely transferred to the recycle bin. This mechanism of moving first and then deleting not only effectively avoids the risk of complete data loss due to sudden system crashes or network interruptions during asynchronous migration, but also ensures the timely release of metadata server cache and storage resources.

[0062] Based on any of the above embodiments Figure 2 This is a schematic diagram of the storage object deletion process provided by the present invention, such as... Figure 2As shown, MDS inserts interception logic into its `Server::handle_client_request` method. When it receives a client request from the front end, it first determines the request type, which can be achieved by identifying the operation type of the request. If the request is identified as a regular read, write, or create request, the system will process it normally using existing file system logic and will not trigger the interception mechanism of this application. If the operation type of the request is identified as `CEPH_MDS_OP_UNLINK` or `CEPH_MDS_OP_RMDIR`, it is determined that the request is a deletion request for the target object (i.e., a file or an empty directory). In this case, the system will further obtain the absolute path of the target object and determine whether the recycle bin is enabled on that path.

[0063] like Figure 2 As shown, the system's processing flow exhibits a clear branching mechanism. For branches where the judgment result is "yes" (i.e., the recycle bin function is enabled), the system will perform the following operations in sequence: First, it synchronously marks the metadata deletion on the front end, then immediately returns a response to the client and generates an asynchronous task. To avoid blocking subsequent operations, the generated task is properly delivered to the system's asynchronous task queue, and then processed by a background thread. After taking over the task, the background thread performs a renaming operation to the recycle bin to achieve the physical migration of the underlying data, and updates the metadata (i.e., destroys the old metadata under the original path) after confirming the move is complete, thus completing the entire asynchronous protection loop.

[0064] Furthermore, after determining whether the recycle bin function is enabled on the path where the target object is located in step 120, the method further includes: If the recycle bin function is not enabled, the deletion request is executed directly to delete the target object, and the processing result corresponding to the deletion request is returned to the client.

[0065] Specifically, if the recycle bin feature is not enabled, the system processing flow will proceed to... Figure 2 The "No" branch is shown in the image. In this case, the system directly executes the deletion request to delete the target object, i.e., it executes... Figure 2 The diagram shows the execution of the original deletion process. This means that for paths without a recycle bin protection policy, MDS will no longer perform any interception or renaming operations. Instead, it will follow standard distributed storage data cleanup behavior, synchronously destroying the data blocks of files or empty directories and their corresponding inodes, and returning the processing result corresponding to the deletion request to the client.

[0066] The method provided in this invention, by combining a fine-grained directory-level recycle bin activation strategy, not only provides protection against accidental deletion of core business data but also preserves a channel for the system to execute the native deletion process. For specific directories storing massive amounts of temporary data, log files, or those that genuinely do not require recycle protection, the system can directly allow the original deletion process, avoiding unnecessary asynchronous task generation, queue scheduling, and space occupation overhead, thereby achieving a dynamic balance between data security and overall operational performance in the distributed system.

[0067] Based on any of the above embodiments, in order to better manage reclaimed objects in a distributed architecture and prepare for subsequent recovery and cleanup work, the embodiments of the present invention have made specific designs on the internal structure and data storage rules of the recycle bin. Specifically, the recycle bin directory includes a dedicated directory independently allocated to each metadata server instance, and the dedicated directory is divided into subdirectories according to date.

[0068] Specifically, Figure 3 This is a schematic diagram of the structure of the recycle bin directory provided by the present invention, as shown below. Figure 3 As shown, under the preset recycle bin root directory (such as the .trash root directory), not all recycled objects (i.e., files or empty directories) are stored together. Instead, based on the load balancing architecture of multiple MDS in the distributed system, a separate dedicated directory is allocated for each MDS instance. For example... Figure 3 The diagram shows dedicated directories such as .trash0 (MDS0 exclusive), .trash1 (MDS1 exclusive), and .trashN (MDSN exclusive). Within each dedicated directory, the system further creates subdirectories based on the specific date the object was deleted (e.g., in YYYYMMDD format), for example... Figure 3 The date directories shown are 20251111, 20251112, 20251113, etc.

[0069] Furthermore, based on the clarified directory structure, step 140, which involves moving the target object to the recycle bin directory via the asynchronous task, specifically includes: Step 141: Extract the parent node index information, the self node index information, and the original name of the target object; Step 142: Concatenate the parent node index information, the self node index information, and the original name according to a preset format to generate a new name for the target object in the recycle bin directory; In step 143, the corresponding target-specific directory is determined, as well as the target date corresponding to the date when the metadata of the target object is marked as deleted, and the target object named according to the new name is stored in the subdirectory under the target-specific directory corresponding to the target date.

[0070] Specifically, for each target object in the asynchronous task queue, the system first extracts the target object's parent inode index information, its own inode index information, and its original name. In the file system, an inode is the core data structure used to describe file metadata, containing information such as the file's location and size. The extracted parent inode index information (represented as ParentInode) indicates which parent directory the object was originally stored in, the own inode index information (represented as Inode) is the object's unique identifier, and the original name (represented as FileName) is the original filename or directory name from the user's perspective.

[0071] Next, the parent node index information, the self node index information, and the original name are concatenated according to a preset format to generate the new name of the target object in the recycle bin directory. For example, the preset format can be ParentInode_Inode_FileName.

[0072] For example, such as Figure 3 As shown, assuming a file named file1.txt has a parent node index of 1099511650201 and a self node index of 1099511650202, the newly generated name is 1099511650201_1099511650202_file1.txt.

[0073] Finally, the system will determine the corresponding target directory and the target date corresponding to when the target object's metadata was marked as deleted. The target object, renamed with the new name, will then be stored in a subdirectory within the target directory corresponding to that target date. For example, if the deletion operation was handled by the MDS0 instance on November 11, 2025, then the target directory is .trash0, and the file1.txt, renamed with the new name, will be physically moved to the path .trash0 / 20251111. Similarly, if the target object is an empty directory (e.g., dir1), a new name will be generated using the same logic (e.g., ...). Figure 3 The values ​​1099511650201_1099511650204_dir1 are shown and stored in the corresponding locations.

[0074] The method provided in this invention avoids authorization conflicts in multi-instance concurrent operation scenarios by allocating an independent dedicated recycling directory for each metadata server instance, ensuring the atomicity and consistency of renaming and moving operations in a distributed environment. Simultaneously, the subdirectory structure based on deletion date lays the data organization foundation for subsequent automated batch data cleanup based on time periods. Furthermore, the new names within the recycle bin adopt a naming strategy that directly concatenates the index information of the parent node and its own node, preserving the original hierarchical topology of the stored objects at extremely low cost. This allows the system to quickly and accurately reconstruct the entire original data directory tree even in the event of large-scale accidental deletions in complex multi-level directories, thanks to the index links contained in the names.

[0075] Based on any of the above embodiments, the method further includes: Step 150: Receive the recovery command and parse the recovery parameters carried in the recovery command to determine the recovery type and target recovery path; Step 160: Obtain the objects to be recovered from the recycle bin directory according to the recovery type, and summarize the obtained objects to be recovered to generate a list of objects to be recovered; Step 170: For each object to be recovered in the list of objects to be recovered, parse the new name of each object to be recovered in the recycle bin directory to obtain the parent node index information and the self node index information corresponding to each object to be recovered; Step 180: Using the target recovery path as the root directory, reconstruct the original data directory structure of each object to be recovered based on the parent node index information and the self node index information; Step 190: Restore each object in the list of objects to be restored to the reconstructed data directory structure object by object.

[0076] It should be noted that, in order to safely and completely restore accidentally deleted objects that have entered the recycle bin, this embodiment of the invention also provides a complete object recovery process.

[0077] Specifically, Figure 4 This is a schematic diagram of the storage object recovery process provided by the present invention, as shown below. Figure 4 As shown, the system first receives a recovery command and parses the recovery parameters carried in the command to determine the recovery type and target recovery path. Here, to prevent unauthorized access to recycle bin data by ordinary users and potential secondary damage, this recovery command typically originates from a recovery command executed by an administrator; that is, object recovery operations are by default only accessible to the admin user with recycle bin directory administrator privileges. After receiving the command, the system parses the recovery parameters, extracting the criteria for determining the administrator's desired recovery type and the target recovery path for storing the recovered files or directories.

[0078] Subsequently, the system will retrieve the corresponding objects to be recovered (i.e., files or directories that need to be recovered) from the recycle bin directory according to the recovery type, and summarize these objects to be recovered to generate a list of objects to be recovered, such as... Figure 4 The process shown is for collecting a list of objects to be recovered.

[0079] Because the object names in the recycle bin have been specially concatenated, in order to restore their original locations, the system will parse the new name of each object in the list of objects to be recovered in the recycle bin directory, thereby obtaining the parent node index information and the self node index information of each object. Here, by reverse decomposing the format of ParentInode_Inode_FileName, the system can accurately obtain the original topological association data of the object.

[0080] Based on this, the system will use the target recovery path as the root directory and, according to the parent node index information and its own node index information, reconstruct the original data directory structure of each object to be recovered, i.e., execute... Figure 4 The diagram illustrates the operation of rebuilding the directory tree structure. This means that the list of objects to be restored will use the specified safe target path as the new root node, and restore the original multi-level parent-child directory hierarchy of the deleted files or directories under it, ensuring that the restored directory framework is consistent with that before deletion.

[0081] Finally, for each object in the list of objects to be recovered, the system will restore it object by object to the rebuilt data directory structure, as follows: Figure 4 The steps for performing recovery are shown. After all the underlying data is back in place, MDS will update the metadata accordingly and finally return the recovery results to the administrator, completing the entire closed loop.

[0082] The method provided in this invention, by introducing administrator permission verification and name reverse parsing mechanism, not only ensures the absolute security of data inside the recycle bin from the source, but also enables the system to automatically reconstruct complex original multi-level data directory trees starting from any specified path, solving the problem of difficulty in sorting out hierarchical relationships after recovering scattered files from the traditional recycle bin.

[0083] Based on any of the above embodiments, in order to adapt to the refined retrieval and recovery needs under different business scenarios, such as Figure 4 As shown in the recovery type determination branch, in step 160, obtaining the object to be recovered from the recycle bin directory according to the recovery type includes: Step 161: If the recovery type is path-based recovery, search the recycle bin directory for an object that matches the specified path carried in the recovery instruction as the object to be recovered. Step 162: If the recovery type is recovery by date, find the subdirectory in the recycle bin directory that matches the specified date carried by the recovery instruction, and retrieve the object to be recovered from the subdirectory; Step 163: If the recovery type is recovery by mode, match the objects to be recovered in the recycle bin directory based on the wildcards carried in the recovery instructions.

[0084] Specifically, by parsing the recovery parameters, if the parsed recovery type is path-based recovery, the system will further search for objects matching the specified path in the recycle bin directory as objects to be recovered, based on the path specified in the recovery command. Figure 4 The steps shown illustrate how to find a matching object in the recycle bin. This mode is suitable when the administrator knows the exact absolute path of the original file or directory before it was accidentally deleted; the system will directly locate the target through path mapping.

[0085] If the parsed recovery type is date-based recovery, the system will first determine the specific date to be recovered (i.e., the exact date the file or directory was accidentally deleted) based on the specified date in the recovery command. Then, it will search for subdirectories in the recycle bin directory that match the specified date, and thus select the objects in those subdirectories as the objects to be recovered. Figure 4 The steps shown are for scanning a directory for a specified date. For example, if a business reports a large number of accidental deletions from yesterday's operations, the administrator can directly specify the previous day's date, and the system will then target the corresponding date subdirectory to extract all accidentally deleted objects from that day.

[0086] If the parsed recovery type is pattern-based recovery, the system will match the wildcards carried in the recovery command in the recycle bin directory to obtain the object to be recovered, i.e., execute the recovery command. Figure 4 The steps shown illustrate the use of wildcards to match objects. For example, an administrator can input a generalized pattern parameter such as ".log", which the system can then use to perform global or local regular expression filtering within the recycle bin, quickly retrieving a batch of files or directories with a specific format.

[0087] The embodiments of the present invention provide a variety of flexible and multi-dimensional object retrieval and recovery methods, such as by path, by date, and by pattern matching, which reduces the difficulty of object retrieval in massive recycle bin data and improves the object retrieval efficiency for various sudden accidental deletion scenarios.

[0088] Based on any of the above embodiments, during the process of performing object-by-object recovery on a list of objects to be recovered, it is often encountered that a file or directory with the same name already exists under the specified target recovery path. To properly handle this data overlap, embodiments of the present invention provide, as follows: Figure 4 The conflict handling logic shown is as follows. Specifically, step 190 includes: Step 191: Detect whether there is an object with the same name as the object to be recovered in the reconstructed data directory structure; Step 192: If it exists, create a file with a different name at the specified location of the target recovery path to store the object to be recovered, and output an exception report after the recovery operation is completed; Step 193: If it does not exist, then use the original name of the object to be recovered to restore the object to the data directory structure.

[0089] Specifically, firstly, before each recovery, the system checks whether an object with the same name as the object to be recovered exists in the rebuilt data directory structure, that is, it executes... Figure 4 The target location conflict determination is shown in the figure.

[0090] If it does not exist (corresponding) Figure 4 If the branch that determines "no" indicates that the target location is clean, then the original name of the object to be recovered can be used directly to restore the object to the rebuilt data directory structure (i.e., execute...). Figure 4 The direct rename recovery step shown in the figure successfully completes the recovery operation of the object.

[0091] If there exists (corresponding) Figure 4 (If a branch is identified as a conflict), to avoid overwriting existing useful data, the system will create a variant object at a specified location in the target recovery path to restore the current object to be restored, and output an exception report after the recovery operation is completed. In practice, the system first generates a conflict resolution solution, which can be confirmed by the user or handled automatically. For example, the system automatically appends a timestamp or sequence number to the original filename according to preset rules to create a safe variant file, thereby securely storing the data. To ensure that the batch recovery task is not interrupted, the system records these conflict situations and outputs an exception report centrally after the entire recovery operation is completed, facilitating post-event verification and organization by the administrator.

[0092] The method provided in this invention, by introducing a non-blocking conflict resolution mechanism that includes name conflict detection, generation of objects with different names, and post-event reporting, effectively avoids the problem of accidentally overwriting the original useful objects when restoring objects. At the same time, it ensures the continuity and automation of large-scale batch recovery tasks and optimizes the operation and maintenance security of the system.

[0093] Based on any of the above embodiments, the method further includes: The background thread periodically scans each subdirectory under the recycle bin directory; Calculate the data retention time for each subdirectory and check whether the data retention time exceeds the preset retention period; If the data retention time corresponding to any subdirectory exceeds the preset retention period, the subdirectory is determined to be an expired subdirectory and marked as pending deletion. Batch delete and release storage space for each expired subdirectory that is in a pending deletion state and the data contained within each expired subdirectory.

[0094] It should be noted that, since a large amount of data may be placed in the recycle bin every day in a distributed storage system, if left unchecked, the data in the recycle bin will occupy a significant amount of valuable storage resources, and the amount of data occupied will increase dramatically. Therefore, this embodiment of the invention introduces a mechanism for cleaning up recycle bin objects, which can automatically clean up the data in the recycle bin based on time-driven processes.

[0095] Specifically, Figure 5 This is a schematic diagram of the process for cleaning up recycle bin objects provided by the present invention, such as... Figure 5 As shown, firstly, a scheduled cleanup task is triggered internally, causing a background thread to periodically scan each subdirectory under the recycle bin directory. Before performing the actual scan, the background thread loads the cleanup configuration to obtain the data security buffer period (i.e., the preset retention period, such as 30 days by default) pre-set by the administrator in the system. Subsequently, the thread begins scanning all recycle bin directories. Since, in the aforementioned embodiment, the reclaimed objects are already stored in the recycle bin according to their deletion date, the system can efficiently group data by date directory.

[0096] Based on this, the system will calculate the data retention time for each independent group directory (i.e., the subdirectory corresponding to the date) and check whether the data retention time exceeds the preset retention period.

[0097] If the determination result is negative, meaning the objects in that date subdirectory were recently deleted and are still within the security protection period, the system skips the check and further determines if there are any unchecked directories in the system. If so, it loops back to the step of grouping data by date directory and continues to calculate and determine the next subdirectory.

[0098] If the determination result is yes, meaning the data retention time corresponding to the subdirectory exceeds the preset retention period, then the subdirectory can be determined as an expired subdirectory and marked as pending deletion. To improve the efficiency of subsequent operations, the system will group all subdirectories marked as pending deletion and perform an operation to collect all directories to be deleted.

[0099] Once the background thread confirms that all subdirectories have been traversed and no unchecked directories remain, it will enter the final cleanup execution phase. The system will batch delete all expired subdirectories in the pending deletion state, along with the data contained within these expired subdirectories. This batch deletion directly reuses the system's original underlying file cleanup logic, destroying the directory structure and all contained file fragments together, thereby completely freeing up data block space. After completing the reclamation of physical space, to maintain the consistency and traceability of system monitoring metrics, the system will also update storage usage statistics, record detailed cleanup operation logs, and finally output a status signal indicating that the cleanup task is complete, ending this round of automated cleanup cycle.

[0100] The method provided in this invention achieves fully automated lifecycle management and space reclamation of recycle bin data by using a background thread combined with a date-based directory structure to perform timed scanning and judgment. This process requires no manual intervention and significantly reduces operation and maintenance costs. More importantly, because recycle bin data is divided into date-based subdirectories, the system does not need to retrieve the attribute time of each object individually when cleaning up expired data. Instead, it directly performs batch judgment and whole-pack deletion at the date directory granularity. This design releases a large amount of storage space with extremely low system overhead and extremely high concurrency.

[0101] Based on any of the above embodiments, step 140, moving the target object to the recycle bin directory via the asynchronous task, includes: Obtain the target storage pool associated with the recycle bin directory, wherein the storage medium cost of the target storage pool is lower than the storage medium cost of the original storage pool where the target object is located; The asynchronous task moves the target object from the original storage pool to the recycle bin directory in the target storage pool.

[0102] It should be noted that cost management of storage hardware is a crucial aspect of distributed storage systems. In conventional storage scenarios, frequently accessed and valuable data is typically stored on expensive, high-performance media. If these high-performance storage resources continue to occupy data after files or directories are deleted and moved to the recycle bin, it results in significant waste. Therefore, this embodiment of the invention optimizes the hierarchical location of data storage.

[0103] Specifically, first, the system retrieves the target storage pool associated with the recycle bin directory. It should be understood that a data storage pool is a logical storage unit in a distributed storage system (such as Ceph), used to define data redundancy policies and the physical storage media it relies on. In this system, the storage media cost of the target storage pool is lower than the storage media cost of the original storage pool where the target object resides. For example, the original storage pool where business operations are normally read and written may be configured with high-performance, high-cost storage devices such as SSDs or NVMe; while the recycle bin directory is pre-configured and bound to an independent data storage pool composed of low-cost media such as HDDs.

[0104] After determining the storage destination, the system uses asynchronous tasks to move the target object from the original storage pool to the recycle bin directory in the target storage pool. This process leverages the directory layout characteristics of the distributed file system, allowing discarded data blocks to be directly written to the underlying low-cost storage medium during background data block migration.

[0105] This invention utilizes the data pool hierarchical management feature of a distributed storage system to automatically migrate data that has been deleted by the user but still needs to be in a safe buffer period from expensive high-performance storage media to inexpensive low-speed storage media. While maintaining the ability to prevent accidental deletion and without changing the system's logical architecture, it releases core storage resources, thereby optimizing and reducing hardware storage overhead in massive data scenarios.

[0106] Based on any of the above embodiments, the method further includes: Receive a rename request for any object sent by the client; The target path and source path corresponding to the rename request are verified; If the target path is the recycle bin directory, or the source path is located within the recycle bin directory, the rename request is rejected and an error message is returned to the client.

[0107] It should be noted that in Linux systems or most distributed storage systems, users can typically use the `mv` (move) command to organize files, which is interpreted as a `rename` request in the underlying metadata server. However, the recycle bin system of this invention is automatically managed by an internal background thread using a specific naming format and directory structure. To prevent improper user operations from disrupting this internal mechanism, this embodiment of the invention adds a set of verification and protection logic.

[0108] Specifically, when MDS receives a rename request from a client for any file or directory (i.e., it recognizes the CEPH_MDS_OP_RENAME operation type), the system will not execute it directly, but will instead verify the target path and source path corresponding to the rename request.

[0109] During the verification process, if the target path is the recycle bin directory, or the source path is located within the recycle bin directory, the rename request will be rejected, and an error message will be returned to the client. Specifically, this involves verification and interception in two directions. One is the interception of the target path verification. If a user attempts to move (i.e., rename) a regular file directly to the recycle bin directory, the system will directly intercept it. This is because the recycle bin is only used to store deleted files or directories automatically managed by the system; users are not allowed to drag and drop valid data into it as if it were a regular file.

[0110] Secondly, there's the verification and interception of the source path. If a user attempts to move a file or directory out of the recycle bin, or rename it within the recycle bin, the system will also reject the attempt with an error. This is to prevent users from manually disrupting the specific object naming rules (i.e., ParentInode_Inode_FileName) and the date-based directory structure within the recycle bin. If a user truly needs to recover accidentally deleted files or directories, they must do so through a dedicated administrator recovery interface and commands, and cannot rely on the ordinary `mv` command.

[0111] The invention provides a method that sets up bidirectional path security verification for renaming and moving operations, preventing ordinary client users from directly interfering with objects inside the recycle bin using regular system commands. This not only prevents valid files or directories from being mistakenly moved in and causing management chaos, but also prevents the specific metadata splicing structure within the recycle bin from being damaged. Thus, in a complex distributed multi-user environment, it ensures the consistency and security of data flow in the recycle bin.

[0112] The storage object recycling apparatus provided by the present invention is described below. The storage object recycling apparatus described below can be referred to in correspondence with the storage object recycling method described above.

[0113] Based on any of the above embodiments Figure 6 This is a schematic diagram of the storage object recycling device provided by the present invention, as shown below. Figure 6 As shown, the device includes: The request receiving unit 610 is used to receive a deletion request for a target object sent by a client, wherein the target object includes at least one of a file and a directory; The request interception unit 620 is used to respond to the deletion request, determine whether the recycle bin function is enabled in the path where the target object is located, and if the recycle bin function is enabled, intercept the deletion request and convert the deletion request into a renaming operation pointing to a preset recycle bin directory; The synchronization marking unit 630 is used to synchronously mark the metadata of the target object as deleted based on the renaming operation, and return response information for the deletion request to the client; The asynchronous movement unit 640 is used to generate an asynchronous task and move the target object to the recycle bin directory through the asynchronous task.

[0114] The device provided in this invention, upon receiving a deletion request from a client, determines whether the target object's path has a recycle bin enabled. This breaks the traditional limitation of a global recycle bin forcibly retaining all data, enabling fine-grained control to flexibly enable anti-accidental deletion protection for specific directory paths as needed. This effectively avoids a large amount of unprotected temporary data occupying space, significantly reducing storage costs. After confirming the recycle bin is enabled, this invention directly intercepts the deletion request at the lower level and converts it into a rename operation. This mechanism is completely transparent to the upper-layer client, requiring no synchronous upgrades to the client software, significantly reducing client maintenance costs and compatibility risks. Furthermore, this invention employs a processing mechanism combining synchronous metadata marking and asynchronous actual data movement. During the synchronization phase, the system only needs to lightweightly mark the metadata as deleted and immediately return response information to the client, ensuring the user receives rapid deletion operation feedback. In the background, the system generates asynchronous tasks to perform the time-consuming operation of migrating the target object to the recycle bin directory. This decoupled front-end and back-end design solves the serious blocking problem caused by traditional synchronous data movement mechanisms when deleting a large number of files, effectively ensuring the overall high-efficiency response speed and concurrent processing performance of the distributed storage system.

[0115] Based on any of the above embodiments, the asynchronous movement unit is further configured to: If it is determined that the target object has been successfully moved to the recycle bin directory, delete the metadata corresponding to the target object in its original path.

[0116] Based on any of the above embodiments, the recycle bin directory includes a dedicated directory independently allocated to each metadata server instance, and the dedicated directory is divided into subdirectories according to date; the asynchronous movement unit is specifically used for: Extract the parent node index information, the self node index information, and the original name of the target object; The parent node index information, the self node index information, and the original name are concatenated according to a preset format to generate a new name for the target object in the recycle bin directory; Determine the corresponding target-specific directory and the target date corresponding to when the metadata of the target object is marked as deleted, and store the target object named according to the new name in the subdirectory under the target-specific directory corresponding to the target date.

[0117] Based on any of the above embodiments, the device further includes an object recovery unit, the object recovery unit being used for: Receive recovery instructions and parse the recovery parameters carried in the recovery instructions to determine the recovery type and target recovery path; According to the recovery type, retrieve the objects to be recovered from the recycle bin directory, and summarize the retrieved objects to be recovered to generate a list of objects to be recovered; For each object in the list of objects to be recovered, parse the new name of each object in the recycle bin directory to obtain the parent node index information and the self node index information corresponding to each object; Using the target recovery path as the root directory, the original data directory structure of each object to be recovered is reconstructed based on the parent node index information and the self node index information; Each object in the list of objects to be restored is restored to the reconstructed data directory structure.

[0118] Based on any of the above embodiments, the object recovery unit is specifically used for: When the recovery type is path-based recovery, the object to be recovered is found in the recycle bin directory that matches the specified path carried in the recovery instruction. If the recovery type is recovery by date, locate the subdirectory in the recycle bin directory that matches the specified date carried in the recovery instruction, and retrieve the object to be recovered from the subdirectory; When the recovery type is recovery by mode, the object to be recovered is obtained by matching the wildcard carried in the recovery instruction in the recycle bin directory.

[0119] Based on any of the above embodiments, the object recovery unit is specifically used for: Detect whether there is an object with the same name as any object to be recovered in the reconstructed data directory structure; If it exists, create an object with a different name at the specified location of the target recovery path to recover any of the objects to be recovered, and output an exception report after the recovery operation is completed; If it does not exist, then the original name of any object to be recovered is used to restore any object to be recovered to the data directory structure.

[0120] Based on any of the above embodiments, the device further includes a recycling bin cleaning unit, the recycling bin cleaning unit being used for: The background thread periodically scans each subdirectory under the recycle bin directory; Calculate the data retention time for each subdirectory and check whether the data retention time exceeds the preset retention period; If the data retention time corresponding to any subdirectory exceeds the preset retention period, the subdirectory is determined to be an expired subdirectory and marked as pending deletion. Batch delete and release storage space for each expired subdirectory that is in a pending deletion state and the data contained within each expired subdirectory.

[0121] Based on any of the above embodiments, the asynchronous movement unit is specifically used for: Obtain the target storage pool associated with the recycle bin directory, wherein the storage medium cost of the target storage pool is lower than the storage medium cost of the original storage pool where the target object is located; The asynchronous task moves the target object from the original storage pool to the recycle bin directory in the target storage pool.

[0122] Based on any of the above embodiments, the device further includes a request verification unit, the request verification unit being used for: Receive a rename request for any object sent by the client; The target path and source path corresponding to the rename request are verified; If the target path is the recycle bin directory, or the source path is located within the recycle bin directory, the rename request is rejected and an error message is returned to the client.

[0123] Based on any of the above embodiments, the device further includes an object deletion unit, the object deletion unit being used for: If the recycle bin function is not enabled, the deletion request is executed directly to delete the target object, and the processing result corresponding to the deletion request is returned to the client.

[0124] Figure 7 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 7As shown, the electronic device may include: a processor 710, a communication interface 720, a memory 730, and a communication bus 740, wherein the processor 710, the communication interface 720, and the memory 730 communicate with each other through the communication bus 740. The processor 710 can call logical instructions in the memory 730 to execute a storage object recycling method, which includes: receiving a deletion request for a target object sent by a client, the target object including at least one of files and directories; responding to the deletion request, determining whether the path where the target object is located has a recycle bin function enabled; if the recycle bin function is enabled, intercepting the deletion request and converting the deletion request into a renaming operation pointing to a preset recycle bin directory; based on the renaming operation, synchronously marking the metadata of the target object as deleted and returning response information for the deletion request to the client; generating an asynchronous task and moving the target object to the recycle bin directory through the asynchronous task.

[0125] Furthermore, the logical instructions in the aforementioned memory 730 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to related technologies, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0126] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the storage object recycling method provided by the above methods. The method includes: receiving a deletion request for a target object sent by a client, the target object including at least one of a file and a directory; responding to the deletion request, determining whether the path where the target object is located has a recycle bin function enabled; if the recycle bin function is enabled, intercepting the deletion request and converting the deletion request into a renaming operation pointing to a preset recycle bin directory; based on the renaming operation, synchronously marking the metadata of the target object as deleted and returning response information for the deletion request to the client; generating an asynchronous task and moving the target object to the recycle bin directory through the asynchronous task.

[0127] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a storage object reclamation method provided by the above methods. The method includes: receiving a deletion request from a client for a target object, the target object including at least one of a file or a directory; responding to the deletion request, determining whether the path where the target object is located has a recycle bin function enabled; if the recycle bin function is enabled, intercepting the deletion request and converting the deletion request into a renaming operation pointing to a preset recycle bin directory; based on the renaming operation, synchronously marking the metadata of the target object as deleted and returning response information for the deletion request to the client; generating an asynchronous task and moving the target object to the recycle bin directory through the asynchronous task.

[0128] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0129] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of software products. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0130] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for recycling stored objects, characterized in that, include: Receive a deletion request from a client for a target object, wherein the target object includes at least one of a file or a directory; In response to the deletion request, it is determined whether the recycle bin function is enabled in the path where the target object is located. If the recycle bin function is enabled, the deletion request is intercepted and the deletion request is converted into a renaming operation pointing to a preset recycle bin directory. Based on the renaming operation, the metadata of the target object is synchronously marked as deleted, and response information for the deletion request is returned to the client. An asynchronous task is generated, and the target object is moved to the recycle bin directory through the asynchronous task.

2. The storage object reclamation method according to claim 1, characterized in that, After the step of moving the target object to the recycle bin directory via the asynchronous task, the method further includes: If it is determined that the target object has been successfully moved to the recycle bin directory, delete the metadata corresponding to the target object in its original path.

3. The method for recycling storage objects according to claim 1, characterized in that, The recycle bin directory includes a dedicated directory allocated independently to each metadata server instance, and the dedicated directory is divided into subdirectories according to date; Moving the target object to the recycle bin directory via the asynchronous task includes: Extract the parent node index information, the self node index information, and the original name of the target object; The parent node index information, the self node index information, and the original name are concatenated according to a preset format to generate a new name for the target object in the recycle bin directory; Determine the corresponding target-specific directory and the target date corresponding to when the metadata of the target object is marked as deleted, and store the target object named according to the new name in the subdirectory under the target-specific directory corresponding to the target date.

4. The method for recycling storage objects according to claim 3, characterized in that, Also includes: Receive recovery instructions and parse the recovery parameters carried in the recovery instructions to determine the recovery type and target recovery path; According to the recovery type, retrieve the objects to be recovered from the recycle bin directory, and summarize the retrieved objects to be recovered to generate a list of objects to be recovered; For each object in the list of objects to be recovered, parse the new name of each object in the recycle bin directory to obtain the parent node index information and the self node index information corresponding to each object; Using the target recovery path as the root directory, the original data directory structure of each object to be recovered is reconstructed based on the parent node index information and the self node index information; Each object in the list of objects to be restored is restored to the reconstructed data directory structure.

5. The method for recycling storage objects according to claim 4, characterized in that, The step of retrieving the object to be recovered from the recycle bin directory according to the recovery type includes: When the recovery type is path-based recovery, the object to be recovered is found in the recycle bin directory that matches the specified path carried in the recovery instruction. If the recovery type is recovery by date, locate the subdirectory in the recycle bin directory that matches the specified date carried in the recovery instruction, and retrieve the object to be recovered from the subdirectory; When the recovery type is recovery by mode, the object to be recovered is obtained by matching the wildcard carried in the recovery instruction in the recycle bin directory.

6. The method for recycling storage objects according to claim 4, characterized in that, The step of restoring each object in the list of objects to be restored to the reconstructed data directory structure includes: Detect whether there is an object with the same name as any object to be recovered in the reconstructed data directory structure; If it exists, create an object with a different name at the specified location of the target recovery path to recover any of the objects to be recovered, and output an exception report after the recovery operation is completed; If it does not exist, then the original name of any object to be recovered is used to restore any object to be recovered to the data directory structure.

7. The method for recycling storage objects according to claim 3, characterized in that, Also includes: The background thread periodically scans each subdirectory under the recycle bin directory; Calculate the data retention time for each subdirectory and check whether the data retention time exceeds the preset retention period; If the data retention time corresponding to any subdirectory exceeds the preset retention period, the subdirectory is determined to be an expired subdirectory and marked as pending deletion. Batch delete and release storage space for each expired subdirectory that is in a pending deletion state and the data contained within each expired subdirectory.

8. The method for recycling storage objects according to claim 1, characterized in that, Moving the target object to the recycle bin directory via the asynchronous task includes: Obtain the target storage pool associated with the recycle bin directory, wherein the storage medium cost of the target storage pool is lower than the storage medium cost of the original storage pool where the target object is located; The asynchronous task moves the target object from the original storage pool to the recycle bin directory in the target storage pool.

9. The method for recycling storage objects according to any one of claims 1 to 8, characterized in that, Also includes: Receive a rename request for any object sent by the client; The target path and source path corresponding to the rename request are verified; If the target path is the recycle bin directory, or the source path is located within the recycle bin directory, the rename request is rejected and an error message is returned to the client.

10. The method for recycling storage objects according to any one of claims 1 to 8, characterized in that, After the step of determining whether the path where the target object is located has the recycle bin function enabled, the method further includes: If the recycle bin function is not enabled, the deletion request is executed directly to delete the target object, and the processing result corresponding to the deletion request is returned to the client.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the storage object reclamation method as described in any one of claims 1 to 10.

12. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the storage object reclamation method as described in any one of claims 1 to 10.

Images