From: Brian Foster <bfoster@redhat.com>
To: fstests@vger.kernel.org
Cc: Josef Bacik <josef@toxicpanda.com>, Amir Goldstein <amir73il@gmail.com>
Subject: [PATCH 2/2] generic/482: use thin volume as data device
Date: Thu, 28 Feb 2019 09:41:28 -0500 [thread overview]
Message-ID: <20190228144128.55583-3-bfoster@redhat.com> (raw)
In-Reply-To: <20190228144128.55583-1-bfoster@redhat.com>
The dm-log-writes replay mechanism issues discards to provide
zeroing functionality to prevent out-of-order replay issues. These
discards don't always result in zeroing bevavior, however, depending
on the underlying physical device. In turn, this causes test
failures on XFS v5 filesystems that enforce metadata log recovery
ordering if the filesystem ends up with stale data from the future
with respect to the active log at a particular recovery point.
To ensure reliable discard zeroing behavior, use a thinly
provisioned volume as the data device instead of using the scratch
device directly. This slows the test down slightly, but provides
reliable functional behavior at a reduced cost from active snapshot
management or forced zeroing.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
tests/generic/482 | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/tests/generic/482 b/tests/generic/482
index 3c2199d7..3b93a7fc 100755
--- a/tests/generic/482
+++ b/tests/generic/482
@@ -22,12 +22,14 @@ _cleanup()
cd /
$KILLALL_PROG -KILL -q $FSSTRESS_PROG &> /dev/null
_log_writes_cleanup &> /dev/null
+ _dmthin_cleanup
rm -f $tmp.*
}
# get standard environment, filters and checks
. ./common/rc
. ./common/filter
+. ./common/dmthin
. ./common/dmlogwrites
# remove previous $seqres.full before test
@@ -44,6 +46,7 @@ _require_command "$KILLALL_PROG" killall
_require_scratch
# and we need extra device as log device
_require_log_writes
+_require_dm_target thin-pool
nr_cpus=$("$here/src/feature" -o)
@@ -53,9 +56,15 @@ if [ $nr_cpus -gt 8 ]; then
fi
fsstress_args=$(_scale_fsstress_args -w -d $SCRATCH_MNT -n 512 -p $nr_cpus \
$FSSTRESS_AVOID)
+devsize=$((1024*1024*200 / 512)) # 200m phys/virt size
+csize=$((1024*64 / 512)) # 64k cluster size
+lowspace=$((1024*1024 / 512)) # 1m low space threshold
+# Use a thin device to provide deterministic discard behavior. Discards are used
+# by the log replay tool for fast zeroing to prevent out-of-order replay issues.
_test_unmount
-_log_writes_init $SCRATCH_DEV
+_dmthin_init $devsize $devsize $csize $lowspace
+_log_writes_init $DMTHIN_VOL_DEV
_log_writes_mkfs >> $seqres.full 2>&1
_log_writes_mark mkfs
@@ -70,16 +79,15 @@ cur=$(_log_writes_find_next_fua $prev)
[ -z "$cur" ] && _fail "failed to locate next FUA write"
while [ ! -z "$cur" ]; do
- _log_writes_replay_log_range $cur $SCRATCH_DEV >> $seqres.full
+ _log_writes_replay_log_range $cur $DMTHIN_VOL_DEV >> $seqres.full
# Here we need extra mount to replay the log, mainly for journal based
# fs, as their fsck will report dirty log as error.
- # We don't care to preserve any data on $SCRATCH_DEV, as we can replay
+ # We don't care to preserve any data on the replay dev, as we can replay
# back to the point we need, and in fact sometimes creating/deleting
# snapshots repeatedly can be slower than replaying the log.
- _scratch_mount
- _scratch_unmount
- _check_scratch_fs
+ _dmthin_mount
+ _dmthin_check_fs
prev=$cur
cur=$(_log_writes_find_next_fua $(($cur + 1)))
--
2.17.2
next prev parent reply other threads:[~2019-02-28 14:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-28 14:41 [PATCH 0/2] fstests: prevent dm-log-writes out of order replay issues Brian Foster
2019-02-28 14:41 ` [PATCH 1/2] common/dmlogwrites: genericize log writes target device Brian Foster
2019-02-28 16:18 ` Amir Goldstein
2019-02-28 14:41 ` Brian Foster [this message]
2019-02-28 16:47 ` [PATCH 2/2] generic/482: use thin volume as data device Amir Goldstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190228144128.55583-3-bfoster@redhat.com \
--to=bfoster@redhat.com \
--cc=amir73il@gmail.com \
--cc=fstests@vger.kernel.org \
--cc=josef@toxicpanda.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox