Metadata fault-tolerant storage method of eCryptfs file system and related device

Abstract

The embodiment of the invention relates to the field of data processing, and provides a metadata fault-tolerant storage method of an eCryptfs file system and a related device, and the method comprises the following steps: obtaining a first shadow storage area; distributing the first shadow storage area in a metadata storage area of an eCryptfs file system to obtain a first metadata storage area; when a metadata updating instruction sent by the eCryptfs file system is received, obtaining real-time metadata; performing copy-on-write strategy operation on the real-time metadata in the first metadata storage area to obtain a real-time metadata backup; performing damage detection on the real-time metadata to obtain a damage detection result; if the damage detection result is that the real-time metadata is damaged, the real-time metadata backup is adopted for carrying out recovery mechanism processing operation, and the real-time metadata in the main storage area is recovered, so that the problem that metadata block-level damage occurs in an eCryptfs file system can be solved, effective metadata can be prevented from being lost, and the error-tolerant rate of the metadata is increased.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, in particular to a metadata fault-tolerant storage method of eCryptfs file system and related device. BACKGROUND

[0002] Currently, the file system encryption method based on eCryptfs realizes data security storage through hierarchical key management and file-level encryption mechanism. In specific implementation, eCryptfs embeds encrypted metadata (such as encryption key, file attribute, access control information, etc.) in the file header or stores it independently in the extended attribute of the target file, and relies on the metadata management mechanism of the underlying file system (such as Ext4) for persistent storage. This scheme ensures the confidentiality of file content and metadata through encryption key derivation, metadata and ciphertext data separation storage, and provides basic data consistency protection with the help of the file system's own log mechanism.

[0003] However, when the metadata storage area is damaged due to hardware failure, abnormal power failure or software error, the existing traditional log mechanism can guarantee the operation sequence consistency, but cannot solve the metadata block level damage problem, and the overwrite writing strategy may directly cause the loss of valid metadata, and the metadata fault tolerance is low. SUMMARY

[0004] The embodiments of the present application provide a metadata fault-tolerant storage method of eCryptfs file system and related device, which can allocate a shadow storage area in the metadata storage area of eCryptfs file system, and automatically use the real-time metadata of the shadow storage area to recover the real-time metadata of the main storage area in combination with the real-time metadata damage detection mode, thereby improving the metadata fault tolerance.

[0005] The first aspect of the embodiments of the present application provides a metadata fault-tolerant storage method of eCryptfs file system, which comprises: obtaining a first shadow storage area; allocating the first shadow storage area in the metadata storage area of eCryptfs file system to obtain a first metadata storage area; when receiving a metadata update instruction issued by the eCryptfs file system, obtaining real-time metadata; performing a write-once copy strategy operation on the real-time metadata in the first metadata storage area to obtain a real-time metadata backup; detecting damage of the real-time metadata to obtain a damage detection result; if the damage detection result is real-time metadata damage, performing a recovery mechanism processing operation using the real-time metadata backup to recover the real-time metadata of the main storage area.

[0006] In one possible implementation, allocating the first shadow storage area within the metadata storage area of ​​the eCryptfs file system to obtain the first metadata storage area includes: The shadow storage area of ​​the eCryptfs file system is initialized to obtain the first shadow storage area after initialization. In the metadata storage area of ​​the eCryptfs file system, key metadata is obtained, including inode, key index, and access permissions; Based on the key metadata, the first shadow storage area after initialization is allocated in the metadata storage area of ​​the eCryptfs file system using incremental storage mode to obtain the second shadow storage area, wherein the second shadow storage area is a sub-shadow storage area allocated in the metadata storage area of ​​the eCryptfs file system. The initial hash value is calculated for each metadata block in the second shadow storage area to obtain the hash value calculation result of the shadow storage area. The hash value calculation result of the shadow storage area is stored in the corresponding second shadow storage area to obtain the first metadata storage area.

[0007] In one possible implementation, the step of performing a copy-on-write strategy operation on the real-time metadata in the first metadata storage area to obtain a real-time metadata backup includes: Copy-on-write is performed on the real-time metadata to obtain copied real-time metadata; The copied real-time metadata is written to the shadow storage area in the first metadata storage area to obtain a real-time metadata backup.

[0008] In one possible implementation, the replicated real-time metadata includes incremental information about the real-time metadata.

[0009] In one possible implementation, the step of performing corruption detection on the real-time metadata to obtain a corruption detection result includes: Obtain real-time metadata from the primary storage area; The hash value of the real-time metadata of the main storage area is calculated to obtain the hash value calculation result of the main storage area. Based on the hash value calculation results of the main storage area and the shadow storage area, the corruption detection result of the real-time metadata is determined.

[0010] In one possible implementation, the recovery mechanism operation using the real-time metadata backup to recover the real-time metadata of the main storage area includes: The real-time metadata backup is subjected to corruption detection to obtain the real-time metadata backup corruption detection result; If the real-time metadata backup corruption detection result is that the data is complete and undamaged; The real-time metadata in the main storage area is directly replaced by the real-time metadata backup. If the real-time metadata backup corruption detection result indicates that the data may be corrupted, XOR redundancy recovery is performed on the real-time metadata backup to obtain the recovered real-time metadata backup. The real-time metadata in the main storage area is replaced with the restored real-time metadata backup.

[0011] In this example, by acquiring the first shadow storage area, allocating the first shadow storage area in the metadata storage area of ​​the eCryptfs file system, and then upon receiving a metadata update instruction, performing write-on-write copy on the real-time metadata in the first metadata storage area to obtain a real-time metadata backup, and then performing corruption detection on the real-time metadata, based on the corruption detection results, automatically restoring the real-time metadata in the main storage area using the real-time metadata backup, thereby solving the problem of metadata block-level corruption in the eCryptfs file system, avoiding the loss of valid metadata, and improving the metadata fault tolerance rate.

[0012] A second aspect of this application provides a metadata fault-tolerant storage device for an eCryptfs file system, the device comprising: The first acquisition unit is used to acquire the first shadow storage area; The first processing unit is used to allocate the first shadow storage area in the metadata storage area of ​​the eCryptfs file system to obtain the first metadata storage area. The second acquisition unit is used to acquire real-time metadata when it receives a metadata update instruction issued by the eCryptfs file system; The second processing unit is used to perform a copy-on-write strategy operation on the real-time metadata in the first metadata storage area to obtain a real-time metadata backup. The third processing unit is used to perform damage detection on the real-time metadata and obtain the damage detection result. The recovery unit is used to perform a recovery mechanism operation using the real-time metadata backup if the damage detection result indicates that the real-time metadata is corrupted, thereby restoring the real-time metadata of the main storage area.

[0013] In one possible implementation, regarding the allocation of the first shadow storage area in the metadata storage area of ​​the eCryptfs file system to obtain the first metadata storage area, the first processing unit is configured to: The shadow storage area of ​​the eCryptfs file system is initialized to obtain the first shadow storage area after initialization. In the metadata storage area of ​​the eCryptfs file system, key metadata is obtained, including inode, key index, and access permissions; Based on the key metadata, the first shadow storage area after initialization is allocated in the metadata storage area of ​​the eCryptfs file system using incremental storage mode to obtain the second shadow storage area, wherein the second shadow storage area is a sub-shadow storage area allocated in the metadata storage area of ​​the eCryptfs file system. The initial hash value is calculated for each metadata block in the second shadow storage area to obtain the hash value calculation result of the shadow storage area. The hash value calculation result of the shadow storage area is stored in the corresponding second shadow storage area to obtain the first metadata storage area.

[0014] In one possible implementation, in the aspect of performing a copy-on-write strategy operation on the real-time metadata in the first metadata storage area to obtain a real-time metadata backup, the second processing unit is configured to: Copy-on-write is performed on the real-time metadata to obtain copied real-time metadata; The copied real-time metadata is written to the shadow storage area in the first metadata storage area to obtain a real-time metadata backup.

[0015] In one possible implementation, in the aspect of copy-on-write of the real-time metadata to obtain copied real-time metadata, the second processing unit is configured to: The replicated real-time metadata includes incremental information about the real-time metadata.

[0016] In one possible implementation, in the aspect of performing corruption detection on the real-time metadata to obtain corruption detection results, the third processing unit is configured to: Obtain real-time metadata from the primary storage area; The hash value of the real-time metadata of the main storage area is calculated to obtain the hash value calculation result of the main storage area. Based on the hash value calculation results of the main storage area and the shadow storage area, the corruption detection result of the real-time metadata is determined.

[0017] In one possible implementation, regarding the aspect of restoring the real-time metadata of the main storage area using the real-time metadata backup recovery mechanism, the recovery unit is configured to: The real-time metadata backup is subjected to corruption detection to obtain the real-time metadata backup corruption detection result; If the real-time metadata backup corruption detection result is that the data is complete and undamaged; The real-time metadata in the main storage area is directly replaced by the real-time metadata backup. If the real-time metadata backup corruption detection result indicates that the data may be corrupted, XOR redundancy recovery is performed on the real-time metadata backup to obtain the recovered real-time metadata backup. The real-time metadata in the main storage area is replaced with the restored real-time metadata backup.

[0018] A third aspect of this application provides a terminal including a processor, an input device, an output device, and a memory, wherein the processor, input device, output device, and memory are interconnected, and the memory is used to store a computer program, the computer program including program instructions, and the processor is configured to invoke the program instructions to execute the steps of the metadata fault-tolerant storage method of the eCryptfs file system as described in the first aspect of this application.

[0019] A fourth aspect of this application provides a computer-readable storage medium storing a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the steps described in the metadata fault-tolerant storage method of the eCryptfs file system in the first aspect of this application.

[0020] A fifth aspect of this application provides a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps described in the metadata fault-tolerant storage method for the eCryptfs file system in the first aspect of this application. The computer program product may be a software installation package. Attached Figure Description

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

[0022] Figure 1 This application provides a schematic diagram of the overall process for a metadata fault-tolerant storage method for the eCryptfs file system. Figure 2This application provides a schematic diagram of metadata corruption detection in a metadata fault-tolerant storage method for an eCryptfs file system, as illustrated in this embodiment. Figure 3 This application provides a schematic diagram of real-time metadata backup corruption detection in the shadow storage area of ​​a metadata fault-tolerant storage method for an eCryptfs file system, as illustrated in this embodiment. Figure 4 This application provides a schematic diagram illustrating the repair of corrupted metadata backup in the shadow storage area using a method for fault-tolerant storage of eCryptfs file system metadata. Figure 5 This application provides a schematic diagram of the structure of a metadata fault-tolerant storage device for the eCryptfs file system. Figure 6 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application; Figure label: 100 - First acquisition unit, 200 - First processing unit, 300 - Second acquisition unit, 400 - Second processing unit, 500 - Third processing unit, 600 - Recovery unit. Detailed Implementation

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

[0024] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0025] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application can be combined with other embodiments.

[0026] To better understand the business product determination method provided in this application embodiment, the following is a brief introduction to the scenario of applying the eCryptfs file system metadata fault-tolerant storage method. In a cloud-based collaborative document editing platform using eCryptfs encryption, real-time modifications to encrypted files by users trigger high-frequency metadata updates. Traditional mechanisms rely on the underlying file system's log function to record the metadata operation sequence and directly update the latest metadata to the storage block through an overwrite strategy. Specifically, for example, when multiple users concurrently modify the same encrypted document, the system generates log entries according to the operation order and ultimately overwrites the metadata to the target storage area. However, if a metadata block is partially corrupted due to a partial failure of the storage medium or a network transmission interruption, traditional logs can only roll back the operation process but cannot repair the corrupted metadata block itself. At the same time, overwrite permanently erases the old version of metadata. Once newly written data becomes invalid due to block-level corruption, the system cannot obtain a complete data copy from the log, nor can it recover the original metadata through redundancy mechanisms. Ultimately, this results in encrypted files being unable to be decrypted or permission information being disordered, severely affecting the continuity of collaborative business and resulting in low metadata fault tolerance.

[0027] The metadata fault-tolerant storage method of the eCryptfs file system is applied to the metadata fault-tolerant storage device of the eCryptfs file system. Figure 1 A schematic diagram illustrating the overall process of a metadata fault-tolerant storage method for the eCryptfs file system is shown. Figure 1 As shown, it includes: S1. Obtain the first shadow storage area.

[0028] The first shadow storage area can be a dedicated redundant storage area embedded within the eCryptfs metadata storage area, used to provide real-time backup and fault tolerance capabilities for the metadata of the main storage area.

[0029] S2. Allocate the first shadow storage area in the metadata storage area of ​​the eCryptfs file system to obtain the first metadata storage area.

[0030] Specifically, the first shadow storage area can be allocated based on the key metadata in the metadata storage area of ​​the eCryptfs file system, thereby obtaining the second shadow storage area. Then, the initial hash value of the second shadow storage area can be calculated to obtain the hash value calculation result of the shadow storage area, which is used for subsequent program processing and comparison.

[0031] S3. When a metadata update instruction is received from the eCryptfs file system, real-time metadata is obtained.

[0032] Specifically, when a metadata update instruction is received from the eCryptfs file system, it can be understood that when there is a metadata update (such as file creation, deletion, modification of file permissions, or inode update) in the eCryptfs file system, the eCryptfs file system can issue a metadata update instruction to obtain real-time metadata.

[0033] S4. Perform a copy-on-write strategy operation on the real-time metadata in the first metadata storage area to obtain a real-time metadata backup.

[0034] Specifically, when performing write-on-write copy operations on real-time metadata, a write-on-write method can be used to obtain copied real-time metadata. Then, the copied real-time metadata can be written to the shadow storage area in the first metadata storage area to obtain a real-time metadata backup. It should be noted that copying real-time metadata only includes incremental information of real-time metadata.

[0035] S5. Perform damage detection on the real-time metadata to obtain the damage detection results.

[0036] The process involves first obtaining the real-time metadata of the main storage area, then using a hash value calculation method to obtain the hash value of the main storage area, and further determining the damage detection result of the real-time metadata of the main storage area based on the hash value calculation result of the main storage area and the hash value calculation result of the shadow storage area. The damage detection result can be confirmed by comparing whether the hash values ​​match.

[0037] S6. If the damage detection result indicates that the real-time metadata is corrupted, the real-time metadata backup is used to perform a recovery mechanism to restore the real-time metadata in the main storage area.

[0038] Before restoring the real-time metadata of the main storage area using real-time metadata backup, a corruption detection of the real-time metadata backup can be performed first. The method is similar to that in step S5, which can be done by comparing hash values ​​to confirm the corruption detection result of the real-time metadata backup. If the real-time metadata backup is corrupted, the XOR redundancy recovery method can be used to repair the real-time metadata backup. After repair, the repaired real-time metadata backup can be used to restore the real-time metadata of the main storage area. If the real-time metadata backup is intact, the real-time metadata of the main storage area can be directly replaced by the real-time metadata backup, thereby realizing the recovery of the real-time metadata.

[0039] In one possible implementation, the metadata of the main storage area can be synchronized with the shadow storage area periodically. An LRU caching strategy is used to prioritize caching recently accessed metadata in memory, so as to facilitate the recovery of all recently accessed metadata.

[0040] To ensure data consistency, this example periodically synchronizes metadata between the primary storage and shadow storage. When reading metadata, if a hash mismatch is detected, data is immediately recovered from shadow storage to avoid excessive synchronization. Data recovery from shadow storage is only triggered in the event of a failure or hash inconsistency, reducing unnecessary I / O operations. Frequently accessed metadata caching is optimized by loading critical data from shadow storage into memory. An LRU caching strategy is used to prioritize caching recently accessed metadata in memory, further improving performance.

[0041] In this example, by acquiring the first shadow storage area, allocating the first shadow storage area in the metadata storage area of ​​the eCryptfs file system, and then upon receiving a metadata update instruction, performing write-on-write copy on the real-time metadata in the first metadata storage area to obtain a real-time metadata backup, and then performing corruption detection on the real-time metadata, based on the corruption detection results, automatically restoring the real-time metadata in the main storage area using the real-time metadata backup, thereby solving the problem of metadata block-level corruption in the eCryptfs file system, avoiding the loss of valid metadata, and improving the metadata fault tolerance rate.

[0042] In one possible implementation, the method of allocating the first shadow storage area in the metadata storage area of ​​the eCryptfs file system to obtain the first metadata storage area includes: S201. Perform initialization operations on the shadow storage area of ​​the eCryptfs file system to obtain the first shadow storage area after initialization.

[0043] S202. Obtain key metadata from the metadata storage area of ​​the eCryptfs file system. The key metadata includes inode, key index, and access permissions.

[0044] S203. Based on the key metadata, the first shadow storage area after initialization is allocated in the metadata storage area of ​​the eCryptfs file system using incremental storage mode to obtain the second shadow storage area, wherein the second shadow storage area is a sub-shadow storage area allocated in the metadata storage area of ​​the eCryptfs file system.

[0045] S204. Perform initial hash value calculation on each metadata block of the second shadow storage area to obtain the hash value calculation result of the shadow storage area.

[0046] The initial hash verification can calculate the initial hash value for each metadata block in the shadow storage area using the XXH64 hash algorithm.

[0047] S205. The hash value calculation result of the shadow storage area is stored in the corresponding second shadow storage area to obtain the first metadata storage area.

[0048] In this example, the shadow storage area is first initialized to ensure the structural stability of redundant storage space and avoid backup anomalies caused by unformatted or residual data. Then, key metadata (such as inodes and key indexes) is filtered to focus on the core vulnerabilities of the encrypted file system, avoiding storage redundancy caused by full backups. Subsequently, the shadow storage area is allocated in incremental storage mode to dynamically match the metadata update frequency, minimizing storage overhead while ensuring backup timeliness. A hash value is calculated and stored for each metadata block to build a block-level data integrity verification benchmark, enabling subsequent damage detection to accurately locate specific damaged blocks, rather than relying on fuzzy judgments from overall verification. Finally, the hash value is embedded in the shadow storage area to form a self-verifying data structure, ensuring that backup data and verification information are stored synchronously, avoiding additional retrieval overhead caused by the separation of hash value storage.

[0049] In one possible implementation, a method for performing a copy-on-write strategy on the real-time metadata in the first metadata storage area to obtain a real-time metadata backup includes: S401. Perform write-time copy on the real-time metadata to obtain copied real-time metadata, wherein the copied real-time metadata includes incremental information of the real-time metadata.

[0050] S402. Write the copied real-time metadata into the shadow storage area in the first metadata storage area to obtain a real-time metadata backup.

[0051] In this example, copy-on-write of real-time metadata ensures that the current version is fully copied to the shadow storage area before metadata updates, preventing the loss of historical valid data in the main storage area due to direct overwrite and providing an immediately usable backup copy for the recovery mechanism. The subsequent writing of the copied data to the shadow storage area, combined with the hash verification structure initialized in step S2, ensures that the backup data is verifiable at storage time, laying the foundation for subsequent corruption detection. Furthermore, in this example, copying real-time metadata only includes incremental information, ensuring that the backup process only transmits and stores changed metadata fragments (such as key version updates, access permission adjustments, etc.), rather than a full copy. This not only reduces redundant data and space usage in the shadow storage area but also significantly shortens the backup operation time window. Especially in high-concurrency metadata update scenarios, it avoids I / O bottlenecks caused by full copying, ensuring a balance between backup timeliness and system performance.

[0052] Figure 2 A schematic diagram illustrating metadata corruption detection in a metadata fault-tolerant storage method for the eCryptfs file system is shown, as follows: Figure 2As shown, in one possible implementation, a method for performing corruption detection on the real-time metadata and obtaining corruption detection results includes: S501, Obtain real-time metadata of the main storage area.

[0053] S502. Calculate the hash value of the real-time metadata of the main storage area to obtain the hash value calculation result of the main storage area.

[0054] S503. Based on the hash value calculation result of the main storage area, determine the corruption detection result of the real-time metadata.

[0055] When the system needs to access a file's metadata, it first reads the metadata from the main storage area, calculates the hash value of that metadata block, and then compares the hash value from the shadow storage area with the hash value from the main storage area. If the hash values ​​do not match, it indicates that the metadata is corrupted, triggering an error detection mechanism. If the hash values ​​match, the metadata is returned normally.

[0056] In this example, obtaining real-time metadata from the primary storage area ensures that the detected object is the currently used metadata version, avoiding misjudgments or missed detections due to detection lag. The hash value of the primary storage area is calculated and compared with the hash value pre-stored in the shadow storage area in step S2 (i.e., the shadow storage area hash value calculated during initialization). Through the collision-resistant characteristics of the hash algorithm, subtle damage at the metadata block level (such as single-bit flips or partial byte loss) can be accurately identified. Traditional log mechanisms can only detect abnormal operation sequences and cannot locate data corruption at the physical storage level. The primary / shadow hash value comparison determines the corruption result, which is directly linked to the write-on-write backup mechanism in step S4—because the backup data in the shadow storage area is strongly bound to the data in the primary storage area through hashing, differences in the comparison can immediately trigger the recovery process in the next step, forming a "detection-recovery" closed loop. Compared to the post-event full-disk scan of traditional file system inspection tools (such as fsck), this step achieves real-time, dynamic damage detection with extremely low computational overhead, especially suitable for high-frequency metadata update scenarios, ensuring detection accuracy while avoiding system performance degradation.

[0057] Figure 3 This diagram illustrates real-time metadata backup corruption detection in the shadow storage area of ​​a metadata fault-tolerant storage method for the eCryptfs file system, as shown below. Figure 3 As shown, in one possible implementation, the method for restoring the real-time metadata of the main storage area using the real-time metadata backup recovery mechanism includes: S601. Perform damage detection on the real-time metadata backup to obtain the real-time metadata backup damage detection result.

[0058] S602. If the real-time metadata backup corruption detection result is that the data is complete and undamaged.

[0059] S603. Directly replace the real-time metadata in the main storage area with the real-time metadata backup.

[0060] S604. If the real-time metadata backup corruption detection result indicates that the data may be corrupted, perform XOR redundancy recovery on the real-time metadata backup to obtain the recovered real-time metadata backup.

[0061] S605. Replace the real-time metadata in the main storage area with the restored real-time metadata backup.

[0062] In this example, upon detecting corrupted metadata in the primary storage area, the first step is to check for the corrupted metadata using a hash check. If the hash value does not match, the primary storage area's metadata is confirmed to be corrupted. If the data in the shadow storage area is intact and undamaged, the metadata in the shadow storage area can be directly used to overwrite the corrupted data in the primary storage area, thus achieving data recovery.

[0063] Figure 4 This diagram illustrates the repair of corrupted metadata backups in a shadow storage area, representing a fault-tolerant metadata storage method for the eCryptfs file system. Figure 4 As shown, during the recovery process, it is necessary to ensure that the data in the shadow storage is consistent with the data in the primary storage. The current hash value of the metadata in the shadow storage area is calculated and compared with the initial hash value of the storage. If the two do not match, it indicates that the data in the shadow storage may be corrupted. In this case, the XOR redundancy recovery mechanism is used for repair. In this example, the formula for recovery using XOR is expressed as follows: P=𝐵 -1 .⊕,𝐵 -2 .⊕,𝐵 -3 .⊕…⊕,𝐵 -𝑁 .; 𝐵 -𝑘 .=𝑃⊕,𝐵 -1 .⊕,𝐵-2.⊕…⊕,𝐵 -𝑘−1. ⊕,𝐵 -𝑘+1 .⊕…⊕,𝐵 -𝑁 .; Among them, 𝐵- 1. ,,𝐵- 2. , ..., 𝐵 -𝑁. There are N metadata blocks, where P is a redundancy check block used for data recovery. -𝑘. It is a corrupted metadata block in the shadow storage area.

[0064] In this example, a secondary corruption detection is first performed on the backup data to verify the integrity of the shadow storage backup, avoiding "dirty data overwriting" caused by potential errors during backup synchronization and ensuring the reliability of the recovery source. Then, if the backup data is not corrupted, the primary data is directly replaced. Relying on the write-time copy strategy in step 3, the logical isolation between the shadow storage and the primary storage is utilized to achieve atomic replacement operations, minimizing recovery latency. If the backup may be corrupted, XOR redundancy recovery is enabled, and complete metadata is derived from the redundant data blocks. Even if some backup blocks are corrupted, the original data can still be recovered through mathematical redundancy, overcoming the limitations of single backup dependency, thereby enhancing the fault tolerance of metadata and improving system reliability.

[0065] In summary, this example provides a fault-tolerant metadata storage method for the eCryptfs file system. This example can quickly recover metadata and improve data reliability when silent data corruption (SDC) occurs in the file system. By employing hash checksum, XOR redundancy recovery, and LRU caching mechanisms, data integrity is guaranteed while minimizing performance loss, resulting in high metadata fault tolerance and strong system reliability.

[0066] For those consistent with the above, please refer to Figure 5 , Figure 5 This application provides a schematic diagram of the structure of a metadata fault-tolerant storage device for the eCryptfs file system, as shown in the embodiments of this application. Figure 5 As shown, the device includes: The first acquisition unit 100 is used to acquire the first shadow storage area; The first processing unit 200 is used to allocate the first shadow storage area in the metadata storage area of ​​the eCryptfs file system to obtain the first metadata storage area. The second acquisition unit 300 is used to acquire real-time metadata when it receives a metadata update instruction issued by the eCryptfs file system. The second processing unit 400 is used to perform a copy-on-write strategy operation on the real-time metadata in the first metadata storage area to obtain a real-time metadata backup. The third processing unit 500 is used to perform damage detection on the real-time metadata and obtain damage detection results. The recovery unit 600 is used to perform a recovery mechanism operation using the real-time metadata backup if the damage detection result indicates that the real-time metadata is corrupted, thereby restoring the real-time metadata of the main storage area.

[0067] In one possible implementation, regarding the allocation of the first shadow storage area in the metadata storage area of ​​the eCryptfs file system to obtain the first metadata storage area, the first processing unit 200 is configured to: The shadow storage area of ​​the eCryptfs file system is initialized to obtain the first shadow storage area after initialization. In the metadata storage area of ​​the eCryptfs file system, key metadata is obtained, including inode, key index, and access permissions; Based on the key metadata, the first shadow storage area after initialization is allocated in the metadata storage area of ​​the eCryptfs file system using incremental storage mode to obtain the second shadow storage area, wherein the second shadow storage area is a sub-shadow storage area allocated in the metadata storage area of ​​the eCryptfs file system. The initial hash value is calculated for each metadata block in the second shadow storage area to obtain the hash value calculation result of the shadow storage area. The hash value calculation result of the shadow storage area is stored in the corresponding second shadow storage area to obtain the first metadata storage area.

[0068] In one possible implementation, regarding the aspect of performing a copy-on-write strategy operation on the real-time metadata in the first metadata storage area to obtain a real-time metadata backup, the second processing unit 400 is configured to: Copy-on-write is performed on the real-time metadata to obtain copied real-time metadata; The copied real-time metadata is written to the shadow storage area in the first metadata storage area to obtain a real-time metadata backup.

[0069] In one possible implementation, in the aspect of copy-on-write of the real-time metadata to obtain copied real-time metadata, the second processing unit 400 is configured to: The replicated real-time metadata includes incremental information about the real-time metadata.

[0070] In one possible implementation, in the aspect of performing corruption detection on the real-time metadata to obtain a corruption detection result, the third processing unit 500 is configured to: Obtain real-time metadata from the primary storage area; The hash value of the real-time metadata of the main storage area is calculated to obtain the hash value calculation result of the main storage area. Based on the hash value calculation results of the main storage area and the shadow storage area, the corruption detection result of the real-time metadata is determined.

[0071] In one possible implementation, in the aspect of the recovery mechanism processing operation using the real-time metadata backup to recover the real-time metadata of the main storage area, the recovery unit 600 is configured to: The real-time metadata backup is subjected to corruption detection to obtain the real-time metadata backup corruption detection result; If the real-time metadata backup corruption detection result is that the data is complete and undamaged; The real-time metadata in the main storage area is directly replaced by the real-time metadata backup. If the real-time metadata backup corruption detection result indicates that the data may be corrupted, XOR redundancy recovery is performed on the real-time metadata backup to obtain the recovered real-time metadata backup. The real-time metadata in the main storage area is replaced with the restored real-time metadata backup.

[0072] For examples consistent with the above embodiments, please refer to... Figure 6 , Figure 6 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application, such as... Figure 6 As shown, it includes a processor, an input device, an output device, and a memory, which are interconnected. The memory is used to store a computer program, which includes program instructions. The processor is configured to call the program instructions. The program includes instructions for performing the following steps. Obtain the first shadow storage area; The first shadow storage area is allocated in the metadata storage area of ​​the eCryptfs file system to obtain the first metadata storage area; When a metadata update instruction is received from the eCryptfs file system, real-time metadata is obtained; In the first metadata storage area, a copy-on-write strategy is performed on the real-time metadata to obtain a real-time metadata backup. The real-time metadata is subjected to corruption detection to obtain corruption detection results; If the damage detection result indicates that the real-time metadata is corrupted, the real-time metadata backup is used for recovery processing to restore the real-time metadata in the main storage area.

[0073] In this example, by acquiring the first shadow storage area, allocating the first shadow storage area in the metadata storage area of ​​the eCryptfs file system, and then upon receiving a metadata update instruction, performing write-on-write copy on the real-time metadata in the first metadata storage area to obtain a real-time metadata backup, and then performing corruption detection on the real-time metadata, based on the corruption detection results, automatically restoring the real-time metadata in the main storage area using the real-time metadata backup, thereby solving the problem of metadata block-level corruption in the eCryptfs file system, avoiding the loss of valid metadata, and improving the metadata fault tolerance rate.

[0074] The above mainly describes the solutions of the embodiments of this application from the perspective of the method execution process. It is understood that, in order to achieve the above functions, the terminal includes the corresponding hardware structure and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments provided herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0075] This application embodiment can divide the terminal into functional units according to the above method example. For example, each function can be divided into a separate functional unit, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0076] This application also provides a computer storage medium that stores a computer program for electronic data interchange, which causes a computer to perform some or all of the steps of any of the metadata fault-tolerant storage methods for the eCryptfs file system described in the above method embodiments.

[0077] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program that causes a computer to perform some or all of the steps of any of the metadata fault-tolerant storage methods for the eCryptfs file system described in the above method embodiments.

[0078] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0079] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0080] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0081] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0082] Furthermore, the functional units in the various embodiments of the application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software program module.

[0083] If the integrated unit is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0084] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage device, which may include: a flash drive, a read-only memory, a random access memory, a magnetic disk, or an optical disk, etc.

[0085] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for fault-tolerant metadata storage in an eCryptfs file system, characterized in that, include: Obtain the first shadow storage area; The first shadow storage area is allocated in the metadata storage area of ​​the eCryptfs file system to obtain the first metadata storage area; When a metadata update instruction is received from the eCryptfs file system, real-time metadata is obtained; In the first metadata storage area, a copy-on-write strategy is performed on the real-time metadata to obtain a real-time metadata backup. The real-time metadata is subjected to corruption detection to obtain corruption detection results; If the damage detection result indicates that the real-time metadata is corrupted, the real-time metadata backup is used for recovery processing to restore the real-time metadata in the main storage area.

2. The metadata fault-tolerant storage method for the eCryptfs file system according to claim 1, characterized in that, The step of allocating the first shadow storage area in the metadata storage area of ​​the eCryptfs file system to obtain the first metadata storage area includes: The shadow storage area of ​​the eCryptfs file system is initialized to obtain the first shadow storage area after initialization. In the metadata storage area of ​​the eCryptfs file system, key metadata is obtained, including inode, key index, and access permissions; Based on the key metadata, the first shadow storage area after initialization is allocated in the metadata storage area of ​​the eCryptfs file system using incremental storage mode to obtain the second shadow storage area, wherein the second shadow storage area is a sub-shadow storage area allocated in the metadata storage area of ​​the eCryptfs file system. The initial hash value is calculated for each metadata block in the second shadow storage area to obtain the hash value calculation result of the shadow storage area. The hash value calculation result of the shadow storage area is stored in the corresponding second shadow storage area to obtain the first metadata storage area.

3. The metadata fault-tolerant storage method for the eCryptfs file system according to claim 1, characterized in that, The step of performing a copy-on-write strategy operation on the real-time metadata in the first metadata storage area to obtain a real-time metadata backup includes: Copy-on-write is performed on the real-time metadata to obtain copied real-time metadata; The copied real-time metadata is written to the shadow storage area in the first metadata storage area to obtain a real-time metadata backup.

4. The metadata fault-tolerant storage method for the eCryptfs file system according to claim 3, characterized in that, The replicated real-time metadata includes incremental information about the real-time metadata.

5. The metadata fault-tolerant storage method for the eCryptfs file system according to claim 2, characterized in that, The step of performing corruption detection on the real-time metadata to obtain corruption detection results includes: Obtain real-time metadata from the primary storage area; The hash value of the real-time metadata of the main storage area is calculated to obtain the hash value calculation result of the main storage area. Based on the hash value calculation result of the main storage area, the corruption detection result of the real-time metadata is determined.

6. The metadata fault-tolerant storage method for the eCryptfs file system according to claim 1, characterized in that, The recovery mechanism operation using the real-time metadata backup to restore the real-time metadata of the main storage area includes: The real-time metadata backup is subjected to corruption detection to obtain the real-time metadata backup corruption detection result; If the real-time metadata backup corruption detection result is that the data is complete and undamaged; The real-time metadata in the main storage area is directly replaced by the real-time metadata backup. If the real-time metadata backup corruption detection result indicates that the data may be corrupted, XOR redundancy recovery is performed on the real-time metadata backup to obtain the recovered real-time metadata backup. The real-time metadata in the main storage area is replaced with the restored real-time metadata backup.

7. A metadata fault-tolerant storage device for an eCryptfs file system, characterized in that, include: The first acquisition unit is used to acquire the first shadow storage area; The first processing unit is used to allocate the first shadow storage area in the metadata storage area of ​​the eCryptfs file system to obtain the first metadata storage area. The second acquisition unit is used to acquire real-time metadata when it receives a metadata update instruction issued by the eCryptfs file system; The second processing unit is used to perform a copy-on-write strategy operation on the real-time metadata in the first metadata storage area to obtain a real-time metadata backup. The third processing unit is used to perform damage detection on the real-time metadata and obtain the damage detection result. The recovery unit is used to perform a recovery mechanism operation using the real-time metadata backup if the damage detection result indicates that the real-time metadata is corrupted, thereby restoring the real-time metadata of the main storage area.

8. The metadata fault-tolerant storage device for the eCryptfs file system according to claim 7, characterized in that, In the aspect of the recovery mechanism operation using the real-time metadata backup to recover the real-time metadata of the main storage area, the recovery unit is configured to: The real-time metadata backup is subjected to corruption detection to obtain the real-time metadata backup corruption detection result; If the real-time metadata backup corruption detection result is that the data is complete and undamaged; The real-time metadata in the main storage area is directly replaced by the real-time metadata backup. If the real-time metadata backup corruption detection result indicates that the data may be corrupted, XOR redundancy recovery is performed on the real-time metadata backup to obtain the recovered real-time metadata backup. The real-time metadata in the main storage area is replaced with the restored real-time metadata backup.

9. A terminal, characterized in that, The system includes a processor, an input device, an output device, and a memory, which are interconnected. The memory is used to store a computer program, which includes program instructions. The processor is configured to invoke the program instructions to execute the metadata fault-tolerant storage method of the eCryptfs file system as described in any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions, which, when executed by a processor, cause the processor to perform the metadata fault-tolerant storage method of the eCryptfs file system as described in any one of claims 1-6.

Images