Choosing a Root Filesystem Format for Embedded Linux
The root filesystem format is a critical, often overlooked, decision in embedded Linux development. It dictates how your system boots, handles updates, behaves during power interruptions, and manages wear on flash storage. While vendor Build System Packages (BSPs) often default to ext4, this choice carries significant long-term consequences. Developers must consider the underlying storage hardware, update strategy, and required system behavior to select the optimal format from realistic candidates: ext4, f2fs, squashfs with overlayfs, and UBIFS.
Understanding the Candidates
Each filesystem offers distinct advantages and disadvantages, making the choice dependent on specific product requirements and hardware constraints.
Ext4
Ext4 remains a widely adopted and familiar choice. Its strengths lie in its maturity, extensive tooling for recovery, and general-purpose flexibility. However, it's not inherently designed for the specific challenges of embedded systems, particularly concerning flash wear and atomic updates. For products requiring a writable root filesystem and where ease of recovery using standard Linux tools is paramount, ext4 is a sensible, albeit not always optimal, choice.
F2FS (Flash-Friendly File System)
Designed by Samsung specifically for NAND flash memory, F2FS aims to mitigate flash wear by employing a log-structured approach. It offers better performance and longevity on flash storage compared to traditional filesystems like ext4. However, its tooling and ecosystem are less mature than ext4's, and it's not suitable for raw NAND flash, which requires a different layer of abstraction.
Squashfs with OverlayFS
Squashfs is a highly compressed, read-only filesystem. When paired with OverlayFS, it forms a powerful combination for embedded systems. The read-only squashfs provides a stable, immutable root, ensuring system integrity. OverlayFS then creates a writable layer on top, typically mounted to a separate partition. This setup is ideal for systems with A/B update schemes, allowing for atomic updates and easy rollbacks. It also enhances security by making the core system read-only, preventing accidental or malicious modification. This is the default recommended approach for managed flash like eMMC.

UBIFS (Unsorted Block Image File System)
UBIFS is designed to work on top of UBI (Unsorted Block Images), a layer that manages raw NAND flash. It is the de facto standard for raw NAND storage, providing wear-leveling and error correction capabilities essential for this type of memory. If your hardware uses raw NAND flash, UBIFS is not just a choice but a necessity. It offers good performance and reliability on raw flash but lacks the broad compatibility and tooling of ext4.
Hardware Dictates the Initial Choice
The fundamental constraint for selecting a root filesystem format is the underlying storage hardware. Raw NAND flash memory requires a specific software stack to manage its peculiarities, such as bad blocks and wear leveling. For raw NAND, the combination of UBI and UBIFS is the only viable option. Attempting to use filesystems like ext4 or f2fs directly on raw NAND will lead to data corruption, premature wear, and system instability. UBI acts as a layer that abstracts the raw flash, presenting clean blocks to UBIFS.
Managed flash devices, such as eMMC, SD cards, and SSDs, have built-in controllers that handle wear leveling and bad block management. This simplifies the software layer. On these devices, you have more flexibility. Ext4 and F2FS are generally compatible, with F2FS often offering better performance and endurance due to its flash-aware design. Squashfs with OverlayFS is also a strong contender for managed flash, especially when combined with robust update strategies.
Update Strategies and System Behavior
Your chosen update strategy significantly influences the filesystem decision. Systems employing A/B updates, where a new firmware image is written to an inactive partition while the system runs on the active one, pair exceptionally well with an immutable root filesystem. Squashfs is ideal here because it's read-only and compressed, reducing image size. The OverlayFS writable layer can then store system logs, configuration changes, and temporary files. During an update, the system simply switches to the new, verified squashfs image and a fresh overlay. This provides a high degree of reliability and allows for quick rollbacks if an update fails.
If your system requires a constantly writable root filesystem—perhaps for dynamic configuration or frequent application installs directly to the root—then ext4 or f2fs become more appealing. However, writable roots increase the complexity of atomic updates. Power-cut behavior is another critical consideration. Filesystems with robust journaling (like ext4) or copy-on-write mechanisms can often recover more gracefully from unexpected power loss. F2FS also incorporates features to handle this, while squashfs, being read-only, is inherently resilient to corruption during power loss on the root itself, with the writable overlay being the only part susceptible.
Flash Wear and Longevity
Flash memory has a finite number of write cycles. Filesystems that minimize writes and distribute them evenly can significantly extend the lifespan of the storage medium. UBIFS, by design, works with the UBI layer to provide excellent wear leveling on raw NAND. F2FS is also optimized for flash, aiming to reduce wear compared to ext4. Ext4, while generally robust, can be more prone to write amplification and uneven wear if not carefully managed, especially with frequently changing data in the root filesystem.
The read-only nature of squashfs is a major advantage for flash longevity, as the core system files are never written to after being flashed. All writes are confined to the overlay partition, which can be managed separately. This separation allows for tailored wear-leveling strategies for the writable data.
Choosing the Right Fit
The decision matrix for choosing a root filesystem format for embedded Linux should consider these factors:
- Raw NAND Flash: UBIFS on UBI is the mandatory choice.
- Managed Flash (eMMC, SD, SSD):
- Immutable Root + A/B Updates: Squashfs with OverlayFS is the preferred solution for robustness, security, and simplified updates.
- Writable Root + Familiar Recovery: Ext4 is a viable option if immutability and advanced update schemes are not critical, and standard recovery tools are valued.
- Writable Root + Flash Optimization: F2FS offers better flash endurance and performance than ext4 for writable roots on managed flash, but with a less mature ecosystem.
Ultimately, the best root filesystem format is one that aligns with the hardware capabilities, development team's expertise, system update strategy, and the product's operational requirements for reliability and longevity.
