Clarifications.

[pintos-anon] / doc / filesys.texi

diff --git a/doc/filesys.texi b/doc/filesys.texi
index 36c21a39748c8e61be73094318b5991a7e74f293..4d663913b29e3b49dfd881d69b1de911e5027278 100644 (file)
--- a/doc/filesys.texi
+++ b/doc/filesys.texi
@@ -26,12 +26,13 @@ Your submission should define @code{THREAD_JOIN_IMPLEMENTED} in
 
 @menu
 * File System New Code::        
+* File System Synchronization::  
 * Problem 4-1 Large Files::     
 * Problem 4-2 File Growth::     
 * Problem 4-3 Subdirectories::  
 * Problem 4-4 Buffer Cache::    
 * File System Design Document Requirements::  
-* File System FAQ::            
+* File System FAQ::             
 @end menu
 
 @node File System New Code
@@ -91,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:
@@ -265,7 +266,11 @@ Note that write-behind makes your filesystem more fragile in the face
 of crashes.  Therefore, you should
 periodically write all cached blocks to disk.  If you have
 @func{timer_sleep} from the first project working, this is an
-excellent application for it.
+excellent application for it.  (If you're still using the base
+implementation of @func{timer_sleep}, be aware that it busy-waits, which
+is not an acceptable solution.) If @func{timer_sleep}'s delays seem too
+short or too long, reread the explanation of the @option{-r} option to
+@command{pintos} (@pxref{Debugging versus Testing}).
 
 Likewise, read-ahead is only really useful when done asynchronously.
 That is, if a process wants disk block 1 from the file, it needs to
@@ -476,6 +481,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