Data repair method, device and medium of embedded storage system

Abstract

This invention relates to the field of data storage, and discloses a data repair method, device, and medium for an embedded storage system. In this invention, the storage space of the embedded storage system includes multiple logical blocks and reference check values ​​corresponding to the multiple logical blocks. The method includes: determining the target logical block to be checked, and calculating the current check value of the data within the target logical block; comparing the current check value with the reference check value corresponding to the target logical block; if the current check value and the reference check value do not match, obtaining the corresponding backup data segment according to the logical block index of the target logical block, and overwriting the backup data segment into the target logical block. This addresses the problems of low efficiency in locating data corruption and the need for manual intervention or system restart during the repair process, which affects the continuous availability of the device in related technologies.

Description

Technical Field

[0001] This invention relates to the field of data storage, and in particular to data repair methods, devices, and media for embedded storage systems. Background Technology

[0002] Embedded storage systems, as the core component for data persistence in embedded devices, are widely used in mobile terminals, smart vehicles, industrial control, and other fields. During device operation, embedded storage systems bear the responsibility of storing critical information such as system boot programs, application firmware, and user data. The integrity and reliability of this data directly affect the operational stability of the entire embedded device.

[0003] However, during the actual operation of embedded devices, data in embedded storage systems may be corrupted or abnormally altered due to factors such as frequent read / write operations, abnormal power outages, storage media aging, and external security threats. Currently, data verification and repair methods for embedded storage systems are still insufficient in terms of verification granularity and automation, resulting in low efficiency in locating data corruption. Furthermore, the repair process often requires manual intervention or system restart, affecting the continuous availability of embedded devices. Summary of the Invention

[0004] The purpose of this invention is to provide a data repair method, device, and medium for embedded storage systems, in order to solve the problems of low efficiency in locating data corruption and the need for manual intervention or system restart during the repair process, which affects the continuous availability of the device.

[0005] To address the aforementioned technical problems, this invention provides a data repair method for an embedded storage system. The embedded storage system's storage space includes multiple logical blocks and reference verification values ​​corresponding to the multiple logical blocks. The method includes: determining a target logical block to be verified and calculating the current verification value of the data within the target logical block; comparing the current verification value with the reference verification value corresponding to the target logical block; if the current verification value does not match the reference verification value, obtaining a corresponding backup data segment based on the logical block index of the target logical block and overwriting the backup data segment into the target logical block.

[0006] The present invention also provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory is an embedded storage system, and the storage space of the memory includes a plurality of logical blocks; the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the data repair method of the embedded storage system as described above.

[0007] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the data repair method of the embedded storage system as described above.

[0008] In this invention, the storage space is divided into multiple logical blocks, each with a corresponding reference check value. This means that when data in a logical block is corrupted, the system only needs to compare the current check value of that logical block with its reference check value to determine the location of the corruption, without needing to perform a full scan and comparison of the entire storage space. Simultaneously, when a mismatch is detected, the system directly retrieves the corresponding backup data segment based on the logical block index and overwrites it. The entire process, from detection to repair, is automatically completed within the same execution flow. The device does not need to be shut down and restarted, nor does it need to wait for remote intervention from maintenance personnel. For scenarios where service interruption is unacceptable, such as in-vehicle systems and industrial controllers, data recovery can be completed while the device is operating normally. Furthermore, the repair operation only performs an overwrite on the single logical block that failed the check, rather than erasing and rewriting the entire partition it belongs to. This directly reduces the number of erase and write operations on the embedded storage medium, helping to delay the wear and tear of the storage medium.

[0009] Furthermore, the step of obtaining the corresponding backup data segment based on the logical block index of the target logical block includes: if a backup data segment corresponding to the logical block index exists in the local backup area, then the backup data segment is read from the local backup area; if the backup data segment does not exist in the local backup area, then the backup data segment is requested from an external data source. Thus, when obtaining backup data, the system first searches the local backup area. Local reading is typically much faster than downloading from an external data source, thus enabling near-instantaneous repair responses in most cases. When the required backup data segment does not exist in the local backup area, the system automatically degrades to obtaining it from an external data source, ensuring that the repair process is not interrupted due to the lack of a local backup. This allows the system to achieve the fastest repair speed in common scenarios while maintaining the integrity of its repair capabilities in extreme scenarios.

[0010] Furthermore, the local backup area is a reserved storage partition in the embedded storage system, independent of the partition where the target logical block is located; the external data source includes at least one of a cloud server, or a storage medium connected to the embedded storage system. Thus, the local backup area and the target logical block reside in different physical storage partitions. When the partition where the target logical block is located suffers regional data corruption due to abnormal power outages, bad block propagation, or other reasons, the backup data located in another independent partition remains unaffected, avoiding the risk of simultaneous corruption of backup data and original data. Simultaneously, the external data source supports both cloud servers and external storage media. Devices with network connectivity can remotely obtain backup data via a cloud server, while devices deployed in environments without network access (such as industrial control equipment in mines or tunnels) can obtain data via a local external connection, ensuring that devices under different deployment conditions have complete repair capabilities.

[0011] Furthermore, after determining the overwrite result of the target logical block based on the comparison result of the verification value and the reference verification value, the method further includes: if the overwrite result is a failure, remapping the logical address of the target logical block to a reserved spare physical block; and writing the backup data fragment to the spare physical block. Thus, when the verification confirms the overwrite failure, the physical storage area corresponding to the target logical block has already suffered irreversible hardware damage. By remapping the logical address to the reserved spare physical block, the system bypasses the damaged physical area at the logical level, and all subsequent read and write operations on that logical address will be redirected to the healthy spare physical block, thereby restoring the normal read and write function of the logical block without replacing the hardware. This mechanism enables the system to have self-healing capabilities against permanent physical damage, avoiding the need for the entire device to be returned to the factory for repair or the storage chip to be replaced due to the appearance of a single bad physical block.

[0012] Furthermore, the number of target logical blocks is at least two. The step of requesting the backup data fragment from the external data source includes: the external data source sending an aggregation data request; receiving the merged data stream returned by the external data source corresponding to at least two target logical blocks, and segmenting it to obtain the backup data fragment corresponding to each target logical block. Therefore, when multiple logical blocks need to be repaired from an external data source simultaneously, if requests are sent one by one, each request requires a communication process. For N logical blocks, this would require N complete communication round trips. In scenarios with high latency, the communication overhead will increase linearly with the number of logical blocks. By aggregating the data requests of multiple logical blocks into a single request and returning it all at once as a merged data stream, N communication round trips are compressed into one. The receiving end then segments and restores the merged data stream according to the logical block index. In actual batch repair scenarios, network communication time can be reduced to a fraction of the original time, significantly shortening the overall completion time of batch repair. Attached Figure Description

[0013] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0014] Figure 1 This is a storage space structure diagram of an embedded storage system provided in this application; Figure 2 This is an example diagram of a data repair method for an embedded storage system provided in this application; Figure 3 This is an execution flowchart of a data repair method for an embedded storage system provided in this application; Figure 4 This is an example diagram of another data repair method for an embedded storage system, including a verification step, provided in this application; Figure 5 This is a structural diagram of an electronic device provided in this application. Detailed Implementation

[0015] As described in the background section, existing data verification and repair methods for embedded storage systems are insufficient in terms of verification granularity and automation, resulting in low efficiency in locating data corruption and requiring manual intervention or system restarts for repair. The applicant's research reveals that the root cause of these problems lies in the following: Firstly, traditional data integrity verification mechanisms often employ file-level or partition-level verification strategies, such as consistency checks based on file system logs or cyclic redundancy checks based on the entire partition image. File-level verification relies on the integrity of file system metadata, but the file system itself can be damaged due to abnormal power outages or bit flips in the storage medium, rendering file-level verification unreliable. While partition-level verification does not depend on the file system, its verification unit is the entire storage partition. Once data changes at any location within the partition, the verification result can only indicate an anomaly in that partition, but cannot further indicate the specific offset location of the anomaly. The system must perform a full scan or full rewrite of the entire partition to complete fault location and data recovery. On the other hand, existing repair processes are typically coupled with system upgrades or firmware flashing. This means that when data anomalies are detected, the system needs to enter a dedicated recovery mode or perform a full overwrite of the damaged partition via a system-wide OTA upgrade. This repair mode requires the device to interrupt its current operations and restart into the recovery environment. For embedded devices with extremely high service continuity requirements, such as in-vehicle infotainment systems and industrial field controllers, any unplanned downtime can lead to vehicle function degradation or production line shutdowns, resulting in unacceptable safety risks and economic losses. Furthermore, full overwrite repair does not distinguish between damaged and intact areas, generating numerous unnecessary write and erase operations on the embedded storage medium, accelerating the programming / erase cycle of storage cells and shortening the lifespan of the storage medium.

[0016] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the various embodiments of the present invention will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details are presented in the various embodiments of the present invention to facilitate a better understanding of this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various variations and modifications based on the following embodiments. The division of the various embodiments below is for ease of description and should not constitute any limitation on the specific implementation of the present invention. The various embodiments can be combined with and referenced by each other without contradiction.

[0017] The data repair method for embedded storage systems involved in this embodiment is executed by an electronic device with data processing capabilities. This electronic device includes, but is not limited to, various terminal devices equipped with embedded storage systems and the processors or controllers running on them, specifically such as vehicle domain controllers, in-vehicle infotainment systems, industrial programmable logic controllers, smart meters, smart gateways, mobile terminals, set-top boxes, and various IoT edge computing nodes. This electronic device includes at least a processor and an embedded memory connected to the processor, such as eMMC memory, UFS memory, or embedded NOR Flash memory. The processor implements the data repair method described in this embodiment by executing program instructions stored in the embedded memory or external storage medium.

[0018] The core of the data repair method provided in this embodiment is as follows: the storage space of the embedded storage system is divided into multiple logical blocks, and a corresponding reference check value is pre-generated and stored for each logical block. During operation, the target logical block to be checked is determined and its current check value is calculated. The current check value is compared with the reference check value to determine whether the data of the target logical block is abnormal. When the comparison result is a mismatch, the backup data fragment corresponding to the logical block is obtained according to the logical block index of the target logical block and overwrite is performed, thereby completing the targeted repair of the damaged logical block. Through the above solution, on the one hand, the block-level verification mechanism enables the system to accurately locate data anomalies within a single logical block. Compared to partition-level or file-level verification, it eliminates the need for a full scan of the entire storage space or partition to determine the specific location of the damage, reducing the time complexity of fault location from being proportional to the partition capacity to being proportional to the capacity of a single logical block, thus significantly improving the efficiency of fault location. On the other hand, the repair operation performs overwrite operations on a single logical block basis instead of a full flush. The repair process is automatically completed within the same execution context after an anomaly is detected, without requiring the device to be shut down and restarted or switched to a dedicated recovery mode. This makes the data repair process transparent to upper-layer services, meeting the service continuity requirements of scenarios such as vehicle systems and industrial controllers. At the same time, writing operations are only performed on logical blocks that fail verification, avoiding redundant erasure and writing of intact data areas, reducing the number of times the embedded storage medium is erased and written, and helping to delay the wear and aging of the storage medium.

[0019] The following is a detailed description of the implementation details of the data repair method for the embedded storage system according to an embodiment of the present invention. The following content is only for the convenience of understanding and is not necessary for implementing this solution.

[0020] like Figure 1 As shown in this embodiment, the storage partition layout, logical address space, and check value index table of the embedded storage system are illustrated.

[0021] In the storage partitioning layout, the physical storage space of an embedded storage system is divided into multiple storage partitions, including but not limited to the boot partition, system partition, vendor partition, and other partitions. Each storage partition carries different types of data. For example, the boot partition stores the system boot program, the system partition stores the operating system core files and framework, and the vendor partition stores the device manufacturer's customized drivers and configuration data.

[0022] In the logical address space, each storage partition establishes a correspondence with the logical address space through mapping and addressing mechanisms. The logical address space is divided into multiple logical blocks. Logical blocks are the basic operation units for data verification and repair in this embodiment. Each logical block corresponds to a continuous logical address range, and its capacity can be configured according to actual application needs, such as 4KB, 8KB, 16KB, or other preset values. Figure 1 As shown, in the logical address space, logical blocks are arranged in logical address order. For the target logical block to be verified, the logical block before its logical address is called the preceding logical block, and the logical block after its logical address is called the following logical block. Each logical block has a unique logical block index, which is used to identify the position of the logical block in the logical address space and serves as the addressing basis for subsequent verification comparison and backup data retrieval.

[0023] The checksum index table stores reference checksums that correspond one-to-one with multiple logical blocks. Each entry in the checksum index table contains a logical block index and its corresponding reference checksum, enabling the system to quickly retrieve the reference checksum corresponding to any logical block based on its index. For example... Figure 1 As shown, during the verification process, the system reads the target reference verification value corresponding to the target logical block from the verification value index table based on the logical block index of the target logical block, and compares it with the current verification value of the target logical block. The verification value index table can be stored in a secure area of ​​the embedded storage system independent of the aforementioned storage partition, or it can be stored in an external secure storage medium connected to the embedded storage system to avoid the reference verification value and the data being verified being damaged simultaneously due to the same physical failure event.

[0024] like Figure 2 As shown, the data repair method for the embedded storage system provided in this embodiment includes the following steps S1 to S3: Step S1: Determine the target logic block to be verified and calculate the current verification value of the data within the target logic block.

[0025] In this step, the system first identifies the target logical block that needs to undergo data integrity verification. For example... Figure 1As shown, the target logic block is the logic block selected in the logical address space for the current verification operation, located between the preceding and following logic blocks. The method for determining the target logic block can be flexibly selected according to different operating scenarios and triggering conditions. During operation, the system selects one or more logic blocks from multiple logic blocks as the target logic block for the current verification cycle based on a preset triggering strategy.

[0026] After identifying the target logic block, the system reads all the data stored in that block and uses a preset encryption algorithm to calculate the current checksum of the target logic block at the current moment. This encryption algorithm includes, but is not limited to, cryptographic hash algorithms, such as SHA-1, SHA-256, or MD5. Any tiny change in the input data will produce significantly different output results. Therefore, even a single bit flip or tampering in the data of the target logic block will result in a different checksum calculated from the original data compared to the reference checksum.

[0027] In a specific example, the reference check value is calculated based on the initial data of the logic block using a preset encryption algorithm; calculating the current check value of the data within the target logic block includes: using the encryption algorithm to calculate the target logic block data to obtain the current check value.

[0028] Specifically, the reference checksum is generated by calculating the initial data in each logical block one by one using a preset encryption algorithm during the initial system deployment, firmware upgrade, or initial data writing phase. This initial data is verified and known to be intact original data. After generation, the reference checksum is written into the checksum index table and persistently stored as the benchmark for subsequent verification and comparison. When performing step S1 to calculate the current checksum, the system uses the exact same encryption algorithm as the one used to generate the reference checksum to calculate the current data of the target logical block, ensuring that the same unmodified data will yield the same checksum at any time after calculation, thus ensuring the reliability of the comparison results. This symmetrical mechanism of using the same encryption algorithm for benchmark generation and runtime verification ensures the consistency of the verification process at the algorithm level and eliminates false alarms caused by algorithm differences.

[0029] In a specific example, determining the target logical block to be verified includes at least one of the following: when the load is detected to be lower than a preset load threshold, traversing the storage space in a preset order and determining the currently traversed logical block as the target logical block; when a read request for a logical block to be processed is received, the logical block to be processed is determined as the target logical block; during the system startup phase, the logical block in the boot partition is determined as the target logical block.

[0030] Specifically, the first triggering method is the background inspection mode during idle periods. The system continuously monitors the current processor load, storage I / O load, or overall system load. When the load is detected to be lower than a preset load threshold, it is determined that the system is currently in an idle period, and a background inspection task is initiated. The inspection task traverses each logical block in the storage space one by one according to a preset order. In each round of traversal, the currently traversed logical block is identified as the target logical block and verification is performed. The preset order can be to traverse the preceding logical block, the target logical block, and the subsequent logical blocks in ascending order of logical block index, or to traverse the logical blocks in each partition according to the priority order of the storage partition. For example, logical blocks in the system partition are traversed first, followed by logical blocks in the vendor partition. This method utilizes idle system resources to perform verification tasks, which will not affect the performance of the foreground business. At the same time, it can achieve a comprehensive check of all logical blocks within a certain period, which is suitable for long-term and continuous integrity protection of stored data during system operation.

[0031] The second triggering method is real-time verification during reading. When the system receives a read request for a specific logical block from an upper-layer application or the operating system kernel, it first identifies the logical block as the target logical block and performs verification before returning the data in that logical block to the requester. This method embeds the verification operation into the critical path of data reading, ensuring that every piece of data read undergoes integrity verification before being delivered to the upper layer. It can intercept corrupted data before it is actually used, preventing corrupted data from being loaded and executed or participating in business logic operations, which could cause wider system anomalies.

[0032] The third triggering method is the boot sector priority verification mode during the startup phase. During the system power-on startup phase, the processor first loads the bootloader from the boot partition to complete system initialization. The integrity of the bootloader directly determines whether the system can start normally. If the bootloader data is corrupted and not detected, the system may fail to start or even load tampered malicious code. Therefore, during the system startup phase, all logical blocks within the boot partition are identified as target logical blocks and verified first. Only after confirming the integrity of the boot data does the subsequent system startup process continue. This method provides data integrity protection for trusted system startup.

[0033] In an optional embodiment, the system can also dynamically adjust the verification strategy based on the health status information of the storage medium. Specifically, the controller of the embedded storage system can typically provide health status indicators of the storage medium, such as the number of erase / write cycles for each physical block and the number of corrected errors. When the health status indicator of a certain physical area exceeds a preset degradation threshold, the system can mark the logical blocks mapped to that physical area as high-risk logical blocks and increase the verification frequency of those logical blocks, for example, prioritizing and more frequently performing verification on high-risk logical blocks in background inspection mode. This approach implements differentiated verification density allocation based on the actual degradation state of the storage medium, concentrating limited verification resources on the areas most likely to be corrupted, thereby improving the overall fault detection rate with the same system resource overhead.

[0034] Step S2: Compare the current check value with the reference check value corresponding to the target logic block.

[0035] In this step, such as Figure 1 As shown, the system reads the target reference check value corresponding to the logical block index from the check value index table based on the logical block index of the target logical block. Then, it compares the current check value calculated in step S1 with the read target reference check value bit by bit. If the current check value is completely consistent with the target reference check value, it is determined that the data of the target logical block has not been changed, the data integrity check passes, and the system can continue to perform check on the next logical block to be checked (e.g., the subsequent logical block of the target logical block) or end the current check cycle. If the current check value does not match the target reference check value, it is determined that the data of the target logical block has been abnormally changed, which may be caused by bit flipping of the storage medium, write interruption caused by abnormal power failure, external malicious tampering, etc. At this time, the system enters step S3 to perform the repair process.

[0036] It should be noted that, since the encryption algorithm used in this embodiment has an extremely low collision probability, that is, the probability of two different sets of input data producing the same output value is negligible in engineering practice, the matching result of the current check value and the target reference check value can characterize the integrity status of the target logical block data with a very high degree of confidence.

[0037] Step S3: If the current check value does not match the reference check value, obtain the corresponding backup data fragment according to the logical block index of the target logical block, and overwrite the backup data fragment into the target logical block.

[0038] In this step, when the comparison result in step S2 is a mismatch, the system locates and retrieves the backup data segment corresponding to the target logical block based on its logical block index. The backup data segment is a copy of data stored in another location that has the same initial data content as the target logical block, and its data volume is consistent with the capacity of a single logical block. After retrieving the backup data segment, the system overwrites it into the storage address space corresponding to the target logical block, replacing the damaged current data with healthy backup data, thus completing the targeted repair of the target logical block.

[0039] The repair process only performs an overwrite operation on the single logical block that failed the verification, without involving any read or write operations on the preceding or succeeding logical blocks or other logical blocks within the same partition. Therefore, the I / O overhead of the repair operation is proportional to the capacity of the single logical block, and independent of the total capacity of the partition. Taking a logical block capacity of 16KB and a partition capacity of 256MB as an example, the amount of data written for targeted repair of a single logical block is only about one sixty-thousandth of that required for a full write of the partition, resulting in a reduction of several orders of magnitude in I / O time and media erasure / writing costs.

[0040] like Figure 3 As shown, in a specific example, obtaining the corresponding backup data fragment based on the logical block index of the target logical block includes: if a backup data fragment corresponding to the logical block index exists in the local backup area, then the backup data fragment is read from the local backup area; if no backup data fragment exists in the local backup area, then the backup data fragment is requested from an external data source.

[0041] Specifically, when acquiring backup data fragments, the system employs a tiered acquisition strategy of prioritizing local access and using remote backup as a fallback. The system first checks if a backup data fragment corresponding to the logical block index of the target logical block exists in the local backup area. The local backup area is located locally within the embedded storage system; read operations do not rely on external network connections. Its data transfer rate is limited by the read bandwidth of the storage medium itself, typically reaching tens to hundreds of megabytes per second. Therefore, the response latency for acquiring backup data fragments from the local backup area is extremely low; for a single logical block with a capacity of several thousand to tens of kilobytes, the read time is usually completed in the sub-millisecond range. When the required backup data fragment is not present in the local backup area—for example, if only some critical partitions are backed up locally due to local storage capacity limitations, or if the data becomes unavailable due to a failure in the local backup area itself—the system automatically switches to requesting backup data fragments from an external data source. This tiered acquisition strategy ensures that the system can acquire backup data with minimal latency under normal scenarios, while retaining recovery capabilities even in extreme scenarios where local backups are missing, preventing the entire recovery process from being interrupted by the failure of a single acquisition path.

[0042] In a specific example, the local backup area is a reserved storage partition in the embedded storage system that is independent of the partition where the target logical block is located; the external data source includes a cloud server, or at least one of the storage media connected to the embedded storage system.

[0043] Specifically, the local backup area is configured as a reserved storage partition in the embedded storage system, independent of the partition containing the target logical block. This reserved storage partition is physically isolated from business partitions such as the boot partition, system partition, and vendor partition, and has independent address ranges and partition management mechanisms. This physical isolation design ensures that when the partition containing the target logical block suffers data corruption due to write interruptions during abnormal power outages or regional faults such as the spread of bad blocks in the storage medium, the backup data in the independent partition remains unaffected, avoiding the risk of simultaneous failure of the original data and backup data due to the same fault event. External data sources support both cloud servers and external storage media connected to the embedded storage system. For devices with network connectivity (such as in-vehicle infotainment systems accessing the internet via Ethernet, Wi-Fi, or cellular networks), the required backup data segments can be remotely obtained through a cloud server. For devices deployed in environments without network coverage (such as industrial controllers in mines or tunnels), backup data can be obtained through external storage media (such as USB storage devices or SD cards) connected to the embedded storage system. Support for both external data source types enables embedded devices under different network conditions to obtain complete recovery capabilities.

[0044] In a specific example, the number of target logical blocks is at least two. The process of requesting backup data fragments from an external data source includes: sending an aggregation data request to the external data source; receiving the merged data stream returned by the external data source corresponding to at least two target logical blocks; and splitting it to obtain the backup data fragment corresponding to each target logical block.

[0045] Specifically, when two or more logical blocks fail verification within a single verification cycle, and these logical blocks all require backup data from an external data source, if an independent data request is initiated for each logical block individually, N logical blocks will generate N complete network communication round trips. Each communication round trip includes fixed overhead such as TCP connection establishment, TLS handshake (if encrypted transmission is used), and HTTP request and response. In scenarios with high network latency (e.g., when connecting to a cloud server via a cellular network, the latency of a single round trip may reach hundreds of milliseconds), the cumulative latency of N communication round trips will increase linearly with the number of logical blocks. To reduce network communication overhead in batch repair scenarios, the system aggregates the backup data requirements of multiple target logical blocks into a single aggregated data request and sends it to the external data source. This aggregated data request carries a list of logical block indexes for all logical blocks that need to be repaired. After receiving the aggregated data request, the external data source concatenates the backup data fragments corresponding to each logical block index into a merged data stream according to a predetermined encapsulation format and returns it all at once. After receiving the merged data stream, the system segments the merged data stream according to each logical block index and the predetermined encapsulation format to restore the backup data fragments corresponding to each target logical block. By compressing N round trips into one, network communication time in batch repair scenarios can be reduced to about one-Nth of the original time.

[0046] like Figure 3 and Figure 4 As shown, in a specific example, after the backup data fragment is overwritten to the target logical block, the method further includes steps S4 and S5: S4, calculate the verification value of the target logical block after overwriting; S5, determine the overwriting result of the target logical block based on the comparison result of the verification value and the reference verification value.

[0047] Specifically, after the overwrite operation is completed, the system does not directly mark the logic block as repaired, but performs a secondary verification of the repair result. The system rereads all data in the target logic block after the overwrite, calculates the data using the same encryption algorithm as in step S1, and generates a verification value. Then, the verification value is compared with the reference verification value corresponding to the logic block in the verification value index table. If the verification value matches the reference verification value, the overwrite result is determined to be successful, indicating that the backup data has been completely and correctly written to the target logic block, the data repair is complete, the system records the repair success, and reports the repair result. If the verification value still does not match the reference verification value, the overwrite result is determined to be unsuccessful, indicating that although the system has performed the write operation, the physical storage area corresponding to the target logic block may have irreversible hardware damage (e.g., gate oxide layer breakdown or severe floating gate charge leakage in the NAND Flash memory cell), causing the data written to this physical area to be unable to be correctly preserved. This verification mechanism forms a closed loop of "write-readback-verification", which can immediately detect write failures caused by physical defects in the storage medium after the repair operation is completed, and prevent the system from mistakenly marking logical blocks that have not been successfully repaired as normal.

[0048] like Figure 3 As shown, in a specific example, after determining the overwrite result of the target logical block based on the comparison result of the verification value and the reference verification value, the method further includes: if the overwrite result is a failure, remapping the logical address of the target logical block to the reserved spare physical block; and writing the backup data fragment to the spare physical block.

[0049] Specifically, when the verification confirms that the overwrite operation has failed, it indicates that the physical storage area currently mapped to the target logical block has suffered irreversible hardware damage, and continued write operations to this physical area will continue to fail. At this point, the system performs a logical address to physical address remapping operation through the embedded storage system's controller (e.g., the flash translation layer in the eMMC controller), remapping the logical address of the target logical block from the currently damaged physical block to a reserved spare physical block. The spare physical block is a portion of healthy physical storage blocks reserved during the manufacturing or initialization phase of the embedded storage system, specifically used to replace permanently damaged physical blocks during operation. After the remapping is complete, the system writes backup data fragments to the spare physical block. Subsequently, all read and write operations on this logical address by the upper-layer system will be transparently redirected to the new spare physical block without the upper-layer application or operating system being aware of the underlying physical block change. This mechanism enables the system to self-heal from permanent physical damage, restoring the normal read and write function of the damaged logical block without replacing the storage hardware, and avoiding the need for the entire device to be returned to the factory for repair or the storage chip to be replaced due to the appearance of a single bad physical block.

[0050] In an optional embodiment, the above data repair method further includes a repair result recording and reporting process. Specifically, after each logical block verification and repair operation, the system records detailed information about the operation in a local log. This recording includes, but is not limited to: the timestamp of the verification execution, the logical block index of the target logical block, the verification result (pass or fail), the source of the backup data fragment (local backup area or external data source), the execution result of the repair operation (success or failure), and whether logical address remapping was triggered. When the system detects that the device is in a network connectivity available state, it reports the repair result information recorded in the local log to a remote monitoring platform or system management module. The remote monitoring platform can perform statistical analysis based on the collected repair record data from multiple devices, such as identifying the failure rate trend of a specific batch of storage chips or the damage frequency of a specific partition, thereby providing maintenance personnel with a global view of the storage media's health status and assisting in the formulation of preventative maintenance strategies.

[0051] Furthermore, during the system initialization phase, the process for generating the baseline checksum is as follows: After initial deployment or firmware upgrade, the system divides the data in each partition of the storage space into multiple logical blocks according to preset logical block partitioning rules. A preset encryption algorithm is used to calculate the reference checksum for the data content of each logical block, and a mapping entry between the logical block index and the reference checksum is established. All mapping entries are written to the checksum index table for persistent storage. Additionally, the system can obtain a list of reference checksums for a specified version from the local secure storage area or from a remote server via the network. This list is pre-generated by a trusted firmware distributor during the firmware packaging phase and includes the index, starting position, and corresponding reference checksum for each logical block in each partition. After obtaining the reference checksum list, the system parses the list and loads the logical block index and reference checksum from each entry into the checksum index table for baseline comparison in subsequent verification processes.

[0052] In an optional embodiment, the system can also maintain a verification result sequence table during background inspections. This sequence table records the result status of each logical block in the most recent verification. After a complete round of inspection is completed, the system can quickly calculate the overall health status of the current storage space based on this sequence table and assess the degree of storage media degradation based on the number and distribution of logical blocks that failed verification. If the number of logical blocks that failed verification exceeds a preset alarm threshold, the system can proactively send a storage degradation alarm to the remote monitoring platform, prompting maintenance personnel to pay attention to the storage health status of the device so that timely replacement can be planned before the storage media reaches the end of its service life.

[0053] In this invention, the storage space is divided into multiple logical blocks, each with a corresponding reference check value. This means that when data in a logical block is corrupted, the system only needs to compare the current check value of that logical block with its reference check value to determine the location of the corruption, without needing to perform a full scan and comparison of the entire storage space. Simultaneously, when a mismatch is detected, the system directly retrieves the corresponding backup data segment based on the logical block index and overwrites it. The entire process, from detection to repair, is automatically completed within the same execution flow. The device does not need to be shut down and restarted, nor does it need to wait for remote intervention from maintenance personnel. For scenarios where service interruption is unacceptable, such as in-vehicle systems and industrial controllers, data recovery can be completed while the device is operating normally. Furthermore, the repair operation only performs an overwrite on the single logical block that failed the check, rather than erasing and rewriting the entire partition it belongs to. This directly reduces the number of erase and write operations on the embedded storage medium, helping to delay the wear and tear of the storage medium.

[0054] In the description of the embodiments of this application, unless otherwise expressly specified and limited, technical terms such as "installation," "connection," "joining," and "fixing" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. For those skilled in the art, the specific meaning of the above terms in the embodiments of this application can be understood according to the specific circumstances.

[0055] The steps described above are for clarity only. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the protection scope of this invention. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, without changing the core design of the algorithm and process, are also within the protection scope of this invention.

[0056] Furthermore, the examples mentioned in the above embodiments can be freely combined, and any combination can be understood as an embodiment. The terms "embodiment" or "example" appearing in various locations in the specification do not necessarily refer to the same embodiment, nor are they independent or alternative embodiments mutually exclusive with other embodiments. Those skilled in the art will understand that the embodiments described herein can be combined with other embodiments.

[0057] Another embodiment of the present invention relates to an electronic device, such as Figure 5As shown, it includes at least one processor 201; and a memory 202 communicatively connected to at least one processor 201; wherein the memory 202 is an embedded storage system, and the storage space of the memory 202 includes multiple logical blocks; the memory 202 stores instructions that can be executed by at least one processor 201, and the instructions are executed by at least one processor 201 to enable at least one processor 201 to perform the data repair method of the embedded storage system as described above.

[0058] The memory 202 and processor 201 are connected via a bus, which may include any number of interconnecting buses and bridges, connecting various circuits of one or more processors 201 and memory 202 together. The bus may also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. A bus interface provides an interface between the bus and the transceiver. The transceiver may be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by processor 201 is transmitted over a wireless medium via an antenna, which further receives data and transmits it to processor 201.

[0059] Processor 201 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory 202 can be used for data accessed by processor 201 during operation.

[0060] Another embodiment of the present invention relates to a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the method embodiments described above.

[0061] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0062] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing the present invention, and in practical applications, various changes in form and detail may be made without departing from the spirit and scope of the present invention.

Claims

1. A data repair method for an embedded storage system, characterized in that, The embedded storage system's storage space includes multiple logical blocks and reference check values ​​corresponding to the multiple logical blocks. The method includes: Identify the target logic block to be verified, and calculate the current verification value of the data within the target logic block; The current verification value is compared with the reference verification value corresponding to the target logic block; If the current verification value does not match the reference verification value, then the corresponding backup data fragment is obtained according to the logical block index of the target logical block, and the backup data fragment is overwritten into the target logical block.

2. The data repair method for an embedded storage system according to claim 1, characterized in that, The step of obtaining the corresponding backup data fragment based on the logical block index of the target logical block includes: If a backup data segment corresponding to the logical block index exists in the local backup area, then the backup data segment is read from the local backup area; If the backup data fragment does not exist in the local backup area, the backup data fragment is requested from an external data source.

3. The data repair method for an embedded storage system according to claim 2, characterized in that, The local backup area is a reserved storage partition in the embedded storage system that is independent of the partition where the target logical block is located; The external data source includes a cloud server, or at least one of the storage media connected to the embedded storage system.

4. The data repair method for an embedded storage system according to claim 1, characterized in that, The determination of the target logic block to be verified includes at least one of the following: When the load is detected to be lower than the preset load threshold, the storage space is traversed in a preset order, and the currently traversed logical block is determined as the target logical block. Upon receiving a read request for a logic block to be processed, the logic block to be processed is identified as the target logic block. During the system startup phase, the logical block within the boot partition is identified as the target logical block.

5. The data repair method for an embedded storage system according to claim 1, characterized in that, The reference verification value is calculated based on the initial data of the logic block using a preset encryption algorithm; The calculation of the current verification value of the data within the target logic block includes: using the encryption algorithm to calculate the current verification value of the target logic block data.

6. The data repair method for an embedded storage system according to claim 1, characterized in that, After overwriting the backup data fragment into the target logical block, the method further includes: Calculate the verification value of the target logic block after the overwrite; Based on the comparison result between the verification value and the reference verification value, the overwrite result of the target logic block is determined.

7. The data repair method for an embedded storage system according to claim 6, characterized in that, After determining the overwrite result of the target logic block based on the comparison result between the verification value and the reference verification value, the method further includes: If the overwrite result is a failure, the logical address of the target logical block is remapped to a reserved spare physical block. Write the backup data fragment into the spare physical block.

8. The data repair method for an embedded storage system according to claim 2, characterized in that, The number of target logical blocks is at least two, and the step of requesting the backup data fragment from an external data source includes: The external data source sends an aggregated data request; Receive the merged data stream returned by the external data source corresponding to at least two of the target logical blocks, and divide it to obtain the backup data fragment corresponding to each of the target logical blocks.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein the memory is an embedded storage system, and the storage space of the memory includes multiple logical blocks; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the data repair method of the embedded storage system as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the data repair method for the embedded storage system as described in any one of claims 1 to 8.

Images