Understanding the Flash‑Friendly File System (F2FS): Design, Implementation, and Future Directions

F2FS (Flash Friendly File System) is a file system specifically designed for flash‑based storage such as SSD, eMMC and UFS. It was announced by Samsung engineer Jaegeuk Kim in October 2012 and merged into the mainline Linux kernel in version 3.8. Although it operates on the generic block‑device interface like UBIFS or JFFS2, it remains “flash‑aware” because it exploits the weaknesses of the Flash Translation Layer (FTL) – namely the lack of hot/cold data awareness, inefficient garbage collection and write amplification.

F2FS inherits the principles of log‑structured file systems, using out‑of‑place writes to turn random writes into sequential ones and to mitigate the classic “snowball effect” and cleaning overhead of earlier log‑structured designs. Interestingly, the FTL itself also employs a log‑structured write strategy, making F2FS a complementary software layer that targets the soft spots of the FTL.

The file system is flash‑aware in its layout and allocation policies. It can be tuned via several parameters to match different flash implementations. The article first introduces the address‑mapping schemes used by FTL – block‑level mapping, page‑level mapping, and hybrid (mixed) mapping such as SAST, which combines data blocks and log blocks to balance update frequency and space efficiency.

A brief history of log‑structured file systems is provided, citing the seminal LFS paper by John Ousterhout and Mendel Rosenblum (1992). While LFS offers high write throughput and fast crash recovery, it also introduces challenges in garbage collection that F2FS must address.

F2FS’s on‑disk layout is organized into fixed‑size segments, which are grouped into sections and zones. Key metadata structures include the Superblock (SB), Checkpoint (CP), Segment Information Table (SIT), Node Address Table (NAT), Segment Summary Area (SSA), and the Main Area where actual data and inodes reside. Each structure’s purpose – from storing partition parameters to tracking valid blocks – is described.

The NAT breaks the “snowball effect” by allowing independent updates of data blocks and their index nodes. A file lookup example demonstrates the steps: retrieve the root inode via NAT, locate the directory entry, fetch the target inode, and finally access the file’s data blocks. F2FS uses a three‑level inode index (similar to EXT3), supporting files up to ~3.94 TB and partitions up to 16 TB. Inline data storage further optimizes small‑file handling on Android devices.

To reduce garbage‑collection overhead, F2FS separates hot, warm and cold data using multiple log heads and zones. A table in the original article classifies node and data types (e.g., directory inodes as hot, indirect index blocks as cold) and shows how this segregation leads to a more balanced distribution of valid blocks across zones.

Garbage collection (GC) in F2FS operates in foreground and background modes. Selection algorithms include a greedy approach (fewest valid blocks) for foreground GC and a cost‑benefit method (considering block age) for background GC. The GC process consists of target selection, valid‑block identification via SIT and SSA, and post‑move handling after checkpoint completion. When free space is scarce, F2FS can employ Slack‑Space Recycling (SSR), a “threaded logging” technique that writes into fragmented segments to avoid foreground GC stalls.

The article concludes with an outlook: Google adopted F2FS on Pixel 3 (2018), Samsung began using it on flagship devices in 2019, and many other manufacturers have followed. Ongoing community work adds features such as online resize, cold‑data compression, and potential support for Shingled Magnetic Recording (SMR) disks, extending F2FS beyond Android.

References: Lee et al., “F2FS: A New File System for Flash Storage” (FAST ’15); Rosenblum et al., “The Design and Implementation of a Log‑Structured File System” (SOSP ’92); Jaegeuk Kim, “Flash‑Friendly File System (F2FS)” (KLF 2012); SMR introduction (zonedstorage.io).