short-circuit checker/verifier behavior #1044

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

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

No due date set.

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