Method for flexibly recovering and cleaning distributed recycle bin

Abstract

The invention discloses a method for flexibly recovering and cleaning a distributed recycle bin, which relates to the field of distributed file storage recycle bins and is characterized in that in a distributed file storage system, a key value storage mode is adopted, specifically, through a rocksdb database, flexible recovery and cleaning after file deletion are realized, and when the file is deleted, the file can be flexibly recovered and cleaned. Metadata information and filename information of a file are stored in a rocksdb database of a current metadata node in a key-value pair mode, and an index is established according to a certain rule. Aiming at the characteristics of a distributed file storage system, the method can uniformly manage deleted files in a cross-node manner, the security and restorability of data in a complex environment are ensured, a user can recover mistakenly deleted files from a recycle bin within a certain time, the data loss risk is reduced, and the user experience is improved. The metadata information and the filename information of the file are stored in the high-performance rocksdb database in the form of the key-value pair, and the index is established, so that the overhead of moving the file across nodes is avoided, and the processing speed and efficiency of the recycle bin are greatly improved.

Description

Technical Field

[0001] The invention relates to the field of distributed file storage recycling bins, and in particular to a method for flexibly restoring and cleaning distributed recycling bins. Background Art

[0002] With the rapid development of information technology, distributed file storage systems have been widely used in cloud computing, big data processing, enterprise file sharing and other fields due to their high availability, scalability and fault tolerance. However, while enjoying the convenience brought by distributed storage, problems such as accidental deletion and accidental damage of files have also arisen, which have brought huge losses to enterprises and individual users.

[0003] In traditional file storage systems, the recycle bin mechanism is the main means to prevent accidental deletion of files. When a user deletes a file, the system will move the file to a specific recycle bin area instead of deleting it immediately from the physical storage. Users can restore these files from the recycle bin within a certain period of time. However, this traditional recycle bin mechanism faces many challenges in distributed file storage systems.

[0004] First, distributed file storage systems usually involve multiple nodes and complex network environments. Files may be randomly distributed on different nodes. The traditional local recycle bin mechanism cannot uniformly manage deleted files across nodes, which makes it difficult to effectively ensure the security and recoverability of data in a distributed environment. Secondly, the number of files in a distributed system is huge and the number of users is large. The traditional recycle bin mechanism is often inefficient when processing a large number of deletion and recovery requests, and cannot meet the needs of large-scale distributed storage systems. In addition, moving files across nodes is a very resource-consuming operation in a distributed system, which will seriously affect the overall performance of the system. Thirdly, the traditional recycle bin mechanism usually lacks an effective indexing and query mechanism, resulting in inefficiency when searching for specific files in the recycle bin, which cannot meet the needs of enterprise-level file management. At the same time, the traditional recycle bin mechanism cannot support the setting of independent recycle bin space for different user directories, which can easily cause resource confusion and management difficulties. Summary of the invention

[0005] Based on this, the purpose of the present invention is to provide a flexible recovery and cleaning method for distributed recycle bins to solve the technical problems that the traditional local recycle bin mechanism cannot uniformly manage deleted files across nodes, is often inefficient when processing a large number of deletion and recovery requests, lacks an effective indexing and query mechanism, resulting in inefficiency when searching for specific files in the recycle bin, and cannot support setting up independent recycle bin space for different user directories, which easily causes resource confusion and management difficulties.

[0006] In view of the above problems, the present application provides a method for flexibly restoring and cleaning a distributed recycle bin.

[0007] The first aspect of the present application provides a method for flexibly recovering and cleaning a distributed recycle bin. In a distributed file storage system, a key-value (KV) storage method is adopted, specifically through a rocksdb database, to realize flexible recovery and cleaning after file deletion. The method includes: when a file is deleted, the metadata information (inode) and file name information (dentry) of the file are stored in the form of a key-value pair in the rocksdb database of the current metadata node, and an index is established according to certain rules to support subsequent file recovery and cleaning operations; when restoring a file, according to a user request, the corresponding metadata information is retrieved from the rocksdb database, restored to a specified location, and the corresponding key-value pair is deleted from rocksdb after completion; when a file is completely deleted, the file metadata is added to the background garbage collection (GC) task queue, and the GC thread asynchronously cleans up the file data and the recycle bin information in rocksdb.

[0008] The following steps are also included: two tables are set up in the rocksdb database to support fast query and filtering based on file deletion time and file path, respectively, to improve the efficiency of recovery and cleanup operations; independent recycle bin space is set up for each user directory to ensure isolation between recycle bin resources and avoid resource confusion.

[0009] It also includes an occupancy judgment step when a file is deleted: when a file is deleted, first check whether the file is occupied; if the file is occupied, it is marked as occupied and the corresponding entry in the rocksdb database is updated; after the file is unoccupied, the entry status in the rocksdb database is updated again to unoccupied for subsequent recovery or cleanup.

[0010] It also includes the directory judgment step when restoring files: before restoring files, check whether the target directory exists; if the target directory does not exist, create the corresponding directory on the node where the file is located, and obtain the directory information of the target path; use the directory information of the target path and the inode information of the file to rebuild the dentry and new inode data of the file at the target location.

[0011] In the step of completely deleting the file, if the file is still occupied when it is deleted, the file information will be placed in the pre-deletion queue. After the file occupation is released, the file information will be placed in the GC task queue for cleaning.

[0012] It also includes regular sorting and cleaning of metadata stored in the rocksdb database to ensure efficient use of recycle bin space and stable operation of the system.

[0013] The second aspect of the present application provides a distributed file storage system, which includes: a storage unit for storing metadata information of a rocksdb database and files therein; a processing unit for performing the following operations: when a file is deleted, storing the file metadata information in the rocksdb database and creating an index; receiving a file recovery request, retrieving and recovering the file from the rocksdb database; receiving a file complete deletion request, adding the file metadata to a GC task queue, and having the GC thread clean it up asynchronously; an index management unit for maintaining the index in the rocksdb database and supporting fast query and filtering; a recycle bin space management unit for allocating independent recycle bin space to each user directory and ensuring resource isolation; a GC task management unit for managing the GC task queue and performing asynchronous deletion operations on files, and a user interface for receiving user file recovery and deletion requests and displaying operation results.

[0014] According to a third aspect of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements a method for flexibly recovering and cleaning a distributed recycle bin when executing the computer program.

[0015] A fourth aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of a method for flexibly restoring and cleaning a distributed recycle bin.

[0016] In summary, the present invention mainly has the following beneficial effects:

[0017] The present invention aims at the characteristics of distributed file storage systems. The method can uniformly manage deleted files across nodes to ensure the security and recoverability of data in complex environments. Users can recover accidentally deleted files from the Recycle Bin within a certain period of time, reducing the risk of data loss. By storing the file's metadata information (inode) and file name information (dentry) in the form of key-value pairs in a high-performance rocksdb database and establishing an index, the overhead of moving files across nodes is avoided, greatly improving the speed and efficiency of Recycle Bin processing. In a distributed environment, it can effectively cope with the deletion and recovery needs of massive data. In the rocksdb database, support is set to support fast query and filtering functions based on file deletion time and file path, making it more efficient to find specific files. This not only saves administrators' time and energy, but also improves the convenience of enterprise-level file management. It is convenient to set up an independent recycle bin space for each user directory, which realizes the strict isolation between recycle bin resources and avoids resource confusion and management difficulties. On the multi-user collaboration platform, each user can have an independent and orderly recycle bin space, which enhances the user experience and system flexibility. By implementing the background GC task queue, the recycle bin related tasks are arranged to be executed in the background, avoiding the interference of recycle bin operations on normal I / O requests, ensuring the stable operation and efficient response of the system. In the process of file deletion and recovery, the file occupancy judgment step is added. If the file is occupied, the deletion or recovery operation will not be performed temporarily, avoiding data conflict and damage. At the same time, the introduction of the pre-deletion queue also provides a flexible processing method for completely deleting files. The metadata stored in the rocksdb database is sorted and cleaned regularly to ensure the effective use of the recycle bin space and the stable operation of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 This is a framework diagram of the method for flexibly restoring and cleaning distributed recycle bins of the present invention;

[0019] Figure 2 A diagram of the steps for requesting recovery of files for the present invention;

[0020] Figure 3 A diagram of the steps for requesting complete file deletion for the present invention. DETAILED DESCRIPTION

[0021] The following will be combined with the accompanying drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and cannot be understood as limiting the present invention.

[0022] The following describes an embodiment of the present invention based on its overall structure.

[0023] The distributed file storage system of the present invention is mainly composed of a storage unit, a processing unit, an index management unit, a recycle bin space management unit, a GC task management unit and a user interface, and these units work together to achieve flexible recovery and cleaning of files.

[0024] Storage unit, used to store metadata information of RocksDB database and its files;

[0025] A processing unit that performs the following operations:

[0026] When a file is deleted, the file metadata information is stored in the rocksdb database and an index is created;

[0027] Receive file recovery requests, retrieve and restore files from the rocksdb database;

[0028] Receive a request to completely delete a file, add the file metadata to the GC task queue, and have the GC thread clean it up asynchronously;

[0029] Index management unit, used to maintain indexes in the rocksdb database, supporting fast query and filtering;

[0030] Recycle Bin space management unit, used to allocate independent Recycle Bin space for each user directory and ensure resource isolation;

[0031] GC task management unit, used to manage GC task queues and perform asynchronous deletion of files;

[0032] User interface, used to receive user's file recovery and deletion requests and display the operation results.

[0033] A method for flexibly restoring and cleaning distributed recycle bins. In a distributed file storage system, a key-value (KV) storage method is used. Specifically, the rocksdb database is used to realize flexible recovery and cleaning after file deletion. Rocksdb is a high-performance key-value storage database that supports fast data reading and writing and index establishment. The storage unit is responsible for deploying and managing the rocksdb database to ensure stable operation and efficient access to the database:

[0034] When a file is deleted, the file's metadata information (inode) and file name information (dentry) are stored in the rocksdb database of the current metadata node in the form of key-value pairs, and an index is established according to certain rules to support subsequent file recovery and cleanup operations.

[0035] When a file is deleted, the system will first capture the file's metadata information (inode) and file name information (dentry). The inode information contains the file's metadata, such as file type, size, creation / modification time, number of links, data block location, etc., while the dentry contains the link to the file name and its inode object. These metadata information (inode) and file name information (dentry) are stored in the rocksdb database of the current metadata node in the form of key-value pairs. In order to improve the efficiency of subsequent recovery and cleanup operations, the system will create indexes in the rocksdb database according to certain rules (such as file deletion time, file path, etc.). These indexes enable the system to quickly locate the metadata information of specific files, thereby supporting efficient file recovery and cleanup.

[0036] The establishment of indexes can be customized according to actual needs. For example, a timestamp index can be established based on the deletion time of the file, so that eligible files can be quickly filtered out according to the time range; a path index can also be established based on the file path, so that the metadata information of the file can be quickly queried through the file path. By utilizing the powerful query capabilities of RocksDB and combining the established indexes, the system can efficiently perform file recovery and cleanup operations. Whether restoring a single file or cleaning up old files in batches, the target file can be quickly located through the index, reducing unnecessary disk I / O operations and improving the overall system performance.

[0037] When restoring a file, according to the user's request, the corresponding metadata information is retrieved from the rocksdb database, restored to the specified location, and the corresponding key-value pairs are deleted from rocksdb after completion.

[0038] When a user needs to restore a file that was previously deleted by mistake, a restore request is initiated through the user interface or command line interface (CLI). The request usually contains the name or identifier of the file to be restored. The processing unit in the distributed file storage system receives the user's restore request. This processing unit is the core part of the system and is responsible for performing all operations related to file recovery and deletion. The processing unit retrieves the corresponding metadata information (inode) and file name information (dentry) from the rocksdb database based on the file name or identifier provided by the user.

[0039] Before restoring files, the system needs to check whether the target directory (that is, the directory to which the user wants to restore the file) exists. This is to ensure that the file can be restored to the correct location and avoid recovery failure due to the non-existence of the directory. If the target directory does not exist, the system will create a corresponding directory on the node where the file is located and obtain the directory information of the target path.

[0040] Once the existence of the target directory is confirmed, the system will use the directory information of the target path and the inode information of the file retrieved from the rocksdb database to rebuild the dentry and new inode data of the file at the target location. This step is the core operation of file recovery, which involves recreating the file's index node (inode) and directory entry (dentry) at the appropriate location in the file system, thereby restoring the physical and logical structure of the file.

[0041] After the file is successfully restored, in order to prevent redundant data in the database and reduce storage space usage, the system will delete the key-value pairs related to the restored file from the rocksdb database. This step ensures the cleanliness and efficient operation of the rocksdb database.

[0042] It should be noted that during the entire recovery process, if any errors or abnormal situations (such as insufficient disk space, database access failure, etc.) are encountered, the system should be able to capture these errors and give corresponding error prompts so that users or administrators can discover the problems in time and take corresponding solutions. In addition, in order to ensure the stability of the system and the integrity of the data, the file recovery operation should be atomic, that is, it should either be completely successful or completely failed, and there should be no partial recovery or data inconsistency.

[0043] When a file is completely deleted, the file metadata is added to the background garbage collection (GC) task queue, and the GC thread asynchronously cleans up the file data and the recycle bin information in rocksdb.

[0044] This process is started when the user decides that a file that has been deleted and stored in the Recycle Bin is no longer needed, or when the system automatically initiates a complete deletion request based on preset rules (such as a file that has been stored in the Recycle Bin for too long). Upon receiving a request to completely delete a file, the system retrieves the file's metadata (such as inode and dentry) from the rocksdb database and adds it to a dedicated background garbage collection (GC) task queue. This queue is used to store the file metadata to be cleaned up for subsequent asynchronous processing. There are one or more GC threads in the system, which continuously check the GC task queue. Once it finds that there are tasks to be processed in the queue (i.e., file metadata to be cleaned up), the GC thread will retrieve these tasks for asynchronous processing.

[0045] The GC thread will first find and delete the actual file data stored on the physical storage medium (such as the hard disk) based on the retrieved file metadata. Then, it will update the rocksdb database and delete all recycle bin information related to the file, including previously stored key-value pairs such as inode and dentry. During the entire cleanup process, the system needs to ensure data consistency and security, which includes checking whether the file is occupied when processing file deletion (if it is occupied, deletion is delayed), and recording logs during the deletion process for recovery in case of problems.

[0046] The following steps are also included:

[0047] Set up two tables in the rocksdb database to support fast query and filtering based on file deletion time and file path, respectively, to improve the efficiency of recovery and cleanup operations;

[0048] Table based on file deletion time: This table is indexed according to the file deletion time. Through the timestamp index, users can quickly locate files deleted within a certain period of time. This is particularly useful for batch cleaning of old files or recovering recently deleted files.

[0049] Table based on file paths: This table is indexed by file paths. Users can quickly find metadata information of specific files by file paths, which is very efficient when specific files need to be restored.

[0050] When users need to restore or clean up files, the system can quickly locate the corresponding table in the rocksdb database based on the user's query conditions (such as deletion time range, file path, etc.), and use the index in the table for efficient query and filtering operations. This index-based query method greatly reduces the overhead of blind searching in the rocksdb database and improves the efficiency of file recovery and cleanup.

[0051] Set up an independent recycle bin space for each user directory to ensure isolation between recycle bin resources and avoid resource confusion.

[0052] The system maintains a user directory list, recording each user's directory information and the corresponding recycle bin space identifier. When a user creates a file or directory for the first time, the system allocates an independent recycle bin space for the user and records the relevant information in the rocksdb database.

[0053] An independent recycle bin space is allocated for each user directory in the distributed file storage system. This means that each user's deleted files will be stored in their own exclusive recycle bin instead of being shared globally. In this way, the isolation between recycle bin resources can be ensured to avoid file mixing and resource conflicts between different users. Independent recycle bin space realizes resource isolation. Each user can only access and manage the recycle bin files under his own directory, which not only simplifies the resource management process, but also improves the security and stability of the system. On the multi-user collaboration platform, each user can have an independent and orderly recycle bin space, which can easily find and restore files that they have accidentally deleted. Independent recycle bin space also supports user-defined configuration and management, such as setting the recycle bin size, cleanup strategy, etc., which enhances the user experience and system flexibility. Since the recycle bin files are divided and isolated by user directory, the system can locate and process the target files more efficiently when performing file recovery and cleanup operations, which helps to reduce unnecessary disk I / O operations and query time, and improve the overall performance of the system.

[0054] The specific steps for determining occupancy when deleting a file are as follows:

[0055] When a file is deleted, first check whether the file is occupied. When a user or system requests to delete a file, a check mechanism is first triggered to determine whether the file is currently occupied by other processes or users. This step is to ensure that the file will not cause data corruption or inconsistency due to being still in use before deletion.

[0056] If the file is occupied, it is marked as occupied and the corresponding entry in the rocksdb database is updated. If a file is detected to be occupied (for example, a process is reading or writing the file), the system will mark the file as "occupied", and this status information will be recorded in the corresponding entry in the rocksdb database. The purpose of this is to let the system know that the file cannot be deleted at present and needs to wait for the occupation to be released before subsequent operations. Once the file is marked as occupied, the system will update the corresponding entry in the rocksdb database to reflect this status change. In this way, whether it is file recovery or complete deletion, the status information in the rocksdb database will be checked first to avoid improper operations on files in use. After the file is marked as occupied, the system will wait until the file is no longer occupied by any process or user. This may take a while, depending on the cause and duration of the occupation.

[0057] After the file is unoccupied, the entry status in the rocksdb database is updated to unoccupied again for subsequent recovery or cleanup. After the file status is updated to unoccupied, the system will perform corresponding deletion or recovery operations based on user requests or system automatic tasks (such as garbage collection). These operations will be performed based on the latest status information in the rocksdb database to ensure data integrity and consistency.

[0058] The directory determination steps for file recovery are as follows:

[0059] Before restoring a file, check whether the target directory exists. When a user requests to restore a file from the recycle bin of a distributed file storage system, the system first checks whether the target directory specified by the user exists. This is an important step to ensure that the file can be restored to the correct location and avoid data confusion or loss.

[0060] If the target directory does not exist, create the corresponding directory on the node where the file is located, and obtain the directory information of the target path. If the target directory is found to be non-existent, the system will create the corresponding directory on the node where the file is located. This step is necessary because the file cannot be restored to a non-existent directory. After creating the directory, the system will further obtain detailed directory information of the target path for subsequent use. The system obtains the complete directory information of the target path by accessing the directory structure of the file system. This information includes but is not limited to the inode number of the directory, the inode number of the parent directory, the permissions of the directory, the owner, etc. This information is crucial for rebuilding the file at the target location.

[0061] Using the directory information of the target path and the inode information of the file, the dentry and new inode data of the file are rebuilt at the target location. After obtaining the directory information of the target path and the inode information of the file, the system will rebuild the dentry (directory entry) and new inode data of the file at the target location. The dentry is the link between the file name and its inode object, while the inode contains the metadata information of the file, such as the file type, size, creation / modification time, etc. The process of rebuilding the dentry and inode involves creating a link to the new inode in the directory structure of the file system and ensuring that the metadata of the file correctly reflects its status, so that when the user accesses the target directory, he can see and access the restored file.

[0062] Once the file is successfully rebuilt at the target location, the system will update the corresponding entry in the rocksdb database to reflect that the file recovery operation has been completed. At the same time, the system will delete the key-value pairs related to the file recovery operation from the rocksdb database to free up the occupied storage space.

[0063] In the step of completely deleting the file, if the file is still occupied when it is deleted, the file information will be placed in the pre-deletion queue. After the file occupation is released, the file information will be placed in the GC task queue for cleanup. If the file is still occupied when the deletion request is made (for example, a process is reading or writing the file), the system will not perform the deletion operation immediately, but will place the file information in a "pre-deletion queue". This queue is used to temporarily store file information that cannot be deleted temporarily because it is occupied. The pre-deletion queue exists to ensure that even if the file is currently occupied, the system can record the file information that needs to be deleted so that it can be processed in time when the file is no longer occupied. This can avoid the problem of deletion requests being ignored or delayed due to file occupation. Once a file is placed in the pre-deletion queue, the system will continue to monitor the status of the file. When the file is no longer occupied by any process or user, the system will check. Upon detecting this state change, when the file is no longer occupied, the system will take the file information out of the pre-deletion queue and put it into the background garbage collection (GC) task queue. The tasks in this queue will be executed asynchronously by the GC thread to ensure that the deletion operation does not block normal I / O requests or system operations. The GC thread will take the file information from the GC task queue and perform the actual deletion operation, which includes deleting the file data from the physical storage and cleaning up the recycle bin information related to the file from the rocksdb database. In this way, the system can ensure that even if the file is still occupied when it is deleted, it can be finally cleaned up after the occupation is released.

[0064] It also includes regular sorting and cleaning of metadata stored in the rocksdb database to ensure efficient use of recycle bin space and stable operation of the system.

[0065] By regularly sorting the metadata in the RocksDB database, you can ensure that the data in the database remains in an ordered state, which helps speed up query and index operations and improve the overall performance of the database. The system can set a timer or trigger to perform sorting tasks regularly. The sorting operation can be based on different criteria, such as the deletion time of the file, the file path, etc., to ensure that the data is more compact and ordered in physical storage.

[0066] As time goes by, a large amount of expired or invalid file metadata information may accumulate in the recycle bin. If this data is not cleaned up in time, it will not only take up valuable storage space, but also affect the query and indexing efficiency of the database. The system can regularly check the metadata in the rocksdb database, identify and delete those entries that are expired or no longer needed. For example, a time threshold can be set to treat the file metadata that exceeds the deletion time as invalid data and clean it up.

[0067] By regularly cleaning and sorting, you can optimize the storage space of the RocksDB database and ensure that the recycle bin space is effectively used, which helps reduce database fragmentation, improve storage efficiency, and reduce system maintenance costs. After regular sorting and cleaning, the RocksDB database will remain more compact and orderly, the response time of query and index operations will be greatly shortened, and the overall performance of the system will be significantly improved.

[0068] By regularly maintaining the RocksDB database, potential performance problems or data errors can be discovered and resolved in a timely manner, thereby ensuring the stable operation of the system. During the sorting and cleaning process, the system can also perform other maintenance tasks, such as checking the consistency of the database and repairing damaged data blocks. These tasks help ensure that the RocksDB database is always kept in the best condition and provide reliable support for file recovery and cleanup operations.

[0069] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, a method for flexibly recovering and cleaning a distributed recycle bin is implemented. The storage device is used to store an operating system, user data, and specially designed computer programs. These programs are the key to implementing the method for flexibly recovering and cleaning a distributed recycle bin. The memory is also used to store a rocksdb database and file metadata information therein to ensure data security and fast access. The processor is a core component of the electronic device and is responsible for executing the computer programs stored in the memory. When the processor executes these programs, it can process file deletion, recovery, and complete deletion requests in a distributed file storage system and interact with the rocksdb database. The computer program stored in the memory is designed to implement the method for flexibly recovering and cleaning a distributed recycle bin described in the document.

[0070] A computer-readable storage medium stores a computer program, which implements the steps of a method for flexibly restoring and cleaning a distributed recycle bin when executed by a processor. This computer-readable storage medium is a physical device capable of storing computer programs. When these programs are executed by a computer processor, a method for flexibly restoring and cleaning a distributed recycle bin can be implemented. This method is mainly applied to distributed file storage systems and aims to optimize file deletion, recovery, and cleaning operations through key-value storage technology (especially using a rocksdb database). Computer programs can be written in programming languages ​​(such as C++, Java, etc.) and compiled into executable files or library files. These program files are deployed to the corresponding nodes of a computer or distributed file storage system and executed by the processor of the node. When the processor executes these programs, the above-mentioned file deletion, recovery, and cleaning operations are implemented according to the logic of the program.

[0071] Those skilled in the art will understand that the various digital numbers such as the first and second involved in this application are only for the convenience of description, and are not used to limit the scope of this application, nor do they indicate a sequence of precedence. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the objects associated with each other are in an "or" relationship. "At least one" refers to one or more. At least two refers to two or more. "At least one", "any one" or similar expressions refer to any combination of these items, including any combination of single items (individuals) or plural items (individuals). For example, at least one item (individual, kind) of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple.

[0072] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in this application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

[0073] The steps of the method or algorithm described in this application can be directly embedded in hardware, software units executed by a processor, or a combination of the two. The software unit can be stored in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, register, hard disk, removable disk, CD-ROM or any other form of storage medium in the art. Exemplarily, the storage medium can be connected to the processor so that the processor can read information from the storage medium and write information to the storage medium. Optionally, the storage medium can also be integrated into the processor. The processor and the storage medium can be arranged in an ASIC, and the ASIC can be arranged in a terminal. Optionally, the processor and the storage medium can also be arranged in different components in the terminal. These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are performed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide for implementing the process in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0074] Although the present application has been described in conjunction with specific features and embodiments thereof, it is obvious that various modifications and combinations may be made thereto without departing from the spirit and scope of the present application. Accordingly, this specification and the accompanying drawings are merely exemplary illustrations of the present application and are deemed to have covered any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, a person skilled in the art may make various modifications and variations to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the present application and its equivalents, the present application is intended to include these modifications and variations.

Claims

1. A method for flexibly restoring and cleaning a distributed recycle bin, applicable to a distributed file storage system, characterized in that: include: In the distributed file storage system, a key-value (KV) storage method is used, specifically through the rocksdb database, to achieve flexible recovery and cleanup of deleted files. The method includes: When a file is deleted, the file's metadata information (inode) and file name information (dentry) are stored in the rocksdb database of the current metadata node in the form of key-value pairs, and indexes are created according to certain rules to support subsequent file recovery and cleanup operations; When restoring a file, according to the user's request, the corresponding metadata information is retrieved from the rocksdb database, restored to the specified location, and the corresponding key-value pairs are deleted from rocksdb after completion; When a file is completely deleted, the file metadata is added to the background garbage collection (GC) task queue, and the GC thread asynchronously cleans up the file data and the recycle bin information in rocksdb.

2. According to claim 1, a method for flexibly restoring and cleaning distributed recycle bins is characterized in that: The following steps are also included: Set up two tables in the rocksdb database to support fast query and filtering based on file deletion time and file path, respectively, to improve the efficiency of recovery and cleanup operations; Set up an independent recycle bin space for each user directory to ensure isolation between recycle bin resources and avoid resource confusion.

3. A method for flexibly restoring and cleaning distributed recycle bins according to claim 1, characterized in that: It also includes the occupancy judgment step when the file is deleted: When a file is deleted, first check whether the file is occupied; If the file is occupied, it is marked as occupied and the corresponding entry in the rocksdb database is updated; After the file is unoccupied, the entry status in the rocksdb database is updated to unoccupied for subsequent recovery or cleanup.

4. A method for flexibly restoring and cleaning distributed recycle bins according to claim 1, characterized in that: It also includes the directory determination steps when restoring files: Before restoring files, check whether the target directory exists; If the target directory does not exist, create the corresponding directory on the node where the file is located and obtain the directory information of the target path; Using the directory information of the target path and the inode information of the file, the dentry and new inode data of the file are rebuilt at the target location.

5. The method for flexibly restoring and cleaning distributed recycle bins according to claim 1, characterized in that: In the step of completely deleting the file, if the file is still occupied when it is deleted, the file information is put into the pre-deletion queue, and after the file occupation is released, the file information is put into the GC task queue for cleaning.

6. A method for flexibly restoring and cleaning distributed recycle bins according to claim 1, characterized in that: It also includes regular sorting and cleaning of metadata stored in the rocksdb database to ensure efficient use of recycle bin space and stable operation of the system.

7. A distributed file storage system implementing the method according to any one of claims 1 to 6, characterized in that: The system includes: Storage unit, used to store metadata information of RocksDB database and its files; A processing unit that performs the following operations: When a file is deleted, the file metadata information is stored in the rocksdb database and an index is created; Receive file recovery requests, retrieve and restore files from the rocksdb database; Receive a request to completely delete a file, add the file metadata to the GC task queue, and have the GC thread clean it up asynchronously; Index management unit, used to maintain indexes in the rocksdb database, supporting fast query and filtering; Recycle Bin space management unit, used to allocate independent Recycle Bin space for each user directory and ensure resource isolation; GC task management unit, used to manage GC task queues and perform asynchronous deletion of files; User interface, used to receive user's file recovery and deletion requests and display the operation results.

8. 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, the method for flexible recovery and cleaning of a distributed recycle bin according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a processor, the steps of the method for flexible recovery and cleaning of a distributed recycle bin as described in any one of claims 1 to 6 are implemented.

Images