LU-1415 tests: Explain refresh_disk()

Following Brian's suggestion in http://review.whamcloud.com/2981, this
patch adds a brief comment on refresh_disk(), which could be a bit
tricky to understand at first sight.

Change-Id: I83d583b5149c7648be4c68e31b6ff31f57410d9f
Signed-off-by: Li Wei <liwei@whamcloud.com>
Reviewed-on: http://review.whamcloud.com/3430
Tested-by: Hudson
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Mike Pershin <tappro@whamcloud.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>

diff --git a/lustre/tests/test-framework.sh b/lustre/tests/test-framework.sh
index a081522..eb58b8e 100644 (file)
--- a/lustre/tests/test-framework.sh
+++ b/lustre/tests/test-framework.sh
@@ -912,6 +912,16 @@ start() {
     return $RC
 }
 
+#
+# When a ZFS OSD is made read-only by replay_barrier(), its pool is "freezed".
+# Because stopping corresponding target may not clear this in-memory state, we
+# need to zap the pool from memory by exporting and reimporting the pool.
+#
+# Although the uberblocks are not updated when a pool is freezed, transactions
+# are still written to the disks.  Modified blocks may be cached in memory when
+# tests try reading them back.  The export-and-reimport process also evicts any
+# cached pool data from memory to provide the correct "data loss" semantics.
+#
 refresh_disk() {
        local facet=$1
        local fstype=$(facet_fstype $facet)
@@ -930,7 +940,8 @@ refresh_disk() {
                fi
                do_facet $facet "cp /etc/zfs/zpool.cache /tmp/zpool.cache.back"
                do_facet $facet "$ZPOOL export ${poolname}"
-               do_facet $facet "$ZPOOL import -f -c /tmp/zpool.cache.back ${poolname}"
+               do_facet $facet "$ZPOOL import -f -c /tmp/zpool.cache.back \
+                                ${poolname}"
        fi
 }