Documentation and 6.3.2 test results

Also, updated README.md with dates for releases.

Change-Id: I2acd800eb621ed01aa8aeff01816058950c4dcf4
Reviewed-on: https://gerrit.franz.com:9080/8191
Reviewed-by: Kevin Layer <layer@franz.com>
Tested-by: Kevin Layer <layer@franz.com>

Makefile

@@ -250,9 +250,9 @@ runtests: testnfs
 	./testnfs -l $(LOCAL_TEST_DIR) -t $(REMOTE_TEST_DIR) \
 		$(TEST_HOST) $(TEST_NFSPATH)
 	test/bigfile-test.sh $(LOCAL_TEST_DIR) $(TEST_NFSPATH) 
-# this takes a couple of hours to run--consider upping the count and
-# running overnight
-	test/stress-test.sh $(LOCAL_TEST_DIR) $(TEST_NFSPATH) 240
+# 240 iterations takes ~5.5 hours.
+# 600 iterations takes ~13.5 hours.
+	test/stress-test.sh $(LOCAL_TEST_DIR) $(TEST_NFSPATH) 600
 
 ###############################################################################
 # misc

README.md

@@ -75,7 +75,7 @@ NFS.
 
 TBD
 
-### Version 6.3.2 [TBD August, 2017]
+### Version 6.3.2 [9 August, 2017]
 
 * Fix: It was possible for NFS clients to issue a readdir call with a
   requested max response size which is too large to fit into a UDP
@@ -87,7 +87,7 @@ TBD
   readdir requests.  Allegro NFS now detects and handles clients that
   behave in this way.
 
-### Version 6.3.1 [TBD July, 2017]
+### Version 6.3.1 [19 July, 2017]
 
 * Fix: correct a regression which resulted in empty directory listings
   for directories containing special files (such as pagefile.sys).

doc/testing.txt

@@ -36,14 +36,29 @@ The following script, test/performance.sh, runs `hammernfs' in many
 different combinations of block size (from 512 to 8192), NFS protocol
 versions (2 & 3) and transport layers (tcp & udp).
 
-Setup: put a 30M file into the NFS share "nfs.test" and:
+Setup:
 
-  $ test/performance.sh results/$version
+Server:
 
-where $version is something like 6.3.0.rc1, etc.
+ * put a 30M file into the NFS share "nfs.test", which must have write
+   access to the root of the nfs.test share.  There is usually one in
+   freon:/home/tmp/layer/nfs.test/.
 
-Then, do "make results" to see how it stacks up against previous
-versions.
+ * start the task manager and minimize it, and wait for the system to
+   settle into a true idle.  Sometimes after starting the VM, Windows
+   will go crazy for a while doing who knows what.
+
+Client:
+
+ * "make hammernfs" and then "scp -rq" this nfs repo directory over to
+   the client.
+
+ * find the IP of the server, and do
+
+   $ test/performance.sh 192.132.95.228:/nfs.test/nfstestfile 6.3.2.rc1
+
+ * copy the results file back here, git add it, and do "make results"
+   to see how it stacks up against previous versions.
 
 If multiple versions are tested, then do this when one version is
 finished testing: