PREV_LEC | NEXT_LEC

What You Will Learn

• How to classify your storage requirements into three categories before touching any filesystem
• Which filesystems are viable on NOR, NAND, and eMMC-based boards, and why
• When squashfs and UBI mtdblock emulation save you real flash space
• Why tmpfs is the only sane choice for volatile data, and how much RAM it can quietly consume
• How to build a small original script that inspects your board and recommends a filesystem, based on embedded Linux filesystem selection best practices

Prerequisites

• Basic familiarity with MTD devices (/proc/mtd, mtdblock) — covered in earlier lectures of this storage course
• A working embedded Linux target or QEMU setup with a mounted root filesystem
• Comfort with basic shell scripting

Three Buckets, Not Twenty Filesystems

The mistake most beginners make is trying to memorize every embedded filesystem before deciding anything. That’s backwards. The right first step in any embedded Linux filesystem selection process is to sort your data into exactly three buckets, because the bucket — not the filesystem name — is what actually drives the decision.

Once your data is sorted, the filesystem choice nearly falls out on its own — you just need to know which options your physical storage medium supports.

Matching Filesystems To Physical Media

Raw flash (NOR and NAND) behaves nothing like a block device internally — it has erase blocks, bad blocks, and a limited number of program/erase cycles, which is why it needs a filesystem that understands flash directly, or a translation layer underneath a conventional one. eMMC and modern NAND-based storage often expose a Flash Translation Layer (FTL) in hardware, which is why they can happily run filesystems designed for spinning disks.

Read-Only Root: The squashfs Shortcut

Any of the filesystems above can be mounted with the ro flag if your data is permanent and read-only — but that wastes space, because UBIFS and ext4 both carry journaling and metadata overhead your device will never use if nothing is ever written. squashfs is a purpose-built, heavily compressed, read-only filesystem that avoids all of that overhead, and on NAND it pairs naturally with UBI’s mtdblock emulation, which quietly absorbs bad-block remapping underneath it. For a root filesystem that never changes after manufacturing, squashfs is almost always the right call.

Volatile Data: There’s Only One Right Answer

For temporary storage like /tmp, scratch directories, or PID files, the book’s advice still holds today: use tmpfs. It lives entirely in RAM, costs zero flash write cycles, and disappears cleanly on reboot. The only caveat is that an unbounded tmpfs mount can exhaust your device’s RAM if a runaway process starts writing large files into it — always cap it with a size= mount option in production.

# Mount /tmp as tmpfs, capped at 32 MB, on a resource-constrained target
mount -t tmpfs -o size=32m,mode=1777 tmpfs /tmp

# Verify
mount | grep tmpfs
# tmpfs on /tmp type tmpfs (rw,relatime,size=32768k,mode=1777)

Original Tool: A Filesystem Advisor Script

Rather than repeating the book’s flowchart from memory every time you bring up a new board, here’s a small original helper — ep_fs_advisor.sh — that inspects the running target and prints a filesystem recommendation for each bucket. It’s deliberately simple so you can extend it for your own hardware.

#!/bin/sh
# ep_fs_advisor.sh - suggests a filesystem strategy based on detected storage
# Part of the EmbeddedPathashala free embedded Linux course

echo "== EP Storage Advisor =="

if [ -e /proc/mtd ] && grep -qi "nand" /proc/mtd 2>/dev/null; then
    echo "Detected: raw NAND flash"
    echo " -> Read-write data:  UBIFS (preferred) or JFFS2"
    echo " -> Read-only rootfs: squashfs over UBI mtdblock emulation"
elif [ -e /proc/mtd ]; then
    echo "Detected: raw NOR flash"
    echo " -> Read-write data:  UBIFS or JFFS2"
    echo " -> Read-only rootfs: squashfs"
elif [ -e /dev/mmcblk0 ]; then
    echo "Detected: eMMC / managed NAND"
    echo " -> Read-write data:  ext4 or F2FS"
    echo " -> Read-only rootfs: squashfs (optional, saves space)"
else
    echo "No flash device detected on this run"
fi

echo " -> Volatile data (/tmp, /var/log): tmpfs, always size-capped"

$ chmod +x ep_fs_advisor.sh
$ ./ep_fs_advisor.sh
== EP Storage Advisor ==
Detected: raw NAND flash
 -> Read-write data:  UBIFS (preferred) or JFFS2
 -> Read-only rootfs: squashfs over UBI mtdblock emulation
 -> Volatile data (/tmp, /var/log): tmpfs, always size-capped

Real-World Use Case: An Industrial NAND Gateway

Consider a 512 MB NAND-based industrial gateway that logs sensor readings continuously. Using the bucket model: the bootloader and kernel live on a small UBIFS partition (permanent, rarely written), the application binaries and libraries sit on a squashfs partition (permanent, read-only, saves flash and boot time), sensor logs get written to a UBIFS partition mounted specifically for that purpose with wear-leveling in mind, and /var/log and /tmp are tmpfs so the thousands of daily log-rotation writes never touch flash at all. This single layout, built purely from the three-bucket model, is representative of the pattern used across most production NAND devices today.

Common Mistakes And Troubleshooting

• Mounting ext4 directly on raw NAND/NOR — ext4 has no wear-leveling logic and no bad-block awareness; it will corrupt raw flash over time. Only use it on eMMC/managed media with a hardware FTL.
• Forgetting to cap tmpfs size — an uncapped tmpfs can consume all available RAM and trigger the OOM killer under heavy logging.
• Using JFFS2 on multi-gigabyte NAND — JFFS2’s mount-time scan becomes painfully slow as capacity grows; switch to UBIFS well before you hit that wall.
• Skipping bad-block handling on raw NAND — always go through UBI/MTD layers; never write a generic block filesystem straight onto raw NAND.

Best Practices

• Decide the three buckets before you decide any filesystem name.
• Keep read-only content on squashfs whenever it never changes post-manufacture.
• Always size-cap tmpfs mounts explicitly.
• Re-evaluate JFFS2 vs UBIFS as your NAND capacity grows across product revisions.

Performance And Security Considerations

Read-only squashfs partitions also double as a security boundary — if an attacker can’t write to the root filesystem, a large class of persistence techniques simply doesn’t work. On the performance side, UBIFS’s write-back caching (covered in an earlier lecture) usually outperforms JFFS2 significantly on writes, at the cost of slightly higher RAM usage, which matters on very small targets.

Summary And Key Takeaways

• Classify data first: permanent read-write, permanent read-only, or volatile.
• NOR and NAND need flash-aware filesystems (UBIFS/JFFS2/YAFFS2); eMMC can use conventional ones (ext4/F2FS).
• squashfs is almost always correct for a static, read-only root filesystem.
• tmpfs is the only correct choice for volatile data — just cap it.

Conclusion

Filesystem selection stops being confusing the moment you stop asking “which filesystem is best” and start asking “which bucket does this data belong to, and what medium is it sitting on.” Apply that two-question framework consistently and you’ll make the right call on every future board, regardless of how unfamiliar the flash chip datasheet looks. In the next lecture in this free Linux kernel development course, we move from choosing a filesystem to actually updating it safely in the field.

FAQ

PREV_LEC | NEXT_LEC