-------- Original Message --------
Subject: Re: [PATCH 1/2] btrfs-progs: Add support for btrfs-image +
corrupt script fsck test case.
From: Filipe David Manana <fdman...@gmail.com>
To: Qu Wenruo <quwen...@cn.fujitsu.com>
Date: 2014年12月15日 17:43
On Mon, Dec 15, 2014 at 9:40 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote:
-------- Original Message --------
Subject: Re: [PATCH 1/2] btrfs-progs: Add support for btrfs-image + corrupt
script fsck test case.
From: Filipe David Manana <fdman...@gmail.com>
To: Qu Wenruo <quwen...@cn.fujitsu.com>
Date: 2014年12月15日 17:00
On Mon, Dec 15, 2014 at 3:54 AM, Qu Wenruo <quwen...@cn.fujitsu.com>
wrote:
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
+}
I'm confused with this function, why it's needed and the respective
comment.
So I can interpret it as either:
1) The several loops means fsck --repair does multiple passages
internally to fix some issues?
If this is the case, we (user or script) only need to call fsck
--repair once, which should exit with status 0 if it was able to fix
all the issues, right? If so, then we should check that fsck --repair
exits with status 0, removing the need for this new function.
Sorry for the poor explain.
The problem is, there is some check cases before we doing repair and these
check result is bad so
btrfsck thinks there is err even it will be repaired later.
So The result is, especially on corrupted-leaf case, btrfsck --repair will
fix all the problems but
still return 1, and the next btrfsck without --repair will return 0.
That seems wrong to me. If --repair was able to fix all problems it
should exit with status 0.
If a script is running fsck --repair it would incorrectly assume
--repair failed.
That's right, I'll look into it and try to fix the return value things
before I send the v2 test case.
Thanks,
Qu
--
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
