Your SlideShare is downloading. ×
0
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
logfs
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

logfs

274

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
274
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Flash Introduction Logfs Brief Intro to Logfs 彭 涛BUPT—Broadband Network Research Center Bergwolf Flash Device and Logfs
  • 2. Flash Introduction LogfsContents 1 Flash Introduction 2 Logfs Bergwolf Flash Device and Logfs
  • 3. Flash Introduction Logfs1 Flash Introduction2 Logfs Bergwolf Flash Device and Logfs
  • 4. Flash Introduction LogfsCharacteristics 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 LogfsAdvantage 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 LogfsLimitation 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 Logfs1 Flash Introduction2 Logfs Bergwolf Flash Device and Logfs
  • 8. Flash Introduction LogfsOverview 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 LogfsLog-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 LogfsLog-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 LogfsLog-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 LogfsWandering Tree !@#$% Bergwolf Flash Device and Logfs
  • 13. Flash Introduction LogfsGarbage 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 LogfsGarbage 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 LogfsVim 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 LogfsVim (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 LogfsInode 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 LogfsObject 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 LogfsInode Allocation Currently, inodes are allocated sequencially. Bergwolf Flash Device and Logfs
  • 20. Flash Introduction LogfsBlock 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 LogfsBlock 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 LogfsLogfs 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 LogfsThank you! Q&A Copyright c 2009. No rights reserved except that of others. Bergwolf Bergwolf Flash Device and Logfs

×