On 17.07.2018 11:24, Qu Wenruo wrote:
> And it's causing problem for certain test cases.
> Please ignore this (at least for now).
>
> But on the other hand, we indeed have a lot of reports on corrupted
> extent tree, it's possible to hit some corrupted extent tree (Su is
> already exhausted by the corrupted tree reported by Marc)
>
> So I'm not completely fine with current extent tree error handling.
> I'll try to find some balance in next version.
I agree we need a better OVERALL error handling/detection. Your
tree-checker work IMO is a step in the right direction. What I want is
to prevent ad-hoc checks being sprinkled in the code. Sorry, but that's
not fine. The thing with working on a lot of corruption reports is the
fact each one of them is looked at in isolation so it produces isolated
fixes. Whereas if a step back is taken and the overall error
handling/detection is considered it might turn out a whole class of
corruption could be detected by a single change, otherwise checks upon
checks will be added which just add technical debt.
Considering this, I'm more in favor of extending the tree-checker to be
the central place where errors are detected (of course this is easier
said than 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
