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)
* 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.
--
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.
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
