Simplifying and Accelerating NOR Flash I/O Stack for RAM-Restricted Microcontrollers

Tiny microcontrollers with almost no RAM store their data on NOR flash, so their file systems push all the bookkeeping — block-level data organization and wear leveling — onto the flash itself, but managing storage in fine blocks means constant on-flash index updates and full-chip scanning, which multiplies every read and write into many flash operations and wears the chip out fast, made worse because the two jobs are handled separately; this paper (Harbin Institute of Technology and East China Normal University — Hao Huang, Yanqi Pan, Wen Xia, Xiangyu Zou, Darong Yang, Liang Shi, Hongwei Du) presents NF2FS, which notices that embedded files are small and their access patterns predictable, so it drops the block machinery for a flat file layout and does wear leveling by swapping whole files, cooperating the two at a coarse file granularity to cut I/O amplification and keep the flash from wearing out.

The argument in one glance

Problem

A file system for tiny devices must live on the flash, not in the scarce RAM

Many small embedded devices — sensors, wearables, controllers — use NOR flash for storage, because it comes in a small package and is highly reliable. But these microcontrollers have very little RAM, often just kilobytes, so a file system for them cannot keep its bookkeeping in memory the way a normal file system does. It has to store its data organization and its wear-leveling state on the NOR flash itself. NOR flash also has the usual flash constraints: you can only erase in large units, each cell wears out after a limited number of erases, and reads and writes have real cost. So the file system has to manage where data lives and spread wear evenly across the chip, all while barely using RAM. How it does that bookkeeping determines both how fast the device is and how long the flash lasts.
What people did

Push block-level organization and wear leveling onto the flash

Existing NOR flash file systems satisfy the RAM restriction by migrating their functions from RAM to flash: they organize data at a fine block granularity, keeping the indexes that map and track those blocks on the NOR flash, and they perform wear leveling at that same block level, again with the necessary state stored on flash. This keeps the RAM footprint tiny, which is the hard constraint, and is the standard way these file systems cope.
Why it fell short

Fine block management on flash causes severe, compounding I/O amplification

Managing storage in fine blocks with the state on flash is expensive in exactly the way flash punishes. Because the indexes live on flash, every change means frequent on-flash index updates, and because RAM cannot cache the layout, the file system must scan the NOR flash to find or rebuild information. Both turn a single logical read or write into many flash operations — severe I/O amplification — which is slow and, worse, wears the flash out quickly since each extra write consumes erase-cycle life. The problem compounds because data organization and wear leveling are handled as separate, decoupled subsystems, so they each do their own indexing and scanning, duplicating the very work that is causing the amplification. Fine granularity plus decoupling plus on-flash state is a combination that makes the bookkeeping cost dominate.
This paper's idea

Manage whole files, not blocks, and cooperate organization with wear leveling

NF2FS is a NOR flash-friendly file system built on two observations about the applications these devices run. First, their files are usually small, so the block-based data organization can be replaced with a flat file layout, which makes scanning files and directories fast without block-level indexes. Second, their I/O patterns are deterministic, so wear leveling does not need fine block-level machinery — it can be achieved by coarse file swapping, moving whole files to balance wear. NF2FS therefore relaxes both data organization and wear leveling to a coarse, file-level granularity, and, crucially, has them cooperate within the file system rather than run as decoupled subsystems, eliminating the duplicated indexing and scanning. It is implemented in FreeRTOS with a set of supporting techniques: an all-logging layout that suits flash's write-then-erase nature, a dual bitmap space allocator for efficient allocation, and a soft-update-like crash-consistency scheme that keeps the file system consistent across power loss without heavy journaling. Experiments show NF2FS significantly outperforms existing file systems and prevents quick NOR flash wear-out.

Why this problem is worth solving

The file system is a quiet but decisive factor in whether a tiny device is fast and long-lived.

NOR flash is a kind of flash memory prized in embedded systems for its small physical package, high reliability, and the ability to read data in place, which is why it is increasingly the storage of choice for microcontroller-based devices. But it inherits flash’s awkward physics: it is written in pages but can only be erased in larger blocks, each cell tolerates only a limited number of erase cycles before it wears out, and to reuse space you must erase it first. On top of the flash physics sits the microcontroller’s defining constraint — extremely little RAM, often only kilobytes. A conventional file system leans heavily on RAM to cache its indexes and metadata, so lookups and updates are fast and the storage device is touched sparingly; a microcontroller file system cannot afford that, so it must keep its bookkeeping on the flash and touch the flash to do almost anything. That collision — flash that is costly to write and wears out, and RAM too small to buffer the metadata that would spare the flash — is what makes storage on these devices genuinely hard. And it matters practically: embedded devices are deployed in huge numbers, often for years on a battery, so a file system that hammers the flash makes the device slower and shortens its life, while one that touches the flash sparingly does the opposite. Getting this right is why the file system design is worth revisiting for this setting.

The reason the standard approach backfires is that it fights the flash on every operation.

To meet the RAM limit, existing NOR flash file systems move their machinery onto the flash: they track data in fine blocks and keep the mapping indexes for those blocks on the flash, and they spread wear at that same fine granularity. This satisfies the RAM constraint, but it creates a treadmill. Every time data changes, the on-flash index that describes it must be updated, and since flash cannot be overwritten in place, an update means writing new data and eventually erasing old — so a small logical change becomes several physical writes. And because there is no RAM to hold the layout, the file system frequently has to scan the flash to locate data or rebuild its picture of what is where, turning reads into sweeps. This is I/O amplification: one logical operation costing many flash operations. It is doubly harmful, because it is slow and because each extra write eats into the finite erase-cycle budget, so the device wears out faster. The situation is made worse by keeping data organization and wear leveling as two separate subsystems: each maintains its own on-flash structures and does its own scanning, so the amplification is paid twice over for overlapping work. The root problem is a mismatch — fine-grained, decoupled, on-flash bookkeeping applied to a medium and a RAM budget that punish exactly that pattern — which is what a redesign around the real workload can fix.

What people did before, and where it broke

Migrate block-level organization from RAM to flash. Keep the block indexes on the NOR flash to satisfy the tiny RAM budget. Where it broke. Every data change updates on-flash indexes, and with no RAM cache the file system must scan the flash, so a single operation becomes many flash operations.
Block-level wear leveling with on-flash state. Spread wear at fine block granularity, storing the wear state on flash. Where it broke. Fine-grained wear tracking adds its own frequent on-flash updates and scanning, compounding the amplification rather than relieving it.
Treat data organization and wear leveling separately. Build each as its own subsystem with its own structures. Where it broke. The two decoupled subsystems duplicate indexing and scanning, so the expensive bookkeeping is paid twice for overlapping work.
Generic or block-device file systems on flash. Reuse designs built for block devices with RAM to spare. Where it broke. They assume the RAM to cache metadata and the ability to overwrite in place, neither of which holds on a RAM-restricted microcontroller with NOR flash, so they amplify I/O and wear.
The gap. No file system exploited the fact that embedded NOR-flash workloads have small files and deterministic access to relax both data organization and wear leveling to a coarse file level and cooperate them, cutting the on-flash bookkeeping that drives I/O amplification and wear-out.

How NF2FS works

Relaxing organization and wear leveling to the file level on NOR flash

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Match the granularity of management to the actual workload. The organizing insight of NF2FS is that the fine-grained, general-purpose block machinery existing file systems carry is mismatched to what embedded NOR-flash devices actually do. Their files are small and their access is deterministic, so managing storage in fine blocks buys precision the workload never uses while paying its full cost in on-flash indexing and scanning. NF2FS relaxes both data organization and wear leveling up to the coarse file level, where a flat layout suffices and whole-file swapping levels wear, so the bookkeeping shrinks to fit the need. Coping with a resource-constrained embedded storage medium by tailoring the software to the device’s real usage rather than importing a heavyweight general design is the same instinct the work on a software caching runtime for embedded non-volatile memory covered elsewhere on this site is built on, shaping the storage software to the constraints of tiny systems. NF2FS applies that instinct to the file system’s granularity, which is where the cost was hiding.

Cut the amplification by not repeating the work. The direct payoff of coarsening the granularity is fewer flash operations per logical operation. A flat file layout removes the block indexes whose updates and scans amplified every access, and file-level wear leveling removes the fine wear-tracking that added its own. On top of that, NF2FS refuses the decoupling that made prior systems pay for overlapping indexing twice, cooperating organization and wear leveling in one file system. Reducing the wasted multiplication of I/O by aligning how data is laid out and accessed with how the storage device actually behaves is the same goal the work on maximizing SSD bandwidth by curbing read amplification covered elsewhere on this site pursues, driving down the gap between logical requests and physical operations. NF2FS pursues it on NOR flash, where each avoided write is also erase-cycle life saved.

Spend the flash sparingly so the device lasts. Because I/O amplification on flash is not just slow but life-shortening — every extra write consumes a limited erase cycle — cutting it directly extends how long the device works. NF2FS’s coarse wear leveling by file swapping still balances erasure across the chip so no region wears out first, but it does so without the constant fine-grained updates that themselves caused wear. Managing a storage medium so that its finite endurance is respected and its usable lifetime stretched is the same lifetime-aware concern the work on lifetime-aware design for intelligence at the extreme edge covered elsewhere on this site is built on, treating device longevity as a first-class design goal for tiny deployed systems. NF2FS treats it that way for NOR-flash microcontrollers, which are often deployed in the field for years and cannot easily be replaced.

Following a write through NF2FS

Saving a small file on a RAM-restricted NOR-flash device

An illustrative trace, based on the paper's abstract, of how NF2FS handles a write. Internal details beyond the abstract were not available for this draft.

Step 1 of 5

An application writes a small file

A microcontroller application saves a small file, as its workload typically does. A block-based file system would fragment this into blocks and update on-flash block indexes; NF2FS instead treats the file as a unit under its flat layout.

Small files are exactly the case the flat layout is designed for.

Why it works

A flat file layout removes the block indexes that amplified access. Block-based organization keeps on-flash indexes that must be updated and scanned constantly → but small files can be managed whole with a flat layout → so those index updates and scans, a main source of amplification, disappear.
Deterministic access lets wear leveling be coarse. Fine block-level wear leveling adds its own frequent on-flash updates → but predictable I/O means whole-file swapping suffices to balance wear → so wear is leveled without the fine-grained bookkeeping.
Cooperating the two subsystems stops paying twice. Decoupled organization and wear leveling each index and scan the flash for overlapping work → but cooperating them at the file level shares that work → so the duplicated amplification is eliminated.
An all-logging layout fits how flash actually writes. Flash cannot cheaply overwrite in place, so in-place updates trigger read-modify-erase-write → but appending in a log matches write-then-erase → so writes stay cheap and flash-friendly.
Cutting amplification also saves the flash’s life. Every extra write on flash consumes a finite erase cycle → but reducing the flash operations per logical operation reduces erases → so the device is both faster and much slower to wear out.

What it costs (trade-offs and scope)

This is a draft built from the paper’s abstract. The full paper was behind a publisher access wall for this draft (no arXiv version, no open-access or author copy located, and the ACM Digital Library returned a bot-verification challenge), so this account is assembled from the paper’s complete abstract plus standard background on NOR flash and embedded file systems. The exact flat-layout design, the dual bitmap allocator, the soft-update-like consistency scheme, the file-swapping wear-leveling algorithm, and the evaluation setup are not reproduced here and should be read from the paper.
The gains rest on the two workload assumptions. NF2FS relies on files being small (so a flat layout works) and access patterns being deterministic (so coarse wear leveling suffices). Workloads with large files or irregular, unpredictable access would fit the design less well, and how far it degrades outside these assumptions is not detailed in this draft.
Coarse wear leveling could be less precise. Leveling wear by swapping whole files is cheaper than block-level tracking, but coarser granularity can in principle balance wear less finely; the abstract states NF2FS prevents quick wear-out, but the precise wear behavior versus fine-grained schemes should be checked in the paper.
The results are qualitative in the abstract. The abstract reports that NF2FS significantly outperforms existing works and prevents quick wear-out, but it does not, in what is available here, give the specific speedups, wear reductions, workloads, hardware, or baselines behind those claims.
It targets RAM-restricted microcontrollers with NOR flash. NF2FS is designed for and implemented in FreeRTOS on this class of device; larger systems with ample RAM, other flash types, or different reliability requirements are outside its stated scope.

The evaluation

File systems for RAM-restricted NOR-flash microcontrollers

Property	Block-based NOR FS	Decoupled organization + WL	NF2FS
Management granularity
On-flash index updates and scanning
Wear leveling
I/O amplification
Reported outcome (per abstract)

A qualitative comparison based on the paper's abstract; the paper's main body, including the flat layout, allocator, consistency scheme, wear-leveling algorithm, and quantitative results, was not available for this draft. The 'significantly outperforms' and 'prevents quick wear-out' claims are the abstract's own.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This is an honest draft assembled from the paper’s complete abstract plus standard background on NOR flash, wear leveling, and embedded file systems; the full text was not accessible (no arXiv preprint, no open-access or author copy found, and the ACM Digital Library version returned a bot-verification challenge), so the internal design is not reproduced. What is solid and comes directly from the abstract: NOR flash is popular for RAM-restricted microcontrollers; existing NOR flash file systems migrate block-level data organization and wear leveling from RAM to flash, and this fine-grained block-level management introduces frequent index updates and NOR flash scanning, causing severe I/O amplification that worsens because the two are decoupled; NF2FS is a NOR flash-friendly file system built on the insights that applications have small file sizes (so block-based organization can become a flat file layout for fast file and directory scanning) and deterministic I/O patterns (so wear leveling can be achieved through coarse file swapping); NF2FS relaxes data organization and wear leveling to a coarse file level and cooperates them within the file system; it is implemented in FreeRTOS with an all-logging layout, a dual bitmap space allocator, and a soft-update-like crash-consistency scheme; and experiments show it significantly outperforms existing works and prevents quick NOR flash wear-out. The explanations of why fine-grained on-flash management amplifies I/O and wear are standard background and the natural reading of the abstract, not claims about NF2FS’s specific internals. Read the exact designs and the quantitative results in the paper itself; treat this page as a faithful account at the level of the abstract, not of the implementation.

Background

Why storage for tiny devices keeps needing its own designs

It helps to see NF2FS against a persistent truth of embedded computing: the storage designs that work for servers and phones rarely transfer down to the smallest devices, which live under constraints those larger systems never face. A microcontroller may have kilobytes of RAM, run for years on a coin cell, and store its data on flash whose cells wear out and which cannot be overwritten in place. General-purpose file systems assume abundant RAM to cache metadata, the freedom to rewrite data, and storage that does not degrade with use — assumptions that all fail here — so naively porting them produces exactly the I/O amplification and premature wear that shorten a device’s life. This has forced the embedded community to build storage software specifically for the tiny, the flash-based, and the long-lived, repeatedly rediscovering that the right move is to strip away generality and shape the design around the device’s real limits and the application’s real behavior. As embedded devices proliferate and take on more, from sensing to on-device intelligence, these constraints only get more pressing, and the lifetime of the storage becomes a design objective in its own right. That same imperative to design for the endurance and constraints of hardware at the extreme edge, where devices must last and cannot be casually replaced, is what the work on lifetime-aware design for item-level intelligence at the extreme edge covered elsewhere on this site pursues. NF2FS is a file-system-level instance of the same lesson, reshaping NOR flash management around what tiny devices actually need.

If you remember only three things

1. NOR flash is popular for RAM-restricted microcontrollers, but with only kilobytes of RAM the file system must keep its data organization and wear-leveling state on the flash itself. Existing systems do this at a fine block granularity, which causes frequent on-flash index updates and full-chip scanning — severe I/O amplification that is slow and wears the flash out fast, made worse because data organization and wear leveling are decoupled subsystems that duplicate the indexing and scanning.
2. NF2FS is a NOR flash-friendly file system built on two workload observations: embedded files are usually small (so block-based organization can become a flat file layout for fast file and directory scanning), and their I/O patterns are deterministic (so wear leveling can be done by coarse whole-file swapping). It relaxes both data organization and wear leveling to a coarse file level and, crucially, has them cooperate in one file system instead of running separately, eliminating the duplicated bookkeeping. It is implemented in FreeRTOS with an all-logging layout, a dual bitmap space allocator, and a soft-update-like crash-consistency scheme.
3. Experiments show NF2FS significantly outperforms existing NOR flash file systems and prevents quick wear-out. This explainer is a draft from the abstract, so the flat-layout design, the allocator, the consistency scheme, the wear-leveling algorithm, and the quantitative results should be confirmed against the paper. The gains rest on the small-file and deterministic-access assumptions, coarse wear leveling trades some precision for far less bookkeeping, and the design targets RAM-restricted microcontrollers with NOR flash specifically.

Check yourself

Check your understanding

1. Why do existing NOR flash file systems for microcontrollers suffer severe I/O amplification?
2. What are the two workload observations behind NF2FS?
3. How does NF2FS reduce the bookkeeping cost that plagued prior systems?
4. What should a reader keep in mind about this explainer, and what did the paper report?

Sources

The paper is “Simplifying and Accelerating NOR Flash I/O Stack for RAM-Restricted Microcontrollers” by Hao Huang, Yanqi Pan, Wen Xia, Xiangyu Zou, Darong Yang, Liang Shi, and Hongwei Du (Harbin Institute of Technology and East China Normal University), published at ASPLOS 2025, DOI 10.1145/3676641.3716272. The file system is named NF2FS.

This explainer is a draft. The paper’s main text was not accessible at the time of writing (there is no arXiv preprint, no open-access or author copy was located, and the ACM Digital Library PDF returned a bot-verification challenge), so it is written from the paper’s complete abstract together with standard background on NOR flash, wear leveling, I/O amplification, and embedded file systems. The abstract supplies the problem and approach: NOR flash is increasingly popular for RAM-restricted microcontrollers due to its small package and high reliability; to satisfy RAM restrictions, existing NOR flash file systems migrate their functionalities — block-level data organization and wear leveling — from RAM to NOR flash, but this fine-grained block-level management introduces frequent index updates and NOR flash scanning, leading to severe I/O amplification that further deteriorates because the two are decoupled; NF2FS is a NOR flash-friendly file system whose key insight is that applications running on NOR flash usually have small file sizes (so block-based data organization can be converted to a flat file layout for fast file and directory scanning) and deterministic I/O patterns (so wear leveling can be achieved through coarse file swapping); NF2FS thus relaxes data organization and wear leveling to a coarse file level and cooperates them within the file system; it is implemented in FreeRTOS using techniques including an all-logging layout, a dual bitmap space allocator, and a soft-update-like crash-consistency scheme; and experiments suggest NF2FS significantly outperforms existing works and can prevent quick NOR flash wear-out. The explanations of why fine-grained on-flash management amplifies I/O and wear are standard background and the natural reading of the abstract, not claims about NF2FS’s specific internal design. The paper’s exact designs, hardware, and quantitative results are not reproduced here and should be read from the paper. No numbers beyond the abstract’s have been introduced.