Data management method and smart card

Abstract

The invention provides a data management method and an intelligent card, and the method comprises the steps: enabling a transaction management layer to respond to a transaction request sent by an interface layer, and judging whether a volatile memory has an available storage space meeting a preset condition or not; if not, the transaction management layer executes an NVMlog backup mode, so that the physical write protection layer writes the to-be-written data into the target storage address; if yes, the transaction management layer executes an RAMlog backup mode, so that the physical write protection layer writes the to-be-written data into the target storage address; wherein if the length of the to-be-written data is larger than one page, the transaction management layer controls the current transaction to be in an unsubmitted state until the historical data corresponding to all the to-be-written data is backed up. According to the mode, dynamic switching can be carried out between the RAM log backup mode with the cache as the main part and the NVMlog backup mode with the direct writing as the main part, and therefore the data writing efficiency and reliability of the intelligent card are improved.

Description

Technical Field

[0001] This application relates to the field of smart card technology, and in particular to a data management method and a smart card. Background Technology

[0002] With the widespread application of embedded devices such as smart cards in the financial and communications fields, persistent storage based on non-volatile memory has become the key to ensuring system reliability. However, if non-volatile memory encounters a sudden power failure during the writing process, it is very easy for the data to be in a half-written or inconsistent state, thereby compromising data integrity.

[0003] To address data inconsistency issues caused by power outages, existing technologies typically employ strategies such as hardware atomic writes, pre-write logging, or shadow pages. However, hardware support varies significantly across different platforms, while purely software-based logging or shadow page solutions often consume additional storage space and incur complex management overhead. More importantly, existing power-loss protection schemes are usually tightly coupled with specific hardware characteristics, resulting in rigid implementations that cannot flexibly switch dynamically based on the runtime system's resource status (such as remaining memory space). Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a data management method and a smart card, which, by the transaction management layer detecting the available space of volatile memory when responding to transaction requests and intelligently switching between NVMlog backup mode and RAMlog backup mode accordingly, can automatically adopt a highly reliable log backup mechanism when volatile memory resources are limited, and prioritize the high-speed read and write characteristics of volatile memory when resources are sufficient. This improves the flexibility of the system while ensuring the atomicity of data writing and power-loss safety, thereby improving the data writing efficiency and reliability of the smart card.

[0005] In a first aspect, the present invention provides a data management method applied to a data management system, the data management system comprising an interface layer, a transaction management layer, and a physical write protection layer; the method comprising: The transaction management layer responds to the transaction request sent by the interface layer by determining whether there is available storage space in the volatile memory that meets the preset conditions; the transaction request includes the data to be written and the target storage address.

[0006] If there is no available storage space in the volatile memory that meets the preset conditions, the transaction management layer executes the NVMlog backup mode so that the physical write protection layer writes the data to be written to the target storage address.

[0007] If the volatile memory has available storage space that meets the preset conditions, the transaction management layer executes RAMlog backup mode so that the physical write protection layer writes the data to be written to the target storage address.

[0008] In NVMlog or RAMlog backup mode, if the length of the data to be written is greater than one page, the transaction management layer controls the current transaction to be in an uncommitted state until the backup of all historical data corresponding to the data to be written is completed.

[0009] In an optional implementation, the NVMlog backup mode includes: The transaction management layer determines whether the log area of ​​the non-volatile memory has backed up the historical data corresponding to the target storage address.

[0010] If historical data has been backed up, the physical write protection layer will write the data to be written to the target storage address.

[0011] If historical data is not backed up, the physical write protection layer will back up the historical data in the target storage address to the log area of ​​the non-volatile memory, and write the data to be written to the target storage address after the historical data backup is completed.

[0012] If only partial historical data is backed up, the physical write protection layer will back up the unbacked-up historical data in the target storage address to the log area, and write the data to be written to the target storage address after the unbacked-up historical data is backed up.

[0013] In an optional implementation, the RAMlog backup mode includes: The transaction management layer caches the data to be written in volatile memory.

[0014] When a transaction commit request is received from the interface layer, the physical write protection layer backs up the historical data in the target storage address to the log area of ​​the non-volatile memory.

[0015] After the historical data backup is completed, the physical write protection layer writes the data to be written, which is cached in the volatile memory, to the target storage address.

[0016] In an optional implementation, the step of the transaction management layer caching the data to be written in volatile memory includes: The transaction management layer identifies whether cached data exists at the target memory address.

[0017] If cached data exists, the transaction management layer modifies the cached data in volatile memory corresponding to the target memory address.

[0018] If no cached data exists, the transaction management layer adds the data to be written to volatile memory and merges consecutive address data.

[0019] In an optional implementation, during the execution of NVMlog backup mode or RAMlog backup mode, the method further includes: The physical write protection layer writes the transaction start marker into the non-volatile memory.

[0020] After the physical write protection layer writes the data to be written to the target memory address, the method also includes: The physical write protection layer writes a transaction completion flag to non-volatile memory.

[0021] In an optional implementation, before the step of the physical write protection layer writing the transaction start marker in the non-volatile memory, the method further includes: The transaction management layer increments the page sequence number and determines the write address of the log area in non-volatile memory based on the incremented page sequence number.

[0022] In an optional implementation, the method further includes: When responding to a transaction request, the transaction management layer obtains the current transaction sequence number from the preset transaction control page, increments the current transaction sequence number, and generates the transaction sequence number corresponding to the transaction request.

[0023] When the physical write protection layer backs up historical data to the log area of ​​non-volatile memory, the transaction sequence number is stored in the log area.

[0024] In an optional implementation, when the length of the data to be written is greater than one page, the method further includes: The transaction management layer merges the log area of ​​non-volatile memory and the page backup area of ​​non-volatile memory into a transaction page backup area.

[0025] The physical write protection layer writes consecutive page operation markers into the transaction page backup area.

[0026] The physical write protection layer backs up historical data in the target storage address to the transaction page backup area.

[0027] The physical write protection layer writes the data to be written to the target storage address, and erases the consecutive page operation markers after all the data to be written has been written.

[0028] In an optional implementation, the method further includes: The interface layer sends a data read request to the transaction management layer; the data read request includes the target read address.

[0029] In response to a data read request, the transaction management layer identifies whether the target read address contains data to be written in the volatile memory cache.

[0030] If it exists, the transaction management layer retrieves and returns the data to be written corresponding to the target read address from the volatile memory to the interface layer.

[0031] Secondly, the present invention provides a smart card, including a smart card body and a data management system deployed on the smart card body; the data management system is used to execute the data management method of any of the foregoing embodiments.

[0032] This application provides a data management method and a smart card. By intelligently detecting the available space of volatile memory when responding to transaction requests, it achieves dynamic switching between a RAMlog backup mode primarily based on caching and an NVMlog backup mode primarily based on direct writing. This achieves a dynamic balance between high performance and high reliability while ensuring data write atomicity and power-loss safety. Simultaneously, by utilizing a historical data deduplication mechanism in the NVMlog backup mode to reduce redundant erasure and writing of non-volatile memory, an address merging mechanism in the RAMlog backup mode to optimize memory usage, and a dynamic backup space merging strategy for continuous large data sets, the system's read / write efficiency and resource utilization are improved. Furthermore, combined with transaction start / end marking, sequence number verification, and a log rotation mechanism based on incrementing page sequence numbers, it effectively achieves Flash (flash memory) wear leveling while ensuring stringent transaction consistency and data integrity, thus extending the smart card's lifespan.

[0033] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application. The objectives and other advantages of this application are realized and obtained through the structures particularly pointed out in the description, claims and drawings.

[0034] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

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

[0036] Figure 1 A flowchart of a data management method provided in an embodiment of this application; Figure 2 A flowchart of the NVMlog backup mode execution method provided in the embodiments of this application; Figure 3 A flowchart of the RAMlog backup mode execution method provided in the embodiments of this application; Figure 4A flowchart illustrating a method for caching data to be written in volatile memory, as provided in an embodiment of this application. Figure 5 A schematic diagram of the transaction page backup area provided in the embodiments of this application; Figure 6 This is a schematic diagram of a smart card provided in an embodiment of this application.

[0037] Icons: 1-Smart card body; 2-Data management system. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions 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, 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.

[0039] To help those skilled in the art better understand this application, a brief introduction to its application scenarios and design concepts is provided.

[0040] In resource-constrained devices such as smart cards and embedded security chips, data storage typically relies on non-volatile memory such as Flash memory. Because Flash memory has the physical characteristics of erase-before-write and page-by-page programming, write operations are not instantaneous. If a sudden power outage or reset occurs during data updates (i.e., an unexpected power interruption), it can easily result in only half of the data being written, or inconsistencies between metadata and actual data, leading to severe data corruption or file system crashes.

[0041] To address the aforementioned data consistency issues, existing technologies typically employ two approaches: one relies on specific hardware for atomic write support, but this leads to deep coupling between the software solution and the hardware platform, resulting in poor portability; the other uses pure software-based pre-write logging or shadow page mechanisms, but this often incurs significant performance overhead (such as double writes) and wasted storage space. More critically, existing data management architectures are usually static and rigid, meaning the system is designed with a fixed strategy of prioritizing either high performance or high reliability, unable to dynamically adjust based on runtime system resource conditions (such as remaining memory). This results in the system being unable to process transactions when memory resources are scarce, while failing to fully utilize the advantages of caching when memory is plentiful, making it difficult to balance high performance and high reliability with limited resources.

[0042] Based on this, this application proposes a data management method and a smart card that dynamically senses the resource status of RAM (volatile memory) upon receiving a transaction request. When RAM resources are sufficient, the RAMlog backup mode is prioritized, with persistence only performed upon commit, thereby improving system throughput. When RAM resources are scarce or limited, the system automatically and seamlessly switches to NVMlog backup mode, utilizing the log area of ​​non-volatile memory for robust backup-before-write operations, ensuring the atomicity and security of transactions under extreme resource conditions.

[0043] This application not only breaks the rigid binding between software logic and hardware resources in traditional solutions, but also introduces historical data deduplication, dynamic space merging of large transactions, and a log rotation mechanism based on page sequence numbers. Thus, while ensuring power failure safety, it achieves efficient utilization of storage resources and extends the lifespan of Flash memory, providing a flexible, efficient, safe, and reliable general data management solution for smart card devices.

[0044] To facilitate understanding of this embodiment, the embodiments of this application will be described in detail below.

[0045] This application provides a data management method applied to a data management system, which includes an interface layer, a transaction management layer, and a physical write protection layer.

[0046] Here, the interface layer is primarily responsible for receiving call instructions from external or internal upper-layer applications. The transaction management layer is responsible for maintaining the transaction state machine, determining mode switching, and managing the cache. The physical write protection layer, as the underlying driver, directly interfaces with the hardware storage device and is responsible for performing specific physical operations such as atomic writes, page backups, erases, and mark-and-write operations.

[0047] Reference Figure 1 The data management method provided in this application includes: In step S101, the transaction management layer responds to the transaction request sent by the interface layer and determines whether there is available storage space in the volatile memory that meets the preset conditions; the transaction request includes the data to be written and the target storage address.

[0048] Here, the transaction request is usually initiated by the smart card operating system or upper-layer application. The request contains the content of the data to be written and the target storage address of the data in non-volatile memory.

[0049] Here, volatile memory usually refers to RAM (random access memory).

[0050] Specifically, the preset condition can be a pre-defined storage threshold (e.g., less than 1KB of remaining space, or less than 2 pages remaining). The transaction management layer monitors the occupancy of RAM allocated to the data cache in real time, and determines that the condition is not met when the available space is lower than the threshold.

[0051] In other embodiments, the preset conditions can also be dynamic, determined based on the size of the data to be written. For example, if the length of the data to be written is 512 bytes, and the remaining contiguous space in RAM is only 200 bytes, then the condition is determined not to be met.

[0052] In addition to space availability, preset conditions can also be combined with the system's current load or power status. For example, when the battery is detected to be extremely low and about to shut down, even if there is space in the RAM, it can be forcibly determined that the conditions are not met, thus directly entering a safer direct write mode.

[0053] In step S102, if there is no available storage space in the volatile memory that meets the preset conditions, the transaction management layer executes the NVMlog backup mode so that the physical write protection layer writes the data to be written to the target storage address.

[0054] Here, when RAM resources are limited, the system enters NVMlog backup mode (i.e., non-volatile memory log mode). NVMlog backup mode is a strategy that sacrifices a small amount of write speed for extremely high reliability and instant persistence.

[0055] In NVMlog backup mode, the physical write protection layer's process of writing the data to the target storage address is not a simple direct overwrite, but rather includes a series of rigorous atomicity protection measures. The specific execution process may include: To extend the lifespan of Flash memory and reduce unnecessary erasures and writes, the transaction management layer checks the log area of ​​the non-volatile memory to see if a historical data backup corresponding to the target storage address already exists before performing a backup.

[0056] If the old data at the target address has already been fully backed up in the log area (e.g., backed up in the previous incomplete operation), the physical write protection layer skips the backup step and directly writes the data to be written to the target storage address.

[0057] If there is no relevant backup in the log area, the physical write protection layer first reads the original historical data in the target storage address and writes it to the log area. After the backup is successful, the data to be written is then written to the target storage address.

[0058] If the log area contains backups of only a portion of the target addresses, then only the unbacked-up portions will be backed up.

[0059] To ensure the power-loss recovery mechanism is effective, the physical write protection layer writes a transaction start flag to non-volatile memory before writing any data or backups. After the data to be written is successfully written to the target address, a transaction completion flag is written. At startup, if a start flag is detected but no completion flag is found, the backup data in the log area is used for restoration.

[0060] When selecting the write location for the log area, to prevent fixed physical pages from being corrupted by frequent erasures and writes, the transaction management layer maintains an incrementing page sequence number (page_num). Each time a log write is needed, the latest valid page in non-volatile memory is calculated based on this sequence number as the current log write address, thereby achieving wear leveling.

[0061] Step S103: If the volatile memory has available storage space that meets the preset conditions, the transaction management layer executes RAMlog backup mode so that the physical write protection layer writes the data to be written to the target storage address.

[0062] Here, when RAM resources are sufficient, the system enters RAMlog backup mode (i.e., volatile memory log mode). RAMlog backup mode is a high-performance strategy that reduces the frequency of physical operations on Flash memory by caching data in memory. The specific execution process may include: The transaction management layer first temporarily stores the data to be written in volatile memory, and does not immediately write it to Flash.

[0063] During this process, the transaction management layer executes a smart merging strategy. If the target storage address already exists in the cache (i.e., repeated modifications to the same address), the data in the cache is updated directly. If the data to be written is contiguous with existing data addresses in the cache, they are merged into a larger data block.

[0064] Before data is committed to Flash, if a read request accesses the target storage address, the transaction management layer will first check the volatile storage. If the latest data is in the cache, the cached data is returned directly instead of reading the old data from Flash, thus ensuring read-write consistency.

[0065] Data is only actually written to physical storage when a transaction commit request is received (or when the cache space reaches its limit and triggers an automatic refresh). At this time, the physical write protection layer still follows the principle of backup before writing. First, the old data in Flash at the target storage address is backed up to the log area. After the backup is successful, the new data cached in RAM is written to the target storage address all at once (or in batches).

[0066] In NVMlog or RAMlog backup mode, if the length of the data to be written is greater than one page, the transaction management layer controls the current transaction to be in an uncommitted state until the backup of all historical data corresponding to the data to be written is completed.

[0067] For continuous large data writes spanning multiple physical pages, ordinary single-page backup mechanisms may cause inconsistencies in data at page boundaries.

[0068] When data longer than one page (i.e., continuous large data) is detected, the standard log area space may be insufficient. In this case, the transaction management layer logically merges the log area with the page backup area at the end of the non-volatile memory to build a temporary transaction page backup area, providing enough space to store the historical data of all affected pages.

[0069] Before backup begins, a special contiguous page operation flag is written to this extended backup area. New data can only be written to the target address after all relevant old data pages have been fully backed up to this area.

[0070] To ensure the atomicity of the big data backup process, this application utilizes consecutive page operation markers to lock backup actions involving multiple physical pages into an indivisible whole. This means that the transaction state is strictly locked throughout the entire backup and write process. If a power outage occurs during the backup process, causing the backup to fail to complete completely, it will be considered a failure of the entire atomic operation. Therefore, during recovery, this transaction will be discarded directly, ensuring that the original data in the target storage address remains in its unmodified initial state. Only when all historical data has been fully backed up, all new data has been successfully written, and the lock is finally released by erasing the consecutive page operation markers (or the write completion marker), is the transaction truly considered complete, thus completely eliminating the risk of data inconsistency caused by partial backups or partial writes.

[0071] In one embodiment, reference is made to Figure 2 The NVMlog backup mode includes the following steps S201-S204.

[0072] Here, NVMlog backup mode is typically triggered in scenarios where volatile storage resources are insufficient, or when the system is in a low-power state or about to lose power, requiring immediate data persistence. In NVMlog backup mode, a write-before-log or write-back strategy is employed to ensure the atomicity of data writes.

[0073] In step S201, the transaction management layer determines whether the log area of ​​the non-volatile memory has backed up the historical data corresponding to the target storage address.

[0074] Here, before performing any physical write operation, in order to improve write efficiency and extend the lifespan of non-volatile memory, the transaction management layer first performs a deduplication check.

[0075] Specifically, the transaction management layer maintains a transaction control frame or log index table in volatile memory to record which physical pages or logical addresses have been modified by the currently running transaction. When a new write request is received, the transaction management layer queries this record to determine whether the original data page (i.e., historical data) pointed to by the target storage address has been copied to the log area in the preceding operations of the current transaction.

[0076] For example, within a transaction, if the application layer modifies the same address (such as page 100) twice, the system has already backed up the original data of page 100 during the first modification. When making the second modification, it will determine that the page has been backed up, thus avoiding the need to read and write historical data on the same page twice, significantly reducing the number of times the Flash memory is erased and rewritten.

[0077] In step S202, if historical data has been backed up, the physical write protection layer writes the data to be written to the target storage address.

[0078] Here, if it is determined that historical data already exists in the log area, it means that the current operation is a subsequent update to the same data block, or that the current transaction already has all the information needed for rollback.

[0079] At this point, the transaction management layer instructs the physical write protection layer to skip the backup step and directly perform the write operation. The physical write protection layer directly overwrites the data to be written into the target memory address of the non-volatile memory. Although the data backup step is skipped, it still ensures that the current transaction is in the open state (i.e., the transaction start marker has been written) before the physical write, so as to ensure that if a power failure occurs during the write process, the target address can be restored to the state before the transaction started by using the existing backup data in the log area after restart.

[0080] In step S203, if historical data has not been backed up, the physical write protection layer backs up the historical data in the target storage address to the log area of ​​the non-volatile memory, and writes the data to be written to the target storage address after the historical data backup is completed.

[0081] Here, if the data at the target address is modified for the first time in the current transaction, the physical write protection layer first reads the original old data from the target memory address in the non-volatile memory.

[0082] To achieve wear leveling, the transaction management layer obtains an incrementing page sequence number and selects the latest valid page in non-volatile memory as the write location for the log area based on the sequence number, thus avoiding frequent erasure and writing of the same physical log page.

[0083] The read historical data is written to the selected log area location. During this process, the transaction sequence number of the current transaction may also be written.

[0084] Only after the physical backup operation in the confirmation log area is successfully completed (i.e., the Flash programming is successful) will the physical write protection layer begin writing the data to be written to the target storage address.

[0085] Step S204: If only part of the historical data is backed up, the physical write protection layer backs up the unbacked-up historical data in the target storage address to the log area, and writes the data to be written to the target storage address after the unbacked-up historical data is backed up.

[0086] This occurs in scenarios involving cross-page writes or unaligned writes. For example, the data to be written covers the latter half of page A and the first half of page B, while page A has been backed up in the preceding operations of the current transaction, but page B has not yet been backed up.

[0087] At this point, the assessment result is a partial backup. To save time and space, the physical write protection layer will not re-back up page A, but will only locate the target storage address of page B, read the historical data of page B, and supplement it to the log area.

[0088] Only after all the historical data of the physical pages that have been modified but not yet backed up (such as page B) are safely stored in the log area will the physical write protection layer write the data to be written to the target storage address (the corresponding location of page A and page B).

[0089] In one embodiment, reference is made to Figure 3 The RAMlog backup mode includes the following steps S301-S303.

[0090] Here, RAMlog backup mode is typically triggered when volatile memory (such as RAM) resources are plentiful. It aims to leverage the high-speed read and write characteristics of volatile memory to improve system throughput and reduce the frequency of physical operations on non-volatile memory (such as Flash), thereby achieving high-performance data management.

[0091] In step S301, the transaction management layer caches the data to be written in volatile memory.

[0092] Here, the transaction management layer does not rush to write the data to the slow non-volatile memory, but instead temporarily stores it in the cache of the volatile memory.

[0093] Specifically, before writing data to the cache, the transaction management layer checks whether the target storage address already exists in volatile memory.

[0094] If the target storage address already contains cached data (for example, the application layer has modified the same variable multiple times), the transaction management layer directly overwrites the old data in the cache with the new data to be written. This avoids multiple invalid Flash writes and only retains the state of the last modification.

[0095] If the new data to be written is contiguous in address with existing data in the cache (for example, writing to addresses 0x10-0x1F first, then 0x20-0x2F), the transaction management layer will merge these scattered write requests into a single contiguous block of data. This mechanism can combine multiple small, fragmented writes into a single large page write, significantly improving bandwidth utilization during subsequent commits.

[0096] In RAMlog backup mode, data is in a cached but not persisted state. In this state, if the interface layer initiates a data read request for a specific address, the transaction management layer will first search the volatile memory cache. If a cache hit occurs, the latest data in the cache is returned directly, instead of reading the older data from non-volatile memory. This ensures that the upper-layer application can read the recently modified data before the transaction is committed, guaranteeing logical consistency.

[0097] In step S302, when a transaction commit request is received from the interface layer, the physical write protection layer backs up the historical data in the target storage address to the log area of ​​the non-volatile memory.

[0098] Here, when the upper-layer application issues a transaction commit command, or when the volatile memory cache space reaches a threshold triggering automatic refresh, the cached data is persisted. To prevent data corruption due to power failure during persistence, this application adheres to the safe write principle even in RAM mode when finally writing to disk.

[0099] Specifically, before performing a backup, the physical write protection layer writes a transaction start marker in non-volatile memory to indicate that the persistence process has begun.

[0100] The transaction management layer selects a valid page with minimal wear in non-volatile memory as the log area by incrementing the page sequence number.

[0101] The physical write protection layer reads the historical data originally stored at the non-volatile memory based on the target storage address corresponding to the data to be written in the cache, and backs it up to the selected log area.

[0102] Step S303: After the historical data backup is completed, the physical write protection layer writes the data to be written cached in the volatile memory to the target storage address.

[0103] Here, the physical write protection layer only begins to perform data updates after confirming that the log backup has been successfully written physically.

[0104] The physical write protection layer writes the merged and organized data from volatile memory to the target memory address in non-volatile memory, either all at once or in batches. Due to the initial merging operation, this write is typically an efficient page-based programming process.

[0105] Once all cached data has been successfully written to the target address, the physical write protection layer writes a transaction completion marker to the non-volatile memory. The writing of this marker signifies the perfect termination of the transaction, and the historical data previously backed up in the log area immediately becomes invalid (logically invalid).

[0106] Finally, the transaction management layer clears the corresponding cache space in the volatile memory, releasing resources for subsequent transactions.

[0107] In one embodiment, reference is made to Figure 4 Step S301 includes the following steps S401-S403.

[0108] In step S401, the transaction management layer identifies whether cached data exists in volatile memory at the target storage address.

[0109] Here, before placing the data to be written into the volatile memory, the transaction management layer first needs to determine whether the data to be written is new data or an update to the old cache. To achieve fast identification, the transaction management layer maintains an efficient data structure (such as a hash table, red-black tree, or linked list) as a cache index in the volatile memory.

[0110] The index records the mapping between the target storage addresses of all currently cached data and the physical addresses of volatile memory. When a write request is received, the transaction management layer extracts the target storage address from the request and searches for it in the cache index. This search process not only compares the starting address but also checks the address range to determine whether the current write operation falls within the range of cached data blocks.

[0111] In step S402, if cached data exists, the transaction management layer modifies the cached data in the volatile memory corresponding to the target storage address.

[0112] If the target memory address is found to already exist in volatile memory, this usually means that the upper-level application is repeatedly modifying the same variable or data block (e.g., a loop accumulator counter).

[0113] At this point, the transaction management layer will not allocate new cache space, but will instead locate the corresponding cache data block in volatile memory and overwrite the old cache data with the new data to be written.

[0114] Multiple logical write operations to the same address are folded into a single final state update in volatile memory. Regardless of how many times the upper-layer application modifies the data, only the final state needs to be written to non-volatile memory when the transaction is committed, thus greatly reducing the number of Flash writes and communication bandwidth usage.

[0115] In step S403, if there is no cached data, the transaction management layer adds the data to be written to the volatile memory and merges consecutive address data.

[0116] Here, if no cache record for the target storage address is found, the transaction management layer allocates a new memory space in the volatile memory, stores the data to be written, and creates a new mapping entry in the cache index.

[0117] When adding new data, the transaction management layer checks whether the target memory address of the new data block is contiguous with the addresses of other existing data blocks in volatile memory.

[0118] For example, if the cache already contains data for addresses 0x1000-0x10FF, and the newly written data is for addresses 0x1100-0x11FF, the cache will recognize that these two address ranges are connected end to end.

[0119] At this point, the transaction management layer will logically or physically merge these two separate data blocks into a larger contiguous data block (0x1000-0x11FF).

[0120] Through this merging mechanism, the originally scattered small blocks of data are integrated into large blocks of data, allowing the physical write protection layer to perform a single efficient page write operation on this large block of data, instead of performing multiple inefficient byte writes or small block writes. This improves the write efficiency of non-volatile memory and reduces the management overhead of metadata.

[0121] In one embodiment, during the execution of NVMlog backup mode or RAMlog backup mode, the method further includes: The physical write protection layer writes the transaction start marker into the non-volatile memory.

[0122] Here, before any substantial operation that can change the state of non-volatile memory (such as backing up historical data or writing new data) can begin, its state must first be marked as in progress by a transaction start flag.

[0123] The transaction start flag is typically set to a specific identifier (e.g., 0x5A5A) or the unique sequence number of the current transaction. The transaction start flag is written to the header of the log area in non-volatile memory or to a dedicated transaction control page. To ensure the safety of the flag writing itself, this step is usually performed using atomic write instructions supported by the Flash hardware, or designed as a single-byte / single-word atomic operation.

[0124] In NVMlog backup mode, the transaction start flag must be written before the physical write protection layer begins backing up the historical data at the target storage address. This ensures that if a power outage occurs during the backup process, an incomplete backup operation can be identified upon restart.

[0125] In RAMlog backup mode, although data is initially cached in memory, the transaction start flag must be written before the cached data is flushed to non-volatile memory (involving the backup of old data) during the final commit phase.

[0126] After the transaction start marker is written, if a reset or power failure occurs, the recovery scan program at startup will find a transaction with a start marker but no end marker, thus triggering a rollback or redo process.

[0127] After the physical write protection layer writes the data to be written to the target storage address, the method further includes: The physical write protection layer writes a transaction completion flag to non-volatile memory.

[0128] Here, once the data to be written has been safely and completely written to the target storage address, it means that the data update operation has been physically successful and the transaction has entered the final stage.

[0129] The transaction completion flag is typically set to another identifier corresponding to the start flag (e.g., 0xA5A5), or a toggle of a status bit (e.g., clearing the valid bit). The transaction completion flag is usually stored immediately after the transaction start flag, or it may overwrite the existing start flag.

[0130] Writing the transaction completion flag is logically equivalent to a commit operation. Once the flag is successfully written, the historical data previously backed up in the log area immediately becomes invalid. This means that the new data in the current target storage address is valid and complete, and there is no longer a need to retain backups of the old data.

[0131] The transaction is only truly complete when the transaction completion marker is successfully written to non-volatile memory.

[0132] If the data is written but the completion marker is not successfully written before the power failure, and the system detects only the start marker after restarting, even though the new data may have already been written, for absolute safety, the system may still roll back the data to the old data based on the backup in the log area, or write the completion marker after confirming that the new data is intact through consistency checks (such as CRC, cyclic redundancy check). This ensures that under any extreme power failure situation, the stored data is either the old state before the update or the new state after the update, and there will never be an intermediate state that is half new and half old.

[0133] In one embodiment, before the step of the physical write protection layer writing the transaction start marker in the non-volatile memory, the method further includes: The transaction management layer increments the page sequence number and determines the write address of the log area in non-volatile memory based on the incremented page sequence number.

[0134] Here, the transaction management layer increments the page sequence number and determines the write address of the log area in non-volatile memory based on the incremented page sequence number.

[0135] In traditional solutions, transaction logs or tags are often written to a fixed physical address (such as a fixed system reserved area). Due to the frequent transaction operations, the physical page at this fixed address will be subjected to extremely high write and erase pressure, making it very easy for it to reach its lifespan limit first and fail, causing the entire device to fail.

[0136] In this embodiment, a global page sequence number is maintained within the transaction management layer. This page sequence number is a monotonically increasing counter. Whenever a new transaction is about to be initiated (whether in the commit phase of NVMlog backup mode or RAMlog backup mode), the transaction management layer first increments the current page sequence number by 1 before writing any physical markers.

[0137] Subsequently, the transaction management layer uses the incremented page sequence number to calculate the physical address where the transaction log should be written using a mapping algorithm. Mapping algorithms typically employ modulo operations or logical mapping tables. For example, assuming N physical pages are reserved in non-volatile memory as a circular buffer for the log area, the currently valid write address (i.e., the latest valid page) can be determined by taking the page sequence number modulo N and adding it to the base address of the log area.

[0138] As transactions continue to occur, the page sequence number accumulates, and the calculated write address will circulate within the reserved log area physical pages. This means that the transaction start marker, subsequent backups of historical data, and transaction completion marker will not repeatedly fall on the same physical page, but will be evenly distributed across different physical pages in the log area.

[0139] After determining the specific write address, the transaction management layer passes this address to the physical write protection layer. The physical write protection layer then writes a transaction start marker at this dynamically determined address. This log rotation mechanism based on page sequence numbers effectively achieves wear leveling for non-volatile memory, avoiding premature hardware failure caused by frequent erasures and writes to fixed addresses, and significantly extending the lifespan of the smart card. Simultaneously, the page sequence number itself can also serve as a unique identifier for transactions, aiding in determining the order of transactions during system recovery.

[0140] In one embodiment, the method further includes the following steps S501-S502.

[0141] In step S501, when responding to a transaction request, the transaction management layer obtains the current transaction sequence number from the preset transaction control page, and increments the current transaction sequence number to generate the transaction sequence number corresponding to the transaction request.

[0142] Here, a preset transaction control page is pre-configured in the non-volatile memory. The preset transaction control page is used to store critical control information of the persistent storage system, including the current global transaction sequence number.

[0143] The transaction management layer reads the current sequence number value stored in the preset transaction control page, increments it by 1, and generates a unique identifier for this new transaction, namely the transaction sequence number corresponding to the transaction request.

[0144] After obtaining the new sequence number, the transaction management layer constructs a transaction control frame in RAM. This transaction control frame is used to temporarily store the current transaction's state information in memory, including the newly generated transaction sequence number, the list of target storage addresses involved, and the current execution stage of the transaction.

[0145] To ensure the continuity of the sequence number, the updated global sequence number is usually written back to non-volatile memory synchronously or asynchronously along with the transaction state update, ensuring that the sequence number will not roll back after the next restart.

[0146] In step S502, when backing up historical data to the log area of ​​non-volatile memory in the physical write protection layer, the transaction sequence number is stored in the log area.

[0147] Here, when the physical write protection layer performs a backup operation, it not only writes the old data pages to the log area, but also writes the generated transaction sequence number as metadata to the header of the log area or a specific metadata field.

[0148] Because this application uses a log rotation mechanism (using physical pages cyclically based on page sequence numbers), a physical page in the log area may retain old log data from the last time it was used, or even a long time ago.

[0149] When the system performs transaction recovery or commit confirmation, the transaction management layer reads the sequence number recorded in the log area and compares it with the sequence number in the transaction control frame in memory, or the expected sequence number recorded in the preset transaction control page.

[0150] A log entry is considered a valid backup of the current transaction only if the two are completely identical. If they are inconsistent, the log entry is considered invalid residual data and is ignored.

[0151] In one embodiment, when the length of the data to be written is greater than one page, the method further includes the following steps S601-S604.

[0152] In step S601, the transaction management layer merges the log area of ​​the non-volatile memory and the page backup area of ​​the non-volatile memory into a transaction page backup area.

[0153] Here, when the transaction management layer recognizes that the length of the data to be written exceeds the size of a physical page of non-volatile memory (e.g., greater than 512 bytes or 4KB, depending on hardware specifications), the standard log area space may not be sufficient to accommodate historical data backups of all affected pages.

[0154] At this point, the transaction management layer performs a logical space merging operation. Non-volatile memory typically reserves two types of areas: a log area for storing transaction status and metadata, and a page backup area for storing data page backups. In typical small data scenarios, these two areas may be used independently. However, in large data scenarios, the transaction management layer concatenates these two physical areas in the logical address space, merging them into a unified, larger-capacity transaction page backup area. This ensures that the system can accommodate multiple pages of historical data at once, avoiding the forced splitting of transactions due to insufficient backup space, thus guaranteeing the integrity of complex operations.

[0155] Reference Figure 5 When the transaction management layer identifies that the length of the data to be written is greater than a physical page of non-volatile memory (e.g., greater than 4KB), it executes a space merging strategy to accommodate all historical data backups. Specifically, the transaction management layer concatenates the original non-volatile memory log area and the reserved page backup area at logical addresses, merging them to construct a larger transaction page backup area.

[0156] The transaction page backup area physically comprises a region for storing actual backup data and Log pages for storing control information. The Log pages define a strict data frame format to ensure the atomicity and traceability of transactions.

[0157] The consecutive page operation flag is a special attribute flag written to the physical write protection layer in the header (or specific control bits) of the Log page. As shown in the figure, the consecutive page operation flag can consist of a start identifier (TAG A55A, occupying 2 bytes), an attribute field (ATTRIBUTE, occupying 2 bytes), a cyclic redundancy check code (crc, occupying 2 bytes), and an end identifier (end A55A, occupying 2 bytes).

[0158] When the system detects that the consecutive page operation flag is valid, it indicates that it is currently in the midst of an incomplete consecutive large data transaction. If a power outage occurs and the system restarts at this time, the recovery process will trigger a rollback based on this flag.

[0159] Transaction completion flags are used to indicate whether the entire big data transaction has been successfully committed. In practice, transaction completion confirmation can be achieved by writing a specific end status word at a specific location, or by directly erasing the aforementioned consecutive page operation flags.

[0160] The rollback process specifically includes: The physical write protection layer locates the transaction page backup area, which is formed by merging the log area and the page backup area, based on the indication of the continuous page operation mark.

[0161] The log metadata in the backup area is parsed to extract each backup data block and its corresponding target storage address. Then, the physical write protection layer reads all historical data stored in the backup area and forces it back to the corresponding target storage address on the non-volatile memory. This process overwrites any new data that may have been written to the target address or data corrupted due to power failure.

[0162] Once all affected physical pages have been restored to their initial state before the transaction began, the physical write protection layer performs an erase operation, clearing the consecutive page operation markers. At this point, a consistent state is achieved, and the system is ready to receive new transaction requests.

[0163] For each piece of historical data backed up to this area, the corresponding log data structure is recorded. The log structure includes: The TAG A5 (1 byte) is used to identify that this is a valid log entry.

[0164] INDEX (1 byte) is used to record the sequence number of the current entry in the transaction to prevent out-of-order entries.

[0165] The addr (4 bytes) is used to record the target storage address corresponding to the backup data, that is, which physical address in the non-volatile memory the data originally belonged to, so that the data can be restored to the correct location during recovery.

[0166] The crc (2 bytes) is used to verify the integrity of the entry data.

[0167] In step S602, the physical write protection layer writes a continuous page operation marker into the transaction page backup area.

[0168] Here, before any substantial data backup begins, the physical write protection layer first writes a specific consecutive page operation mark in the merged transaction page backup area (usually at the header position).

[0169] The continuous page operation flag indicates that the system is currently performing an indivisible multi-page operation. If a power outage occurs during the subsequent process, the recovery program after restarting will detect the presence of the continuous page operation flag, determine that the previous large data operation was incomplete, and trigger a forced rollback process.

[0170] In step S603, the physical write protection layer backs up the historical data in the target storage address to the transaction page backup area.

[0171] Here, after the write mark is executed, the physical write protection layer begins performing a large-scale backup. It sequentially reads the original historical data from all physical pages covered by the target storage address and writes this data sequentially into the transaction page backup area.

[0172] Only after all historical data for all affected pages has been successfully and completely written to the backup area is the next step allowed, ensuring that regardless of which page the failure occurs on when new data is written, there is enough information to restore all pages to their state before modification.

[0173] In step S604, the physical write protection layer writes the data to be written to the target storage address, and erases the continuous page operation mark after all the data to be written has been written.

[0174] Here, after the backup is complete, the physical write protection layer begins to write the data to be written sequentially to the target memory address of the non-volatile memory.

[0175] During the write process, the transaction remains in an uncommitted state. Only after the last page of new data has been successfully written to the physical medium will the physical write protection layer erase the markers for the previously written consecutive pages.

[0176] If the marker is successfully erased, it means that all new data has been safely stored, backup data is no longer needed, and the transaction has successfully ended.

[0177] If the mark is not erased (e.g., a power outage occurs before the erasure operation), the mark will still exist after a restart. Then, the snapshot in the transaction page backup area will be used to roll back all pages of the target storage address to the old data, thus ensuring strong consistency of cross-page writes.

[0178] In one embodiment, the method further includes the following steps S701-S703.

[0179] Step S701: The interface layer sends a data read request to the transaction management layer; the data read request includes the target read address.

[0180] During the operation of a smart card, upper-layer applications or the operating system frequently need to read data from memory. The interface layer, acting as the gateway for interaction between the smart card and the outside world, receives these read commands. A read request typically includes the target read address (logical or physical) and the length of data to be read.

[0181] At this point, the smart card may be in the middle of a transaction, with some of the newly written data temporarily stored in the RAM cache and not yet persisted to Flash. This means that the data at the same address is inconsistent between RAM (new value) and Flash (old value).

[0182] In step S702, the transaction management layer responds to the data read request by identifying whether the target read address exists in the data to be written in the volatile memory cache.

[0183] Here, after receiving a read request, the transaction management layer does not directly read data from the non-volatile memory. Instead, it uses an internally maintained cache index table (which records the address mapping relationship of all currently cached data) to compare the target read address in the request with the address range of all data to be written in the volatile memory.

[0184] If the target read address range is completely contained within a certain cached data block, the transaction management layer determines it as a full cache hit, directly extracts the data to be written from the corresponding address range from the volatile memory and returns it to the interface layer, thereby avoiding read operations on the non-volatile memory, ensuring that the data is up-to-date and improving the read speed.

[0185] If the target read address range overlaps with a cached data block, the transaction management layer determines it as a partial cache hit. In this case, a hybrid read and concatenation strategy is adopted: for the overlapping addresses, the latest cached data is read from volatile memory; for the non-overlapping addresses, the existing persistent data is read from non-volatile memory. Finally, these two parts of data are concatenated into a complete target data block and returned to the interface layer to ensure that the read data is logically continuous and up-to-date.

[0186] In step S703, if the data exists, the transaction management layer extracts and returns the data to be written corresponding to the target read address from the volatile memory to the interface layer.

[0187] Here, if it is confirmed that the data at the target read address exists in volatile memory, the transaction management layer will directly extract the latest data to be written from the volatile memory and return it to the interface layer, which will then pass it to the upper-layer application.

[0188] If the target read address is not found in volatile memory, the transaction management layer will switch to non-volatile memory, read the physical page data corresponding to the target address, and return it to the interface layer.

[0189] If the target read address is found to exist only partially in volatile memory, the transaction management layer will perform a data concatenation operation, extracting the latest modified part from volatile memory and reading the unmodified part from non-volatile memory, concatenating the two into a complete data block and returning it, thereby ensuring that every byte of the returned data is the latest state.

[0190] Based on the above embodiments, this application provides a smart card, referring to... Figure 6 The smart card provided in this application includes a smart card body 1 and a data management system 2 deployed on the smart card body 1; the data management system 2 is used to execute the data management method of any of the foregoing embodiments.

[0191] Here, smart cards can include, but are not limited to, embedded security devices such as SIM cards, financial IC cards, social security cards, and electronic certificate cards.

[0192] The smart card includes a smart card body 1 and a data management system 2 deployed on the smart card body 1.

[0193] The smart card body 1 mainly includes a microcontroller chip (MCU), volatile memory (RAM), non-volatile memory (Flash), and input / output interface (I / O) at the hardware level.

[0194] The CPU is responsible for executing the program code of the data management system 2.

[0195] RAM is used to provide temporary data storage space, serve as a cache for RAMlog backup mode in data management methods, and store runtime data structures such as transaction control frames and cache index tables.

[0196] Flash memory is used for persistent storage of user data, system code, and the log area, page backup area, and transaction control page described in this application.

[0197] I / O interfaces are used to communicate with external terminals (such as card readers and mobile phones).

[0198] The data management system 2, deployed on the smart card body 1, is logically divided into an interface layer, a transaction management layer, and a physical write protection layer from top to bottom.

[0199] The interface layer is configured to receive call instructions from the smart card operating system (COS) or upper-layer application applets. Specific instructions include transaction start requests, data write requests (containing the data to be written and the target storage address), data read requests, and transaction commit requests. The interface layer is responsible for validating the parameters of these requests and forwarding them to the transaction management layer.

[0200] The transaction management layer is the core control unit of this system, responsible for implementing the core transaction semantics and mode switching logic. It is used to monitor the available storage space of volatile memory in real time. It determines whether the current remaining space meets preset conditions (such as whether it is full), thereby deciding whether the system enters NVMlog backup mode or RAMlog backup mode.

[0201] Operating in RAMlog backup mode, it is responsible for maintaining the cache index in volatile memory. It identifies whether the target memory address hits the cache, executes the hit-and-update logic, and is responsible for merging write data to consecutive addresses to optimize memory utilization.

[0202] The transaction management layer is also used to maintain page sequence numbers and transaction sequence numbers. Page sequence numbers are used to calculate the physical write address of the log area to achieve wear leveling. Transaction sequence numbers are used to generate globally unique transaction IDs and record them in the transaction control frame.

[0203] The transaction management layer also maintains the lifecycle states of transactions (such as idle, running, committing, and recovering). This is especially important when dealing with large datasets longer than a page, keeping transactions in an uncommitted state until all backups are complete.

[0204] Running when the smart card starts, the transaction management layer scans the transaction markers in the non-volatile memory. If a transaction that has been abnormally interrupted is found, the physical write protection layer is scheduled to perform data restoration.

[0205] The physical write protection layer is an abstract encapsulation of the physical characteristics of non-volatile memory. It is responsible for shielding the details of the underlying page programming and block erase, and providing atomic write services to the upper layers.

[0206] The physical write protection layer is used to perform specific backup operations. Based on instructions from the transaction management layer, it copies historical data from the target storage address to the log area. For big data scenarios, it also supports logically merging the log area and page backup area to build an extended transaction page backup area.

[0207] The physical write protection layer is also used to write transaction start markers, transaction completion markers, and consecutive page operation markers at specific locations in non-volatile memory.

[0208] The physical write protection layer is also used to ultimately program the data to be written to the target address of the non-volatile memory.

[0209] At runtime, the transaction management layer of the data management system 2 dynamically selects the write path based on feedback from the resource monitoring module.

[0210] If volatile memory space is insufficient, the system activates the NVMlog path, and the physical write protection layer directly connects to the non-volatile memory. By performing deduplication, backup, and write processes, it ensures absolute security when resources are limited.

[0211] If there is sufficient volatile memory space, the system activates the RAMlog path. The transaction management layer prioritizes using the cache management module to aggregate data in RAM. Only when a commit instruction is received will the physical write protection layer be called to perform batch backups and writes, thereby maximizing throughput performance while ensuring security.

[0212] At the same time, regardless of the mode, the log writing position of the physical write protection layer is always controlled by incrementing the page sequence number to prevent local wear of the Flash.

[0213] The smart card provided in this application can adaptively adjust its data writing strategy according to the real-time load of its own RAM resources, thus resolving the contradiction between limited storage resources and high performance requirements in traditional smart cards.

[0214] The computer program product provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0215] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0216] Furthermore, in the description of the embodiments of this application, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; 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; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0217] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium 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 storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0218] In the description of this application, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0219] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of protection of the claims.

Claims

1. A data management method characterized by, The method is applied to a data management system, which includes an interface layer, a transaction management layer, and a physical write protection layer; the method includes: The transaction management layer responds to the transaction request sent by the interface layer by determining whether there is available storage space in the volatile memory that meets preset conditions; the transaction request includes the data to be written and the target storage address; If the volatile memory does not have available storage space that meets the preset conditions, the transaction management layer executes the NVMlog backup mode so that the physical write protection layer writes the data to be written to the target storage address. If the volatile memory has available storage space that meets the preset conditions, the transaction management layer executes RAMlog backup mode so that the physical write protection layer writes the data to be written to the target storage address; In the NVMlog backup mode or the RAMlog backup mode, if the length of the data to be written is greater than one page, the transaction management layer controls the current transaction to be in an uncommitted state until the backup of all historical data corresponding to the data to be written is completed.

2. The data management method according to claim 1, characterized by, The NVMlog backup modes include: The transaction management layer determines whether the log area of ​​the non-volatile memory has backed up the historical data corresponding to the target storage address; If the historical data has been backed up, the physical write protection layer will write the data to be written to the target storage address; If the historical data is not backed up, the physical write protection layer will back up the historical data in the target storage address to the log area of ​​the non-volatile memory, and after the historical data backup is completed, write the data to be written to the target storage address. If only a partial backup of the historical data is performed, the physical write protection layer will back up the unbacked-up historical data in the target storage address to the log area, and after the unbacked-up historical data is backed up, write the data to be written to the target storage address.

3. The data management method of claim 1, wherein, The RAMlog backup mode includes: The transaction management layer caches the data to be written in the volatile memory; When a transaction commit request is received from the interface layer, the physical write protection layer backs up the historical data in the target storage address to the log area of ​​the non-volatile memory. After the historical data backup is completed, the physical write protection layer writes the data to be written, which is cached in the volatile memory, to the target storage address.

4. The data management method according to claim 3, characterized in that, The step of the transaction management layer caching the data to be written in the volatile memory includes: The transaction management layer identifies whether the target storage address contains cached data in the volatile memory; If the cached data exists, the transaction management layer modifies the cached data in the volatile memory corresponding to the target storage address; If the cached data does not exist, the transaction management layer adds the data to be written to the volatile memory and merges consecutive address data.

5. The data management method according to claim 1, characterized in that, During the execution of the NVMlog backup mode or the RAMlog backup mode, the method further includes: The physical write protection layer writes a transaction start marker into the non-volatile memory; After the step of writing the data to be written to the target storage address in the physical write protection layer, the method further includes: The physical write protection layer writes a transaction completion flag into the non-volatile memory.

6. The data management method according to claim 5, characterized in that, Before the step of writing the transaction start marker in the non-volatile memory, the method further includes: The transaction management layer increments the page sequence number and determines the write address of the log area in the non-volatile memory based on the incremented page sequence number.

7. The data management method according to claim 1, characterized in that, The method further includes: When responding to the transaction request, the transaction management layer obtains the current transaction sequence number from the preset transaction control page, and increments the current transaction sequence number to generate the transaction sequence number corresponding to the transaction request. When the physical write protection layer backs up the historical data to the log area of ​​the non-volatile memory, the transaction sequence number is stored in the log area.

8. The data management method according to claim 1, characterized in that, When the length of the data to be written is greater than one page, the method further includes: The transaction management layer merges the log area of ​​the non-volatile memory with the page backup area of ​​the non-volatile memory into a transaction page backup area. The physical write protection layer writes consecutive page operation markers into the transaction page backup area; The physical write protection layer backs up the historical data in the target storage address to the transaction page backup area; The physical write protection layer writes the data to be written to the target storage address, and erases the consecutive page operation markers after all the data to be written has been written.

9. The data management method according to claim 3, characterized in that, The method further includes: The interface layer sends a data read request to the transaction management layer; the data read request includes the target read address; In response to the data read request, the transaction management layer identifies whether the target read address exists in the data to be written cached in the volatile memory; If present, the transaction management layer extracts and returns the data to be written corresponding to the target read address from the volatile memory to the interface layer.

10. A smart card, characterized in that, It includes a smart card body and a data management system deployed on the smart card body; the data management system is used to execute the data management method according to any one of claims 1-9.

Images