-prepared for interactions with all previous parts (as usual).
-
-@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.
-
-@node Problem 4-3 Subdirectories
-@section Problem 4-3: Subdirectories
+prepared for interactions with all previous parts.
+
+@node Testing File System Persistence
+@subsection Testing File System Persistence
+
+By now, you should be familiar with the basic process of running the
+Pintos tests. @xref{Testing}, for review, if necessary.
+
+Until now, each test invoked Pintos just once. However, an important
+purpose of a file system is to ensure that data remains accessible from
+one boot to another. Thus, the tests that are part of the file system
+project invoke Pintos a second time. The second run combines all the
+files and directories in the file system into a single file, then copies
+that file out of the Pintos file system into the host (Unix) file
+system.
+
+The grading scripts check the file system's correctness based on the
+contents of the file copied out in the second run. This means that your
+project will not pass any of the extended file system tests until the
+file system is implemented well enough to support @command{tar}, the
+Pintos user program that produces the file that is copied out. The
+@command{tar} program is fairly demanding (it requires both extensible
+file and subdirectory support), so this will take some work. Until
+then, you can ignore errors from @command{make check} regarding the
+extracted file system.
+
+Incidentally, as you may have surmised, the file format used for copying
+out the file system contents is the standard Unix ``tar'' format. You
+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 Requirements
+@section Requirements
+
+@menu
+* Project 4 Design Document::
+* Indexed and Extensible Files::
+* Subdirectories::
+* Buffer Cache::
+* File System Synchronization::
+@end menu
+
+@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
+seek itself does not extend the file. Writing at a position past EOF
+extends the file to the position being written, and any gap between the
+previous EOF and the start of the write must be filled with zeros. A
+read starting from a position past EOF returns no bytes.
+
+Writing far beyond EOF can cause many blocks to be entirely zero. Some
+file systems allocate and write real data blocks for these implicitly
+zeroed blocks. Other file systems do not allocate these blocks at all
+until they are explicitly written. The latter file systems are said to
+support ``sparse files.'' You may adopt either allocation strategy in
+your file system.
+
+@node Subdirectories
+@subsection Subdirectories