[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:  kevan
         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
-------------------------+-------------------------------------------------

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 (by zooko):

 There was discussion of this issue on tahoe-dev: [//pipermail/tahoe-
 dev/2013-March/008091.html]

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