This is a repository for my research, paper reading summaries/reviews, and relevant blog-like posts in markdown.

What is the problem the authors are trying to solve?

The authors were trying to improve utilization of disk bandwidth, which was increased to 4% simply by doubling the default block size.

What other approaches or solutions existed at the time that this work was done?

There were other filesystems available, but this paper minimally describes alternate solutions. The alternate solutions mentioned are: Multics, Hydra, Spice, “Symbolic file system”, and a few survey papers.

What was wrong with the other approaches or solutions?

What is the authors’ approach or solution?

The authors’ approach has several aspects, but only a few primary aspects described before the performance analysis of their work. The primary aspect which seems to motivate the other 2 primary aspects is increasing block size to improve disk throughput utilization, but allow “fragments” of a block to be used as blocks for small files, to minimize wasted space with many small files. This 2-tier block system makes block allocation at write time complex with a lot of overhead.

The other primary contributions of the authors’ work is parameterizing hardware characteristics to determine optimal operation pipelining given hardware features and configuration driven policy that determines how inode and data blocks are laid out on disk. An example of device features that affect operation pipelining, is whether the CPU has an I/O side channel which affects whether data transfers from storage are interrupt-driven. An example of how inode and data block layout affects throughput utilization, is how they are distributed across the cylinder groups of the storage device. It is preferable for inodes of the same directory to be co-located, and spreading out inodes of different directories the co-location is made a bit easier.

There are also many “quality of life” improvements mentioned at the end of the paper regarding features such as symbolic links (inspired by multics), support for longer file names, the ability to interact with file locks without having to open/close them and without having to request a lock to see if a lock exists (which may block until the lock is acquired), etc. While I think that features such as improved file locking would improve performance, the performance analysis in the paper only seems to be with respect to the primary contributions above (layout policies, block sizes, etc).

Why is it better than the other approaches or solutions?

How does it perform?

The primary contributions of the paper perform up to an order of magnitude better than the previous implementation of the file system, for reads and writes. For reads, the bandwidth is at least an order of magnitude improvement with some fluctuations in the additional CPU usage. For writes, the bandwidth can be up to an order of magnitude improvement with a different device (how is this useful?) but for the same device is still at least ~3x improvement. I think this performance is great.

Why is this work important?

3+ comments/questions