Recently, we found that this test running with btrfs didn't
pass the post-check fsck on scratch device. This issue occured
due to the commit 5faafc77f ("dm space maps: don't reset space map
allocation cursor when committing") and the use of SSD as scratch
device.
In this test, it does not directly use the filesystem on scratch
device. It runs test on dm-thin volume tying two linear-mapping
devices, and those two linear devices are created from the scratch
device. When the test runs, it will write data on dm-thin volume,
and dirty the underlying scratch device.
Since the commit (5faafc77f) changes the dm space allocation policy,
it may cause more dirty blocks on underlying scratch device when we
write data on thin volume. So it makes more chance to overwrite the
position of btrfs-meta on the scratch device. Besides, our scratch
device is SSD, so there is only one copy of btrfs meta on the scratch
device. Once the btrfs-meta is overwritten, the btrfs volume will
crash, and cannot pass the fsck check.
Because, this test won't directly use the fs on scratch device. We
just disable the post-check fsck on scratch device, instead, we run
post-check fsck on thin-vol device.
Reviewed-by: Chung-Chiang Cheng <cccheng@xxxxxxxxxxxx>
Reviewed-by: Robbie Ko <robbieko@xxxxxxxxxxxx>
Signed-off-by: Kai-Wen Hu <kevinhu@xxxxxxxxxxxx>
---
tests/generic/457 | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/generic/457 b/tests/generic/457
index f4fdd81d..7e0a3157 100755
--- a/tests/generic/457
+++ b/tests/generic/457
@@ -29,6 +29,8 @@ _require_scratch_reflink
_require_cp_reflink
_require_log_writes
_require_dm_target thin-pool
+# $SCRATCH_DEV won't be directly created filesystem on, so fsck isn't required
+rm -f "${RESULT_DIR}/require_scratch"
check_files()
{
@@ -114,6 +116,7 @@ for j in `seq 0 $((NUM_FILES-1))`; do
md5=$(_md5_checksum $SCRATCH_MNT/testfile$j)
[ "${md5}" != "${test_md5[$j]}" ] && _fail "testfile$j end md5sum mismatched"
done
+_dmthin_check_fs
echo "Silence is golden"
status=0
--
2.25.1
