xfstests: improve test 286 for repeated unwritten/hole extents.
PATCH 1/1 xfstests: improve test 286 for repeated unwritten/hole extents.
Hello,
I'd like to enlarge the test coverage of 286 to includes file mapping with repeated hole/unwritten/unwritten_without_data/data intersections.
Those two new sub-tests could help verifying the current seek_data/seek_hole improvements.
Besides, I observed a weird thing at the diff of 286.full, look at the the sparse file creation output, there seems to be a significant I/O degradation compare to the old test01/test02 IOPS results:
-1 MiB, 256 ops; 0.0000 sec (1.242 GiB/sec and 325699.7455 ops/sec) +1 MiB, 256 ops; 0.0000 sec (70.161 MiB/sec and 17961.1310 ops/sec)
I run the test on same machine and same partition, I recalled the old result is generated against around 3.4-rc2(not very sure), now is updated to 3.5-rc4, does anyone hit that?
--- 286 | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 286.full | 82 +++++++++++++++++++++++++++++++++++---------------------- 2 files changed, 136 insertions(+), 33 deletions(-) mode change 100644 => 100755 286
286 +86 -1
@@ -105,10 +105,95 @@ test02() cmp $src $dest || _fail "TEST02: file bytes check failed" } -rm -f $seq.full +# seek_copy_test_03 - tests file with unwritten with data, repeated unwritten +# without data, as well as data extents mapping. +# verify results: +# 1. file size is identical. +# 2. perform cmp(1) to compare SRC and DEST file byte by byte. +test03() +{ + rm -rf $src $dest + + write_cmd="-c \"truncate 200m\"" + + # + # Firstly, make the file with allocated && reserved extents + # mapping without real data wrote. + # + for i in $(seq 0 10 180); do + offset=$(($((10 << 20)) + $i * $((1 << 20)))) + write_cmd="$write_cmd -c \"falloc $offset 10m\"" + done + + # + # Secondly, write data to some unwritten extents, hence we + # have a test file will extents mapping as: + # |data|multiple unwritten_without_data|data| repeat... + for i in $(seq 0 60 180); do + offset=$(($((20 << 20)) + $i * $((1 << 20)))) + write_cmd="$write_cmd -c \"pwrite $offset 10m\"" + done + + echo "*** test03() create sparse file ***" >>$seq.full + eval ${XFS_IO_PROG} -F -f "${write_cmd}" $src >>$seq.full 2>&1 || + _fail "create sparse file failed!" + echo "*** test03() create sparse file done ***" >>$seq.full + echo >>$seq.full + $here/src/seek_copy_test $src $dest + test $(stat --printf "%s" $src) = $(stat --printf "%s" $dest) || + _fail "TEST03: file size check failed" + + cmp $src $dest || _fail "TEST03: file bytes check failed" +} + +# seek_copy_test_04 - tests file with hole, repeated unwritten +# without data, as well as data extents mapping. +# verify results: +# 1. file size is identical. +# 2. perform cmp(1) to compare SRC and DEST file byte by byte. +test04() +{ + rm -rf $src $dest + + write_cmd="-c \"truncate 200m\"" + + # + # Firstly, make the file with allocated && reserved extents + # mapping without real data wrote. + # + for i in $(seq 30 30 180); do + offset=$(($((30 << 20)) + $i * $((1 << 20)))) + write_cmd="$write_cmd -c \"falloc $offset 5m\"" + done + + # + # Secondly, write data to some unwritten extents, hence we + # have a test file will extents mapping as: + # |hole|multiple unwritten_without_data|hole|data| repeat... + for i in $(seq 30 90 180); do + offset=$(($((30 << 20)) + $i * $((1 << 20)))) + write_cmd="$write_cmd -c \"pwrite $offset 2m\"" + done + + echo "*** test04() create sparse file ***" >>$seq.full + eval ${XFS_IO_PROG} -F -f "${write_cmd}" $src >>$seq.full 2>&1 || + _fail "create sparse file failed!" + echo "*** test04() create sparse file done ***" >>$seq.full + echo >>$seq.full + $here/src/seek_copy_test $src $dest + + test $(stat --printf "%s" $src) = $(stat --printf "%s" $dest) || + _fail "TEST04: file size check failed" + + cmp $src $dest || _fail "TEST04: file bytes check failed" +} + +rm -f $seq.full test01 test02 +test03 +test04 status=0 exit
286.full +50 -32
120 lines not on this page · raw message
Signature · 6 lines
1.7.9 _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 6 lines · Jeff Liu
Hello,
I'd like to enlarge the test coverage of 286 to includes file mapping with repeated hole/unwritten/unwritten_without_data/data intersections.
Those two new sub-tests could help verifying the current seek_data/seek_hole improvements.
Quoted 10 lines
Besides, I observed a weird thing at the diff of 286.full, look at the the sparse file creation output, there seems to be a significant I/O degradation compare to the old test01/test02 IOPS results:
-1 MiB, 256 ops; 0.0000 sec (1.242 GiB/sec and 325699.7455 ops/sec) +1 MiB, 256 ops; 0.0000 sec (70.161 MiB/sec and 17961.1310 ops/sec)
I run the test on same machine and same partition, I recalled the old result is generated against around 3.4-rc2(not very sure), now is updated to 3.5-rc4, does anyone hit that?
Quick feedback. I don't see any degradation.
OLD: 1 MiB, 256 ops; 0.0000 sec (484.027 MiB/sec and 123910.9390 ops/sec) THIS: 1 MiB, 256 ops; 0.0000 sec (494.560 MiB/sec and 126607.3195 ops/sec)
All the tests are very close to the unpatched results.
Quoted 5 lines
Signed-off-by Jie Liu<[email protected]>--- 286 | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 286.full | 82 +++++++++++++++++++++++++++++++++++----------------------
Please, drop the 286.full patch.
--Mark Tinguely.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 16 lines · Mark Tinguely
Quoted 15 lines · Jeff Liu
Hello,
I'd like to enlarge the test coverage of 286 to includes file mapping with repeated hole/unwritten/unwritten_without_data/data intersections.
Those two new sub-tests could help verifying the current seek_data/seek_hole improvements.
Besides, I observed a weird thing at the diff of 286.full, look at the the sparse file creation output, there seems to be a significant I/O degradation compare to the old test01/test02 IOPS results:
-1 MiB, 256 ops; 0.0000 sec (1.242 GiB/sec and 325699.7455 ops/sec) +1 MiB, 256 ops; 0.0000 sec (70.161 MiB/sec and 17961.1310 ops/sec)
Quoted 7 lines
Quoted 5 lines
I run the test on same machine and same partition, I recalled the old result is generated against around 3.4-rc2(not very sure), now is updated to 3.5-rc4, does anyone hit that?
Quick feedback. I don't see any degradation.
Thanks for the verification.
Quoted 8 lines
OLD: 1 MiB, 256 ops; 0.0000 sec (484.027 MiB/sec and 123910.9390 ops/sec) THIS: 1 MiB, 256 ops; 0.0000 sec (494.560 MiB/sec and 126607.3195 ops/sec)All the tests are very close to the unpatched results.
Quoted 2 lines
Signed-off-by Jie Liu<[email protected]>
Quoted 7 lines
Quoted 5 lines
--- 286 | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 286.full | 82+++++++++++++++++++++++++++++++++++----------------------
Please, drop the 286.full patch.
Ok, will re-post a little while.
Thanks,
-Jeff
Quoted 7 lines
--Mark Tinguely.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 18 lines · Mark Tinguely
Quoted 6 lines · Jeff Liu
Hello,
I'd like to enlarge the test coverage of 286 to includes file mapping with repeated hole/unwritten/unwritten_without_data/data intersections.
Those two new sub-tests could help verifying the current seek_data/seek_hole improvements.
Quoted 10 lines
Besides, I observed a weird thing at the diff of 286.full, look at the the sparse file creation output, there seems to be a significant I/O degradation compare to the old test01/test02 IOPS results:
-1 MiB, 256 ops; 0.0000 sec (1.242 GiB/sec and 325699.7455 ops/sec) +1 MiB, 256 ops; 0.0000 sec (70.161 MiB/sec and 17961.1310 ops/sec)
I run the test on same machine and same partition, I recalled the old result is generated against around 3.4-rc2(not very sure), now is updated to 3.5-rc4, does anyone hit that?
Quoted 6 lines
Quick feedback. I don't see any degradation.
OLD: 1 MiB, 256 ops; 0.0000 sec (484.027 MiB/sec and 123910.9390 ops/sec) THIS: 1 MiB, 256 ops; 0.0000 sec (494.560 MiB/sec and 126607.3195 ops/sec)All the tests are very close to the unpatched results.
Sounds like the change in size pushed the workload from running in memory under the dirty limit to being over the dirty limit and running at disk speed rather than page cache speed. i.e. the behaviour is RAM size dependent....
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs