20090420 logfs

Flash IntroductionLogfs

Brief Intro to Logfs

彭涛

BUPT—Broadband Network Research Center

Bergwolf Flash Device and Logfs


Contents

1 Flash Introduction

2 Logfs




2 Logfs



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.



Advantage

Performance

Reliability(people are advocating this, but evidences...:P)

Power saving(citing Intel: 13% battery life extensionis reported in SSD)



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)




2 Logfs



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)...



Log-structure layout

Treats its storage as a circular log and writes sequentiallyto the head of the log.



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.



Log-structure layout(Cont.)

logfs devides the device into segments to avoidgarbage collection IO overhead. See the gc slides.



Wandering Tree

!@#$%



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.



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.



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.



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.



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.



Inode Allocation

Currently, inodes are allocated sequencially.



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







Block Allocation (Cont.)

6 - ifile data blocks

7 - ifile i1 indirect blocks





Potential levels to be used in the future:

12 - gc recycled blocks, long-lived data13 - replacement blocks, short-lived data



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));


20090420 logfs

Technology

Transcript of 20090420 logfs