BiteSizedChunks.comLearn one small thing at a time.
Course contentsShow
← Embedded Systems & Computer Architecture
Lesson 813 of 93611. Introduction to Embedded LinuxFree lesson

Integrating Persistent Storage Partitions

Configure separate writable partitions for logs and configuration data to maintain system integrity while allowing necessary runtime data persistence.

In this lesson, you will learn how to design your embedded storage layout to balance system integrity with the requirement for persistent runtime data.

In high-reliability embedded systems, we often deploy the Root Filesystem (RootFS) as a read-only image to prevent corruption during unexpected power loss or unauthorized tampering. However, applications still need to store device logs, user preferences, and network configurations. To achieve this, we decouple the immutable system code from the mutable data by using separate persistent storage partitions.

Partitioning Strategy

The typical architecture involves mounting the main system partition as ro (read-only) and dedicated data partitions as rw (read-write). For example, you might partition an eMMC or NAND flash device into three distinct areas:

  1. / (RootFS): Mounted read-only.
  2. /etc/config: A persistent partition for runtime settings.
  3. /var/log: A dedicated partition for telemetry and debug data.

By isolating /var/log, you prevent a full log directory from causing a system-wide boot failure. If a log file grows unchecked, only that partition fills up, while your core OS remains functional.

Implementation via fstab

Once you have defined your partitions (e.g., /dev/mmcblk0p2 for configs and /dev/mmcblk0p3 for logs), you map them in your /etc/fstab file within the RootFS. This ensures the system automatically mounts these areas at runtime:

# <device>        <dir>         <type>   <options>    <dump>  <pass>
/dev/mmcblk0p2    /etc/config   ext4     defaults     0       2
/dev/mmcblk0p3    /var/log      ext4     defaults     0       2

When designing this, ensure your application code writes configuration files using atomic operations (e.g., writing to a temporary file and using rename()) to ensure that a power cut does not leave you with a corrupted configuration. By treating the RootFS as an immutable binary and externalizing "state" into these persistent partitions, you significantly improve the robustness of your device in the field, allowing you to update the core OS without wiping critical user or device-specific data.

Key Takeaway: Separating your immutable RootFS from dedicated, persistent data partitions allows you to maintain system integrity while ensuring essential runtime data survives power cycles.