Persistent memory crash recovery method and system combining operation queue and collaborative synchronization

Abstract

The invention discloses a persistent memory crash recovery method and system combining an operation queue and collaborative synchronization. The persistent memory crash recovery method and system are suitable for an Optan DCPMM or NVDIMM-based file system. According to the method, a file system is divided into a newest view and a consistent view, metadata packaging and scheduling are carried out by adopting an operation queue bound according to files, and asynchronous persistence is completed through foreground and background threads. The system dynamically monitors a plurality of indexes based on the FoF window, regulates and controls the check point period and the persistent batch of the operation nodes according to the indexes, and improves the data security in a power-off scene. Write amplification is reduced by introducing a lightweight index and adding a write strategy, and resource allocation and release are isolated through atomic operation. After the system crashes and is restarted, the consistent state of the file system is quickly rebuilt with high concurrency through a verification mechanism, snapshot replay and index recovery. The scheme has the advantages of low write amplification, high recovery efficiency, extensible architecture and the like.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer storage systems, in particular to a persistent memory crash recovery method and system combining operation queue and cooperative synchronization. BACKGROUND

[0002] With the development of persistent memory (PM) technology, new storage media with non-volatility, byte addressability and high bandwidth, such as Intel Optane DCPMM and NVDIMM, are widely used in file system design. Although existing PM file systems have initially realized the trade-off between crash consistency and performance, they still face many challenges in actual deployment.

[0003] Specifically, the existing PM file system still has significant deficiencies in the following aspects: 1. Serious write amplification: Frequent metadata atomic update operations (such as linked list pointers or log tail pointers) will cause random writes, significantly increasing the write amplification of persistent memory and wasting I / O bandwidth; 2. Foreground I / O blocking: Most systems use strict synchronization strategies and need to return user responses after data is written to disk, resulting in long write paths and reduced I / O throughput; 3. Low FoF energy window utilization: In the case of power failure, traditional mechanisms have difficulty completing the persistent flushing of critical data within the limited FoF (Flush-on-Fail) energy window; 4. High recovery delay: Most systems rely on full-disk scanning or sequential log replay to rebuild a consistent view, making it difficult to meet the needs of high-availability scenarios for sub-second or sub-second recovery.

[0004] Therefore, there is an urgent need for a new persistent memory file system crash recovery mechanism that has low write amplification, low blocking, and efficient crash recovery capabilities, and can fully utilize the energy window in the case of power failure to improve system robustness and overall performance. SUMMARY

[0005] This section aims to summarize some aspects of the embodiments of the present application and briefly introduce some preferred embodiments. Some simplifications or omissions may be made in this section and the abstract and title of the specification to avoid obscuring the purpose of this section, abstract and title, and such simplifications or omissions cannot be used to limit the scope of the present application.

[0006] Therefore, to solve the above technical problems, the present application provides the following technical solutions: a persistent memory crash recovery method combining operation queue and cooperative synchronization, comprising the following steps: S1: dividing the file system into a latest view residing in volatile memory and a consistent view residing in persistent memory; S2: Receive user I / O requests, encapsulate each user operation into an operation node, and insert the operation node into the corresponding operation queue according to file binding; S3: Returns a user response immediately after updating the latest view, without waiting for persistence; S4: Background threads run periodically. Execute checkpoints to batch process the operations in the queue. Each operation node is flushed to a consistent view; S5: Real-time monitoring of FoF residual energy window time Number of critical operation nodes that are not persisted Average persistence time of operation nodes and average write time per data block ; S6: Dynamic Adjustment Cycle Number of nodes per batch of write operations Ensure that the requirements are met. and ; S7: A lightweight index structure is used instead of a doubly linked list. Operation nodes carry data block reference information, and file writing adopts an append-only strategy. S8: Foreground threads allocate resources through atomic operations, and background threads release resources through atomic operations; S9: After a system crash and restart, load the consistent view and checkpoint snapshot, and scan the persistent operation node queue to rebuild metadata; S10: Verify the magic number and checksum of the node header, replay valid nodes and roll back partially completed nodes, load a lightweight index snapshot to restore the latest view.

[0007] As a preferred embodiment of the persistent memory crash recovery method combining operation queues and cooperative synchronization described in this invention, wherein: in step S5: FoF residual energy window time Obtain in real time via hardware registers or the pmem_get_foflen interface; The average persistence time of the operation node The calculation is based on persistent memory bandwidth and the average size of the operand node. The formula is as follows: Calculation, where The average size of the operation nodes. This refers to the measured bandwidth of persistent memory. The average write time of the data block The write latency of a single data block was measured using the pmemobj_bench tool. The number of non-persistent critical operation nodes The number of unflushed metadata update nodes is dynamically counted by the operation queue monitoring module.

[0008] As a preferred solution of the method for persistent memory crash recovery combining operation queue and cooperative synchronization, the dynamic regulation in step S6 specifically includes: The maximum number of operation nodes in a single batch is set: ; The period T is calculated by the following formula: ; wherein, the redundancy coefficient ; When , an emergency checkpoint is triggered.

[0009] As a preferred solution of the method for persistent memory crash recovery combining operation queue and cooperative synchronization, the lightweight index structure in step S7 is FDS-Index containing triplets <inode_id, version, pm_addr> or version chain-based persistent hash table, and only new entries are added during updating.

[0010] As a preferred solution of the method for persistent memory crash recovery combining operation queue and cooperative synchronization, the resource allocation and release in step S8 specifically includes: The foreground thread updates the DRAM resource allocation counter by atomic_inc; The background thread releases the completed persistent resource by atomic_dec.

[0011] As a preferred solution of the method for persistent memory crash recovery combining operation queue and cooperative synchronization, the verification mechanism in step S10 specifically includes: The operation node header is preset with magic number 0x55AA and CRC32 checksum; The failed verification node is marked as uncommitted; The partially completed node is rolled back to the previous consistent state through reverse operation log.

[0012] As a preferred solution of the method for persistent memory crash recovery combining operation queue and cooperative synchronization, the operation queue is organized as a directed acyclic graph structure, supporting cross-file operation merging.

[0013] As a preferred solution of the method for persistent memory crash recovery combining operation queue and cooperative synchronization, the method is applicable to persistent memory file systems based on Optane DCPMM or NVDIMM under Linux / Windows operating systems.

[0014] A computer readable storage medium, having stored thereon a computer program, wherein the program, when executed by a processor, implements any of the above methods.

[0015] The crash recovery system of persistent memory combined with operation queue and cooperative synchronization is applied to any of the above-mentioned crash recovery methods of persistent memory combined with operation queue and cooperative synchronization, and the method comprises the following steps: A dual-view management module is used to maintain the latest view in volatile memory and the consistent view in persistent memory. An operation queue management module receives user I / O requests and generates operation nodes, and stores the operation nodes in the operation queue according to file binding. A dynamic regulation module is connected to the operation queue management module Signal, real-time monitoring of FoF residual energy window time , the number of key operation nodes not persisted , the average persistence time of operation nodes and the average write time of data blocks , and output the regulation instruction meeting And Period , the number of operation nodes persisted in a single checkpoint ; A cooperative synchronization module is connected to the operation node reference interface of the operation queue management module, and comprises a lightweight index generation unit and an atomic operation unit, so as to realize resource allocation / release isolation and data block reference management. A checkpoint execution module receives the instruction of the dynamic regulation module, and persists Operation nodes in a consistent view in batches with a period T; A FoF emergency module responds to a power-off interrupt signal, and forcibly flushes the operation nodes not persisted within Window; A crash recovery module loads the consistent view and the checkpoint snapshot, and reconstructs the latest view through a verification mechanism and a replay unit.

[0016] The beneficial effects of the present application are as follows: 1、The present application combines "write fast return" with a delayed consistent checkpoint mechanism, greatly reducing the number of random writes when synchronously updating metadata; a lightweight FDS-Index (ternary index structure) is used to replace the traditional double-linked list, and the operation node has data block reference information, avoiding repeated writing of pointers or path information, and realizing more efficient batch persistence.

[0017] 2. The application monitors the FoF residual energy window, non-persistent key operation number and average persistent delay in real time, and dynamically calculates the optimal checkpoint period and single maximum node number, to ensure that the key data is written to the disk within a typical 300ms window; compared with the static period strategy, the dynamic regulation mechanism can improve the window utilization rate to more than 90%, and reduce the risk of data loss caused by power interruption.

[0018] 3. Based on the per-file operation queue and the lightweight index snapshot, the application does not need to scan the whole disk after crash and restart, only loads the checkpoint and index in parallel, uses CRC32 plus magic number check to remove illegal nodes, and replays legal operations in parallel; the recovery time can be shortened to less than 20% of the traditional synchronization mechanism, meeting the strict requirements of distributed storage and key business scenarios for high availability.

[0019] 4. The application logically separates the "latest view" (resident volatile memory) and "consistent view" (resident persistent memory), bridges through the "cooperative synchronization module", realizes loose coupling between views, and realizes the front-end atomic resource allocation and back-end atomic resource release mechanism, so that the responsibilities of each module are clear and the mainstream PM file system can be seamlessly integrated.

[0020] 5. The application does not depend on specific manufacturer hardware, and can be deployed only with standard NVDIMM / Optane DCPMM and FoF support environment; it is suitable for mainstream x86_64 and ARM64 embedded platforms; through software level dynamic regulation and lightweight index technology, no additional hardware acceleration module is needed, and the research and development and operation and maintenance costs are minimized. BRIEF DESCRIPTION OF DRAWINGS

[0021] In order to more clearly illustrate the technical solutions of the embodiments of the application, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor. Among them: Figure 1 It is a system architecture diagram of the application.

[0022] Figure 2 It is a workflow diagram of the application.

[0023] Figure 3 It is a pseudo code diagram of the function flow of the file system executing "write quick return" operation in the second embodiment of the application.

[0024] Figure 4 It is a pseudo code diagram of the periodic checkpoint operation of CheckpointWorker in the second embodiment of the application.

[0025] Figure 5 Pseudo code of the emergency flash procedure triggered by the FoFHandler in Embodiment Two of the present application when receiving a power failure interrupt.

[0026] Figure 6 Pseudo code of the recovery operation by the FDS-Index after a system crash in Embodiment Two of the present application. DETAILED DESCRIPTION

[0027] In order to make the above objectives, features and advantages of the present application more apparent, specific embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0028] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present application. However, it will be apparent to one skilled in the art that the present application can be practiced without the specific details given herein, that the present application can be practiced with other different ways, and that the present application is not limited to the embodiments disclosed below.

[0029] Secondly, the "one embodiment" or "embodiment" referred to herein means that the specific features, structures or characteristics can be included in at least one implementation of the present application. "In one embodiment" appearing in different places in the specification does not mean the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments.

[0030] Embodiment 1 Reference Figures 1-2 For the first embodiment of the present application, a persistent memory crash recovery method combining operation queues and cooperative synchronization is provided, which is suitable for deployment in a persistent memory device (such as Intel Optane DCPMM, NVDIMM-N) environment supporting byte addressing, and can be implemented under Linux or Windows operating system, and uses the direct access (DAX) mechanism and PMDK library interface to realize direct read and write and consistency maintenance of the persistent memory.

[0031] After system initialization, the file system state is divided into two logical views: S1: View division and system environment setting; Latest view: Resides in volatile memory (such as DRAM), used to cache the user's recent write operation, such as the data and metadata corresponding to the user I / O operation; Consistent view: Resides in persistent memory (PMem), used to maintain the recoverable file system consistency state.

[0032] The dual-view structure provides a structural basis for subsequent asynchronous consistency maintenance and crash recovery through decoupling processing of data and metadata.

[0033] Adaptation system platform: Hardware environment: Persistent memory device supporting byte addressing (Intel Optane DCPMM / NVDIMM-N); Software environment: Linux / Windows operating system, persistent memory operation coordination is realized through DAX direct access mechanism and PMDK library.

[0034] S2: User requests encapsulation and operation queue mounting; When the user submits a write request, the system will encapsulate it into an operation node (Operation Node) and insert it into the operation queue bound to the target file.

[0035] Each node structure includes: operation type (such as create, write, unlink), target inode number, data block address, data length, timestamp (for recovery order), preset magic number 0x55AA and CRC32, etc. Check information, And the tail is attached with an 8-byte rollback log (for S63 reverse operation), format as follows:

[0036] Operation queue mechanism: Store operation nodes according to files; Cross-file operations (such as rename) are extended to directed acyclic graph (DAG) structure to ensure atomic submission; Return to the user immediately after updating the latest view in DRAM, realizing "write fast return".

[0037] After encapsulation, the operation is immediately executed in the latest view and returned to the user, realizing the "high-speed return" mechanism and improving I / O throughput efficiency.

[0038] S3: Periodic checkpoint mechanism; The background thread starts the "checkpoint task" periodically, and performs the following processing on the non-persistent nodes in the operation queue: S31: Scan each operation queue at time interval T, collect non-persistent nodes, and form a batch (default nodes); S32: Calculate the total write time consumption of the current batch , constraint , where is the FOF (Flush-on-Fail) residual window time; This ensures that critical data persistence can still be completed when the system suddenly powers off; S33: Write the batch operation to the consistent view in an atomic manner, and update the FDS-Index index.

[0039] S4: Dynamic regulation of FoF energy window driving In order to guarantee the persistence of key operation nodes in the power-off scenario, the system dynamically adjusts the flush period T and the number of single checkpoint persistent operation nodes , the steps are as follows: S41: Call the PMDK interface pmem_get_foflen(), or access the 0x1A8 register in the Intel Optane platform control table (PTT) through hardware, to obtain the current available FoF residual energy window time ; S42: The persistence delay is determined as follows: The time consumed by a single data block persistence The typical value is about 1.2μs (4KB) measured by the pmemobj_bench tool; The average operation node write latency is obtained by the following formula: , wherein is the average size of the operation node, is the measured bandwidth of the persistent memory; , wherein the average size of the operation node is about 256B, and the measured bandwidth of the persistent memory is about 2GB / s (Optane DCPMM measured bandwidth).

[0040] S43: Set the maximum number of operation nodes in a single batch: ; This parameter represents the maximum number of nodes that can be operated within the budget window , calculated according to the single node time .

[0041] Calculate the flush period formula: Calculate the flush period by the formula ; wherein is the redundancy coefficient, and the value range is ; When , trigger an emergency checkpoint to monitor the system state and prevent system problems caused by too many nodes; S5: Design of cooperative synchronization mechanism and lightweight index structure FDS-Index To improve metadata consistency and replay efficiency, the system introduces a synchronization mechanism in the persistence phase. This mechanism uses a combined strategy of asynchronous append write, lightweight index, and resource isolation: Lightweight index structure FDS-Index: Structure: Hash table is constructed with a triple of <inode_id, version, pm_addr>; Conflict handling: Linear probing method is adopted, and the load factor threshold is 0.7; Version management: The version is generated by the rdtsc() instruction, and the old entry is marked as stale and recycled asynchronously.

[0042] Atomic resource isolation: Frontground thread: The atomic_inc updates the res_counter.alloc_count in the DRAM; Background thread: The atomic_dec releases the resource after being persisted.

[0043] S6: Crash recovery process; After the system is abnormally closed due to power failure or the like, the system will perform the following operations to rebuild the latest view: Consistent view loading: The last checkpoint snapshot is recovered from the persistent memory; Operation node checking: S61: 0x55AA and the CRC32 check code in the operation node header are read and verified in sequence; The node with failed checking is marked as OP_STATUS_INVALID and written into the recovery.log; Legal node replay: S62: All legal nodes are sorted according to timestamps, and the redo legal operations are executed in sequence; S63: The inverse operations are performed on the partially completed nodes to perform rollback processing; Example: If the original operation is create, the inverse operation is unlink, and the execution action is to delete the target file; If the original operation is write, the inverse operation is zero-fill, and the execution action is to clear the data block; The original operation and the inverse operation mapping relationship are maintained in the log, so that the system can be rolled back to a logically consistent state; S64: Rebuild the latest view: Load the FDS-Index snapshot to recover the active state.

[0044] The application further discloses a persistent memory crash recovery system combined with an operation queue and cooperative synchronization, applied to the persistent memory crash recovery method combined with the operation queue and the cooperative synchronization. A dual-view management module is used for maintaining the latest view in the volatile memory and the consistent view in the persistent memory; Operation queue management module, receiving user I / O request and generating operation node, storing to operation queue by file binding; Dynamic regulation module, connected to operation queue management module Signal, real-time monitoring FoF residual energy window time , non-persistent key operation node number , operation node average persistence time And the average write time of data block , and output the regulation instruction meeting And Period , single checkpoint persistent operation node number ; Co-synchronization module, connected to operation queue management module operation node reference interface, including lightweight index generation unit and atomic operation unit, realizing resource allocation / release isolation and data block reference management; Checkpoint execution module, receiving dynamic regulation module instruction, persisting Operation node to a consistent view in batches with period T; FoF emergency module, responding to power-off interrupt signal, flushing non-persistent operation node within Window; Crash recovery module, loading consistent view and checkpoint snapshot, rebuilding the latest view through verification mechanism and replay unit.

[0045] Embodiment 2 Referring to Figure 2 , 3 And 4, the second embodiment of the application, which is different from the first embodiment, is as follows: 1. Operating environment: Kernel version: customized Linux Kernel 5.15; Hardware platform: x86_64 server equipped with Intel Optane DC Persistent Memory (DCPMM); File system: NOVA persistent memory file system (supporting DAX direct access) dual-view structure: Latest view: resident DRAM, storing temporary state (data block + metadata) of user I / O; Consistent view: resident persistent memory, maintaining crash-recoverable consistent state (address range: 0x8000~0xFFFF); 2. Module integration: The following core modules are extended on the NOVA file system architecture: OpQueueManager: Its function is to manage operation queues by file granularity, supporting cross-file DAG dependency chains (such as rename operations); OCheckpointWorker: periodically batch-persist operation nodes with adjustable period T, triggering batch persistence (default , ); OFDSIndexTracker: maintain the mapping between DRAM snapshot index (<inode_id, version, pm_addr> triplet) and operation nodes; FoFHandler: respond to Flush-on-Fail (FOF) interrupts, schedule emergency flushing in the residual window (typical value: 300 ms); 3. The typical workflow is as follows: Step 1: User write request processing; User process calls write(fd, buf, len); OpQueueManager constructs operation node OpNode (including write type, target inode, data block address, etc.); The operation node is inserted into the file binding queue, and the latest DRAM view is updated immediately after returning.

[0046] As shown in Figure 3 , the figure shows the specific function implementation of the "write fast return" process, which shows the typical processing flow of operation node construction, operation queue writing, and DRAM view updating.

[0047] Step 2: Periodic checkpoint execution; CheckpointWorker wakes up every 100 ms; Batch collect non-persistent nodes (about 4096), call pmem_persist() atomic flush to persistent memory; Update the consistent view of FDS-Index.

[0048] As shown in Figure 4 , CheckpointWorker wakes up every period to collect batch operation nodes, execute pmem_persist() persistence function and update the consistent view until all nodes are processed.

[0049] Step 3: FoF emergency processing After receiving the FoF interrupt signal, FoFHandler traverses all file operation queues; Forced flush unpersisted nodes, ensure key data flush to disk within 300ms energy window.

[0050] As Figure 5 shown, the emergency data persistence process executed by FoFHandler after receiving a power failure interrupt is demonstrated, ensuring that the operating node flush task is completed within the typical 300ms residual energy window.

[0051] Step 4: Crash recovery After system restart, call RecoverFromCrash() to load the last checkpoint snapshot; Rebuild metadata through FDS-Index, replay legal operating nodes by timestamp.

[0052] As Figure 6 shown, during system restart, the file system loads the last checkpoint snapshot and combines the FDS-Index reconstruction and operation log replay processes through the RecoverFromCrash() interface to restore the consistent state.

[0053] 4. Alternative implementation Scheme A: Cross-file operation optimization; Expand OpQueue to a directed acyclic graph (DAG) structure to support atomic submission of cross-file operations (such as mvdir1 / filedir2 / ).

[0054] Scheme B: Low-power embedded adaptation; In ARM64 edge devices (such as NXP i.MX8): Adjust the checkpoint period to ; Optimize the FoF energy model to adapt to capacitive backup power.

[0055] Scheme C: Versioned recovery enhancement; Replace FDS-Index with a version chain persistent hash table to support file history version rollback.

[0056] This embodiment introduces DAG structure cross-file atomic operations (Scheme A) and version chain persistent hash table (Scheme C) in alternative schemes, providing a directly usable technical framework for future multi-version rollback and distributed file system expansion; the dynamic control module can access more complex energy prediction models or machine learning algorithms to continuously optimize crash recovery performance, with good upgrade and evolution space.

[0057] It should be noted that the above examples are only used to illustrate the technical solutions of the present application but not limit the present application. Although the present application is described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application can be modified or equivalently replaced, without departing from the spirit and scope of the technical solutions of the present application, which should be covered in the scope of the claims of the present application.

Claims

1. A persistent memory crash recovery method combining operation queues and cooperative synchronization, characterized by: Includes the following steps: S1: Divide the file system into a latest view residing in volatile memory and a consistent view residing in persistent memory; S2: Receive user I / O requests, encapsulate each user operation into an operation node, and insert the operation node into the corresponding operation queue according to file binding; S3: Returns a user response immediately after updating the latest view, without waiting for persistence; S4: Background threads run periodically. Execute checkpoints to batch process the operations in the queue. Each operation node is flushed to a consistent view; S5: Real-time monitoring of FoF residual energy window time Number of critical operation nodes that are not persisted Average persistence time of operation nodes and average write time per data block ; S6: Dynamic Adjustment Cycle Number of nodes per batch of write operations Ensure that the requirements are met. and ; S7: A lightweight index structure is used instead of a doubly linked list. Operation nodes carry data block reference information, and file writing adopts an append-only strategy. S8: Foreground threads allocate resources through atomic operations, and background threads release resources through atomic operations; S9: After a system crash and restart, load the consistent view and checkpoint snapshot, and scan the persistent operation node queue to rebuild metadata; S10: Verify the magic number and checksum of the node header, replay valid nodes and roll back partially completed nodes, load a lightweight index snapshot to restore the latest view.

2. The persistent memory crash recovery method combining operation queues and cooperative synchronization as described in claim 1, characterized in that: In step S5: FoF residual energy window time Obtain in real time via hardware registers or the pmem_get_foflen interface; The average persistence time of the operation node The calculation is based on persistent memory bandwidth and the average size of the operand node. The formula is as follows: Calculation, where The average size of the operation nodes, This refers to the measured bandwidth of persistent memory. The average write time of the data block The write latency of a single data block was measured using the pmemobj_bench tool. The number of non-persistent critical operation nodes The operation queue monitoring module dynamically counts the number of metadata update nodes that have not been refreshed.

3. The persistent memory crash recovery method combining operation queues and cooperative synchronization as described in claim 2, characterized in that: The dynamic control in step S6 specifically includes: Set the maximum number of operation nodes per batch: ; The period T is calculated using the following formula: Among them, the redundancy coefficient ; when At that time, an emergency checkpoint is triggered.

4. The persistent memory crash recovery method combining operation queues and cooperative synchronization as described in claim 3, characterized in that: The lightweight index structure in step S7 contains triples.<inode_id, version, pm_addr> The FDS-Index or version-chain-based persistent hash table only appends new entries during updates.

5. The persistent memory crash recovery method combining operation queues and cooperative synchronization as described in claim 4, characterized in that: The resource allocation and release in step S8 specifically includes: The foreground thread updates the DRAM resource allocation counter via atomic_inc; The background thread releases the persistent resources using atomic_dec.

6. The persistent memory crash recovery method combining operation queues and cooperative synchronization as described in claim 5, characterized in that: The verification step in step S10 specifically includes: The operation node header is pre-set with magic number 0x55AA and CRC32 checksum; Nodes that fail verification are marked as unsubmitted. Some completed nodes roll back to the previous consistent state through reverse operation logs.

7. The persistent memory crash recovery method combining operation queues and cooperative synchronization as described in claim 6, characterized in that: The operation queue is organized as a directed acyclic graph structure, which supports merging operations across files.

8. The persistent memory crash recovery method combining operation queues and cooperative synchronization as described in claim 7, characterized in that: The method is applicable to persistent memory file systems based on Optane DCPMM or NVDIMM under Linux / Windows operating systems.

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

10. A persistent memory crash recovery system combining operation queues and cooperative synchronization, applied to the persistent memory crash recovery method combining operation queues and cooperative synchronization as described in any one of claims 1-9, characterized in that, include: The dual-view management module is used to maintain the latest view in volatile memory and the consistent view in persistent memory. The operation queue management module receives user I / O requests and generates operation nodes, which are then bound to and stored in the operation queue according to files. The dynamic control module is connected to the operation queue management module. Signal, real-time monitoring of FoF residual energy window time Number of critical operation nodes that are not persisted Average persistence time of operation nodes and average write time per data block and output the condition that satisfies and cycle Number of nodes for a single checkpoint persistence operation Control instructions; The collaborative synchronization module connects to the operation node reference interface of the operation queue management module. It includes a lightweight index generation unit and an atomic operation unit to realize resource allocation / release isolation and data block reference management. The checkpoint execution module receives instructions from the dynamic control module and persists data in batches at a period of T. To a consistent view of all operation nodes; The FoF emergency module responds to power outage signals. Force refresh of non-persistent operation nodes within the window; The crash recovery module loads a consistent view and checkpoint snapshot, and reconstructs the latest view through a verification mechanism and replay unit.

Images