At 01/12/2017 10:37 PM, [email protected] wrote:
Hi Qu,
Thanks for the details, I'll create image using these steps. Never used
btrfs-image before will try it out. in the mean time: I was thinking
about these two approaches:
--
I agree on the dependency issue with btrfs-debug-tree. Test script will
break if output is changed or jumbled.
If btrfs-debug-tree is the only issue, possible solution can be :
(a) when btrfs-debug-tree breaks the scripts add a backward captiable
option (--print-old-format) for outputs. (or)
(b) Use 'ls -i' to find the inode object id? I guess that will be more
reliable than parsing btrfs-debug-tree output. (or)
(c) may be use hard-corded id, if i'm not wrong, first object id will be
always 256+1 = 257
I slightly prefer script over image because:
* It might be more easier to have script to add new functionality (ex:
corrupt nlink field from hardlink)
Right, but btrfs-corrupt-block is no longer default installed and its
options are badly arranged, with little documentation.
Quite a lot of its code is old and its output is quite hard to catch.
In short, it's just in bad shape.
* It allows option to inject corruption sequentitally.
ex: clean image->injection corrupt-x -> run btrfsck -> fixed image ->
inject corruption 'variant of' x -> repeat the process.
* It might also be more easier to deal with possible RAID-based
corruption test scripts.
Yes, RAID test indeed needs btrfs-corrupt-block support, just as fstests
guys pointed out, but we really need to refact it before introducing new
features.
Before we have a really good btrfs-corrupt-block, current image method
seems to be best yet.
If btrfs-corrupt-block has the following feature, then I'm OK to convert
to script based tests:
1) Able to corrupt things CoW or noCoW
Only part of corruptions are noCow now.
NoCow corruption is especially important for shared node/leaf case.
2) Ability to corrupt node/leaf header (Already supported)
3) Ability to corrupt data structure pinpointly
This means, we should be able to corrupt given fields of specified
data structures, at least covers the current fsck test cases.
I see patches enhancing them, but 5) still makes them quite hard to
use.
4) Better error handling and output.
5) Documentation
No document for current btrfs-currupt-block, and this makes the
options of it quite chaos and hard to use.
(So normally I just hard code it to create test images)
But current one is far from those objectives, which makes it unpredictable.
And that's why we are still using binary images, because it's reliable
and makes error always reproducible.
--
To my (QA) eyes, creating new image from 'mkfs.btrfs' for a each
btrfs-progs version, injecting corruption (using ls -i output) and then
verifying looks better. This way we can even catch any (rare) changes
made to mkfs.btrfs. Script makes btrfsck heavily dependent on
'mkfs.btrfs' which is a good thing,imo.
IIRC current fsck-tests acts more or less like regression or corner-case
tests.
And in this case, btrfsck dependent on mkfs.btrfs(or
btrfs-corrupt-block) behavior makes us hard to trigger corner-case or
regression which only happens on certain cases.
Thanks,
Qu
Let me know your thoughts. thanks!
Cheers.
Lakshmipathi.G
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
