20090420 logfs
TRANSCRIPT
Flash IntroductionLogfs
Brief Intro to Logfs
彭 涛
BUPT—Broadband Network Research Center
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Contents
1 Flash Introduction
2 Logfs
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
1 Flash Introduction
2 Logfs
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Characteristics
No seek time
Page: write granularity. 1 bit(NOR), 8-16bytes(ECCNOR), 256, 512 or 2048 bytes(NAND,AGAND)
Erase block: usually a power of 2 from 32k to 256k.
ECC(error checking and correction) is needed.
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Advantage
Performance
Reliability(people are advocating this, but evidences...:P)
Power saving(citing Intel: 13% battery life extensionis reported in SSD)
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Limitation
Must be erased before rewritten: out of placeupdating
Erase block larger than fs block: garbage collection
Erase cycles(about 100,000 per erase block): wearleveling
Others...(Like MLC NAND’s paired pages)
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
1 Flash Introduction
2 Logfs
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Overview
A flash filesystem for Linux working on top of MTD.
A journaling filesystem.
A log-structured filesystem.
out of place updating: wandering tree
Wear leveling: pre scanning and determining
Garbage collection.
MLC flash support (uncertain)...
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Log-structure layout
Treats its storage as a circular log and writes sequentiallyto the head of the log.
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Log-structure layout(Cont.)
Writes create multiple, chronologically-advancingversions of both file data and meta-data.
Recovery from crashes is simpler. Upon its nextmount, the file system can reconstruct its state fromthe last consistent point in the log.
Free space must be constantly reclaimed from the tailof the log to prevent the file system from becomingfull when the head of the log wraps around to meet it.
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Log-structure layout(Cont.)
logfs devides the device into segments to avoidgarbage collection IO overhead. See the gc slides.
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Wandering Tree
!@#$%
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Garbage Collection
This is the reason why a flash filesystem is needed.FTL has to look into each fs’s internal structure to find
out which block is in use and which is obsolete(due to filedeletion). And I think this is where the rumor FTL isoptimized for FAT filesystem comes from.
A TRIM command is introduced into ATA specification,telling the underlying hardware a chunk of sectors is nolonger need.
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Garbage Collection
This is the reason why a flash filesystem is needed.FTL has to look into each fs’s internal structure to find
out which block is in use and which is obsolete(due to filedeletion). And I think this is where the rumor FTL isoptimized for FAT filesystem comes from.
A TRIM command is introduced into ATA specification,telling the underlying hardware a chunk of sectors is nolonger need.
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Vim
Old data recycled during gc operation is expected to belong-lived. New data is of uncertain life expectancy. Newdata used to replace older blocks in existing files isexpected to be short-lived.
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Vim (Cont.)
By cleverly predicting the life time of data, it is possible toseperate long-living data from short-living data andthereby reduce the GC overhead later. Each type of distinclife expectency (vim) can have a seperate segment open forwriting. Each (level, vim) tupel can be open just once. Ifan open segment with unknown vim is encountered atmount time, it is closed and ignored henceforth.
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Inode File
All inodes are stored in a special file, the inode file. Singleexception is the inode file’s inode (master inode) which forobvious reasons is stored in the journal instead. Instead ofdata blocks, the leaf nodes of the inode files are inodes.
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Object Store
All space except for the superblocks and journal is part ofthe object store. Each segment contains a segment headerand a number of objects, each consisting of the objectheader and the payload. Objects are either inodes,directory entries (dentries), file data blocks or indirectblocks.
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Inode Allocation
Currently, inodes are allocated sequencially.
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Block Allocation
Block are allocated in one of several segments depending ontheir level. The following levels are used:
0 - regular data block
1 - i1 indirect blocks
2 - i2 indirect blocks
3 - i3 indirect blocks
4 - i4 indirect blocks
5 - i5 indirect blocks
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Block Allocation (Cont.)
6 - ifile data blocks
7 - ifile i1 indirect blocks
8 - ifile i2 indirect blocks
9 - ifile i3 indirect blocks
10 - ifile i4 indirect blocks
11 - ifile i5 indirect blocks
Potential levels to be used in the future:
12 - gc recycled blocks, long-lived data13 - replacement blocks, short-lived data
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Logfs Dentry Structure
Logfs has on-medium dentry structure, which is stored ininode’s datablocks.struct logfs disk dentry {
be64 ino;be16 namelen;u8 type;u8 name[LOGFS MAX NAMELEN];
} attribute ((packed));
Bergwolf Flash Device and Logfs
Flash IntroductionLogfs
Thank you!
Q & A
Copyright c© 2009.No rights reserved except that of others.
Bergwolf
Bergwolf Flash Device and Logfs