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 Log-structured file systems Crash recovery Experience with the Sprite LFS Conclusion

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

1. Introduction References

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

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

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

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 Mapping inode number with actual address of inode

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

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

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?

3. Log-structured file systems

3. Log-structured file systems

3. Log-structured file systems

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

Checkpoint Fixed position on disk 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

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

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

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

5. Experience with the Sprite LFS

6. Conclusion LFS Collect large amounts of new data in a cache (main memory) Write the data to disk in a single large I/O that 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

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