+Read-ahead is only really useful when done asynchronously. That means,
+if a process requests disk block 1 from the file, it should block until disk
+block 1 is read in, but once that read is complete, control should
+return to the process immediately. The read-ahead request for disk
+block 2 should be handled asynchronously, in the background.
+
+@strong{We recommend integrating the cache into your design early.} In
+the past, many groups have tried to tack the cache onto a design late in
+the design process. This is very difficult. These groups have often
+turned in projects that failed most or all of the tests.
+
+@node File System Synchronization
+@subsection Synchronization
+
+The provided file system requires external synchronization, that is,
+callers must ensure that only one thread can be running in the file
+system code at once. Your submission must adopt a finer-grained
+synchronization strategy that does not require external synchronization.
+To the extent possible, operations on independent entities should be
+independent, so that they do not need to wait on each other.
+
+Operations on different cache blocks must be independent. In
+particular, when I/O is required on a particular block, operations on
+other blocks that do not require I/O should proceed without having to
+wait for the I/O to complete.
+
+Multiple processes must be able to access a single file at once.
+Multiple reads of a single file must be able to complete without
+waiting for one another. When writing to a file does not extend the
+file, multiple processes should also be able to write a single file at
+once. A read of a file by one process when the file is being written by
+another process is allowed to show that none, all, or part of the write
+has completed. (However, after the @code{write} system call returns to
+its caller, all subsequent readers must see the change.) Similarly,
+when two processes simultaneously write to the same part of a file,
+their data may be interleaved.
+
+On the other hand, extending a file and writing data into the new
+section must be atomic. Suppose processes A and B both have a given
+file open and both are positioned at end-of-file. If A reads and B
+writes the file at the same time, A may read all, part, or none of what
+B writes. However, A may not read data other than what B writes, e.g.@:
+if B's data is all nonzero bytes, A is not allowed to see any zeros.
+
+Operations on different directories should take place concurrently.
+Operations on the same directory may wait for one another.
+
+@node Project 4 FAQ
+@section FAQ
+
+@table @b
+@item How much code will I need to write?
+
+Here's a summary of our reference solution, produced by the
+@command{diffstat} program. The final row gives total lines inserted
+and deleted; a changed line counts as both an insertion and a deletion.
+
+This summary is relative to the Pintos base code, but the reference
+solution for project 4 is based on the reference solution to project 3.
+Thus, the reference solution runs with virtual memory enabled.
+@xref{Project 3 FAQ}, for the summary of project 3.
+
+The reference solution represents just one possible solution. Many
+other solutions are also possible and many of those differ greatly from
+the reference solution. Some excellent solutions may not modify all the
+files modified by the reference solution, and some may modify files not
+modified by the reference solution.
+
+@verbatim
+ Makefile.build | 5
+ devices/timer.c | 42 ++
+ filesys/Make.vars | 6
+ filesys/cache.c | 473 +++++++++++++++++++++++++
+ filesys/cache.h | 23 +
+ filesys/directory.c | 99 ++++-
+ filesys/directory.h | 3
+ filesys/file.c | 4
+ filesys/filesys.c | 194 +++++++++-
+ filesys/filesys.h | 5
+ filesys/free-map.c | 45 +-
+ filesys/free-map.h | 4
+ filesys/fsutil.c | 8
+ filesys/inode.c | 444 ++++++++++++++++++-----
+ filesys/inode.h | 11
+ threads/init.c | 5
+ threads/interrupt.c | 2
+ threads/thread.c | 32 +
+ threads/thread.h | 38 +-
+ userprog/exception.c | 12
+ userprog/pagedir.c | 10
+ userprog/process.c | 332 +++++++++++++----
+ userprog/syscall.c | 582 ++++++++++++++++++++++++++++++-
+ userprog/syscall.h | 1
+ vm/frame.c | 161 ++++++++
+ vm/frame.h | 23 +
+ vm/page.c | 297 +++++++++++++++
+ vm/page.h | 50 ++
+ vm/swap.c | 85 ++++
+ vm/swap.h | 11
+ 30 files changed, 2721 insertions(+), 286 deletions(-)
+@end verbatim
+
+@item What extra credit opportunities are available?
+
+You may implement Unix-style support for @file{.} and @file{..} in
+relative paths in their projects.
+
+You may submit with VM enabled.
+
+@item Can @code{DISK_SECTOR_SIZE} change?
+
+No, @code{DISK_SECTOR_SIZE} is fixed at 512. This is a fixed property
+of IDE disk hardware.