From: Nathan Dire (ndire_at_cs.washington.edu)
Date: Mon Feb 23 2004 - 15:44:40 PST
In "The Design and Implementation of a Log-Structured File System", Rosenblum
and Ousterhout present a new file system structure which organizes the disk as
a log. This structure is optimized for small file writes, and the prototype
implementation, Sprite LFS reflects this.
This proposed file system structure is motivated by the changing
characteristics of computer hardware. CPU and memory are growing at an
exponential rate, but disk performance is relatively limited. Thus, caching
has become more common and performance is increasingly limited by disks. Also,
the workload in many office environments is dominated by small files, and
current file systems may spread allocations around the disk, so throughput
is limited by seeking.
The goal of a log-structure file system is to coalesce file system changes
into large sequential writes. To allow large sequential writes, a
log-structure file system maintains fixed-size contiguous extents on disk
called segments. This is the most difficult part of implementing a
log-structure file system. The segments may become fragmented and thus must
be periodically cleaned by combining them.
In addition to write performance, a log-structured file system allows for
easier recovery from crashes. Whereas in traditional Unix FFS, the entire
disk must be scanned to look for inconsistencies, the last changes to a
log-structure file system are known.
In general, I think many of the problems that a log-structured file system is
meant to address still exist today. For example, as disks have grown, the
process of running fsck on FFS-stlye file systems after crashes has become
even worse. And, ever larger disks increase the seek penalty associated with
non-contiguous allocations. On the other hand, I think media files are
becoming a much more important consideration for file systems, so read
performance for large files may be more important than it was at the time of
this paper.
I do have to question the authors' assumption that it's OK to lose some work b
buffering writes. It seems that if FFS were modified to buffer more data, it
might perform significantly better as well. Overall, I would consider this
proposal quite compelling as an option for certain scenarios, but I'm not as
confident that it remains a universally better option in all of today's
environments.
This archive was generated by hypermail 2.1.6 : Mon Feb 23 2004 - 15:44:42 PST