1 / 33

Optimization of LFS with Slack Space Recycling and Lazy Indirect Block Update

Optimization of LFS with Slack Space Recycling and Lazy Indirect Block Update. Yongseok Oh <ysoh@uos.ac.kr> The 3rd Annual Haifa Experimental Systems Conference May 24, 2010 Haifa, Israel. Yongseok Oh and Donghee Lee (University of Seoul) Jongmoo Choi ( Dankook University)

oistin
Download Presentation

Optimization of LFS with Slack Space Recycling and Lazy Indirect Block Update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Optimization of LFS with Slack Space Recycling and Lazy Indirect Block Update Yongseok Oh <ysoh@uos.ac.kr> The 3rd Annual Haifa Experimental Systems Conference May 24, 2010 Haifa, Israel • Yongseok Oh and Donghee Lee (University of Seoul) • JongmooChoi (Dankook University) • Eunsam Kim and Sam H. Noh (Hongik University)

  2. Outline Introduction Slack Space Recycling and Lazy Indirect Block Update Implementation of SSR-LFS Performance Evaluation Conclusions

  3. Log-structured File System Segment buffer Storage A B C D • LFS collects small write requests and writes them sequentially to the storage device [Rosenblum at el, ACM TOCS ‘91] • Advantages • Superior write performance for random workloads • Fast recovery • Drawbacks • On-demand cleaning • Cascading meta-data update

  4. Storage Devices • Hard Disk Drives • Mechanical components – disk head, spindle motor, and platter • Poor random read/write performance • Solid State Drives • Consist of NAND flash memory, no mechanical parts • High performance, low-power consumption, and shock resistance • Sequential writes are faster than random writes

  5. Outline Introduction Slack Space Recycling and Lazy Indirect Block Update Implementation of SSR-LFS Performance Evaluation Conclusions

  6. LFS cleaning Copy C D A B Segment 1 Segment 2 Segment 3 A B C D • To make free segments • LFS cleaner copies valid blocks to other free segment • On-demand cleaning • Overall performance decreases • Background cleaning • It does not affect the performance

  7. Hole-plugging Copy A B Segment 1 A B Segment 2 Segment 3 C D Matthews et al. employed Hole-plugging in LFS [Matthews et al, ACM OSR ’97] The cleaner copies valid blocks to holes ofother segments

  8. Slack Space Recycling (SSR) Scheme Segment buffer E E G F F H SSR SSR G H A B C D Segment 1 Segment 2 Segment 3 We proposed SSR scheme that directly recycles slack space to avoid on-demand cleaning Slack Space is invalid area in used segment

  9. Cascading meta-data update Double Indirect i-node 1 Indirect C N-1 N Data C D B A A’ A B’ B update Update update A’ B’ C’ D’ Update 1 Segment 1 Segment 2 Data’ N-1 C’ N A’ B’ D’ C’ C A E F B D Update of a data block incurs cascading meta-data update Modification of a data block consumes 4 blocks

  10. Lazy Indirect Block Update (LIBU) scheme Indirect Map Double Indirect i-node 1 Indirect 2 N-1 N Data E C D B A A’ A IBC (Indirect Block Cache) B B’ C’ C Insert Update Insert Insert A’ D’ Update 1 Segment 1 Segment 2 Data’ N-1 C’ N E’ A’ B’ D’ 2 E C A D B F • We propose LIBU scheme to decrease cascading meta-data update • LIBU uses IBC (Indirect Block Cache) to absorb the frequent update of indirect blocks • Indirect Map is necessary to terminate cascading meta data update

  11. Crash Recovery i-node map Segment usage table indirect map indirect blocks RAM flush Power failure Consistent state Rebuild Write Write Scan Disk search the last checkpoint Check point(last) Check point • For crash recovery, LFS periodically stores checkpoint information • If power failure occurs, • search the last check point • scan all segments written after the last check point • rebuild i-node map, segment usage table, indirect map, and indirect blocks in IBC

  12. Outline Introduction Slack Space Recycling and Lazy Indirect Block Update Implementation of SSR-LFS Performance Evaluation Conclusions

  13. Implementation of SSR-LFS Userspace Kernel SSR-LFS Core write(“/mnt/file”) IBC buffer cache i-node cache Syncer Cleaner Recycler libfuse VFS FUSE Architecture of SSR-LFS • We implemented SSR-LFS (Slack Space Recycling LFS) • Using FUSE (Filesystem in Userspace) framework in Linux • SSR-LFS selectively chooses either SSR or cleaning • When the system is idle, it performs background cleaning • When the system is busy, it performs SSR or on-dmenad cleaning • Ifaverage slack size is too small, it selects on-demand cleaning • Otherwise, it selects SSR

  14. Outline Introduction Slack Space Recycling and Lazy Indirect Block Update Implementation of SSR-LFS Performance Evaluation Conclusions

  15. Experimental Environment • For comparison, we used several file systems • Ext3-FUSE • Org-LFS(cleaning) • Org-LFS(plugging) • SSR-LFS • Benchmarks • IO TEST that generates random write workload • Postmark that simulates the workload of a mail server • Storage Devices • SSD – INTEL SSDSA2SH032G1GN • HDD – SEAGATE ST3160815AS

  16. Random Update Performance HDD SSD • SSR-LFS shows better than others for a wide range of utilization • On HDD • SSR-LFS and Org-LFS outperform Ext3-FUSE under utilization of 85%, • On SSD • Ext3-FUSE outperforms Org-LFS due to optimization of SSD for random writes

  17. Postmark Benchmark Result (1) • Medium file size (16KB ~ 256KB) • Subdirectories 1000, # of files 100,000, # of transactions 100,000 • SSR-LFS outperforms other file systems on both devices • Org-LFS shows better performance than Ext3-FUSE on HDD • Ext3-FUSE shows comparative performance to Org-LFS on SSD

  18. Postmark Benchmark Result (2) • Small file size (4KB ~ 16KB) • Subdirectories 1000, # of files 500,000 ,# of transactions 200,000 • Ext3-FUSE performs better than other file systems on SSD • due to meta-data optimization of Ext3 such as hash-based directory

  19. Outline Introduction Slack Space Recycling and Lazy Indirect Block Update Implementation of SSR-LFS Performance Evaluation Conclusions

  20. Conclusions • SSR-LFS outperforms original style LFS for a wide range of utilization • Future works • Optimization of meta-data structures • Cost-based selection between cleaning and SSR • We plan to release the source code of SSR-LFS this year • http://embedded.uos.ac.kr

  21. Q & A Thank you

  22. Back up slides

  23. Storage devices

  24. Measurement of FUSE overhead • To identify the performance penalty of a user space implementation • Ext3-FUSE underperforms Kernel Ext3 for almost patterns • Due to FUSE overhead

  25. Postmark Benchmark Result (1) 1302 cleanings 4142 SSRs • Medium file size (16KB ~ 256KB) • Subdirectories 1000, # of files 100,000, # of transactions 100,000 • SSR-LFS outperforms other file systems on both devices • Org-LFS shows better performance then Ext3-FUSE on HDD • Ext3-FUSE shows comparative performance to Org-LFS on SSD

  26. Postmark Benchmark Result (2) 1692 cleanings 1451 SSRs 3018 cleanings • Small file size (4KB ~ 16KB) • Subdirectories 1000, # of files 500,000 ,# of transactions 200,000 • Ext3-FUSE performs better than other file systems on SSD • due to meta-data optimization of Ext3 such as hash-based directory

  27. Postmark Benchmark Result (3) • Large file size (disappeared in the paper) • File size 256KB ~ 1MB • Subdirectories 1000 • # of files 10,000 • # of transactions 10,000

  28. Statistics of IO-TEST

  29. Random Update Performance Create files Disk 90%(High threshold) 20%(desired threshold) Random update files Delete files • IO TEST benchmark • 1st stage • Creates 64KB files until 90% utilization • Randomly deletes files until target utilization • 2nd stage • Randomly updates up to 4GB of file capacity • Measures the elapsed time in this stage • LFS has no free segments • Including cleaning or SSR cost

  30. Experimental Environment

  31. Write Request Comparison of cleaning and SSR scheme Tidle Tseg Tssr Tseg Foreground write SSR write Tback-ground Cleaning case : Background 1 0 3 0 2 1 Free Segments Time T2 T3 T1 Write Request SSR case : delay x Tidle Tseg Ton-demand Tseg Foreground cleaning write write Tback-ground Background 1 0 1 3 0 2 1 Free Segments Time T2 T1 T3

  32. FIO Benchmark Result (1) To measure the performance impact of Lazy Indirect Block Update 1 worker - File size 1GB, Request size 4KB, Sync I/O mode SSR-LFS outperforms Org-LFS and Ext3-FUSE for sequential and random writes on both devices

  33. FIO Benchmark Result (2) 4 workers - File size 1GB, Request size 4KB, Sync mode The LIBU scheme has greater impact on performance when four workers are running

More Related