Electronics Guide

Flash Memory Fundamentals

Flash memory has become the dominant storage technology in embedded systems due to its solid-state reliability, low power consumption, and decreasing cost. However, flash memory presents unique characteristics that significantly impact file system design.

Erase-before-write requirement: Flash memory cannot overwrite existing data directly. Before writing new data to a location, the existing data must first be erased. This fundamental characteristic requires file systems to track which areas contain valid data and manage erasure operations carefully.

Block-based erasure: While flash memory can be read and written at relatively fine granularity (typically pages of 512 bytes to 4 KB), erasure operates on much larger blocks (typically 16 KB to 256 KB for NOR flash, or 128 KB to several megabytes for NAND flash). This asymmetry between write granularity and erase granularity creates the need for sophisticated management strategies.

Limited write endurance: Each flash memory cell can only endure a finite number of program-erase cycles before wearing out. Consumer-grade NAND flash typically supports 1,000 to 3,000 cycles, while high-endurance flash may support 100,000 cycles or more. File systems must distribute writes evenly across the device to maximize overall device lifetime.

Read disturb: Repeatedly reading from the same flash cells without intervening erasure can cause adjacent cells to lose their charge over time. File systems designed for flash may implement read disturb management to prevent data corruption from this phenomenon.

NOR versus NAND Flash

The two primary types of flash memory present different trade-offs for embedded applications:

NOR flash provides random access capability, allowing code to execute directly from the flash (execute-in-place or XIP). NOR flash offers faster read performance and higher reliability but comes at higher cost per bit and lower density. It is commonly used for storing boot code and firmware in embedded systems.

NAND flash provides higher density and lower cost per bit, making it suitable for mass storage applications. However, NAND flash requires data to be read in pages and may contain bad blocks that the file system must manage. NAND flash dominates in applications requiring significant storage capacity, such as data logging, multimedia storage, and removable media.

Managed Flash Devices

Many embedded systems use managed flash devices such as SD cards, eMMC (embedded MultiMediaCard), and USB flash drives. These devices include integrated controllers that handle wear leveling, bad block management, and error correction, presenting a block device interface similar to traditional hard drives.

While managed flash devices simplify file system selection by hiding flash-specific characteristics, they introduce their own considerations. The internal management algorithms may conflict with file system optimizations, and the quality of wear leveling varies significantly between manufacturers and price points. Critical applications may still benefit from file systems that minimize write amplification even when using managed flash.

FAT Architecture

FAT file systems organize storage into clusters, with a central file allocation table tracking the status and linkage of each cluster. The file allocation table serves as both a bitmap indicating free and used clusters and a linked list connecting the clusters belonging to each file.

The directory structure uses fixed-size entries containing file names, attributes, timestamps, starting cluster numbers, and file sizes. The original FAT specification limited file names to eight characters with a three-character extension (8.3 format), though later extensions support long file names while maintaining backward compatibility.

FAT Variants

FAT12 uses 12-bit cluster addresses, supporting volumes up to approximately 16 MB. While largely obsolete for primary storage, FAT12 may still be encountered on very small devices or legacy systems.

FAT16 uses 16-bit cluster addresses, supporting volumes up to 2 GB with reasonable efficiency. FAT16 remains common in smaller embedded applications where its simplicity and compatibility outweigh capacity limitations.

FAT32 uses 32-bit cluster addresses (though only 28 bits are actually used), supporting volumes up to 2 TB. FAT32 has become the standard for removable media and embedded storage in consumer devices due to its broad operating system support.

exFAT (Extended FAT) was designed specifically for flash memory, supporting files larger than 4 GB and volumes larger than 32 GB while maintaining simplicity. exFAT removes some FAT32 limitations but requires licensing for commercial use in some jurisdictions.

FAT Advantages and Limitations

FAT file systems offer several advantages for embedded applications:

Universal compatibility: Virtually every operating system can read and write FAT file systems, making FAT ideal for removable media and data interchange.

Simplicity: The FAT structure is straightforward to implement, with numerous open-source implementations available. Memory requirements are modest, with the file allocation table being the primary RAM consumer.

Deterministic performance: FAT operations are relatively predictable, though worst-case performance can be poor for fragmented files or nearly full volumes.

However, FAT has significant limitations:

No power-fail safety: FAT lacks journaling or other mechanisms to ensure file system consistency after unexpected power loss. Corrupted file allocation tables can render data inaccessible.

No wear leveling: FAT was designed for magnetic media and does not distribute writes to maximize flash lifetime. The file allocation table itself becomes a wear hotspot as it is updated with every file operation.

Limited metadata: FAT lacks support for access permissions, symbolic links, and other features expected in Unix-like environments.

ext2 File System

The second extended file system (ext2) was the standard Linux file system for many years before journaling file systems became prevalent. ext2 divides storage into block groups, each containing a superblock copy, block and inode bitmaps, an inode table, and data blocks.

ext2 supports Unix permissions, symbolic links, and file attributes that FAT lacks. For embedded systems where journaling overhead is undesirable and power-fail safety is managed through other means (such as read-only root file systems), ext2 provides a capable and efficient option.

The lack of journaling makes ext2 faster for write operations and reduces flash wear compared to journaling file systems. However, unexpected power loss can leave the file system in an inconsistent state requiring a full file system check during the next boot.

ext3 and ext4 File Systems

ext3 added journaling capability to ext2, recording pending changes to a journal before committing them to the file system proper. This journaling ensures that the file system can be quickly recovered to a consistent state after unexpected power loss, eliminating the need for lengthy file system checks.

ext3 offers three journaling modes: journal (safest but slowest, journaling both metadata and data), ordered (default, journaling metadata while ensuring data is written before metadata), and writeback (fastest but provides only metadata consistency guarantees).

ext4 extended ext3 with numerous improvements including extents for more efficient large file handling, delayed allocation for improved performance, and support for larger volumes and files. ext4 has become the default file system for most Linux distributions.

For embedded Linux systems with flash storage, ext4 with appropriate mount options can provide good performance. Disabling the journal (mounting as ext2) or using journaling modes appropriate for flash can reduce write amplification. However, ext3/ext4 were not designed specifically for flash memory and may not provide optimal wear distribution.

Considerations for Embedded Use

When using ext file systems on embedded flash storage, several considerations apply:

Mount options: Options like noatime (disabling access time updates), commit interval adjustments, and barrier settings can significantly impact write patterns and flash wear.

Journal placement: If using journaling, placing the journal on a more durable storage area or using external journaling can extend flash life.

Read-only root: Many embedded systems use a read-only root file system with a separate writable partition for variable data, eliminating wear concerns for the bulk of the file system.

JFFS2

The Journaling Flash File System 2 (JFFS2) is a log-structured file system designed specifically for raw flash memory in embedded Linux systems. JFFS2 writes data sequentially to flash, treating the entire flash device as a circular log.

Log-structured design: Rather than updating files in place, JFFS2 writes new data to the next available location and marks old data as obsolete. This approach eliminates the need to erase blocks before writing and naturally distributes writes across the flash device.

Garbage collection: As the flash fills with a mix of valid and obsolete data, JFFS2 performs garbage collection to reclaim space. The garbage collector selects blocks containing mostly obsolete data, copies any valid data to new locations, and erases the blocks for reuse.

Power-fail safety: The log-structured design provides inherent power-fail safety. Because new data is always written to new locations, a power failure never corrupts existing valid data. At mount time, JFFS2 scans the flash to reconstruct the file system state.

Compression: JFFS2 supports transparent data compression, which can significantly increase effective storage capacity for compressible data while reducing the amount of flash written.

JFFS2 limitations include relatively slow mount times (due to the requirement to scan the entire flash), high memory consumption for large file systems (the entire file system structure is kept in RAM), and suboptimal performance on large NAND flash devices.

YAFFS and YAFFS2

Yet Another Flash File System (YAFFS) was designed specifically for NAND flash memory. YAFFS2, the current version, improves on the original to support larger page sizes and newer NAND technologies.

NAND optimization: YAFFS2 is structured around NAND flash characteristics, with objects (files and directories) stored as collections of chunks that map efficiently to NAND pages. The design minimizes the number of page writes required for file system operations.

Checkpoint mechanism: Unlike JFFS2, YAFFS2 can save checkpoints of the file system state, dramatically reducing mount time for large file systems. The checkpoint captures the in-memory data structures, allowing rapid reconstruction without scanning all flash blocks.

Memory efficiency: YAFFS2 uses fixed-size data structures that scale linearly with the number of objects in the file system, providing more predictable memory consumption than JFFS2.

YAFFS2 is available under GPL licensing and has been widely used in embedded Linux and Android devices. Its NAND-specific optimizations make it particularly suitable for devices using raw NAND flash.

UBIFS

The Unsorted Block Images File System (UBIFS) works on top of UBI (Unsorted Block Images), a volume management layer for raw flash. This layered architecture separates wear leveling and bad block management (handled by UBI) from file system functionality (handled by UBIFS).

UBI layer: UBI presents logical erase blocks that hide the complexity of physical flash management. UBI handles wear leveling across the entire flash device, manages bad blocks, and provides atomic logical erase block updates. This abstraction allows UBIFS to focus on file system functionality.

Scalability: UBIFS was designed to scale well to large flash devices where JFFS2 performance degrades. Mount times remain fast regardless of flash size because UBIFS uses an on-flash index rather than scanning the entire device.

Write-back caching: UBIFS supports write-back caching for improved performance, with configurable synchronization policies to balance performance against power-fail safety.

Compression: Like JFFS2, UBIFS supports transparent compression with multiple algorithm options.

UBIFS has become the recommended file system for raw flash in modern embedded Linux systems, offering the best combination of performance, reliability, and scalability for large NAND flash devices.

F2FS

The Flash-Friendly File System (F2FS) was developed by Samsung for use with modern flash storage devices including SSDs, eMMC, and SD cards. Unlike JFFS2 and UBIFS which target raw flash, F2FS works with managed flash devices that present a block device interface.

Log-structured design: F2FS uses a log-structured approach optimized for flash, with modifications to address the performance issues of traditional log-structured file systems. The multi-head logging design maintains separate logs for different data types, improving garbage collection efficiency.

Flash awareness: F2FS aligns file system structures with flash erase block boundaries and optimizes write patterns to work harmoniously with flash translation layer algorithms in managed devices.

Performance features: F2FS includes numerous performance optimizations including adaptive logging, hot/cold data separation, and multi-stream support for devices that expose this capability.

F2FS is particularly well-suited for Android devices and embedded Linux systems using eMMC or high-quality SD cards where its flash-optimized design can significantly improve both performance and device longevity.

FTL Fundamentals

An FTL maps logical block addresses (as seen by the file system) to physical flash locations. When the file system writes to a logical block, the FTL writes the data to a new physical location and updates its mapping tables. This indirection allows the FTL to perform wear leveling and handle the erase-before-write requirement transparently.

Mapping granularity: FTLs may use page-level mapping (finest granularity, best performance, highest memory consumption), block-level mapping (coarsest granularity, lowest overhead, worst performance for small random writes), or hybrid approaches that balance these trade-offs.

Garbage collection: Like flash file systems, FTLs must reclaim space occupied by obsolete data. FTL garbage collection operates transparently to the file system but can cause significant performance variations, particularly when the device is nearly full.

Hardware FTL: Managed Flash Devices

SD cards, eMMC, USB flash drives, and SSDs all contain integrated controllers running FTL firmware. The quality and sophistication of these FTLs varies enormously:

Consumer-grade devices: Inexpensive SD cards and USB drives may use simple FTLs optimized for sequential write patterns typical of consumer applications. Performance can degrade dramatically under random write workloads common in embedded systems.

Industrial-grade devices: Industrial SD cards and eMMC modules typically include more sophisticated FTLs with better wear leveling, power-fail protection, and consistent performance characteristics. These devices cost more but provide reliability appropriate for embedded applications.

TRIM/Discard support: Modern managed flash devices may support TRIM (for SATA) or discard (for eMMC) commands that allow the file system to inform the FTL when blocks are no longer in use. This information helps the FTL optimize garbage collection and maintain performance.

Software FTL Solutions

For systems using raw flash where a block device interface is desired, software FTL solutions provide the translation layer:

mtdblock: The simplest Linux option, mtdblock provides a basic block device interface over MTD (Memory Technology Device) flash. However, mtdblock does not perform wear leveling and is not suitable for read-write file systems on flash.

UBI block: UBI can expose block devices on top of its wear-leveled logical erase blocks, providing a more suitable foundation for block-oriented file systems on raw flash.

Application-specific FTLs: Some applications implement custom FTL functionality tailored to their specific access patterns and reliability requirements.

Dynamic Wear Leveling

Dynamic wear leveling distributes writes among blocks that are currently available for writing. When a block is written, it is selected from a pool of free erased blocks based on their wear counts, preferring less-worn blocks.

Dynamic wear leveling is simple to implement and effective when all data is frequently updated. However, it cannot address wear imbalance caused by static data that is written once and never modified. Blocks containing static data never participate in the wear distribution.

Static Wear Leveling

Static wear leveling extends dynamic wear leveling by periodically relocating static data from less-worn blocks to more-worn blocks. This ensures that even blocks containing rarely-changed data participate in overall wear distribution.

Static wear leveling adds complexity and overhead, as it requires tracking wear counts for all blocks and periodically copying data that does not need to move for other reasons. The trade-off is improved wear distribution and longer device lifetime, particularly important for devices with mixed static and dynamic data.

File System Integration

Flash-native file systems like JFFS2, YAFFS2, and UBIFS integrate wear leveling directly into their operation. Their log-structured designs naturally distribute writes, and they explicitly track and optimize wear distribution.

When using block-oriented file systems on flash, wear leveling depends on the underlying FTL (either hardware in managed devices or software like UBI). The file system can help by avoiding unnecessary writes (using appropriate mount options) and providing discard hints when blocks become free.

Journaling

Journaling file systems record pending changes to a journal before committing them to the main file system structures. If power fails during an operation, the file system can replay or discard the journal entries to reach a consistent state.

Journaling adds write overhead and can accelerate flash wear, particularly for metadata-heavy workloads. The journal itself becomes a wear hotspot unless the file system or underlying layer provides wear leveling.

Log-Structured Approaches

Log-structured file systems like JFFS2 and F2FS provide inherent power-fail safety through their write-once, append-only structure. New data is always written to new locations, so power failure cannot corrupt existing valid data. Recovery involves identifying the most recent valid state, which can be determined by scanning for the latest complete writes.

Copy-on-Write

Copy-on-write file systems never overwrite existing data. Instead, modifications create new copies of affected blocks, with parent blocks updated to point to the new copies. This approach, used by file systems like Btrfs and ZFS, provides atomic updates and snapshot capabilities.

While copy-on-write provides excellent data safety, it can increase write amplification and may not be optimal for flash memory without careful tuning.

Application-Level Considerations

Even with power-safe file systems, applications must consider their own data consistency. Writing multiple related files or updating configuration atomically may require application-level techniques such as write-to-temporary-then-rename patterns or explicit synchronization points.

LittleFS

LittleFS is a small fail-safe file system designed for microcontrollers. Created by ARM, LittleFS provides wear leveling and power-fail safety in a package small enough for devices with limited RAM and flash.

Bounded RAM usage: LittleFS uses a fixed amount of RAM regardless of file system size, making it predictable for memory-constrained devices.

Power-fail resilience: The copy-on-write design ensures that the file system can always recover to a valid state after power loss.

Wear leveling: LittleFS includes dynamic wear leveling to extend flash lifetime.

LittleFS is widely used in IoT devices, wearables, and other microcontroller-based systems where traditional file systems would be too resource-intensive.

SPIFFS

The SPI Flash File System (SPIFFS) targets SPI NOR flash commonly used in microcontroller applications. SPIFFS provides wear leveling and operates efficiently on flash devices ranging from 128 KB to several megabytes.

SPIFFS uses a flat directory structure (no subdirectories) to minimize complexity and RAM usage. This limitation suits many embedded applications that require simple key-value or configuration storage rather than hierarchical file organization.

FatFs

FatFs is a popular FAT file system implementation for embedded systems, written in portable C with minimal dependencies. FatFs supports FAT12, FAT16, FAT32, and exFAT with configurable features that allow trading functionality for code size.

While FatFs does not provide wear leveling or power-fail safety, its small footprint and compatibility with removable media make it suitable for applications where these limitations are acceptable or addressed through other means.

Read-Only File Systems

For systems where file system contents do not change during operation, read-only file systems provide simplicity and reliability:

SquashFS: A compressed read-only file system widely used for embedded Linux root file systems. SquashFS provides high compression ratios, reducing storage requirements and improving read performance through reduced flash access.

CramFS: An older compressed read-only file system with lower memory requirements than SquashFS but also lower compression efficiency.

ROMFS: A simple read-only file system with minimal overhead, suitable for very small embedded systems.

Read-only file systems eliminate wear concerns for stored data and provide inherent protection against corruption. Many embedded systems use a read-only root file system combined with a small writable partition for configuration and runtime data.

Storage Media Type

Raw NAND flash: UBIFS (with UBI) provides the best combination of features for modern raw NAND devices. YAFFS2 remains a solid choice, particularly for smaller devices or when UBIFS overhead is a concern. JFFS2 may be appropriate for very small NOR or NAND devices.

Raw NOR flash: JFFS2 works well for NOR flash. For execute-in-place requirements, specialized solutions or careful JFFS2 configuration may be needed.

Managed flash (eMMC, SD): F2FS offers flash-optimized performance on quality managed devices. ext4 with appropriate mount options provides good compatibility and performance. FAT32 or exFAT may be necessary for removable media compatibility.

Reliability Requirements

Power-fail safety critical: UBIFS, JFFS2, YAFFS2, LittleFS, and F2FS all provide power-fail safety. For FAT or ext file systems, additional measures (battery backup, supercapacitor hold-up, graceful shutdown handling) may be required.

Data integrity critical: Consider file systems with checksumming (UBIFS, F2FS) or implement application-level verification.

Performance Requirements

Fast mount required: UBIFS and F2FS mount quickly regardless of size. YAFFS2 with checkpoints also mounts quickly. JFFS2 mount time increases with flash size.

Consistent latency required: Consider the garbage collection behavior of chosen file system. UBIFS and F2FS offer more predictable performance than JFFS2.

High throughput required: F2FS and ext4 generally offer better throughput than JFFS2 on managed flash. For raw flash, UBIFS provides good throughput with proper UBI configuration.

Resource Constraints

Limited RAM: LittleFS and SPIFFS are designed for memory-constrained microcontrollers. FatFs can operate with very small buffers. JFFS2 memory consumption scales with file system content and may be prohibitive for large devices with limited RAM.

Limited code space: LittleFS, SPIFFS, and FatFs have small code footprints. Full-featured file systems like UBIFS and F2FS require substantially more code space.

Mount Options and Configuration

Appropriate mount options significantly impact file system behavior:

Disable unnecessary updates: Options like noatime (Linux) disable access time updates that cause unnecessary writes.

Synchronization policy: Configure write-back behavior appropriate for your power-fail safety requirements. More aggressive write-back improves performance but increases data loss risk on power failure.

Compression: Enable compression where appropriate to reduce storage requirements and write volume, but consider CPU overhead.

Partition Layout

Thoughtful partition layout improves system reliability and maintainability:

Separate static and dynamic data: Place infrequently-changing data (firmware, application code) on separate partitions from frequently-written data (logs, configuration, user data). This separation simplifies updates and optimizes wear patterns.

Reserve space: Leave adequate free space for file system operation, particularly garbage collection. Running a flash file system near capacity severely degrades performance and may accelerate wear.

Redundancy for critical data: Consider storing critical configuration in multiple locations or maintaining previous versions for recovery.

Testing and Validation

File system testing for embedded systems should include:

Power-fail testing: Repeatedly interrupt power during file system operations to verify recovery behavior. Automated test rigs can perform thousands of power cycles with verification.

Endurance testing: Verify that wear leveling maintains acceptable wear distribution over expected device lifetime. Monitoring tools can track erase counts and predict remaining life.

Stress testing: Test performance and stability under adverse conditions including full file systems, fragmented files, and concurrent access.