1. Flash Introduction
Logfs
Brief Intro to Logfs
彭 涛
BUPT—Broadband Network Research Center
Bergwolf Flash Device and Logfs

2. Flash Introduction
Logfs
Contents
1 Flash Introduction
2 Logfs
Bergwolf Flash Device and Logfs

3. Flash Introduction
Logfs
1 Flash Introduction
2 Logfs
Bergwolf Flash Device and Logfs

4. Flash Introduction
Logfs
Characteristics
No seek time
Page: write granularity. 1 bit(NOR), 8-16
bytes(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

5. Flash Introduction
Logfs
Advantage
Performance
Reliability(people are advocating this, but evidences...
:P)
Power saving(citing Intel: 13% battery life extension
is reported in SSD)
Bergwolf Flash Device and Logfs

6. Flash Introduction
Logfs
Limitation
Must be erased before rewritten: out of place
updating
Erase block larger than fs block: garbage collection
Erase cycles(about 100,000 per erase block): wear
leveling
Others...(Like MLC NAND’s paired pages)
Bergwolf Flash Device and Logfs

7. Flash Introduction
Logfs
1 Flash Introduction
2 Logfs
Bergwolf Flash Device and Logfs

8. Flash Introduction
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)...
Bergwolf Flash Device and Logfs

9. Flash Introduction
Logfs
Log-structure layout
Treats its storage as a circular log and writes sequentially
to the head of the log.
Bergwolf Flash Device and Logfs

10. Flash Introduction
Logfs
Log-structure layout(Cont.)
Writes create multiple, chronologically-advancing
versions of both file data and meta-data.
Recovery from crashes is simpler. Upon its next
mount, the file system can reconstruct its state from
the last consistent point in the log.
Free space must be constantly reclaimed from the tail
of the log to prevent the file system from becoming
full when the head of the log wraps around to meet it.
Bergwolf Flash Device and Logfs

11. Flash Introduction
Logfs
Log-structure layout(Cont.)
logfs devides the device into segments to avoid
garbage collection IO overhead. See the gc slides.
Bergwolf Flash Device and Logfs

12. Flash Introduction
Logfs
Wandering Tree
!@#$%
Bergwolf Flash Device and Logfs

13. Flash Introduction
Logfs
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 file
deletion). And I think this is where the rumor FTL is
optimized for FAT filesystem comes from.
Bergwolf Flash Device and Logfs

14. Flash Introduction
Logfs
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 file
deletion). And I think this is where the rumor FTL is
optimized for FAT filesystem comes from.
A TRIM command is introduced into ATA specification,
telling the underlying hardware a chunk of sectors is no
longer need.
Bergwolf Flash Device and Logfs

15. Flash Introduction
Logfs
Vim
Old data recycled during gc operation is expected to be
long-lived. New data is of uncertain life expectancy. New
data used to replace older blocks in existing files is
expected to be short-lived.
Bergwolf Flash Device and Logfs

16. Flash Introduction
Logfs
Vim (Cont.)
By cleverly predicting the life time of data, it is possible to
seperate long-living data from short-living data and
thereby reduce the GC overhead later. Each type of distinc
life expectency (vim) can have a seperate segment open for
writing. Each (level, vim) tupel can be open just once. If
an open segment with unknown vim is encountered at
mount time, it is closed and ignored henceforth.
Bergwolf Flash Device and Logfs

17. Flash Introduction
Logfs
Inode File
All inodes are stored in a special file, the inode file. Single
exception is the inode file’s inode (master inode) which for
obvious reasons is stored in the journal instead. Instead of
data blocks, the leaf nodes of the inode files are inodes.
Bergwolf Flash Device and Logfs

18. Flash Introduction
Logfs
Object Store
All space except for the superblocks and journal is part of
the object store. Each segment contains a segment header
and a number of objects, each consisting of the object
header and the payload. Objects are either inodes,
directory entries (dentries), file data blocks or indirect
blocks.
Bergwolf Flash Device and Logfs

19. Flash Introduction
Logfs
Inode Allocation
Currently, inodes are allocated sequencially.
Bergwolf Flash Device and Logfs

20. Flash Introduction
Logfs
Block Allocation
Block are allocated in one of several segments depending on
their 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

21. Flash Introduction
Logfs
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 data
13 - replacement blocks, short-lived data
Bergwolf Flash Device and Logfs

22. Flash Introduction
Logfs
Logfs Dentry Structure
Logfs has on-medium dentry structure, which is stored in
inode’s datablocks.
struct logfs disk dentry {
be64 ino;
be16 namelen;
u8 type;
u8 name[LOGFS MAX NAMELEN];
} attribute ((packed));
Bergwolf Flash Device and Logfs

23. Flash Introduction
Logfs
Thank you!
Q&A
Copyright c 2009.
No rights reserved except that of others.
Bergwolf
Bergwolf Flash Device and Logfs