Pádraig Brady wrote: ... >> +# Require a fiemap-enabled FS. >> +df -T -t btrfs -t xfs -t ext4 -t ocfs2 . \ >> + || skip_ "this file system lacks FIEMAP support" >> + >> +# Create a large-but-sparse file. >> +timeout 1 dd bs=1 seek=1T of=f < /dev/null || framework_failure_ >> + >> +# Nothing can read (much less write) that many bytes in so little time. >> +timeout 3 cp f f2 || framework_failure_ > > I'm a bit worried with a 1s timeout. > The following will only give false negatives over 100GB/s > > timeout 10 truncate -s1T f || framework_failure_ > timeout 10 cp f f2 || framework_failure_
Thanks. Using truncate there is better, and 10 seconds is more consistent with many other timeout-using tests. While fixing that I noticed another problem: the latter command should be setting fail=1. diff --git a/tests/cp/fiemap-perf b/tests/cp/fiemap-perf index 429e59b..6c588cb 100755 --- a/tests/cp/fiemap-perf +++ b/tests/cp/fiemap-perf @@ -24,9 +24,9 @@ df -T -t btrfs -t xfs -t ext4 -t ocfs2 . \ || skip_ "this file system lacks FIEMAP support" # Create a large-but-sparse file. -timeout 1 dd bs=1 seek=1T of=f < /dev/null || framework_failure_ +timeout 10 truncate -s1T f || framework_failure_ # Nothing can read (much less write) that many bytes in so little time. -timeout 3 cp f f2 || framework_failure_ +timeout 10 cp f f2 || fail=1 Exit $fail > I wouldn't worry about filling file systems either, > as we're already limiting to ext4 etc. Nor would I. >> Subject: [PATCH 9/9] tests: cp/fiemap: exercise previously-failing parts >> +# Ensure that --sparse=always can restore holes. >> +rm -f k >> +# Create a file starting with an "x", followed by 257K-1 0 bytes. >> +printf x > k || framework_failure_ >> +dd bs=1k seek=1 of=k count=255 < /dev/zero || framework_failure_ > > S/257/256/ ? Good catch. Initially I had count=256 and the comment was correct, but I changed to 255 and didn't adjust. I've corrected the comment as you suggest. I've amended those two commits, rebased, and pushed to a new branch: fiemap-copy-3.
