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>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The dm-log-writes infrastructure is currently implemented to use
SCRATCH_DEV as a hardcoded data device. In preparation to allow use
of specialized devices in certain circumstances, genericize the code
to allow an arbitrary data device. This requires passing the target
device as a parameter to several helper functions from various
tests. No functional changes.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Basic test case which triggers fsstress with dm-log-writes, and then
check the fs after each FUA writes.
With needed infrastructure and special handlers for journal based fs.
[Eryu: cap $nr_cpu to 8 to avoid wasting time on hosts with many cpus]
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Brian Foster
Dave Chinner
Qu Wenruo