A distributed file system orphan file semantic provenance lazy recovery method

Abstract

This invention discloses a semantic tracing and lazy reclamation method for orphan files in a distributed file system, belonging to the field of distributed file system technology. This method persists directory entry change operations through full-link logging and establishes an independent operation log index for each inode. It monitors changes in the inode hard link count in real time, marks files to be classified as orphan files when the hard link count reaches zero, and triggers the semantic tracing process. It traces back the file's entire lifecycle relationships to complete the classification, matches the corresponding hierarchical reclamation strategy based on the classification results, and generates a read-only snapshot before releasing space when the reclamation trigger conditions are met. This method can accurately distinguish different types of orphan files, reduce resource consumption during the reclamation process, avoid accidental deletion of business data, balance storage space reclamation efficiency and data security, and improve the operational stability of the distributed file system.

Description

Technical Field

[0001] This invention relates to the field of distributed file system technology, and in particular to a method for semantic tracing and lazy reclamation of orphan files in a distributed file system. Background Technology

[0002] Distributed file systems (DFS), as the core infrastructure for massive data storage and management, are widely used in cloud computing, big data analytics, artificial intelligence training, internet services, and other fields, providing highly available, scalable, and high-performance file storage services for various business systems. With the continuous growth of data scale and the increasing richness of business scenarios, the architecture of DFS has evolved, forming a mainstream architecture centered on the separation of metadata clusters and storage nodes. By storing file metadata separately from data blocks, the overall performance and scalability of the system are improved. Currently, mainstream DFSs are POSIX semantic specifications, using inodes as the basic storage unit for file metadata. File path access is achieved through the association between directory entries and inodes, and hard link counting records the number of directory entries pointing to the same inode, serving as the core criterion for file space reclamation. Simultaneously, various DFSs are continuously optimizing in areas such as metadata synchronization, data redundancy backup, and automatic fault recovery, gradually forming a mature technical system and industry standards.

[0003] Current distributed file systems have significant shortcomings in orphan file management. When the hard link count of an inode becomes 0, the system typically triggers an immediate space release process for the inode and its corresponding data block, making it impossible to determine the business validity of orphan files. Due to the lack of a complete full-link record of directory entry changes, the system cannot trace the entire lifecycle of inode relationships and can only identify orphan files by fully scanning all inodes and directory entries. This process requires traversing all metadata, consuming significant cluster computing and I / O resources. Furthermore, existing technologies cannot distinguish between valid business files whose directory entries are lost due to abnormal circumstances and obsolete files actively deleted by the business. They can only use indiscriminate forced reclamation, which carries the risk of accidental deletion of business data. In addition, existing technologies lack a tiered reclamation mechanism and pre-reclamation backup measures, making it impossible to set different reclamation strategies based on the business importance of files, and making it difficult to balance storage space reclamation efficiency with business data security. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of the prior art and provide a semantic source tracing lazy recycling method for orphan files in a distributed file system.

[0005] The objective of this invention is achieved through the following technical solution: A semantic-based lazy reclamation method for orphan files in a distributed file system is provided, which includes the following steps: S1. Persist the entire chain of directory entry change operations, record the association and deassociation operations between directory entries and inodes, and create an independent operation log index for each inode; S2. Monitor the hard link count of inodes in the metadata. When the hard link count of an inode changes from greater than or equal to 1 to 0, mark the inode as an orphan file to be determined, lock the inode, and trigger the semantic tracing process of the inode. S3. Retrieve the full-link operation log corresponding to the inode through the operation log index, trace back the directory entry association relationship of the inode throughout its entire life cycle, analyze the reason why the hard link count of the inode becomes 0, and combine the inode's historical access records, business affiliation and file type to complete the classification of the orphan files to be determined. S4. Based on the classification results of the orphan files to be determined, match the corresponding hierarchical reclamation strategy. When the orphan files to be determined meet the reclamation triggering conditions, first generate a read-only snapshot of the full data block corresponding to the inode, and then trigger the space release process of the metadata and data block corresponding to the inode.

[0006] Furthermore, step S1 includes the following sub-steps: S1.1. Embed log collection hooks in all directory item operation entry points of the metadata node. The directory item operation entry points include the file system call processing layer and the metadata transaction commit layer. The log collection hooks are implemented using system call interception technology to capture all operations that affect the association between inode and directory item in real time. These operations include hard link creation, hard link deletion, renaming, directory deletion, file creation, and file deletion. S1.2. Record the globally unique operation identifier, operation timestamp, operation type, operation subject, target inode number, original file path corresponding to the inode, hard link count before and after the operation, full path of directory entry changes, file business level label and inode lifecycle attributes for each captured operation log. S1.3. Persist the completed operation log to the metadata storage pool by appending the write operation. Build an operation log index based on the inode number in the operation log. The operation log index uses a hash table structure to store the mapping from inode number to log offset. Retrieve all directory entry change operations of the inode throughout its entire lifecycle by using the inode number.

[0007] Furthermore, step S2 includes the following sub-steps: S2.1. Embed hard link count change detection logic in the inode update transaction of the metadata node. Whenever the hard link count of the inode is updated, obtain the value of the hard link count of the inode in real time. S2.2. When the hard link count of the inode is detected to change from greater than or equal to 1 to 0, the system call for inode release is intercepted, and the release process of the inode and the corresponding data block is terminated. S2.3. Add a pending orphan file marker to the inode, store the pending orphan file marker in the extended attributes of the inode, record the marker timestamp, store the marker timestamp in the extended attributes of the inode, and set the inode's status to pending classification.

[0008] Furthermore, step S3 includes the following sub-steps: S3.1. Retrieve the operation log index by inode number, obtain the full-link operation log corresponding to the inode, and extract the directory entry association information of the inode's entire lifecycle; S3.2. Extract the corresponding operation record from the full-link operation log where the hard link count of the inode becomes 0, and analyze the reason why the hard link count of the inode becomes 0. S3.3. Obtain the historical access records, business ownership, and file type information of the inode. The historical access records are extracted from the access log of the file system. S3.4. Divide the orphan files to be determined into orphan files with valid abnormal business, orphan files to be confirmed, and abandoned orphan files. Mark the classification result for each orphan file to be determined, record the tracing process and the judgment basis, and store the classification result, tracing process and judgment basis in the extended attributes of the inode and persist them to the metadata.

[0009] Furthermore, in step S4, based on the classification results of the orphan files to be determined, a corresponding hierarchical recycling strategy is matched. A first-level recycling strategy is matched for valid orphan files with abnormal business, a protection period is set, an alarm is triggered to the administrator, and file traceability information and recovery entry are pushed. A second-level recycling strategy is matched for orphan files to be confirmed, a delayed recycling period is set, and access requests to the files are continuously monitored. A third-level recycling strategy is matched for abandoned orphan files, and a delayed recycling period is set. When the corresponding period of the orphan file to be determined ends, and there are no business access operations, no manual recovery operations, and no business appeal operations, the orphan file to be determined is determined to meet the recycling triggering conditions.

[0010] Furthermore, in step S4, when generating a read-only snapshot of the full data block corresponding to the inode, a copy-on-write technique is used to generate the read-only snapshot. The read-only snapshot contains reference information of all data blocks corresponding to the inode and metadata information of the inode. The metadata information of the inode includes the basic attributes, extended attributes and operation log index of the inode. The read-only snapshot is persisted to the archive storage pool, a unique identifier is assigned to each read-only snapshot, the association between the read-only snapshot and the corresponding inode is recorded, and the read-only snapshot is retained until the end of the set backup cycle.

[0011] Furthermore, in step S4, when the space release process of the inode's corresponding metadata and data block is triggered, the data block corresponding to the inode is first marked as free, the data block bitmap information of the storage node is updated, and then the inode's metadata information is cleared. The inode's metadata information includes the inode's basic attributes, extended attributes, and operation log index. At the same time, the recycling record in the metadata is updated, and the recycling record is persisted to the recycling log file of the metadata storage pool.

[0012] Furthermore, in step S4, when the space release process of the metadata and data block corresponding to the inode is triggered, the CPU utilization, memory utilization and IO throughput of the metadata node and storage node are collected periodically to calculate the comprehensive value of the cluster business load. The space release process is only executed when the cluster business load is lower than the set threshold. When the cluster business load is higher than the set threshold, all space release processes are paused and the current execution progress is saved.

[0013] Furthermore, in step S4, files are divided into different service levels according to the file service level tags recorded in step S1. For each service level file, a protection period for the first-level recycling strategy, a delayed recycling period for the second-level recycling strategy, and a delayed recycling period for the third-level recycling strategy are set respectively. A permanent protection period is set for the files with the set service level.

[0014] Furthermore, in step S4, when the space release process of the metadata and data block corresponding to the inode is triggered, the inodes that meet the recycling trigger conditions are sorted according to the order of the timestamps recorded in step S2. The sorted inodes are divided into multiple batches, and the number of inodes in each batch does not exceed a set threshold. The space release process of each batch is executed in sequence. After each batch is completed, the space release process of the next batch is executed after a set time interval is waited.

[0015] The beneficial effects of this invention are: (1) By persisting the full-link log of directory item change operations, combined with real-time marking and semantic source classification of orphan files, we can accurately distinguish different types of orphan files and avoid the risk of business data loss caused by indiscriminate forced reclamation; (2) By replacing the traditional full scan method with a real-time triggering mechanism based on changes in hard link count, the orphan file identification process significantly reduces the consumption of cluster computing power and IO resources, and reduces the impact of recycling operations on normal business operations; (3) By combining the hierarchical lazy reclamation strategy and the cluster load-aware space release mechanism with the snapshot backup process before reclamation, the efficiency of storage space reclamation and the security of business data are balanced, thereby improving the operational stability of the distributed file system. Attached Figure Description

[0016] Figure 1 A flowchart illustrating the steps of a semantic source tracing and lazy garbage collection method for orphan files in a distributed file system; Figure 2 The flowchart illustrates the specific steps of a semantic tracing and lazy reclamation method for orphan files in a distributed file system, as provided in this embodiment. Detailed Implementation

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

[0018] Example 1 See Figure 1 This embodiment provides a method for semantic tracing and lazy reclamation of orphan files in a distributed file system, which includes the following steps: S1. Persist the entire chain of directory entry change operations, record the association and deassociation operations between directory entries and inodes, and create an independent operation log index for each inode; S2. Monitor the hard link count of inodes in the metadata. When the hard link count of an inode changes from greater than or equal to 1 to 0, mark the inode as an orphan file to be determined, lock the inode, and trigger the semantic tracing process of the inode. S3. Retrieve the full-link operation log corresponding to the inode through the operation log index, trace back the directory entry association relationship of the inode throughout its entire life cycle, analyze the reason why the hard link count of the inode becomes 0, and combine the inode's historical access records, business affiliation and file type to complete the classification of the orphan files to be determined. S4. Based on the classification results of the orphan files to be determined, match the corresponding hierarchical reclamation strategy. When the orphan files to be determined meet the reclamation triggering conditions, first generate a read-only snapshot of the full data block corresponding to the inode, and then trigger the space release process of the metadata and data block corresponding to the inode.

[0019] In some embodiments, step S1 includes the following sub-steps: S1.1. Embed log collection hooks in all directory item operation entry points of the metadata node. The directory item operation entry points include the file system call processing layer and the metadata transaction commit layer. The log collection hooks are implemented using system call interception technology to capture all operations that affect the association between inode and directory item in real time. These operations include hard link creation, hard link deletion, renaming, directory deletion, file creation, and file deletion. S1.2. Record the globally unique operation identifier, operation timestamp, operation type, operation subject, target inode number, original file path corresponding to the inode, hard link count before and after the operation, full path of directory entry changes, file business level label and inode lifecycle attributes for each captured operation log. S1.3. Persist the completed operation log to the metadata storage pool by appending the write operation. Build an operation log index based on the inode number in the operation log. The operation log index uses a hash table structure to store the mapping from inode number to log offset. Retrieve all directory entry change operations of the inode throughout its entire lifecycle by using the inode number.

[0020] In some embodiments, step S2 includes the following sub-steps: S2.1. Embed hard link count change detection logic in the inode update transaction of the metadata node. Whenever the hard link count of the inode is updated, obtain the value of the hard link count of the inode in real time. S2.2. When the hard link count of the inode is detected to change from greater than or equal to 1 to 0, the system call for inode release is intercepted, and the release process of the inode and the corresponding data block is terminated. S2.3. Add a pending orphan file marker to the inode, store the pending orphan file marker in the extended attributes of the inode, record the marker timestamp, store the marker timestamp in the extended attributes of the inode, and set the inode's status to pending classification.

[0021] In some embodiments, step S3 includes the following sub-steps: S3.1. Retrieve the operation log index by inode number, obtain the full-link operation log corresponding to the inode, and extract the directory entry association information of the inode's entire lifecycle; S3.2. Extract the corresponding operation record from the full-link operation log where the hard link count of the inode becomes 0, and analyze the reason why the hard link count of the inode becomes 0. S3.3. Obtain the historical access records, business ownership, and file type information of the inode. The historical access records are extracted from the access log of the file system. S3.4. Divide the orphan files to be determined into orphan files with valid abnormal business, orphan files to be confirmed, and abandoned orphan files. Mark the classification result for each orphan file to be determined, record the tracing process and the judgment basis, and store the classification result, tracing process and judgment basis in the extended attributes of the inode and persist them to the metadata.

[0022] In some embodiments, in step S4, based on the classification results of the orphan files to be determined, a corresponding hierarchical recycling strategy is matched. A first-level recycling strategy is matched for valid orphan files of abnormal services, a protection period is set, an alarm is triggered to the administrator, and file traceability information and recovery entry are pushed. A second-level recycling strategy is matched for orphan files to be confirmed, a delayed recycling period is set, and access requests to the files are continuously monitored. A third-level recycling strategy is matched for abandoned orphan files, and a delayed recycling period is set. When the corresponding period of the orphan file to be determined ends, and there are no business access operations, no manual recovery operations, and no business appeal operations, the orphan file to be determined is determined to meet the recycling triggering conditions.

[0023] In some embodiments, when generating a read-only snapshot of the full data block corresponding to the inode in step S4, a copy-on-write technique is used to generate the read-only snapshot. The read-only snapshot contains reference information of all data blocks corresponding to the inode and metadata information of the inode. The metadata information of the inode includes the basic attributes, extended attributes and operation log index of the inode. The read-only snapshot is persisted to the archive storage pool, a unique identifier is assigned to each read-only snapshot, the association between the read-only snapshot and the corresponding inode is recorded, and the read-only snapshot is retained until the end of the set backup cycle.

[0024] In some embodiments, when the space release process of the inode corresponding metadata and data block is triggered in step S4, the data block corresponding to the inode is first marked as free, the data block bitmap information of the storage node is updated, and then the metadata information of the inode is cleared. The metadata information of the inode includes the basic attributes, extended attributes and operation log index of the inode. At the same time, the recycling record in the metadata is updated and the recycling record is persisted to the recycling log file of the metadata storage pool.

[0025] In some embodiments, when the space release process of the metadata and data block corresponding to the inode is triggered in step S4, the CPU utilization, memory utilization and IO throughput of the metadata node and storage node are collected periodically, the comprehensive value of the cluster business load is calculated, and the space release process is executed only when the cluster business load is lower than the set threshold. When the cluster business load is higher than the set threshold, all space release processes are paused and the current execution progress is saved.

[0026] In some embodiments, in step S4, files are divided into different service levels according to the file service level tags recorded in step S1, and a protection period of the first-level recycling strategy, a delayed recycling period of the second-level recycling strategy, and a delayed recycling period of the third-level recycling strategy are set for each service level file, and a permanent protection period is set for the files with the set service level.

[0027] In some embodiments, when the space release process of the metadata and data block corresponding to the inode is triggered in step S4, the inodes that meet the recycling trigger conditions are sorted according to the order of the timestamps recorded in step S2. The sorted inodes are divided into multiple batches, and the number of inodes in each batch does not exceed a set threshold. The space release process of each batch is executed in sequence. After each batch is completed, the space release process of the next batch is executed after a set time interval is waited.

[0028] Example 2 This embodiment provides a specific implementation process for a semantic tracing and lazy reclamation method for orphan files in a distributed file system. This method is deployed based on the metadata cluster and storage node architecture of the distributed file system, is compatible with existing POSIX semantic specifications, and achieves effective management of orphan files in the distributed file system through full-link recording of directory entry change operations, real-time marking and classification of orphan files, execution of a hierarchical lazy reclamation strategy, and a secure space release process. For example... Figure 2 As shown, the specific implementation process is as follows: Step 1. Log persistence and index building: Step 1.1. Log Collection Hook Deployment: A log collection hook is a code snippet embedded in the system execution flow to capture specific system operations and obtain system running status information without modifying the original business logic. In this embodiment, the log collection hook is deployed in the file system call processing layer and metadata transaction commit layer of the metadata node, and is implemented using system call interception technology. System call interception technology refers to inserting custom code before and after system call execution by modifying the system call table or using kernel modules to capture the parameters and execution results of the system call. It is a standard technology for obtaining operation information at the operating system level. In this embodiment, the log collection hook is used to capture all operations that affect the association between inodes and directory entries in real time, including hard link creation, hard link deletion, renaming, directory deletion, file creation, and file deletion.

[0029] Step 1.2. Operation Log Content Recording: An inode is the basic data structure in a distributed file system used to store file metadata. Each file corresponds to a unique inode, containing information such as file permissions, owner, size, creation time, modification time, and data block location. It is the basic unit for file system management. In this embodiment, each captured operation log record a globally unique operation identifier, operation timestamp, operation type, operation subject, target inode number, original file path corresponding to the inode, hard link count before and after the operation, full path of directory entry changes, file service level tag, and inode lifecycle attributes. The hard link count is a field in the inode used to record the number of directory entries pointing to that inode. When the hard link count is 0, the file corresponding to that inode is usually reclaimed by the system. The file service level tag is a metadata field used to identify the importance of the file; different service levels correspond to different reclamation strategies. The inode lifecycle attributes are used to record the state changes of the inode throughout its creation and reclamation process.

[0030] In some specific implementations, the field definitions and recording rules of the directory entry change operation log are shown in Table 1. Each field is serialized and stored according to a fixed byte order to ensure a consistent log format across different metadata nodes. The operation type field uses enumerated values ​​to represent different directory entry operations, facilitating subsequent log parsing and processing. The target inode number field uniquely identifies the file corresponding to the operation and is a key field for building the operation log index. The hard link count field before and after the operation records changes in the hard link count and is the core basis for detecting orphan files. The file business level label field inherits from the metadata set when the file is created. If no business level label is set when the file is created, the default business level label is used. The inode lifecycle attribute field records information such as the inode's creation time, modification time, and access time, which helps determine the business validity of the file. After the log serialization is completed, it is first written to the memory buffer of the metadata node. When the buffer reaches a set size or a set time interval, it is written in batches to the metadata storage pool to reduce the number of disk I / O operations.

[0031] Table 1. Table of Fields in the Directory Item Change Operation Log Field Name Field type Field length Field Function Globally unique operation identifier String 32 bytes Each operation log is uniquely identified Operation timestamp Integer 8 bytes Record the time when the operation occurred Operation type enumerate 1 byte Identify the type of operation for directory entries. Operating entity String 16 bytes Record the user or process that performed the operation. Target inode number Integer 8 bytes Identify the file corresponding to the operation Hard link count before operation Integer 4 bytes Record hard link count before operation Hard link count after operation Integer 4 bytes Record hard link count after operation Full path to directory entry change String 256 bytes Record the full path of directory entry changes Document Business Level Label Integer 1 byte The business importance level of the identification document inode lifecycle attributes binary 64 bytes Record inode lifecycle information Step 1.3. Operation Log Persistence and Index Construction: Append-only writing is a file writing method where all newly written data is added to the end of the file without overwriting existing data. It has the advantages of fast writing speed and low data loss, making it a commonly used writing method for log files. In this embodiment, the completed operation log is persisted to the metadata storage pool using append-only writing. The metadata storage pool is a dedicated storage area in a distributed file system for storing metadata, typically composed of multiple metadata nodes, providing highly available and high-performance metadata access services. Then, an operation log index is built based on the inode number in the operation log. The operation log index uses a hash table structure to store the mapping from inode number to log offset. A hash table is a data structure that directly accesses the memory storage location based on a key, offering the advantage of fast lookup speed, with an average lookup time complexity of constant level. Through the operation log index, all directory entry change operations throughout the entire lifecycle of an inode can be quickly retrieved by inode number without traversing the entire log file.

[0032] In some specific implementations, a periodic cleanup process for directory entry change operation logs is executed to address the issue of continuously growing operation logs consuming metadata storage pool space. The log cleanup process is performed during periods when cluster workload is below a set threshold, avoiding competition for system resources with business operations and space release processes. First, all operation log files in the metadata storage pool are traversed. Based on the target inode number in the operation log, the corresponding inode status is retrieved. If the inode has completed its space release process and the corresponding read-only snapshot has exceeded its backup cycle, all operation logs corresponding to that inode are marked as cleanable. If the inode is still in a pending classification state, protection period state, or delayed reclamation period state, all operation logs corresponding to that inode are retained until the inode completes its space release process and the corresponding read-only snapshot exceeds its backup cycle. Then, the operation logs marked as cleanable are removed from the operation log files, and the operation log index is updated, deleting the index entry for the corresponding inode number. Finally, a log cleanup record is generated, recording the number of cleaned operation logs, the number of inodes involved, and the cleanup time. This log cleanup record is persisted to the system log file of the metadata storage pool. The log cleanup process is executed periodically at set time intervals to ensure that the space occupied by the metadata storage pool remains within a reasonable range, while ensuring that the operation logs of orphan files that have not been processed are complete and usable, providing a basis for subsequent semantic tracing and classification.

[0033] In some embodiments, operation logs can be persisted using write-ahead logging, where the operation log is written to a log file before the actual directory entry change operations are performed. Write-ahead logging is a common technique in databases and file systems used to ensure data consistency in the event of a system crash. When a system crashes, unfinished operations can be recovered by replaying the write-ahead logs, preventing data loss or inconsistency.

[0034] Step 2. Real-time tagging of orphan files: Step 2.1. Hard Link Count Change Detection: An inode update transaction is an atomic operation unit within the metadata node used to perform inode metadata updates. It either succeeds entirely or fails entirely to ensure metadata consistency and is the fundamental mechanism for metadata management in distributed file systems. In this embodiment, hard link count change detection logic is embedded in the inode update transaction of the metadata node. Each time the inode's hard link count is updated, the value of the inode's hard link count is obtained in real time. This detection logic is executed before the transaction is committed to ensure that changes in the hard link count are captured in a timely manner, preventing the inode from being released before the detection is completed.

[0035] In some specific implementations, a pre-detection and early warning process for abnormal fluctuations in hard link counts is executed to identify potential orphan file risks in advance and avoid data unavailability caused by abnormal directory entry loss. First, a historical record of hard link count changes is established for each inode, recording the number and magnitude of hard link count changes within a set time range. When the number of changes in the hard link count of a certain inode within the set time range exceeds a set threshold, or the magnitude of the change exceeds a set threshold, the pre-detection process is triggered. The pre-detection process retrieves the recent directory entry change operation logs corresponding to the inode through the operation log index to analyze the reasons for abnormal fluctuations in hard link counts. If incomplete renaming operations, batch hard link deletion operations, or parent directory modification operations are found, an early warning is triggered to the administrator, pushing the basic information of the inode and an operation log summary. Simultaneously, the inode is marked as a high-risk inode, and the monitoring frequency of hard link counts is increased until the hard link count stabilizes or the corresponding operation is completed. For high-risk inodes, the retention time of their corresponding operation logs is extended to ensure complete semantic tracing and data recovery in the event of an anomaly.

[0036] Step 2.2. File Release Process Interception: When the hard link count of an inode changes from greater than or equal to 1 to 0, the system call for inode release is intercepted, terminating the release process of the inode and its corresponding data block. System calls are the interface between user-space programs and the kernel. The inode release system call is used to notify the kernel to reclaim the metadata and data block space corresponding to the inode. In traditional distributed file systems, when the hard link count of an inode becomes 0, the system immediately triggers the inode release process, reclaiming the corresponding space. In this embodiment, by intercepting this system call, the accidental release of orphan files can be avoided, providing time for subsequent semantic tracing and classification.

[0037] Step 2.3. Orphan File Tagging and Status Setting: Add an orphan file tag to the inode and store the tag in the inode's extended attributes. Extended attributes are a POSIX standard-defined extended storage area for file metadata, allowing users and applications to associate additional metadata with files without modifying the basic file system structure. They are widely used in scenarios such as file tags and access control lists. In this embodiment, extended attributes store information such as the orphan file tag, tag timestamp, classification result, tracing process, and judgment criteria. Simultaneously, the tag timestamp is recorded and stored in the inode's extended attributes, setting the inode's status to "pending classification." The tag timestamp is used to determine the start time of the subsequent recycling cycle, and the "pending classification" status indicates that the inode is awaiting semantic tracing and classification processing.

[0038] In some specific implementations, a cross-metadata node orphan file status synchronization process is executed to resolve the issue of inconsistent states among different nodes in a distributed metadata cluster. When a metadata node marks an inode as an orphan file to be determined and sets its status, it immediately sends a status synchronization request to other metadata nodes in the cluster. The status synchronization request includes the inode number, the orphan file mark, the mark timestamp, and the classification status information. Upon receiving the status synchronization request, other metadata nodes update the metadata information of the inode stored locally, add the corresponding mark and status information, and return a synchronization confirmation to the sending node. If a metadata node does not return a synchronization confirmation within a set time, the sending node will resend the status synchronization request until all metadata nodes have completed synchronization. When the classification result or reclamation status of an inode changes, the same status synchronization process is executed to ensure that the orphan file status of all metadata nodes in the cluster remains consistent, avoiding duplicate processing, omissions, or status conflicts.

[0039] In some embodiments, the operation log index can use a B+ tree structure to store the mapping from inode numbers to log offsets. A B+ tree is a balanced multi-way search tree, offering advantages such as high search efficiency and support for range queries, making it a commonly used index structure in databases and file systems. Compared to hash tables, B+ trees are more suitable for scenarios requiring range queries, such as retrieving all directory entry change operations within a specific time period.

[0040] Step 3. Document semantic tracing and classification: Step 3.1. Full-Link Operation Log Retrieval: Retrieve the operation log index by inode number to obtain the full-link operation log corresponding to the inode, and extract the directory entry association information throughout the inode's entire lifecycle. The operation log index is constructed in Step 1. The inode number allows for quick location of all operation logs corresponding to that inode, thus obtaining a complete operation record. The full-link operation log contains all directory entry change operations from the inode's creation to the current moment, fully reflecting the changes in the inode's association relationships.

[0041] Step 3.2. Analysis of Hard Link Count Reaching Zero: Extract the corresponding operation records from the end-to-end operation logs where the hard link count of an inode becomes 0, and analyze the reasons why the hard link count of the inode becomes 0. The operation records contain information such as operation type, operation subject, and operation time. By analyzing this information, it can be determined whether the hard link count becoming 0 is due to a proactive deletion operation by the business or due to the loss of directory entries caused by abnormal circumstances. For example, if the operation record shows that the deletion operation was performed by a legitimate business user, then the file corresponding to the inode may be a discarded file; if the operation record shows that a node crashed during a renaming operation, then the file corresponding to the inode may be a valid business file; if the operation record shows that the parent directory was deleted, then the file corresponding to the inode may be an orphan file caused by directory cascading deletion.

[0042] Step 3.3. File Attribute Information Acquisition: Obtain the inode's historical access records, business affiliation, and file type information. Historical access records are extracted from the file system's access log. The file system's access log records all file access operations, including read, write, open, and close operations. By analyzing historical access records, we can understand the file's usage frequency and recent usage time, thus determining whether the file is still being used by the business. Business affiliation information is used to determine the business department or system to which the file belongs, and file type information is used to distinguish different types of files, such as database files, virtual machine image files, log files, and configuration files. Different types of files have different importance and usage characteristics, providing a basis for classification.

[0043] Step 3.4. Orphan File Classification and Result Storage: Orphan files to be determined are classified into three categories: valid orphan files for abnormal business operations, orphan files to be confirmed, and discarded orphan files. Valid orphan files for abnormal business operations refer to inodes with a hard link count of 0 due to non-active deletion operations and existing business access records. Orphan files to be confirmed refer to inodes whose business validity cannot be clearly determined. Discarded orphan files refer to inodes with a hard link count of 0 due to active deletion operations and no business access records. Each orphan file to be determined is marked with a classification result, and the tracing process and judgment criteria are recorded. The classification result, tracing process, and judgment criteria are stored in the extended attributes of the inode and persisted to the metadata. The tracing process and judgment criteria are used for subsequent manual review and troubleshooting to ensure the traceability of the classification results.

[0044] In some specific implementations, the classification rules for orphan files are shown in Table 2. Classification is performed in descending order of priority; if a high-priority classification condition is met, a low-priority classification is not performed. The determination of valid orphan files for abnormal business operations takes precedence over pending orphan files and discarded orphan files, ensuring that valid business files are not mistakenly reclaimed. The reason for a hard link count reaching zero is determined by analyzing the operation type and operator information in the operation log. If the operation log contains records of incomplete renaming operations or parent directory deletion operations, it is determined to be a non-intentional deletion operation. Business access records are determined by retrieving the file system's access log. If read or write operation records exist within a set time range, it is determined that business access records exist. The legitimacy of the operator is determined by verifying the operator's permission information. If the operator has deletion permissions for the corresponding file, it is determined to be a legitimate operator. After classification, the classification results and judgment criteria are written to the inode's extended attributes and the classification results are synchronized to the metadata cluster to ensure consistency of classification information across all metadata nodes.

[0045] Table 2. Rules for Classifying Orphan Documents Classification type Reasons for hard link count reaching zero Business access records Legality of the operating entity Category Priority Valid orphan files for abnormal business Non-active deletion operation exist legitimate 1 Valid orphan files for abnormal business Non-active deletion operation Does not exist legitimate 2 Orphan documents pending confirmation Unable to determine exist Unable to determine 3 Orphan documents pending confirmation Unable to determine Does not exist Unable to determine 4 Discarded orphan files Active deletion operation Does not exist legitimate 5 In some embodiments, incremental snapshot technology can be used to generate read-only snapshots. Incremental snapshots are snapshot technologies that only record data blocks that have changed since the last snapshot. Compared to full snapshots, incremental snapshots occupy less storage space and are generated faster. In this embodiment, incremental snapshots can be used to back up frequently modified files, reducing the storage resource consumption of snapshots.

[0046] Step 4. Tiered Recycling and Space Management: Step 4.1. Tiered Reclamation Strategy Matching: Based on the classification results of the orphan files to be determined, match the corresponding tiered reclamation strategy. For valid orphan files with abnormal business operations, match the first-level reclamation strategy, set a protection period, trigger an alarm to the administrator, and push file tracing information and recovery entry points. For orphan files awaiting confirmation, match the second-level reclamation strategy, set a delayed reclamation period, and continuously monitor file access requests. For obsolete orphan files, match the third-level reclamation strategy, setting a delayed reclamation period. Tiered reclamation strategy refers to a file space management strategy that sets different reclamation trigger conditions according to the file's risk level. By setting different reclamation strategies for different types of orphan files, storage space reclamation and data security can be balanced. The first-level reclamation strategy has the highest priority and is used to protect valid business files; the second-level reclamation strategy is used to handle files that cannot be clearly determined; and the third-level reclamation strategy is used to handle files that are definitely obsolete.

[0047] In some specific implementations, a manual recovery process for valid orphan files from abnormal business operations is implemented, providing administrators with a standardized file recovery operation path. Administrators access the file recovery interface through the recovery portal pushed by alarms. The interface displays the basic information of the inode, the entire operation log, classification results, and the tracing process. After confirming the file to be recovered, the administrator enters the target path for file recovery. The system first checks the legality and permissions of the target path to ensure its existence and that the administrator has write permissions. Then, a new directory entry is created under the target path, and the new directory entry is associated with the inode, increasing the inode's hard link count. Next, the inode's pending orphan file marker, classification result marker, and corresponding status information are cleared, restoring the inode's status to a normal state. Finally, a file recovery record is generated, recording the recovered inode number, original path, target path, recovery time, and operation subject, and persisted to the system log file in the metadata storage pool. After file recovery is complete, a successful recovery notification is sent to the administrator, and all recycling processes corresponding to that inode are terminated, ensuring that the file can be accessed normally by the business.

[0048] In some specific implementations, the configuration parameters of the tiered reclamation strategy are shown in Table 3. Files of different business levels correspond to different protection periods and delayed reclamation periods; the higher the business level, the longer the corresponding period. The first-level reclamation strategy applies to valid orphan files with abnormal business operations. During the protection period, any reclamation operation is prohibited, and an alarm is triggered to the administrator. The alarm information includes the file's inode number, original path, classification result, and tracing process. The second-level reclamation strategy applies to orphan files awaiting confirmation. During the delayed reclamation period, file access is continuously monitored. If access is detected, an alarm is triggered, and the delayed reclamation period is extended. The third-level reclamation strategy applies to abandoned orphan files. After the delayed reclamation period ends, these files enter a pending reclamation state, waiting for the space release process to execute. The reclamation strategy configuration is stored in the metadata cluster's configuration file, supports dynamic modification, and the modified configuration takes effect immediately without requiring a restart of the metadata node.

[0049] Table 3. Tiered Recycling Strategy Configuration Table Business Level Level 1 Recycling Strategy Protection Period The second-level recycling strategy delays the recycling period. The third-level recycling strategy delays the recycling period. Permanent protection mark Core Business Permanent protection System longest delay period System long delay period yes Key Business Long protection cycle of the system Long delay period in the system Delay period in the system no General business Protection cycle in the system Delay period in the system System short latency period no Temporary business short protection cycle of the system System short latency period The system has an extremely short latency period. no Step 4.2. Determining Recycling Trigger Conditions: When the corresponding period for a file to be classified as an orphan ends, and there are no business access operations, no manual recovery operations, and no business appeal operations, the file to be classified as an orphan is determined to meet the recycling trigger conditions. If there are business access operations or manual recovery operations during the protection period or delayed recycling period, it indicates that the file is still being used by the business, and the orphan file mark needs to be cleared, and the corresponding directory entry and hard link restored. If there are business appeal operations, the administrator needs to manually review the case to determine whether the file needs to be restored. Only when all conditions are met will the subsequent space release process begin to avoid accidental deletion of business data.

[0050] Step 4.3. Read-only Snapshot Generation and Archiving: When generating a read-only snapshot of the full data blocks corresponding to an inode, copy-on-write (COW) technology is used. COW is the standard technology for snapshot generation in existing file systems. Its basic principle is that when generating a snapshot, not all data blocks are copied immediately, but the data blocks of the original file are shared. When the data blocks of the original file are modified, the unmodified data blocks are copied to the snapshot. COW can greatly improve the speed of snapshot generation and reduce the consumption of system resources by snapshots. The read-only snapshot contains reference information of all data blocks corresponding to the inode and the metadata information of the inode. The metadata information of the inode includes the basic attributes, extended attributes, and operation log index of the inode. The read-only snapshot is persisted to the archive storage pool, a unique identifier is assigned to each read-only snapshot, the association between the read-only snapshot and the corresponding inode is recorded, and the read-only snapshot is retained until the end of the set backup cycle. The archive storage pool is a storage area in the distributed file system specifically used to store archived data. It usually uses low-cost, high-capacity storage media for long-term storage of data that is not frequently accessed.

[0051] In some specific implementations, an automatic cleanup process for read-only snapshots in the archive storage pool is executed to address the issue of read-only snapshots continuously occupying archive storage pool space. The snapshot cleanup process is executed periodically at set time intervals. First, all read-only snapshots in the archive storage pool are traversed, and their expiration time is calculated based on their creation time and the set backup cycle. If the current time exceeds the snapshot's expiration time, it checks whether the inode corresponding to the snapshot has completed the space release process. If the inode has completed the space release process, the snapshot is marked as cleanable. If the inode is still in the recycling process or there are unresolved business appeals, the snapshot is retained until the inode completes the space release process and the snapshot exceeds the backup cycle. Then, the read-only snapshot marked as cleanable is deleted from the archive storage pool, and the association record between the snapshot and its corresponding inode is also deleted. Finally, a snapshot cleanup record is generated, recording the number of snapshots cleaned, the number of inodes involved, and the cleanup time. This snapshot cleanup record is persisted to the system log file of the metadata storage pool. The snapshot cleanup process is executed during periods when the cluster's business load is below a set threshold to avoid affecting the normal read and write operations of the archive storage pool.

[0052] Step 4.4. Space Release Process Execution: When the space release process for the inode's corresponding metadata and data blocks is triggered, the data block corresponding to the inode is first marked as free, and the data block bitmap information of the storage node is updated. The data block bitmap is a standard data structure used by the storage node to manage the free status of data blocks. Each data block corresponds to a bit in the bitmap; a value of 0 indicates that the data block is free, and a value of 1 indicates that the data block is occupied. By updating the data block bitmap, the reclaimed data blocks can be reassigned to other files. Then, the inode's metadata information is cleared. The inode's metadata information includes the inode's basic attributes, extended attributes, and operation log index. At the same time, the reclamation record in the metadata is updated and persisted to the reclamation log file in the metadata storage pool. The reclamation log file is used to record all space reclamation operations, facilitating subsequent auditing and troubleshooting.

[0053] In some specific implementations, a storage consistency verification process is executed after space release to ensure that no data inconsistencies occur during the space release process. Immediately after the space release process is completed, a consistency verification process is triggered. First, the data block bitmap information of the storage node is read to check whether all data blocks corresponding to the inode have been correctly marked as free. Then, the inode metadata information of the metadata node is read to check whether the basic attributes, extended attributes, and operation log index of the inode have been correctly cleared. Next, the reclamation record in the metadata is checked to confirm that the reclamation record contains complete reclamation information for the inode. Finally, the operation log index is checked to confirm whether the index entry corresponding to the inode has been deleted. If all checks pass, the space release process is considered successfully completed; if any checks fail, an error handling process is triggered, and corresponding repair operations are performed according to the error type, such as updating the data block bitmap, clearing the inode metadata again, or regenerating the reclamation record. After the error handling process is completed, the consistency verification is executed again until all checks pass.

[0054] Step 4.5. Cluster Load Awareness Execution: When the space release process for the corresponding metadata and data blocks of an inode is triggered, the CPU utilization, memory utilization, and IO throughput of the metadata node and storage node are collected periodically to calculate a comprehensive value of the cluster's business load. CPU utilization refers to the proportion of time the CPU is used per unit of time, memory utilization refers to the proportion of system memory used, and IO throughput refers to the number of IO requests processed by the system per unit of time. By combining these three indicators, the business load of the cluster can be comprehensively reflected. The space release process is only executed when the cluster business load is below a set threshold. When the cluster business load is above the set threshold, all space release processes are paused, and the current execution progress is saved. This avoids space release operations competing for system resources with business operations, reducing the impact on business performance.

[0055] In some specific implementations, the calculation weights for the overall cluster service load are shown in Table 4. The overall cluster service load is calculated using a weighted summation method, with the overall value ranging from 0 to 1. CPU utilization, memory utilization, IO throughput, and network bandwidth are all normalized values, i.e., the actual value divided by the maximum value to obtain a value between 0 and 1. When the overall value is lower than a set threshold, a space release process is executed; when the overall value is higher than the set threshold, all space release processes are paused, the current execution progress is saved, and execution resumes from the saved progress once the overall value falls below the set threshold. Load data collection is accomplished through a monitoring agent deployed on each node. The monitoring agent periodically collects the node's load data and sends it to the cluster management node. The cluster management node aggregates the load data of all nodes and calculates the average overall load value of the cluster, which serves as the basis for deciding whether to execute the space release process.

[0056] Table 4. Cluster Load Comprehensive Calculation Weight Table Load metrics weight value Normalization method Data collection cycle CPU utilization 0.3 Actual value / Maximum value 10 seconds Memory usage 0.3 Actual value / Maximum value 10 seconds IO throughput 0.2 Actual value / Maximum value 10 seconds Network bandwidth 0.2 Actual value / Maximum value 10 seconds Step 4.6. Customizable Periods for Business Levels: Files are categorized into different business levels based on their business level tags. For each business level, a protection period for the first-level reclamation strategy, a delayed reclamation period for the second-level strategy, and a delayed reclamation period for the third-level strategy are set. A permanent protection period is also set for files with defined business levels. The file business level tags are recorded in Step 1. Different business levels have different requirements for data security and storage space reclamation efficiency. For example, for important business data files, a longer protection period or a permanent protection period can be set to ensure that data is not accidentally deleted; for temporary files or log files, a shorter delayed reclamation period can be set to improve storage space reclamation efficiency.

[0057] Step 4.7. Batch Reclamation Execution: When the space release process for the metadata and data blocks corresponding to an inode is triggered, the inodes that meet the reclamation trigger conditions are sorted according to the order of their timestamps. The sorted inodes are divided into multiple batches, with each batch containing no more than a set threshold of inodes. The space release process for each batch is executed sequentially. After each batch is completed, the system waits for a set time interval before executing the space release process for the next batch. Batch reclamation avoids the performance fluctuations of metadata nodes caused by reclamating a large number of inodes at once, improving system stability. The time interval is used to allow the system buffer time to handle possible business requests and avoid excessive pressure on the system from continuous reclamation operations.

[0058] In some embodiments, network bandwidth can be added as a load indicator when calculating the overall cluster workload. Network bandwidth refers to the amount of data transmitted over the network per unit time. For distributed file systems, network bandwidth is one of the important factors affecting system performance. By comprehensively considering CPU utilization, memory utilization, I / O throughput, and network bandwidth, the cluster's workload can be assessed more accurately, avoiding the need to perform space release operations when network bandwidth is insufficient.

[0059] In some embodiments, inodes can be batched according to file size, grouping inodes of similar size into the same batch. This avoids storage fragmentation caused by mixing files of different sizes for reclamation, thus improving storage space utilization.

[0060] This embodiment provides a complete basis for the identification and classification of orphan files by persisting end-to-end logs of directory entry change operations, avoiding the resource consumption of traditional full-scan methods. By monitoring changes in hard link counts in real time, orphan files can be promptly identified and marked, preventing accidental file release. Semantic tracing and classification distinguish different types of orphan files, allowing for different reclamation strategies and balancing storage space reclamation with data security. A tiered lazy reclamation strategy provides a protection period for valid business files and a delayed reclamation period for obsolete files, ensuring both business data security and improved storage space reclamation efficiency. A cluster load-aware space release process performs reclamation operations only during periods of low cluster business load, reducing the impact of reclamation operations on business performance. Snapshot backups and batch reclamation further enhance data security and system stability. This embodiment's method is compatible with existing POSIX semantic specifications, requires no modification to the underlying storage architecture, and can be smoothly deployed to existing distributed file systems, providing an effective solution for orphan file management in distributed file systems.

[0061] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A method for semantic sourcing and lazy garbage collection of orphan files in a distributed file system, characterized in that, Includes the following steps: S1. Persist the entire chain of directory entry change operations, record the association and deassociation operations between directory entries and inodes, and create an independent operation log index for each inode; S2. Monitor the hard link count of inodes in the metadata. When the hard link count of an inode changes from greater than or equal to 1 to 0, mark the inode as an orphan file to be determined, lock the inode, and trigger the semantic tracing process of the inode. S3. Retrieve the full-link operation log corresponding to the inode through the operation log index, trace back the directory entry association relationship of the inode throughout its entire life cycle, analyze the reason why the hard link count of the inode becomes 0, and combine the inode's historical access records, business affiliation and file type to complete the classification of the orphan files to be determined. S4. Based on the classification results of the orphan files to be determined, match the corresponding hierarchical reclamation strategy. When the orphan files to be determined meet the reclamation triggering conditions, first generate a read-only snapshot of the full data block corresponding to the inode, and then trigger the space release process of the metadata and data block corresponding to the inode.

2. The method according to claim 1, characterized in that, Step S1 includes the following sub-steps: S1.

1. Embed log collection hooks in all directory item operation entry points of the metadata node. The directory item operation entry points include the file system call processing layer and the metadata transaction commit layer. The log collection hooks are implemented using system call interception technology to capture all operations that affect the association between inode and directory item in real time. These operations include hard link creation, hard link deletion, renaming, directory deletion, file creation, and file deletion. S1.

2. Record the globally unique operation identifier, operation timestamp, operation type, operation subject, target inode number, original file path corresponding to the inode, hard link count before and after the operation, full path of directory entry changes, file business level label and inode lifecycle attributes for each captured operation log. S1.

3. Persist the completed operation log to the metadata storage pool by appending the write operation. Build an operation log index based on the inode number in the operation log. The operation log index uses a hash table structure to store the mapping from inode number to log offset. Retrieve all directory entry change operations of the inode throughout its entire lifecycle by using the inode number.

3. The method according to claim 1, characterized in that, Step S2 includes the following sub-steps: S2.

1. Embed hard link count change detection logic in the inode update transaction of the metadata node. Whenever the hard link count of the inode is updated, obtain the value of the hard link count of the inode in real time. S2.

2. When the hard link count of the inode is detected to change from greater than or equal to 1 to 0, the system call for inode release is intercepted, and the release process of the inode and the corresponding data block is terminated. S2.

3. Add a pending orphan file marker to the inode, store the pending orphan file marker in the extended attributes of the inode, record the marker timestamp, store the marker timestamp in the extended attributes of the inode, and set the inode's status to pending classification.

4. The method according to claim 1, characterized in that, Step S3 includes the following sub-steps: S3.

1. Retrieve the operation log index by inode number, obtain the full-link operation log corresponding to the inode, and extract the directory entry association information of the inode's entire lifecycle; S3.

2. Extract the corresponding operation record from the full-link operation log where the hard link count of the inode becomes 0, and analyze the reason why the hard link count of the inode becomes 0. S3.

3. Obtain the historical access records, business ownership, and file type information of the inode. The historical access records are extracted from the access log of the file system. S3.

4. Divide the orphan files to be determined into orphan files with valid abnormal business, orphan files to be confirmed, and abandoned orphan files. Mark the classification result for each orphan file to be determined, record the tracing process and the judgment basis, and store the classification result, tracing process and judgment basis in the extended attributes of the inode and persist them to the metadata.

5. The method according to claim 1, characterized in that, In step S4, based on the classification results of the orphan files to be determined, a corresponding hierarchical recycling strategy is matched. For valid orphan files with abnormal business, a first-level recycling strategy is matched, a protection period is set, an alarm is triggered to the administrator, and file traceability information and recovery entry are pushed. For orphan files to be confirmed, a second-level recycling strategy is matched, a delayed recycling period is set, and file access requests are continuously monitored. For abandoned orphan files, a third-level recycling strategy is matched, and a delayed recycling period is set. When the corresponding period of the orphan file to be determined ends, and there are no business access operations, no manual recovery operations, and no business appeal operations, the orphan file to be determined is determined to meet the recycling trigger conditions.

6. The method according to claim 1, characterized in that, In step S4, when generating a read-only snapshot of the full data block corresponding to the inode, the copy-on-write technique is used to generate the read-only snapshot. The read-only snapshot contains the reference information of all data blocks corresponding to the inode and the metadata information of the inode. The metadata information of the inode includes the basic attributes, extended attributes and operation log index of the inode. The read-only snapshot is persisted to the archive storage pool, a unique identifier is assigned to each read-only snapshot, the association between the read-only snapshot and the corresponding inode is recorded, and the read-only snapshot is retained until the end of the set backup cycle.

7. The method according to claim 1, characterized in that, In step S4, when the space release process of the inode's corresponding metadata and data block is triggered, the data block corresponding to the inode is first marked as free, the data block bitmap information of the storage node is updated, and then the metadata information of the inode is cleared. The metadata information of the inode includes the basic attributes, extended attributes and operation log index of the inode. At the same time, the reclamation record in the metadata is updated and the reclamation record is persisted to the reclamation log file of the metadata storage pool.

8. The method according to claim 1, characterized in that, In step S4, when the space release process of the metadata and data block corresponding to the inode is triggered, the CPU utilization, memory utilization and IO throughput of the metadata node and storage node are collected periodically to calculate the comprehensive value of the cluster business load. The space release process is only executed when the cluster business load is lower than the set threshold. When the cluster business load is higher than the set threshold, all space release processes are paused and the current execution progress is saved.

9. The method according to claim 5, characterized in that, In step S4, files are divided into different service levels according to the file service level tags recorded in step S1. For each service level file, a protection period for the first-level recycling strategy, a delayed recycling period for the second-level recycling strategy, and a delayed recycling period for the third-level recycling strategy are set. A permanent protection period is set for the files with the set service level.

10. The method according to claim 1, characterized in that, In step S4, when the space release process of the metadata and data block corresponding to the inode is triggered, the inodes that meet the recycling trigger conditions are sorted according to the order of the timestamps recorded in step S2. The sorted inodes are divided into multiple batches, and the number of inodes in each batch does not exceed the set threshold. The space release process of each batch is executed in sequence. After each batch is completed, the set time interval is waited before the space release process of the next batch is executed.

Images