@menu
* Project 4 Background::
+* Project 4 Suggested Order of Implementation::
* Project 4 Requirements::
* Project 4 FAQ::
@end menu
can use the Unix @command{tar} program to examine them. The tar file
for test @var{t} is named @file{@var{t}.tar}.
+@node Project 4 Suggested Order of Implementation
+@section Suggested Order of Implementation
+
+We suggest implementing the parts of this project in the following
+order to make your job easier:
+
+@enumerate
+@item
+Buffer cache (@pxref{Buffer Cache}). Implement the buffer cache and
+integrate it into the existing file system. At this point all the
+tests from project 2 (and project 3, if you're building on it) should
+still pass.
+
+@item
+Extensible files (@pxref{Indexed and Extensible Files}). After this
+step, your project should pass the file growth tests.
+
+@item
+Subdirectories (@pxref{Subdirectories}). Afterward, your project
+should pass the directory tests.
+
+@item
+Remaining miscellaneous items.
+@end enumerate
+
+You should think about synchronization throughout.
+
@node Project 4 Requirements
@section Requirements
older entry if necessary. You are limited to a cache no greater than 64
sectors in size.
-Be sure to choose an intelligent cache replacement algorithm.
-Experiment to see what combination of accessed, dirty, and other
-information results in the best performance, as measured by the number
-of disk accesses. For example, metadata is generally more valuable to
-cache than data.
+You must implement a cache replacement algorithm that is at least as
+good as the ``clock'' algorithm. Your algorithm must also account for
+the generally greater value of metadata compared to data. Experiment
+to see what combination of accessed, dirty, and other information
+results in the best performance, as measured by the number of disk
+accesses.
You can keep a cached copy of the free map permanently in memory if you
like. It doesn't have to count against the cache size.