From: Li Wei Date: Wed, 18 Jul 2012 10:04:29 +0000 (+0800) Subject: LU-1415 tests: Explain refresh_disk() X-Git-Tag: 2.2.91~1 X-Git-Url: https://git.whamcloud.com/?a=commitdiff_plain;h=546d07e06d241356e084784c70df467152d865d9;p=fs%2Flustre-release.git 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 Reviewed-on: http://review.whamcloud.com/3430 Tested-by: Hudson Reviewed-by: Brian Behlendorf Tested-by: Maloo Reviewed-by: Mike Pershin Reviewed-by: Oleg Drokin --- diff --git a/lustre/tests/test-framework.sh b/lustre/tests/test-framework.sh index a081522..eb58b8e 100644 --- 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 }