[tahoe-dev] [tahoe-lafs] #778: "shares of happiness" is the wrong measure; "servers of happiness" is better

[tahoe-lafs]

#778: "shares of happiness" is the wrong measure; "servers of happiness" is
better
--------------------------------+-------------------------------------------
 Reporter:  zooko               |           Owner:           
     Type:  defect              |          Status:  new      
 Priority:  critical            |       Milestone:  undecided
Component:  code-peerselection  |         Version:  1.4.1    
 Keywords:  reliability         |   Launchpad_bug:           
--------------------------------+-------------------------------------------

Comment(by zooko):

 Kevan:

 I think Shawn and you and I (at least) agree on the desired result --
 "{{{k}}}-out-of-{{{m}}}" servers is the desired goal of upload and at
 least "{{{k}}}-out-of-{{{h}}}" servers is the least reliable upload that
 still counts as a success.

 I think I like your and Shawn's proposed algorithm for how to  choose
 {{{k_e}}} and {{{m_e}}} and to map shares onto servers.  However, it
 should be a separate ticket from this one.  The reason is that there is (I
 think) a very easy way to implement this ticket without implementing that
 improved algorithm.  That is: let {{{k_e = k}}}, {{{m_e = m}}} (the same
 as it is now), then run the current algorithm for mapping-shares-to-
 servers, then check if the result satisfies the new criteria for success.

 This will be much easier to implement because the algorithm for mapping
 shares to servers can be a complex.  If I recall correctly, it currently
 adaptively deals with servers which fail to respond to the initial "Will
 you hold these shares?" requests, and with servers that respond with "Yes,
 but actually I already have shares number 1 and 4.", and with servers that
 respond with "Yes, I'll hold that one, Yes, I'll hold that one, No, I'm
 full go away.". (I could be wrong about some of those details.)

 So if this ticket is just about changing the criteria of upload success
 and not changing the share-to-server-mapping algorithm then you can finish
 this ticket sooner and we can have greater confidence that it didn't cause
 regressions.  Note that in the "normal" cases that I can think of, the
 current share-to-server-mapping algorithm will meet the new criteria,
 except of course in the case of fewer than {{{h}}} servers which can
 accept shares.

 By the way, I'd like to have Brian Warner review this ticket once we've
 finalized the design.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/778#comment:31>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid