The Flash File System

Home / The Flash File System

The Flash File System

December 9, 2015 | Article | No Comments

You might have ever heard of Journaling Flash File System (JFFS) and Yet Another Flash File System (YAFF), both are file system that underlying flash device. These file system mostly used in embedded employing flash memory technology. Flash file system considers the special abilities, performance, and restrictions of flash memory device.

This article will discuss about Flash File System, the technology behind, and implementation.

Flash Memory Technology

There are several different technology for Flash Memory categories. But, all the technologies are non-volatile memory, which the content can persist after the power source is removed. It’s like magnetic-based storage system such as Hard Disk, but using flash memory instead.

Two of the most common type of flash memory are: NOR and NAND. NOR-based flash is the older technology. It supports high read performance at the expense of smaller capacities. NAND flash offers higher capacity with faster write and erase performance. NAND also requires a much more complicated input/output (I/O) interface.

Flash parts are commonly divided into partitions, which allows multiple operations to occur simultaneously (erasing one partition while reading from another). Partitions are further divided into blocks which might be 64KB or 128KB in size. Firmware that uses the partitions can further apply technique segmenting to the blocks.

Flash devices exhibit a common constraint that requires device management when compared to other storage devices such as RAM disks. The only Write operation permitted on a flash memory device is to change a bit from a one to a zero. If the reverse operation is needed, then the block must be erased (to reset all bits to the one state). This means that other valid data within the block must be moved for it to persist. NOR flash memory can typically be programmed a byte at a time, whereas NAND flash memory must be programmed in multi-byte bursts (typically, 512 bytes).

The process of erasing a block differs between the two memory types. Each requires a special Erase operation that covers an entire block of the flash memory. NOR technology requires a precursor step to clear all values to zero before the Erase operation can begin. An Erase is a special operation with the flash device and can be time-consuming. Erasing is an electrical operation that drains the electrons from each cell in an entire block.

NOR flash devices typically require seconds for the Erase operation, whereas a NAND device can erase in milliseconds. A key characteristic of flash devices is the number of Erase operations that can be performed. In a NOR device, each block in the flash memory can be erased up to 100,000 times. NAND flash memories can be erased up to one million times.

The Challenges

In addition to and as a result of the constraints explained in previous section, managing flash devices has several challenges. Three most important are: garbage collection, managing bad blocks, and wear leveling.

Garbage Collection

The process of reclaiming invalid blocks. The invalid blocks are block which contain some amount of invalid data. Reclamation involves moving the valid data to a new block, and then erasing invalid block to make it available. This process is commonly done in the background or as needed, if the file system is low on available space.

Managing Bad Blocks

Over time, flash devices can develop bad blocks through use and can even ship from the manufacturer with blocks that are bad and cannot be used. The bad blocks may occur from a failed flash operation (such as an Erase) or an invalid Write operation (discovered through an invalid Error Correction Code, or ECC).

After bad blocks have been identified, they are marked within the flash itself in a bad block table. How this is done is device-dependent but can be implemented with a separate set of reserved blocks managed separately from normal data blocks. The process of handling bad blocks—whether they ship with the device or appear over time—is called bad block management. In some cases, this functionality is implemented in hardware by an internal microcontroller and is therefore transparent to the upper-level file system.

Wear Leveling

Like any device, you cannot use flash memory forever. Flash memory has finite limit of Erase cycles on each blocks before the block becomes bad. To maximize the life of the flash, wear-leveling algorithms are provided. Wear leveling comes in two varieties: dynamic wear leveling and static wear leveling.

Dynamic wear leveling addresses the problem of a limited number of Erase cycles for a given block. Rather than randomly using blocks as they are available, dynamic wear-leveling algorithms attempt to evenly distribute the use of blocks so that each gets uniform use.

Static wear-leveling algorithms address an even more interesting problem. In addition to a maximum number of Erase cycles, certain flash devices suffer from a maximum number of Read cycles between Erase cycles. This means that if data sits for too long in a block and is read too many times, the data can dissipate and result in data loss. Static wear-leveling algorithms address this by periodically moving stale data to new blocks.

System Architecture

For Operating System perspective (in our example, Linux) the filesystem based on flash memory technology has similar abstraction as other file system. The difference might exists in lower level, where the hardware addressing the storage system.

As seen on figure below, at the top is the virtual filesystem (VFS), which presents a common interface to higher-level applications. As controlled by same abstraction, user-space application can address flash memory like any other storage.

figure1

The VFS is then followed by the flash file system, which will be covered in the next section. Next is the Flash Translation Layer (FTL), which provides for overall management of the flash device including allocation of blocks from the underlying flash device as well as address translation, dynamic wear leveling, and garbage collection. In some flash device, a portion of the FTL can be implemented in hardware.

The Linux kernel uses the Memory Technolody Device (MTD) interface, which is a generic interface for flash device.

Flash File System

Journaling Flash File System (JFFS)

One of the earliest flash file system. It is a log-structured file system that was designed for NOR flash devices. It was unique and addressed a variety of problems with flash devices, but it created another.

figure2

JFFS viewed the flash device as a circular log of blocks. Data written to the flash is written to the tail, and blocks at the head are reclaimed. The space between the tail and head is free space; when this space becomes low, the garbage collector is executed. The garbage collector moves valid blocks to the tail of the log, skips invalid or obsolete blocks, and erases them (see Figure 2). The result is a file system that is automatically wear leveled both statically and dynamically. The fundamental problem with this architecture is that the flash device is erased too often (instead of an optimal erase strategy), which wears the device out too quickly.

When a JFFS is mounter, the structural details are read into memory. This can be slow at mount-time and consume more memory than desired.

Journaling Flash File System 2 (JFFS2)

The successor of JFSS to address JFSS limitation. The wear-leveling algorithm of JFSS tends to shorten the life of NOR flash device. The first JFFS2 was designed for NAND flash devices and also includes improved performance with compression.

In JFFS2, each block in the flash is treated independently. JFFS2 maintains block lists to sufficiently wear-level the device. The clean list represents blocks on the device that are full of valid nodes. The dirty list contains blocks with at least one obsoleted node. Finally, the free list represents the blocks that have been erased and are available for use.

figure3

The garbage collection algorithm can then intelligently decide what to reclaim in a reasonable way. Currently, the algorithm probabilistically selects from the clean or dirty list. The dirty list is selected 99 percent of the time to reclaim blocks (moving the valid contents to another block), and the clean list is selected 1 percent of the time (simply moving the contents to a new block). In both cases, the selected block is erased and placed on the free list (see Figure 3). This allows the garbage collector to re-use blocks that are obsoleted (or partially so) but still move data around the flash to support static wear leveling.

Yet Another Flash File System (YAFFS)

Another flash file system for NAND flash. The initial version of YAFFS support flash device with 512 byte pages. The newer version has support newer devices with larger page sizes and greater write constraints.

figure4

In most flash file systems, obsolete blocks are marked as such, but YAFFS2 additionally marks blocks with monotonically increasing sequence numbers. When the file system is scanned at mount time, the valid inodes can be quickly identified. YAFFS also maintains trees in RAM to represent the block structure of the flash device, including fast mounting through checkpointing —the process of saving the RAM tree structure to the flash device on a normal unmount so that it can be quickly read and restored to RAM at mount time (see Figure 4). Mount-time performance is a great advantage of YAFFS2 over other flash file systems.

About Author

about author

xathrya

A man who is obsessed to low level technology.

Leave a Reply

Your email address will not be published. Required fields are marked *

Social media & sharing icons powered by UltimatelySocial