Syed Adnan (sadnan@ucsd.edu)
Thu, 01 Jun 2000 02:04:16 -0700

Name: Syed Adnan
Date: 5-31-00

A Fast File System For Unix

This paper talks about the re-implementation of the UNIX file system. Paper argues that this file system provides higher throughput rates by using more flexible allocation methods, better locality of references.
Paper explains the changes that have been made to previous file system, and how these changes improve the current file system. First, paper talks about the minimum size of file system block to be 4096 bytes. Paper claim that though it is good size for large files, small files must be stored differently that this method will waster a lot of space. Paper introduces the notion of division of single file system block into one or more fragments. Size of these fragments is 512 bytes. Paper goes over few rules (heuristic) to make a good use of these fragments. Paper talks about utilizing the system parameter to take advantage of the hardware. System parameters are detected and block size could be modified based on the speed bandwidth and speed of the processor to make a good use of hardware. File system layout policies are discussed in this paper. Top-level policy manages the global policies that make decision of placement of I-odes and data blocks. Few methods of improving file system
are mention here as well. Paper does talk about performance in which paper determine that reads are faster in new file system and write are slower compare to the old system.
After these issues, paper talks about few more additional enchantment of this system, but not in great detail. Over all paper was interesting to read, but I really didn't care for much of the detail of the disk cylinders. I think that log-structure idea is much more better one, and more efficient. Over all I learned few things from this paper. Using the hardware parameter technique is a good one. I think most of the system level software should look at the hardware to made the most of the latest technology with out being updated.

Name: Syed Adnan
Date: 5-31-00

The Design and Implementation of a
Log-Structure file System

Paper presents new techniques for disk storage management called a log-structure file system. Paper claim that most file system only utilize 5 to 10% of the disk bandwidth because how data is being read, and write to the disk. This system writes all modifications to disk sequentially in a log-like structure, and ends up speeding up both disk writing and crash recovery.
This system is based on the assumption that files are cached in main memory and that increasing sizes will make the caches more and more effective at satisfying read requests. For this system to be successful, system must give guarantee that there is large space available at any given time. Paper gives a solution to this problem by introducing segments. Then a segment cleaner process that continuously cleans segments with a given algorithm to ensure that there is space available at any given time. As a rule of thumb, it segregates older, more slowly changing data from young rapidly changing data and treats them differently during cleaning.
Paper talks about previous systems, and compares this approach. One of the more important issues, I think, was the segment cleaning policy. In this policy paper talks about several issues like when to clean the segment, how many times, which segment should be cleaned. Paper does give answer to all these questions explaining the policy that is being implemented. Paper talked about crash recover, and for crash recovery system used log. After crashing, which recovering, all system has to do is to go to the end of the log. But then introduced the notion of checkpoints for recovering as much data as possible. Check point are point where system was in consistent; therefore, system while recovering looks after the last check point in log, and then try to recover more data. A small interval for checkpoints increases the chances to recover a lot of data by roll-forward. Results from experiments were great, and I like this file system personally. I wonder why it didn't catch on?