-For each of these three optimizations, design a file I/O workload that
-is likely to benefit from the enhancement, explain why you expect it
-to perform better than on the original file system implementation, and
-demonstrate the performance improvement.
-
-Note that write-behind makes your filesystem more fragile in the face
-of crashes. Therefore, you should
-periodically write all cached blocks to disk. If you have
-@func{timer_sleep} from the first project working, this is an
-excellent application for it. (If you're still using the base
-implementation of @func{timer_sleep}, be aware that it busy-waits, which
-is not an acceptable solution.) 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}).
-
-Likewise, read-ahead is only really useful when done asynchronously.
-That is, if a process wants disk block 1 from the file, it needs to
-block until disk block 1 is read in, but once that read is complete,
-control should return to the process immediately while the read
-request for disk block 2 is handled asynchronously. In other words,
-the process will block to wait for disk block 1, but should not block
-waiting for disk block 2.
-
-When you're implementing this, please make sure you have a scheme for
-making any read-ahead and write-behind threads halt when Pintos is
-``done'' (when the user program has completed, etc), so that Pintos
-will halt normally and the disk contents will be consistent.
-
-@node File System Design Document Requirements
-@section Design Document Requirements
-
-As always, submit a design document file summarizing your design. Be
-sure to cover the following points:
-
-@itemize @bullet
-@item
-How did you choose to synchronize file system operations?