Understanding the F2FS File System Structure and Operations

The article provides a detailed technical analysis of the Flash Friendly File System (F2FS), an open‑source file system designed for NAND flash storage. It explains the logical organization of F2FS, including Zones, Sections, Segments, and Blocks, and gives their typical sizes (e.g., a Segment = 512 Blocks = 2 MiB, a Block = 4 KiB).

The on‑disk layout is described, starting with the SuperBlock that stores the locations and sizes of all major areas. The SuperBlock occupies one Segment and contains two copies (offsets 1 KiB and 5 KiB). The Checkpoint area follows, holding consistency information such as timestamps, version numbers, and counts of valid blocks and nodes.

Further structures are covered: the Segment Info Table (SIT) records per‑segment metadata (type, used blocks, etc.); the Node Address Table (NAT) maps node IDs (nid) to physical block addresses; and the Segment Summary Area (SSA) provides a reverse index from block numbers to inode numbers.

To illustrate these concepts, the author creates two empty disk images (100 MiB and 1000 MiB) and formats them with make_f2fs -f -d1 -g android -O compression -O extra_attr <image> . The images are examined using the dump.f2fs utility and the T32 debugger, revealing the exact placement of Zones, Sections, Segments, and the calculated block counts for each area.

Mounting the freshly formatted images shows that the SuperBlock remains unchanged, while the Checkpoint fields (e.g., checkpoint_ver , timestamps) are updated. The first mount also moves some blocks between segments, as observed in the SIT output.

When a small file (~1.4 KiB) is created, the SuperBlock still does not change, but the Checkpoint records an increased valid_block_count and new node/inode counts. The SIT shows one additional used block, the NAT gains a new entry for nid=7 , and the SSA records the new block‑to‑inode mapping. The node for this file resides in segment 1, block 7.

Creating a larger file (~1 MiB) triggers allocation of separate data segments. A new node (e.g., nid=8 ) is added to the NAT, and many blocks are listed in the SSA. The data blocks are stored in higher‑numbered segments (e.g., segment 14), and the node’s i_addr array points to these data blocks.

Modifying the small file results in a new node being written to a fresh block (e.g., block 4626) while the old block (4624) becomes stale. The Checkpoint updates its cur_node_blkoff , the NAT entry for the inode points to the new block, and the SSA records the new block‑to‑inode relationship. The previous block remains on disk but is no longer referenced.

Deleting the large file clears its entries in the NAT and SIT, but the SSA retains historical block information, illustrating how F2FS preserves metadata for possible recovery.

Overall, the article offers a step‑by‑step, hands‑on view of how F2FS organizes data on flash storage, making it valuable for kernel developers, storage engineers, and researchers interested in file‑system internals.