Edge Storage Filesystems 2026:
f2fs vs ext4 vs btrfs vs xfs on Flash

An unattended industrial PC loses power. It comes back with a corrupt root filesystem, a 90-second fsck and a logger that will not mount. The drive gets the blame, and often the drive is innocent: the real cause is a journaling filesystem tuned for spinning disks being asked to run on flash with default mount options. Filesystem and mount-option choice is one of the few genuinely free reliability wins at the edge — it costs a line in /etc/fstab and buys years of uptime.

What Actually Matters on Flash at the Edge

Four properties decide the choice, and they trade against each other:

• Power-loss recovery. Will the volume mount cleanly after an unannounced cut mid-write, and how long does recovery take? A 30-second journal replay on an unattended gateway is an availability defect.
• Write amplification. A log-structured or copy-on-write design can write the same data many times over. On eMMC and small industrial SSDs with modest endurance, filesystem-induced WAF dominates the wear budget.
• TRIM / discard propagation. Does the filesystem free blocks back to the flash translation layer? This is the biggest single lever on long-term endurance, as covered in our write amplification guide.
• Tooling maturity. Repair tools, operator familiarity, Yocto/Buildroot support and vendor kernel patches. An exotic filesystem that nobody can repair in the field is a liability, however elegant.

The Contenders Compared

The short version: ext4 is the correct default for systems where operators need familiarity and repair is a known quantity. f2fs is the correct choice when the storage is eMMC, microSD or a modest industrial SSD and the box may lose power at any moment — it was designed by Samsung for exactly this and its roll-forward recovery means a cut mid-write costs a mount, not a repair. btrfs earns its complexity when you want snapshots for OTA rollback or checksums that catch silent corruption. xfs shines on large sequential streams — the classic case being a video archive — and is a poor fit for millions of tiny files on a small flash device.

Mount Options Do More Than the Filesystem Choice

Most field failures come from defaults, not from the wrong filesystem. These are the options worth an explicit decision on every industrial image:

One more pattern deserves its own heading, because it removes the entire class of problem.

The Read-Only Rootfs + Overlay Pattern

For appliances that should never corrupt — gateways, HMI panels, cameras, anything bolted to a wall — mount the root filesystem read-only and place a small writable overlay on a separate partition. The OS image becomes immutable, power loss cannot damage it, OTA becomes "swap the overlay-free partition and reboot," and the only writable surface is a bounded data partition you sized deliberately.

A workable arrangement:

• Read-only rootfs (ext4 or squashfs), atomic A/B for OTA — never written at runtime.
• Small writable overlay for /etc and service state, on f2fs with aggressive cleaning.
• Separate data partition for logs and captures, capped and rotated, on the highest-endurance device in the box.
• RAM-backed tmpfs for /tmp and /var/run, so transient writes never reach flash.

Combined with a real-time clock that survives the cut, this pattern turns "did the filesystem survive?" into a design question you answer once, rather than an incident you investigate repeatedly.

Selection Checklist

1. Match filesystem to media. f2fs for eMMC/microSD, ext4 for industrial SSD/NVMe, UBIFS for raw NAND, btrfs when you need snapshots or checksums.
2. Set mount options explicitly in the image — noatime, a considered commit=, and a discard strategy. Do not ship distribution defaults to a field device.
3. Prove the power-cut behaviour. Cut power mid-write on a bench unit fifty times and confirm every one boots. This test is cheap and finds more defects than any datasheet review.
4. Cap and rotate every writable partition, and alarm on free space before it reaches the write cliff.
5. Keep a read-only rootfs with A/B OTA on any device where a failed boot means a site visit.
6. Verify TRIM reaches the device with lsblk -D and confirm with SMART counters after a trim cycle.
7. Pick storage hardware with power-loss protection for partitions holding a journal or a database — the filesystem cannot fully protect a write the controller was still buffering.

QSCompute supplies the wide-temperature industrial SSDs, eMMC and NVMe modules these designs run on, along with the fanless industrial PCs, ARM gateways and Jetson edge systems around them — specified against your workload, power environment and service life, with DDP shipping to 85+ countries.