Update write up to reflect new test cases.

labs/fs1.html

@@ -8,9 +8,9 @@
 <h1>Lab: mount/umount</h1>
 
 <p>In this lab you will add support for mounting/unmounting of file
-systems to xv6.  This lab will expose you to many parts of the xv6 file
-system, including pathname lookup, inodes, logging, disk driver,
-concurrency, etc.
+systems to xv6.  This lab will expose you to many parts of the xv6
+file system, including pathname lookup, inodes, logging/recovery, disk
+driver, concurrency, etc.
 
 <p>Your job is modify xv6 so that your modified kernel passes the
   tests in mounttest. You will have to implement two system
@@ -181,11 +181,27 @@ add <tt>$(QEMUEXTRA)</tt> to the end of <tt>QEMUOPTS</tt>.
 <h2>umount</h2>
 
 <p>Once your kernel passes usertests and test0 of mounttest, implement
-  umount.  Make sure your kernel can pass test1 of mounttest.
+  umount.  The main challenge is mount should fail if the file system
+  is still in use; that is, if there is an inode on the mounted device
+  that has a <tt>ref > 0</tt>.  Furthermore, this test and unmounting
+  should be a atomic operation. (Hint: lock the inode cache.)  Make
+  sure your kernel can pass test1 of mounttest.
 
 <p>Test2 of mounttest stresses <namex> more; if you have done
-    everything right above, your kernel may be able to pass it.
+    everything right above, your kernel may be able to pass it.  Test3
+    tests concurrent mount/unmounts with file creation.
+
+<h2>crash safety</h2>
+
+<p>One of the main goals of the file system is to provide crash
+  safety: if there is a power failure during a file system operation,
+  xv6 should recover correctly.  It is difficult to introduce power
+  failure at the critical steps of logging; instead, we added a system
+  call that causes a kernel panic after committing an operation but
+  before installing the operation.  Test4 with crashtest tests if your
+  xv6 recovers the mounted disk correctly.
    
+       
 </body>
 </html>