Use standard POSIX "ustar" format for the scratch disk.

[pintos-anon] / doc / filesys.texi

diff --git a/doc/filesys.texi b/doc/filesys.texi
index 1b666b3b6e3ca24dbc3c1579ee3c8df4b10b934f..eb2ba766bf8ec675d36746cf0bb268c06374328b 100644 (file)
--- a/doc/filesys.texi
+++ b/doc/filesys.texi
@@ -16,6 +16,7 @@ to 5% extra credit if you do enable VM.
 
 @menu
 * Project 4 Background::        
+* Project 4 Suggested Order of Implementation::  
 * Project 4 Requirements::      
 * Project 4 FAQ::               
 @end menu
@@ -108,6 +109,36 @@ 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 Suggested Order of Implementation
+@section Suggested Order of Implementation
+
+To make your job easier, we suggest implementing the parts of this
+project in the following order:
+
+@enumerate
+@item
+Buffer cache (@pxref{Buffer Cache}).  Implement the buffer cache and
+integrate it into the existing file system.  At this point all the
+tests from project 2 (and project 3, if you're building on it) should
+still pass.
+
+@item
+Extensible files (@pxref{Indexed and Extensible Files}).  After this
+step, your project should pass the file growth tests.
+
+@item
+Subdirectories (@pxref{Subdirectories}).  Afterward, your project
+should pass the directory tests.
+
+@item
+Remaining miscellaneous items.
+@end enumerate
+
+You can implement extensible files and subdirectories in parallel if
+you temporarily make the number of entries in new directories fixed.
+
+You should think about synchronization throughout.
+
 @node Project 4 Requirements
 @section Requirements
 
@@ -272,7 +303,7 @@ are straightforward once the above syscalls are implemented.
 We have also provided @command{pwd}, which is not so straightforward.
 The @command{shell} program implements @command{cd} internally.
 
-The @code{pintos} @option{put} and @option{get} commands should now
+The @code{pintos} @option{extract} and @option{append} commands should now
 accept full path names, assuming that the directories used in the
 paths have already been created.  This should not require any significant
 extra effort on your part.
@@ -283,12 +314,12 @@ extra effort on your part.
 Modify the file system to keep a cache of file blocks.  When a request
 is made to read or write a block, check to see if it is in the
 cache, and if so, use the cached data without going to
-disk.  Otherwise, fetch the block from disk into cache, evicting an
+disk.  Otherwise, fetch the block from disk into the cache, evicting an
 older entry if necessary.  You are limited to a cache no greater than 64
 sectors in size.
 
 You must implement a cache replacement algorithm that is at least as
-good as the ``clock'' algorithm.  Your algorithm must also account for
+good as the ``clock'' algorithm.  We encourage you to 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
@@ -366,6 +397,10 @@ 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.
 
+Keep in mind that only data shared by multiple threads needs to be
+synchronized.  In the base file system, @struct{file} and @struct{dir}
+are accessed only by a single thread.
+
 @node Project 4 FAQ
 @section FAQ
 
@@ -484,7 +519,7 @@ corresponding sector from disk when it's created.  Keeping extra
 copies of inodes would subvert the 64-block limitation that we place
 on your cache.
 
-You can store a pointer to inode data in @struct{inode}, but it you do
+You can store a pointer to inode data in @struct{inode}, but if you do
 so you should carefully make sure that this does not limit your OS to 64
 simultaneously open files.
 You can also store other information to help you find the inode when you