Data storage method, device and equipment under system power failure and readable medium

Abstract

The invention relates to a data storage method, device and equipment under system power failure and a readable medium. The method comprises the following steps: writing user data in an application layer into a reserved memory of a system kernel in a memory mapping manner in a system running process; directly writing the user data in the reserved memory into a target partition of the storage device through a target kernel thread created in a system kernel under the condition that the system power-down trigger interruption is detected; the target partition is a storage partition which is pre-divided in the storage device, is not subjected to file system formatting and is specially used for power-down data storage. According to the application, a data writing demand is directly undertaken through the kernel layer, a multi-level redundancy process of notification of the application layer and forwarding of the file system layer is skipped, the path time consumption of data from temporary storage to writing into the storage device is shortened, reliable data storage is ensured to be completed in a power supply maintenance window period after power failure, and the reliability of data storage is improved. The technical problem of storage failure easily caused by a multi-stage flow of data storage after power failure is solved.

Description

Technical Field

[0001] This application relates to the field of computer operating system technology, and in particular to a method, apparatus, device and readable medium for data storage when the system is powered off. Background Technology

[0002] In the field of computer operating system technology, it is often necessary to save critical user data to eMMC storage devices when power is lost in Linux systems.

[0003] In related technologies, after a power failure triggers a GPIO interrupt, the application layer is notified via an asynchronous notification mechanism. The application layer then calls a save function, and the data is written to the EMMC through multiple levels, including the file system layer, block device layer, MMC core layer, and driver layer. This process involves multiple interactions between the application layer and the kernel layer, multi-level data forwarding, and parallel processing of non-critical requests, resulting in a long total time from triggering the save function to finally writing the data to the EMMC. When the power supply voltage is maintained for a short period after a power failure, data saving failures are likely to occur.

[0004] There is currently no effective solution to the problem that the multi-level data saving process after power failure is prone to saving failure. Summary of the Invention

[0005] This application provides a method, apparatus, device, and readable medium for data storage during system power failure, in order to solve the technical problem that the multi-level process of data storage after power failure is prone to storage failure.

[0006] According to one aspect of the embodiments of this application, this application provides a data saving method under system power failure, including: during system operation, writing user data in the application layer into the reserved memory of the system kernel through memory mapping; when a system power failure triggers an interrupt, writing the user data in the reserved memory directly into a target partition of the storage device through a target kernel thread created in the system kernel; the target partition is a storage partition pre-allocated in the storage device, which is not formatted with a file system and is dedicated to saving data under power failure.

[0007] Optionally, the system kernel is a system kernel with full real-time mode enabled or with real-time patches installed; the target kernel thread is created in the driver layer of the system kernel, the target kernel thread has the highest priority, and the target kernel thread is bound to the target kernel, so that the target kernel is dedicated to running the target kernel thread.

[0008] Optionally, before directly writing the user data retained in memory to the storage device, the method further includes: determining the device node of the storage device in the device tree of the system kernel; detecting the speed mode of the storage device at the device node of the storage device; and modifying the speed mode of the storage device to the highest speed mode if the speed mode is not configured in the highest speed mode.

[0009] Optionally, user data in reserved memory can be directly written to the target partition of the storage device through a target kernel thread created in the system kernel. This includes: reading user data from reserved memory through the target kernel thread and determining the partition identifier of the target partition in the storage device at the block device layer of the system kernel; and writing the user data to the target partition in the storage device for storage, carrying the partition identifier of the target partition.

[0010] Optionally, in the event of a system power failure triggering an interrupt, the method further includes: when the MMC core layer of the system kernel receives a request for data flow to pass, obtaining the storage area identifier of the storage area requested by the data flow; and if the storage area identifier is not the partition identifier of the target partition, intercepting the data flow.

[0011] Optionally, in the event of a system power failure triggering an interrupt, the method further includes: when the MMC driver layer of the system kernel receives a request to pass through the request queue, obtaining the storage area identifier of the storage area requested by the request queue; and if the storage area identifier is not the partition identifier of the target partition, intercepting the request queue.

[0012] Optionally, before directly writing user data stored in memory to the storage device through the MMC driver layer of the system kernel, the method further includes: configuring the block size of the MMC driver layer when the system is powered on, so that the amount of data written to the storage device is less than a preset data amount threshold.

[0013] According to another aspect of the embodiments of this application, this application provides a data storage device under system power failure, including: a kernel temporary storage module, used to write user data in the application layer into the reserved memory of the system kernel through memory mapping during system operation; a kernel writing module, used to directly write the user data in the reserved memory into a target partition of the storage device through a target kernel thread created in the system kernel when an interrupt is detected due to system power failure; the target partition is a storage partition pre-divided in the storage device and not formatted with a file system, dedicated to saving data under power failure.

[0014] According to another aspect of the embodiments of this application, this application provides an electronic device, including a memory, a processor, a communication interface and a communication bus. The memory stores a computer program that can run on the processor. The memory and the processor communicate with each other through the communication bus and the communication interface. When the processor executes the computer program, it implements the steps of the above method.

[0015] According to another aspect of the embodiments of this application, this application also provides a computer-readable medium having processor-executable non-volatile program code that causes the processor to perform the above-described method.

[0016] Compared with related technologies, the technical solutions provided in this application have the following advantages: This application provides a data preservation method under system power failure, comprising: during system operation, writing user data from the application layer into reserved memory of the system kernel via memory mapping; and, upon detecting a system power failure triggering an interrupt, directly writing the user data from the reserved memory into a target partition of the storage device via a target kernel thread created in the system kernel; the target partition is a pre-allocated storage partition in the storage device, not formatted with a file system, dedicated to power failure data preservation. This application directly handles data writing requirements at the kernel layer, skipping the multi-level redundant processes of application layer notification and file system layer forwarding, shortening the path time from temporary storage to writing to the storage device, ensuring reliable data storage within the power supply maintenance window after a power failure, and solving the technical problem that the multi-level data preservation process after a power failure easily leads to preservation failure. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram illustrating the process of saving user data to an EMMC storage device when a Linux system loses power in the existing technology. Figure 2 This is a schematic flowchart of an optional data saving method under system power failure according to an embodiment of this application; Figure 3 This is a schematic diagram illustrating an optional process for saving user data to an EMMC storage device when a Linux system loses power, according to an embodiment of this application. Figure 4 This is a block diagram of an optional data storage device under system power failure according to an embodiment of this application; Figure 5 This is a schematic diagram of an optional electronic device structure provided in an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, 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.

[0021] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustration and has no specific meaning in itself. Therefore, "module" and "part" may be used interchangeably.

[0022] In related technologies, after a power failure triggers a GPIO interrupt, the application layer is notified via an asynchronous notification mechanism. The application layer then calls a save function, and the data is written to the EMMC through multiple levels, including the file system layer, block device layer, MMC core layer, and driver layer. Specifically, for example... Figure 1 As shown, when the system loses power, a GPIO interrupt is triggered. Linux enters the GPIO interrupt handler and then uses an asynchronous notification mechanism to trigger the SIGIO signal to notify the application layer. Upon receiving this signal, the application layer calls the power-down save function, which saves the specified length of critical data to the EMMC as a file using a write function. The written data enters the Linux Kernel, passes through the file system layer, block device layer, MMC kernel layer, and MMC driver layer, and is finally written to the EMMC storage device.

[0023] This process involves multiple interactions between the application layer and the kernel layer, multi-level data forwarding, and parallel processing of non-critical requests, resulting in a long total time from triggering data saving to finally writing data to the EMMC. When the power supply voltage is maintained for a short time after a power failure, data saving failure is likely to occur.

[0024] To address the problems mentioned in the background art, according to one aspect of the embodiments of this application, an embodiment of a data retention method under system power failure is provided, which can be applied to systems including but not limited to Linux, Windows, Android, and iOS. This application embodiment uses a Linux system as an example for illustration.

[0025] One data saving method under system power failure in this application embodiment can be executed by the system kernel, such as... Figure 2 As shown, the method may include the following steps: Step S202: During system operation, user data in the application layer is written into the reserved memory of the system kernel through memory mapping; Step S204: When a system power failure triggers an interrupt, the user data in the memory is directly written to the target partition of the storage device through the target kernel thread created in the system kernel. The target partition is a storage partition in the storage device that is pre-allocated and not formatted with a file system, and is dedicated to saving data in case of power failure.

[0026] In this embodiment, the application layer is the software layer in the computer system that directly interacts with the user. It includes various user applications, is responsible for receiving user operation instructions and processing related business logic, and is the layer where user data is generated and data storage requests are initiated. Memory mapping is a memory management technique. In this application, by establishing a mapping relationship between the virtual address space of the application layer and the physical address space of the kernel layer's reserved memory, the application layer can directly read and write to the kernel's reserved memory without having to copy data through traditional system calls, thus improving data transmission efficiency. The system kernel refers to the core component of the operating system, responsible for managing the system's hardware resources, such as memory, CPU, and storage devices, and providing core services such as process scheduling and interrupt handling. Reserved memory refers to a memory area that is pre-allocated and locked during system kernel initialization. This area is independent of the memory space accessible to ordinary applications and is only used for temporary storage of specific critical data, such as power-down data, to prevent it from being occupied or interfered with by other programs. Power-down triggered interrupt refers to the hardware sending an interrupt signal to the CPU when the system detects an abnormal drop in the power supply voltage, forcing the CPU to suspend the currently executing task and instead execute a preset interrupt handler to cope with power-down scenarios. The target kernel thread is a kernel thread specifically created in the system kernel's MMC driver layer, dedicated solely to performing power-down data saving tasks. Unlike ordinary application threads, kernel threads run directly in kernel space, eliminating the need for switching between user and kernel modes. This target kernel thread has the highest priority and is bound to the target kernel, ensuring that the target kernel thread runs exclusively on that kernel. The MMC driver layer is the driver layer within the system kernel responsible for hardware interaction with MMC (Multimedia Card) type storage devices (such as eMMC), providing low-level interfaces for data reading / writing and device control, directly interfacing with the physical layer operations of the storage device. The target kernel is a pre-defined CPU core specifically designed to run the target kernel thread. This core avoids the system's default interrupt handling core and other critical service threads as much as possible, reducing CPU resource contention and improving the execution efficiency of the data saving task. The storage device can be a flash-based embedded storage medium used for long-term data storage. The target partition is a pre-partitioned, unformatted partition in the eMMC storage device specifically designed to store critical user data during power failure. This partition is not formatted and can skip the Linux kernel's file system layer, avoiding the time-consuming parsing and forwarding of the file system layer. Data can be written directly through the block device layer, reducing the time spent on kernel layer operations.

[0027] In this embodiment, during normal system operation, the allocation and configuration of reserved memory must first be completed in the system kernel. During kernel initialization, a fixed-size physical memory is designated as reserved memory by modifying the kernel configuration file or device tree parameters. This reserved memory is marked as kernel-exclusive and accessed by ordinary applications is prohibited. The application layer initiates a memory mapping request to the kernel by calling the memory mapping interface provided by the system, such as the mmap() function in Linux. After receiving the request, the kernel establishes a one-to-one mapping relationship between a virtual address of the application layer and the physical address of the reserved memory, and returns the mapped virtual address to the application layer. After obtaining the virtual address, the application layer can directly write the generated critical user data into the corresponding kernel reserved memory without using traditional system calls such as write() (traditional calls require multiple steps of copying from the application layer buffer to the kernel buffer to the storage device). During the data writing process, due to the directness of memory mapping, the data does not need to be copied additionally and is directly stored in the physical address space of the reserved memory.

[0028] In this embodiment, when the system power supply is abnormal, and the hardware detection module, such as the power management chip, detects that the supply voltage is lower than a preset threshold, it immediately sends a GPIO interrupt signal to the CPU, triggering a power-down interrupt. Upon receiving the interrupt signal, the CPU suspends the currently executing application-layer tasks and non-critical kernel tasks and starts the power-down interrupt handler. The interrupt handler triggers the kernel-layer data writing process, whereby the target kernel thread directly accesses the kernel reserved memory through the low-level read / write interface provided by the MMC driver layer, reading the temporarily stored user data. Since the reserved memory already stores complete critical user data, it is unnecessary to retrieve it from the application layer. After the data reading is complete, the target kernel thread establishes communication directly with the physical layer of the storage device through the MMC driver layer, and writes the read user data to the target partition of the storage device in blocks according to the transmission protocol supported by the storage device. Throughout this process, the data transmission path is kernel reserved memory → MMC driver layer → storage device, skipping the multi-level redundant processes of application-layer notification → file system layer parsing → block device layer forwarding in traditional methods, greatly shortening the time it takes for data to go from temporary storage to writing to the storage device.

[0029] Through steps S202 to S204, this application directly undertakes data writing requirements through the kernel layer, skipping the multi-level redundant process of application layer notification and file system layer forwarding, shortening the path time of data from temporary storage to writing to the storage device, ensuring reliable data storage within the power supply maintenance window after power failure, and solving the technical problem that the multi-level process of data saving after power failure is prone to cause saving failure.

[0030] In this embodiment, the system kernel is a system kernel with full real-time mode enabled or with real-time patches installed. Full real-time mode can be enabled during system kernel configuration, or real-time patches can be installed. Specifically: Step 1: When configuring the system kernel, detect the system kernel's running mode; Step 2: If the system kernel is running in non-real-time mode, switch the system kernel to full real-time mode. Alternatively, download the real-time patch corresponding to the current system kernel from the preset patch database and install the real-time patch to set the system kernel to full real-time mode. The interrupt latency of the system kernel in full real-time mode is less than the interrupt latency of the system kernel in non-real-time mode.

[0031] In this embodiment, the system kernel's operating mode refers to the kernel's task scheduling and interrupt handling mode, mainly divided into full real-time mode and non-real-time mode. The kernel's response speed to interrupt requests and process scheduling priority strategies differ between these modes. Full real-time mode, also known as fully preemptible kernel mode, allows the kernel to pause the currently executing task and immediately switch to the higher-priority task at any time it receives a higher-priority task request, ensuring the timeliness of critical task responses. Real-time patches are patches developed for non-real-time kernels. By modifying the kernel's process scheduling mechanism and interrupt handling logic, they enable the non-real-time kernel to possess the core characteristics of real-time mode, achieving real-time transformation without recompiling the entire kernel. Interrupt latency refers to the time interval between the generation of an interrupt signal by the hardware and the execution of the first instruction of the corresponding interrupt handler by the CPU. It is a key indicator for measuring the system's response speed to sudden events; the shorter the interrupt latency, the stronger the system's ability to cope with emergency scenarios (such as power outages).

[0032] In this embodiment, before writing application-layer data to kernel-reserved memory, the system kernel can be configured first. Specifically, the current kernel's operating mode is detected. This detection can be achieved through system interfaces provided by the kernel or by reading kernel status files. Taking Linux as an example, the contents of the ` / proc / sys / kernel / preempt` file can be read. If the file content is "2", it indicates the kernel is currently in full real-time mode; if it is "1" (voluntary preemption mode) or "0" (non-preemption mode), it is determined to be in non-real-time mode. Alternatively, the kernel API function `preempt_count()` can be called to assist in the determination based on the returned preemption count status. The dynamic adjustment logic of the preemption count in full real-time mode differs significantly from that in non-real-time mode. The detection process is executed by the kernel initialization script or a dedicated system configuration tool, completing mode verification before application-layer data processing begins, thus avoiding interrupt response delays due to kernel mode issues during subsequent power outages.

[0033] In this embodiment of the application, if the kernel is detected to be in non-real-time mode, it is configured to full real-time mode in one of the following two ways: Method 1: Directly switch kernel execution mode. This method is suitable for scenarios where the kernel itself is compiled to support full real-time mode but is not enabled by default. It triggers the kernel execution mode switch by modifying dynamic kernel configuration parameters. For example, in Linux systems, the kernel preemptive mode can be set to full real-time mode by executing the command `echo 2> / proc / sys / kernel / preempt`. This command modifies the kernel's global preemption control variable through a system call. Once the kernel detects the change, it automatically adjusts the process scheduling policy and interrupt handling mechanism, taking effect without requiring a system reboot.

[0034] Method 2: Install Real-Time Patches. This is suitable for scenarios where the kernel is not compiled to support full real-time mode. Specifically, first, obtain the current system kernel version number using the system's hardware information query tool. Access the preset patch database, which can be the official patch server provided by the system vendor or a real-time patch repository from the open-source community. Retrieve the corresponding real-time patch file based on the kernel version number and CPU model. Obtain the real-time patch file using a download tool such as wget and save it to the kernel source code directory. Execute the patch installation command to apply the real-time patch to the current kernel source code. The patch installation process automatically modifies critical code such as the kernel's process scheduling module and interrupt handling module, adding the functional logic required for full real-time mode. After the patch installation is complete, recompile the kernel and restart the system to make the new real-time kernel effective.

[0035] This application significantly reduces the response latency of power failure interrupts by detecting the kernel running mode and configuring it to full real-time mode. This enables the system to start the data saving process faster after a power failure event, allowing more time for data to be written from kernel-retained memory to storage devices, and further improving the reliability of power failure data saving.

[0036] In an optional embodiment, before directly writing the user data retained in memory to the storage device, the method further includes: Step 1: Determine the device node of the storage device in the system kernel's device tree; Step 2: At the device node of the storage device, detect the speed mode of the storage device; Step 3: If the speed mode is not configured to the highest speed mode, change the speed mode of the storage device to the highest speed mode.

[0037] In this embodiment, the kernel device tree refers to a structured data file describing hardware platform information, used to inform the system kernel of the current hardware configuration. A device node refers to the node structure in the device tree used to describe a single hardware device. Each device node contains information such as the device's identifier, compatibility attributes, register address, and operating parameters, serving as the basis for the kernel to identify and configure hardware devices. MMC storage devices correspond to independent device nodes in the device tree. The speed mode refers to the operating speed configuration mode of the MMC storage device. Different speed modes correspond to different data transmission bandwidths and clock frequencies; the higher the speed mode, the faster the data read / write speed.

[0038] In this embodiment of the application, before writing user data stored in memory to the storage device, the speed mode of the storage device can be set to the highest speed mode to provide a faster write rate.

[0039] In this embodiment, firstly, the device tree file loaded by the system kernel is searched, and the device node of the storage device is located based on the device identifier of the storage device. After locating the device node of the storage device, the speed mode parameters of the device tree node can be read directly, or the actual operating speed mode of the storage device can be queried through system tools. If it is detected that the current speed mode is not configured as the highest speed mode, the device tree node parameters are modified to adjust and enable the highest speed mode.

[0040] This application, by configuring the storage device in the device tree at its highest speed, fully utilizes the hardware performance of the storage device and the CPU controller, significantly improving the data writing rate to the storage device, shortening the data transmission time between the MMC driver layer and the storage device, and further ensuring that data can be saved within the power supply maintenance window in the event of a power failure.

[0041] The following is combined with Figure 3 This application will now describe the data saving method provided for the system during power failure.

[0042] In an optional embodiment, user data held in memory is directly written to a target partition of the storage device via a target kernel thread created in the system kernel, including: Step 1: Read user data from reserved memory through the target kernel thread and determine the partition identifier of the target partition in the storage device at the block device layer of the system kernel; Step 2: Carrying the partition identifier of the target partition, write the user data to the target partition in the storage device for storage.

[0043] In this embodiment, when the system loses power, a target kernel thread for power-down data saving is created in the MMC driver layer of the system kernel, and its priority and CPU core binding are configured. Specifically, the target kernel thread is created using the `kthread_create()` function provided by the Linux kernel. After the thread is created, it is bound to the target core using the `kthread_bind()` function. The principle for selecting the target core is to avoid the system's default interrupt handling core (such as CPU0 core, as most system interrupts are assigned to CPU0 by default). For example, CPU1 core is selected as the target core. The CPU affinity of the thread is set using the `set_cpus_allowed_ptr()` function, restricting the thread to run only on CPU1 core. The priority of the target kernel thread is set to the highest priority using the `set_user_nice()` function or the `sched_setscheduler()` function, so that the thread can preferentially preempt the resources of CPU1 core and immediately execute the data saving task when power fails.

[0044] In this embodiment, the target kernel thread can be created when the system loses power or it can be created in advance. After the power failure interrupt is triggered, the target kernel thread is woken up, which further reduces the time spent saving power failure data.

[0045] In the embodiments of this application, such as Figure 3 As shown, the target kernel thread directly accesses the kernel's reserved memory using the pre-passed reserved memory address parameter and reads the temporarily stored user data. Since the reserved memory already stores the complete user data through memory mapping, and the kernel thread runs directly in kernel space, the data reading process does not require copying and the raw data can be obtained directly. Simultaneously, the target kernel thread queries the partition identifier of the target partition at the system kernel's block device layer. First, it obtains the partition table information of the storage device using its device identifier, such as mmcblk0. The partition table records information such as the starting address, size, and partition number of each partition. Based on the pre-configured target partition information, such as the target partition's partition number being 2, corresponding to / dev / mmcblk0p2, it extracts the identifier information of the target partition from the partition table.

[0046] The target kernel thread organizes the read user data into data blocks recognizable by the block device layer. It then initiates a data write request through the block device layer interface, carrying information such as the starting address of the target partition, the data block size, and the data content. Since the target partition is not formatted with a file system, the data skips the file system layer and enters the block device layer directly. After performing simple block management on the data write request, the block device layer forwards the request to the MMC core layer. The MMC core layer performs protocol adaptation and request queue management before forwarding the request to the MMC driver layer. Based on the target partition identifier and data information in the request, the MMC driver layer communicates with the physical layer of the eMMC storage device to directly write the data block to the corresponding address of the target partition, completing the data storage.

[0047] This application ensures the priority execution of power-down data saving tasks by creating a target kernel thread with the highest priority and binding it to an independent CPU core, thus avoiding CPU resource contention. At the same time, by writing data directly to a dedicated target partition, it skips the redundant process of the file system layer, which greatly improves the execution efficiency and reliability of data saving.

[0048] In an optional embodiment, when a system power failure triggers an interrupt, the method further includes: Step 1: When the MMC core layer of the system kernel receives a request for the data stream to pass through, obtain the storage area identifier of the storage area that the data stream requests to access. Step 2: If the storage area identifier is not the partition identifier of the target partition, intercept the data stream.

[0049] In this embodiment, the MMC core layer is the core subsystem layer in the system kernel responsible for managing MMC-type devices. It is located between the block device layer and the MMC driver layer. Its main functions include request queue management, data transmission protocol processing, and device status monitoring. It is the core scheduling layer for MMC device data transmission.

[0050] In this embodiment of the application, when a data write request initiated by the target kernel thread is forwarded through the block device layer and enters the MMC core layer, such as... Figure 3As shown, the MMC core layer receives the request through the `mmc_mq_queue_rq()` function. `mmc_mq_queue_rq()` is the core function of the MMC core layer for handling block device layer requests; all data stream requests for MMC storage devices must enter the core layer for processing through this function. The request parameters received by this function include a `struct request` structure, which encapsulates key information such as the target storage area identifier (e.g., partition number, starting address), data length, and data buffer address. The MMC core layer obtains the core information of the request by parsing this structure. After receiving the data stream request, the MMC core layer first extracts the storage area identifier from the `struct request` structure and compares it with the pre-configured target partition identifier, such as "mmcblk0p2", to determine if the request is for accessing the target partition. If the storage area identifier and the target partition identifier do not match, it is confirmed that the request is a normal request initiated by another application to access a non-target partition. Therefore, the data stream is intercepted to ensure that the processing resources of the MMC core layer can focus on processing target requests for power-down data saving.

[0051] Optionally, if the storage area identifier matches the partition identifier of the target partition, the data flow is allowed to pass through the MMC core layer. That is, if the storage area identifier matches the target partition identifier, it is confirmed that the request is the target request for power-down data saving, and the data flow is allowed to pass through the MMC core layer. After the MMC core layer performs protocol adaptation, data verification, and other processing on the request, it forwards the request to the MMC driver layer.

[0052] The above interception logic can be implemented by modifying the code of the mmc_mq_queue_rq() function. The interrupt flag can be used to determine whether it is in a power failure scenario, so that the interception logic of the modified mmc_mq_queue_rq() function only takes effect in the power failure scenario.

[0053] This application achieves the interception of non-target partition requests by modifying the mmc_mq_queue_rq() function in the MMC core layer, which reduces the number of requests processed and the load in the core layer, avoids ordinary requests occupying core layer resources, ensures that target requests for saving data after power failure can quickly pass through the core layer, and further shortens the total data transmission time.

[0054] In an optional embodiment, when a system power failure triggers an interrupt, the method further includes: Step 1: When the MMC driver layer of the system kernel receives a request to pass through the request queue, obtain the memory area identifier of the memory area requested by the request queue. Step 2: If the storage area identifier is not the partition identifier of the target partition, intercept the request queue.

[0055] In this embodiment of the application, after the request forwarded by the MMC core layer enters the MMC driver layer, it is first added to the request queue of the driver layer. For example... Figure 3 As shown, the MMC driver layer retrieves requests from the request queue for processing through functions such as `phytium_mci_ops_request()`. This function is the core entry point for the interaction between the driver layer and the hardware, responsible for parsing requests and controlling the MMC controller to execute corresponding hardware operations. After retrieving a single request from the request queue, the MMC driver layer's `request()` function parses the relevant parameters of the request, obtains the storage area identifier, and determines whether the current request is for accessing the target partition in the storage device based on the storage area identifier. If the storage area identifier and the target partition identifier are inconsistent, the request is confirmed as a normal request, and the request queue is intercepted, ensuring that the processing resources of the MMC driver layer can focus on processing target requests for power-down data saving.

[0056] Optionally, if the storage area identifier matches the partition identifier of the target partition, the request queue is allowed to pass through the MMC driver layer. That is, if the storage area identifier matches the preset target partition identifier, it is confirmed that the request is a power-down data preservation request, and the request queue is allowed to pass through the MMC driver layer. The request function of the driver layer parses the request into control signals that the MMC controller can recognize, and sends these signals to the EMMC storage device through the CPU's MMC controller interface, controlling the physical layer of the storage device to perform a data write operation and save the data to the target partition.

[0057] The above interception logic can be implemented by modifying the code of the request function. The interrupt flag can be used to determine whether there is a power failure scenario, so that the interception logic of the modified request function only takes effect in the power failure scenario.

[0058] This application modifies the request function at the MMC driver layer to intercept request queues from non-target partitions, reducing the number of hardware operations at the driver layer and invalid accesses to the storage device. This avoids ordinary requests consuming hardware resources, ensures that power-down data saving requests can quickly trigger physical layer write operations on the storage device, and further shortens the hardware time consumption for data saving.

[0059] If the system loses power while the eMMC hardware layer is performing other large data writes, and a power failure interrupt occurs at this time, requesting to save the file to the eMMC, then it must wait for the large data writes to complete before writing the power-loss file data can be performed. The larger the data volume, the longer the time required. If the time exceeds the range maintained by the power-loss voltage, it will cause the power-loss file saving to fail. Therefore, this application can also pre-configure the block size written to the eMMC to an appropriate value to reduce the time spent writing a block of data, thereby reducing the time when the eMMC returns an interrupt.

[0060] In an optional embodiment, before directly writing user data held in memory to the storage device via the system kernel's MMC driver layer, the method further includes: When the system is powered on, the block size of the MMC driver layer is configured so that the amount of data written to the storage device is less than the preset data size threshold.

[0061] Specifically: Step 1: When the system is powered on, obtain the block size configuration data of the MMC driver layer. The block size configuration data is used to limit the amount of data written to the storage device. The larger the block size, the more data is written to the storage device, and the longer it takes to write a piece of data to the storage device. Step 2: If the block size of the MMC driver layer is determined to be greater than the preset data volume threshold based on the block size configuration data, modify the block size configuration data to make the block size less than the preset data volume threshold.

[0062] In this embodiment, during the system power-on initialization phase, after the MMC driver layer is loaded, the driver obtains the current configuration value of the `max_req_size` parameter by reading kernel configuration parameters or relevant attributes in the device tree. The `max_req_size` parameter is a global variable defined in the MMC driver layer, used to limit the maximum data block size of a single write request; the default configuration value is typically 512KB. After obtaining the current block size configuration data, it is compared with a preset data volume threshold, and the configuration is modified based on the comparison result. The maximum block size that ensures a single write operation can be completed within the maintenance window period can be calculated by combining the hardware characteristics of the storage device and the power supply maintenance time after a system power failure; this is the preset data volume threshold. The currently obtained `max_req_size` value (e.g., the default 512KB) is compared with the preset data volume threshold (64KB). If the current block size (512KB) is greater than the preset threshold (64KB), the block size configuration needs to be modified. After modification, all subsequent data write requests initiated by the driver layer will be divided into data blocks according to the modified block size, and the time spent writing a single data block is controlled within a preset range.

[0063] This application adjusts the block size configuration of the MMC driver layer when the system is powered on, thereby controlling the time spent on a single data write within a reasonable range, avoiding the problem of long return interruption time caused by excessively large block size, and further shortening the data storage time.

[0064] This application directly undertakes data writing requirements at the kernel layer, skipping the multi-level redundant process of application layer notification and file system layer forwarding, shortening the path time of data from temporary storage to writing to the storage device, ensuring reliable data storage within the power supply maintenance window after power failure, and solving the technical problem that the multi-level process of data saving after power failure is prone to saving failure.

[0065] According to another aspect of the embodiments of this application, such as Figure 4 As shown, a data storage device for system power failure is provided, comprising: The kernel temporary storage module 401 is used to write user data from the application layer into the reserved memory of the system kernel through memory mapping during system operation. The kernel write module 403 is used to write user data stored in memory directly to the target partition of the storage device through the target kernel thread created in the system kernel when an interrupt is detected due to a system power failure. The target partition is a storage partition in the storage device that is pre-allocated and not formatted with a file system, and is dedicated to saving data in case of power failure.

[0066] It should be noted that the kernel temporary storage module 401 in this embodiment can be used to execute step S202 in this application embodiment, and the kernel writing module 403 in this embodiment can be used to execute step S204 in this application embodiment.

[0067] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should also be noted that the above modules, as part of the device, can be implemented in software or hardware.

[0068] Optionally, the system kernel is a system kernel with full real-time mode enabled or with real-time patches installed; the target kernel thread is created in the driver layer of the system kernel, the target kernel thread has the highest priority, and the target kernel thread is bound to the target kernel, so that the target kernel is dedicated to running the target kernel thread.

[0069] Optionally, the data storage device under power failure of the system further includes a storage device mode configuration module, specifically used for: determining the device node of the storage device in the device tree of the system kernel before directly writing the user data in the memory to the storage device; detecting the speed mode of the storage device at the device node of the storage device; and modifying the speed mode of the storage device to the highest speed mode if the speed mode is not configured in the highest speed mode.

[0070] Optionally, the kernel write module is specifically used to: read user data from reserved memory through the target kernel thread, and determine the partition identifier of the target partition in the storage device at the block device layer of the system kernel; and write the user data to the target partition in the storage device for storage, carrying the partition identifier of the target partition.

[0071] Optionally, the data storage device under power failure of the system also includes an interception module, specifically used for: when a power failure triggers an interrupt, when the MMC core layer of the system kernel receives a request for data flow to pass, obtaining the storage area identifier of the storage area requested by the data flow; and if the storage area identifier is not the partition identifier of the target partition, intercepting the data flow.

[0072] Optionally, the interception module is further configured to: when a system power failure triggers an interrupt, and the system kernel's MMC driver layer receives a request to pass through the request queue, obtain the storage area identifier of the storage area requested by the request queue; and if the storage area identifier is not the partition identifier of the target partition, intercept the request queue.

[0073] Optionally, the data storage device under power failure of the system also includes a driver layer block size configuration module, which is specifically used to: configure the block size of the MMC driver layer when the system is powered on, so that the amount of data written to the storage device is less than a preset data amount threshold.

[0074] According to another aspect of the embodiments of this application, this application provides an electronic device, such as... Figure 5 As shown, the system includes a memory 501, a processor 503, a communication interface 505, and a communication bus 507. The memory 501 stores a computer program that can run on the processor 503. The memory 501 and the processor 503 communicate through the communication interface 505 and the communication bus 507. When the processor 503 executes the computer program, it implements the steps of the above method.

[0075] The memory and processor in the aforementioned electronic devices communicate with each other via a communication bus and a communication interface. The communication bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into an address bus, a data bus, a control bus, etc.

[0076] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0077] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0078] According to another aspect of the embodiments of this application, a computer program product or computer program is also provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps of any of the above embodiments.

[0079] Optionally, in embodiments of this application, the computer-readable medium is configured to store program code for the processor to perform the following steps: During system operation, user data in the application layer is written to the reserved memory of the system kernel through memory mapping; When a system power failure triggers an interrupt, the target kernel thread created in the system kernel directly writes the user data retained in memory to the target partition of the storage device. The target partition is a storage partition that is pre-allocated in the storage device and is not formatted with a file system, dedicated to saving data in the event of a power failure.

[0080] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0081] In specific implementation, the embodiments of this application can be referred to the above embodiments and have corresponding technical effects.

[0082] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0083] For software implementation, the techniques described herein can be implemented by units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0084] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0085] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

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

[0088] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0089] If the aforementioned function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the prior art, or a part 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, ROM, RAM, magnetic disks, or optical disks. It should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. In the absence of further restrictions, an element defined by the phrase "comprising a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0090] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for saving data at power down of a system, characterized by, The method applied to a system kernel comprises: In the process of system running, writing user data in an application layer into reserved memory of the system kernel through memory mapping; In the case of detecting a system power-off trigger interrupt, directly writing the user data in the reserved memory into a target partition of a storage device through a target kernel thread created in the system kernel; the target partition is a storage partition in the storage device which is pre-divided and not formatted by a file system and is specially used for saving power-off data.

2. The method of claim 1, wherein, The system kernel is a system kernel enabled with full real-time mode or installed with a real-time patch; the target kernel thread is created in a driver layer of the system kernel, the priority of the target kernel thread is the highest priority, and the target kernel thread is bound to a target core so that the target core is specially used for running the target kernel thread.

3. The method of claim 1, wherein, Before the directly writing the user data in the reserved memory into the storage device, the method further comprises: Determining a device node of the storage device in a device tree of the system kernel; Detecting a speed mode of the storage device at the device node of the storage device; In the case that the speed mode is not configured in a highest speed mode, modifying the speed mode of the storage device to the highest speed mode.

4. The method of claim 1, wherein, The directly writing the user data in the reserved memory into the target partition of the storage device through the target kernel thread created in the system kernel comprises: Reading the user data from the reserved memory through the target kernel thread and determining a partition identification of the target partition in a block device layer of the system kernel; Carrying the partition identification of the target partition, writing the user data into the target partition in the storage device for saving.

5. The method of claim 1, wherein, In the case of detecting a system power-off trigger interrupt, the method further comprises: When a pass request of a data stream is received in an MMC core layer of the system kernel, obtaining a storage area identification of a storage area requested to be accessed by the data stream; In the case that the storage area identification is not the partition identification of the target partition, intercepting the data stream.

6. The method of claim 1, wherein, In the case of detecting a system power-off trigger interrupt, the method further comprises: When a pass request of a request queue is received in an MMC driver layer of the system kernel, obtaining a storage area identification of a storage area requested to be accessed by the request queue; In the case that the storage area identification is not the partition identification of the target partition, intercepting the request queue.

7. The method according to any one of claims 1 to 6, characterized in that, Before the directly writing the user data in the reserved memory into the storage device through the MMC driver layer of the system kernel, the method further comprises: When the system is powered on, configuring a block size of the MMC driver layer so that the amount of data for writing one block of data into the storage device is less than a preset data amount threshold.

8. A system power-down data saving apparatus for implementing the system power-down data saving method according to any one of claims 1 to 7, characterized by, Comprise: A kernel temporary storage module for writing user data in an application layer into reserved memory of the system kernel through memory mapping in the process of system running; A kernel writing module is configured to, in the case of detecting a system power-off triggering interrupt, directly write the user data in the reserved memory to a target partition of a storage device through a target kernel thread created in a system kernel; the target partition is a storage partition in the storage device that is pre-divided and not formatted with a file system and is dedicated to power-off data saving.

9. An electronic device comprising a memory, a processor, a communication interface and a communication bus, the memory storing a computer program executable on the processor, the memory, the processor communicating through the communication bus and the communication interface, characterized in that, The processor executes the computer program to implement the data saving method under system power-off of any one of claims 1 to 7.

10. A computer readable medium having a non-transitory program code executable by a processor, the program code comprising instructions for: The program code causes the processor to execute the data saving method under system power-off of any one of claims 1 to 7.

Images