1. Introduction to F2FS SRC-Nanjing Chao Yu

2. 2/23 1.Overview 2.Design 3.Performance 4.TODO Contents

3. 3/23 General information Flash Friendly File System (F2FS) Maintainer: Jaegeuk Kim / Changman Lee Exploiting NAND flash memory-based storage devices Based on Log-structured File System (LFS) Focus on Snowball effect of wandering tree High cleaning overhead Limitation Variable blocks size: 4 KB Max. file size: 3.94 TB Max. volume size: 16 TB 1. Overview – General information

4. 4/23 Multi-head logging Adaptive logging scheme Inline xattr/data Discard (run-time/batch mode) Offline filesystem check/repair Background GC Flush merge 1. Overview – Feature

5. 5/23 FTL Functions Address Mapping/Garbage Collection/Wear Leveling Address Mapping Methods Page-level Mapping (fragment / memory cost issue) Block-level Mapping (write amplification) Hybrid Mapping (AKA log block mapping) Log block (page-level) / Data block (block-level) BAST/FAST/SAST (Block/Fully/Set Associative Sector Translation) 1. Overview – FTL

6. 6/23 Merge (GC in Hybrid Mapping) Merge log blocks and data block to form up-to-data data blocks Merge types Full merge/Partial merge/Switch merge: most efficient! 1. Overview – FTL(cont’d)

7. 7/23 Log-structured File System (LFS) Assume the whole storage space as one big continuous area Write all the data sequentially Speed up both file writing & crash recovery Out-of-Place Update 1. Overview - LFS

8. 8/23 Wandering Tree Problem Propagates index updates recursively Goal Eliminate or relax the update propagation 1. Overview – Design Issue1

9. 9/23 Cleaning Overhead Free space becomes fragmented with more and more updates In order to serve new empty log space, it needs to reclaim the obs olete blocks seamlessly to users May cause unexpected long delays The goal is to hide the latencies to users 1. Overview - Design Issue2 Live data Dead block Free space Copy & compact

10. 10/23 2. Design On-disk Format Block/Segment/Section/Zone Backup for each CP/SIT/NAT Random/Sequential writes region update with different frequency

11. 11/23 Flash Awareness To drive FTL to do switch merge in most cases: Use great number of sequential write All the FS metadata are located together for locality Cleaning operation is done in a unit of section which is also fit to the FTL operation unit Start address of main area is aligned to the zone size 2. Design Overview

12. 12/23 2. Design – Solution for issue1 Wandering Tree Problem Use a term “node”, represents inode as well as various pointer block Introduce NAT(Node Address Table) containing the locations of all the “node” blocks

13. 13/23 TypeDescription Hot DataDirectory entry blocks Warm DataFile data blocks Cold DataMultimedia or GC data blocks Hot NodeDirect node blocks of directory Warm NodeDirect node blocks of file Cold NodeIndirect node blocks 2. Design – Solution for issue2 Cleaning Overhead Automatic background cleaning Different victim selection policies for foreground and background cleaning Support multi-head logs for hot and cold data separation Introduce adaptive logging for efficient block allocation

14. 14/23 indirect node Data Block direct node Double indirect node Block (4 Kbytes) Node Block 0 th 4 th 2959 th 1039282 th 3 rd 1 st 923 th 1940 th 0 th 1 st 922 th 2 nd 1941 th 2958 th … … 1023 th … …… 1024 th File body 2045 h 1025 th … 2046 th 2047 th … 1042445 th 1043465 th … 2. Design – Block Mapping …… (some basic inode infor mation, such as name, si ze, flag etc) Data[0] block address …… Data[922] block address Direct nid[0] Direct nid[1] Indirect nid[0] ……

15. 15/23 2. Design – Dir block indexing Bitmap …… dentry …… Dentries …… filewithname0000123456789 …… Filenames Filename len = 25 Adopt 32 bytes, 4 slots Level #0 Level #1 Block #0 Block #0 Block #1 Block #1 Bucket #0 Block #2 Block #2 Block #3 Block #3 Bucket #1 Block #4 Block #4 Block #5 Block #5 Bucket #2 …… 1 1 1 1 1 1 1 1

16. 16/23 For CP/flush/fsync META/NODE inode Inner cache Extent cache for each inode META/NODE/DATA bio cache for WRITE. Bio cache for metadata READAHEAD. 2. Design – Data management

17. 17/23 2. Design– Checkpoint data ckpt. On-Disc In-Core Node segment Log segment SIT NAT Checkpoint file system operation 1 file system operation 2 file system operation 3 node ckpt. SIT update NAT update Recovery line SSA checkpointing sums SIT update NAT update sums checkpointing sums node data ckpt.

18. 18/23 Method Roll-backward Roll-forward (optionally) Process Search fsynced inode/dnode from node chain (construct through - >next_blkaddr in node_footer). Store ino to recovery list. Replay each node node chain if ino is in recovery list. 2. Design - Recovery

19. 19/23 Test Result on eMMC 3. Performance -Tiotest DeviceGT-I9300Kernel3.0.31 DRAM1GPartition Size11.5 GB StorageSamsung eMMC 64 GB [ Tiotest ]

20. 20/23 Inline dentry (v2 was sent to mailing list) Extent cache enhancement (like cache in FAT?) Transparent compression Data deduplication Snapshot Offline resizing 4. TODO

21. 21/23 Flash Memory Filesystem, Korea Linux Forum, Oct. 12, 20 12 -Jaegeuk Kim Flash Memory Filesystem, Korea Linux Forum, Oct. 12, 20 12 Flash Friendly File System (F2FS), Embedded Linux Conf erence Feb 22, 2013 -JooYoung Hwang Flash Friendly File System (F2FS), Embedded Linux Conf erence Feb 22, 2013 A superblock-based flash translation layer for nand flash memory -Jeong-Uk Kang, Heeseung Jo, Jin-Soo Kim, Jo onwon Lee Reference

22. 22/23 Thank You! Q&A