What You Will Learn

• Why eMMC and SD cards behave differently from raw NAND, and why that matters for filesystem choice
• How F2FS’s log-structured design reduces write amplification on managed flash
• How to build, mount, and tune an F2FS partition on the latest stable kernel
• Why FAT16/FAT32 still matter on modern embedded boards, and where they break down
• How the mainline in-kernel exFAT driver changes the story the old textbooks tell
• How to pick between F2FS, ext4, and FAT for a given storage requirement

Prerequisites

This lesson assumes you have already worked through the earlier storage lessons in this free embedded Linux course: partitioning MTD/eMMC devices, building UBI volumes, and creating ext4 images. You should be comfortable cross-compiling kernel modules and flashing a target board over serial or SSH.

Managed Flash Needs A Different Filesystem

Everything you have built so far in this course targeted raw NAND or NOR flash through MTD, where the filesystem itself is responsible for wear leveling and bad block management. eMMC, SD cards, and USB flash drives are different: they contain an on-die controller called a Flash Translation Layer (FTL) that already does wear leveling internally. From the kernel’s point of view, these devices look like ordinary block devices — /dev/mmcblk0, not an MTD character device.

That changes the filesystem design problem. On managed flash you no longer need JFFS2- or UBIFS-style wear leveling in the filesystem itself, but you still benefit enormously from a filesystem that writes in a pattern the FTL is good at handling: large, sequential, append-only writes rather than small random overwrites. That is exactly the gap F2FS was designed to fill.

How F2FS Works

F2FS stands for Flash-Friendly File System. It was developed at Samsung and merged into mainline Linux in version 3.8. Unlike ext4, which updates data and metadata roughly in place, F2FS is a log-structured filesystem: every write, whether it is file data or metadata, is appended to a rotating set of “log” areas rather than overwritten in place.

The filesystem organizes storage into fixed-size segments that match common erase-block and page sizes on eMMC/SD media. New writes are packed sequentially into the current open segment. When a segment fills up, F2FS moves to the next one, and a background garbage collector reclaims segments that are mostly full of stale (overwritten or deleted) data by copying the still-valid blocks forward and freeing the segment for reuse.

Because writes never land on the same physical location twice in a row, F2FS avoids the read-modify-erase-write cycle that hurts both performance and flash endurance on managed media. In practical terms this means fewer erase cycles per logical write, which extends the life of the flash and, on many eMMC parts, noticeably improves throughput compared to ext4 for the same workload — the gap is most visible under small, frequent writes such as logging or database-style updates.

F2FS also keeps two copies of its checkpoint metadata and uses roll-forward recovery after an unclean shutdown, so it tolerates power loss reasonably well without the extra write overhead of a full journal on every transaction.

Building And Mounting An F2FS Filesystem

On the latest stable kernel, F2FS support is enabled with CONFIG_F2FS_FS=y (or as a module). The userspace tools live in the f2fs-tools package, which your Buildroot or Yocto build should already include if you selected F2FS support.

# create an F2FS filesystem on an eMMC partition, with a volume label
mkfs.f2fs -l rootfs /dev/mmcblk0p2

# mount it
mount -t f2fs /dev/mmcblk0p2 /mnt

# check filesystem health and fragmentation
fsck.f2fs -y /dev/mmcblk0p2

# see live segment/GC statistics once mounted
cat /sys/kernel/debug/f2fs/status

Two mount options are worth knowing for embedded targets. discard tells F2FS to issue TRIM commands as it frees segments, which helps the FTL reclaim space faster — but only enable it if you have confirmed your storage device supports discard without a large latency penalty. mode=lfs forces strictly sequential allocation, which is the safer default for small, low-power devices; the alternative mode=adaptive lets F2FS mix in in-place updates for better performance on larger, faster storage.

mount -t f2fs -o discard,mode=lfs /dev/mmcblk0p2 /mnt

A Small Demo: Writing To F2FS From A Kernel Module

To make this concrete, here is a minimal original demo — a character device driver, prefixed ep_, that appends timestamped log lines to a file on an F2FS-mounted partition every time it is written to. It is deliberately small so you can trace exactly what happens on disk with filefrag or f2fs_io.

// ep_f2fs_logger.c - appends writes to /mnt/ep_log.txt on an F2FS mount
#include <linux/init.h>
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/miscdevice.h>
#include <linux/uaccess.h>
#include <linux/namei.h>

#define EP_LOG_PATH "/mnt/ep_log.txt"

static ssize_t ep_log_write(struct file *filp, const char __user *buf,
                             size_t len, loff_t *off)
{
    struct file *logf;
    loff_t pos = 0;
    ssize_t ret;
    char *kbuf = kmalloc(len, GFP_KERNEL);

    if (!kbuf)
        return -ENOMEM;
    if (copy_from_user(kbuf, buf, len)) {
        kfree(kbuf);
        return -EFAULT;
    }

    logf = filp_open(EP_LOG_PATH, O_WRONLY | O_CREAT | O_APPEND, 0644);
    if (IS_ERR(logf)) {
        kfree(kbuf);
        return PTR_ERR(logf);
    }

    ret = kernel_write(logf, kbuf, len, &pos);
    filp_close(logf, NULL);
    kfree(kbuf);
    return ret;
}

static const struct file_operations ep_log_fops = {
    .owner = THIS_MODULE,
    .write = ep_log_write,
};

static struct miscdevice ep_log_dev = {
    .minor = MISC_DYNAMIC_MINOR,
    .name  = "ep_f2fs_logger",
    .fops  = &ep_log_fops,
};

static int __init ep_log_init(void)
{
    return misc_register(&ep_log_dev);
}

static void __exit ep_log_exit(void)
{
    misc_deregister(&ep_log_dev);
}

module_init(ep_log_init);
module_exit(ep_log_exit);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("EmbeddedPathashala demo: append writes onto an F2FS mount");

$ echo "boot event" > /dev/ep_f2fs_logger
$ cat /mnt/ep_log.txt
boot event
$ f2fs_io getflags /mnt/ep_log.txt
Get a flag on /mnt/ep_log.txt ret=0, flags=00000000

FAT16, FAT32, And Why exFAT Changed The Story

While F2FS is the modern choice for a device’s own root filesystem or data partition, FAT is still the filesystem you cannot avoid whenever your device needs to exchange a removable card or USB stick with a laptop, camera, or another embedded board. Most SD cards ship pre-formatted as FAT32, and some SoC boot ROMs — certain TI and NXP parts among them — insist on a FAT partition to hold the second-stage bootloader before Linux is even running.

Linux supports FAT16 through the msdos filesystem driver and both FAT16 and FAT32 through the more capable vfat driver, which adds long filename support. For an embedded product you will almost always want vfat.

mount -t vfat /dev/mmcblk1p1 /mnt/sdcard

FAT32’s biggest practical limitation is a 32 GiB volume-size ceiling imposed by common formatting tools (the on-disk format can technically go larger, but most tools refuse). For anything bigger — larger SDXC cards, USB drives above 32 GiB — the industry standard is Microsoft’s exFAT format.

Here is where this lesson has to correct an outdated assumption you may have read elsewhere: older references claim exFAT needs a proprietary FUSE driver because there was no in-kernel support. That has not been true since kernel 5.4, when Microsoft published the exFAT specification and an in-kernel driver was merged as CONFIG_EXFAT_FS. On any current stable kernel you can mount exFAT natively:

mount -t exfat /dev/sda1 /mnt/usb

You should still check your product’s legal requirements before shipping exFAT support commercially, since patent licensing terms for exFAT exist independently of whether the driver ships in the kernel — but the “no kernel driver” objection from the old textbooks is simply out of date.

Choosing Between F2FS, ext4, And FAT

Common Mistakes And Troubleshooting

• Enabling discard blindly. Some low-cost eMMC parts implement TRIM so slowly that every delete stalls the whole system. Benchmark before enabling it in production.
• Using F2FS on a bad-block-prone raw NAND without UBI underneath. F2FS assumes a managed device; on raw NAND you still need UBI (or MTD) plus a NAND-aware filesystem like UBIFS.
• Assuming any FAT partition can hold files over 4 GiB. FAT32’s per-file limit is 4 GiB regardless of volume size; only exFAT and NTFS lift that.
• Forgetting fsck.f2fs after unclean shutdowns during development. F2FS recovers automatically at mount time in most cases, but running an explicit check catches slow-building fragmentation early.

Best Practices

• Use F2FS for your writable data/root partition on eMMC or SD-backed products; keep FAT restricted to boot partitions and removable interchange media.
• Periodically run f2fs_io‘s GC trigger or rely on the kernel’s background GC thread rather than disabling garbage collection to “save CPU” — deferred GC just moves the cost to a worse moment.
• Always mount FAT boot partitions with errors=remount-ro-style safety in your init scripts is not available on FAT — instead keep the FAT boot partition strictly read-only in production and update it only through your OTA mechanism.

Performance And Security Considerations

F2FS’s log-structured design trades some upfront capacity for endurance and write throughput — segments awaiting garbage collection temporarily hold both live and stale data, so free space can look tighter than on ext4 for the same partition size. On the security side, neither F2FS nor FAT provide native permission enforcement equivalent to a full Unix filesystem when the vfat driver is used, since FAT has no concept of Unix uid/gid/mode — never store credential files or private keys on a FAT-mounted partition.

Summary And Key Takeaways

• F2FS is a log-structured filesystem purpose-built for managed flash (eMMC/SD), reducing write amplification through append-only segment writes and background garbage collection.
• FAT16/FAT32 remain necessary for boot partitions and universal removable-media interchange, handled by the msdos and vfat drivers.
• The in-kernel exFAT driver (since kernel 5.4) removes the old need for a FUSE-based exFAT implementation.
• Pick F2FS for your device’s own writable storage, and FAT/exFAT only where interoperability with the outside world is the actual requirement.

Conclusion

Every filesystem in this free embedded Linux course exists to solve one specific mismatch between how applications want to write data and how the underlying flash actually behaves. F2FS closes that gap for managed flash by writing the way SSD and eMMC controllers prefer to be written to, while FAT and exFAT solve a completely different problem: making sure your device’s removable media can be read by literally anything else in the world. Knowing when to reach for each one is what separates a storage strategy that merely boots from one that survives years of field deployment.

FAQ