1 / 22

The Design and Implementation of a Log-Structured File System

The Design and Implementation of a Log-Structured File System. Rosenblum, Mendel, and John K. Ousterhout , ACM Transactions on Computer Systems (TOCS) 10.1 (1992): 26-52. 2019.09.23 Presentation by Sion Lee sioni322@naver.com. Introduction Designs for file systems of the 1990’s

dwilson
Download Presentation

The Design and Implementation of a Log-Structured File System

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. The Design and Implementation of a Log-Structured File System Rosenblum, Mendel, and John K. Ousterhout, ACM Transactions on Computer Systems (TOCS) 10.1 (1992): 26-52. 2019.09.23 Presentation by Sion Lee sioni322@naver.com

  2. Introduction • Designsforfilesystems of the 1990’s • Log-structured file systems • Crash recovery • Experience with the Sprite LFS • Conclusion

  3. 1. Introduction • Log-structured file system • “Log” • Crash recovery • Segment • Segment cleaner • Unix FFS vs Sprite LFS <Ext2 FS> <Sprite LFS>

  4. 1. Introduction • References

  5. 2. Designsforfilesystems of the 1990’s • Technology • CPU • Speed↑ • Main memory • Size ↑  cache size↑ • Disk • Cost • Capacity • Performance  transfer bandwidth, access time • Workload • Small-file access

  6. 2. Designsforfilesystems of the 1990’s • Problem? • 1) Spread information  frequent access • 2) Inode is separate from the file • 3) Synchronous write

  7. 3. Log-structured file systems • Improve write performance  buffering & writing at once • Issue • Retrieve information • Manage free space

  8. 3. Log-structured file systems • Inode • Write log sequentially • Mapping with inode map • Includes metadata (indirect block address, etc) • Inode map • Its address resides in cp • Mappinginode number with actual address of inode

  9. 3. Log-structured file systems • Segment • 512KB or 1MB • Include 4KB blocks • Threading, copying • Segment cleaning • 1) Read a number of segments into memory • 2) Identify the live data • 3) Write the live data back to a smaller number of clean segments • 4) Segments that were read are marked as clean

  10. 3. Log-structured file systems • Segment summary block • Useful during crash recovery • Distinguish live blocks from those that have been overwritten or deleted • Records the block age • Its address resides in cp • Identify alive blocks, file #, block #, etc • uid = version # + inode # • Segment usage table • For segment cleaning (cost-benefit) • # of live bytes, recent modified time • Its address resides in cp

  11. 3. Log-structured file systems • Segment cleaning policy • 1) When should the segment cleaner execute? • 2) How many segments should it clean at a time? • 3) Which segments should be cleaned? • 4) How should the live blocks be grouped when they are written out?

  12. 3. Log-structured file systems

  13. 3. Log-structured file systems

  14. 3. Log-structured file systems

  15. 4. Crash recovery • Traditional Unix file systems  fsck (high cost) • LFS  last location of log • Checkpoint • Roll-forward <Window system crash>

  16. 4. Crash recovery • Checkpoint • Fixed position on disk • Addresses of inode map, segment usage table, current time, pointer to the last segment written • Two checkpoint • One for system crash • The other for crash during checkpoint operation • Do checkpoint when fs is unmounted or system shut down

  17. 4. Crash recovery • Roll-forward • Scan through the log segments that were written after the last checkpoint • Segment summary block • Adjust the utilization in the segment usage table read from the checkpoint • Restore consistency between directory entries and inodes • Directory operation log Log → new segments ∙∙∙ Last checkpoint segment

  18. 5. Experience with the Sprite LFS • Sprite LFS is faster than SunOS. • Sprite LFS only kept the disk 17% busy during the create phase while saturating the CPU. • Sprite LFS has a higher write bandwidth and the same read bandwidth as SunOS. • Traditional file system: logical locality • Log-structured file system: temporal locality

  19. 5. Experience with the Sprite LFS • Cleaning costs are lower in Sprite LFS than in the simulations. • 1) all the files in the simulations were just a single block long • 2) simulated reference patterns were evenly distributed within the hot and cold file groups

  20. 5. Experience with the Sprite LFS

  21. 6. Conclusion • LFS • Collect large amounts of new data in a cache (main memory) • Write the data to disk in a single large I/Othat can use all of the disk’s bandwidth • Low cleaning overheads can be achieved  cost and benefit  Use disks an order of magnitude more efficiently than existing file systems

  22. Thank you 2019.09.23 Presentation by Sion Lee sioni322@naver.com

More Related