generic/457: post-check fs on thin-vol device instead of scratch device

generic/457: post-check fs on thin-vol device instead of scratch device

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@synology.com>
Reviewed-by: Robbie Ko <robbieko@synology.com>
Signed-off-by: Kai-Wen Hu <kevinhu@synology.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>