F2FS: How It Conquers Billions of Android Devices
- 60% of MD5 Password Hashes Can Be Cracked in Under an Hour with a Single GPU
- Dirty Frag: Root Access on Every Major Linux Distribution — No Patch, No Warning
- Ubuntu 26.04 LTS (Resolute Raccoon): The Most Ambitious Ubuntu LTS in a Decade
- Proton Mail: Data Transferred to FBI Again!
- How Close Are Quantum Computers to Breaking RSA-2048?
- How to Prevent Ransomware Infection Risks?
- What is the best alternative to Microsoft Office?
Storage Systems · Deep Dive
F2FS: How It Conquers Billions of Android Devices
From Google Pixel to Samsung Galaxy, from Xiaomi to OPPO — a large proportion of flagship Android phones today use the same file system for their data partitions: F2FS, the Flash-Friendly File System. Born in Samsung’s labs in 2012, it now runs on billions of devices and has largely displaced the former incumbent, ext4, on high-end Android hardware. The reason lies in a design philosophy tailored to the physics of flash memory itself.
Origins: Samsung, 2012
Jaegeuk Kim, then a Samsung engineer, submitted the initial F2FS patch series to the Linux Kernel Mailing List on October 5, 2012. It was merged into the Linux mainline with kernel 3.8 on December 20, 2012. More than a decade later, the codebase has grown from a small experimental patch into a mature storage subsystem spanning tens of thousands of lines — encompassing compression, encryption, zoned block device support, and more. Kim has since moved through Huawei, Motorola, and Google, where he continues as the primary F2FS maintainer.
“F2FS is a new file system carefully designed for NAND flash memory-based storage devices. We chose a log-structured file system approach, but we tried to adapt it to the new form of storage.” — Jaegeuk Kim, Linux Kernel Mailing List, October 2012
Its rise was not driven by marketing. It happened because the dominant alternative, ext4, was designed for an entirely different era of storage hardware.
The Problem: ext4 Was Built for Spinning Disks
Ext4 was designed when mechanical hard drives ruled. On a spinning disk, the cost difference between random and sequential writes is primarily one of head positioning time — significant, but manageable. NAND flash memory operates under entirely different physical constraints that make the ext4 model deeply inefficient.
Flash memory cannot overwrite data in place. Before any block can be written, it must first be erased — and the erase unit (typically 256 KB to several megabytes, depending on the device) is far larger than the write unit (a page, typically 4–16 KB). Every time ext4 performs an in-place update of a few bytes, it forces the underlying Flash Translation Layer (FTL) to read the entire erase block, erase it, and rewrite it with the modification — a cycle called write amplification. Over time, this accelerates wear and degrades performance.
Additionally, each flash block can only be erased a finite number of times — typically thousands to tens of thousands of erase cycles — before it wears out. Every unnecessary erase shortens device lifespan.
F2FS’s Answer: Work With the Hardware, Not Against It
F2FS adopts a log-structured design: all writes are sequential appends to the end of an active log segment. Data never overwrites its previous location. Instead, it lands at a new address, and the old address is marked as stale, awaiting garbage collection. This single architectural decision eliminates in-place random writes at the source.
- File data has a fixed physical address
- Modifications directly overwrite the original block
- Metadata is written to the journal first, then committed
- Efficient on HDDs; expensive on flash due to erase-before-write
- File data has no fixed physical address
- Each write appends to a new location; old location becomes garbage
- No journal needed — old data is never overwritten mid-flight
- NAT (Node Address Table) indirection keeps address changes transparent
The NAT Layer: Making Address Instability Invisible
A natural question arises: if a file’s data keeps moving to new addresses, how does the file system track where anything is? Ext4 answers this with fixed address pointers in inodes via an extent tree — modifying data simply overwrites the same block, so the inode never needs updating. That model depends on stable addresses, which flash’s write patterns destroy.
F2FS introduces the Node Address Table (NAT), a persistent indirection layer that maps node IDs to their current physical addresses. When a file’s data moves to a new location after a write, only the NAT entry is updated. Upper layers — the VFS, applications — see stable inode numbers regardless of how often the physical address changes. This is the architectural core that makes log-structured writes transparent to the rest of the operating system.
Because old data is never overwritten mid-update, F2FS also eliminates the need for a journal. There is no “halfway through writing” intermediate state that could cause corruption after a crash. Consistency is maintained through a periodic checkpoint mechanism instead.
Features in the Modern Kernel
F2FS has grown well beyond its initial log-structured core. The version present in modern Linux kernels includes:
Compression support (LZ4 and zstd) arrived with Linux 5.6 and 5.7 respectively. Android uses F2FS compression aggressively to reduce storage footprint without a performance penalty — sequential reads of compressed data on flash are fast enough that decompression overhead is often negligible.
Performance: The Numbers
The original F2FS research paper, published at FAST 2015, showed that on a state-of-the-art mobile system, F2FS outperformed ext4 on synthetic workloads by up to 3.1× (iozone) and 2× (SQLite), while reducing elapsed time on realistic workloads by up to 40%. On server systems, the advantage extended to up to 2.5× on SATA SSDs. These gains come directly from eliminating the write-amplification penalty that ext4 imposes on flash.
Adoption and Caveats
F2FS is now the default data partition file system on Google Pixel and Nexus devices, and is widely deployed across Samsung Galaxy, Xiaomi, OPPO, and many other Android OEM lineups. Its adoption across the Android ecosystem is broad — though ext4 remains in use on some older, budget, or custom-ROM configurations.
F2FS’s journey from a 16-patch RFC on the kernel mailing list to the de facto storage substrate for a significant share of the world’s Android devices is a case study in hardware-software co-design. It did not win by being comprehensive out of the gate — it won by solving one problem with unusual precision: flash memory is not a disk, so stop pretending it is.
