Explain better what we expect from the buffer cache.
[pintos-anon] / doc / filesys.texi
index 744c0b28ee9bbc64e2b6ac552ece511243085e0d..1b666b3b6e3ca24dbc3c1579ee3c8df4b10b934f 100644 (file)
@@ -287,11 +287,12 @@ disk.  Otherwise, fetch the block from disk into cache, evicting an
 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.
@@ -311,11 +312,8 @@ blocks back to disk.  The cache should also be written back to disk in
 @func{filesys_done}, so that halting Pintos flushes the cache.
 
 If you have @func{timer_sleep} from the first project working, write-behind is
-an excellent application.  If you're still using the base
-implementation of @func{timer_sleep}, be aware that it busy-waits, which
-is not acceptable here (or elsewhere).  If @func{timer_sleep}'s delays seem too
-short or too long, reread the explanation of the @option{-r} option to
-@command{pintos} (@pxref{Debugging versus Testing}).
+an excellent application.  Otherwise, you may implement a less general
+facility, but make sure that it does not exhibit busy-waiting.
 
 You should also implement @dfn{read-ahead}, that is,
 automatically fetch the next block of a file