EE512 System Programming

1
EE512 System Programming
Lecture 12 Flash Memory File Systems I
PFFSAn Efficient and Scalable Flash File System
with a Hybrid Storage of PRAM and NAND Flash
Memories Nov. 5, 2009 Kyu Ho Park
(kpark_at_ee.kaist.ac.kr), Y. W. Park, S.H. Baek,
S.H. Lim, and C. LeeComputer Research
LaboratoryEECS, KAIST
2
Outline

• NAND flash memory characteristics
• NAND flash file systems
• JFFS2, YAFFS2
• CFFS
• PFFS design and implementation
• NAND vs. PRAM characteristics
• PFFS design goal
• PFFS implementation
• Metadata separation
• Virtual management of metadata
• Evaluation
• Conclusion

3
PRAM and Flash Memory
4
Flash memory charateristics
5
NAND Flash Memory

• NAND flash memory is beauty
• Non-volatility
• Shock-resistance
• Low power consumption
• Relatively large capacity
• Fast access time (No seek latency)
• NAND flash memory is beast
• Limited life time(100K 1M erase cycles)
• Slow program/erase operation

6
Introduction

• NAND Flash Memory
• Non-volatile, shock-resistant, power-economic
  nature
• Treated as block-oriented storage media
• NAND flash memory characteristics
• Page unit of transfer (Read/Write)
• Block unit of Erase, consist of several pages
• In-Place Update is not allowed
• Erase is required before update
• Requires Mapping management
• Garbage collection
• Read/write vs. Erase mismatch
• make free pages using Erase operation

page

block
spare

7
NAND Flash Memory Characteristics

• Operations
• Read
• Write (or Program) Change state 1 to 0
• Erase Change state 0 to 1
• Units
• Page (2KB) Read and Write Unit
• Block (64 Pages 128KB) Erase Unit
• ? The write operation should be preceded by erase
  operation which takes much longer time than a
  page write

Ref) K9F1G08X0A NAND flash memory datasheet
8
NAND flash file systems
9
NAND flash file system

• File system is aware of flash memory
  characteristics
• File system performs flash memory specific
  optimization
• Using LFS (Log-structured File System) approach
• No in-place update
• Any file system modification (data and metadata)
  is appended to log
• Need invalid page management garbage collection

Need Garbage Collection
10
Related Works

• Flash memory based file system approach
• Block Level Approach FTLFlash Translation
  LayerNFTL
• Emulate a standard block device
• Portable, file system independent Ext3, FAT can
  use on top of it
• File system direct interface Approach
  JFFSYAFFSCFFSHFFSPFFS
• OS file system design for Flash memory as storage
  system

11
Reference

• CFFS S. H. Lim and K. H. Park, An efficient
  nand flash file system for flash memory storage,
  IEEE Transactions on Computers, vol. 55, no. 7,
  pp. 906912, 2006.
• HFFS C. Lee, S. H. Baek, K. H. Park, A Hybrid
  Flash File System Based on NOR and NAND Flash
  Memories for Embedded Devices, IEEE Transactions
  on Computers, vol. 57, no. 7, pp. 1002-1008,
  2008.
• PFFS Y. Park, S. H. Lim, C. Lee, K. H. Park,
  et. Al., PFFS A Scalable Flash Memory File
  System for the Hybrid architecture of Phase
  change RAM and NAND Flash, The 23rd Annual ACM
  Symposium on Applied Computing, pp.1498-1503,
  2008.

12
Flash File System Consideration

• Reliability
• Robustness on power failure and unclean shutdown
• Wear leveling
• Balancing the number of erase cycles
• Flash Memory Scan time
• Memory footprint
• Garbage collection
• Throughput

13
Flash File Systems

• JFFS (Journaling Flash File System)
• Designed for both NOR NAND, which is not
  optimized for NAND flash memory, designed for NOR
  at the first time.
• Better than FTL (reliability and wear leveling)
• High RAM usage
• Slow mount time due to Data region scan operation
• YAFFS (Yet Another Flash File System)
• Developed for the NAND Flash Memory
• Well use the OOB region (Spare)
• FAST scan reduces mount time

14
JFFS

• Designed for NOR at the first time.
• Ideal log-structured (circular)
• High Reliability
• Full scan at a mount time
• Very long time
• Requires many RAM
• Linux 2.0, Axis corp.,
• Linux 2.2, Redhat
• Long test, Robust
• JFFS2 eCos, Linux 2.4 2.6 by Redhat

15
JFFS Log-structured
0
A
Operations
NAND Flash
150
C
B
250
Version

1
Store A (200 Bytes) at 0
Offset

0
Len

200
400
Data

AAAA
..
Version

2
Store B(200 Bytes) at 200
Offset

200
jffs
_
raw
_
inode
Len

200
Data

BBBB
..
Version

3
Offset

150
Store C(100Bytes) at 150
Len

100
Data

CCC
..
16
Garbage Collection (contd)
head
17
JFFS2

• Compression
• Recoding JFFS, but similar structure
• Efficient storage utilization
• Fast if the flash is slow
• Inode
• inode and dirent (reducing space overhead,
  supporting hard links)
• Circular log -gt non sequential log structure
• randomly select a dirty block
• Clean block marker more reliable at a
  power-failure
• memory usage
• 4MB for 128MB flash

18
YAFFS File System Design

• File
• Object Header Page means inode
• 512 bytes for each inode
• Inode number is stored in OOB region as Object Id
• Chunk Id is always 0
• Data Page
• Store data information of File
• Object Id stand for their inode
• Chunk Id means their position in file structure
  starting from 1 (1,2,3,4 etc)
• OOB data (16 bytes)
• Object Id inode number (file id)
• Chunk Id file data position (page id)
• Write serial number for integrity
• Bytes amount of stored data
• ECC for data, ECC for tag
• Data status byte, block status byte
• Updating the relevant pages

OOB region (Spare)
Data region
page
block

19
YAFFS log structure
20
YAFFS log structure (contd)
1. Writing data A(0 799) to a file
file.doc 2. Writing data B(700-999) to the file
OOB region (16 bytes)
Data region (512 bytes)
parent object ID 0 (top) Name
file.doc Attributes , File size
Object ID 100 Page ID 0 Byte count 512
Page 0
A (0511)
Object ID 100 Page ID 1 Byte count 512
Page 1
A(512799)
Object ID 100 Page ID 2, discarded Byte count
288
Page 2
unused (8001023)
A(512699)
Object ID 100 Page ID 2 Byte count 488
Page 3
B(700999)
unused (10001023)
21
YAFFS Garbage Collection

• Dirty block a block that contains at least one
  discarded page.
• Arbitrarily select a dirty block
• Set all pages of the dirty block to be discarded.
• Erase the dirty block, then the block is empty

full block
empty
Discarded page
allocated page
22
YAFFS RAM Structure
Store as Object Header
Object Header
Internal Tnode
..
Leaf Tnode
..
..

Store as Data page
Page number in NAND
Object Header Data Free
RAM usage 784 kB for 128MB flash
23
New Flash File System

• CORE Flash File System(CFFS)

24
Top Document Accessed
CFFS (Core Flash File System )
25
Motivation

• Problems of Flash Memory based File System
• Garbage collection
• Performance is degraded when garbage collection
  happens
• Affect the write performance
• Mounting (booting) time
• Reduce exhaustive mounting time
• YAFFS 24 seconds for 1 GB flash
• Generally, file system characteristics affect the
  flash memory performance
• File size distribution
• File access patterns
• Inode data characteristics

26
Core Flash File System (CFFS)

• Flash File system Design consideration
• File size distribution File access patterns
• Most files are small and most accesses are to
  small files
• Most storage is consumed by large files which are
  read most of time
• Different characteristics of inode data
• Inode is much hotter than data
• Every update of data cause the inode update
• Even not update of data, inode update is required
• File rename, file move, update of file attributes
• Minimize extra write operation
• Efficient garbage collection
• Fast boot time

27
CFFS Design

• Inode classification
• Each inode (file)
• Occupies one page
• Small files many write operations
• i-class 1 direct index only
• Large files read operations in most of time
• i-class 2 indirect index only
• As index level increase, extra write operation
  increases in NAND flash memory
• Reduce extra write operations

i-class 1
Attributes
File Name
Parent Inode
Direct index
i-class 2
Attributes
File Name
Parent Inode
Indirect index
NAND Flash Memory
28
CFFS Indirect Indexing

• CFFS
• i-class 1 Almost files are covered by i-class 1
• i-class 2 User files such as multimedia files
• Indexing
• Basic idea that enables to discriminate Inode
  blocks and data blocks

29
CFFS Design (contd)

• Inode data Separation
• Inode and data is written to different blocks in
  flash memory
• Inode is much hotter than data
• Hot-cold separation is good for garbage
  collection
• Fast scan can be made
• Only the scan of inode blocks can setup the file
  system
• InodeMapBlock manages the inode block lists

NAND structure
InodeMapBlock

RAM structure
Stored in Inode Block
Inode block
Inode
Data block
Index entries
Data
..
..

Stored in Data Block
Page number in NAND
Inode Data Free
30
CFFS Design (contd)

• InodeMapBlock design
• Log-structured inode block pointers
• InodeBlockList structure
• First 2 blocks in flash memory region

Struct InodeBlockList
Next block list
Next block list
Next block list

Block number
Block number
Block number
Page number in Super 0
Page number in Super 0
Page number in Super 1
Page offset in Super
Page offset in Super
Page offset in Super
InodeMapBlock 0
InodeMapBlock 1
page 0
page 1




31
InodeMapBlock
InodeMapBlock
Inode-stored Block Lists
UF
NIB
NP
Inode-stored Block Lists
UF
NIB
NP

Inode-stored Block Lists
UF
NIB
NP
Example
p256
260
2
p1
p2
p3
p4
p5
p6
p7
p8
p9
p10

1
All 1s
1
260
2
p257
p258
p258
pp259
p260

All 1s
1
1s
1s

• UF (Unmount Flag)
• 1 cleanly unmounted, it means that
  InodeMapBlock is valid
• NIB
• The total number of inode-stored blocks
• NP
• The number of valid pages that are required to
  store inode-stored blocks

32
CFFS mount

• Two step scan operations
• 1st step Superblock scan
• Superblock the first valid eraseblock.
• Read superblock pages
• Finding inode-stored blocks.
• 2nd step Inode block scan
• For each inode block
• Read spare regions of each pages in the inode
  block
• If the page is a valid inode block
• Scan the index entries
• Build Tnode structure

Inode block
Data block
InodeMapBlock
33
CFFS mount (contd)

• If the InodeMapBlock is invalid or corrupted.
• Read the spare region of the first page of each
  eraseblocks
• if the eraseblock is a inode block.
• 2nd step Inode block scan
• Else
• Skip the eraseblock
• Continue for the next eraseblock
• Because we can identify if a eraseblock is a
  inode block by the spare region of the first
  page.

Read part
Unread part
34
CFFS Garbage Collection

• Garbage collection is performed when
• When Block contains only discarded pages
  garbage collection
• If only small free pages exist, copy it to other
  region and garbage collection
• Inode block data block separation
• When the reclaimed block is a inode block
• Live inode page is copied to somewhere other
  inode block
• Eliminate from the InodeBlockList linked list
• Inode block pointer in superblock is set to zero
• Erase the block
• When the reclaimed block is data block
• Live data page is copied to somewhere other data
  block
• Erase the block

35
CFFS Garbage Collection

• Dirty block a block that contains at least one
  discarded page.
• Select the dirties block
• Copy a valid block to a free space
• Set all pages of the dirty block to be discarded.
• Erase the dirty block, then the block is empty

full block
empty
Discarded page
allocated page
36
Performance Evaluation

• Experimental environment
• Embedded EVB (SMDK2410)
• ARM9 SoC processor (S3C2410) 200MHz
• Main Memory 64MB
• SAMSUNG NAND K9S1208VOM SMC card

• Flash Memory Characteristics

• Embedded Evaluation Board

37
Scan Coverage
CFFS Valid InodeMapBlock
CFFS Invalid InodeMapBlock
JFFS2
YAFFS
gt
gt
gt
Read part
Read part
Read part
Read part
Unread part
Unread part
Unread part
Unread part
38
Performance Evaluation

• Performance metric
• File system Mount time (boot time)
• Scan time estimation using file distribution
• 64MB NAND Flash memory
• 80 of file system consists of small files under
  1MB
• Files, device nod, symbolic links
• 20 of file system consists of large files over
  1MB
• Comparison
• FTL, NFTL, JFFS, YAFFS, CFFS

39
Experimental Results

• Performance metric
• Garbage collection
• PostMark benchmark
• 100-300 files with file size range 512 bytes to
  70KB with distribution 8020
• 1000 transactions
• Read/write with creation/deletions
• Varying the ratio Files transactions
• 110, 13, 12
• results

40
Experimental Results

• CFFS vs. YAFFS
• NAND flash file system comparison
• Boot time (scan operation)
• Garbage collection (system performance)

41
CFFS Performance
42
Summary of CFFS

• Core Flash File System(CFFS)
• NAND Flash Memory based File System
• Designed for NAND flash memory considering
  general file system characteristics
• Architecture
• Inode classification i-class 1, i-class 2
• inode data separation
• InodeMapBlock fast searching inode blocks
• Fast boot time (scan operation)
• Efficient garbage collection
• Hot page locality
• Reduced extra writes

43
Previous flash file systems
44
Problems in flash file system

• The scalability problems
• They have to find where the metadata of file
  system in NAND flash memory
• The mounting time is increased according to the
  size of NAND flash memory
• They store temporal metadata in the main memory
• The memory usage is increased according to the
  number of files.
• The performance problems
• Each metadata update cause one page write (2KB)
• However metadata is usually under 10 bytes and
  frequently updated
• It impacts on the overall flash file system
  performance