short-circuit checker/verifier behavior #1044

Open
opened 2010-05-16 20:54:56 +00:00 by zooko · 0 comments
zooko commented 2010-05-16 20:54:56 +00:00
Owner

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".

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".
tahoe-lafs added the
code-encoding
major
defect
1.6.1
labels 2010-05-16 20:54:56 +00:00
tahoe-lafs added this to the undecided milestone 2010-05-16 20:54:56 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#1044
No description provided.