Ayse Ozturk Sunum (0,2 MB)


Published on

  • Be the first to comment

  • Be the first to like this

Ayse Ozturk Sunum (0,2 MB)

  1. 1. The Design Of Efficient Initialization And Crash Recovery For Log-based File Systems Over Flash Memory Chin-Hsien WU and Tei-Wei KUO;Li-Pin CHAN National Taiwan University; National Chiao-Tung University
  2. 2. Flash technology considerations <ul><li>Performance-> </li></ul><ul><li>Quick mounting/unmounting </li></ul><ul><li>Effective garbage collection </li></ul><ul><li>Reliability-> </li></ul><ul><li>Efficient roll-back </li></ul><ul><li>İnitialization and crash recovery </li></ul>
  3. 3. Why Flash Memory? <ul><li>Non-volatile </li></ul><ul><li>Shock-resistant </li></ul><ul><li>Power-economic </li></ul><ul><li>Affordable capacity </li></ul><ul><li>Suitable to mobile devices due to less energy need and </li></ul><ul><li>better vibration tolerance </li></ul>
  4. 4. Features: <ul><li>Write-once: updates to existing data on a page are only possible after an erase operation </li></ul><ul><li>No in-place updates </li></ul><ul><li>Out-place updates preferred for performance and endurance </li></ul>
  5. 5. Different implementations <ul><li>NFS(Native File System): </li></ul><ul><li>JFFS/2,LFM,YAFFS/2 </li></ul><ul><li>*Access to files by vaiable sized records with (file-id and file-offset) pairs </li></ul><ul><li>Block-emulation approach: </li></ul><ul><li>FTL/Lite,CompactFlash,SmartMedia </li></ul><ul><li>*Access to files by indexes of LBA(Logical Block Addresses) and RAM resident address translation tables </li></ul>
  6. 6. Mounting time: <ul><li>Most important design consideration </li></ul><ul><li>Mount:scanning all spare areas of pages to reconstruct house-keeping data structures in main memory </li></ul><ul><li>Time consuming  </li></ul><ul><li>Will be impractical soon  </li></ul>
  7. 7. Alternative way <ul><li>Snapshot of entire housekeeping data structure </li></ul><ul><li>Speed up initialization  </li></ul><ul><li>What if crash or improper unmounting?  </li></ul>
  8. 8. Proposed Solution <ul><li>Log Management Scheme via Log-Record Manager(LRM) and Logger </li></ul><ul><li>For initialization and crash recovery scan check regions instead of all spare areas. </li></ul>
  9. 9. LRM <ul><li>Collect log-records in main memory </li></ul><ul><li>Write/Update to files </li></ul><ul><li>Merge/Delete as necessary </li></ul>
  10. 10. Logger <ul><li>Commit=write to flash memory log-records via check regions data structures </li></ul>
  11. 11. Check regions <ul><li>=#log segments and a log segment directory </li></ul><ul><li>Segments in size of a block </li></ul>
  12. 12. Log-segment directory <ul><li>Organization of check regions </li></ul>
  13. 13. Visual representation-see article
  14. 14. Related work <ul><li>Effective garbage collection->cost-benefit policy by value-driven heuristic function </li></ul><ul><li>Periodically move live data among blocks to increase even erase counts </li></ul><ul><li>Adopt SRAM as write buffers, several cleaning polic,es </li></ul><ul><li>Interrupt emulation mechanism to reduce interference of IO on user tasks </li></ul><ul><li>Layers for index processing </li></ul><ul><li>Space efficient search-tree like structure for address translation </li></ul><ul><li>In-memory file system metadata(inode and cache)during unmounting write to flash memory. </li></ul><ul><li>If crash occurs, all spare areas need to be scanned  </li></ul><ul><li>Closest work to writer’s methodology </li></ul>
  15. 15. Problem Formulation <ul><li>Characteristics: </li></ul><ul><li>NAND flash </li></ul><ul><li>No overwrite->new data is written to free space->invalidate previous which is called dead </li></ul><ul><li>Block recycling policy minimize overhead due to live pages </li></ul><ul><li>1 million erase counts max, then frequent write errors </li></ul><ul><li>Wear levelling->evenly erase blocks to increase lifetime </li></ul><ul><li>Wear-levelling if strong locality on updates causes too much overhead </li></ul>
  16. 16. Initialization and Crash Recovery <ul><li>Logical address space </li></ul><ul><li>by LBA(Logical Block Address) index </li></ul><ul><li>for block-device emulation via RAM-resident translation tables->mounting:rebuilt by scanning all spare areas </li></ul><ul><li>by (file id,offset pairs)for NFS->variable sized records to show writes/updates;hiearchical ds-tree in main memory to reflect updates;scan to construct logical view </li></ul>
  17. 17. Problem <ul><li>Scan time is intolerable to many users </li></ul><ul><li>Snapshot does not work well in case of crash and cause lengthy shut down procedure due to large fle size </li></ul>
  18. 18. Solution <ul><li>NFS is adapted in the solution which could be extended for block-emulation type. </li></ul><ul><li>NFS->writes, updates in sequential style(by appending) </li></ul><ul><li>BMI(back-up memory image) by scanning spare areas </li></ul><ul><li>PMI(primary memory image) by scanning check regions and stored in main memory </li></ul><ul><li>Additional log records are allowed as metadata about write/update operations on continous segment with starting offset and size </li></ul>
  19. 19. System architecture
  20. 20. Efficient Crash Recovery <ul><li>Writes must be in appending fashion even inside a block </li></ul><ul><li>Committing log records in-order is required for the mechanism </li></ul><ul><li>Version tags to track the recency of data </li></ul><ul><li>In case of crash most recent and most consistent check region is used for recovery </li></ul>
  21. 21. Intelligent scan <ul><li>If first page of block is free, then skip the rest which is free due to in-order commitment policy </li></ul><ul><li>If metadata match some check region, then skip that part since already exists </li></ul><ul><li>Skipping some parts intelligently based on above logic reduces crash recovery time and provides better performance. </li></ul>
  22. 22. Performance <ul><li>Performance measurements with different metrics, ratio, buffer size and crash recovery scenarios show that the solution is efficient and has good performance on different cases. </li></ul>
  23. 23. Conclusion <ul><li>Reconstruction via check regions </li></ul><ul><li>Reduce crash recovery time </li></ul><ul><li>Improve initialization time with less overhead </li></ul><ul><li>Log-management scheme works well… </li></ul>
  24. 24. Future Work <ul><li>More performance enhancement </li></ul><ul><li>Even less overhead </li></ul>