[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):

 Hooray! Thank you for volunteering, Kevan!

 Uploading an immutable file is a safe thing to do -- each share that you
 upload will either end up being properly served by a server or it won't.
 Success means enough shares are hosted by enough servers. If the upload
 fails, no harm was done. Publishing a new version of a mutable file is
 less safe, because each share that gets accepted by a server overwrites
 any share of the same file and the same sharenumber that was previously
 held by that server. Once you've started overwriting older shares then you
 really ought to finish -- you can't undo, and if you don't finish writing
 all of your shares then your new version will be unhealthy.

 So this ticket is easier than you thought. First of all, you can ignore
 mutable files entirely, and second, the only change to be made to the
 share placement algorithm for publish.py is "when to give up and report
 failure".

 Here is a recent motivating example, in case you missed it:

 http://allmydata.org/pipermail/tahoe-dev/2009-August/002494.html # Why no
 error message when I have only one storage node?

 So the basic test is, with 3-of-10 encoding but only 1 storage server,
 upload the file, and then give up and return an error message to the user
 because 1 < servers_of_happiness. (By the way, a sane default value for
 "servers of happiness" might be ceil(k + m / 2).)

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