A Design of Flash Memory File System for Embedded Systems

Systems and Computers in Japan, Vol.35, No. 1, 2004Noritaka Ishizumi (IBM Japan), Keizo Saisho (Kagawa University), Akira Fukuda

Speaker : Kim, Jung KukOS Lab, SNU

Table of Contents

IntroductionRelated WorkFlash MemoryDesign Policy of File SystemDesign of File SystemEvaluationConclusion

IntroductionFile Entry Area Contains file information Frequently created, updated, deleted

To reduce turnaround time of memory ops Reducing the amount of data written Reducing the number of block erase ops

• By writing only the difference (appending ops)

To improve durability of flash memory Balancing the number of block erase ops for each erase block (wear-leveling)

• by using erase counter & linked lists management • little degradation in efficiency

Related Work

LFS File Manager (LFM)Flash Data Integrator (FDI)Data Management System (DMS)Flash Translation Layer (FTL)Microsoft Flash File System (MS-FFS)

Flash MemoryFlash EEPROMCharacteristic of ops (cell state change)

Suspended write & block erase ops Read ops ahead delay

Design Policy of File System

Target Device Digital Hand-held devices (Dica, Voice Recorder, MP3 player)

• file size : more than tens of KiBs• # of files : several hundred• No update w/ a small unit of data• Appending operations are mainly done in update

Logical structure and interface Flat directory is adopted

• To reduce the overhead of file ops Common Flash Interface (CFI)

Requirements for flash memory file system Distribution & reduction of rewrite

• File entries at any locations by managing linked lists (block erase scattered) Real-time read ops (within a fixed interval)

• Suspend function• FDI performs block erase ops in the background

Design of File SystemOverview of file system

Link structured file system• To restrict the # of memory write to only one• File ops performed by appending ops.

Allocation of an erase block

2 problems• Fragmentation in free space

Garbage collection• Link pointer cannot be changed once it has been written

introduces ‘reserved link pointer’ & ‘delete bit’ in file entry

File block

Design of File System

Structure of file entry Basic file entry

• Invalid file entry• File name related flags• Data area related flags• Update time related flags• File link pointer related flags• Append link pointer related flags

•

Design of File SystemData appending w/o block erase

1. Read the file entry of the target file from flash memory

2. Retrieve the last file block of the file to be read by tracing linked lists

3. Create a file block consisting of data area and file entry including append link pointers, data size, update time and related flags in the write buffer

4. Write the appended data into the data area, as well as the size of appended data and the current time into the file entry on the write buffer

5. Write the contents of the write buffer into flash memory

6. Write the pointer of the file block written at (5) into the append link pointer of the file block retrieved at (2)

Design of File SystemGarbage Collection

When a file is deleted, • not actually deleted, but only flag bit is invalidated

Link modification entry• LM extends alternate link pointer of FB1,

– So it should be in the same erase block as FB1• GC trigger condition

– # of deletion increases– free space for LM becomes scarce

Intensive allocation of file blocks • when creation of a new file or appending,

– allocate unused erase blocks as far as possible

Use of suspend function• GC is time-consuming, so suspend op can be performed to diminish the delay of read op.

EvaluationSimulator and experimental environment Flash memory simulator

• read, write, block erase I/F that take out log info. such as # of bytes.

Flash memory file system (proposed here)• open, read, write, unlink, rename, lseek• erase block selection

– min. value of “current effective used area + # of block erase ops. X 2KB” – to distribute block erase during GC

Test System • Windows 2000, AMD K7 550 MHz, Visual C++ 5.0 (/Omax)

EvaluationReduction and distribution of block erase ops.

Reduction• creation & deletion of files, (10,000 logs)

– 64KB & 50KB average size– 16MB flash memory (64KB blk size)– create 255 files (DOS-FAT),

» randomly erase 10%(26) files» create 10%(26) files, repeat 2 steps

• result – 9249 : 36.1 (Link structured FFS)– 30,000 : 117.2 (DOS-FAT FS)– 3 times better

Distribution• mean erase count per block : 33• difference b/w min and max : 22

EvaluationDistribution of file creation time

Result• assumption

– 1 byte write (8us), 1 block erase (1s)• Table.1

– 260 files creation time

Drawback• 2 block erases

– should be avoided in real-time applications• background GC or timing to initiate GC is important

– eg. initiate GC at threshold # of ops

EvaluationComparison of amount of write the amount of write,

• when 100KB file created by appending a fixed amount

without append (write into new block)• Internal fragmentation increases, as the amount per appending decreases.• twice around 40KB• rapidly increase around 10KB

with append (append into a block w/ free space)• rapidly increase around 200 bytes

as the ratio of management info. VS. appending data becomes large

such a small unit rarely happens in embedded systems

Conclusion

Link structured FFS extends the life of flash memory

• through averaging the block erase count– by managing files with linked list– by providing each block with erase counter

increases freedom of appending • by appending the difference in update• and appending link modification

shortened the file writing time