ext4 vs F2FS on SBC Root Filesystems: Power-Loss Behaviour, Performance, and When to Switch

How ext4 Journaling Works on Flash

ext4 writes metadata changes (and optionally data) to a journal before committing them to the main filesystem. This guarantees consistency after a crash — fsck replays the journal and the filesystem is clean within seconds.

The problem on flash media: every journal write is a random write to a fixed region of the storage. SD card controllers must erase a large block to update a small journal entry. This creates write amplification — the controller internally writes 10-100x more data than the OS requested.

Practical consequences:

• The journal region wears faster than the rest of the card
• Default 5-second commit interval means journal writes every 5 seconds, 24/7
• The ext4 journal on a 32 GB card occupies 128 MB — on a card with 3,000 P/E cycles, that region can wear out in under a year of heavy use

How F2FS Log-Structured Writes Work

F2FS (Flash-Friendly File System) was designed by Samsung specifically for NAND flash storage. Instead of updating data in place, it writes to new locations sequentially — a log-structured approach that works with the flash hardware instead of against it.

Key differences from ext4:

• No fixed journal region — writes are distributed across the device
• Append-only writes — new data goes to clean segments, avoiding read-modify-erase cycles
• TRIM/discard awareness — F2FS tells the controller which blocks are free, improving wear leveling
• Checkpoint recovery — instead of a journal, F2FS uses periodic checkpoints. After a crash, it rolls back to the last checkpoint.

Power-Loss Behaviour Comparison

This is the critical comparison for always-on SBCs that may lose power unexpectedly.

Performance on SD and eMMC

Tested on a Banana Pi Pro with Samsung PRO Endurance 32 GB SD card, kernel 6.6 LTS:

The standout result: random 4K writes are 2x faster on F2FS. This is the I/O pattern that dominates system workloads — logging, package management, database writes. On SATA drives the difference narrows, but on SD cards and eMMC, F2FS has a meaningful advantage.

When ext4 Is the Safer Choice

• You're running a critical production system and can't risk any filesystem surprises
• You need maximum compatibility with recovery tools and boot loaders
• Your root is on SATA (where ext4's write amplification penalty is irrelevant)
• You're dual-booting or need to mount the filesystem from multiple OSes
• You want the most extensively tested crash recovery behavior

When F2FS Is the Faster Choice

• Root filesystem lives on SD card or eMMC and will stay there
• System does heavy random writes (logging, databases, package installs)
• You want to reduce SD card wear (F2FS's log-structured writes cause less write amplification)
• You're running Armbian or Debian with kernel 6.6+ (F2FS is mature in these kernels)
• Board doesn't have SATA, so SD is your only option

Migration: ext4 to F2FS

Prerequisites

• A second SD card or USB drive for the backup
• Another computer to perform the conversion (you can't reformat your own root while running)
• F2FS tools installed: sudo apt install f2fs-tools

Procedure

# 1. Back up the entire SD card
sudo dd if=/dev/mmcblk0 bs=4M status=progress | gzip > full-backup.img.gz

# 2. From another machine, mount the SD card
# Identify the root partition (usually partition 1)
lsblk /dev/sdX

# 3. Copy the root filesystem to a temporary location
sudo mkdir -p /mnt/old-root /mnt/new-root
sudo mount /dev/sdX1 /mnt/old-root
sudo rsync -axHAWXS --numeric-ids /mnt/old-root/ /tmp/rootfs-backup/
sudo umount /mnt/old-root

# 4. Format the root partition as F2FS
sudo mkfs.f2fs -l rootfs -O extra_attr,inode_checksum,sb_checksum /dev/sdX1

# 5. Mount and restore
sudo mount /dev/sdX1 /mnt/new-root
sudo rsync -axHAWXS --numeric-ids /tmp/rootfs-backup/ /mnt/new-root/

# 6. Update fstab on the new root
sudo nano /mnt/new-root/etc/fstab
# Change the root line:
# OLD: /dev/mmcblk0p1  /  ext4  defaults,noatime  0  1
# NEW: /dev/mmcblk0p1  /  f2fs  defaults,noatime  0  0

# 7. Update boot configuration
# For Armbian:
sudo nano /mnt/new-root/boot/armbianEnv.txt
# Add or change: rootfstype=f2fs

# For manual boot.cmd, change rootfstype=ext4 to rootfstype=f2fs
# Then recompile boot.scr

sudo umount /mnt/new-root

Kernel support check

Before migrating, confirm your kernel has F2FS compiled in (not just as a module that might not load during early boot):

# Check if F2FS is available
cat /proc/filesystems | grep f2fs
# Or check kernel config
zcat /proc/config.gz | grep CONFIG_F2FS
# Should show CONFIG_F2FS_FS=y (built-in) or =m (module)

Verification Steps

# After booting on the F2FS root:

# 1. Confirm filesystem type
mount | grep "on / "
# Should show: /dev/mmcblk0p1 on / type f2fs

# 2. Check F2FS status
cat /sys/fs/f2fs/mmcblk0p1/segment_info 2>/dev/null | head -5

# 3. Run a quick write test
dd if=/dev/zero of=/tmp/test bs=4k count=10000 conv=fsync
rm /tmp/test

# 4. Check dmesg for F2FS messages
dmesg | grep -i f2fs
# Should show clean mount messages, no errors

# 5. Verify discard/TRIM support (if card supports it)
cat /sys/fs/f2fs/mmcblk0p1/discard_granularity 2>/dev/null

Rollback to ext4

If F2FS causes problems, restore your backup:

# Flash the backup image
gunzip -c full-backup.img.gz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync
sudo sync

The backup image contains the original ext4 partition and all boot configuration. One flash restores everything to the pre-migration state.