Metadata restoration method and device, computer equipment and storage medium

Abstract

The invention relates to a metadata restoration method and device, computer equipment and a storage medium, and the method comprises the steps: obtaining log data of to-be-checked metadata and operation data of hardware equipment storing the to-be-checked metadata under the condition of not carrying out read-write operation; determining to-be-checked metadata in the to-be-checked metadata according to the log data and the operation data; verifying the metadata to be verified to obtain a verification result; according to the embodiment of the invention, the metadata which may be abnormal can be found in time under the condition that the read-write operation is not performed, and the abnormal metadata in the to-be-verified metadata can be repaired under the condition that the verification result is abnormal, so that the abnormal metadata can be repaired in time under the condition that the read-write operation is not performed, and the reliability of the to-be-verified metadata is improved. The problem that abnormal metadata is found only during read-write operation, and thus read-write cannot be executed due to the abnormal metadata is avoided.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer device, and storage medium for metadata restoration. Background Technology

[0002] Metadata does not directly record the specific content of data, but rather helps people understand, manage, find, and use data by defining its attributes, characteristics, relationships, and other information. For example, in a storage system, metadata is used to manage the allocation of storage space and data access; metadata is a core data structure that ensures the normal operation of the storage system.

[0003] However, metadata in storage systems is susceptible to damage or loss due to various factors. For example, at the hardware level, physical damage to the storage media or firmware update errors can lead to metadata corruption. At the software level, software logic errors or system crashes can cause metadata inconsistencies, all of which can result in metadata corruption. This metadata corruption directly impacts the normal operation of the storage system, rendering user data inaccessible or even leading to permanent data loss. Therefore, timely and effective repair of metadata in storage systems is crucial for ensuring their reliability.

[0004] In existing storage systems, once the metadata in the system is corrupted, the system usually cannot continue to perform normal read and write operations, thus affecting the execution of read and write operations. Summary of the Invention

[0005] Therefore, it is necessary to provide a metadata repair method, apparatus, computer device, and storage medium to address the aforementioned technical problems, so as to minimize the problem of read and write operations failing due to metadata corruption.

[0006] Firstly, this application provides a metadata repair method, including:

[0007] Without performing read / write operations, obtain the log data of the metadata to be inspected, as well as the operating data of the hardware device storing the metadata to be inspected;

[0008] Based on the log data and the runtime data, determine the metadata to be verified in the metadata to be checked;

[0009] The metadata to be verified is verified to obtain the verification result;

[0010] If the verification result is abnormal, the abnormal metadata in the metadata to be verified shall be repaired.

[0011] In the above embodiments, without performing read / write operations, log data of the metadata to be checked and the operating data of the hardware device storing the metadata to be checked are obtained; and based on the log data and the operating data, the metadata to be verified in the metadata to be checked is determined; and the metadata to be verified is verified to obtain the verification result. This allows for the timely detection of potentially abnormal metadata without performing read / write operations, and the repair of abnormal metadata in the metadata to be verified if the verification result is abnormal. This timely repair of abnormal metadata without performing read / write operations avoids the problem of abnormal metadata being discovered only during read / write operations, thereby preventing read / write operations from failing due to abnormal metadata.

[0012] In one embodiment, determining the metadata to be verified in the metadata to be checked based on the log data and the runtime data includes:

[0013] Based on the anomaly alerts and log count information in the log data, determine the first target metadata in the metadata to be inspected;

[0014] Based on the operational data, determine the second target metadata in the metadata to be inspected;

[0015] The first target metadata and the second target metadata are used as the metadata to be verified.

[0016] In the above embodiments, the first target metadata and the second target metadata are identified based on log data and running data, respectively, and then the first target metadata and the second target metadata are integrated into the metadata to be verified, making the determination of the metadata to be verified more logical and comprehensive, and improving the accuracy of abnormal metadata identification.

[0017] In one embodiment, determining the first target metadata in the metadata to be inspected based on the anomaly alert information and log quantity information in the log data includes:

[0018] Based on the anomaly message in the log data, determine the first indication metadata and the first associated metadata stored in the metadata to be inspected that is associated with the first indication metadata; wherein, the first indication metadata is the metadata indicated by the anomaly message in the metadata to be inspected;

[0019] Based on the reference operation quantity and the log quantity information in the log data, determine the second indication metadata and the second associated metadata stored in the metadata to be checked that is associated with the second indication metadata; wherein, the second indication metadata is the metadata corresponding to the abnormal log quantity information in the metadata to be checked;

[0020] The first target metadata is determined based on the first indication metadata, the second indication metadata, the first associated metadata, and the second associated metadata.

[0021] In the above embodiments, the first target metadata is accurately determined based on the abnormal prompt information and log quantity information, combined with the correlation between metadata, thereby improving the accuracy of abnormal metadata identification.

[0022] In one embodiment, based on the reference operation quantity and the log quantity information in the log data, the second associated metadata stored in the metadata to be inspected, which is associated with the second indication metadata, is determined, including:

[0023] Based on the reference operation quantity and the log quantity information in the log data, determine the physical storage unit corresponding to the second indication metadata;

[0024] Based on the metadata stored in the physical storage unit that matches the attribute information of the second indication metadata, determine the second associated metadata stored in the metadata to be inspected that is associated with the second indication metadata.

[0025] In the above embodiments, the reliability of the determined second associated metadata is improved by locating the physical storage unit and matching attribute information.

[0026] In one embodiment, determining the second target metadata in the metadata to be inspected based on the operational data includes:

[0027] Based on the operational data, identify the abnormal device among the hardware devices storing the metadata to be inspected;

[0028] Based on the metadata stored in the abnormal device, determine the second target metadata in the metadata to be inspected.

[0029] In the above embodiments, by first locating the abnormal device and then filtering the metadata, the efficiency of determining the second target metadata is improved on the one hand, and on the other hand, it ensures that potential abnormal metadata at the hardware level is not overlooked.

[0030] In one embodiment, the step of verifying the metadata to be verified and obtaining the verification result includes:

[0031] Based on the metadata association relationship, determine the third associated metadata corresponding to the metadata to be verified;

[0032] The third associated metadata and the metadata to be verified are matched to obtain the matching result;

[0033] If the matching result shows that the third associated metadata matches the metadata to be verified, then the verification result is determined to be normal.

[0034] If the matching result indicates that the third associated metadata and the metadata to be verified do not match, then the verification result is determined to be abnormal.

[0035] In the above embodiments, the verification is performed by using the correlation between metadata, which improves the efficiency and accuracy of the verification.

[0036] In one embodiment, the metadata to be inspected is linearly continuous metadata, and in the case of read / write operations, the method further includes:

[0037] If abnormal metadata is detected, the abnormal metadata is investigated based on at least one data identifier, and the investigated abnormal metadata is repaired; wherein, the data identifier is generated during the periodic verification of the metadata to be checked and is used to identify the data range of normal metadata.

[0038] In the above embodiments, for linear and continuous metadata, combining the data identifier generated by periodic verification can narrow the scope of anomaly investigation, improve repair efficiency, and avoid long-term interruption of read and write operations.

[0039] In one embodiment, the method further includes:

[0040] The metadata to be checked is periodically verified, and if no abnormal metadata is found in the metadata to be checked during each verification process, a new data identifier is generated and the data identifiers generated in the previous verification process are retained.

[0041] If abnormal metadata exists in the metadata to be checked, the abnormal metadata will be repaired, a new data identifier will be generated, and the data identifiers generated in the historical verification process will be discarded.

[0042] In the above embodiments, by periodically verifying linear and continuous metadata and generating data identifiers, it is convenient to discover abnormal metadata during read and write operations, and to quickly locate abnormal metadata based on the data identifiers, thereby improving the efficiency of investigating abnormal metadata.

[0043] In one embodiment, the step of checking abnormal metadata based on at least one data identifier includes:

[0044] Sort the data identifiers according to their generation time from most recent to oldest.

[0045] The data identifier corresponding to the latest stored metadata is used as the first data identifier, and the first data identifier in the sorting order is used as the second data identifier;

[0046] The scope of data screening is determined based on the first data identifier and the second data identifier;

[0047] Investigate abnormal metadata within the scope of the data investigation;

[0048] If no abnormal metadata is found, the second data identifier is used as the new first data identifier, and the next data identifier of the second data identifier is used as the new second data identifier. Then, the operation of determining the data investigation scope based on the first data identifier and the second data identifier is returned until the abnormal metadata is found.

[0049] In the above embodiments, by sorting and dynamically updating the data identifiers, the scope of abnormal metadata is gradually narrowed down and accurately located, thereby improving the efficiency of anomaly detection for linear continuous metadata.

[0050] Secondly, this application also provides a metadata repair apparatus, comprising:

[0051] The acquisition module is used to acquire log data of the metadata to be inspected and the operating data of the hardware device storing the metadata to be inspected without performing read or write operations.

[0052] The determination module is used to determine the metadata to be verified in the metadata to be checked based on the log data and the running data.

[0053] The verification module is used to verify the metadata to be verified and obtain the verification result;

[0054] The repair module is used to repair the abnormal metadata in the metadata to be verified when the verification result is abnormal.

[0055] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0056] Without performing read / write operations, obtain the log data of the metadata to be inspected, as well as the operating data of the hardware device storing the metadata to be inspected;

[0057] Based on the log data and the runtime data, determine the metadata to be verified in the metadata to be checked;

[0058] The metadata to be verified is verified to obtain the verification result;

[0059] If the verification result is abnormal, the abnormal metadata in the metadata to be verified shall be repaired.

[0060] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0061] Without performing read / write operations, obtain the log data of the metadata to be inspected, as well as the operating data of the hardware device storing the metadata to be inspected;

[0062] Based on the log data and the runtime data, determine the metadata to be verified in the metadata to be checked;

[0063] The metadata to be verified is verified to obtain the verification result;

[0064] If the verification result is abnormal, the abnormal metadata in the metadata to be verified shall be repaired.

[0065] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0066] Without performing read / write operations, obtain the log data of the metadata to be inspected, as well as the operating data of the hardware device storing the metadata to be inspected;

[0067] Based on the log data and the runtime data, determine the metadata to be verified in the metadata to be checked;

[0068] The metadata to be verified is verified to obtain the verification result;

[0069] If the verification result is abnormal, the abnormal metadata in the metadata to be verified shall be repaired.

[0070] The aforementioned metadata repair method, apparatus, computer equipment, and storage medium, without performing read / write operations, acquire log data of the metadata to be checked and operational data of the hardware device storing the metadata to be checked; determine the metadata to be verified in the metadata to be checked based on the log data and operational data; and verify the metadata to be verified to obtain a verification result. This allows for the timely detection of potentially abnormal metadata without performing read / write operations, and the repair of abnormal metadata in the metadata to be verified if the verification result is abnormal. This timely repair of abnormal metadata avoids the problem of read / write operations failing due to abnormal metadata, as it prevents the discovery of abnormal metadata only during read / write operations. Attached Figure Description

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

[0072] Figure 1 This is a flowchart illustrating a metadata repair method in one embodiment;

[0073] Figure 2 This is a schematic diagram of the process for determining the metadata to be verified in one embodiment;

[0074] Figure 3 This is a schematic diagram of the process for determining the first target metadata in one embodiment;

[0075] Figure 4 This is a schematic diagram of the process for determining the second associated metadata in one embodiment;

[0076] Figure 5 This is a schematic diagram of the process for determining the second target metadata in one embodiment;

[0077] Figure 6A This is a flowchart illustrating the process of validating metadata to be verified in one embodiment.

[0078] Figure 6B This is a schematic diagram of the metadata association architecture in an all-flash storage system according to one embodiment;

[0079] Figure 7 This is a flowchart illustrating the process of checking abnormal metadata in one embodiment;

[0080] Figure 8 This is a flowchart illustrating the metadata repair method in another embodiment;

[0081] Figure 9 This is a structural block diagram of a metadata repair device in one embodiment;

[0082] Figure 10 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0083] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0084] The metadata repair method provided in this application embodiment can be applied to application scenarios that identify and repair abnormal metadata. This method can be executed by a server or by a terminal.

[0085] The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. The terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle systems, and projection devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can include virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses.

[0086] In one exemplary embodiment, such as Figure 1 As shown, a metadata repair method is provided. Taking the application of this method to a server as an example, the method includes the following steps:

[0087] S101, without performing read / write operations, obtains log data of the metadata to be checked, as well as the operating data of the hardware device storing the metadata to be checked.

[0088] Metadata does not directly record the specific content of data, but rather helps people understand, manage, find, and use data by defining its attributes, characteristics, relationships, and other information. For example, in a storage system, metadata is used to manage the allocation of storage space and data access; metadata is a core data structure that ensures the normal operation of the storage system.

[0089] The metadata to be inspected can be metadata that has already been generated and stored. For example, it could be metadata stored in an all-flash storage system.

[0090] Log data records the creation, deletion, modification, and query actions of metadata, including operation type, operation object identifier, time and scenario information, operation result status, and associated auxiliary information. The operation type specifies the concrete action of the metadata, such as "create," "modify," "delete," "query," and "repair." The operation object identifier locates the metadata of a specific operation, such as the Logical Block Addressing (LBA) number, metadata type (LBA table or coordinate diagram), and storage area (disk partition). The time and scenario information records the timestamp of the operation, the business time period it belongs to, and the input / output (I / O) scenario (such as write or read operations). The operation result status indicates whether the operation was successful, failed, and the reason for failure, such as alarms or error messages like "metadata does not exist," "write timeout," and "verification error." Associated auxiliary information, such as the user business identifier (ID) corresponding to the operation, disk health status snapshots, and data checksums, is used for cross-validation.

[0091] For example, let's take metadata stored in an all-flash storage system as an example. During the business idle period of the all-flash storage system, when the system is not performing any read or write operations on user data, the server can obtain log data of the metadata to be checked in the system, and at the same time collect the operating data of the hard drive storing this metadata. The operating data is used to reflect information such as whether the hard drive is in place, its wear level, and whether there are bad blocks.

[0092] S102, Based on log data and runtime data, determine the metadata to be verified in the metadata to be checked.

[0093] By combining abnormal information in log data and device anomalies in hardware operation data, metadata that may be at risk of damage can be filtered out and used as metadata to be verified, thus avoiding the waste of resources caused by indiscriminate verification.

[0094] For example, the acquired log data can be analyzed to identify any anomalies. For instance, if the analysis reveals an anomaly message "metadata not found" in the log data, the metadata corresponding to this anomaly message, along with the metadata stored in association with it, can be used as metadata to be verified, i.e., metadata for the area requiring verification.

[0095] For example, if the hardware device's operating data indicates that a hard drive has a bad block warning, all metadata on the hard drive corresponding to the warning can be used as metadata to be verified.

[0096] S103, validate the metadata to be validated and obtain the validation result.

[0097] For example, the correlation between metadata can be used for matching and verification to determine whether the metadata to be verified is normal and obtain the verification result.

[0098] For example, if the metadata to be verified contains a forward table of LBA->VBA (Virtual Block Address) metadata, the corresponding reverse table of VBA->LBA metadata can be found based on the metadata association. The two are then matched, and it is checked whether all entries in the forward table can be found in the reverse table to obtain the verification result.

[0099] S104. If the verification result is abnormal, repair the abnormal metadata in the metadata to be verified.

[0100] For example, if the verification result is abnormal, the normal metadata corresponding to the abnormal metadata can be found based on the metadata association relationship, and the abnormal metadata can be replaced with the normal metadata to repair the abnormal metadata in the metadata to be verified.

[0101] The aforementioned metadata repair method, without performing read / write operations, acquires the log data of the metadata to be checked and the operating data of the hardware device storing the metadata; determines the metadata to be verified in the metadata to be checked based on the log data and operating data; and verifies the metadata to be verified to obtain the verification result. This method can promptly detect potentially abnormal metadata without performing read / write operations, and repair the abnormal metadata in the metadata to be verified if the verification result is abnormal. It can promptly repair abnormal metadata without performing read / write operations, avoiding the problem of read / write failures caused by abnormal metadata.

[0102] In some alternative implementations, the metadata to be verified can be determined from the metadata to be checked based on log data and runtime data.

[0103] See Figure 2 , Figure 2 A flowchart illustrating the process of determining metadata to be verified is provided, specifically including the following steps:

[0104] S201, Based on the abnormal message and log quantity information in the log data, determine the first target metadata in the metadata to be inspected.

[0105] Error messages are text or code-like information recorded in the log data when metadata is subjected to "create, delete, modify, or query" operations, directly or indirectly indicating that the metadata status is abnormal. For example, error messages may include: metadata does not exist or is missing, metadata format or checksum error, broken metadata association, or abnormal metadata operation permissions or resources.

[0106] Log quantity information refers to the number of log entries corresponding to metadata "create, delete, modify, and query" operations within a specific time period and under a specific business scenario. For example, 1200 metadata creation logs within 1 hour, or 80 metadata repair logs when writing 1TB of user data.

[0107] For example, if the abnormal message in the log data is "metadata modification failed", the metadata corresponding to the abnormal message is determined to be the first potential abnormal metadata; if the average number of metadata creation logs when writing 1TB of user data is 1000, but 1500 creation logs are generated when writing 1TB of data in a certain period, the difference is obvious, then the metadata corresponding to the write operation in that period can be determined as the second potential abnormal metadata; then the first potential metadata, the second potential abnormal metadata, and the metadata associated with the first potential metadata and the second potential abnormal metadata can all be used as the first target metadata.

[0108] S202, Based on the running data, determine the second target metadata in the metadata to be inspected.

[0109] Based on operational data, abnormal hardware devices in the village can be filtered out, and the metadata stored in the abnormal hardware devices can be used as the second target metadata.

[0110] For example, if the running data indicates that two hard drives have failed, then all the metadata stored in these two failed hard drives can be identified as the second target metadata.

[0111] S203, take the first target metadata and the second target metadata as the metadata to be verified.

[0112] Therefore, the data set of the first target metadata and the second target metadata can be used as the metadata to be verified.

[0113] In the above embodiments, the first target metadata and the second target metadata are identified based on log data and running data, respectively, and then the first target metadata and the second target metadata are integrated into the metadata to be verified, making the determination of the metadata to be verified more logical and comprehensive, and improving the accuracy of abnormal metadata identification.

[0114] In some optional implementations, the exception metadata can be determined based on the exception message and the number of logs, and then the first target metadata can be determined based on the exception metadata determined by the two.

[0115] See Figure 3 , Figure 3 A flowchart for determining the first target metadata is provided, which includes the following steps:

[0116] S301, based on the abnormal prompt information in the log data, determine the first associated metadata stored in the first indication metadata and the metadata to be checked that is associated with the first indication metadata.

[0117] The first indicator metadata is the metadata indicated by the exception message in the metadata to be checked. For example, if the exception message is "The metadata query corresponding to LBA-100 failed", then "LBA-100" is the first indicator metadata.

[0118] To avoid overlooking any corrupted data, it is also necessary to identify the first associated metadata stored in association with the first indication metadata. For example, the physical storage unit corresponding to the first indication metadata can be identified first, and then the data stored in that physical storage unit in association with the first indication metadata can be used as the first associated metadata stored in association with the first indication metadata. For instance, if "LBA-100" is stored in segments 0-999 of the LBA table in partition 3 of hard disk 2, then the metadata of segments 0-999 of the LBA table in partition 3 of hard disk 2 can be used as the first associated metadata stored in association with the first indication metadata.

[0119] S302, based on the reference operation quantity and the log quantity information in the log data, determine the second indication metadata and the second associated metadata stored in the metadata to be inspected that is associated with the second indication metadata.

[0120] The second indicator metadata is the metadata corresponding to the abnormal log quantity information in the metadata to be checked. For example, a reference operation quantity can be used as a benchmark to compare the log quantity information and identify the metadata corresponding to the abnormal period. For instance, if the reference operation quantity of metadata deletion logs is 300 when writing 2TB of user data, but 500 deletion logs are generated when writing 2TB of data in a certain period, then the metadata involved in that period can be identified as the second indicator metadata.

[0121] S303, determine the first target metadata based on the first indication metadata, the second indication metadata, the first associated metadata, and the second associated metadata.

[0122] For example, a data set consisting of the first indication metadata, the second indication metadata, the first associated metadata, and the second associated metadata can be used as the first target metadata.

[0123] In the above embodiments, the first target metadata is accurately determined based on the abnormal prompt information and log quantity information, combined with the correlation between metadata, thereby improving the accuracy of abnormal metadata identification.

[0124] In some alternative implementations, during the process of determining the second associated metadata, the physical storage unit can be determined based on the metadata corresponding to the log quantity information of the exception, and then the second associated metadata can be determined in the physical storage unit.

[0125] See Figure 4 , Figure 4 A flowchart for determining the second associated metadata is provided, which includes the following steps:

[0126] S401, based on the reference operation quantity and the log quantity information in the log data, determine the physical storage unit corresponding to the second indication metadata.

[0127] The physical storage unit serves as the storage carrier for metadata. The second indicator metadata can be determined based on the number of reference operations and the number of logs in the log data. Furthermore, the physical storage unit corresponding to the second indicator metadata can be determined based on its physical storage location.

[0128] S402, based on the metadata stored in the physical storage unit that matches the attribute information of the second indication metadata, determine the second associated metadata stored in the metadata to be checked that is associated with the second indication metadata.

[0129] Among them, the attribute information of the second indication metadata is used to identify the operation time, operation type and other information of the second indication metadata.

[0130] For example, metadata that matches the attribute information of the second indication metadata can be filtered from the metadata stored in the physical storage unit. For instance, if 1TB of data is written as a reference operation, and the average number of repair logs is 500 with a reasonable fluctuation of ±30 (i.e., 470-530 logs), and the log quantity information in the log data is from 3 PM to 4 PM on a certain day, and 800 or only 200 repair logs are generated when 1TB of data is written, then the second indication data is the repair log data generated by the write operation from 3 PM to 4 PM on that day. Furthermore, based on the operation type and operation time corresponding to the second indication data, the repair log data generated by the write operation stored in the physical storage unit from 3 PM to 4 PM on a certain day can be used as the second associated metadata associated with the second indication metadata.

[0131] In the above embodiments, the reliability of the determined second associated metadata is improved by locating the physical storage unit and matching attribute information.

[0132] In some alternative implementations, the abnormal hardware device can be identified based on the hardware device's operating data, and then the second target metadata can be determined based on the data stored on the hardware device.

[0133] See Figure 5 , Figure 5 A flowchart illustrating the process of determining the metadata of a second target is provided, specifically including the following steps:

[0134] S501, based on the operational data, identifies the abnormal device among the hardware devices storing the metadata to be inspected.

[0135] For example, if analyzing the operating data of hardware devices reveals alarm messages indicating that hard drive A has excessive wear (exceeding the threshold of 80%) and hard drive B has 10 bad blocks, then hard drive A and hard drive B are identified as abnormal devices.

[0136] S502, based on the metadata stored in the faulty device, determine the second target metadata in the metadata to be inspected.

[0137] For example, the metadata stored in the faulty device can be directly used as the second target metadata to ensure that all metadata that may be affected by the hardware failure is included in the verification scope.

[0138] For example, if hard drive A stores 40 metadata entries and hard drive B stores 35 metadata entries, all 75 metadata entries can be identified as the second target metadata.

[0139] In the above embodiments, by first locating the abnormal device and then filtering the metadata, the efficiency of determining the second target metadata is improved on the one hand, and on the other hand, it ensures that potential abnormal metadata at the hardware level is not overlooked.

[0140] In some optional implementations, the metadata to be verified can be verified based on the third associated original data associated with the metadata to be verified, and the verification result can be obtained.

[0141] See Figure 6A , Figure 6A A flowchart illustrating the process of validating metadata to be verified is provided, which includes the following steps:

[0142] S601, Based on the metadata association relationship, determine the third associated metadata corresponding to the metadata to be verified.

[0143] For example, metadata association can be understood as a fixed correspondence between different metadata based on data management logic, storage structure dependency, or business function association, and is used for metadata integrity verification.

[0144] For example, see all-flash storage systems. Figure 6B , Figure 6B This document provides a schematic diagram of the metadata association architecture in an all-flash storage system. The architecture includes the mapping relationships between Logical Addresses (LBAs), Virtual Addresses (VBAs), and Physical Addresses (Physical File Identifiers, PFIs), as well as the storage system's management logic for "objects, resources, and IDs," specifically including:

[0145] The object abstraction layer, through a layered design of "data objects (dObj)" and "virtual objects (vObj)," decouples user data from the system's internal storage.

[0146] dObj (data object): The allocation status is managed by the dObj allocation bitmap. It is uniquely identified by dObjd and associated with KObj (kernel object) to achieve system-level management. The lifecycle and attributes of the subordinate dSeg (data segment) are managed by the maximum dSegId and dSegInfo.

[0147] vObj (virtual object): uniquely identified by vObjd, associated with the physical dObj through the dObj mapping of vObjd, and its attribute information is recorded by vObjInfo, serving as an intermediary layer between the user's logical object and the physical object.

[0148] The address virtualization layer, through a bidirectional mapping table of three-level addresses (Logical Address LBA, Virtual Address VBA, and Physical Address PFI), decouples user logic from flash physical storage and supports flash characteristics (such as wear leveling).

[0149] Mapping between LBA and VBA: Bidirectional conversion is achieved through VBA→LBA tables and LBA→VBA tables, completing the association between user logical addresses and system virtual addresses.

[0150] VBA to PFI mapping: Bidirectional conversion is achieved through the VBA→PFI table and the PFI→VBA table, completing the association between virtual address and flash physical address.

[0151] Mapping between LBA and PFI: Bidirectional conversion is achieved through the PFI→LBA table and the LBA→PFI table, completing the direct association between user logical addresses and physical addresses.

[0152] The global resource management layer enables unified management of ID allocation, storage resources, and volumes through a global module.

[0153] ID Management: The ID allocator uniformly allocates various IDs such as dObjd, vObjd, and dSegId to ensure uniqueness.

[0154] Storage resource management: The KVDB (key-value database) manages the idle LBA table (idle logical addresses) and the space allocation table (address allocation relationship) to achieve global scheduling of storage resources.

[0155] Volume Management: Enables resource isolation and identification in a multi-volume environment through volume management ID.

[0156] For example, in the metadata association architecture of an all-flash storage system, metadata associations may include mapping associations, subordinate associations, pointing associations, and inclusion associations.

[0157] The mapping relationships can be represented using forward tables and reverse tables. For example, a forward table can be used to record the mapping from logical addresses to physical addresses, such as an LBA to VBA mapping table, where LBA is the logical block address and VBA is the virtual block address. A reverse table can be used to record the mapping from physical addresses to logical addresses, such as a VBA to LBA mapping table.

[0158] The subordinate relationships can be represented by master metadata and attribute metadata. Master metadata is used to uniquely identify the core information of a data block and serves as the index key for data access. Attribute metadata is attached to master metadata and provides supplementary descriptions of the data block; without master metadata, attribute metadata is meaningless. Each piece of master metadata must correspond to a unique set of attribute metadata, and the key information in the attribute metadata (such as data length and checksum) must be consistent with the actual information of the data block pointed to by the master metadata.

[0159] The relationships between data blocks can be represented using index metadata and data block metadata. Index metadata records the mapping from index keys to data block metadata storage addresses; for example, user ID-001 in a hash index table corresponds to data block metadata address-0x00A1. Data block metadata records information about specific data blocks, such as the user's data block LBA range and storage status. The data block metadata storage address recorded in the index metadata must accurately locate valid data block metadata; and the index key information in the data block metadata (such as user ID) must be consistent with the index key of the index metadata.

[0160] The relationships can be represented by parent metadata and child metadata. Parent metadata, such as directory metadata, records the directory name, number of subdirectories / files, and total capacity of data blocks under the directory; partition metadata records the LBA range and used capacity of the partition; child metadata, such as file metadata, records the LBA list corresponding to the file; and data block metadata records information about individual LBAs. The statistical information in the parent metadata (such as the number of child files and total capacity) must be consistent with the cumulative information of all child metadata. For example, if the directory metadata records 10 child files, then the total number of file metadata under that directory must be 10.

[0161] Taking the mapping relationship as an example, assuming that the metadata to be verified is a forward mapping table from LBA to VBA, the third associated metadata corresponding to the metadata to be verified can be determined to be a reverse mapping table from VBA to LBA based on the forward-reverse mapping relationship.

[0162] Taking subordinate relationships as an example, assuming the metadata to be verified is the primary metadata, the third related metadata corresponding to the primary metadata can be determined based on the subordinate relationships.

[0163] Taking the pointing association relationship as an example, assuming that the metadata to be verified is the index metadata, the third associated metadata corresponding to the metadata to be verified is determined to be the data block metadata corresponding to the index metadata based on the pointing association relationship.

[0164] Taking inclusion relationships as an example, assuming the metadata to be verified is directory metadata, the third related metadata can be determined to be the file metadata under the directory based on the inclusion relationships.

[0165] S602, match the third associated metadata with the metadata to be verified to obtain the matching result.

[0166] S603, if the matching result is that the third associated metadata and the metadata to be verified match, then the verification result is determined to be normal.

[0167] S604. If the matching result is that the third associated metadata and the metadata to be verified do not match, then the verification result is determined to be abnormal.

[0168] Taking the mapping relationship as an example, if every LBA to VBA entry in the forward mapping table has a unique corresponding VBA to LBA entry in the reverse mapping table, it means that the third-party metadata and the metadata to be verified match, that is, the verification result is normal. If an entry is missing or the information does not match, it means that the third-party metadata and the metadata to be verified do not match, that is, the verification result is abnormal.

[0169] Taking a subordinate relationship as an example, assuming the metadata to be verified is the primary metadata, and the specific content of the primary metadata is (LBA-200->VBA-800), based on the subordinate relationship, we can check whether the attribute metadata corresponding to the primary metadata exists. If it is missing, it means that the third-party related metadata and the metadata to be verified do not match, that is, the verification result is determined to be abnormal. If it is not missing, we can further determine whether the primary metadata matches the corresponding attribute metadata. If they match, the verification result is determined to be normal; if they do not match, the verification result is determined to be abnormal.

[0170] Taking a pointer association as an example, suppose the metadata to be verified is index metadata, specifically user ID-002 -> data block metadata address-0x00B3. Based on the pointer association, the third associated metadata corresponding to the metadata to be verified is the data block metadata corresponding to address-0x00B3. Then, the association is verified to see if it holds true. For example, check if valid data block metadata exists at address-0x00B3. If the address is invalid or the data is empty, it is determined that the third associated metadata and the metadata to be verified do not match, i.e., the verification result is abnormal. Alternatively, check if the user ID in the data block metadata is 002. If it is 003, it is determined that the third associated metadata and the metadata to be verified do not match, i.e., the verification result is abnormal; if it is 002, it is determined that the third associated metadata and the metadata to be verified match, i.e., the verification result is normal.

[0171] Taking inclusion relationships as an example, suppose the metadata to be verified is directory metadata, specifically "directory A, 8 subfiles, total size 16KB". Based on inclusion relationships, the third related metadata can be determined as "the file metadata of all 8 files under directory A". Then, the number of all subfile metadata can be counted. If it is 7, the parent metadata "number of subfiles" is abnormal, indicating that the metadata to be verified is abnormal. Alternatively, the "file size" of all subfile metadata can be accumulated. If the accumulated size is 14KB, the parent metadata "total size" is abnormal, indicating that the metadata to be verified is abnormal. If all items match, the verification result is normal.

[0172] In the above embodiments, the verification is performed by using the correlation between metadata, which improves the efficiency and accuracy of the verification.

[0173] In some optional implementations, if the metadata to be checked is linearly continuous, and abnormal metadata is detected during read / write operations, the abnormal metadata can be identified based on the data identifier used to identify the data range of normal metadata.

[0174] For example, if abnormal metadata is detected, the abnormal metadata is investigated based on at least one data identifier, and the detected abnormal metadata is repaired. The data identifier is generated during the periodic verification of the metadata to be checked; it can be a metadata version breakpoint used to identify the data range of normal metadata. The data identifier can be a key-value pair (kv) of metadata.

[0175] For example, suppose the metadata to be checked is an LBA table (linear continuous structure). When a user reads or writes data, abnormal metadata is detected. Also suppose that the LBA table has generated three data identifiers through periodic verification, corresponding to the normal data ranges of LBA-0 to LBA-400, LBA-400 to LBA-800, and LBA-800 to LBA-1200, respectively. The abnormal metadata can be identified and repaired based on these data identifiers.

[0176] In the above embodiments, for linear and continuous metadata, combining the data identifier generated by periodic verification can narrow the scope of anomaly investigation, improve repair efficiency, and avoid long-term interruption of read and write operations.

[0177] Among some alternative implementations, this application describes an implementation for generating data identifiers.

[0178] For example, the metadata to be inspected can be periodically validated. For instance, a full validation of the metadata can be scheduled at fixed intervals to detect and correct abnormal data in advance. For example, a full validation of LBA tables in an all-flash storage system can be scheduled monthly.

[0179] If no abnormal metadata is found in the metadata to be checked, a new data identifier is generated, and data identifiers generated during the historical verification process are retained. When all the metadata to be checked is normal, a new data identifier is generated to record the current normal range, while historical identifiers are retained to provide multiple reference benchmarks for subsequent anomaly investigation.

[0180] For example, during this periodic verification, the LBA table data is stored in LBA-1500. If no abnormal metadata is found in the LBA table, new data identifiers corresponding to LBA-0 to LBA-1500 can be generated, while the previously generated data identifiers LBA-0 to LBA-1200 and LBA-0 to LBA-800 are retained.

[0181] If abnormal metadata is found in the metadata to be checked, the abnormal metadata will be repaired, a new data identifier will be generated, and the data identifiers generated during the previous verification process will be discarded. This process avoids errors caused by relying on abnormal historical data for troubleshooting when abnormal metadata is found.

[0182] For example, during this periodic verification, the LBA table data is stored in LBA-1500. It is found that the metadata of LBA-1300 to LBA-1400 in the LBA table is abnormal. After the server repairs it, it generates new data identifiers corresponding to LBA-0 to LBA-1500, and discards all previously generated data identifiers.

[0183] In the above embodiments, by periodically verifying linear and continuous metadata and generating data identifiers, it is convenient to discover abnormal metadata during read and write operations, and to quickly locate abnormal metadata based on the data identifiers, thereby improving the efficiency of investigating abnormal metadata.

[0184] In some optional implementations, the scope of data investigation can be determined based on data identifiers, and then abnormal metadata can be investigated within the scope of data investigation.

[0185] See Figure 7 , Figure 7 A flowchart illustrating the process of investigating abnormal metadata is provided, which includes the following steps:

[0186] S701, sort the data identifiers according to their generation time from most recent to oldest.

[0187] Data identifiers can be sorted in ascending order of their generation time. For example, if there are three data identifiers generated in May 2024 (Identifier A: LBA-0 to LBA-1500), April 2024 (Identifier B: LBA-0 to LBA-1200), and March 2024 (Identifier C: LBA-0 to LBA-800), they can be sorted in ascending order of generation time as Identifier A, Identifier B, and Identifier C.

[0188] S702 uses the data identifier corresponding to the latest stored metadata as the first data identifier and the first data identifier in the sorting order as the second data identifier.

[0189] The data identifier corresponding to the most recently stored metadata can be used as the first data identifier, and the first data identifier in the sorted order can be used as the second data identifier. For example, suppose the most recently stored metadata is LBA-1610, and the corresponding data identifier is identifier D, and the first data identifier in the sorted order is identifier A. Therefore, the first data identifier is identifier D, and the second data identifier is identifier A.

[0190] S703, determine the scope of data screening based on the first data identifier and the second data identifier.

[0191] For example, the first data identifier is identifier D, and the second data identifier is identifier A. The determined data screening range is from LBA-1500 to LBA-1610.

[0192] S704, Investigate abnormal metadata within the scope of data investigation.

[0193] You can check for abnormal metadata in LBA-1500 to LBA-1610.

[0194] S705 If no abnormal metadata is found, the second data identifier is used as the new first data identifier, and the next data identifier of the second data identifier is used as the new second data identifier. Then, the operation of determining the data investigation scope based on the first data identifier and the second data identifier is returned until the abnormal metadata is found.

[0195] For example, if no abnormal metadata is found within LBA-1500 to LBA-1610, the second data identifier (identifier A) can be updated to the new first data identifier, and the next data identifier (identifier B) can be used as the new second data identifier. Then, the process returns to S903. Based on the first data identifier and the second data identifier, the data investigation range is determined to be LBA-1200 to LBA-1500, and the investigation continues until abnormal metadata is found.

[0196] In the above embodiments, by sorting and dynamically updating the data identifiers, the scope of abnormal metadata is gradually narrowed down and accurately located, thereby improving the efficiency of anomaly detection for linear continuous metadata.

[0197] In some alternative implementations, see [link to relevant documentation]. Figure 8 , Figure 8 A flowchart illustrating a metadata repair method is provided, which includes the following steps:

[0198] Step 1: Generating the metadata to be verified.

[0199] Based on the abnormal prompts and log quantity information in the log data of the metadata to be checked, potential abnormal metadata can be located from the software operation level, namely the first target metadata; and based on the hardware device's operating data, metadata stored in the abnormal device can be located from the hardware level, namely the second target metadata; and the first target metadata and the second target metadata can be used as the metadata to be verified.

[0200] Step 2: Data verification.

[0201] It can perform early warning area verification on metadata to be verified, and perform full verification on all metadata to be checked at fixed intervals to avoid missing early warning area verification.

[0202] Step 3: Repair and Data Identification Management.

[0203] After a full verification at a fixed period, if the verification finds that the metadata is corrupted, the abnormal metadata will be repaired and a data identifier (such as data identifier 1, 2...N) will be generated. Each data identifier corresponds to a normal metadata version breakpoint. If the abnormal metadata is detected during a user's read or write operation, the normal metadata version can be quickly called based on the data identifier for rapid repair.

[0204] In the above embodiments, through metadata log analysis and hardware anomaly analysis, potentially corrupted metadata areas can be identified and warned in advance. This allows for rapid and lightweight verification and repair of key warning areas, achieving the goal of repairing corrupted metadata within a short period. Periodic verification ensures that the storage system performs a full verification of metadata at regular intervals, identifying and repairing corrupted metadata in advance, and recording breakpoints in normal metadata versions. When user services encounter metadata problems, the normal version breakpoints recorded by periodic verification can narrow down the scope of metadata verification and repair, achieving the goal of quickly restoring user services.

[0205] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0206] Based on the same inventive concept, this application also provides a metadata repair apparatus for implementing the metadata repair method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more metadata repair apparatus embodiments provided below can be found in the limitations of the metadata repair method described above, and will not be repeated here.

[0207] In one exemplary embodiment, such as Figure 9 As shown, a metadata repair device is provided, comprising:

[0208] The acquisition module 10 is used to acquire log data of the metadata to be inspected and the operating data of the hardware device storing the metadata to be inspected without performing read or write operations.

[0209] The determination module 20 is used to determine the metadata to be verified in the metadata to be checked based on the log data and the running data;

[0210] Verification module 30 is used to verify the metadata to be verified and obtain the verification result;

[0211] Repair module 40 is used to repair the abnormal metadata in the metadata to be verified when the verification result is abnormal.

[0212] In one embodiment, the determining module 20 specifically includes:

[0213] The first determining unit is used to determine the first target metadata in the metadata to be inspected based on the abnormal prompt information and log quantity information in the log data.

[0214] The second determining unit is used to determine the second target metadata in the metadata to be inspected based on the running data;

[0215] The third determining unit is used to take the first target metadata and the second target metadata as metadata to be verified.

[0216] In one embodiment, the first determining unit specifically includes:

[0217] The first determining subunit is configured to determine, based on the anomaly message in the log data, a first indication metadata and a first associated metadata stored in the metadata to be inspected that is associated with the first indication metadata; wherein, the first indication metadata is the metadata indicated by the anomaly message in the metadata to be inspected;

[0218] The second determining subunit is used to determine, based on the reference operation quantity and the log quantity information in the log data, the second indication metadata and the second associated metadata stored in the metadata to be checked that is associated with the second indication metadata; wherein, the second indication metadata is the metadata corresponding to the abnormal log quantity information in the metadata to be checked;

[0219] The third determining subunit is used to determine the first target metadata based on the first indication metadata, the second indication metadata, the first associated metadata, and the second associated metadata.

[0220] In one embodiment, the second determining subunit is specifically used for:

[0221] Based on the reference operation quantity and the log quantity information in the log data, determine the physical storage unit corresponding to the second indication metadata; based on the metadata stored in the physical storage unit that matches the attribute information of the second indication metadata, determine the second associated metadata stored in the metadata to be checked that is associated with the second indication metadata.

[0222] In one embodiment, the second determining unit is specifically used for:

[0223] Based on the operational data, an abnormal device is identified in the hardware device storing the metadata to be inspected; based on the metadata stored in the abnormal device, a second target metadata in the metadata to be inspected is identified.

[0224] In one embodiment, the verification module 30 is specifically used for:

[0225] Based on the metadata association relationship, a third associated metadata corresponding to the metadata to be verified is determined; the third associated metadata and the metadata to be verified are matched to obtain a matching result; if the matching result is that the third associated metadata and the metadata to be verified match, the verification result is determined to be normal; if the matching result is that the third associated metadata and the metadata to be verified do not match, the verification result is determined to be abnormal.

[0226] In one embodiment, the metadata to be checked is linearly continuous metadata. In the case of read / write operations, the repair module 40 is further configured to:

[0227] If abnormal metadata is detected, the abnormal metadata is investigated based on at least one data identifier, and the investigated abnormal metadata is repaired; wherein, the data identifier is generated during the periodic verification of the metadata to be checked and is used to identify the data range of normal metadata.

[0228] In one embodiment, the device further includes a generation module for:

[0229] The metadata to be checked is periodically verified. During each verification process, if there is no abnormal metadata in the metadata to be checked, a new data identifier is generated and the data identifiers generated in the previous verification process are retained. If there is abnormal metadata in the metadata to be checked, the abnormal metadata is repaired and a new data identifier is generated, and the data identifiers generated in the previous verification process are discarded.

[0230] In one embodiment, the repair module 40 is further configured to:

[0231] The data identifiers are sorted in ascending order of their generation time. The data identifier corresponding to the most recently stored metadata is designated as the first data identifier, and the first data identifier in the sorted order is designated as the second data identifier. The data investigation scope is determined based on the first and second data identifiers. Abnormal metadata is investigated within the data investigation scope. If no abnormal metadata is found, the second data identifier is designated as the new first data identifier, and the next data identifier of the second data identifier is designated as the new second data identifier. The process then returns to the previous step, resuming the operation of determining the data investigation scope based on the first and second data identifiers, until abnormal metadata is found.

[0232] Each module in the aforementioned metadata repair device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0233] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores metadata. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a metadata repair method.

[0234] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0235] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the metadata repair method described in any of the above embodiments.

[0236] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the metadata repair method described in any of the above embodiments.

[0237] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the metadata repair method described in any of the above embodiments.

[0238] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0239] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0240] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A metadata repair method, characterized in that, The method includes: Without performing read / write operations, obtain the log data of the metadata to be inspected, as well as the operating data of the hardware device storing the metadata to be inspected; Based on the log data and the runtime data, determine the metadata to be verified in the metadata to be checked; The metadata to be verified is verified to obtain the verification result; If the verification result is abnormal, the abnormal metadata in the metadata to be verified shall be repaired.

2. The method according to claim 1, characterized in that, The step of determining the metadata to be verified in the metadata to be checked based on the log data and the runtime data includes: Based on the anomaly alerts and log count information in the log data, determine the first target metadata in the metadata to be inspected; Based on the operational data, determine the second target metadata in the metadata to be inspected; The first target metadata and the second target metadata are used as the metadata to be verified.

3. The method according to claim 2, characterized in that, The step of determining the first target metadata in the metadata to be inspected based on the anomaly message and log quantity information in the log data includes: Based on the anomaly message in the log data, determine the first indication metadata and the first associated metadata stored in the metadata to be inspected that is associated with the first indication metadata; wherein, the first indication metadata is the metadata indicated by the anomaly message in the metadata to be inspected; Based on the reference operation quantity and the log quantity information in the log data, determine the second indication metadata and the second associated metadata stored in the metadata to be checked that is associated with the second indication metadata; wherein, the second indication metadata is the metadata corresponding to the abnormal log quantity information in the metadata to be checked; The first target metadata is determined based on the first indication metadata, the second indication metadata, the first associated metadata, and the second associated metadata.

4. The method according to claim 3, characterized in that, Based on the reference operation quantity and the log quantity information in the log data, determine the second associated metadata stored in the metadata to be inspected that is associated with the second indication metadata, including: Based on the reference operation quantity and the log quantity information in the log data, determine the physical storage unit corresponding to the second indication metadata; Based on the metadata stored in the physical storage unit that matches the attribute information of the second indication metadata, determine the second associated metadata stored in the metadata to be inspected that is associated with the second indication metadata.

5. The method according to claim 2, characterized in that, The step of determining the second target metadata in the metadata to be inspected based on the operational data includes: Based on the operational data, identify the abnormal device among the hardware devices storing the metadata to be inspected; Based on the metadata stored in the abnormal device, determine the second target metadata in the metadata to be inspected.

6. The method according to any one of claims 1 to 5, characterized in that, The step of verifying the metadata to be verified and obtaining the verification result includes: Based on the metadata association relationship, determine the third associated metadata corresponding to the metadata to be verified; The third associated metadata and the metadata to be verified are matched to obtain the matching result; If the matching result shows that the third associated metadata matches the metadata to be verified, then the verification result is determined to be normal. If the matching result indicates that the third associated metadata and the metadata to be verified do not match, then the verification result is determined to be abnormal.

7. The method according to any one of claims 1 to 5, characterized in that, The metadata to be inspected is linearly continuous metadata. When performing read / write operations, the method further includes: If abnormal metadata is detected, the abnormal metadata is investigated based on at least one data identifier, and the investigated abnormal metadata is repaired; wherein, the data identifier is generated during the periodic verification of the metadata to be checked and is used to identify the data range of normal metadata.

8. The method according to claim 7, characterized in that, The method further includes: The metadata to be checked is periodically verified, and if no abnormal metadata is found in the metadata to be checked during each verification process, a new data identifier is generated and the data identifiers generated in the previous verification process are retained. If abnormal metadata exists in the metadata to be checked, the abnormal metadata will be repaired, a new data identifier will be generated, and the data identifiers generated in the historical verification process will be discarded.

9. The method according to claim 8, characterized in that, The step of checking abnormal metadata based on at least one data identifier includes: Sort the data identifiers according to their generation time from most recent to oldest. The data identifier corresponding to the latest stored metadata is used as the first data identifier, and the first data identifier in the sorting order is used as the second data identifier; The scope of data screening is determined based on the first data identifier and the second data identifier; Investigate abnormal metadata within the scope of the data investigation; If no abnormal metadata is found, the second data identifier is used as the new first data identifier, and the next data identifier of the second data identifier is used as the new second data identifier. Then, the operation of determining the data investigation scope based on the first data identifier and the second data identifier is returned until the abnormal metadata is found.

10. A metadata repair device, characterized in that, The device includes: The acquisition module is used to acquire log data of the metadata to be inspected and the operating data of the hardware device storing the metadata to be inspected without performing read or write operations. The determination module is used to determine the metadata to be verified in the metadata to be checked based on the log data and the running data. The verification module is used to verify the metadata to be verified and obtain the verification result; The repair module is used to repair the abnormal metadata in the metadata to be verified when the verification result is abnormal.

11. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

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

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images