-The file system as provided requires external synchronization, that is,
-callers must ensure that only one thread can be running in the file
-system code at once. Your submission should use a more finely granular
-synchronization strategy. You will need to consider synchronization for
-each type of file system object. The provided code uses the following
-strategies:
-
-@itemize @bullet
-@item
-The free map and root directory are read each time they are needed for
-an operation, and if they are modified, they are written back before the
-operation completes. Thus, the free map is always consistent from an
-external viewpoint.
-
-@item
-Inodes are immutable in the provided file system, that is, their content
-never changes between creation and deletion, and furthermore only one
-copy of an inode's data is maintained in memory at once, even if the
-file is open in multiple contexts.
-
-@item
-File data doesn't have to be consistent because it's just not part of
-the model. In Unix and many other operating systems, a read of a file
-by one process when the file is being written by another process can
-show inconsistent results: it can show that none, all, or part of the
-write has completed. (However, after the write system call returns to
-its caller, all subsequent readers must see the change.) Similarly,
-when two threads write to the same part of a file at the same time,
-their data may be arbitrarily interleaved.
-
-External synchronization of the provided file system ensures that reads
-and writes are fully serialized, but your file system doesn't have to
-maintain full serialization as long as it follows the rules above.
-@end itemize
-
-@node Problem 4-1 Large Files
-@section Problem 4-1: Large Files
-
-Modify the file system to allow the maximum size of a file to be as
-large as the disk. You can assume that the disk will not be larger
-than 8 MB. In the basic file system, each file is limited to a file
-size of just under 64 kB. Each file has a header called an index node
-or @dfn{inode} (represented by @struct{inode}) that is a table of
-direct pointers to the disk blocks for that file. Since the inode is
-stored in one disk sector, the maximum size of a file is limited by
-the number of pointers that will fit in one disk sector. Increasing
-the limit to 8 MB will require you to implement doubly-indirect
-blocks.
-
-@node Problem 4-2 File Growth
-@section Problem 4-2: File Growth
-
-Implement extensible files. In the basic file system, the file size
-is specified when the file is created. One advantage of this is that
-the inode data structure, once created, never changes. In UNIX and
-most other file systems, a file is initially created with size 0 and
-is then expanded every time a write is made off the end of the file.
-Modify the file system to allow this. As one test case, allow the
-root directory file to expand beyond its current limit of ten files.
-Make sure that concurrent accesses to the inode remain properly
-synchronized.
-
-The user is allowed to seek beyond the current end-of-file (EOF). The
+@node Project 4 Design Document
+@subsection Design Document
+
+Before you turn in your project, you must copy @uref{filesys.tmpl, , the
+project 4 design document template} into your source tree under the name
+@file{pintos/src/filesys/DESIGNDOC} and fill it in. We recommend that
+you read the design document template before you start working on the
+project. @xref{Project Documentation}, for a sample design document
+that goes along with a fictitious project.
+
+@node Indexed and Extensible Files
+@subsection Indexed and Extensible Files
+
+The basic file system allocates files as a single extent, making it
+vulnerable to external fragmentation, that is, it is possible that an
+@var{n}-block file cannot be allocated even though @var{n} blocks are
+free. Eliminate this problem by
+modifying the on-disk inode structure. In practice, this probably means using
+an index structure with direct, indirect, and doubly indirect blocks.
+You are welcome to choose a different scheme as long as you explain the
+rationale for it in your design documentation, and as long as it does
+not suffer from external fragmentation (as does the extent-based file
+system we provide).
+
+You can assume that the disk will not be larger than 8 MB. You must
+support files as large as the disk (minus metadata). Each inode is
+stored in one disk sector, limiting the number of block pointers that it
+can contain. Supporting 8 MB files will require you to implement
+doubly-indirect blocks.
+
+An extent-based file can only grow if it is followed by empty space, but
+indexed inodes make file growth possible whenever free space is
+available. Implement file growth. In the basic file system, the file
+size is specified when the file is created. In most modern file
+systems, a file is initially created with size 0 and is then expanded
+every time a write is made off the end of the file. Your file system
+must allow this.
+
+There should be no predetermined limit on the size of a file, except
+that a file cannot exceed the size of the disk (minus metadata). This
+also applies to the root directory file, which should now be allowed
+to expand beyond its initial limit of 16 files.
+
+User programs are allowed to seek beyond the current end-of-file (EOF). The