A method and system for full system state persistence suitable for a library operating system

Abstract

The application discloses a kind of full-system state persistence method and system suitable for library operating system.The application is first configured and initialized to Unikernel virtual machine system;Secondly, the state of Unikernel virtual machine system is abstracted as a versioned object type set;Then, based on the object type set, a one-way linked list structure of superblock anchoring is used to implement incremental log management, and the object metadata and disk location are tracked and persisted by fixed-size log entries;Then, through the resource partition model, the management tasks of object metadata and disk location are offloaded to processor execution by asynchronous decoupling architecture, to realize core decoupling;Finally, external synchronization queue intercepts and delays the release of outgoing data packets, ensures that the system state is persisted after sending, and uses adaptive strategy to optimize performance.The application is linked to Unikernel as a library, and full-system persistence can be achieved without modifying the source code of application programs or third-party libraries.

Description

Technical Field

[0001] This invention relates to the field of computer system persistence and high availability technology, specifically to a method and system for persisting the entire system state of a library operating system. Background Technology

[0002] Unikernel is an emerging proprietary cloud and edge computing architecture that delivers superior performance and robust security isolation by compiling applications and their required operating system libraries into a minimal, single-address-space virtual machine image. However, the widespread adoption of Unikernel is currently hampered by a fundamental limitation: the lack of a high-frequency, low-latency persistence mechanism. Due to the inability to quickly save and restore system state, Unikernel is primarily limited to stateless applications, and its potential for demanding stateful services remains untapped.

[0003] In existing technologies, the most direct method for achieving virtual machine state persistence is to utilize the snapshot functionality of the underlying hypervisor, such as QEMU / KVM or VMware ESXi. However, these technologies are designed for coarse-grained operational tasks such as machine backups, and their architecture is optimized to minimize Service Time Objective (STO), i.e., user-facing application downtime, rather than Recovery Point Objective (RPO), i.e., the time required to create a complete, recoverable snapshot. Figure 1 As shown, persistence using QEMU's `migrate` command (a blocking, stop-and-copy full state serialization operation whose execution time represents the true RPO) incurs high overhead. To achieve a lower RPO, this mechanism forces applications to endure correspondingly high, cumulative STOs, leading to a significant drop in application throughput (e.g., taking only 10 snapshots can result in a 39.5% throughput decrease). Therefore, hypervisor-level snapshot technology cannot meet the needs of applications requiring millisecond-level RPO.

[0004] Another type of solution is process-level checkpointing tools, such as CRIU. These tools are designed for process migration and debugging, not for high-frequency fault tolerance. They typically lack robust guarantees for external synchronization, meaning they cannot ensure that the recovered system maintains a consistent view of its interactions with the external world (such as network clients). For example, the recovered system might "forget" that it has sent a network reply, leading to a violation of application-level protocols. Furthermore, its Recovery Point Objective (RPO) (averaging about 52 milliseconds) is still far higher than the millisecond-level requirement.

[0005] Academic research in the field of Single-Level Storage (SLS), such as Aurora and TreeSLS, has provided ideas for low-latency persistence, the core of which is to treat persistence as a memory management problem. However, these systems heavily rely on the underlying mechanisms of traditional operating systems (such as FreeBSD's VM objects and capability trees), which are absent in Unikernel's minimalist LibOS model. Furthermore, some previous designs were tightly coupled, lacked scalability, and struggled to support new libraries or state types without modification, contradicting Unikernel's extensible nature.

[0006] In summary, the existing technology has the following drawbacks:

[0007] 1. RPO is too high: The RPO of Hypervisor and process-level snapshots is in the tens of milliseconds to seconds, which cannot meet the requirements of millisecond-level state recovery;

[0008] 2. High performance overhead: To achieve low RPO, existing blocking snapshot methods introduce huge performance overhead, which seriously reduces application throughput;

[0009] 3. Lack of external synchronization guarantee: The recovered state may be inconsistent with its external interactions, leading to protocol errors;

[0010] 4. Incompatible with Unikernel architecture: Existing technologies such as SLS rely on the complex mechanisms of traditional OS and cannot be directly applied in the Unikernel environment, which lacks OS features;

[0011] 5. Insufficient scalability: Existing solutions cannot transparently support new libraries or data types, requiring modifications to application or library code, which undermines Unikernel's composability advantage.

[0012] Therefore, there is an urgent need in the field for a new persistence system designed specifically for Unikernel that can achieve millisecond-level RPO with extremely low overhead, guarantee external synchronization, and be completely transparent to applications and easily scalable. Summary of the Invention

[0013] This invention addresses the problems existing in the prior art by providing a method and system for persisting the entire system state of a library operating system.

[0014] In a first aspect, the present invention provides a method for persisting the entire system state of a library operating system, comprising the following steps:

[0015] Configure and initialize the Unikernel virtual machine system;

[0016] The Unikernel virtual machine system state is abstracted into a versioned set of object types;

[0017] Based on the set of object types, incremental log management is implemented using a superblock-anchored singly linked list structure, and object metadata and disk location are persistently tracked through fixed-size log entries.

[0018] Through the resource partitioning model, the asynchronous and decoupled persistence architecture offloads the management tasks of object metadata and disk location to a dedicated processor core for execution, thereby achieving decoupling from the core of the application.

[0019] The external synchronization queue ensures that the associated system state is persisted to the storage device before being sent by intercepting and delaying the release of outgoing data packets, and uses a frame access prediction algorithm and adaptive external synchronization to optimize performance.

[0020] Secondly, the present invention provides a system-wide state persistence system suitable for library operating systems, comprising:

[0021] The object type module is used to abstract the Unikernel virtual machine system state into a versioned collection of object types;

[0022] The log management module is used to implement incremental log management based on the set of object types, using a superblock-anchored singly linked list structure, and to persistently track object metadata and disk location through fixed-size log entries.

[0023] The asynchronous decoupled persistence module is used to offload the management tasks of object metadata and disk location to a dedicated processor core for execution through a resource partitioning model and an asynchronous and decoupled persistence architecture, thereby achieving decoupling from the core of the application.

[0024] The external synchronization queue module is used to ensure that the associated system state is persisted to the storage device before being sent by intercepting and delaying the release of outgoing data packets, and it adopts a frame access prediction algorithm and adaptive external synchronization to optimize performance.

[0025] The beneficial effects of this invention include:

[0026] Extremely low recovery point objective (RPO): Through an asynchronous, incremental persistence mechanism, a millisecond-level (1ms) RPO is achieved, reducing the potential data loss window from seconds to milliseconds, meeting the stringent requirements of high-frequency fault-tolerant scenarios;

[0027] Low performance overhead: The decoupled architecture offloads persistent I / O tasks to a dedicated core, minimizing interference with the application core. With external synchronization enabled, the throughput overhead for production-grade applications such as Redis and Nginx is only 15-20%.

[0028] Strong consistency guarantee: Through an external synchronization queue mechanism, it ensures that the recovered system state is consistent with the interactive view of the external world, avoids protocol violations, and provides crash consistency;

[0029] Transparency and Scalability: This invention is linked into Unikernel as a library, enabling system-wide persistence without modifying the application or third-party library source code. Through a stable object-based API, it easily supports new and unknown state types, exhibiting excellent scalability.

[0030] High security and robustness: The resource partitioning design establishes a robust fault and security boundary between the application and the persistence engine. Application failures will not destroy the persistent state, and vice versa, effectively forming a trusted isolation zone for critical services. Attached Figure Description

[0031] Figure 1 This refers to the persistence overhead that increases with the number of checkpoints when using the migrate command in QEMU.

[0032] Figure 2 The overall architecture of Libckpt and its integration method in Unikernel;

[0033] Figure 3 The layout of incremental logs on the storage device;

[0034] Figure 4 The complete workflow for the checkpoint cycle. Detailed Implementation

[0035] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and processes. However, the scope of protection of the present invention is not limited to the following implementation examples.

[0036] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0037] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0038] like Figure 2As shown, this invention provides a system-wide state persistence method suitable for library operating systems, and provides a Libckpt system library, comprising four main components: object-based state abstraction and logging, asynchronous supervisors and workers, a block SLS storage layer, and an external synchronization queue. Its core lies in an asynchronous, decoupled, object-based state persistence model. This library is linked when the Unikernel starts and achieves transparent, low-overhead persistence through the following technical solutions. Furthermore, without modifying application code, it provides a transparent checkpointing and recovery mechanism with millisecond-level Recovery Point Objectives (RPO) for the Unikernel virtual machine system. It can be widely applied to cloud-native and edge computing scenarios requiring high-frequency fault tolerance or high-fidelity security auditing, mainly solving the following technical problems:

[0039] (1) How to achieve millisecond-level recovery point target (RPO) without sacrificing the high performance and low latency characteristics of Unikernel.

[0040] (2) How to transparently capture and manage the entire system state (including memory, CPU registers, and device state) in a Unikernel environment that does not rely on traditional operating system mechanisms (such as page fault handling and process scheduling).

[0041] (3) How to ensure that the persistent state is consistent with the external interactions of Unikernel (such as network communication), that is, to ensure external synchronization and avoid protocol violations after recovery.

[0042] (4) How to provide a general and scalable architecture that can support new libraries and data types without modifying their source code.

[0043] To address the aforementioned technical problems, the present invention provides the following technical solution:

[0044] 1. Configure and initialize the Unikernel virtual machine system. The deployment environment of the Unikernel virtual machine system includes:

[0045] Hardware platform: Servers equipped with multi-core CPUs (such as Intel Xeon Silver 4214) and non-volatile memory (such as Intel Optane Persistent Memory).

[0046] Virtualization layer: Use QEMU (v8.2.8 and above) as the hypervisor to run the Unikernel virtual machine.

[0047] Unikernel Build: Builds a Unikernel image of the target application (such as Redis, Nginx) based on the Unikraft (v0.16.3 and above) framework. During the build process, the Libckpt library is linked into the final image.

[0048] Furthermore, in this application, Libckpt is initialized during the Unikernel startup process:

[0049] Resource reservation: Libckpt allocates a dedicated area from the physical memory reserved by the system for its internal use (such as log cache and metadata area).

[0050] Processor Binding: Depending on the configuration, one or more virtual CPU (vCPU) cores are exclusively allocated to Libckpt for use. One core is designated as the supervisor core, and the remaining cores (if any) are designated as worker cores.

[0051] Storage Initialization: Initialize the connection to the block SLS storage layer. In this embodiment, the storage layer is simulated by a 512MB virtual NVM (vNVM) device, which is created by the QEMU nvdimm backend and mounted to the Unikernel address space.

[0052] Log system initialization: Create or locate the superblock on the vNVM device and initialize the linked list of the log structure.

[0053] 2. Object-based system state abstraction

[0054] This invention abstracts the entire Unikernel system state into a set of versioned, typed objects, whose types include at least:

[0055] Data Object: Represents a physical memory page frame. Modifications are transparently tracked by setting page table entries (PTEs) to read-only using the page table mechanism. Write operations by the application will trigger page faults, thereby identifying the modified frame.

[0056] Registers Object: Represents the processor's state (such as general-purpose registers and instruction pointers), and is fully captured at each checkpoint cycle to ensure the consistency of the CPU context upon recovery.

[0057] Clock Object: Represents the system time, encapsulates specialized logic, and correctly reinitializes the system clock based on the persistent timestamp counter (TSC) value to ensure time consistency.

[0058] Virtual I / O Object: Represents the management state of a virtualized I / O device (such as a network interface card). It employs a "mark-and-capture" mechanism: When an application performs an operation that modifies the device state (e.g., commits a buffer to the device), the driver sets a dirty bit in the metadata to "mark" it; at checkpoints, the entire management structure of any marked virtual queues is "captured" as an object and persisted to ensure consistency between the client driver and the virtual device.

[0059] In this application, each object is identified by a globally unique key and versioned using a timestamp that includes a version number and a step number.

[0060] 3. Incremental, crash-consistent log structure

[0061] This invention employs an incremental log to manage object state changes. The log is a singly linked list of log blocks anchored by a superblock. Each log block contains a fixed-size log entry used to track the metadata of persisted objects and their location on disk.

[0062] like Figure 3 The diagram illustrates the detailed layout of the incremental log structure on the storage device, including the superblock, log block list, log entries, and the dual backup storage strategy for object data, as shown below:

[0063] Superblock: Stored in the vNVM area, it contains metadata such as a pointer to the head of the current active log list and the global version number;

[0064] Log Block: Contains a header (pointer to the next log block, checksum) and multiple fixed-size log entries.

[0065] Log Entry: Each entry corresponds to a persistent object instance, which contains its global key, timestamp, data length, and pointers to its two backup locations on block storage.

[0066] Furthermore, in this application, to ensure crash consistency, even on storage devices where atomic writes cannot be guaranteed, the present invention employs a dual backup strategy: each log block and the object data it points to have two copies. During recovery, the two copies are checked using checksums and timestamps to identify and use a uniquely valid version, thereby ensuring that the log is not corrupted by partial write operations. The superblock is placed in a byte-addressable virtual non-volatile memory (vNVM) region to avoid I / O bottlenecks during updates.

[0067] 4. Asynchronous and Decoupled Persistence Architecture

[0068] This invention employs a resource partitioning model to offload persistent tasks to a dedicated processor core for execution, decoupling them from the application core. The asynchronous and decoupled persistent architecture includes:

[0069] The oversight core is responsible for coordinating the entire checkpoint cycle. Its tasks include: pausing the application core by sending a nonmasked interrupt (NMI), collecting global state, processing the object list, and updating the log superblock.

[0070] Worker cores: One or more optional cores are responsible for persisting object data to the block storage layer in parallel, accelerating I / O-intensive phases.

[0071] In this application, the asynchronous and decoupled persistence architecture ensures that the core of the application maintains its uninterrupted, low-latency execution mode, while all expensive I / O and coordination tasks are handled in the background by a dedicated core, thereby achieving performance isolation.

[0072] In this application, the checkpoint is a core operation that is periodically performed by the invention, such as... Figure 4 The diagram illustrates the complete workflow of the checkpoint cycle, particularly the timing of collaborative and asynchronous operations between the regulator, workers, and application core. The specific steps are as follows:

[0073] (1) Processor initialization: After the system starts, the regulator core and worker core complete their own initialization, enter the idle state, and wait for the start of the first checkpoint cycle.

[0074] (2) Pause the application: When the predetermined checkpoint interval (determined by the TSC timer) is reached, the supervisor core broadcasts an unmaskable interrupt (NMI) to all vCPU cores running the application. Since the Unikernel disables most interrupts by default, the NMI can reliably and briefly pause the execution of all application threads.

[0075] (3) Capture local state: Each suspended application kernel captures its own register state and interrupt stack contents in its NMI handler.

[0076] (4) Capturing Global State: The supervisor core collects local state from all application cores. It then captures global state objects that do not belong to any single core, including:

[0077] Clock object: Reads and persists the current TSC value.

[0078] Virtual I / O Objects: Inspect all virtual queues (virtqueues) of Virtio devices, and capture the entire management structure metadata for queues that were previously "marked" as dirty.

[0079] Meanwhile, the monitor core iterates through the capture list to collect a list of all data objects (i.e. modified memory pages) that were set to write protection and triggered page faults in the previous cycle.

[0080] (5) Distribute objects: The supervisor core partitions the complete list of captured objects and distributes the object data blocks equally to itself and all available worker cores for processing.

[0081] (6) Resume Application: After all necessary states have been captured in Libckpt's memory space, the supervisor core sends a signal to the application core, causing it to exit the NMI handler and immediately resume execution. This concludes the synchronous "Stop-The-World" phase. This phase is extremely short (microseconds) because no I / O operations have yet occurred.

[0082] (7) Persistent object data (asynchronously): The supervisor core and worker core write their assigned object data to the block SLS storage layer in parallel. The data for each object is written to one of its two backup locations (the currently inactive copy).

[0083] (8) Persistent Log Blocks (Asynchronous): After all object data has been persisted (ensuring this through a synchronization barrier), the supervisor core and worker core commit the updated log blocks to the block SLS storage layer. Each log block is also written following a dual-backup strategy.

[0084] (9) Checkpoint Completion: After all data and log blocks have been persisted, the supervisor core atomically updates the log superblock to point to the head of the newly created log block list. This update marks the successful completion of the current checkpoint cycle, and the latest persisted state of the system takes effect. Subsequently, the external synchronization queue is notified to release all network packets waiting for this checkpoint completion. The worker core returns to the idle state, and the supervisor core waits for the next cycle to begin.

[0085] 5. External Synchronization Guarantee Mechanism

[0086] In this application, to ensure consistency between the system's interactive view with the external world, the present invention provides an external synchronization queue. This mechanism intercepts all outgoing network data packets and delays their release until the system state associated with these data packets is securely persisted to the storage device.

[0087] Specifically, in this application, when the Unikernel virtual machine system restarts after a failure, such as Figure 3 As shown, Libckpt performs the following recovery procedure:

[0088] (1) After initialization, Libckpt first accesses the superblock in vNVM to find the latest valid log chain.

[0089] (2) Starting from the header pointed to by the superblock, traverse each log block sequentially. For each block, check its two backups by checksum and select the valid one.

[0090] (3) Traverse each log entry in the log block. For each object key, the system maintains an in-memory hash table or B+ tree, always retaining the entry with the latest timestamp.

[0091] (4) For all the latest versions of the object, call its type-specific recover function to read the data from block storage into memory and restore it to its original location (such as registers, memory pages, device state).

[0092] (5) Once all objects have been restored, the application is reset to the last consistent checkpoint state and resumes execution from where it was interrupted.

[0093] Furthermore, to further optimize performance, this invention achieves this through the following two methods:

[0094] Frame Access Prediction Algorithm: This algorithm maintains a 64-bit key value for each physical page frame, encoding the recentity and frequency of its access (decay history). When dirty pages are added to the persistence queue, they are sorted according to this key value, prioritizing the persistence of "hot" pages, thereby significantly reducing the probability and duration of application pauses due to waiting for page persistence.

[0095] Adaptive External Synchronization: An adaptive strategy is introduced, setting a packet release threshold (e.g., 256 packets). During periods of high network traffic, outgoing packets accumulate in the queue. Once the number exceeds this threshold, the monitor core immediately initiates a new checkpoint cycle, instead of waiting for a fixed time interval. This dynamically adjusts the checkpoint frequency, decoupling network throughput from checkpoint latency under high network load, prioritizing throughput.

[0096] Based on the same concept as the above method embodiments, this application also proposes a system-wide state persistence system suitable for library operating systems, characterized in that it includes:

[0097] The object type module is used to abstract the Unikernel virtual machine system state into a versioned collection of object types;

[0098] The log management module is used to implement incremental log management based on the set of object types, using a superblock-anchored singly linked list structure, and to persistently track object metadata and disk location through fixed-size log entries.

[0099] The asynchronous decoupled persistence module is used to offload the management tasks of object metadata and disk location to a dedicated processor core for execution through a resource partitioning model and an asynchronous and decoupled persistence architecture, thereby achieving decoupling from the core of the application.

[0100] The external synchronization queue module is used to ensure that outgoing data packets are sent only after their associated system state has been persisted by intercepting and delaying their release, and to optimize performance using an adaptive strategy.

[0101] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of technical features, but should also cover other technical solutions formed by arbitrary combinations of technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A method for persisting the entire system state of a library operating system, characterized in that, Includes the following steps: Configure and initialize the Unikernel virtual machine system; The Unikernel virtual machine system state is abstracted into a versioned set of object types; Based on the set of object types, incremental log management is implemented using a superblock-anchored singly linked list structure, and object metadata and disk location are persistently tracked through fixed-size log entries. Through the resource partitioning model, the asynchronous and decoupled persistence architecture offloads the management tasks of object metadata and disk location to a dedicated processor core for execution, thereby achieving decoupling from the core of the application. The external synchronization queue intercepts and delays the release of outgoing data packets, ensuring that the associated system state is persisted to the storage device before being sent, and employs a frame access prediction algorithm and adaptive external synchronization to optimize performance. Each object in the aforementioned object type is identified by a globally unique key and is version-managed using a timestamp with a version number and a step number, including: Data objects: The page table mechanism is used to set page table entries to read-only, and page faults triggered by write operations are used to transparently trace the modified physical memory page frames; Register objects: Fully capture the CPU context during the checkpoint cycle to ensure recovery consistency; Clock object: Encapsulates logic that reinitializes the system clock using persistent timestamp counter values ​​to ensure time consistency; Virtual I / O objects: Employing a "mark-and-capture" mechanism, the driver marks dirty bits when the application modifies the device state; at checkpoints, the marked virtual queue management structure is persisted to ensure consistency between the driver and the virtual device; The asynchronous and decoupled persistence architecture ensures uninterrupted, low-latency application operation and achieves performance isolation by handling I / O and coordinating tasks through a dedicated background core. The asynchronous and decoupled persistence architecture includes: The core of the monitor is responsible for coordinating checkpoint cycles, pausing the application core by sending non-maskable interrupts, collecting global state, managing the object list and update log superblock; Worker core: Multi-core parallel writing of object data to block storage accelerates I / O performance; The checkpoint is the core mechanism for periodically synchronizing storage states, and its implementation steps include: Processor initialization: After the monitor core and worker core complete initialization, they enter an idle state, waiting for the checkpoint cycle to start; Suspend Application: The regulator core suspends the execution of all application threads via NMI interrupt; Capture local state: Each suspended application core saves register state and interrupt stack contents in the NMI handler; Capture global state: The monitor core collects the local state of the application core; Distribution of objects: After partitioning the object list, the core of the monitor distributes the object data blocks equally to itself and the worker cores for processing; Resume application: After the state capture is complete, the supervisor core notifies the application core to resume execution; Persistent object data: The supervisor core and worker core write object data to the block SLS storage layer in parallel; Persistent log blocks: After the object data is persisted, the log blocks are committed to the block SLS storage layer according to the dual backup strategy; Checkpoint complete: The checkpoint cycle is marked as complete by atomically updating the log superblock and notifying the external synchronization queue; The logging system includes: Superblock: Stored in the vNVM region, it contains the head pointer of the activity log list and global version number metadata; Log block: Consists of a header and multiple fixed-size log entries; Log entries: Each entry corresponds to a persistent object instance, containing a global key, timestamp, data length, and pointers to the dual backup locations of block storage; The frame access prediction algorithm uses a 64-bit key-value encoding to encode the access frequency and relevance of physical page frames, dynamically sorts dirty pages, prioritizes the persistence of frequently accessed "hot" pages, and reduces application downtime. The adaptive external synchronization triggers checkpoints through dynamic data packet thresholds, prioritizing throughput over fixed-interval synchronization under high load.

2. The method for persisting the entire system state of a library operating system according to claim 1, characterized in that, The deployment environment for the Unikernel virtual machine system includes: Hardware platform: Servers equipped with multi-core CPUs and non-volatile memory; Virtualization layer: QEMU is used as the hypervisor to run Unikernel virtual machines; Unikernel build: Build the Unikernel image using Unikraft and integrate the Libckpt library.

3. A method for persisting the entire system state of a library operating system according to claim 1 or 2, characterized in that, When the Unikernel virtual machine system starts, Libckpt initialization is performed, including the following steps: Resource reservation: Libckpt allocates a dedicated area in the system's physical memory for its own use; Processor binding: Allocate a vCPU core exclusively to the Libckpt; Storage initialization: Create a vNVM device via the QEMU nvdimm backend and mount it to the Unikernel address space to initialize the block SLS storage layer connection; Log system initialization: Create or locate the superblock on the vNVM device and initialize the linked list of the log structure.

4. The method for persisting the entire system state of a library operating system according to claim 3, characterized in that, The Libckpt procedure executes a recovery process when the Unikernel virtual machine system fails and restarts, including: During Libckpt initialization, it first reads the vNVM superblock to locate the latest log chain; Starting from the header pointed to by the superblock, check the two backups of each log block in turn, and select the valid backup after verifying the checksum; When the Unikernel virtual machine system traverses log entries in a log block, it maintains an in-memory data structure for each object key and only retains the entry with the latest timestamp. The Unikernel virtual machine system calls the recover function corresponding to the object type to read data from block storage and restore it to its original location in memory.

5. A system-wide state persistence system suitable for library operating systems, used to implement the method of claim 1, characterized in that, include: The object type module is used to abstract the Unikernel virtual machine system state into a versioned collection of object types; The log management module is used to implement incremental log management based on the set of object types, using a superblock-anchored singly linked list structure, and to persistently track object metadata and disk location through fixed-size log entries. The asynchronous decoupled persistence module is used to offload the management tasks of object metadata and disk location to a dedicated processor core for execution through a resource partitioning model and an asynchronous and decoupled persistence architecture, thereby achieving decoupling from the core of the application. The external synchronization queue module is used to ensure that the associated system state is persisted to the storage device before being sent by intercepting and delaying the release of outgoing data packets, and to optimize performance using an adaptive strategy.

Images