diff --git a/web/src/labs/lab7.srhtml b/web/src/labs/lab7.srhtml
index f8e105c..d887e49 100644
--- a/web/src/labs/lab7.srhtml
+++ b/web/src/labs/lab7.srhtml
@@ -193,7 +193,7 @@ in the next section.</li>
 transactions. Users can modify the file system by creating, modifying,
 and deleting files, and then send a commit message to save their changes.
 Commit messages are sent via an <i>ioctl</i> (I/O control) system call:
-more information about the iotcl interface is presented in the next
+more information about the ioctl interface is presented in the next
 section.</p>
 
 <p>From the file system user's perspective, creating and comitting two new files,
@@ -218,7 +218,7 @@ to the log.</p>
 
 <p>The file system makes a guarantee to the user that committed transactions will survive
 file system crashes, and uncommitted transactions will not. When the commit
-iotcl returns, the file system makes a guarantee to the user that the commit operation
+ioctl returns, the file system makes a guarantee to the user that the commit operation
 (and all other operations in the transaction) have been persisted to the
 disk log. (By <i>persisted</i>, we mean that the sector that contains
 the given entry is actually on disk.)
@@ -291,14 +291,14 @@ fully logged.
 <p>
 As mentioned in the previous section, user-level processes send requests to commit
 to the file system
-using an iotcl system call.
+using an ioctl system call.
 In general, ioctl is a mechanism for sending driver-defined request
 codes to a driver (the idea is that both the sender and the device know
 what a given ioctl request number means, but the kernel does not
 interpret them). The supplied program
-<tt>send_iotcl</tt> can be used to send ioctls to your driver:
+<tt>send_ioctl</tt> can be used to send ioctls to your driver:
 <pre>
-$ <kbd>./send_iotcl mnt/.txn [request code]</kbd>
+$ <kbd>./send_ioctl mnt/.txn [request code]</kbd>
 </pre>
 Request codes are defined in <tt>crashmod.h</tt>. The following request codes are provided:
 <ul>
@@ -320,7 +320,7 @@ resulting log entry is replayed.
 <p>So, for example, the following command sends a commit message to your FUSE
 driver:</p>
 <pre>
-$ <kbd>./send_iotcl mnt/.txn 4000</kbd> # When this program returns, users
+$ <kbd>./send_ioctl mnt/.txn 4000</kbd> # When this program returns, users
                              # of the file system have a guarantee
                              # that their changes have been committed.
 </pre>
@@ -363,6 +363,8 @@ file systems in your lab directory.)
 </div>
 <p>
 The file system log in this lab is an array of log entries.
+Each log entry has an opcode. These opcodes are defined in log.h, e.g.
+commit entries have an opcode of 19. 
 Almost every user update to the file system will generate a
 new log entry. 
 Each log entry stores all the necessary information to reapply 
@@ -441,11 +443,31 @@ would have required a different way of finding the end of the
 log during replay, versus the approach that you will take in Exercise 2.)
 
 </p><p>
+
 It's important to make sure that your log works correctly before proceeding to the next
-exercises. Test log entries can be sent to your driver via ioctl request code 5003, and you can print log contents using request code 5002 (as
+exercises. 
+
+<ul>
+<li>
+<p>
+Type <kbd>make grade</kbd>. You should be able to pass the "basic operations" test.
+While this test 
+does not really test your implementation of <code>log_tx_add</code>
+and <code>log_tx_done</code>, it does 
+check that your implementation of these two functions
+does not break existing file system functionality.
+</p>
+
+<p>
+To do more comprehensive testing than what the grading script provides, 
+follow the instructions below:
+</p>
+</li>
+<li>
+Test log entries can be sent to your driver via ioctl request code 5003, and you can print log contents using request code 5002 (as
 described above). Below is sample
 output under correct behavior: on one terminal, run <tt>fsdriver</tt> with the -d flag:
-<pre> 
+<pre>
 # run fsdriver -d
 $ <kbd>test/makeimage.bash</kbd> # create a new image (with an empty log)
 $ <kbd>mkdir mnt</kbd> # create directory mnt if you do not have mnt already
@@ -454,13 +476,13 @@ $ <kbd>build/fsdriver -d testfs.img mnt</kbd>
 On a second terminal, issue the following commands:
 <pre>
 # send commands
-$ <kbd>./send_iotcl mnt/.txn 5003</kbd> 
-$ <kbd>./send_iotcl mnt/.txn 5003</kbd> 
-$ <kbd>./send_iotcl mnt/.txn 5002</kbd> 
-$ <kbd>./send_iotcl mnt/.txn 4000</kbd>
-$ <kbd>./send_iotcl mnt/.txn 5003</kbd>
-$ <kbd>./send_iotcl mnt/.txn 5003</kbd>
-$ <kbd>./send_iotcl mnt/.txn 5002</kbd>
+$ <kbd>./send_ioctl mnt/.txn 5003</kbd> 
+$ <kbd>./send_ioctl mnt/.txn 5003</kbd> 
+$ <kbd>./send_ioctl mnt/.txn 5002</kbd> 
+$ <kbd>./send_ioctl mnt/.txn 4000</kbd>
+$ <kbd>./send_ioctl mnt/.txn 5003</kbd>
+$ <kbd>./send_ioctl mnt/.txn 5003</kbd>
+$ <kbd>./send_ioctl mnt/.txn 5002</kbd>
 </pre>
 
 
@@ -524,6 +546,9 @@ If you are using the devbox, the output will be slightly different: FUSE will ch
 <pre>
 # [ FUSE startup output and debug information have been omitted ]
 
+# [ You might see a start-up message similar to "fusermount: failed to open
+#   /etc/fuse.conf:Permission denied". This messsage can be safely ignored. ]
+
 ...
 
 received ioctl: 5003
@@ -588,14 +613,29 @@ entry 48: op: 0, txn_id: 2
 entry 49: op: 0, txn_id: 2
 </pre>
 
-<p>Each log entry has an opcode.
-These opcodes are defined in <tt>log.h</tt>: 
-commit entries have an opcode of 19. Other opcodes exist for 
-operations that you will add logging support for later in the lab.</p>
 
-The log can be erased by creating a new disk: run <code>test/makeimage.bash</code> to 
-generate a new disk. Debugging your work may be easier if you 
-create a new disk before each debugging attempt.
+</li>
+</ul>
+<p>During the course of testing your FUSE driver, various combinations
+of operations may cause your FUSE driver
+to stop functioning or enter a non-clean state. It may be helpful to search Piazza for information about
+specific error messages.</p>
+
+More generally, to get your system to a clean
+starting state, you can do:
+<pre>
+$ fusermount -u mnt      # unmount the driver
+$ test/makeimage.bash    # make a clean testfs.img
+$ rm -rf mnt             # remove the mounting directory and its residents
+$ mkdir mnt              # recreate the mounting directory
+</pre>
+or you can invoke the following script, which is equivalent to the lines
+above:
+<pre>
+$ ./startclean.bash
+</pre>
+
+
 
 </div>
 <p></p>
@@ -606,12 +646,20 @@ when the driver is (re)started: it should replay all
 <i>committed</i> transactions -- and only committed transactions -- from
 the beginning of the log to the end of the log
 (<code>log-&gt;nentries-1</code>).
-</p>
-You can do this in two passes: first, record the 
-transaction numbers of transactions that have commit entries. Second, call
+</p><p>
+There are several ways to do this. One way is 
+is to use two passes. In the first pass, record the 
+transaction numbers of transactions that have commit entries. In the
+secnod pass, call
 <code>log_entry_install</code> on all transaction entries that are part of a committed
 transaction. <code>log_entry_install</code> takes a single log entry and modifies the 
 file system: you will fill in this function in a later exercise.
+You can also implement log_replay in a single pass. To avoid undue code
+complexity, it may be helpful to model the replay logic as a FSM (finite state machine).
+
+</p>
+Use <code>make grade</code> to test your work so far.
+You should be able to pass the "replay" test.
 </div>
 
 <h2>Logging File System Operations</h2>
@@ -637,13 +685,15 @@ following library functions useful: <tt>strcpy</tt>, <tt>memcpy</tt>,
 and <tt>time</tt> (as usual, use the man pages to learn the usage of
 these library calls; for example, <tt>man 2 time</tt>).
 
-</p></p>
+</p><p>
 Also implement the <code>OP_MKNOD</code> case branch in
 <code>log_entry_install</code> (defined in <code>log.c</code>) by calling <code>fs_mknod_install</code>
 with the appropriate arguments.
 </p>
 
-At this point, your driver should pass the test <code>test_touch_crash.bash</code>.
+At this point, your driver should pass the test
+<code>test_touch_crash.bash</code>; equivalently, you should pass the
+"touch" test when doing <tt>make grade</tt>.
 The test checks the following:
 <ul>
 <li>Calling <code>$ <kbd>touch mnt/[file]</kbd></code> creates a log entry for mknod and creates a file.</li>
@@ -656,6 +706,7 @@ is restarted.</li>
 <p></p>
 <div class="required">
 <span class="header">Exercise 4.</span>
+<p>
 Using the same pattern as in Exercise 3, 
 modify the following functions to use transactions: <code>fs_write</code>,
 <code>fs_link</code>, <code>fs_unlink</code>, <code>fs_rename</code>,
@@ -666,6 +717,27 @@ library calls that may be useful.
 It will be easiest to do this by changing one function at a time. You 
 can use the scripts provided in <code>test/</code> and <code>make grade</code> to test your
 solution. 
+
+  <ol>
+    <li>
+      After modifying <code>fs_write</code>, you should be able to pass the "echo", "time", 
+        "big_txn" and "many_txn" tests.
+    </li>
+    <li>
+      After modifying <code>fs_truncate</code> as well as <code>fs_write</code>, you should be able to pass the "truncate" test.
+    </li>
+    <li>
+      After modifying <code>fs_rename</code>, you should be able to pass the "mv" test.
+    </li>
+    <li>
+      After modifying <code>fs_link</code>, 
+        you should be able to pass the "link" test.
+    </li>
+    <li>
+      After modifying <code>fs_link</code> and <code>fs_unlink</code>, 
+        you should be able to pass the "unlink" test.
+    </li>
+  </ol>
 </div>
 <p></p>
 
