A storage medium partition management method, device and equipment of an embedded system and a medium

Abstract

This application relates to the field of computer software, and in particular to a method, apparatus, device, and medium for managing storage media partitions in an embedded system. The method includes: configuring a first storage medium of the embedded system as multiple partitions for storing bootloader, kernel, file system, and application data; the embedded system includes a first storage medium and a second storage medium for storing historical runtime data; deploying the bootloader partition, kernel partition, and file system partition in read-only mode, and deploying the application partition in read-write mode; employing a stacked file system, using a first directory containing the mounted storage file system as the lower-level directory, and a writable second directory in the application partition as the upper-level directory; during system startup, performing a stacked file system mount operation, aggregating the lower-level directory and the upper-level directory into a unified file system view, and mounting the unified file system view to a target mount point.

Description

Technical Field

[0001] This application relates to the field of computer software, and in particular to a method, apparatus, device and medium for partitioning storage media in an embedded system. Background Technology

[0002] The Linux operating system is widely used in complex embedded terminal devices due to its open-source nature, strong ecosystem, and comprehensive features such as network communication, file processing, and multitasking. These devices include smart home IoT devices, industrial control equipment, automotive electronic devices, consumer electronic devices, communication network equipment, medical devices, power devices, and security devices.

[0003] The system files U-Boot, kernel, file system, applications and configuration files, historical data, and runtime logs of a Linux embedded system are typically deployed on the same physical storage medium. Frequent refreshing of historical data and runtime logs, or sudden power outages and subsequent power restorations, can damage these components, causing the system to malfunction.

[0004] Especially in carbon metering and new energy applications, the risks of high-frequency data writing and abnormal power loss are prominent, further increasing the possibility of system file corruption and threatening carbon data security and the stable operation of new energy equipment. Therefore, ensuring the normal operation of embedded systems is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] The purpose of this application is to provide a storage medium partitioning management method, apparatus, device, and medium for embedded systems, aiming to overcome the defects of existing Linux embedded systems, such as easy damage due to power failure, startup failure, and low reliability caused by the mixed storage of firmware, parameters, and data. It provides a highly stable hardware and software design method with physical isolation of multiple storage media, read-only firmware, dynamic parameter mounting, and independent data storage, thereby synergistically improving the power failure resistance and operational stability of embedded Linux systems from both hardware and software levels.

[0006] Firstly, a method for managing storage media partitions in an embedded system is provided, including: The first storage medium of the embedded system is configured as a boot program partition for storing the bootloader, a kernel partition for storing the kernel, a file system partition for storing the file system, and an application partition for storing application data; wherein, the embedded system includes a first storage medium and a second storage medium, the second storage medium being used to store historical running data; The bootloader partition, the kernel partition, and the file system partition are deployed in read-only mode, and the application partition is deployed in read-write mode. A stacked file system is used, with the first directory containing the mounted storage file system as the lower directory and the writable second directory in the application partition as the upper directory. During system startup, a stacked file system mount operation is performed, which aggregates the lower-level directory and the upper-level directory into a unified file system view and mounts the unified file system view to the target mount point. Write operations on files under the target mount point can be redirected to the upper-level directory by the stacked file system.

[0007] In a preferred embodiment, this application can be further configured to: employ a stacked file system, using the first directory containing the mounted storage file system as the lower-level directory and the second directory containing the application partition as the upper-level directory, including: When compiling the Linux kernel, the stacked file system is compiled into the kernel driver; In the / etc / fstab file of the file system, the first directory where the mounted storage file system is located is designated as the lower-level directory, and the second directory where the application partition is located is designated as the upper-level directory.

[0008] In a preferred embodiment, this application may be further configured to include: By writing username and password files to the upper-level directory, the login username and password of the operating system can be modified online.

[0009] In a preferred embodiment, this application may be further configured to include: When an application update is needed, obtain the target incremental file required for the upgrade; The target incremental file is written to the parent directory to achieve incremental upgrade.

[0010] In a preferred embodiment, this application may be further configured to include: Delete the target incremental file in the upper-level directory to roll back to the state corresponding to the lower-level directory.

[0011] In a preferred embodiment, this application can be further configured as follows: historical operational data includes log data and historical data, wherein the log data is stored in a first partition of the second storage medium, and the historical data is stored in a second partition of the second storage medium. The method for partitioning the storage medium of the embedded system further includes: Determine if a second storage medium is detected; if not, exit abnormally. If detected, then check whether the second storage medium contains the first partition and the second partition; If the first or second partition does not exist, execute the disk check command to check the disk so that the partition table can be read again and the first and second partitions can be mounted to the corresponding directories. If the mounting result is abnormal, the second storage medium will be repartitioned and remounted.

[0012] In a preferred embodiment, this application may be further configured to include, after repartitioning and mounting the second storage medium, the following: If mounting fails, the first and second partitions of the second storage medium will be formatted after repartitioning, and then mounted again. If mounting is successful, the process will exit normally.

[0013] Secondly, a storage medium partitioning management device for an embedded system is provided, comprising: A partitioning module is used to configure the first storage medium of the embedded system as a boot program partition for storing the boot program, a kernel partition for storing the kernel, a file system partition for storing the file system, and an application partition for storing application data; wherein, the embedded system includes a first storage medium and a second storage medium, and the second storage medium is used to store historical running data; The mode setting module is used to deploy the boot program partition, the kernel partition, and the file system partition in read-only mode, and deploy the application partition in read-write mode; The directory mounting module is used to employ a stacked file system, taking the first directory containing the mounted storage file system as the lower-level directory and the writable second directory in the application partition as the upper-level directory. The mount operation execution module is used to perform a stacked file system mount operation during system startup, aggregating the lower-level directory and the upper-level directory into a unified file system view, and mounting the unified file system view to the target mount point. Write operations on files under the target mount point can be redirected to the upper-level directory by the stacked file system.

[0014] Thirdly, an electronic device is provided, the electronic device including a memory and a processor, the memory storing a computer program, and the processor executing the storage medium partitioning management method of the embedded system according to any one of the first aspects when running the computer program.

[0015] Fourthly, a computer-readable storage medium is provided, wherein at least one piece of program code is stored in the computer-readable storage medium, the program code being loaded and executed by a processor to implement the storage medium partitioning management method of the embedded system as described in any of the first aspects.

[0016] Fifthly, a computer program product is provided, including a computer program or instructions, which, when executed by a processor, implement the storage medium partitioning management method of the embedded system as described in any of the first aspects.

[0017] In summary, the embedded system storage media partitioning management method provided in this application has the following beneficial technical effects: The first storage medium is divided into four partitions: bootloader, kernel, file system, and application. The first three are mounted in read-only mode, and the application partition is mounted in read-write mode. A second storage medium specifically for storing historical runtime data is introduced. Based on this, a stacked file system is used, with the first directory containing the mounted read-only file system as the lower-level directory and the writable second directory in the application partition as the upper-level directory. During startup, the stacked file system is mounted, aggregating the lower and upper levels into a unified file system view and mounting it to the target mount point. Under this unified view, all write operations are automatically redirected to the upper-level directory by the stacked file system, while the lower-level read-only file system remains in its original state. Therefore, read-only system files are unaffected by any write operations, avoiding the risk of file corruption due to write interruptions or anomalies. Simultaneously, historical runtime data is stored independently on the second storage medium, and the risk of media damage caused by frequent writes will not affect the data in the first storage medium, thus ensuring the normal operation of the embedded system.

[0018] In addition, this application also provides a storage medium partitioning management device, equipment and medium for embedded systems, all of which have the above-mentioned beneficial technical effects. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of a typical minimum application unit in a conventional Linux embedded system; Figure 2 This is a schematic flowchart of a storage media partitioning management method for an embedded system provided in an embodiment of this application; Figure 3 This is an application architecture diagram of a Linux embedded system provided in an embodiment of this application; Figure 4 This is a schematic flowchart of a second storage medium processing provided in an embodiment of this application; Figure 5This is a schematic diagram of the structure of a storage medium partitioning management device for an embedded system provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] This specific embodiment is merely an explanation of this application and is not intended to limit it. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they are within the scope of this application.

[0022] It should be noted that, in the optional embodiments of this application, the data related to object information, when applied to specific products or technologies, requires the permission or consent of the object. Furthermore, the collection, use, and processing of this data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. In other words, if the embodiments of this application involve data related to an object, it must be obtained with the permission and consent of the object, the permission and consent of relevant departments, and in accordance with the relevant laws, regulations, and standards of the country and region. If the embodiments involve personal information, the acquisition of all personal information requires the consent of the individual. If sensitive information is involved, the separate consent of the information subject is required. The embodiments also need to be implemented with the permission and consent of the object.

[0023] 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.

[0024] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0025] The Linux operating system is widely used in complex embedded terminal devices due to its open-source nature, strong ecosystem, and comprehensive features such as network communication, file processing, and multitasking. These devices include smart home IoT devices, industrial control equipment, automotive electronic devices, consumer electronic devices, communication network equipment, medical devices, power devices, and security devices.

[0026] However, because Linux embedded systems commonly use Flash memory, EMMC (embedded MultiMediaCard), and SD cards (Secure Digital Memory Card) as storage devices, these devices have slow write speeds, large caches, and long erase / write cycles. Furthermore, the driver layer includes an FTL (Flash Translation Layer). Even though a write operation appears complete, the file remains in the cache / FTL and is lost upon power failure. Therefore, a sudden power outage while writing a file can result in data loss, or even file system corruption, preventing the entire device from booting correctly. While modern hardware typically includes a backup power supply, and the application layer stops writing files upon detecting a mains power failure, and the kernel and system files are configured as read-only, these measures mitigate firmware damage from power outages to some extent. However, they don't guarantee 100% protection against damage. Therefore, additional methods such as file backups are used to improve reliability and reduce the probability of failures.

[0027] See Figure 1 , Figure 1 This is a schematic diagram of a typical minimum application unit in a conventional Linux embedded system. The minimum application unit includes: the main processor, i.e., the MCU (Microcontroller Unit), which handles all logic, calculations, control, and scheduling; memory, i.e., DDR (Double Data Rate), which loads firmware programs and provides temporary data buffering during intermediate processes; and NorFlash (NOR Flash Memory) / NandFlash (NAND Flash Memory) / EMMC, which are non-volatile memories used to store system files and data files. Small embedded systems typically use a single NorFlash chip with a smaller capacity, slightly larger embedded systems use a single NandFlash chip with a larger capacity, and applications requiring large amounts of storage use an even larger capacity EMMC.

[0028] The system files of a Linux embedded system generally consist of five parts: U-Boot (Universal Boot Loader), which is the boot manager of embedded Linux and a small system before startup, completing power-on, hardware initialization, kernel loading, and Linux startup. The kernel, also called the system core, is the brain of the entire system, acting as the manager between hardware and applications. The file system is the core mechanism used by the operating system to manage data on storage devices, responsible for file storage, retrieval, access control, space allocation, and data consistency assurance. It provides a unified access interface for applications, shields underlying hardware differences, and ensures stable system operation and data security. Applications and configuration files contain application code written according to requirements to complete relevant applications. Data storage is used by applications to save historical data as needed.

[0029] Once deployed, the U-Boot, kernel, and file system components mentioned above are generally not modified on-site unless defects arise. Applications may occasionally change, and on-site requirements may evolve, necessitating online upgrades. Historical data and operational logs are constantly being modified and refreshed as the device operates. Frequent refreshes of historical data and operational logs, or sudden power outages and subsequent power restorations, can damage the U-Boot, kernel, file system, applications, and configuration files, causing system malfunctions.

[0030] This application provides a method for storage medium partitioning management in an embedded system, such as... Figure 2 As shown, the method provided in this application embodiment can be executed by an electronic device, which is an embedded system. The method includes: S101, The first storage medium of the embedded system is configured as a boot program partition for storing the boot program, a kernel partition for storing the kernel, a file system partition for storing the file system, and an application partition for storing application data; wherein, the embedded system includes a first storage medium and a second storage medium, and the second storage medium is used to store historical running data; In this context, the first storage medium refers to the storage device used in the embedded system to store the bootloader, kernel, file system, and application data, such as NorFlash, NAND Flash, and eMMC. The bootloader is the first program executed after the embedded system powers on, such as U-Boot. U-Boot is the boot manager for embedded Linux, a small system before startup, handling power-on, hardware initialization, kernel loading, and Linux startup. The bootloader partition is the storage area in the first storage medium used to store the bootloader. The kernel represents the core of the operating system, the brain of the entire system, and the main manager between hardware and applications. The kernel partition is a dedicated storage area for storing the kernel. The file system is the core mechanism used by the operating system to manage data on storage devices, responsible for file storage, retrieval, access control, space allocation, and data consistency assurance. It provides a unified access interface for applications, shields underlying hardware differences, and ensures stable system operation and data security; the file system partition is the storage area for storing the file system. Application data consists of applications and configuration files, application code written according to requirements to complete related applications; the application partition is an independent partition used to store application data.

[0031] The second storage medium refers to a different type of storage device from the first storage medium, used to store historical operational data, such as logs and statistical data; that is, historical data saved by the application as needed. Since the first storage medium stores firmware files that are not long, NorFlash can be used. The second storage medium stores historical operational data, which involves a large amount of data, so EMMC can be used.

[0032] The system files of a Linux embedded system typically include the bootloader, kernel, file system, application data, and historical runtime data. See also... Figure 3 , Figure 3 This is an application architecture diagram of a Linux embedded system provided in an embodiment of this application. The hardware layer adds one NorFlash chip for deploying the bootloader, kernel, file system, and application data; the EMMC simply stores historical runtime data. Therefore, the data storage and program storage are physically completely separated, without interfering with each other, ensuring the reliability of the entire system.

[0033] The first storage medium in the embedded system is partitioned as a whole, specifying the starting sector and size, and its logical address space is divided into four partitions according to their purpose. It should be noted that the embedded system has both a first storage medium and a second storage medium, with the second storage medium specifically used for storing historical runtime data. The bootloader, kernel, file system, and application data are automatically written to the corresponding addresses on the first storage medium according to the configuration file, and the partition creation and content writing are automatically completed automatically. In this step, multiple partitions are set up for the first storage medium of the embedded system to isolate the bootloader, kernel, file system, and application data from each other.

[0034] S102. Deploy the boot partition, kernel partition, and file system partition in read-only mode, and deploy the application partition in read-write mode; In read-only mode, after the bootloader partition, kernel partition, and file system partition are mounted, the system can only read the file content from them, but cannot perform write, modify, or delete operations. In read-write mode, after the application partition is mounted, the system can both read the files in it and perform write, create, modify, or delete operations.

[0035] Specifically, each partition is mounted to its corresponding directory and set to read-only mode; the application partition needs to be mounted to a directory such as / app and set to read-write mode. The bootloader U-Boot, kernel, file system, and application data (parameters) are all deployed on the first storage medium. It is formatted into four partitions, storing U-Boot, kernel, file system, and application (parameters) respectively. Because U-Boot, kernel, and file system do not undergo significant changes after leaving the factory, they are configured in read-only mode; the application (parameters) require online upgrades, so they are configured in read-write mode. By separating the system partition and data partition and setting different mount permissions, the integrity and security of the system core are ensured, while writable data storage space is provided for applications.

[0036] In this step, differentiated access permissions are set for different partitions of the first storage medium in the embedded system to ensure the stability and security of critical areas of the system, while providing flexible data storage capabilities for the application.

[0037] Because the root file system is configured as read-only and cannot be modified online, however, in actual operation, some content may sometimes be modified online, such as login usernames and passwords, which users may change according to their needs. To enable online modification of system-level parameters and drivers, this application uses the OverlayFS file system. OverlayFS is a stacked file system under Linux, whose core is to merge multiple layers of directories into a unified view, achieving efficient sharing and isolation through read-only and writable layers. See S103 and S104 for details.

[0038] S103. A stacked file system is adopted, with the first directory where the mounted storage file system is located as the lower directory and the writable second directory in the application partition as the upper directory. The OverlayFS file system can overlay multiple different directory layers together, presenting a unified file system view. The lowerdir layer is a read-only layer in OverlayFS, typically storing the base image / system files; it is read-only and cannot be modified. The upperdir layer is a writable layer in OverlayFS, used to record all modifications, additions, or deletions to files in the lowerdir layer; it actually stores the difference data and is on the same file system as the workdir. The workdir layer (Work Directory) is a temporary directory required by OverlayFS for atomically exchanging data during file modification and merging operations; it must be on the same file system as the upperdir layer and is initially empty. The first directory represents the directory path of the mounted storage file system. The writable second directory in the application partition refers to the directory within the application partition that is mounted in read-write mode and is used to store all modifications to the file system.

[0039] In this embodiment, the underlying rootfs (Root Filesystem) is set to read-only, and all configurations, logs, and modifications are written to the upper layer. This ensures that the underlying original system will never be damaged during power outages or restarts, preventing firmware crashes, viruses, and accidental deletion of system files, thus ensuring the reliability of the underlying system.

[0040] The upper-level code creates an overlay directory and a directory containing system-level files that need modification, such as the etc directory. This allows files that need modification in the system-level etc directory to be moved to the upper-level etc directory. The overlay directory is a temporary working directory dedicated to the OverlayFS system kernel layer and must be empty. In this application, the path is / app / overlay, and the etc path is / app / etc (i.e., the upperdir layer). Modifying or adding files under / app / etc is equivalent to modifying system-level files. For example, in Linux systems, usernames and passwords can be modified online by simply writing `passwd` and `shadow` to / app / etc. To automatically mount the OverlayFS system at boot, the following needs to be added to the / etc / fstab file in the rootfs layer: `overlay / etc overlay lowerdir= / etc,upperdir= / app / etc,workdir= / app / overlay`.

[0041] In one feasible approach, the underlying file system partition is mounted to the first directory, and the application partition is mounted in read-write mode to the second directory. Two subdirectories are created within this application partition: the second directory serves as the upperdir layer; the third directory serves as the workdir layer, an empty directory used for internal atomic operations of OverlayFS. These three directory layers are then mounted together to the new target mount point.

[0042] When reading a file, OverlayFS first searches the upperdir layer; if found, it returns the modified version; otherwise, it reads from the read-only lowerdir layer. When writing a file, OverlayFS first copies the original file from the lowerdir layer to the upperdir layer, and then modifies it in the upperdir layer. Deletion operations hide the corresponding file in the lowerdir layer by creating a whitelist marker file in the upperdir layer. The workdir layer coordinates file renaming and swapping operations, ensuring consistency during the merging process. Regardless of the write operation performed on the file system, the original read-only file system partition is not modified; all changes are stored in the upperdir layer of the application partition.

[0043] The purpose of this step is to leverage OverlayFS stacked file system technology to dynamically overlay a read-only raw file system with directories in a writable application partition, forming a unified file system view that is logically writable but physically protected. The first directory containing the raw file system, acting as the lowerdir layer, remains read-only, ensuring that any system updates, configuration modifications, or application write operations will not compromise the integrity of the underlying firmware. All actual modifications to the file system are stored in the upperdir layer of the application partition; simply clearing the upperdir layer's contents allows for a rollback to the factory default state.

[0044] S104. During system startup, perform a stacked file system mount operation to aggregate the lower-level directory and the upper-level directory into a unified file system view, and mount the unified file system view to the target mount point. Write operations on files under the target mount point can be redirected to the upper-level directory by the stacked file system.

[0045] The system startup process refers to the entire process of an embedded system from power-on or reset, including loading the kernel via the bootloader, kernel initialization, and mounting the file system. OverlayFS logically merges the contents of the lowerdir and upperdir layers, presenting them externally as a single directory structure containing all files from both layers (with upperdir files preferentially overwriting lowerdir files with the same name). The target mount point refers to an existing empty directory in the system directory tree, used to host the aggregated unified file system view. File write operations represent operations that change the content of files, such as creation, modification, deletion, and renaming. Redirection means that OverlayFS automatically redirects a write operation originally targeting a file in the lowerdir layer to the upperdir layer, completing the operation by creating or modifying a copy in the upperdir layer without altering the underlying read-only file.

[0046] As can be seen, in this embodiment, the first storage medium is divided into four partitions: bootloader, kernel, file system, and application. The first three are mounted in read-only mode, and the application partition is mounted in read-write mode. A second storage medium specifically for storing historical runtime data is introduced. Based on this, a stacked file system is used, with the first directory containing the mounted read-only file system as the lower-level directory and the writable second directory in the application partition as the upper-level directory. During startup, a stacked file system mounting operation is performed, aggregating the lower and upper levels into a unified file system view and mounting it to the target mount point. Under this unified view, all write operations are automatically redirected to the upper-level directory by the stacked file system, while the lower-level read-only file system remains in its original state. Therefore, read-only system files are unaffected by any write operations, avoiding the risk of file corruption due to write interruptions or anomalies. Simultaneously, historical runtime data is stored independently on the second storage medium, and the risk of media damage caused by frequent writes will not affect the data in the first storage medium, thus ensuring the normal operation of the embedded system.

[0047] In one feasible approach, during the early stages of startup, a read-only file system on the physical partition is mounted to the first directory. Simultaneously, the application partition is mounted in read-write mode to the `app` directory, creating an upperdir (i.e., the second directory, such as ` / app / etc`) and a workdir (i.e., ` / app / overlay`) layer. The system then initiates an OverlayFS file system mount operation via the `mount` command: the first directory is designated as the lowerdir layer, and ` / app / etc` (the second directory) as the upperdir layer (while specifying the workdir layer path), and these are jointly mounted to a new target mount point, such as ` / merged`. After mounting, the content displayed in the target mount point ` / merged` is a unified file system view formed by the aggregation of the lowerdir and upperdir layers. This ensures that when accessing a path like ` / merged / etc`, if a modified version exists in the upperdir layer, that version is returned first; otherwise, the original files in the read-only lowerdir layer are rolled back. When an application performs a file write operation under / merged, OverlayFS automatically determines the target. If the target is a file that only exists in the lowerdir layer, OverlayFS first copies the file to the upperdir layer, and then performs the write operation on the copy in the upperdir layer. If the target is a newly created file, it is created directly in the upperdir layer. The results of all write operations do not touch the original read-only lowerdir layer, but are recorded in the upperdir layer. After OverlayFS is mounted, the file system runs in the overlay environment. During the device production flashing stage, the first storage medium is divided into four independent partitions, and the second storage medium in the device is dedicated to storing historical running data. When the device boots, the bootloader loads the kernel from the bootloader partition. After the kernel completes initialization, it mounts the file system partition and the application partition. At this time, the file system itself is still read-only, and any write operation to the file directory will fail. To provide a writable file system experience while protecting the original firmware, the system further creates two directories in the application partition: a second directory (upperdir layer) and a third directory (workdir layer), where workdir is an empty directory. Then, the system performs an OverlayFS mount operation, mounting the first directory containing the already mounted file system as the lowerdir (read-only layer), the second directory as the upperdir (writable layer), and the third directory as the workdir (working layer) to the target mount point. After the mount is complete, the target mount point / merged displays a unified file system view that aggregates the lowerdir and upperdir.When a file write operation is performed at the target mount point, OverlayFS determines whether the file exists in the lowerdir layer. If so, it copies the file to the upperdir layer and then modifies the copy. If it is a new file, it creates it directly in the upperdir layer. All write operation results are redirected and stored in the upperdir layer, while the original read-only file system partition remains unmodified, allowing the entire system to run on a writable file system built by OverlayFS. The second storage medium works independently, writing historical runtime data to it.

[0048] One possible implementation of this application embodiment uses a stacked file system, with the first directory where the mounted storage file system is located as the lower-level directory and the second directory where the application partition is located as the upper-level directory. This includes: compiling the stacked file system into the kernel driver when compiling the Linux kernel; and setting the first directory where the mounted storage file system is located as the lower-level directory and the second directory where the application partition is located as the upper-level directory in the / etc / fstab file of the file system.

[0049] Compiling into the kernel driver means that the OverlayFS file system support code is directly statically linked into the kernel image, rather than being compiled as a separate kernel module. This allows the kernel to have OverlayFS capabilities at startup without needing to load an additional module. The / etc / fstab file is the file system mount configuration file in the Linux system, used to define the automatic mounting method for storage devices and partitions. It contains fields such as device, mount point, file system type, and mount options.

[0050] During the kernel compilation phase, developers locate the OverlayFS-related options in the File systems directory based on the embedded system's hardware platform. This means compiling the OverlayFS system into the kernel driver. For Overlay filesystem support, select OverlayFS. After configuration, execute the compilation command; the generated kernel image will contain the complete OverlayFS driver code. When the device boots, the kernel directly registers OverlayFS during the initialization of the file system subsystem. Then, in the file system's / etc / fstab file, the first directory containing the mounted storage filesystem is designated as the lowerdir layer, and the second directory containing the application partition is designated as the upperdir layer.

[0051] As can be seen, in this embodiment of the application, the OverlayFS driver is statically compiled into the kernel and the joint mount parameters are configured in / etc / fstab of the file system to realize the mounting of the OverlayFS stacked file system when the embedded system starts.

[0052] One possible implementation of this application embodiment further includes: writing a username file and a password file to the upper-level directory to enable online modification of the operating system's login username and password.

[0053] The upperdir layer represents the writable layer in the OverlayFS stacked file system, capable of recording all differences resulting from modifications, additions, or deletions to files in the read-only lowerdir layer. The username file is a text file in the Linux operating system that stores local user account information, including username, user ID, etc.; the password file is a secure file in the Linux operating system that stores user password hashes and password expiration information. If a file with the same name exists between the upperdir (the actual modifiable file layer) and the lowerdir (the read-only, non-modifiable underlying file layer), only the upperdir is displayed, and the lowerdir is hidden.

[0054] For the username and password in this solution, there are default username and password files in the lowerdir file. If the upperdir layer does not have a file with the same name as the lowerdir file, the system will use the default username and password. If the upperdir layer has a file with the same name as the lowerdir file, the system will use the upperdir's username or password, thus enabling online modification. Modifications to other drivers are similar.

[0055] As can be seen, in this embodiment of the application, the copy-on-write feature of the OverlayFS stacked file system is utilized to achieve online modification of the operating system login username and password while maintaining the integrity of the original read-only file system.

[0056] In one possible implementation of this application, the first storage medium is NorFlash and the second storage medium is EMMC.

[0057] This application uses NorFlash with an OSPI interface. The main reasons for using NorFlash are as follows: NorFlash differs from NandFlash and eMMC. NandFlash and eMMC are easily damaged, and although they can be repaired via ECC, they cannot be 100% repaired. NorFlash offers fast operation, long lifespan, and inherently no bad blocks. Although this solution will not frequently write to NorFlash, fast operation speed and no bad blocks are key considerations. While NandFlash and eMMC can experience bit rollovers during reads, NorFlash has a simpler storage cell structure, better protection against long-term static storage, high and low temperatures, and power loss, ensuring long-term stability and reliability. Using the OSPI interface balances small package size with high speed requirements; the OSPI interface is an 8-data-line interface, much faster than single SPI.

[0058] As on-site requirements constantly change, and the original factory kernel drivers, some utility software, and some library files can no longer meet new needs, this application also uses OverlayFS to upgrade files in the upperdir layer, achieving incremental online upgrades of files in the lowerdir layer. The upgrade risk is extremely low; in case of failure, simply deleting the upper layer allows for rollback, overlaying drivers, configurations, and scripts without affecting the original firmware. Therefore, one possible implementation of this application's embodiments further includes: when an application update is needed, obtaining the target incremental file required for the upgrade; writing the target incremental file to the upper-level directory to achieve incremental upgrades.

[0059] Obtain the target incremental file involved in this upgrade; place the target incremental file into the corresponding path in the upperdir layer through file system write operations. Due to the federation mechanism of OverlayFS, the write operation will create a new file or overwrite an existing file in the upperdir layer. This file may originally exist in the lowerdir layer or the upperdir layer.

[0060] When an application upgrade is needed, an upgrade package is obtained. This package does not contain all the complete application files; instead, it only contains the target incremental files that differ between the current version and the target version. Each target incremental file is written to the corresponding path in the upperdir layer. If the file to be written to the path originally existed only in the read-only lowerdir layer, OverlayFS copies the file from the lowerdir layer to the upperdir layer and then overwrites the copy with the incremental file content. If the file already exists in the upperdir layer, the existing version in the upperdir layer is directly overwritten. If it is a completely new file, it is created directly in the upperdir layer. Throughout the entire writing process, all original files in the lowerdir layer remain unchanged and are not modified.

[0061] As can be seen, in this embodiment of the application, OverlayFS is used to achieve incremental upgrade of the application by selectively writing target incremental files to the upperdir layer while keeping the read-only lowerdir layer unchanged.

[0062] One possible implementation of this application embodiment can also achieve boot restore or one-click recovery, clearing the upperdir and directly restoring the underlying original system without reflashing the ROM, restoring factory settings in seconds. Specifically, the method further includes: deleting the target incremental file in the upper directory to roll back to the corresponding state in the lower directory.

[0063] In an OverlayFS environment, deleting a file may involve creating a corresponding marker file in the upperdir layer to mask out files with the same name in the lowerdir layer. The target incremental file refers to a file that was previously written to the upperdir layer through an upgrade operation.

[0064] When a serious defect is discovered after an application upgrade, the upgrade results in incompatibility with hardware or system environments, the upgrade process is abnormally interrupted leading to incomplete files, or verification fails in a test environment, requiring a return to a stable version, the current application version is deemed to have a problem. In such cases, a rollback operation is triggered to restore the application to its pre-upgrade state. Since the previous incremental upgrade operation only wrote the new target incremental files to the upperdir layer without modifying the lowerdir layer, the essence of a rollback is to undo the write operations, ensuring that these files used for overwriting or adding no longer exist in the upperdir layer.

[0065] When performing a deletion operation, if the target incremental file overwrites an existing file in the lowerdir layer, the deletion operation removes the copy of that file from the upperdir layer. After deletion, when OverlayFS reads the file, since it no longer exists in the upperdir layer, the stacked file system automatically rolls back to the lowerdir layer, returning the original version of the file content. If the target incremental file is a newly created file, the deletion operation directly removes the file from the upperdir layer. After removal, the file completely disappears from the federated view, and the system reverts to a state where the file never existed. In this way, incremental files related to the current upgrade in the upperdir layer can be deleted one by one or in batches to achieve precise rollback. After the rollback operation is complete, there is no need to restart the entire device; simply restarting the relevant application processes or reloading the configuration is sufficient for the rollback to take effect. Throughout the entire process, the lowerdir layer remains untouched, ensuring the safety and reversibility of the rollback.

[0066] As can be seen, in this embodiment of the application, by utilizing the hierarchical isolation feature of OverlayFS, the file view of the application is restored to the original state represented by the lowerdir layer by deleting the target incremental file in the upperdir layer, thereby achieving a fast, safe and accurate rollback operation.

[0067] For the second storage medium, only operation logs and historical data are stored. Mounting and exception handling of the second storage medium are performed at the application layer. The second storage medium is formatted into two partitions: mmcblk0p1 (taking EMMC as an example) and mmcblk0p2. mmcblk0p1 stores logs, and mmcblk0p2 stores historical data. Specifically, in one possible implementation of this application embodiment, historical operation data includes: log data and historical data. Log data is stored in the first partition of the second storage medium, and historical data is stored in the second partition of the second storage medium. The method further includes: determining whether the second storage medium is identified; if it does not exist, exiting abnormally; if it is identified, detecting whether the first and second partitions exist on the second storage medium; if the first and second partitions do not exist, executing a disk detection command to detect the disk in order to reread the partition table and mount the first and second partitions to the corresponding directories; if the mounting result is abnormal, repartitioning and remounting the second storage medium.

[0068] The solution of this application embodiment is executed in scenarios such as device initial power-on initialization, identification and mounting of the second storage medium, and periodic health checks.

[0069] Specifically, the command -e / dev / mmcblk0 is used to check if a second storage medium is detected. If no second storage medium is detected, the process will exit abnormally.

[0070] If the second storage medium is successfully identified, further check whether the expected first and second partitions already exist on that medium. Use the commands -e / dev / mmcblk0p1 and -e / dev / mmcblk0p2 to check if the partitions are mounted correctly. If correct, exit normally.

[0071] If either the first or second partition is missing, a disk check command is executed to examine the disk. Specifically, the disk is checked using `fdisk / dev / mmcblk0> / dev / null`, and the `mount` command is executed to mount the partition. If the mount is successful, the process exits normally. After rereading the partition table, the first and second partitions are checked again. If they exist, the mount operation continues. The first partition is mounted to the preset log directory, and the second partition (e.g., ` / dev / sda2`) is mounted to the preset historical data directory. If the mount command returns successfully, the process ends normally.

[0072] If the mount fails, repartition the eMMC disk using `e2fsck -p / dev / mmcblk0p1` and `e2fsck -p / dev / mmcblk0p2`, then execute the `mount` command to mount the partition. If the mount is successful, exit normally.

[0073] As can be seen, in this embodiment, the second storage medium is divided into a first partition and a second partition, used to store log data and historical data, respectively. The system determines whether the second storage medium is detected; if it does not exist, the process exits abnormally to avoid data loss due to continued operation without historical storage capacity. If detected, the system checks whether the second storage medium has the first and second partitions. If either partition does not exist, a disk check command is executed to reread the partition table and mount it. If the mounting result is still abnormal, the second storage medium is repartitioned and remounted, enabling self-recovery in the event of a recoverable media failure.

[0074] One possible implementation of this application embodiment includes, after repartitioning and mounting the second storage medium, the following steps are also included: if mounting fails, formatting the first and second partitions of the repartitioned second storage medium and mounting them again; if mounting succeeds, exiting normally.

[0075] The system has successfully identified the second storage medium and created the first and second partitions through a repartitioning operation (or the partitions originally existed but subsequent mount attempts failed). At this point, the system attempts to mount these two partitions to their respective target directories, but the mount operation returns an error.

[0076] A common root cause of mount failure is the lack of a recognizable valid file system on the partition. Therefore, you can format the disk using the `mke2fs -m` command, typically as ext4, ext3, or vfat (FAT32). Then, execute the `mount` command to mount the partition. If the mount is successful, exit normally; otherwise, exit abnormally.

[0077] After formatting, perform the mount operation again, mounting the formatted first partition to the log directory and the second partition to the historical data directory. If this round of mounting is successful, exit normally.

[0078] As can be seen, in this embodiment of the application, a repair capability is provided for the second storage medium of the embedded system. When the normal mounting operation fails, the storage function of historical running data can be restored and made available again by formatting the repartitioned partition and retrying mounting.

[0079] For the second storage medium, see Figure 4 , Figure 4 This is a flowchart illustrating the processing of a second storage medium provided in this application embodiment. Taking EMMC as an example, the application layer identifies and mounts the EMMC using a shell file, mainly including the following steps: First, using the `-e / dev / mmcblk0` command, check if an EMMC device is detected. If no EMMC device is detected, exit abnormally. Second, using the `-e / dev / mmcblk0p1` and `-e / dev / mmcblk0p2` commands, check if the partition is mounted correctly. If correct, exit normally. Third, if the partition mount is abnormal, use `fdisk / dev / mmcblk0> / dev / null` to detect the disk, execute the `mount` command to mount the partition, and exit normally if the mount is successful. Fourth, if the mount is still abnormal, use `e2fsck -p / dev / mmcblk0p1` and `e2fsck -p / dev / mmcblk0p2` to repartition the EMMC disk, and then execute the `mount` command to mount the partition. If the mount is successful, exit normally. If mount fails, format the disk using the `mke2fs -m` command, typically as ext4, ext3, or vfat (FAT32). Then execute the `mount` command to mount the partition. If mount is successful, exit normally; otherwise, exit abnormally.

[0080] Therefore, the post-mounting exit process includes: if mounting fails, a hardware reset is performed on the second storage device to prevent device recognition errors caused by accidental external interference; then, the system performs a warm reboot to re-execute the above process. If mounting is successful, the entire process is officially started.

[0081] Based on any of the above embodiments, this application can solve the problems of sudden power failure impacting Linux embedded systems, differential online system upgrades, and one-click recovery from upgrade anomalies, fundamentally ensuring normal system startup. This makes Linux embedded systems more reliable and stable, and enables differential online system upgrades while simultaneously achieving one-click restore.

[0082] In this application, the program area and data area are physically separated to avoid frequent data writing within the same chip, which could damage the program area and cause system crashes. The Linux firmware files U-Boot, kernel, file system, and applications (parameters) are all deployed in reliable NorFlash storage. The U-Boot, kernel, and file system partitions are configured as read-only to ensure normal system startup. The OverlayFS system cleverly handles online differential upgrades of the necessary changes to the read-only system files. An EMMC is mounted at the application layer. Even if a sudden power outage causes an anomaly to the EMMC, the entire system and applications can still start normally. After the application starts, the faulty EMMC is processed. If it cannot be recovered, the worst-case scenario is formatting the EMMC. While the data is important, this is less damaging than a system crash.

[0083] The following describes a device provided by an embodiment of this application. The device described below can be referred to in correspondence with the method described above. The device of this embodiment is installed in an electronic device. Figure 5 , Figure 5This is a structural block diagram of an apparatus according to one embodiment of this application, including: a partitioning module 210, used to configure a first storage medium of an embedded system as a boot program partition for storing a boot program, a kernel partition for storing a kernel, a file system partition for storing a file system, and an application partition for storing application data; wherein the embedded system includes a first storage medium and a second storage medium, the second storage medium being used to store historical running data; a mode setting module 220, used to deploy the boot program partition, kernel partition, and file system partition in read-only mode, and deploy the application partition in read-write mode; a directory mounting module 230, used to employ a stacked file system, using the first directory where the mounted storage file system is located as the lower-level directory, and the writable second directory in the application partition as the upper-level directory; and a mount operation execution module 240, used to perform a stacked file system mount operation during system startup, aggregating the lower-level directory and the upper-level directory into a unified file system view, and mounting the unified file system view to a target mount point, wherein write operations of files under the target mount point can be redirected to the upper-level directory by the stacked file system.

[0084] In one possible implementation, the directory mount module 230 is used to: compile the stacked file system into the kernel driver when compiling the Linux kernel; and to set the first directory where the mounted storage file system is located as the lower directory and the second directory where the application partition is located as the upper directory in the / etc / fstab file of the file system.

[0085] In a preferred embodiment, this application may be further configured to include: a password modification module, used to modify the operating system's login username and password online by writing username and password files to the upper-level directory.

[0086] In a preferred embodiment, this application may be further configured to include: an upgrade module, used to obtain the target incremental file required for the upgrade when the application needs to be updated; and to write the target incremental file to the upper-level directory to achieve incremental upgrade.

[0087] In a preferred example, this application may be further configured to include: a rollback module for deleting the target incremental file in the upper-level directory to roll back to the corresponding state in the lower-level directory.

[0088] In a preferred embodiment, this application can be further configured as follows: historical operational data, including log data and historical data, with log data stored in the first partition of the second storage medium and historical data stored in the second partition of the second storage medium; and also including: a second storage medium management module, used to: determine whether the second storage medium is identified; if it does not exist, exit abnormally; if it is identified, check whether the first and second partitions exist on the second storage medium; if the first or second partition does not exist, execute a disk detection command to detect the disk in order to reread the partition table and mount the first and second partitions to the corresponding directories; if the mounting result is abnormal, repartition and remount the second storage medium.

[0089] In a preferred embodiment, this application may be further configured such that, after repartitioning and mounting the second storage medium, it also includes a processing module, which, if mounting fails, formats the first and second partitions of the repartitioned second storage medium and mounts them again; if mounting succeeds, it exits normally.

[0090] Figure 6 A structural diagram of an electronic device provided in an embodiment of this application, such as... Figure 6 As shown, the electronic device includes: a memory 60 for storing a computer program; and a processor 61 for executing the computer program to implement the steps of the method as described in the above embodiments.

[0091] The electronic devices provided in this embodiment may include, but are not limited to, smartphones, tablets, laptops, or desktop computers.

[0092] The processor 61 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 61 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 61 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 61 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0093] The memory 60 may include one or more computer-readable storage media, which may be non-transitory. The memory 60 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 60 is used to store at least the following computer program 601, which, after being loaded and executed by the processor 61, is capable of implementing the relevant steps of the method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, etc., and the storage method may be temporary storage or permanent storage. The operating system 602 may include Windows, Unix, Linux, etc.

[0094] In some embodiments, the electronic device may further include a display screen 62, an input / output interface 63, a communication interface 64, a power supply 65, and a communication bus 66.

[0095] Those skilled in the art will understand that Figure 6 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0096] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the current technology, or all or 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 executes all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, magnetic disks, or optical disks, and other media capable of storing program code.

[0097] Based on this, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method described above.

[0098] Based on this, embodiments of this application also provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the above-described method. It should be understood that although the steps in the flowcharts of the accompanying drawings are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying drawings may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0099] The above are only some embodiments of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for partitioning and managing storage media in an embedded system, characterized in that, include: The first storage medium of the embedded system is configured as a boot program partition for storing the bootloader, a kernel partition for storing the kernel, a file system partition for storing the file system, and an application partition for storing application data; wherein, the embedded system includes a first storage medium and a second storage medium, the second storage medium being used to store historical running data; The bootloader partition, the kernel partition, and the file system partition are deployed in read-only mode, and the application partition is deployed in read-write mode. A stacked file system is used, with the first directory containing the mounted storage file system as the lower directory and the writable second directory in the application partition as the upper directory. During system startup, a stacked file system mount operation is performed, which aggregates the lower-level directory and the upper-level directory into a unified file system view and mounts the unified file system view to the target mount point. Write operations on files under the target mount point can be redirected to the upper-level directory by the stacked file system.

2. The method for partitioning and managing the storage medium of an embedded system according to claim 1, characterized in that, A stacked file system is used, with the first directory containing the mounted storage file system as the lower-level directory and the second directory containing the application partition as the upper-level directory, including: When compiling the Linux kernel, the stacked file system is compiled into the kernel driver; In the / etc / fstab file of the file system, the first directory where the mounted storage file system is located is designated as the lower-level directory, and the second directory where the application partition is located is designated as the upper-level directory.

3. The method for partitioning and managing the storage medium of an embedded system according to claim 1, characterized in that, Also includes: By writing username and password files to the upper-level directory, the login username and password of the operating system can be modified online.

4. The method for partitioning and managing the storage medium of an embedded system according to claim 1, characterized in that, Also includes: When an application update is needed, obtain the target incremental file required for the upgrade; The target incremental file is written to the parent directory to achieve incremental upgrade.

5. The method for partitioning and managing the storage medium of an embedded system according to claim 4, characterized in that, Also includes: Delete the target incremental file in the upper-level directory to roll back to the state corresponding to the lower-level directory.

6. The method for partitioning and managing the storage medium of an embedded system according to claim 1, characterized in that, Historical operational data includes: log data and historical data, wherein the log data is stored in a first partition of the second storage medium, and the historical data is stored in a second partition of the second storage medium. The method for partitioning the storage medium of the embedded system further includes: Determine if a second storage medium is detected; if not, exit abnormally. If detected, then check whether the second storage medium contains the first partition and the second partition; If the first or second partition does not exist, execute the disk check command to check the disk so that the partition table can be read again and the first and second partitions can be mounted to the corresponding directories. If the mounting result is abnormal, the second storage medium will be repartitioned and remounted.

7. The method for partitioning and managing the storage medium of an embedded system according to claim 6, characterized in that, After repartitioning and mounting the second storage medium, the following steps are also included: If mounting fails, the first and second partitions of the second storage medium will be formatted after repartitioning, and then mounted again. If mounting is successful, the process will exit normally.

8. A storage medium partitioning management device for an embedded system, characterized in that, include: A partitioning module is used to configure the first storage medium of the embedded system as a boot program partition for storing the boot program, a kernel partition for storing the kernel, a file system partition for storing the file system, and an application partition for storing application data; wherein, the embedded system includes a first storage medium and a second storage medium, and the second storage medium is used to store historical running data; The mode setting module is used to deploy the boot program partition, the kernel partition, and the file system partition in read-only mode, and deploy the application partition in read-write mode; The directory mounting module is used to employ a stacked file system, taking the first directory containing the mounted storage file system as the lower-level directory and the writable second directory in the application partition as the upper-level directory. The mount operation execution module is used to perform a stacked file system mount operation during system startup, aggregating the lower-level directory and the upper-level directory into a unified file system view, and mounting the unified file system view to the target mount point. Write operations on files under the target mount point can be redirected to the upper-level directory by the stacked file system.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores a computer program, and the processor executes the storage medium partitioning management method of the embedded system according to any one of claims 1 to 7 when running the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one piece of program code, which is loaded and executed by a processor to implement the storage medium partitioning management method of the embedded system as described in any one of claims 1 to 7.

Images