[tahoe-lafs-trac-stream] [tahoe-lafs] #614: redefine "Healthy" to be "Happy" for checker/verifier/repairer

[tahoe-lafs]

#614: redefine "Healthy" to be "Happy" for checker/verifier/repairer
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:  markberger
         Type:  defect   |     Status:  new
     Priority:  major    |  Milestone:  1.11.0
    Component:  code-    |    Version:  1.3.0
  encoding               |   Keywords:  upload repair verify preservation
   Resolution:           |  performance docs unfinished-business servers-
Launchpad Bug:           |  of-happiness
-------------------------+-------------------------------------------------
Changes (by markberger):

 * owner:  kevan => markberger


Old description:

> Part of dreid's performance problem (in addition to the major part: #610,
> and the other consideration: #613) is that his client is uploading every
> file he has ever uploaded when the checker reports that the file is not
> "Healthy", with only 9 shares of the M=10 (K=3).  Maybe we should
> redefine "Healthy" to be 7 shares and let numbers of shares greater than
> 7 be "super extra Healthy".
>
> I choose 7 because that is the current default value of "shares of
> happiness".  "shares of happiness" is a related notion: when you are
> doing an upload, if some of the attempts to upload shares fail, and you
> are left with 7 or more shares at the end, then you report to the user
> that the upload succeeded.  If enough uploads fail so that you can't get
> more than 6 shares uploaded, then you immediately abort and report to the
> user that the upload failed.  Maybe repairer ought to use the same
> heuristic as uploader does with regard to how many shares is enough to
> "call it good".

New description:

 Part of dreid's performance problem (in addition to the major part: #610,
 and the other consideration: #613) is that his client is uploading every
 file he has ever uploaded when the checker reports that the file is not
 "Healthy", with only 9 shares of the M=10 (K=3).  Maybe we should redefine
 "Healthy" to be 7 shares and let numbers of shares greater than 7 be
 "super extra Healthy".

 I choose 7 because that is the current default value of "shares of
 happiness".  "shares of happiness" is a related notion: when you are doing
 an upload, if some of the attempts to upload shares fail, and you are left
 with 7 or more shares at the end, then you report to the user that the
 upload succeeded.  If enough uploads fail so that you can't get more than
 6 shares uploaded, then you immediately abort and report to the user that
 the upload failed.  Maybe repairer ought to use the same heuristic as
 uploader does with regard to how many shares is enough to "call it good".

--

Comment:

 I have started working on this ticket. You can view my progress here:
 https://github.com/markberger/tahoe-lafs/tree/614-happy-is-healthy

 As of right now I've only written a couple unit tests that should pass
 before this ticket is closed. If someone could glance over them to make
 sure they're implemented correctly, I would really appreciate it. The
 solution to this problem will probably be a little hacky because h is not
 stored in the verify cap while k and n are. Whoever is working on the new
 cap design might want to consider storing h in the verify cap if servers-
 of-happiness is going to be used with the new caps.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/614#comment:19>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage