Why Embedded Devices Corrupt on Power Loss: Read-Only Rootfs and Power-Fail Data Protection (2026)

Key takeaway: corruption on power loss is rarely "the filesystem is bad" — it is "the writable area was designed carelessly". Make the root filesystem read-only, confine persistent data to a small disciplined partition, and replace ad-hoc writes with batched commits. That solves most of it; the rest is covered by the tens of milliseconds a brown-out detector buys you and by A/B boot partitions.

1. What a power cut actually damages

• Half-updated metadata: writing a file in ext4 touches inode, block bitmap, directory entry and journal. A cut in the window where data is on disk but metadata is not produces files with the right length and holes inside, or directory entries pointing at freed blocks. Journalling narrows the window; it does not close it;
• Unflushed eMMC/UFS caches: the device keeps a write cache and an FTL mapping table. The host thinks the write completed; it is still in cache. On power loss the cache is gone and the mapping table may be mid-update — the result is unreadable or garbled blocks;
• Interrupted erase: eMMC erases in blocks and programs in pages. Losing power mid-erase can leave a half-erased block that bad-block management never records;
• Application-level half-writes: a configuration file, a recording index or a database transaction written halfway. The filesystem is fine; the business data is not;
• Broken boot chain: a cut during an upgrade corrupts bootloader or kernel partitions, and the device will not boot at all — the only failure that forces a return to factory.

These five need separate treatment; a single sync solves none of them completely.

2. Overall strategy: three layers

Layer	Content	Mount	Power-loss risk
Boot	Bootloader, kernel, device tree	Dedicated read-only partitions	Highest during upgrades — needs A/B or recovery
System	rootfs (libraries, apps, assets)	Read-only image + RAM overlay	Essentially none; upgrades switch partitions
Data	Config, business records, logs, indexes	Dedicated writable partition or DB	The real risk area — needs write discipline

With this split, damage is confined to the data layer. The system layer can never be corrupted by runtime writes, and the boot layer is only exposed during the minutes an upgrade takes. Such a device can be unplugged a hundred times and the worst outcome is losing the last few seconds of data — not failing to boot.

3. Building a read-only root filesystem

• Choose squashfs or erofs: both are compressed read-only filesystems. erofs is better suited to embedded random reads and memory footprint; squashfs has the more mature tooling. Read-only means no runtime writes and therefore no metadata corruption;
• Put the writable part on overlayfs: a read-only lower layer plus an upper layer on tmpfs (RAM) or a small writable partition. tmpfs returns to factory state on reboot, which suits devices configured by a platform; a writable partition suits sites that must keep local changes;
• Handle directories individually: network and device configuration under /etc, business data under /var/lib, logs under /var/log, temporary files under /tmp. The first two persist; the last two belong on size-limited tmpfs;
• Change the upgrade path: a read-only rootfs cannot be edited in place. Write a whole partition and switch the boot entry (A/B), or reflash from a recovery partition — the same mechanism as the A/B scheme in Firmware OTA and A/B Upgrades;
• Do not treat overlay as a cure-all: an upper layer on tmpfs loses everything on a cut; an upper layer on a writable partition can still corrupt. overlayfs protects system files, not data.

4. Designing the writable data partition

• Keep it small: a larger writable partition means slower fsck and a bigger blast radius. Size it from real data volume plus 20–30% headroom, not "the disk is big anyway";
• Filesystem choice: ext4 with ordered mode and a sensible commit interval is the safe default; F2FS is friendlier to flash but its recovery behaviour must be tested; UBIFS for raw NAND. Never store critical data on FAT32 — it has no journal;
• Reserve space: ext4 reserves 5% for root by default and that is tunable; also keep enough free blocks so fragmentation and write amplification do not explode near full;
• Mount options: noatime removes pointless writes; commit= trades endurance against data loss window; errors=remount-ro stops writing instead of continuing on a damaged filesystem;
• Bad blocks and endurance: read eMMC life and bad-block counters (EXT_CSD and vendor commands) periodically and report remaining life as part of device health, rather than waiting for failure;
• Write amplification: repeatedly rewriting the same small area is the biggest threat to eMMC life. Append logs and archive periodically instead of overwriting one file.

5. Write discipline at application level

This layer is most often skipped, yet "settings disappeared" and "recording index is corrupt" usually originate here.

• Atomic replacement: never overwrite a config file directly. Write a temp file → fsync it → rename over the target → fsync the directory. rename is atomic within a filesystem, so after a cut you get either the old file or the new one, never half a JSON document;
• fsync the directory too: fsyncing only the file leaves the rename's directory entry in cache; after a cut the file exists but has no name;
• Batch instead of per-record writes: aggregate sensor data, heartbeats and counters in memory and flush by time or count. fsync on every record wears flash and stalls the main loop;
• Append and rotate logs: sequential appends are far kinder to flash than random rewrites. Cap total size and rate so an error storm cannot fill the partition;
• Use transactions and WAL in databases: SQLite in WAL mode with a sensible synchronous level, with critical writes wrapped in transactions. Do not keep business records in a hand-rolled CSV;
• Sequence numbers: tag every record with a monotonic sequence so after a cut you can tell exactly where the last record ended.

6. Brown-out detection and graceful shutdown

• Where to detect: the Power Fail / PGOOD signal of the upstream supply, a PMIC undervoltage interrupt, or an ADC on the input rail. Not the reset that happens after the fact;
• Where hold-up energy comes from: input capacitance, supercapacitors or a hold-up module, sized from measured shutdown energy times margin;
• Shutdown order: stop acquisition → stop business threads → commit transactions → sync → unmount or remount-ro the data partition → notify the host → power off. Wrong order is as good as none;
• When there is no time: degrade — remount the data partition read-only immediately and sacrifice the last block of data to keep the filesystem intact;
• Repeated cycling: the field is not one clean cut but a grid dip causing several consecutive drops. Use UVLO with hysteresis so the supply does not hiccup around the threshold — the same issue as in Wide-Input Power and Protection.

7. eMMC considerations

• Cache flush: issue a flush after critical writes so data moves from device cache into flash. Confirm the device's reliable-write behaviour at selection time;
• "Industrial grade" is not power-loss protection: it denotes temperature range and endurance class, not immunity to cuts. Protection is a system design property;
• Endurance budget: estimate total bytes written from daily volume × write amplification × design life, then compare with the device TBW. Monitoring actual writes beats a one-off calculation;
• Alignment and over-provisioning: align partitions to erase-block boundaries to avoid cross-block writes; reserved OP space markedly improves performance and endurance.

8. Proving it actually survives

• Random power-cut rig: a relay or programmable supply cutting power at random intervals covering boot, writes and upgrades, repeated hundreds of times;
• Write down the pass criteria: after every power-up — boots normally, filesystem check passes, config and records readable, sequence numbers continuous, no new bad blocks. All five or it does not count;
• Target the critical windows: cut power specifically during partition writes in an upgrade, config saves and database commits — the windows that actually break;
• Run long enough: many problems do not appear in the first few dozen cycles;
• Read the logs: after each recovery check filesystem warnings, read-only remounts and I/O error counters — the early signals of impending failure.

9. Common pitfalls

• Writable rootfs with fsck as the safety net. fsck repairs metadata, not business data, and a large partition can take tens of seconds to check at boot;
• Overwriting config directly. One cut yields half a JSON file, the next boot falls back to defaults, and the site reports "all settings are gone";
• Uncapped logs. An error storm fills the partition, the filesystem goes read-only and the business stops;
• sync without sequencing. Calling sync while producers keep writing means you sweep while rubbish is still being generated;
• No A/B for upgrades. A cut mid-upgrade bricks the unit and forces a return — the most expensive way to save cost.

10. FAQ

• Q1: Does a read-only rootfs hinder debugging? During development use a writable overlay or disable read-only temporarily; the production image must be read-only. That is the part that matters.
• Q2: Does putting data on tmpfs make it immune? It removes corruption but guarantees loss. tmpfs suits regenerable data (caches, temp files), not configuration or records.
• Q3: Are supercapacitors mandatory? No. If losing the last few seconds is acceptable and the filesystem uses read-only plus atomic writes, the design is stable without them. Add hold-up only where zero loss is required;
• Q4: ext4 or F2FS? Prefer ext4 for mature tooling and diagnosability; F2FS wins in write-heavy workloads but its recovery behaviour must be validated with your own power-cut tests;
• Q5: Can you implement this? Yes. Hongyin Technology covers read-only rootfs, data-partition planning, atomic-write wrappers, brown-out detection and random power-cut testing during firmware customisation, with test records on delivery. Send your device form factor and data criticality for advice within 48 hours.

11. Related solutions & contact

Related solutions: IoT Edge Gateway、Edge AI Box、Environmental Monitoring Station. Further reading: Firmware OTA and A/B Upgrades、Storage and Boot Media Selection、7×24 Long-Run Stability Design.

Shenzhen Hongyin Technology Co., Ltd. (HONGYIN TECH) provides embedded project customization on RK3588/RK3576/RK3568 platforms — free requirement review, engineer-direct communication and low-volume ordering. Send your requirement list and receive selection advice and quotes within 48 hours.
phone +86 13728726926 | email sales@hoyin-tech.com | website www.hoyin-tech.com | address: Room 301, Building A, Fanrong Science Park, Sanwei Community, Hangcheng Street, Bao'an District, Shenzhen, China.