[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:  zooko   
     Type:  defect              |          Status:  assigned
 Priority:  critical            |       Milestone:  1.6.0   
Component:  code-peerselection  |         Version:  1.4.1   
 Keywords:  reliability review  |   Launchpad_bug:          
--------------------------------+-------------------------------------------

Comment(by kevan):

 Replying to [comment:89 davidsarah]:
 > From docs.txt:
 > > shares.happy = (int, optional) 1 <= happy <= # of servers on your grid
 > [...]
 > > shares.happy allows you control over the distribution of your file. An
 upload is only considered successful if shares are placed on at least
 'shares.happy' distinct servers, the correct functioning of at least k of
 which is sufficient to guarantee the availability of the uploaded file.
 This value should not be larger than the number of servers on your grid.
 >
 > I don't think it makes sense to allow shares.happy to be less than k,
 since (if I understand correctly) that is equivalent to letting all
 uploads succeed even if they place '''no''' shares.

 I agree. I'm changing that. I'm also changing the upper bound to "N"; the
 peer selector doesn't know how to place more than N shares, so anything
 greater than that would not be satisfiable, either.

 We should probably make the client do a bounds check on that value before
 using it, in case it is set to something that we don't support (especially
 if there were different acceptable defaults before). Is there a preferred
 way to do that?

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