Re: [PATCH 1/2] btrfs-progs: Add support for btrfs-image + corrupt script fsck test case.

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

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 <quwenruo@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 <quwenruo@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
>