Your SlideShare is downloading. ×
0
Hashing Directory Scheme for NAND flash file system Seung-Ho Lim, Chul Lee and Kyu-Ho Park Department of  Electrical Engin...
Introduction <ul><li>Log based FFS </li></ul><ul><ul><li>metadata into data node </li></ul></ul><ul><ul><li>As flash capac...
Related Works <ul><li>JFFS2 </li></ul><ul><ul><li>Metadata and data with versioning written in free data node on flash in ...
FFS Architecture <ul><li>Design motivation </li></ul><ul><ul><li>To reduce  additional page consumption  overhead  </li></...
Directory Structure <ul><li>Directory Entries </li></ul><ul><ul><li>(filename, inode #) pair </li></ul></ul><ul><ul><li>en...
Directory Structure <ul><li>Directory Hash Table Management </li></ul><ul><ul><li>Hashed Inode # generated by using the ab...
Directory Structure <ul><li>Dentry Structure and File create/lookup method </li></ul><ul><ul><li>Can reduce file creation ...
File Data Indexing <ul><li>Inode Type </li></ul><ul><ul><li>whole flash page for inode  </li></ul></ul><ul><ul><ul><li>e.g...
File Data Indexing <ul><li>Existent FS </li></ul><ul><ul><li>Ext2 allocates only 12 entries for direct indexing (up to 6KB...
Analysis and Evaluation <ul><li>FS mount time </li></ul><ul><ul><li>super block read    hashing directory blocks    make...
Analysis and Evaluation <ul><li>For directory update </li></ul><ul><ul><li>for 2KB page size inode, </li></ul></ul><ul><ul...
Conclusion <ul><li>An efficient metadata management scheme for giga scale capacity flash memory </li></ul><ul><li>Hashing ...
Thank You !
Upcoming SlideShare
Loading in...5
×

Hashing Directory Scheme for NAND flash file system

461

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
461
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Hashing Directory Scheme for NAND flash file system"

  1. 1. Hashing Directory Scheme for NAND flash file system Seung-Ho Lim, Chul Lee and Kyu-Ho Park Department of Electrical Engineering and Computer Science, KAIST ICACT 2007 2007.9.19 Speaker : Kim, Jung-Kuk
  2. 2. Introduction <ul><li>Log based FFS </li></ul><ul><ul><li>metadata into data node </li></ul></ul><ul><ul><li>As flash capacity increases </li></ul></ul><ul><ul><ul><li>more mount time to identify metadata contents </li></ul></ul></ul><ul><ul><ul><li>more memory footprint to store the FS direct mapping structure in core </li></ul></ul></ul><ul><li>Proposed Scheme </li></ul><ul><ul><li>Efficient metadata management scheme for giga scale flash memory </li></ul></ul><ul><ul><li>Hashing directory structure </li></ul></ul><ul><ul><ul><li>for directory management </li></ul></ul></ul><ul><ul><li>Two level index structure </li></ul></ul><ul><ul><ul><li>for file index management </li></ul></ul></ul><ul><ul><li>Reduces mount time and memory footprint </li></ul></ul>
  3. 3. Related Works <ul><li>JFFS2 </li></ul><ul><ul><li>Metadata and data with versioning written in free data node on flash in sequential manner </li></ul></ul><ul><ul><li>Need to scan entire flash media at mounting time </li></ul></ul><ul><li>YAFFS/2 </li></ul><ul><ul><li>File id (inode #) and chunk number (offset) stored in spare region </li></ul></ul><ul><ul><li>Need to scan spare region only (inverse mapping) </li></ul></ul><ul><ul><li>Faster than JFFS2 </li></ul></ul><ul><li>CFFS </li></ul><ul><ul><li>InodeMapBlock : dedicated flash region (UF flag) </li></ul></ul><ul><ul><li>InodeBlockHash in core </li></ul></ul><ul><ul><li>Pseudo hot-cold separation : separate metadata and data region </li></ul></ul><ul><ul><ul><li>Enhance mount time and memory footprint </li></ul></ul></ul>
  4. 4. FFS Architecture <ul><li>Design motivation </li></ul><ul><ul><li>To reduce additional page consumption overhead </li></ul></ul><ul><ul><li>( consumed pages due to update of metadata ) </li></ul></ul><ul><ul><li>when file is created or written </li></ul></ul><ul><ul><li>Separation of data and metadata block </li></ul></ul><ul><ul><ul><li>All directory tree doesn’t need to reside in core during runtime </li></ul></ul></ul><ul><li>Block types </li></ul><ul><ul><li>Hashing directory blocks : hashing table of directory files </li></ul></ul><ul><ul><li>Inode blocks : file’s inode </li></ul></ul><ul><ul><li>Data blocks : file’s real data </li></ul></ul><ul><ul><li>Super block : map of blocks </li></ul></ul>
  5. 5. Directory Structure <ul><li>Directory Entries </li></ul><ul><ul><li>(filename, inode #) pair </li></ul></ul><ul><ul><li>entry data can be large (indirect indexing needed) </li></ul></ul><ul><ul><ul><li>lots of additional page consumption </li></ul></ul></ul><ul><ul><ul><li>proportional to degree of indexing level </li></ul></ul></ul><ul><li>Proposed Scheme </li></ul><ul><ul><li>one page for each inode </li></ul></ul><ul><ul><ul><li>Directory entries stored directly </li></ul></ul></ul><ul><ul><li>Just store the inode # of files to avoid higher degree indexing level </li></ul></ul><ul><ul><li>Filename stored in it’s inode page. </li></ul></ul><ul><ul><li>Hashing Directory Blocks </li></ul></ul><ul><ul><ul><li>List of pair of (hashed directory inode # and physical location) 8 bytes </li></ul></ul></ul>
  6. 6. Directory Structure <ul><li>Directory Hash Table Management </li></ul><ul><ul><li>Hashed Inode # generated by using the absolute path name and hashing function </li></ul></ul>
  7. 7. Directory Structure <ul><li>Dentry Structure and File create/lookup method </li></ul><ul><ul><li>Can reduce file creation / lookup overhead </li></ul></ul>from Hashing Directory Block Inode Block
  8. 8. File Data Indexing <ul><li>Inode Type </li></ul><ul><ul><li>whole flash page for inode </li></ul></ul><ul><ul><ul><li>e.g. 448 four-byte indexing entries / 2KB page (256bytes for attributes) </li></ul></ul></ul><ul><ul><li>i-class1 / i-class2 (size threshold :1MB) </li></ul></ul>Indirect index pointer Double Indirect index pointer
  9. 9. File Data Indexing <ul><li>Existent FS </li></ul><ul><ul><li>Ext2 allocates only 12 entries for direct indexing (up to 6KB) </li></ul></ul><ul><ul><ul><li>Represents 2.4% space when file size is 1MiB </li></ul></ul></ul><ul><ul><ul><li>Probability of (higher level indexing) is much higher, even if small files </li></ul></ul></ul><ul><ul><ul><li>Lots of additional flash page consumption </li></ul></ul></ul><ul><ul><ul><ul><li>Proportional to degree of indexing level </li></ul></ul></ul></ul><ul><li>Proposed Scheme </li></ul><ul><ul><li>For small file </li></ul></ul><ul><ul><ul><li>Only the inode page itself consumption needed </li></ul></ul></ul><ul><ul><ul><li>‘ cause most small files are in i-class1 </li></ul></ul></ul><ul><ul><li>For large file write </li></ul></ul><ul><ul><ul><li>Two additional page consumption needed </li></ul></ul></ul><ul><ul><ul><li>Negligible overhead ‘cause most operations for large files are read </li></ul></ul></ul>
  10. 10. Analysis and Evaluation <ul><li>FS mount time </li></ul><ul><ul><li>super block read  hashing directory blocks  make hash table & tree directory structure in core </li></ul></ul><ul><ul><li>significantly reduced </li></ul></ul><ul><li>Memory footprint </li></ul><ul><ul><li>just manage the hashing value of directory files </li></ul></ul><ul><ul><li>in case of 2KB page flash memory, </li></ul></ul><ul><ul><ul><li>256 directories / page and 16K directories / block </li></ul></ul></ul><ul><ul><ul><li># of allocated hashing dir. blocks < ten blocks for giga scale file system </li></ul></ul></ul>
  11. 11. Analysis and Evaluation <ul><li>For directory update </li></ul><ul><ul><li>for 2KB page size inode, </li></ul></ul><ul><ul><ul><li>1504 bytes (188 files) for direct entries </li></ul></ul></ul><ul><ul><ul><li>seven entries (1792 files) for direct indexing </li></ul></ul></ul><ul><ul><ul><li>one entry (almost 100K files) for indirect indexing </li></ul></ul></ul><ul><ul><li>hundreds of directory entries is enough for one directory </li></ul></ul><ul><ul><li>sufficient to update only one dir inode page in almost cases </li></ul></ul>
  12. 12. Conclusion <ul><li>An efficient metadata management scheme for giga scale capacity flash memory </li></ul><ul><li>Hashing directory structure </li></ul><ul><ul><ul><li>for directory management </li></ul></ul></ul><ul><li>Two level index structure </li></ul><ul><ul><ul><li>for file index management </li></ul></ul></ul><ul><li>Reduces mount time and memory footprint </li></ul><ul><li>Reduces file lookup and creation latency when directory hierarchy is much complex </li></ul>
  13. 13. Thank You !
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×