It seems the second patch, which about 225K including a btrfs-image
dump, can't pass the ml's size limit.
To David:
I created the pull request to your github repo:
https://github.com/kdave/btrfs-progs/pull/3
Thanks,
Qu
-------- Original Message --------
Subject: [PATCH 1/2] btrfs-progs: Add support for btrfs-image + corrupt
script fsck test case.
From: Qu Wenruo <quwen...@cn.fujitsu.com>
To: <linux-btrfs@vger.kernel.org>
Date: 2014年12月15日 11:54
Although btrfsck test case support pure image dump(tar.xz), it is still
too large for some images, e.g, a small 64M image with about 3 levels
(level 0~2) metadata will produce about 2.6M after xz zip, which is too
large for a single binary commit.
However btrfs-image -c9 will works much finer, the above image with
btrfs-image dump will only be less than 200K, which is quite reasonable.
Signed-off-by: Qu Wenruo <quwen...@cn.fujitsu.com>
---
tests/fsck-tests.sh | 34 ++++++++++++++++++++++++++++++++--
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/tests/fsck-tests.sh b/tests/fsck-tests.sh
index 8987d04..007e5b0 100644
--- a/tests/fsck-tests.sh
+++ b/tests/fsck-tests.sh
@@ -22,16 +22,38 @@ run_check()
"$@" >> $RESULT 2>&1 || _fail "failed: $@"
}
+# For complicated fsck repair case,
+# where even repairing is OK, it may still report problem before or after
+# reparing since the repair needs several loops to repair all the problems
+# but report checks it before all repair loops done
+run_check_no_fail()
+{
+ echo "############### $@" >> $RESULT 2>&1
+ "$@" >> $RESULT 2>&1
+}
+
rm -f $RESULT
# test rely on corrupting blocks tool
run_check make btrfs-corrupt-block
+# Supported test image formats:
+# 1) btrfs-image dump(.img files)
# Some broken filesystem images are kept as .img files, created by the tool
-# btrfs-image, and others are kept as .tar.xz files that contain raw filesystem
+# btrfs-image
+#
+# 2) binary image dump only(only test.img in .tar.xz)
+# Some are kept as .tar.xz files that contain raw filesystem
# image (the backing file of a loop device, as a sparse file). The reason for
# keeping some as tarballs of raw images is that for these cases btrfs-image
# isn't able to preserve all the (bad) filesystem structure for some reason.
+# This provides great flexibility at the cost of large file size.
+#
+# 3) script generated dump(generate_image.sh + needed things in .tar.gz)
+# The image is generated by the generate_image.sh script alone the needed
+# files in the tarball, normally a quite small btrfs-image dump.
+# This one combines the advatange of relative small btrfs-image and the
+# flexibility to support corrupted image.
for i in $(find $here/tests/fsck-tests -name '*.img' -o -name '*.tar.xz' |
sort)
do
echo " [TEST] $(basename $i)"
@@ -39,16 +61,24 @@ do
extension=${i#*.}
+ if [ -f generate_image.sh ]; then
+ rm generate_image.sh
+ fi
+
if [ $extension == "img" ]; then
run_check $here/btrfs-image -r $i test.img
else
run_check tar xJf $i
fi
+ if [ -x generate_image.sh ]; then
+ ./generate_image.sh
+ fi
+
$here/btrfsck test.img >> $RESULT 2>&1
[ $? -eq 0 ] && _fail "btrfsck should have detected corruption"
- run_check $here/btrfsck --repair test.img
+ run_check_no_fail $here/btrfsck --repair test.img
run_check $here/btrfsck test.img
done
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
