What You Will Learn

• Why managed flash (eMMC, SD, USB storage) behaves differently from raw NAND/NOR flash from a filesystem’s point of view
• Which filesystem properties matter most for flash-backed storage, and why journaling matters
• How the Flashbench utility infers page size and erase block size purely by timing reads
• How to run Flashbench on a real device, read its output, and turn the numbers into a filesystem plan
• Common mistakes engineers make when picking a filesystem for flash-backed embedded boards

Prerequisites

• Basic familiarity with Linux block devices (/dev/mmcblkN, /dev/sdX)
• Comfort running commands as root on a development board or single-board computer
• A rough idea of what NAND flash pages and erase blocks are (covered earlier in this chapter)

Managed Flash Is Not Raw Flash

Earlier in this course we spent time on raw NAND: MTD devices, UBI, and UBIFS, where the kernel driver talks directly to flash cells and has to handle bad blocks, wear leveling, and out-of-band metadata itself. Managed flash devices — eMMC, SD cards, most USB flash drives, and NVMe-based flash — hide all of that behind an on-package controller. From Linux’s perspective, a managed flash device just looks like an ordinary block device with sectors, no different from a spinning hard disk.

That abstraction is convenient, but it is also a little misleading. Underneath the controller there is still NAND flash with large erase blocks, a limited number of program/erase cycles, and the possibility of losing power mid-write. The controller does its best to smooth over those realities with wear leveling and a flash translation layer (FTL), but the filesystem sitting on top still has choices that make a real difference to lifespan and reliability.

What To Look For In A Flash-Friendly Filesystem

When picking a filesystem for a managed flash device, two properties matter more than any others:

• Write reduction — fewer bytes written to the device means fewer erase cycles consumed by the controller’s wear leveling, extending the device’s usable life.
• Fast, safe recovery after an unclean shutdown — embedded products get their power pulled constantly (battery dies, someone trips over a cable), so the filesystem needs to come back up quickly and without corruption. This is almost always provided by a journal.

The Problem: Manufacturers Rarely Publish Geometry

To tune a filesystem well — aligning partitions, choosing block sizes, deciding how aggressively to batch writes — it helps enormously to know the underlying page size and erase block size of the flash. Unfortunately, most eMMC and SD card vendors treat this as an internal implementation detail and simply don’t publish it. This is where Flashbench comes in: instead of asking the manufacturer, we measure the chip’s behavior directly.

How Flashbench Works

Flashbench’s trick is elegantly simple. It reads a small block of data (say 1 KiB) from positions just before and just after a series of power-of-two aligned offsets, and times how long each read takes. When a read crosses a page boundary or an erase block boundary, the flash controller often has to do extra internal work, and that shows up as a measurable jump in latency. By repeating this at every power-of-two boundary from very large down to very small, Flashbench builds a latency profile that reveals where those boundaries actually sit.

Installing And Running Flashbench

Flashbench is a small standalone C program with no kernel dependency — it just issues reads through the normal block device interface, so it works on any Linux system with access to the raw device node.

$ git clone https://github.com/bradfa/flashbench.git
$ cd flashbench
$ make
$ sudo ./flashbench -a /dev/mmcblk1 --blocksize=1024

Here is an original example run against a 32 GB eMMC module on a Rockchip-based carrier board (numbers will differ on your hardware — that’s the whole point of running the tool yourself):

$ sudo ./flashbench -a /dev/mmcblk1 --blocksize=1024
align 1073741824 pre 6.10ms on 6.30ms post 5.95ms diff 210µs
align 536870912  pre 5.80ms on 6.05ms post 5.70ms diff 190µs
align 268435456  pre 5.40ms on 5.60ms post 5.30ms diff 175µs
align 134217728  pre 5.10ms on 5.35ms post 4.95ms diff 260µs
align 67108864   pre 4.80ms on 5.00ms post 4.55ms diff 300µs
align 33554432   pre 4.50ms on 4.70ms post 4.20ms diff 380µs
align 16777216   pre 4.20ms on 4.35ms post 3.95ms diff 290µs
align 8388608    pre 3.90ms on 4.05ms post 3.60ms diff 310µs
align 4194304    pre 3.60ms on 3.75ms post 3.30ms diff 340µs
align 2097152    pre 3.30ms on 3.45ms post 3.05ms diff 400µs
align 1048576    pre 3.00ms on 3.15ms post 2.70ms diff 350µs
align 524288     pre 2.70ms on 2.85ms post 2.45ms diff 620µs
align 262144     pre 2.45ms on 2.55ms post 2.30ms diff 210µs
align 131072     pre 2.30ms on 2.40ms post 2.15ms diff 190µs
align 65536      pre 2.15ms on 2.25ms post 2.05ms diff 175µs
align 32768      pre 2.05ms on 2.15ms post 1.95ms diff 160µs
align 16384      pre 1.95ms on 2.05ms post 1.85ms diff 150µs
align 8192       pre 1.90ms on 1.98ms post 1.82ms diff 140µs
align 4096       pre 1.85ms on 1.92ms post 1.60ms diff 480µs
align 2048       pre 1.80ms on 1.82ms post 1.79ms diff 12ns

Reading from the bottom of this table upward: the difference jumps sharply at the 4 KiB boundary (480µs versus the noise-level differences at smaller sizes), which is the strongest signal for the page size. Moving further up, there is another clear step at 524288 bytes (512 KiB), which is the most likely erase block size for this module. Everything between those two points is comparatively flat, meaning nothing structurally interesting happens at those boundaries.

Turning Flashbench Numbers Into A Filesystem Plan

Once you know the page size and erase block size, you can make informed decisions:

• Align partitions to the erase block boundary using parted or sfdisk, so filesystem writes don’t straddle two erase blocks unnecessarily.
• Set the filesystem block size to a multiple of the page size where the filesystem supports it.
• Feed the erase block size into any wear-leveling-aware tooling (log-structured filesystems like F2FS accept segment size hints).

# Align a partition to a 512 KiB erase block boundary (1024 sectors of 512 bytes)
$ sudo parted /dev/mmcblk1 -- mkpart primary ext4 1024s 100%

Common Mistakes And Troubleshooting

• Running Flashbench on a mounted, actively-used device. Background I/O from the OS will pollute your timing measurements. Unmount the partition or test on an otherwise idle device.
• Trusting a single run. Flashbench results can be noisy on virtualized or USB-bridged storage; run it two or three times and look for a consistent pattern before trusting a boundary.
• Assuming SD cards and eMMC modules share geometry. Even two eMMC parts from different vendors can have different page/erase block sizes — always measure the specific part on your BOM.
• Ignoring discard/TRIM support when picking a filesystem — we cover this in detail in the next lesson.

Best Practices

• Run Flashbench once per new hardware revision, not once per project — a BOM change to a different eMMC vendor can silently change the geometry.
• Prefer a journaling filesystem (ext4 or F2FS) for the root filesystem on any product that isn’t guaranteed a clean shutdown path.
• Document the measured erase block size in your board support package so future engineers don’t have to re-derive it.

Performance Considerations

Partition and filesystem-block alignment to the measured erase block size mostly pays off on write-heavy workloads — logging, databases, or frequent configuration writes. For mostly-read-only root filesystems, the practical difference is small, but it costs nothing to align correctly from the start.

Summary / Key Takeaways

• Managed flash (eMMC, SD, USB) hides raw NAND behind a controller, but the underlying geometry still matters for filesystem tuning.
• Journaling filesystems like ext4 and F2FS give fast, safe recovery after unclean shutdowns — essential for embedded products.
• Flashbench measures read-timing jumps at power-of-two boundaries to infer page size and erase block size when the vendor won’t publish them.
• Use the measured geometry to align partitions and choose filesystem parameters, and re-measure whenever the eMMC vendor changes.

Conclusion

Choosing a filesystem for managed flash is less about picking a trendy option and more about matching two properties — write reduction and journaled crash recovery — to your product’s power-loss profile. Flashbench closes the information gap that vendors leave open, turning a guess into a measurement. In the next lesson we’ll build on this by looking at Linux’s discard/TRIM support, which lets the filesystem tell the flash controller which sectors are truly free.

FAQ