Opened at 2010-05-16T20:54:56Z
#1044 new defect
short-circuit checker/verifier behavior
| Reported by: | zooko | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | undecided |
| Component: | code-encoding | Version: | 1.6.1 |
| Keywords: | performance immutable verify repair | Cc: | kevan |
| Launchpad Bug: |
Description
It appears that there are some cases where the checker or verifier have already determined that a file is unhealthy, but they proceed to do a thorough analysis of that file, which could be expensive. Imagine for example that you are doing a full verifier run (which downloads and checks the correctness of each share in its entirety), and you immediately discover that the first share that you try to download is broken. If the only thing you need to do is report healthy-or-unhealthy to your caller then you could stop there, report "unhealthy" and save yourself a lot of work.
If we implement #614 (redefine "Healthy" to be "Happy" for checker/verifier/repairer) then you would have to do more work to figure out whether there is any chance that the final result would qualify as satisfying "servers of happiness", but you still wouldn't have to do all the work of verifying every share, in some cases, when you can already deduce that the answer is going to be "not happy".
