Online repair methods, devices, equipment, media, and products for the XFS file system.

Abstract

This application discloses an online repair method, apparatus, device, medium, and product for the XFS file system. The method includes: when a metadata anomaly is detected, obtaining abnormal tuple information of the metadata; classifying the metadata anomaly level into Level 1, Level 2, or Level 3 anomalies based on the impact scope of the damaged objects and the log consistency status in the abnormal tuple information; when the anomaly level is Level 1 or Level 2, implementing a local isolation control strategy for the damaged objects to restrict them to a local isolation area; implementing a partitioned concurrent repair strategy within the local isolation area; and performing a forced shutdown operation when a Level 3 anomaly occurs. This application limits the scope of the fault impact to the damaged objects through anomaly classification and local isolation mechanisms, significantly reducing the impact of metadata anomalies on overall business availability. The partitioned concurrent repair strategy reduces global lock contention and global temporary storage hotspots, improving the efficiency and reliability of online repair.

Description

Technical Field

[0001] This application relates to the field of computer data storage technology, and in particular to an online repair method, apparatus, device, medium and product for the XFS file system. Background Technology

[0002] Currently, the XFS file system continuously verifies the consistency of critical metadata during operation. When the system detects that critical metadata is corrupted, the traditional approach is to directly enter a forced shutdown path to prevent further read and write operations and avoid the error from spreading. Although this approach is conservative and safe, it also means that the file system stops providing services immediately, which can easily lead to the interruption of services such as databases, storage services, and virtualization hosts.

[0003] In related technologies, to reduce the downtime caused by unmounting the file system during offline repair, the industry has proposed an online inspection and repair mechanism for the XFS file system. The difficulty of online repair lies in the fact that the repair thread needs to scan and rebuild metadata, while the foreground business thread is still continuously modifying inodes (objects used to describe file or directory metadata), directory entries, free space, and btree structures. If the repair process holds locks excessively, it will significantly slow down the foreground business; if there is not enough synchronization and consistency control, unreliable repair results may be obtained.

[0004] Therefore, the online repair of the XFS file system using related technologies has the following drawbacks: (1) After detecting metadata anomalies, immediately force the entire XFS file system to shut down. Forcefully shutting down the global file system will cause all normal objects to become unusable, and the recovery window will be long. (2) During the online repair process, holding the lock for a long time causes conflicts in file operations, and the conflict waiting time is long, resulting in lock contention; (3) Different repair threads may simultaneously contend for the same temporary storage structure to store abnormal node metadata information, leading to increased synchronization overhead; (4) If there are continuous incremental writes during the scanning period, the repair thread has difficulty in determining when it is safe to commit. If a step fails, the rollback range often needs to be expanded, which increases the rollback cost.

[0005] In view of this, there is a need to provide an optimized method, apparatus, device, and medium for online repair of the XFS file system to solve the problems existing in the related technologies. Summary of the Invention

[0006] The embodiments of this application adopt the following technical solutions: This application provides an online repair method for an XFS file system, the method comprising: When an abnormality in the metadata of the XFS file system is detected, the abnormal tuple information of the metadata is obtained. The abnormal tuple information includes at least one of the following: the type of damaged object, the allocation group identifier, the log consistency status, and the impact range of the damaged object. Based on the impact range of the damaged object and the log consistency status in the abnormal tuple information, the abnormality level of the metadata is divided into Level 1, Level 2, or Level 3 abnormality. When the anomaly level of the metadata is Level 1 or Level 2, a local isolation control strategy is implemented on the damaged object to restrict the damaged object to a local isolation area. A partitioned concurrent repair strategy is executed within the local isolation area. The partitioned concurrent repair strategy includes: dividing the repair task for the damaged object into multiple independent partitioned work areas, each of which performs online repair operations and submits repair results in a hierarchical manner to obtain the repaired object. When the metadata exception level is level three, a forced shutdown operation is performed on the XFS file system.

[0007] In some embodiments, when the anomaly level of the metadata is Level 1 or Level 2, a local isolation control strategy is implemented on the damaged object to restrict the damaged object to a local isolation area, including: Set a primary isolation flag and a secondary isolation flag in the damaged allocation group table or the damaged index node table; wherein, the primary isolation flag is used to identify the primary isolation status of the damaged object under the primary abnormality condition; the secondary isolation flag is used to identify the secondary isolation status of the damaged object under the secondary abnormality condition; When an access request is received for a damaged object with the first-level isolation tag, a response is returned that prohibits write operations and downgrades the status to read-only. When an access request is received for a compromised object with the secondary isolation tag, a response data that either denies access or returns an error message is returned.

[0008] In some embodiments, The abnormal tuple information also includes cross-validation rules, and the method further includes: When the online repair operation is successful, the primary isolation marker and the secondary isolation marker are removed, and normal access to the damaged object is restored. When the online repair operation fails and the scope of the impact does not expand, the local isolation state of the damaged object is maintained; When the online repair operation fails, and the impact of a newly damaged object exceeds the impact of the isolated object or the global invariant across the allocation group is damaged, a forced shutdown operation is triggered. Wherein, the impaired global invariant across allocation groups means that cross-validation through the cross-validation rules detects that the metadata consistency constraints between multiple allocation groups are not met. The metadata consistency constraints include at least one of the following: consistency of free space count between the superblock and each allocation group, consistency of the total number of index nodes across allocation groups, and integrity of space mapping across allocation groups.

[0009] In some embodiments, each of the said sharded workspaces includes at least one of the following: A scanning cursor is used to record the scanning progress of each of the aforementioned work areas; A local incremental record queue is used to store incremental records corresponding to each of the aforementioned work areas; Version watermark, used to identify the fix version for each of the aforementioned workspaces; A sharded repair patch set is used to store the repair results for each sharded work area; The failure rollback log is used to record rollback information when the online repair operation fails.

[0010] In some embodiments, The repair task for the damaged object is divided into multiple independent work areas, including: Based on the allocation group identifier, metadata type, and object key range of the damaged object, the repair task is divided into multiple independent shard work areas, and the repair tasks in each shard work area are executed in parallel. Wherein, the object key range represents a processing interval composed of multiple object keys, used to divide the scan boundaries of each of the segmented work areas; the object key is used to identify metadata objects, and the metadata objects include at least one of the following: inode, directory entry, free space block.

[0011] In some embodiments, the method further includes: The scanning concurrency is determined based on the system load, and a worker thread is allocated to each of the said work areas. Each of the aforementioned worker threads performs parallel scanning of the damaged objects within the corresponding sliced ​​work area and maintains the local scan status; When a modification operation on the metadata related to the damaged object is detected, a corresponding incremental record is generated and written to the local incremental record queue of the shard work area to which the damaged object belongs. The incremental record includes at least one of the following: object key, operation type, transaction sequence number and the identifier of the shard work area.

[0012] In some embodiments, the method further includes: When each of the sharded work areas meets the preset convergence conditions, it is determined that the shard repair patch set of each sharded work area can be submitted; wherein, the preset convergence conditions include at least one of the following: the scanning range of the scanning cursor has covered the target object range of the sharded work area, the local incremental record queue is empty, the version level remains stable within a preset period, and all cross-validations for the sharded work area pass. Based on the determination result that the fragment repair patch set can be submitted, the fragment repair patch set of each fragment work area is submitted in a hierarchical manner according to the dependency relationship between the metadata; When a fragment repair patch set fails to commit, only the fragment repair patch set that failed to commit is rolled back.

[0013] In some embodiments, the method further includes: When the concurrency of the scanning or merging threads in the worker threads reaches a preset threshold, batch consumption is performed on the incremental records in each of the local incremental record queues: Perform deduplication, sorting, and aggregation operations on the incremental records consumed in batches, and update the aggregated results to the temporary storage area of ​​the corresponding sharded work area.

[0014] In some embodiments, based on the impact scope of the damaged object in the abnormal tuple information and the log consistency status, the anomaly level of the metadata is divided into Level 1 anomaly, Level 2 anomaly, or Level 3 anomaly, including: When the impact of the damaged object is limited to a single enumerable object, and the log consistency status is undistorted, the abnormality level of the metadata is classified as Level 1 abnormality. When the impact of the damaged object is limited to a single allocation group and cross-allocation group consistency is not compromised, the anomaly level of the metadata is classified as a level two anomaly. When the impact of the damaged object exceeds a single allocation group, or the log consistency status indicates that the log replay correctness is compromised, or the integrity of the critical space mapping is compromised, or the scope of the damage cannot be determined, the abnormality level of the metadata is classified into three levels of abnormality.

[0015] This application embodiment also provides an online repair device for an XFS file system, the device comprising: An anomaly information acquisition unit is configured to acquire anomaly tuple information of the metadata when an anomaly is detected in the XFS file system. The anomaly tuple information includes at least one of the following: damaged object type, allocation group identifier, log consistency status, and the impact range of the damaged object. An anomaly classification unit is configured to classify the anomaly level of the metadata into Level 1, Level 2, or Level 3 anomalies based on the impact range of the damaged object and the log consistency status in the anomaly tuple information. The local isolation unit is configured to execute a local isolation control strategy on the damaged object when the anomaly level of the metadata is level one or level two, thereby restricting the damaged object to a local isolation area. The partitioned concurrent repair unit is configured to execute a partitioned concurrent repair strategy within the local isolation area. The partitioned concurrent repair strategy includes: dividing the repair task for the damaged object into multiple independent partitioned work areas, with each partitioned work area performing online repair operations and submitting repair results in a hierarchical manner to obtain the repaired object. The forced shutdown unit is configured to perform a forced shutdown operation on the XFS file system when the exception level of the metadata is level three.

[0016] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any of the preceding claims.

[0017] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in any of the preceding claims.

[0018] This application also provides a computer program product, which includes a computer program / instructions that, when executed by a processor, implement the method described in any of the preceding claims.

[0019] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: This application provides an online repair method, apparatus, device, medium, and product for an XFS file system. The method, upon detecting metadata anomalies in the XFS file system, obtains abnormal tuple information of the metadata. Based on the impact scope of the damaged object and the log consistency status in the abnormal tuple information, the metadata anomaly level is classified into Level 1, Level 2, or Level 3 anomalies. When the metadata anomaly level is Level 1 or Level 2, a local isolation control strategy is implemented on the damaged object, restricting it to a local isolation area. Within the local isolation area, a partitioned concurrent repair strategy is executed. This strategy includes dividing the repair task for the damaged object into multiple independent shard work areas, each shard work area performing online repair operations and submitting repair results layer by layer to obtain the repaired object. When the metadata anomaly level is Level 3, a forced shutdown operation is performed on the XFS file system.

[0020] This application embodiment improves upon the original approach of immediately shutting down the entire XFS file system path when an XFS file system metadata anomaly is detected by an anomaly classification and local isolation mechanism. Instead, it enables more local, reconstructable anomalies to enter the repair process without interrupting all services, thus limiting the impact of the fault to the affected objects while allowing unaffected objects to continue to provide services.

[0021] By employing the aforementioned partitioned concurrent repair strategy, the online repair process can be divided into a fragmented workflow that is parallelizable, convergent, and locally rollbackable. Through layered submission and local rollback mechanisms, this embodiment makes it easier for the repair process to determine when it is safe to submit the repair results, and to converge the rollback scope to the relevant fragments when the submission of the repair results fails. This avoids the high cost of global rollback, improves the commitability and reliability of online repair, reduces global lock contention and global temporary storage hotspots, and improves the efficiency of online repair.

[0022] This application embodiment improves availability while retaining a security fallback mechanism, realizing a closed loop of "availability first, security fallback" for handling anomalies. It avoids both the frequent downtime caused by the "overly conservative" approach of traditional solutions and the expansion of errors caused by the "overly aggressive" approach, thereby significantly reducing the impact of metadata anomalies on overall business availability. Attached Figure Description

[0023] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating an online repair method for an XFS file system provided in this application embodiment; Figure 2 This is a schematic diagram illustrating the calling relationships and data flow between the modules provided in the embodiments of this application; Figure 3 A flowchart illustrating the anomaly classification and local isolation provided in the embodiments of this application; Figure 4 This is a flowchart illustrating the partition concurrency repair strategy provided in an embodiment of this application; Figure 5 A schematic diagram of the structure of an online repair device for an XFS file system provided in this application embodiment; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] It should be noted that the online repair method, apparatus, device, medium, and product for the XFS file system provided in this application are applicable to storage service scenarios based on the XFS file system under the Linux operating system, and are particularly suitable for scenarios with high business continuity requirements, such as database servers, storage servers, and virtualization hosts. They can effectively solve problems such as global shutdown, intense online repair lock contention, high synchronization overhead, and high rollback costs that occur after metadata anomalies in the XFS file system in related technologies. In this application embodiment, the XFS file system runs in kernel mode, and the various functional modules provided in this application also run in kernel mode, directly accessing the metadata structure and memory management interface inside the XFS file system. This application embodiment does not require the deployment of an additional independent repair program, and can achieve full automation of the anomaly detection, classification, isolation, and repair process.

[0026] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0027] See Figure 1 , Figure 1 This is a flowchart illustrating an online repair method for an XFS file system provided in this application embodiment. The online repair method for an XFS file system provided in this application embodiment includes the following steps: S101. When an XFS file system metadata anomaly is detected, obtain the abnormal tuple information of the metadata. The abnormal tuple information includes at least one of the following: the type of damaged object, the allocation group identifier, the log consistency status, and the scope of impact of the damaged object.

[0028] The XFS file system (a high-performance journaling file system widely used in the Linux operating system) continuously verifies the consistency of critical metadata during operation. Key metadata includes inodes (objects describing file or directory metadata), directory entries, free space, and btree structures (a self-balancing tree data structure). When the XFS file system detects metadata anomalies during operation, the system automatically triggers an exception handling process, first retrieving the information of the abnormal tuple in the metadata.

[0029] Optionally, metadata anomalies can be proactively detected through the XFS file system's internal consistency verification mechanisms (such as B+ tree node verification, free space mapping verification, inode verification, etc.), or passively triggered by external monitoring tools (such as the online scanning mode of xfs_check or xfs_repair). Here, B+ tree refers to a tree data structure, specifically an n-ary sorted tree, which contains a root node, internal nodes, and leaf nodes.

[0030] Optionally, the abnormal tuple information is automatically extracted by the anomaly detection module of the XFS file system without manual intervention. The extraction process relies on the native metadata monitoring mechanism of the XFS file system, which can directly obtain the basic metadata of the damaged object (such as the location, type, and attributes of the anomaly) and integrate it into standardized abnormal tuple information, providing data support for the subsequent classification of anomaly levels.

[0031] In some embodiments, the damaged object type indicates the type of metadata object that has malfunctioned, such as an inode, dentry, free space bitmap, or B+ tree node; the allocation group identifier (AG) indicates the allocation group number to which the damaged object belongs. An allocation group is the basic parallel unit used by the XFS file system to divide space and metadata management domains; the log consistency status indicates whether the current log still maintains replayable consistency, that is, whether the transaction sequence recorded in the log can correctly reconstruct a consistent metadata state; and the scope of impact of the damaged object indicates the number, spatial range, or logical range of the damaged object, such as a single inode, a single directory subtree, a single allocation group, or across multiple allocation groups.

[0032] For example, when a corrupted inode metadata is detected, the abnormal tuple information may include: the corrupted object type is an inode, the allocation group number of the corrupted object is AG1, the log consistency status is undistorted, there is cross-validation evidence (e.g., the replica information of the inode), and the scope of the impact is limited to the inode itself.

[0033] Optionally, the abnormal tuple information also includes cross-validation rules, which are used to define the system's method of verifying metadata consistency constraints. For example, by comparing redundant copies, checking for the existence of metadata copies, checking and verifying or cross-references, the system can determine whether the damaged object can be rebuilt and whether the global invariants across allocation groups are valid.

[0034] Optionally, the abnormal tuple information may also include the location of the damaged objects (e.g., whether the set of damaged objects can be accurately located through cross-references such as existing indexes or mapping tables) and the repair priority or the timestamp of the abnormality.

[0035] S102. Based on the impact range of the damaged objects and the log consistency status in the obtained abnormal tuple information, classify the abnormality level of the metadata into Level 1, Level 2, or Level 3 abnormalities.

[0036] In some embodiments, after obtaining the abnormal tuple information, the current metadata anomaly is graded and evaluated based on the impact scope of the damaged object and the log consistency status. The metadata anomaly level is divided into Level 1, Level 2, or Level 3 anomalies, and the grading rules for each anomaly level are as follows: 1. When the impact of a damaged object is limited to a single enumerable object (e.g., a single inode or directory entry), and the log consistency status is undistorted (i.e., log replay can reconstruct a consistent state), the anomaly level is classified as Level 1. Level 1 anomalies typically correspond to local anomalies where metadata can be directly reconstructed using existing copies, cross-references, or preset rules, and are suitable for immediate initiation of the online remediation path.

[0037] For example, if the metadata of a regular index node in an allocation group is corrupted, but the index node has a replica and the log consistency status is not corrupted, the metadata of the index node can be reconstructed using the existing replica. In this case, the abnormality level of the metadata is determined to be a level one abnormality.

[0038] 2. When the impact of a damaged object is limited to a single allocation group (e.g., limited to multiple inodes or free space blocks within that allocation group), and cross-allocation group consistency is not compromised (i.e., global invariants between the superblock and the allocation group still hold), the anomaly level is classified as a Level 2 anomaly. Level 2 anomalies typically cannot be immediately repaired online, but their impact can be limited to a specific allocation group, inode, or directory tree, allowing read-only degradation or access denial processing for the damaged object.

[0039] For example, if the metadata of multiple index nodes in a certain allocation group is corrupted, the impact is limited to that allocation group and cannot be repaired online immediately, but write operations in that allocation group can be restricted, then the abnormality level of the metadata is determined to be a level two abnormality.

[0040] 3. When the impact of a damaged object extends beyond a single allocation group (i.e., spans multiple allocation groups), or the log consistency status indicates impaired log replay correctness (i.e., the log cannot be reconstructed to a consistent state), or the integrity of critical space mapping is compromised, or the scope of the damage cannot be determined, the metadata anomaly level is classified into three levels. Level three anomalies typically require a forced shutdown of the XFS file system, i.e., execution of xfs_force_shutdown (a forced shutdown path triggered by the XFS file system when a serious error is detected). Continuing to run the system may lead to error propagation or irrecoverable data loss.

[0041] For example, when the superblock is corrupted, metadata consistency across allocation groups is compromised, or the specific corrupted object cannot be located, the abnormality level of the metadata is determined to be a level three abnormality, and the XFS file system must be forcibly shut down to prevent the error from spreading.

[0042] It should be noted that the anomaly level classification of metadata can be automatically executed through preset judgment logic, or it can be combined with manual assistance to ensure the accuracy of anomaly level classification. The anomaly level classification can be flexibly configured according to the actual application scenario. The core is to distinguish between "locally controllable anomalies" and "globally unrecoverable anomalies" to provide a basis for subsequent processing strategies.

[0043] S103. When the metadata anomaly level is Level 1 or Level 2, a local isolation control strategy is implemented for the damaged object to restrict the damaged object to a local isolation area.

[0044] When metadata anomalies are classified as Level 1 or Level 2, the system does not immediately shut down the entire XFS file system. Instead, it implements a local isolation control policy for the damaged objects. This policy restricts access to damaged objects or allocation groups to a local isolation area. Only damaged objects are restricted from access, while undamaged objects continue to provide services, thus achieving precise control over the impact of the fault.

[0045] S104. Execute a partitioned concurrent repair strategy within the local isolation area. The partitioned concurrent repair strategy includes: dividing the repair task for the damaged object into multiple independent partitioned work areas, with each partitioned work area performing online repair operations and submitting repair results in layers to obtain the repaired object.

[0046] After confining the damaged object to a local isolation area, the system initiates a partitioned concurrent repair strategy within the local isolation area. The core idea of ​​the partitioned concurrent repair strategy is to break down the repair process, which originally required global locking and global temporary storage, into multiple parallel, convergent, and locally rollback-capable segmented workflows.

[0047] S105. When the metadata exception level is level three, perform a forced shutdown operation on the XFS file system.

[0048] Traditional XFS file systems, when detecting metadata anomalies, typically call `xfs_force_shutdown` to mark the entire file system as closed, causing all subsequent read and write requests to return errors. This approach cannot distinguish between "locally reproducible anomalies" and "globally unrecoverable anomalies." This application's embodiment uses an anomaly grading and local isolation mechanism to classify anomalies into Level 1, Level 2, and Level 3. A forced shutdown operation is only triggered when the anomaly level reaches Level 3 (i.e., affecting log replay correctness, cross-allocation group global invariants, or exceeding the scope of a single allocation group). For Level 1 and Level 2 anomalies, the system enters a local isolation and online repair path.

[0049] This embodiment improves upon the original approach of immediately shutting down the entire XFS file system path upon detecting metadata anomalies. Instead, it allows more local anomalies and reconstructable anomalies limited to a single object or allocation group to enter the repair process without interrupting all services. This limits the impact of the fault to the affected objects, while unaffected objects can continue to provide services, thereby significantly reducing the probability of global downtime caused by metadata anomalies.

[0050] By employing the aforementioned partitioned concurrent repair strategy, the repair task for damaged objects can be divided into multiple independent sharded work areas, each executing online repair operations separately. This breaks down the online repair process into a sharded workflow that is parallelizable, convergent, and capable of partial rollback. Through layered submission and partial rollback mechanisms, this embodiment makes it easier to determine when it is safe to submit the repair results, and when submission fails, the rollback scope is converged to the relevant shard, avoiding the high costs associated with global rollback. Transforming global lock contention into local contention within shards significantly reduces the blocking of front-end services during the repair process, reduces global lock contention and global temporary storage hotspots, and improves the efficiency, reliability, parallelism, and overall throughput of online repair.

[0051] This application embodiment improves availability while retaining a security fallback mechanism, realizing a closed loop of "availability first, security fallback" for handling anomalies. It avoids both the frequent downtime caused by the "overly conservative" approach of traditional solutions and the expansion of errors caused by the "overly aggressive" approach, thereby significantly reducing the impact of metadata anomalies on overall business availability.

[0052] See Figure 2 , Figure 2This illustration shows the calling relationships and data flow between modules provided in this application embodiment. This application embodiment provides an online repair method for the XFS file system, which runs in the kernel mode of the Linux operating system and exists as a functional module within the XFS file system. This application embodiment modifies the XFS file system by embedding mechanisms such as anomaly classification judgment, local isolation control, fragmented work area construction, local incremental record queue, convergence judgment, and hierarchical commit on top of the original metadata consistency verification and error handling path of the XFS file system. This enables the XFS file system to no longer unconditionally enter the global forced shutdown path when a metadata anomaly is detected, but instead selects local isolation repair or forced shutdown based on the anomaly level. For metadata anomalies that meet the online repair conditions, the controlled repair path is prioritized, and the damaged objects are restricted to a local isolation area; subsequently, the online repair is completed by the fragmented work area, incremental local enqueue, and hierarchical commit mechanisms.

[0053] The solution in this application embodiment is integrated into the XFS kernel module and runs on a single device with the XFS file system installed. This device can be a database server, a virtualization host, or a distributed storage node. Since the XFS file system itself runs in kernel mode, the functional modules in this application embodiment also run in kernel mode, directly accessing the metadata structure and memory management interface within the XFS file system without requiring data copying between user mode and kernel mode. This ensures low latency and high efficiency in anomaly handling and online repair.

[0054] Module 1: Anomaly Detection Module When the XFS file system detects metadata anomalies during operation through internal consistency verification mechanisms (such as B+ tree node verification, free space mapping verification, and inode verification) or external monitoring tools, the anomaly detection module captures the anomaly event, generates an anomaly event alarm message, and sends the anomaly event to the anomaly classification determiner.

[0055] The anomaly detection module runs in kernel mode and directly accesses the superblock, allocation group metadata structure, and log buffer of the XFS file system to extract raw information related to anomalies, which serves as the basic data source for the subsequent anomaly classification and determination unit to generate anomaly tuples.

[0056] Module 2, Anomaly Classification Detector The anomaly classification and determination unit receives anomaly event notifications from the anomaly detection module, extracts anomaly tuple information from the XFS file system's internal metadata structure and log buffer, and determines the anomaly level based on the type of damaged object, the scope of impact of the damaged object, log consistency status, and rebuildability in the anomaly tuple information. The anomaly level of the metadata is classified into Level 1, Level 2, or Level 3 anomalies.

[0057] The main interfaces of the anomaly classification determiner include: anomaly tuple (input), object scope (input), and log health status (input). The determination result is output to the local isolation controller or the global forced shutdown path module via control flow.

[0058] Module 3, Local Isolation Controller When the anomaly classification determineer classifies an anomaly as either Level 1 or Level 2, control flow enters the local isolation controller. The local isolation controller sets access restrictions, degradation strategies, and isolation bitmaps for locally isolated damaged objects.

[0059] The main interfaces of the local isolation controller include: damaged allocation group table (output), damaged inode table (output), and access policy (output). Through local isolation control, undamaged objects continue to provide services, while only damaged objects are subject to access restrictions, thus achieving precise control over the impact of faults.

[0060] During the repair result submission phase, when the online repair operation is successful, the local isolation controller cancels the primary and secondary isolation markers and restores normal access to the damaged object; when the repair fails and the scope of impact does not expand, the local isolation status of the damaged object is maintained.

[0061] Module 4: Global Force Close Path Module When the anomaly classification determiner identifies an anomaly as a level three anomaly, or when repair fails and the impact of a newly damaged object exceeds the impact of isolated objects or global invariants across allocation groups are damaged, the control flow enters the global forced shutdown path module, which is used to perform forced shutdown path operations on the XFS file system.

[0062] Module 5, Fragmented Workspace Builder Once the anomaly level is determined to be a Level 1 or Level 2 anomaly and local isolation is completed, the control flow enters the fragmented work area builder. The fragmented work area builder establishes independent temporary storage areas according to the allocation group, the type of damaged object, or the scope of the impact of the damaged object, dividing the repair task into multiple independent fragmented work areas.

[0063] The main interfaces of the sharded workspace builder include: sharded index (output), work queue (output), and local incremental record queue (output).

[0064] Module 6, Restricted Parallel Scanner The restricted parallel scanner is the core execution module following the sharded work area builder. It is responsible for performing restricted parallel scans within the established sharded work areas. The system dynamically determines the scan concurrency based on CPU load, input / output load, and foreground transaction load, and allocates one or more worker threads to each sharded work area.

[0065] Worker threads in different sharded work areas can execute in parallel, but each worker thread only scans damaged objects within the object key range of its own sharded work area and maintains its local scan state. The scanning worker thread advances step by step using a scanning cursor, performing consistency checks on each damaged object within the object key range. If an inconsistency is found, a repair plan is calculated and the sharded repair patch set is updated.

[0066] Module 7, Incremental Hooking of Local Queues The incremental hook local queue runs on the foreground transaction commit path and is responsible for capturing incremental changes on the foreground transaction path and routing them to the corresponding sharded work area.

[0067] Optionally, when the foreground transaction commit path of the XFS file system modifies the metadata related to the damaged object, the incremental hook local queue generates an incremental record at the transaction commit point. The incremental record can contain: object key, operation type, transaction sequence number and target shard identifier. The incremental record is directly written to the local incremental record queue of the corresponding shard work area, instead of being written to the global unified queue, which significantly reduces synchronization overhead.

[0068] The main interfaces of the incremental hook local queue include: transaction commit point (input), object key (output), operation type (output), and transaction sequence number (output).

[0069] Module 8: Batch Merger The batch merger is used to consume incremental records in the local incremental record queue of each shard workspace in batches when the number of concurrent scanning threads or merging threads is greater than or equal to a preset threshold. The preset thresholds include: the number of incremental records reaching a preset quantity threshold, and the cumulative time of incremental records reaching a preset duration threshold.

[0070] The batch merger performs deduplication, sorting, and aggregation operations on incremental records consumed in batches: the deduplication operation retains the latest version of the same object key (determined by the transaction sequence number) and deletes the old version records; the sorting operation sorts the incremental records according to the object key or the transaction sequence number; the aggregation operation merges multiple incremental operations with the same object key into one operation and updates the aggregated result to the temporary storage area of ​​the corresponding shard work area.

[0071] Module Nine: Convergence Decision Maker The convergence criterion determines whether the segmented working area meets the preset convergence conditions based on the scanning cursor, the local incremental record queue, the water level stability, and the cross-validation results.

[0072] The main interfaces of the convergence determiner include: scan round (input), version watermark (input), and cross-validation result (input). The convergence determiner outputs the determination result to the hierarchical committer, allowing entry into the hierarchical commit phase only when the preset convergence conditions are met.

[0073] Module 10: Layered Submitter Optionally, the tiered committer, based on the determination of whether a tiered patch set can be committed, commits the tiered patch sets for each tiered working area according to the dependencies between XFS file system metadata. For example, it commits space allocation-related metadata first (tier 1), then inode-related metadata (tier 2), and finally directory / attribute class secondary indexes (tier 3). Within each tier, tiered patch sets for multiple tiered working areas can be committed in parallel, while tiers are committed sequentially.

[0074] When a shard repair patch set fails to commit, the hierarchical committer only rolls back the failed shard repair patch set. The rollback process reads the failure rollback log corresponding to the failed shard repair patch set and restores the metadata state of the failed shard to its original state before the repair in reverse order of the repair operation sequence, while the shard repair patch sets of other stable shard work areas remain in the committed state.

[0075] The main interfaces of the hierarchical committer include: commit order (input), rollback log (input / output), and commit status (output).

[0076] This application's embodiments employ a kernel-mode modular architecture design, unifying exception handling and online repair into a closed-loop workflow. This avoids data copying and frequent system calls between user mode and kernel mode, significantly reducing latency in exception handling and online repair, improving overall system response speed, and minimizing data copy overhead. Each module runs in kernel mode, directly accessing the internal data structures of the XFS file system, avoiding the switching overhead between user mode and kernel mode. Interfaces between modules are implemented through data structures in kernel memory (such as bitmaps, linked lists, queues, and log buffers), ensuring low latency and high efficiency in exception handling and online repair.

[0077] In some embodiments, based on the impact scope of the damaged objects in the abnormal tuple information and the log consistency status, the abnormality level of the metadata is divided into Level 1, Level 2, or Level 3 abnormalities, including: When the impact of the damaged object is limited to a single enumerable object and the log consistency status is undistorted, the metadata anomaly level is classified as Level 1 anomaly. When the impact of a damaged object is limited to a single allocation group and consistency across allocation groups is not compromised, the metadata anomaly level is classified as a Level 2 anomaly. When the impact of a damaged object extends beyond a single allocation group, or the log consistency status indicates that log replay correctness is compromised, or the integrity of the critical space mapping is compromised, or the scope of the damage cannot be determined, the metadata anomaly level is classified into three levels.

[0078] In some embodiments, when the metadata anomaly level is Level 1 or Level 2, a local isolation control strategy is implemented for the damaged object to restrict it to a local isolation area, including: Set a primary isolation flag and a secondary isolation flag in the damaged allocation group table or the damaged index node table; the primary isolation flag is used to identify the primary isolation status of the damaged object under the primary abnormality condition; the secondary isolation flag is used to identify the secondary isolation status of the damaged object under the secondary abnormality condition. When an access request is received for a compromised object with a Level 1 isolation flag, a response is returned that prohibits write operations and downgrades the status to read-only. When an access request is received for a compromised object with a secondary isolation tag, an access denial request or an error response is returned.

[0079] Optionally, the table of damaged allocation groups or damaged index nodes containing the damaged objects in the metadata can be used as an isolation table (in practical applications, since all damaged objects ultimately correspond to a unique index node, the abnormal tuple IDs of all damaged objects can be maintained in one isolation table, eliminating the need to maintain separate tables for damaged allocation groups and damaged index nodes). A primary isolation flag and a secondary isolation flag are set in the isolation table to identify the abnormal state and isolation range of the damaged objects. The primary and secondary isolation flags are maintained in the form of a bitmap or linked list, allowing the system to quickly determine whether a damaged object is in an isolated state by querying this table.

[0080] Optionally, when an access request is received for a damaged object with a Level 1 isolation tag, a response is returned that prohibits write operations and downgrades the status to read-only. That is, the front-end business can still read the contents of the damaged object, but cannot perform write operations such as modification, deletion or renaming. At the same time, an online repair process can be triggered immediately to ensure that the damaged object is not further modified during the repair process and to avoid the error from spreading.

[0081] Optionally, when an access request is received for a damaged object with a secondary isolation tag, the system returns an access denial request or an error response (such as an EIO error, which is a standard error in Linux indicating failure of underlying input or output operations). This means that read and write requests from the front-end business to the damaged object are rejected, but the resources occupied by the damaged object (such as inode numbers and data blocks) are not released temporarily so that subsequent repair processes can attempt to restore it. This avoids accidental operations on the damaged object. Simultaneously, an online repair process is initiated in the background or a partially isolated area (background repair can dynamically adjust resource usage based on system load to avoid impacting front-end business). Similarly, undamaged objects can continue to provide services normally; only damaged objects are subject to access restrictions, thus achieving precise control over the impact of the fault.

[0082] Optionally, when an access request for a damaged object with a Level 3 anomaly is received, a forced shutdown operation is performed on the XFS file system. All subsequent read and write requests to the XFS file system will return EIO error response data to prevent the unrecoverable error from continuing to expand. The administrator can then arrange offline checks or manual repairs to avoid the error spreading to the entire system.

[0083] Optionally, when an access request for an undamaged object is received, a response data allowing the access request is returned to ensure that undamaged services are not affected.

[0084] The forced shutdown operation in this embodiment is not the crude "shut down as soon as an anomaly is detected" approach of traditional solutions, but rather a last resort path after anomaly classification and assessment. The system only triggers this operation when it is confirmed that the impact of the anomaly has exceeded the local controllable boundary or that log consistency has been compromised, thus achieving a balance between availability and security.

[0085] In some embodiments, the abnormal tuple information further includes cross-validation rules, and the method further includes: When the online repair operation is successful, the primary and secondary isolation markers are removed and normal access to the damaged objects is restored. When online repair fails and the impact does not spread, maintain the local isolation of the damaged object; When the online repair operation fails and the impact of a newly damaged object exceeds the impact of the isolated object, or when cross-validation detects that global invariants across allocation groups are damaged (e.g., the free space count between the superblock and each allocation group is inconsistent, the total number of indices across allocation groups is inconsistent, or the integrity of the space mapping is damaged), a forced shutdown operation is triggered to prevent the unrepairable anomaly from continuing to spread. Among them, the loss of global invariants across allocation groups refers to the following: cross-validation is performed by cross-validation rules and it is found that the metadata consistency constraints between multiple allocation groups are not met. The metadata consistency constraints include at least one of the following: consistency of free space count between the superblock and each allocation group, consistency of the total number of index nodes across allocation groups, and integrity of space mapping across allocation groups.

[0086] Optionally, when the online repair operation is successful, the primary and secondary isolation marks of the damaged objects are cleaned up, that is, the primary and secondary isolation marks are deleted from the isolation table, and normal access to the damaged objects (including write, read and other operations) is restored, so that they can re-participate in the front-end business read and write. The whole process does not require restarting the XFS file system, achieving seamless business recovery.

[0087] Optionally, when the online repair operation fails and the scope of the damaged object does not expand (i.e. the damaged object is still limited to the original local isolation area), the local isolation state of the damaged object that failed to be repaired is maintained. The repair can be attempted again in the background or manual intervention can be waited for. If the repair still fails after another attempt, a forced shutdown operation for the XFS file system can be triggered.

[0088] This application embodiment ensures the accuracy and efficiency of online repair by automatically feeding back the results of online repair during the online repair process, and by using the native repair function of the XFS file system or by performing online repair through custom repair logic.

[0089] See Figure 3 , Figure 3 This is a flowchart illustrating the anomaly classification and local isolation process provided in the embodiments of this application. The embodiments of this application provide an optimization scheme for the unexpected shutdown mechanism in the online repair method of the XFS file system. The optimization scheme for the unexpected shutdown mechanism mainly modifies the original anomaly handling path of the XFS file system. Before the original forced shutdown path that directly calls xfs_force_shutdown, an anomaly classification and local isolation process is added. The global forced shutdown operation is converged from the default path to the last fallback path, so that a large number of metadata anomalies that can be locally isolated and rebuilt can enter the online repair process without shutting down the entire file system.

[0090] The anomaly classification and local isolation process includes the following steps: Step 1: Metadata anomaly detected.

[0091] Step 2: Generate abnormal tuple information.

[0092] When the XFS file system detects a metadata anomaly during operation, the system first enters the anomaly handling path. Unlike the traditional XFS path which directly triggers a forced shutdown operation, this embodiment adds an anomaly tuple generation step at the beginning of the anomaly handling path.

[0093] Extract information about abnormal tuples, which includes at least one of the following: Damaged object type: The type of damaged object determines the direction of subsequent repair strategy selection. For example, an index node anomaly can be repaired by rebuilding the index node table, while a B+ tree node anomaly requires traversing the tree structure for local reconstruction.

[0094] Allocation group identifier of the damaged object: This indicates the allocation group number to which the damaged object belongs. The XFS file system divides disk space into multiple parallel management domains through allocation groups. Each allocation group has independent free space management, inode allocation, and B+ tree structure. Determining the allocation group identifier of the damaged object is a key basis for judging whether the scope of the anomaly's impact can be limited.

[0095] Log consistency status: This indicates whether the current log still maintains replayable consistency. Log consistency is a crucial prerequisite for determining whether anomalies can be repaired online. If log consistency is not compromised, the repair thread can reconstruct a consistent metadata state based on the log; if log consistency is compromised, online repair may be based on an untrusted foundation, necessitating a forced shutdown.

[0096] Cross-validation rules: These are used to indicate whether the system has external evidence to verify the rebuildability of damaged objects. Examples of cross-validation evidence include: redundant copy comparison (e.g., verifying whether damaged objects can be rebuilt by mirroring or checksum), cross-reference verification (e.g., verifying the existence of an object by using the inverted index of the inode number and the directory entry), and rule-based reconstruction (e.g., verifying whether spatial mapping can be rebuilt by using the rule calculation of the free space bitmap).

[0097] Damaged object localization: This indicates whether the system can accurately locate the range of damaged objects through existing indexes or mapping tables. If the damaged objects can be located to a finite set, the scope of the anomaly's impact is controllable, making it suitable for entering the local isolation and online repair path. If the damaged range cannot be determined, the forced shutdown path must be entered.

[0098] The scope of impact of the damaged object: such as the number of damaged objects, spatial range, or logical range.

[0099] Optionally, the abnormal tuple information may also include the repair priority of the damaged object or the timestamp of the abnormality, so that the system can prioritize and manage the timing of multiple concurrent abnormalities.

[0100] Step 3: Classify anomalies into at least three categories: Level 1 anomalies (can be repaired online), Level 2 anomalies (can be partially isolated), and Level 3 anomalies (must be shut down).

[0101] After generating the abnormal tuple information, the system performs a graded assessment of the current metadata abnormality based on each field in the abnormal tuple information.

[0102] Step 4: For Level 1 anomalies, set up a local isolation strategy and directly trigger online repair operations; for Level 2 anomalies, set up a local isolation strategy, restrict access operations to the affected objects, and queue them for repair; for Level 3 anomalies, directly execute a forced path closure operation.

[0103] Step 5: For Level 1 and Level 2 anomalies, determine whether the online repair operation was successful.

[0104] Step 6: When the online repair operation is successful, clear the isolation markers of the damaged objects and restore normal access to the damaged objects; when the online repair operation fails, and the impact of the damaged objects that failed to be repaired has not expanded, maintain the local isolation state of the damaged objects that failed to be repaired; when the online repair operation fails, and the impact of newly detected damaged objects exceeds the impact of the already isolated damaged objects, perform a forced shutdown operation on the XFS file system.

[0105] This embodiment converges the "global forced shutdown" from the default path to the last resort path, enabling numerous local anomalies confined to a single damaged object or a single allocation group to enter the repair process without interrupting all services, thereby significantly reducing the probability of global downtime caused by metadata anomalies. Through a local isolation mechanism, this embodiment strictly limits the scope of the fault's impact to the damaged object or damaged allocation group, while undamaged objects can continue to provide services, thus significantly reducing the impact of the anomaly on overall service availability. By combining techniques such as anomaly tuple generation, anomaly classification, local isolation control, repair decision-making, and corresponding operations for different repair results, the scope of the fault's impact is precisely controlled, constructing a dynamic closed-loop process for handling the situation.

[0106] In some embodiments, the repair task for the damaged object is divided into multiple independent work areas, including: Based on the allocation group identifier, metadata type, and object key range of the damaged object, the repair task is divided into multiple independent shard work areas, and the repair tasks in each shard work area are executed in parallel. The object key range represents a processing interval consisting of multiple object keys, used to divide the scan boundaries of each shard work area; the object key is used to identify metadata objects, which include at least one of the following: inode, directory entry, or free space block.

[0107] The core of this application's embodiment in dividing the work area into fragments is to bind the repair task to the resource domain of the XFS file system, prioritizing allocation group, object type, and object key range as the basis for fragmentation, which helps to limit lock contention within the resource domain and avoid global lock contention.

[0108] For example, metadata repair tasks for index nodes within the same allocation group can be divided into one shard work area, and metadata repair tasks for directory entries within the same allocation group can be divided into another shard work area. Scanning and repair operations can be performed in parallel in different shard work areas.

[0109] In some embodiments, each sharded workspace contains at least one of the following: The scanning cursor is used to record the scanning progress of each work area segment; The local incremental record queue is used to store the incremental records (i.e., incremental changes of foreground transactions) corresponding to each shard work area. Version watermark is used to identify the fix version for each shard workspace; The sharded repair patch set is used to store the repair results that have been calculated for each sharded workspace, waiting for tiered commit; The failure rollback log is used to record rollback information when online repair operations fail, so that a partial rollback can be performed.

[0110] Optionally, the scanning cursor is specifically used to identify the range of object keys that have been scanned; the local incremental record queue is specifically used to store the incremental records of foreground transactions received by each shard workspace during the scanning period; the version watermark is used to identify the version markers at the boundary between the shard scanning phase and the incremental merging phase. When the watermark remains stable within a preset check period, it indicates that the incremental inflow tends to converge.

[0111] Optionally, the object key is generated based on the inode number and uniquely identifies the metadata object within the XFS file system. In this embodiment, it is used to identify damaged objects, including inodes, directory entries, and free space blocks. The object key range represents a processing interval consisting of multiple consecutive object keys, used to delineate the scan boundaries of each shard work area.

[0112] In some embodiments, the method further includes: The scan concurrency is determined based on the system load (including CPU load, I / O load, foreground transaction load, etc.), and worker threads are allocated to each work area. Each worker thread performs parallel scanning of the damaged objects in the corresponding work area and maintains the local scan status. When a modification operation on the metadata related to a damaged object is detected, a corresponding incremental record is generated and written to the local incremental record queue of the shard work area to which the damaged object belongs. The incremental record includes at least one of the following: object key, operation type, transaction sequence number, and shard work area identifier. The object key is used to identify the damaged object that was modified, the operation type is used to identify the modification operation (such as write, delete, modify, etc.), the transaction sequence number is used to identify the execution order of the foreground transaction, and the target shard identifier is used to determine the shard work area to which the incremental record belongs.

[0113] This embodiment dynamically determines the scanning concurrency based on the system's load calculation, allocates one or more scanning worker threads to each shard work area, and allows different shard work areas to scan in parallel. Each shard work area only performs scanning on objects within its own object key range and maintains its local state (such as scanning progress, incremental records, repair status, etc.), without needing to access the shared structure of other shard work areas, thereby reducing shared structure contention and lowering synchronization overhead.

[0114] For example, when the system's CPU load is low and the foreground business pressure is low, more worker threads can be allocated for shard scanning and repair; when the system's CPU load is high, the number of worker threads should be reduced to prioritize the operation of foreground business. Each shard work area's scanning thread is only responsible for scanning the damaged objects within that shard work area and maintaining the local scanning cursor for that shard work area. There is no need to synchronize with scanning threads in other shard work areas, thereby improving scanning efficiency.

[0115] It should be noted that the detection of foreground transactions is implemented by the native transaction monitoring mechanism of the XFS file system. The transaction commit path is the transaction processing flow in the XFS kernel space. The hook is integrated into the transaction commit path, which can capture the modification operations of foreground transactions in real time and generate incremental records. The local incremental record queue is a dedicated queue for each shard work area. It is used to temporarily store the incremental changes corresponding to the shard work area, ensuring that incremental records are not lost, and facilitating subsequent batch processing.

[0116] In this embodiment, during the scanning process, when the backend transaction commit path modifies metadata related to the damaged object, the system generates an incremental record in the transaction commit path. This incremental record can include the object key, operation type, transaction sequence number, and target shard identifier. After generating the incremental record, it is directly written to the local incremental record queue of the shard workspace to which the damaged object belongs, rather than to the global unified queue. This achieves localized management of incremental records, avoids multiple shard workspaces contending for the same global queue, and reduces synchronization overhead. Simultaneously, the transaction sequence number ensures the sequentiality of the incremental records, facilitating sorting and deduplication during subsequent incremental merging.

[0117] In some embodiments, the method further includes: When each of the sharded work areas meets the preset convergence conditions, it is determined that the shard repair patch set (i.e., the final repair result of the sharded work area) of each sharded work area can be submitted; wherein, the preset convergence conditions include at least one of the following: the scanning range of the scanning cursor has covered the target object range of the sharded work area, the local incremental record queue is empty, the version water level remains stable within a preset period, and all cross-validations for the sharded work area pass; Based on the determination result that the fragment repair patch set can be submitted, the fragment repair patch set of each fragment work area is submitted in a hierarchical manner according to the dependency relationship between the metadata; When a fragment repair patch set fails to commit, only the fragment repair patch set that failed to commit is rolled back.

[0118] Optionally, for the preset convergence conditions, the scanning range of the scanning cursor has covered the target object range of the shard work area, that is, all damaged objects corresponding to the shard work area have been scanned, and there are no unscanned damaged objects, and the scanning cursor has reached the preset endpoint; the local incremental record queue is empty, that is, all incremental changes of the front-end transaction corresponding to the shard work area have been consumed, and there are no unprocessed incremental records, ensuring that the repair result is consistent with the modification of the front-end transaction; the version level remains stable within a preset period, that is, each shard work area corresponds to a version level (which can be a specific value), used to identify the repair version of the shard work area. When the version level does not change within a preset check period (e.g., 500ms), it indicates that the repair status of the shard work area is stable and there are no new incremental changes; all cross-validations of the shard work area pass, that is, the cross-validation module of the XFS file system verifies the repair result of the shard work area. The verification content includes metadata consistency, consistency with replicas, cross-shard dependency consistency, etc. Only when all verification items pass is the repair result considered valid.

[0119] Optionally, the convergence determination can be executed periodically (e.g., once every 100ms), or it can be executed when key events such as the local incremental record queue is empty or the scan is completed, to ensure the timeliness and accuracy of the convergence determination.

[0120] Optionally, based on the dependencies between metadata in the XFS file system, tiered patch sets for each shard workspace are submitted, including: Submit the repair results for the corresponding work area in the order of space allocation metadata, inode metadata, and directory and attribute secondary indexes.

[0121] Optionally, the dependencies between metadata can be pre-modeled (either manually specified or automatically identified by the system). The submission order should follow the principle of "basic metadata first", specifically: first submit the metadata related to space allocation, then submit the metadata related to index nodes, and finally submit the secondary indexes of directories or attribute classes to ensure the consistency of the submission process and avoid repair failures due to metadata dependencies.

[0122] Optionally, if the repair result of a certain shard work area fails to be committed, only the shard repair patch set corresponding to the failed shard work area is rolled back, without affecting other shard work areas that have been stably committed, achieving "partial failure, partial rollback" and reducing rollback costs. The rollback process is implemented through the rollback log of the shard work area, which can quickly restore the state to the state before the repair without affecting the repair results of other shard work areas and front-end business.

[0123] This embodiment of the application, through the aforementioned partitioned concurrent repair strategy, submits repair results in layers according to the dependencies between XFS file system metadata for sharded workspaces that have reached a converged state. For example, it first submits space allocation-related metadata (such as free space bitmaps), then inode-related metadata, and finally directory or attribute-class secondary indexes. If a layer's submission fails, only the associated sharded workspace and the shard repair patch set for that layer are rolled back, without affecting other stable sharded workspaces. By submitting shard repair patch sets in layers, the online repair process is divided into a parallel, convergent, and locally rollback-capable sharded workflow, avoiding the large-scale rollback risk caused by a one-time global submission in traditional solutions, reducing global lock contention and global temporary storage hotspots, and improving the efficiency and reliability of online repair.

[0124] Furthermore, a segmented work area refers to an independent repair staging area divided according to allocation group, object type, or object range.

[0125] This embodiment targets damaged objects in a local isolated region and adopts a partitioned concurrent repair strategy. Through steps such as fragmented work area construction, parallel scanning, local incremental absorption, convergence determination, and hierarchical submission, it reduces lock contention and synchronization overhead, thereby improving repair efficiency.

[0126] In some embodiments, the method further includes: When the concurrency of the scanning thread or merging thread in the worker thread reaches the preset threshold, batch consumption is performed on the incremental records in each local incremental record queue. Perform deduplication, sorting, and aggregation operations on incremental records consumed in batches, and update the temporary storage area of ​​the corresponding sharded work area with the aggregated results.

[0127] For example, when the number of concurrent scanning threads or merging threads in the worker threads is greater than or equal to a preset threshold (this preset threshold can be flexibly configured according to the system load and the number of incremental records, such as when the number of incremental records reaches 100, or when the time interval reaches 100ms, it is confirmed that the number of scanning threads or merging threads in the worker threads has reached the preset threshold), batch consumption is performed on the incremental records in each local incremental record queue.

[0128] Optionally, deduplication, sorting, and aggregation operations are performed on the incremental records consumed in batches. The aggregated results are then updated to the temporary storage area of ​​the corresponding shard work area. This includes: deduplication to remove duplicate incremental records (such as multiple repeated modifications to the same object); sorting to organize incremental records according to transaction sequence numbers; and aggregation to merge multiple modification operations on the same object into a single complete modification record, reducing data redundancy. Because the scope of objects within the same shard work area is more concentrated, the lock granularity is smaller, and the synchronization overhead is lower.

[0129] The incremental records after deduplication, sorting, and aggregation operations are updated to the temporary storage area of ​​the corresponding shard work area. This temporary storage area is a dedicated temporary storage space for the shard work area, located in memory, and is used to store the processed incremental records and metadata to be repaired, so as to facilitate the execution of subsequent repair operations.

[0130] The scanning thread and merging thread can be added in this embodiment, or the native threads of the XFS file system can be reused and their functions extended; the "local" in the local incremental record queue refers to the local work area relative to the shard work area, as opposed to "global", that is, each shard work area only manages its own incremental records and does not share them with other shards, thereby further reducing lock contention.

[0131] See Figure 4 , Figure 4 This is a flowchart illustrating the partitioned concurrent repair strategy provided in this application embodiment. This application embodiment executes the partitioned concurrent repair strategy within a local isolated area, constructing multiple independent sharded work areas according to Allocation Group (AG), metadata type, and object key range. This allows scanning, incremental absorption, convergence determination, and result submission to be completed within the sharded work area as much as possible. Only when there is a dependency relationship will it enter the hierarchical submission stage, thereby significantly reducing global lock contention and global temporary storage hotspots, and improving the parallelism and throughput of online repair.

[0132] Specifically, the partition concurrent repair strategy includes the following steps: Step 1: Establish segmented work areas.

[0133] Based on the allocation group identifier, metadata type, and object key range of the damaged object, the repair task for the damaged object is divided into multiple independent shard work areas, and the repair tasks in each shard work area are executed in parallel.

[0134] Prioritize using allocation group identifier, metadata type, and object key range as the basis for sharding, which helps to limit lock contention within resource domains. For example, object key range [0, 4095] corresponds to sharding work area 1, [4096, 8191] corresponds to sharding work area 2, index nodes within the same allocation group can be divided into one sharding work area, free space bitmaps from different allocation groups can be divided into different sharding work areas, and directory items and their attributes can be further subdivided according to object key range.

[0135] Step 2: Constrained Parallel Scan.

[0136] The scan concurrency is dynamically determined based on the CPU load, I / O load, and foreground transaction load. One or more worker threads are allocated to each shard work area, including scan threads and merge threads. Scan threads in different shard work areas can execute in parallel, but each shard work area only performs parallel scans on objects within its own object key range and maintains its local scan state. The scan thread advances step by step using the scan cursor, performing consistency checks on each metadata object within the object key range. If inconsistencies are found, a repair plan is calculated and the shard repair patch set is updated; if the object state is normal, the scan cursor continues to advance.

[0137] Step 3: Foreground transactions are written to the local incremental record queue via hook.

[0138] During the scanning process, when the metadata related to the damaged object is modified in the front-end transaction commit path, a corresponding incremental record is generated in the transaction commit path. The incremental record includes the following fields: object key (identifying the modified metadata object), operation type (such as insert, delete, update), transaction sequence number (identifying the commit order of the front-end transactions), and shard work area identifier (identifying the shard to which the incremental record belongs).

[0139] Incremental records are written directly to the local incremental record queue of the work area of ​​the shard to which the damaged object belongs, rather than to a global unified queue, significantly reducing synchronization overhead. Because the range of objects in the same shard is more concentrated, the object keys in the incremental records have higher locality, thus making subsequent deduplication, sorting, and aggregation operations more efficient.

[0140] Step 4: Perform deduplication, sorting, and aggregation operations in batches.

[0141] When the concurrency of scanning threads or merging threads in the worker threads reaches a preset threshold, batch consumption is performed on the incremental records in each local incremental record queue, and deduplication, sorting and aggregation operations are performed on the batch-consumed incremental records.

[0142] 1. Deduplication: If multiple incremental records exist for the same object key in the queue, only the latest version is retained (determined by the transaction sequence number), and the old version records are deleted to reduce the amount of subsequent processing.

[0143] 2. Sorting: Sort incremental records by object key or transaction sequence number so that subsequent aggregation operations can access them sequentially, improving cache hit rate.

[0144] 3. Aggregation: Combines multiple incremental operations on the same object key into a single operation. For example, if an incremental record contains "Create A → Delete A → Create A", the aggregated operation will be "Create A", thus reducing the number of incremental operations that the repair thread needs to execute.

[0145] Step 5: Convergence determination.

[0146] When the fragmented work area meets the preset convergence conditions, it is allowed to enter the hierarchical submission stage. If the fragmented work area does not meet the preset convergence conditions, parallel scanning will continue until convergence.

[0147] Step 6: Based on the convergence determination results of the fragment repair patch set that can be submitted, submit the fragment repair patch set for each fragment work area in a hierarchical manner according to the dependency relationship between the metadata of the XFS file system.

[0148] Layered commits are not a one-time global commit, but rather commits layer by layer according to dependencies. For example: The first layer: Submitting metadata related to space allocation (such as free space bitmaps and free space counts for allocation groups). Space allocation is the foundational layer of metadata, and the correctness of space allocation is a prerequisite for subsequent inode and directory entry submissions.

[0149] The second layer involves submitting metadata related to the inode. Inodes depend on the spatial location information already submitted at the space allocation layer, therefore they must be submitted only after the first layer has been completed.

[0150] The third level: Commit secondary indexes of directory / attribute classes (such as directory entries and extended attributes). Directory entries and attribute indexes depend on the existence and location information of inodes, so they can only be committed after the second level has been completed.

[0151] Within each layer, fragment repair patch sets from multiple fragment workspaces can be committed in parallel because there are usually no direct dependencies between fragments within the same layer, while fragments between layers are committed sequentially to ensure that metadata dependencies are not broken.

[0152] Step 7: Determine whether the fragmented patch set has been successfully submitted. If the submission is successful, proceed to Step 8; if the submission fails, proceed to Step 9.

[0153] Step 8: Release the worker thread corresponding to the sharded work area and clear the isolation markers of the damaged objects in the sharded work area.

[0154] Step 9: When a shard repair patch set fails to commit, only the shard repair patch set that failed to commit is rolled back, without affecting other stable shard workspaces.

[0155] This embodiment of the application, through a fragmented design, transforms global lock contention into local contention within fragments, significantly reducing the blocking of front-end services during the repair process and improving the overall concurrency performance of the system. By using incremental local queuing and batch merging (deduplication, sorting, and aggregation), this embodiment reduces redundant processing and invalid traversal of incremental records, improving the efficiency of incremental absorption and reducing the computational overhead of the repair thread. Through convergence determination, this embodiment enables the repair process to accurately determine when it is safe to commit, avoiding the commit of unstable results and improving the reliability of the repair results. Through layered commits and partial rollbacks, this embodiment only needs to roll back the associated fragment and the patch set of that layer when a commit fails, without affecting other stable fragments, significantly reducing the rollback cost after failure and improving the fault tolerance of online repair.

[0156] The core innovation of the technical solution provided in this application lies in the collaborative mechanism of "anomaly classification + local isolation + fragmented concurrent repair," which has the following advantages compared with related technologies: 1. Reduce the probability of global shutdown due to anomalies: By classifying anomalies and isolating them locally, a global forced shutdown is converged into a fallback path, and most local, reconstructable anomalies can be repaired without interrupting business operations. Compared to the conservative strategy of "anomalies equal global shutdown" in related technologies, the embodiments of this application significantly improve the availability of the XFS file system, and are especially suitable for scenarios with extremely high requirements for business continuity, effectively shortening the business recovery window.

[0157] 2. Narrowing the scope of the fault impact and limiting it to the affected objects: Unaffected objects can continue to provide services normally, while access to only affected objects is restricted, significantly improving business continuity. In related technologies, a global forced shutdown would render all normal objects unusable. However, this application embodiment uses isolation tables and isolation markers to precisely restrict the access scope of affected objects, ensuring that unaffected allocation groups, index nodes, and other objects can continue to provide services, minimizing the impact of the fault.

[0158] 3. Reduce global lock contention and global temporary storage hotspots: By using sharded work areas and local incremental record queues with the allocation group or the scope of influence of the damaged object as keys, scanning threads, foreground transactions, and commit threads do not need to frequently contend for the same global structure. In online repair solutions of related technologies, the global temporary storage structure is prone to becoming a contention hotspot, leading to increased synchronization overhead and foreground business lag. The embodiments of this application process the repair task in shards, with each sharded work area maintaining its local state and local queue, significantly reducing contention for shared structures and balancing repair efficiency with foreground business performance.

[0159] 4. Improved commitability and rollback reliability of online repairs: Through water level stability determination, cross-validation, and a layered commit mechanism, the repair process more easily determines when to commit and can converge the rollback scope to the relevant shards after failure. Related technologies lack clear convergence criteria, easily leading to unreliable repair results, and requiring a global rollback after a failed commit, which is extremely costly. This application's embodiment ensures reliable repair results through multi-dimensional convergence determination, while the local rollback mechanism significantly reduces rollback costs, improving the stability and reliability of online repairs.

[0160] This embodiment maximizes business availability by prioritizing online repair through anomaly classification and local isolation. Furthermore, when an anomaly reaches level three (affecting log replay correctness or global invariants across allocation groups), a forced shutdown is executed to prevent unrecoverable anomalies from spreading and causing complete data corruption. This embodiment improves availability while retaining a safety fallback mechanism, achieving a closed-loop anomaly handling system of "availability first, safety fallback." This avoids both the frequent downtime caused by "overly conservative" approaches in traditional solutions and the escalation of errors caused by "overly aggressive" approaches.

[0161] It should be further explained that the technical solution of this application embodiment is not a simple partial adjustment to the online repair mechanism of the existing XFS file system, but rather a full-process optimization system of "anomaly detection - anomaly classification - local isolation - online repair - submission of repair results", which deeply integrates anomaly handling and online repair, and solves the core pain points of "large downtime impact, intense lock contention, high synchronization overhead, and high rollback cost" in related technologies.

[0162] The core beneficial effect of this application's embodiments lies in the fact that by constructing a complete technical chain of "abnormal tuple acquisition - abnormal classification - local isolation - partitioned concurrent repair," the entire process of online repair of the XFS file system is optimized, effectively overcoming the core defects of related technologies. This method provides accurate data support for abnormal classification by acquiring abnormal tuple information, avoiding the blindness of abnormal handling in related technologies; through abnormal level division, differentiated handling of abnormalities is achieved, breaking the conservative model of "abnormalities equal global shutdown," accurately distinguishing between repairable abnormalities and those requiring forced shutdown, significantly improving the availability of the XFS file system; through the local isolation control strategy, objects to be repaired are isolated from normal objects, ensuring that undamaged objects provide normal services, reducing the scope of fault impact, and guaranteeing business continuity; through the partitioned concurrent repair strategy, repair tasks are processed in parallel in segments, reducing global lock contention and synchronization overhead, solving the problems of low repair efficiency and interference with front-end services in online repair of related technologies, while also improving the reliability and rollbackability of repair results. Overall, this method does not require the deployment of additional independent repair programs, can be deeply integrated with the native XFS mechanism, and balances practicality, implementability and efficiency. It effectively improves the stability and availability of the XFS file system and is suitable for various XFS storage scenarios with high business continuity requirements, fundamentally solving the core pain points of existing online repair technologies.

[0163] The online repair method for the XFS file system provided in this application forms a closed-loop online repair solution. First, by acquiring abnormal tuple information from metadata, it achieves accurate identification and quantitative description of anomalies, solving the problems of vague anomaly information and inability to accurately locate the core of the fault in related technologies. This provides a solid data foundation for subsequent tiered handling and avoids the drawbacks of blind repair or over-handling. Second, based on the anomaly level classification of abnormal tuple information, it realizes the core idea of ​​"differentiated handling," breaking the "one-size-fits-all" anomaly handling mode in related technologies. It clearly distinguishes between repairable anomalies and those requiring forced shutdown, ensuring system security while minimizing the risk of business interruption. Furthermore, the execution of the local isolation control strategy achieves precise control over the scope of the fault, physically isolating damaged objects from normal business objects, ensuring that undamaged objects provide normal service. This effectively solves the pain point of fault propagation leading to overall business paralysis in related technologies and significantly improves the business continuity of the system. Finally, the application of the partitioned concurrent repair strategy decomposes the repair task into independent and parallel sharded workflows, which not only greatly improves the efficiency of online repair and shortens the repair cycle, but also reduces lock contention and synchronization overhead during the repair process through local state maintenance and partial rollback mechanisms, thus balancing repair reliability and front-end business performance.

[0164] In summary, this method achieves the goals of "accurate identification, hierarchical handling, local isolation, and efficient repair" for online XFS file system repair through collaborative optimization of the entire process. It does not require large-scale modification of the existing XFS file system, has strong compatibility, low implementation cost, and can be widely adapted to various XFS storage scenarios, effectively filling the gaps in the process systematization and practicality of existing online repair technologies.

[0165] The technical solution of this application can be directly integrated into the XFS file system kernel space, and is seamlessly compatible with the native XFS mechanism. It does not require additional deployment of independent hardware or software modules, has low deployment cost and strong implementability, and can be widely used in various storage devices and servers based on the XFS file system. It is especially suitable for scenarios with high requirements for data availability and business continuity, such as database servers, storage arrays, and virtualization hosts, and has extremely high practical value and promotion prospects.

[0166] Furthermore, the anomaly classification rules, fragmentation criteria, convergence judgment conditions, and layered submission order described in this application embodiment can all be flexibly configured according to the needs of actual application scenarios without modifying the core logic, further improving the flexibility and adaptability of the technical solution and meeting the online repair needs of XFS file systems in different industries and scenarios.

[0167] See Figure 5 , Figure 5 This is a schematic diagram of an online XFS file system repair device provided in an embodiment of this application. This application also provides an online XFS file system repair device, which includes: The abnormal information acquisition unit 51 is configured to acquire abnormal tuple information of the metadata when an abnormality of the XFS file system is detected. The abnormal tuple information includes at least one of the following: the type of damaged object, the allocation group identifier, the log consistency status, and the scope of impact of the damaged object. Anomaly classification unit 52 is configured to classify the anomaly level of metadata into level 1 anomaly, level 2 anomaly, or level 3 anomaly based on the impact range of the damaged object in the anomaly tuple information and the log consistency status. Local isolation unit 53 is configured to execute a local isolation control strategy on the damaged object when the metadata anomaly level is level one or level two, thus restricting the damaged object to the local isolation area; The partitioned concurrent repair unit 54 is configured to execute a partitioned concurrent repair strategy within a local isolated area. The partitioned concurrent repair strategy includes: dividing the repair task for the damaged object into multiple independent shard work areas, with each shard work area performing online repair operations and submitting repair results in a hierarchical manner to obtain the repaired object. Forced shutdown unit 55 is configured to perform a forced shutdown operation on the XFS file system when the metadata exception level is level three.

[0168] In some embodiments, the local isolation unit 53 includes: The isolation marker setting module is configured to set a primary isolation marker and a secondary isolation marker in the damaged allocation group table or the damaged index node table; wherein, the primary isolation marker is used to identify the primary isolation status of the damaged object under the primary abnormality condition; the secondary isolation marker is used to identify the secondary isolation status of the damaged object under the secondary abnormality condition; The first response module is configured to return response data that prohibits write operations and degrades to a read-only state when it receives an access request for a damaged object with a Level 1 isolation tag. The second response module is configured to return an access denial request or an error response when it receives an access request for a compromised object with a secondary isolation tag.

[0169] In some embodiments, the abnormal tuple information further includes cross-validation rules, and the apparatus further includes: The Cancel Access unit is configured to cancel the primary and secondary isolation markers and restore normal access to the damaged object when the online repair operation is successful. When online repair fails and the impact does not spread, maintain the local isolation of the damaged object; If the online repair operation fails and the impact of a newly damaged object exceeds the impact of the isolated objects or global invariants across allocation groups are damaged, a forced shutdown operation is performed on the XFS file system. Among them, the loss of global invariants across allocation groups refers to the following: cross-validation is performed by cross-validation rules and it is found that the metadata consistency constraints between multiple allocation groups are not met. The metadata consistency constraints include at least one of the following: consistency of free space count between the superblock and each allocation group, consistency of the total number of index nodes across allocation groups, and integrity of space mapping across allocation groups.

[0170] In some embodiments, each sharded workspace contains at least one of the following: The scanning cursor is used to record the scanning progress of each work area segment; The local incremental record queue is used to store the incremental records corresponding to each shard work area; Version watermark is used to identify the fix version for each shard workspace; A sharded repair patch set is used to store the repair results for each sharded workspace. The failure rollback log is used to record rollback information when an online repair operation fails.

[0171] In some embodiments, the partition concurrency repair unit 54 includes: The partitioning module is configured to divide the repair task into multiple independent shard work areas based on the allocation group identifier, metadata type, and object key range of the damaged object, and the repair tasks of each shard work area are executed in parallel. Wherein, the object key range represents a processing interval composed of multiple object keys, used to divide the scan boundaries of each of the segmented work areas; the object key is used to identify metadata objects, and the metadata objects include at least one of the following: inode, directory entry, free space block.

[0172] In some embodiments, the device further includes: The thread allocation unit is configured to determine the scan concurrency based on the system load and allocate worker threads to each of the said work areas. The parallel scanning unit is configured to perform parallel scanning of damaged objects in the corresponding sliced ​​work area through each of the worker threads, and maintain the local scanning state; An additional recording unit is configured to generate a corresponding incremental record when a modification operation on the metadata related to the damaged object is detected, and write the incremental record to the local incremental record queue of the shard work area to which the damaged object belongs. The incremental record includes at least one of the following: object key, operation type, transaction sequence number, and identifier of the shard work area.

[0173] In some embodiments, the device further includes: The convergence determination unit is configured to determine that the patch set of each shard work area can be submitted when each shard work area meets the preset convergence conditions; wherein, the preset convergence conditions include at least one of the following: the scanning range of the scanning cursor has covered the target object range of the shard work area, the local incremental record queue is empty, the version water level remains stable within a preset period, and all cross-validations for the shard work area have passed. The submission unit is configured to submit the fragment repair patch set of each fragment work area in a hierarchical manner according to the dependency relationship between the metadata, based on the determination result that the fragment repair patch set can be submitted; The rollback unit is configured to roll back only the failed shard repair patch set when a certain shard repair patch set fails to commit.

[0174] In some embodiments, the device further includes: The batch consumption unit is configured to perform batch consumption on each incremental record in the local incremental record queue when the concurrency of the scanning thread or merging thread in the worker thread reaches a preset threshold. The aggregation unit is configured to perform deduplication, sorting, and aggregation operations on incremental records consumed in batches, and update the aggregated results to the temporary storage area of ​​the corresponding sharded work area.

[0175] In some embodiments, the anomaly classification unit 52 includes: The Level 1 anomaly classification module is configured to classify the metadata anomaly level as Level 1 anomaly when the impact of the damaged object is limited to a single enumerable object and the log consistency status is undistorted. The secondary anomaly classification module is configured to classify the anomaly level of the metadata as a secondary anomaly when the impact of the damaged object is limited to a single allocation group and cross-allocation group consistency is not compromised. The three-level anomaly classification module is configured to classify the anomaly level of the metadata into three levels when the impact range of the damaged object exceeds a single allocation group, or the log consistency status indicates that the log replay correctness is damaged, or the integrity of the critical space mapping is damaged, or the scope of damage cannot be determined.

[0176] It should be noted that the execution subject of each step of the method provided in this application embodiment can be the same device, or the method can be executed by different devices. For example, the execution subject of steps S101 and S102 can be device 1, and the execution subject of step S103 can be device 2; or the execution subject of step S101 can be device 1, and the execution subject of steps S102 and S103 can be device 2; and so on.

[0177] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0178] In some embodiments, this application also provides a computer program product comprising a computer program / instruction that, when executed by a processor, implements the method described in any embodiment of this application.

[0179] Therefore, this application also proposes a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the methods described in any embodiment of this application.

[0180] Furthermore, this application also proposes an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in any embodiment of this application.

[0181] This application provides an electronic device. Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 6 As shown, this embodiment provides an electronic device 600, which includes: one or more processors 620; and a storage device 610 for storing one or more programs. When the one or more programs are run by the one or more processors 620, the one or more processors 620 implement an online repair method for an XFS file system provided in this application embodiment. The method includes: When an abnormality in the metadata of the XFS file system is detected, the abnormal tuple information of the metadata is obtained. The abnormal tuple information includes at least one of the following: the type of damaged object, the allocation group identifier, the log consistency status, and the scope of the impact of the damaged object. Based on the impact range of the damaged object and the log consistency status in the abnormal tuple information, the abnormality level of the metadata is divided into Level 1, Level 2, or Level 3 abnormality. When the anomaly level of the metadata is Level 1 or Level 2, a local isolation control strategy is implemented on the damaged object to restrict the damaged object to a local isolation area. A partitioned concurrent repair strategy is executed within the local isolation area. The partitioned concurrent repair strategy includes: dividing the repair task for the damaged object into multiple independent partitioned work areas, each of which performs online repair operations and submits repair results in a hierarchical manner to obtain the repaired object. When the metadata exception level is level three, a forced shutdown operation is performed on the XFS file system.

[0182] Figure 6 The electronic device 600 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0183] like Figure 6 As shown, the electronic device 600 includes a processor 620, a storage device 610, an input device 630, and an output device 640; the number of processors 620 in the electronic device can be one or more. Figure 6 Taking a processor 620 as an example; the processor 620, storage device 610, input device 630, and output device 640 in the electronic device can be connected via a bus or other means. Figure 6Taking the connection between China and Israel via bus 650 as an example.

[0184] Storage device 610, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and module units, such as program instructions corresponding to an online repair method for an XFS file system in an embodiment of this application.

[0185] Storage device 610 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on terminal usage. Furthermore, storage device 610 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, storage device 610 may further include memory remotely located relative to processor 620, and these remote memories can be connected via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0186] Input device 630 can be used to receive input digital, character, or voice information, and to generate key signal inputs related to user settings and function control of the electronic device. Output device 640 may include electronic devices such as a display screen and a speaker.

[0187] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0188] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0189] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0190] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0191] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0192] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0193] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0194] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. An online repair method for an XFS file system, characterized in that, The method includes: When an abnormality in the metadata of the XFS file system is detected, the abnormal tuple information of the metadata is obtained. The abnormal tuple information includes at least one of the following: the type of damaged object, the allocation group identifier, the log consistency status, and the impact range of the damaged object. Based on the impact range of the damaged object and the log consistency status in the abnormal tuple information, the abnormality level of the metadata is divided into Level 1, Level 2, or Level 3 abnormality. When the anomaly level of the metadata is Level 1 or Level 2, a local isolation control strategy is implemented on the damaged object to restrict the damaged object to a local isolation area. A partitioned concurrent repair strategy is executed within the local isolation area. The partitioned concurrent repair strategy includes: dividing the repair task for the damaged object into multiple independent partitioned work areas, each of which performs online repair operations and submits repair results in a hierarchical manner to obtain the repaired object. When the metadata exception level is level three, a forced shutdown operation is performed on the XFS file system.

2. The online repair method for the XFS file system according to claim 1, characterized in that, When the anomaly level of the metadata is Level 1 or Level 2, a local isolation control strategy is implemented for the damaged object, restricting the damaged object to a local isolation area, including: Set a primary isolation flag and a secondary isolation flag in the damaged allocation group table or the damaged index node table; wherein, the primary isolation flag is used to identify the primary isolation status of the damaged object under the primary abnormality condition; the secondary isolation flag is used to identify the secondary isolation status of the damaged object under the secondary abnormality condition; When an access request is received for a damaged object with the first-level isolation tag, a response is returned that prohibits write operations and downgrades the status to read-only. When an access request is received for a compromised object with the secondary isolation tag, a response data that either denies access or returns an error message is returned.

3. The online repair method for the XFS file system according to claim 2, characterized in that, The abnormal tuple information also includes cross-validation rules, and the method further includes: When the online repair operation is successful, the primary isolation marker and the secondary isolation marker are removed, and normal access to the damaged object is restored. When the online repair operation fails and the scope of the impact does not expand, the local isolation state of the damaged object is maintained; When the online repair operation fails, and the impact range of a newly damaged object is detected to exceed the impact range of the isolated object or the global invariant across the allocation group is damaged, the forced shutdown operation is triggered. Wherein, the impaired global invariant across allocation groups means that cross-validation through the cross-validation rules detects that the metadata consistency constraints between multiple allocation groups are not met. The metadata consistency constraints include at least one of the following: consistency of free space count between the superblock and each allocation group, consistency of the total number of index nodes across allocation groups, and integrity of space mapping across allocation groups.

4. The online repair method for the XFS file system according to claim 1, characterized in that, Each of the said partitioned workspaces contains at least one of the following: A scanning cursor is used to record the scanning progress of each of the aforementioned work areas; A local incremental record queue is used to store incremental records corresponding to each of the aforementioned work areas; Version watermark, used to identify the fix version for each of the aforementioned workspaces; A sharded repair patch set is used to store the repair results for each sharded work area; The failure rollback log is used to record rollback information when the online repair operation fails.

5. The online repair method for the XFS file system according to claim 4, characterized in that, The repair task for the damaged object is divided into multiple independent work areas, including: Based on the allocation group identifier, metadata type, and object key range of the damaged object, the repair task is divided into multiple independent shard work areas, and the repair tasks in each shard work area are executed in parallel. Wherein, the object key range represents a processing interval composed of multiple object keys, used to divide the scan boundaries of each of the segmented work areas; the object key is used to identify metadata objects, and the metadata objects include at least one of the following: inode, directory entry, free space block.

6. The online repair method for the XFS file system according to claim 5, characterized in that, The method further includes: The scanning concurrency is determined based on the system load, and a worker thread is allocated to each of the said work areas. Each of the aforementioned worker threads performs parallel scanning of the damaged objects within the corresponding sliced ​​work area and maintains the local scan status; When a modification operation on the metadata related to the damaged object is detected, a corresponding incremental record is generated and written to the local incremental record queue of the shard work area to which the damaged object belongs. The incremental record includes at least one of the following: object key, operation type, transaction sequence number and the identifier of the shard work area.

7. The online repair method for the XFS file system according to claim 5 or 6, characterized in that, The method further includes: When each of the sharded work areas meets the preset convergence conditions, it is determined that the shard repair patch set of each sharded work area can be submitted; wherein, the preset convergence conditions include at least one of the following: the scanning range of the scanning cursor has covered the target object range of the sharded work area, the local incremental record queue is empty, the version level remains stable within a preset period, and all cross-validations for the sharded work area pass. Based on the determination result that the fragment repair patch set can be submitted, the fragment repair patch set of each fragment work area is submitted in a hierarchical manner according to the dependency relationship between the metadata; When a fragment repair patch set fails to commit, only the fragment repair patch set that failed to commit is rolled back.

8. The online repair method for the XFS file system according to claim 6, characterized in that, The method further includes: When the concurrency of the scanning or merging threads in the worker threads reaches a preset threshold, batch consumption is performed on the incremental records in each of the local incremental record queues: Perform deduplication, sorting, and aggregation operations on the incremental records consumed in batches, and update the aggregated results to the temporary storage area of ​​the corresponding sharded work area.

9. The online repair method for the XFS file system according to claim 1, characterized in that, Based on the impact scope of the damaged object and the log consistency status in the abnormal tuple information, the abnormality level of the metadata is divided into Level 1, Level 2, or Level 3 abnormalities, including: When the impact of the damaged object is limited to a single enumerable object, and the log consistency status is undistorted, the abnormality level of the metadata is classified as Level 1 abnormality. When the impact of the damaged object is limited to a single allocation group and cross-allocation group consistency is not compromised, the anomaly level of the metadata is classified as a level two anomaly. When the impact of the damaged object exceeds a single allocation group, or the log consistency status indicates that the log replay correctness is compromised, or the integrity of the critical space mapping is compromised, or the scope of the damage cannot be determined, the abnormality level of the metadata is classified into three levels of abnormality.

10. An online repair device for an XFS file system, characterized in that, The device includes: An anomaly information acquisition unit is configured to acquire anomaly tuple information of the metadata when an anomaly is detected in the XFS file system. The anomaly tuple information includes at least one of the following: damaged object type, allocation group identifier, log consistency status, and the impact range of the damaged object. An anomaly classification unit is configured to classify the anomaly level of the metadata into Level 1, Level 2, or Level 3 anomalies based on the impact range of the damaged object and the log consistency status in the anomaly tuple information. The local isolation unit is configured to execute a local isolation control strategy on the damaged object when the anomaly level of the metadata is level one or level two, thereby restricting the damaged object to a local isolation area. The partitioned concurrent repair unit is configured to execute a partitioned concurrent repair strategy within the local isolation area. The partitioned concurrent repair strategy includes: dividing the repair task for the damaged object into multiple independent partitioned work areas, with each partitioned work area performing online repair operations and submitting repair results in a hierarchical manner to obtain the repaired object. The forced shutdown unit is configured to perform a forced shutdown operation on the XFS file system when the exception level of the metadata is level three.

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

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

13. A computer program product, characterized in that, The computer program product includes a computer program / instruction that, when executed by a processor, implements the method as described in any one of claims 1 to 9.

Images