Hi All,
Sorry for the delay on this set. I meant to send it a while back,
but it looks like the email did not get through, so I am resending it.
This patch corrects a 252 test failure when run on ext4. Becuase ext4
and xfs do not handle splitting extents in the same way, it was decided
that the fiemap filter should not display an extent type. Only the
location of the hole. An md5 check sum has also been added to make
sure the file contents are correct.
Also, another patch was sumbitted that modifes the same code in 242.out.
Assumeing that patch will go through, this set was modifed to be applied on
top of Christoph's "[PATCH] xfstests: update test 042 golden output" (06/20/2011).
Allison Henderson (3):
XFS TESTS: Fix 252 Failure: Relax fiemap filter
XFS TESTS: Fix 252 Failure: Update 252 Golden Output
XFS TESTS: Fix 252 Failure: Update 242 Golden Output
242.out | 17 ++++
252 | 8 +-
252.out | 272 ++++++++++++++++++++++++++++++++++++----------------------
common.punch | 38 ++++++++-
4 files changed, 227 insertions(+), 108 deletions(-)
The current test 252 tests punch hole by collecting fiemap information
on the test file. However this does not work for all file systems since
not all file systems layout their extents in the same way.
This patch corrects this by adding a -h flag to the fiemap filter that ignores
the extent types in the fiemaps. The result is that the fiemap contains only
"extent" or "hole", instead of "unwritten", "data" or "hole". A checksum has
also been added to each test to help ensure the file contents are correct.
Signed-off-by: Allison Henderson <[email protected]>
---
v1 -> v2
Moved new golden output for 252 into a seperate patch to help make the set
easier to read
:100755 100755 5efa243... 1289094... M 252
:100644 100644 ddf63b0... d3c89eb... M common.punch
252 | 8 ++++----
common.punch | 38 ++++++++++++++++++++++++++++++++++++--
2 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/252 b/252
index 5efa243..1289094 100755
--- a/252
+++ b/252
@@ -53,15 +53,15 @@ _require_xfs_io_fiemap
testfile=$TEST_DIR/252.$$
# Standard punch hole tests
-_test_generic_punch falloc fpunch fpunch fiemap _filter_fiemap $testfile -F
+_test_generic_punch falloc fpunch fpunch fiemap "_filter_fiemap -h" $testfile -F
# Delayed allocation punch hole tests
-_test_generic_punch -d falloc fpunch fpunch fiemap _filter_fiemap $testfile -F
+_test_generic_punch -d falloc fpunch fpunch fiemap "_filter_fiemap -h" $testfile -F
# Multi hole punch tests
-_test_generic_punch -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F
+_test_generic_punch -k falloc fpunch fpunch fiemap "_filter_fiemap -h" $testfile -F
# Delayed allocation multi punch hole tests
-_test_generic_punch -d -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F
+_test_generic_punch -d -k falloc fpunch fpunch fiemap "_filter_fiemap -h" $testfile -F
status=0 ; exit
diff --git a/common.punch b/common.punch
index ddf63b0..d3c89eb 100644
--- a/common.punch
+++ b/common.punch
@@ -203,17 +203,34 @@ _coalesce_extents()
_filter_fiemap()
{
+
+ UNWRITTEN_EX="\"unwritten\""
+ DATA_EX="\"data\""
+ OPTIND=1
+ while getopts 'h' OPTION
+ do
+ case $OPTION in
+ h) UNWRITTEN_EX="\"extent\""
+ DATA_EX="\"extent\""
+ ;;
+ ?) echo Invalid flag
+ exit 1
+ ;;
+ esac
+ done
+ shift $(($OPTIND - 1))
+
awk --posix '
$3 ~ /hole/ {
print $1, $2, $3;
next;
}
$5 ~ /0x[[:digit:]]*8[[:digit:]]{2}/ {
- print $1, $2, "unwritten";
+ print $1, $2, '$UNWRITTEN_EX';
next;
}
$5 ~ /0x[[:digit:]]+/ {
- print $1, $2, "data";
+ print $1, $2, '$DATA_EX';
}' |
_coalesce_extents
}
@@ -305,6 +322,7 @@ _test_generic_punch()
-c "$zero_cmd 4k 8k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
echo " 2. into allocated space"
if [ "$remove_testfile" ]; then
@@ -315,6 +333,7 @@ _test_generic_punch()
-c "$zero_cmd 4k 8k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
echo " 3. into unwritten space"
if [ "$remove_testfile" ]; then
@@ -325,6 +344,7 @@ _test_generic_punch()
-c "$zero_cmd 4k 8k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
echo " 4. hole -> data"
if [ "$remove_testfile" ]; then
@@ -335,6 +355,7 @@ _test_generic_punch()
-c "$zero_cmd 4k 8k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
echo " 5. hole -> unwritten"
if [ "$remove_testfile" ]; then
@@ -345,6 +366,7 @@ _test_generic_punch()
-c "$zero_cmd 4k 8k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
echo " 6. data -> hole"
if [ "$remove_testfile" ]; then
@@ -355,6 +377,7 @@ _test_generic_punch()
-c "$zero_cmd 4k 8k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
echo " 7. data -> unwritten"
if [ "$remove_testfile" ]; then
@@ -366,6 +389,7 @@ _test_generic_punch()
-c "$zero_cmd 4k 8k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
echo " 8. unwritten -> hole"
if [ "$remove_testfile" ]; then
@@ -376,6 +400,7 @@ _test_generic_punch()
-c "$zero_cmd 4k 8k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
echo " 9. unwritten -> data"
if [ "$remove_testfile" ]; then
@@ -387,6 +412,7 @@ _test_generic_punch()
-c "$zero_cmd 4k 8k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
echo " 10. hole -> data -> hole"
if [ "$remove_testfile" ]; then
@@ -397,6 +423,7 @@ _test_generic_punch()
-c "$zero_cmd 4k 12k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
echo " 11. data -> hole -> data"
if [ "$remove_testfile" ]; then
@@ -410,6 +437,7 @@ _test_generic_punch()
-c "$zero_cmd 4k 12k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
echo " 12. unwritten -> data -> unwritten"
if [ "$remove_testfile" ]; then
@@ -421,6 +449,7 @@ _test_generic_punch()
-c "$zero_cmd 4k 12k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
echo " 13. data -> unwritten -> data"
if [ "$remove_testfile" ]; then
@@ -433,6 +462,7 @@ _test_generic_punch()
-c "$zero_cmd 4k 12k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
echo " 14. data -> hole @ EOF"
rm -f $testfile
@@ -441,6 +471,7 @@ _test_generic_punch()
-c "$zero_cmd 12k 8k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
echo " 15. data -> hole @ 0"
if [ "$remove_testfile" ]; then
@@ -451,6 +482,7 @@ _test_generic_punch()
-c "$zero_cmd 0k 8k" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
echo " 16. data -> cache cold ->hole"
if [ "$remove_testfile" ]; then
@@ -470,6 +502,7 @@ _test_generic_punch()
diff $testfile $testfile.2
[ $? -ne 0 ] && die_now
rm -f $testfile.2
+ md5sum $testfile | cut -d ' ' -f1
echo " 17. data -> hole in single block file"
if [ "$remove_testfile" ]; then
@@ -481,5 +514,6 @@ _test_generic_punch()
-c "$zero_cmd 128 128" \
-c "$map_cmd -v" $testfile | $filter_cmd
[ $? -ne 0 ] && die_now
+ md5sum $testfile | cut -d ' ' -f1
}
--
1.7.1
New filtered golden output for test 252
Signed-off-by: Allison Henderson <[email protected]>
---
:100644 100644 930c924... fcfd121... M 252.out
252.out | 272 +++++++++++++++++++++++++++++++++++++++------------------------
1 files changed, 170 insertions(+), 102 deletions(-)
diff --git a/252.out b/252.out
index 930c924..fcfd121 100644
--- a/252.out
+++ b/252.out
@@ -1,239 +1,307 @@
QA output created by 252
1. into a hole
+daa100df6e6711906b61c9ab5aa16032
2. into allocated space
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
3. into unwritten space
-0: [0..7]: unwritten
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: unwritten
+2: [24..39]: extent
+daa100df6e6711906b61c9ab5aa16032
4. hole -> data
0: [0..23]: hole
-1: [24..31]: data
+1: [24..31]: extent
2: [32..39]: hole
+cc63069677939f69a6e8f68cae6a6dac
5. hole -> unwritten
0: [0..23]: hole
-1: [24..31]: unwritten
+1: [24..31]: extent
2: [32..39]: hole
+daa100df6e6711906b61c9ab5aa16032
6. data -> hole
-0: [0..7]: data
+0: [0..7]: extent
1: [8..39]: hole
+1b3779878366498b28c702ef88c4a773
7. data -> unwritten
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..31]: unwritten
+2: [24..31]: extent
3: [32..39]: hole
+1b3779878366498b28c702ef88c4a773
8. unwritten -> hole
-0: [0..7]: unwritten
+0: [0..7]: extent
1: [8..39]: hole
+daa100df6e6711906b61c9ab5aa16032
9. unwritten -> data
-0: [0..7]: unwritten
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..31]: data
+2: [24..31]: extent
3: [32..39]: hole
+cc63069677939f69a6e8f68cae6a6dac
10. hole -> data -> hole
+daa100df6e6711906b61c9ab5aa16032
11. data -> hole -> data
-0: [0..7]: data
+0: [0..7]: extent
1: [8..31]: hole
-2: [32..39]: data
+2: [32..39]: extent
+f6aeca13ec49e5b266cd1c913cd726e3
12. unwritten -> data -> unwritten
-0: [0..7]: unwritten
+0: [0..7]: extent
1: [8..31]: hole
-2: [32..39]: unwritten
+2: [32..39]: extent
+daa100df6e6711906b61c9ab5aa16032
13. data -> unwritten -> data
-0: [0..7]: data
+0: [0..7]: extent
1: [8..31]: hole
-2: [32..39]: data
+2: [32..39]: extent
+f6aeca13ec49e5b266cd1c913cd726e3
14. data -> hole @ EOF
-0: [0..23]: data
+0: [0..23]: extent
1: [24..39]: hole
+e1f024eedd27ea6b1c3e9b841c850404
15. data -> hole @ 0
0: [0..15]: hole
-1: [16..39]: data
+1: [16..39]: extent
+eecb7aa303d121835de05028751d301c
16. data -> cache cold ->hole
0: [0..15]: hole
-1: [16..39]: data
+1: [16..39]: extent
+eecb7aa303d121835de05028751d301c
17. data -> hole in single block file
-0: [0..7]: data
+0: [0..7]: extent
+13535fd4d496bf0b74bb2335aa4d1b31
1. into a hole
+daa100df6e6711906b61c9ab5aa16032
2. into allocated space
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
3. into unwritten space
-0: [0..7]: unwritten
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: unwritten
+2: [24..39]: extent
+daa100df6e6711906b61c9ab5aa16032
4. hole -> data
0: [0..23]: hole
-1: [24..31]: data
+1: [24..31]: extent
2: [32..39]: hole
+cc63069677939f69a6e8f68cae6a6dac
5. hole -> unwritten
0: [0..23]: hole
-1: [24..31]: unwritten
+1: [24..31]: extent
2: [32..39]: hole
+daa100df6e6711906b61c9ab5aa16032
6. data -> hole
-0: [0..7]: data
+0: [0..7]: extent
1: [8..39]: hole
+1b3779878366498b28c702ef88c4a773
7. data -> unwritten
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..31]: unwritten
+2: [24..31]: extent
3: [32..39]: hole
+1b3779878366498b28c702ef88c4a773
8. unwritten -> hole
-0: [0..7]: unwritten
+0: [0..7]: extent
1: [8..39]: hole
+daa100df6e6711906b61c9ab5aa16032
9. unwritten -> data
-0: [0..7]: unwritten
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..31]: data
+2: [24..31]: extent
3: [32..39]: hole
+cc63069677939f69a6e8f68cae6a6dac
10. hole -> data -> hole
+daa100df6e6711906b61c9ab5aa16032
11. data -> hole -> data
-0: [0..7]: data
+0: [0..7]: extent
1: [8..31]: hole
-2: [32..39]: data
+2: [32..39]: extent
+f6aeca13ec49e5b266cd1c913cd726e3
12. unwritten -> data -> unwritten
-0: [0..7]: unwritten
+0: [0..7]: extent
1: [8..31]: hole
-2: [32..39]: unwritten
+2: [32..39]: extent
+daa100df6e6711906b61c9ab5aa16032
13. data -> unwritten -> data
-0: [0..7]: data
+0: [0..7]: extent
1: [8..31]: hole
-2: [32..39]: data
+2: [32..39]: extent
+f6aeca13ec49e5b266cd1c913cd726e3
14. data -> hole @ EOF
-0: [0..23]: data
+0: [0..23]: extent
1: [24..39]: hole
+e1f024eedd27ea6b1c3e9b841c850404
15. data -> hole @ 0
0: [0..15]: hole
-1: [16..39]: data
+1: [16..39]: extent
+eecb7aa303d121835de05028751d301c
16. data -> cache cold ->hole
0: [0..15]: hole
-1: [16..39]: data
+1: [16..39]: extent
+eecb7aa303d121835de05028751d301c
17. data -> hole in single block file
-0: [0..7]: data
+0: [0..7]: extent
+13535fd4d496bf0b74bb2335aa4d1b31
1. into a hole
-0: [0..7]: data
+0: [0..7]: extent
1: [8..39]: hole
+5a58e46082be047d0f13bee7974015b9
2. into allocated space
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
3. into unwritten space
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
4. hole -> data
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
5. hole -> unwritten
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
6. data -> hole
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
7. data -> unwritten
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
8. unwritten -> hole
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
9. unwritten -> data
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
10. hole -> data -> hole
-0: [0..7]: data
+0: [0..7]: extent
1: [8..31]: hole
-2: [32..39]: data
+2: [32..39]: extent
+f6aeca13ec49e5b266cd1c913cd726e3
11. data -> hole -> data
-0: [0..7]: data
+0: [0..7]: extent
1: [8..31]: hole
-2: [32..39]: data
+2: [32..39]: extent
+f6aeca13ec49e5b266cd1c913cd726e3
12. unwritten -> data -> unwritten
-0: [0..7]: data
+0: [0..7]: extent
1: [8..31]: hole
-2: [32..39]: data
+2: [32..39]: extent
+f6aeca13ec49e5b266cd1c913cd726e3
13. data -> unwritten -> data
-0: [0..7]: data
+0: [0..7]: extent
1: [8..31]: hole
-2: [32..39]: data
+2: [32..39]: extent
+f6aeca13ec49e5b266cd1c913cd726e3
14. data -> hole @ EOF
-0: [0..23]: data
+0: [0..23]: extent
1: [24..39]: hole
+e1f024eedd27ea6b1c3e9b841c850404
15. data -> hole @ 0
0: [0..15]: hole
-1: [16..39]: data
+1: [16..39]: extent
+eecb7aa303d121835de05028751d301c
16. data -> cache cold ->hole
0: [0..15]: hole
-1: [16..39]: data
+1: [16..39]: extent
+eecb7aa303d121835de05028751d301c
17. data -> hole in single block file
-0: [0..7]: data
+0: [0..7]: extent
+13535fd4d496bf0b74bb2335aa4d1b31
1. into a hole
-0: [0..7]: data
+0: [0..7]: extent
1: [8..39]: hole
+5a58e46082be047d0f13bee7974015b9
2. into allocated space
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
3. into unwritten space
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
4. hole -> data
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
5. hole -> unwritten
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
6. data -> hole
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
7. data -> unwritten
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
8. unwritten -> hole
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
9. unwritten -> data
-0: [0..7]: data
+0: [0..7]: extent
1: [8..23]: hole
-2: [24..39]: data
+2: [24..39]: extent
+cc58a7417c2d7763adc45b6fcd3fa024
10. hole -> data -> hole
-0: [0..7]: data
+0: [0..7]: extent
1: [8..31]: hole
-2: [32..39]: data
+2: [32..39]: extent
+f6aeca13ec49e5b266cd1c913cd726e3
11. data -> hole -> data
-0: [0..7]: data
+0: [0..7]: extent
1: [8..31]: hole
-2: [32..39]: data
+2: [32..39]: extent
+f6aeca13ec49e5b266cd1c913cd726e3
12. unwritten -> data -> unwritten
-0: [0..7]: data
+0: [0..7]: extent
1: [8..31]: hole
-2: [32..39]: data
+2: [32..39]: extent
+f6aeca13ec49e5b266cd1c913cd726e3
13. data -> unwritten -> data
-0: [0..7]: data
+0: [0..7]: extent
1: [8..31]: hole
-2: [32..39]: data
+2: [32..39]: extent
+f6aeca13ec49e5b266cd1c913cd726e3
14. data -> hole @ EOF
-0: [0..23]: data
+0: [0..23]: extent
1: [24..39]: hole
+e1f024eedd27ea6b1c3e9b841c850404
15. data -> hole @ 0
0: [0..15]: hole
-1: [16..39]: data
+1: [16..39]: extent
+eecb7aa303d121835de05028751d301c
16. data -> cache cold ->hole
0: [0..15]: hole
-1: [16..39]: data
+1: [16..39]: extent
+eecb7aa303d121835de05028751d301c
17. data -> hole in single block file
-0: [0..7]: data
+0: [0..7]: extent
+13535fd4d496bf0b74bb2335aa4d1b31
--
1.7.1
New filtered golden output for test 242. Another patch
has been sumbitted that also modifies the 242 output, and
this set has been adjusted to apply on top of it.
This patch requires Christoph's
"[PATCH] xfstests: update test 042 golden output" (06/20/2011)
Signed-off-by: Allison Henderson <[email protected]>
---
:100644 100644 e69382c... 649ac04... M 242.out
242.out | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/242.out b/242.out
index e69382c..649ac04 100644
--- a/242.out
+++ b/242.out
@@ -3,58 +3,75 @@ QA output created by 242
0: [0..7]: hole
1: [8..23]: unwritten
2: [24..39]: hole
+daa100df6e6711906b61c9ab5aa16032
2. into allocated space
0: [0..7]: data
1: [8..23]: unwritten
2: [24..39]: data
+cc58a7417c2d7763adc45b6fcd3fa024
3. into unwritten space
0: [0..39]: unwritten
+daa100df6e6711906b61c9ab5aa16032
4. hole -> data
0: [0..7]: hole
1: [8..23]: unwritten
2: [24..31]: data
3: [32..39]: hole
+cc63069677939f69a6e8f68cae6a6dac
5. hole -> unwritten
0: [0..7]: hole
1: [8..31]: unwritten
2: [32..39]: hole
+daa100df6e6711906b61c9ab5aa16032
6. data -> hole
0: [0..7]: data
1: [8..23]: unwritten
2: [24..39]: hole
+1b3779878366498b28c702ef88c4a773
7. data -> unwritten
0: [0..7]: data
1: [8..31]: unwritten
2: [32..39]: hole
+1b3779878366498b28c702ef88c4a773
8. unwritten -> hole
0: [0..23]: unwritten
1: [24..39]: hole
+daa100df6e6711906b61c9ab5aa16032
9. unwritten -> data
0: [0..23]: unwritten
1: [24..31]: data
2: [32..39]: hole
+cc63069677939f69a6e8f68cae6a6dac
10. hole -> data -> hole
0: [0..7]: hole
1: [8..31]: unwritten
2: [32..39]: hole
+daa100df6e6711906b61c9ab5aa16032
11. data -> hole -> data
0: [0..7]: data
1: [8..31]: unwritten
2: [32..39]: data
+f6aeca13ec49e5b266cd1c913cd726e3
12. unwritten -> data -> unwritten
0: [0..39]: unwritten
+daa100df6e6711906b61c9ab5aa16032
13. data -> unwritten -> data
0: [0..7]: data
1: [8..31]: unwritten
2: [32..39]: data
+f6aeca13ec49e5b266cd1c913cd726e3
14. data -> hole @ EOF
0: [0..23]: data
1: [24..39]: unwritten
+e1f024eedd27ea6b1c3e9b841c850404
15. data -> hole @ 0
0: [0..15]: unwritten
1: [16..39]: data
+eecb7aa303d121835de05028751d301c
16. data -> cache cold ->hole
0: [0..15]: unwritten
1: [16..39]: data
+eecb7aa303d121835de05028751d301c
17. data -> hole in single block file
0: [0..7]: unwritten
+56819989ef2d9f40785adce8c06b64d0
--
1.7.1
On Mon, Jun 27, 2011 at 09:27:25PM -0700, Allison Henderson wrote:
> The current test 252 tests punch hole by collecting fiemap information
> on the test file. However this does not work for all file systems since
> not all file systems layout their extents in the same way.
>
> This patch corrects this by adding a -h flag to the fiemap filter that ignores
> the extent types in the fiemaps. The result is that the fiemap contains only
> "extent" or "hole", instead of "unwritten", "data" or "hole". A checksum has
> also been added to each test to help ensure the file contents are correct.
>
> Signed-off-by: Allison Henderson <[email protected]>
> ---
> v1 -> v2
> Moved new golden output for 252 into a seperate patch to help make the set
> easier to read
>
> :100755 100755 5efa243... 1289094... M 252
> :100644 100644 ddf63b0... d3c89eb... M common.punch
> 252 | 8 ++++----
> common.punch | 38 ++++++++++++++++++++++++++++++++++++--
> 2 files changed, 40 insertions(+), 6 deletions(-)
>
> diff --git a/252 b/252
> index 5efa243..1289094 100755
> --- a/252
> +++ b/252
> @@ -53,15 +53,15 @@ _require_xfs_io_fiemap
> testfile=$TEST_DIR/252.$$
>
> # Standard punch hole tests
> -_test_generic_punch falloc fpunch fpunch fiemap _filter_fiemap $testfile -F
> +_test_generic_punch falloc fpunch fpunch fiemap "_filter_fiemap -h" $testfile -F
>
> # Delayed allocation punch hole tests
> -_test_generic_punch -d falloc fpunch fpunch fiemap _filter_fiemap $testfile -F
> +_test_generic_punch -d falloc fpunch fpunch fiemap "_filter_fiemap -h" $testfile -F
>
> # Multi hole punch tests
> -_test_generic_punch -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F
> +_test_generic_punch -k falloc fpunch fpunch fiemap "_filter_fiemap -h" $testfile -F
>
> # Delayed allocation multi punch hole tests
> -_test_generic_punch -d -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F
> +_test_generic_punch -d -k falloc fpunch fpunch fiemap "_filter_fiemap -h" $testfile -F
>
> status=0 ; exit
> diff --git a/common.punch b/common.punch
> index ddf63b0..d3c89eb 100644
> --- a/common.punch
> +++ b/common.punch
> @@ -203,17 +203,34 @@ _coalesce_extents()
>
> _filter_fiemap()
> {
> +
> + UNWRITTEN_EX="\"unwritten\""
> + DATA_EX="\"data\""
> + OPTIND=1
> + while getopts 'h' OPTION
> + do
> + case $OPTION in
> + h) UNWRITTEN_EX="\"extent\""
> + DATA_EX="\"extent\""
> + ;;
> + ?) echo Invalid flag
> + exit 1
> + ;;
> + esac
> + done
> + shift $(($OPTIND - 1))
> +
> awk --posix '
> $3 ~ /hole/ {
> print $1, $2, $3;
> next;
> }
> $5 ~ /0x[[:digit:]]*8[[:digit:]]{2}/ {
> - print $1, $2, "unwritten";
> + print $1, $2, '$UNWRITTEN_EX';
> next;
> }
> $5 ~ /0x[[:digit:]]+/ {
> - print $1, $2, "data";
> + print $1, $2, '$DATA_EX';
> }' |
> _coalesce_extents
> }
I seriously dislike conditional parameter passing in shell scripts
at the best of times, but for filter functions I really think it is
the wrong thing to do. It significantly obfuscates the working of
the function for no really good reason.
Just write a new filter function, and factor out the common parts of
them if the amount of code duplication is sufficient to make it
desirable to do so.
> + md5sum $testfile | cut -d ' ' -f1
Why cut out the file name? It's not like it changes at all....
Cheers,
Dave.
--
Dave Chinner
[email protected]
On Mon, Jun 27, 2011 at 09:27:26PM -0700, Allison Henderson wrote:
> New filtered golden output for test 252
>
> Signed-off-by: Allison Henderson <[email protected]>
> ---
> :100644 100644 930c924... fcfd121... M 252.out
> 252.out | 272 +++++++++++++++++++++++++++++++++++++++------------------------
> 1 files changed, 170 insertions(+), 102 deletions(-)
>
> diff --git a/252.out b/252.out
> index 930c924..fcfd121 100644
> --- a/252.out
> +++ b/252.out
> @@ -1,239 +1,307 @@
> QA output created by 252
> 1. into a hole
> +daa100df6e6711906b61c9ab5aa16032
> 2. into allocated space
> -0: [0..7]: data
> +0: [0..7]: extent
> 1: [8..23]: hole
> -2: [24..39]: data
> +2: [24..39]: extent
> +cc58a7417c2d7763adc45b6fcd3fa024
I don't really like the way this weakens the test for XFS. With this
change, the test no longer is checking that unwritten extent
behaviour is correct.
Rather than weakening the test, perhaps it would be better to
execute 252 for XFS only (with the md5sums added), and then
duplicate it to a new test for all filesystems to run with the
weaker result checking that using the new filter function gives us.
With the amount of common code the two tests share, it should be
trivial to do this....
Cheers,
Dave.
--
Dave Chinner
[email protected]
On 06/27/2011 09:59 PM, Dave Chinner wrote:
> On Mon, Jun 27, 2011 at 09:27:25PM -0700, Allison Henderson wrote:
> I seriously dislike conditional parameter passing in shell scripts
> at the best of times, but for filter functions I really think it is
> the wrong thing to do. It significantly obfuscates the working of
> the function for no really good reason.
>
> Just write a new filter function, and factor out the common parts of
> them if the amount of code duplication is sufficient to make it
> desirable to do so.
>
Ok, it doesn't look like a lot of code, I can separate them into their
own functions.
>> + md5sum $testfile | cut -d ' ' -f1
>
> Why cut out the file name? It's not like it changes at all....
>
Oh, it looked like there's a pid attached to the file name, so I thought
I should remove that from the output
Allison Henderson
On 06/27/2011 10:09 PM, Dave Chinner wrote:
> On Mon, Jun 27, 2011 at 09:27:26PM -0700, Allison Henderson wrote:
>> New filtered golden output for test 252
>>
>> Signed-off-by: Allison Henderson<[email protected]>
>> ---
>> :100644 100644 930c924... fcfd121... M 252.out
>> 252.out | 272 +++++++++++++++++++++++++++++++++++++++------------------------
>> 1 files changed, 170 insertions(+), 102 deletions(-)
>>
>> diff --git a/252.out b/252.out
>> index 930c924..fcfd121 100644
>> --- a/252.out
>> +++ b/252.out
>> @@ -1,239 +1,307 @@
>> QA output created by 252
>> 1. into a hole
>> +daa100df6e6711906b61c9ab5aa16032
>> 2. into allocated space
>> -0: [0..7]: data
>> +0: [0..7]: extent
>> 1: [8..23]: hole
>> -2: [24..39]: data
>> +2: [24..39]: extent
>> +cc58a7417c2d7763adc45b6fcd3fa024
>
> I don't really like the way this weakens the test for XFS. With this
> change, the test no longer is checking that unwritten extent
> behaviour is correct.
>
> Rather than weakening the test, perhaps it would be better to
> execute 252 for XFS only (with the md5sums added), and then
> duplicate it to a new test for all filesystems to run with the
> weaker result checking that using the new filter function gives us.
> With the amount of common code the two tests share, it should be
> trivial to do this....
>
Alrighty, that sounds pretty straight forward, as long as every one is
in agreement. I think that would help retain the tests effectiveness.
Eric, Josef, what are your thoughts?
Allison Henderson
> Cheers,
>
> Dave.
On Mon, Jun 27, 2011 at 10:17:12PM -0700, Allison Henderson wrote:
> On 06/27/2011 09:59 PM, Dave Chinner wrote:
> >On Mon, Jun 27, 2011 at 09:27:25PM -0700, Allison Henderson wrote:
> >I seriously dislike conditional parameter passing in shell scripts
> >at the best of times, but for filter functions I really think it is
> >the wrong thing to do. It significantly obfuscates the working of
> >the function for no really good reason.
> >
> >Just write a new filter function, and factor out the common parts of
> >them if the amount of code duplication is sufficient to make it
> >desirable to do so.
> >
>
> Ok, it doesn't look like a lot of code, I can separate them into their
> own functions.
>
> >>+ md5sum $testfile | cut -d ' ' -f1
> >
> >Why cut out the file name? It's not like it changes at all....
> >
>
> Oh, it looked like there's a pid attached to the file name, so I
> thought I should remove that from the output
Oh, it does too. My mistake, too trigger happy, just looking for
ways to keep things relatively simple. Maybe using a wrapper
function so if we ever need to modify it we only need to change one
line of code would acheive the same thing?
Cheers,
Dave.
--
Dave Chinner
[email protected]
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
On 6/28/11 12:26 AM, Allison Henderson wrote:
> On 06/27/2011 10:09 PM, Dave Chinner wrote:
>> On Mon, Jun 27, 2011 at 09:27:26PM -0700, Allison Henderson wrote:
>>> New filtered golden output for test 252
>>>
>>> Signed-off-by: Allison Henderson<[email protected]>
>>> ---
>>> :100644 100644 930c924... fcfd121... M 252.out
>>> 252.out | 272 +++++++++++++++++++++++++++++++++++++++------------------------
>>> 1 files changed, 170 insertions(+), 102 deletions(-)
>>>
>>> diff --git a/252.out b/252.out
>>> index 930c924..fcfd121 100644
>>> --- a/252.out
>>> +++ b/252.out
>>> @@ -1,239 +1,307 @@
>>> QA output created by 252
>>> 1. into a hole
>>> +daa100df6e6711906b61c9ab5aa16032
>>> 2. into allocated space
>>> -0: [0..7]: data
>>> +0: [0..7]: extent
>>> 1: [8..23]: hole
>>> -2: [24..39]: data
>>> +2: [24..39]: extent
>>> +cc58a7417c2d7763adc45b6fcd3fa024
>>
>> I don't really like the way this weakens the test for XFS. With this
>> change, the test no longer is checking that unwritten extent
>> behaviour is correct.
>>
>> Rather than weakening the test, perhaps it would be better to
>> execute 252 for XFS only (with the md5sums added), and then
>> duplicate it to a new test for all filesystems to run with the
>> weaker result checking that using the new filter function gives us.
>> With the amount of common code the two tests share, it should be
>> trivial to do this....
>>
>
> Alrighty, that sounds pretty straight forward, as long as every one
> is in agreement. I think that would help retain the tests
> effectiveness. Eric, Josef, what are your thoughts?
Yeah, I agree, I share Dave's concerns and that sounds like a good
way to go.
Thanks,
-Eric
> Allison Henderson
>
>> Cheers,
>>
>> Dave.
>
On 06/28/2011 06:29 AM, Eric Sandeen wrote:
> On 6/28/11 12:26 AM, Allison Henderson wrote:
>> On 06/27/2011 10:09 PM, Dave Chinner wrote:
>>> On Mon, Jun 27, 2011 at 09:27:26PM -0700, Allison Henderson wrote:
>>>> New filtered golden output for test 252
>>>>
>>>> Signed-off-by: Allison Henderson<[email protected]>
>>>> ---
>>>> :100644 100644 930c924... fcfd121... M 252.out
>>>> 252.out | 272 +++++++++++++++++++++++++++++++++++++++------------------------
>>>> 1 files changed, 170 insertions(+), 102 deletions(-)
>>>>
>>>> diff --git a/252.out b/252.out
>>>> index 930c924..fcfd121 100644
>>>> --- a/252.out
>>>> +++ b/252.out
>>>> @@ -1,239 +1,307 @@
>>>> QA output created by 252
>>>> 1. into a hole
>>>> +daa100df6e6711906b61c9ab5aa16032
>>>> 2. into allocated space
>>>> -0: [0..7]: data
>>>> +0: [0..7]: extent
>>>> 1: [8..23]: hole
>>>> -2: [24..39]: data
>>>> +2: [24..39]: extent
>>>> +cc58a7417c2d7763adc45b6fcd3fa024
>>>
>>> I don't really like the way this weakens the test for XFS. With this
>>> change, the test no longer is checking that unwritten extent
>>> behaviour is correct.
>>>
>>> Rather than weakening the test, perhaps it would be better to
>>> execute 252 for XFS only (with the md5sums added), and then
>>> duplicate it to a new test for all filesystems to run with the
>>> weaker result checking that using the new filter function gives us.
>>> With the amount of common code the two tests share, it should be
>>> trivial to do this....
>>>
>>
>> Alrighty, that sounds pretty straight forward, as long as every one
>> is in agreement. I think that would help retain the tests
>> effectiveness. Eric, Josef, what are your thoughts?
>
> Yeah, I agree, I share Dave's concerns and that sounds like a good
> way to go.
>
> Thanks,
> -Eric
Ok I will get an update sent out with these adjustments, and also the
checksum wrapper that Dave mentioned in the 1/3 patch. Thanks all
for your reviews!
Allison Henderson
>
>> Allison Henderson
>>
>>> Cheers,
>>>
>>> Dave.
>>
>
> _______________________________________________
> xfs mailing list
> [email protected]
> http://oss.sgi.com/mailman/listinfo/xfs