From: David V. Winkler (dwinkler_at_windows.microsoft.com)
Date: Sun Feb 22 2004 - 20:28:29 PST
Review: The Design and Implementation of a Log-Structured File System
The basis of the Log Structured File System appears to be consolidation of writes. Standard operating systems require 5 writes and 5 seeks for the creation of a single file. The Sprite Log Structured File System requires only one. This appears to be done by writing Inode, directory, files, and inode maps all together on the disk.
The problem is essentially that seeks are not increasing in speed as quickly as computer processors.
The write strategy is explained in great detail. It would have been more understandable if instead the authors had concentrated on how the log is read rather than how the log is written. While my understanding is in fact sketchy, my understanding is as follows: All of the traditional data for a file including inode, directory, and data is written together.
Like most problems in computer science, this problem seems to have been solved by another layer of indirection. In this case, it is the Inode map. It appears that this is a map of where the inodes are on disk. The inodes each give a location for a structure, either a file or a directory. Blocks in a segment need not all be live.
A new version of a file allows the old version to be deleted and opens up space on disk. This space needs to be collected since the log files need to be (relatively) conguous. Therefore a disk defragmentation algorithm needs to always be running in the background.
The paper makes some pretty grand claims about their Sprite Log Structured File System (LFS) that seem to be borne out by their numbers. Writes in all cases are at least as fast and in the primary usage case much much faster. While some reads are slower, it doesn't seem worth caring about.
This archive was generated by hypermail 2.1.6 : Sun Feb 22 2004 - 20:28:31 PST