Switch the base file system from direct-indexed inodes to extents.

[pintos-anon] / doc / filesys.texi

diff --git a/doc/filesys.texi b/doc/filesys.texi
index 767cfa3a257703de6196da298d9bcbd858a3d91f..b71974f717da1437ab95a72ff941e5b8c81219c8 100644 (file)
--- a/doc/filesys.texi
+++ b/doc/filesys.texi
@@ -27,7 +27,7 @@ Your submission should define @code{THREAD_JOIN_IMPLEMENTED} in
 @menu
 * File System New Code::        
 * File System Synchronization::  
-* Problem 4-1 Large Files::     
+* Problem 4-1 Indexed Files::     
 * Problem 4-2 File Growth::     
 * Problem 4-3 Subdirectories::  
 * Problem 4-4 Buffer Cache::    
@@ -92,7 +92,7 @@ prepared for interactions with all previous parts (as usual).
 
 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 should use a more finely granular
+system code at once.  Your submission should use a finer-grained
 synchronization strategy.  You will need to consider synchronization
 issues for each type of file system object.  The provided code uses the
 following strategies:
@@ -124,19 +124,22 @@ 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
+@node Problem 4-1 Indexed Files
+@section Problem 4-1: Indexed 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.
+The basic file system allocates files as a single extent, making it
+vulnerable to external fragmentation.  Eliminate this problem by
+modifying the 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.)
+
+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.
 
 @node Problem 4-2 File Growth
 @section Problem 4-2: File Growth
@@ -481,6 +484,9 @@ the 64-block limit.  The same rule applies to anything that's
 ``similar'' to a block of disk data, such as a @struct{inode_disk}
 without the @code{length} or @code{sector_cnt} members.
 
+You can keep a cached copy of the free map in memory permanently if you
+like.  It doesn't have to count against the cache size.
+
 That means you'll have to change the way the inode implementation
 accesses its corresponding on-disk inode right now, since it currently
 just embeds a @struct{inode_disk} in @struct{inode} and reads the