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

Comment(by kevan):

 So I was playing with this yesterday and thought of a potential fix:

 Instead of throwing away the peers that aren't able to accept a share of a
 potential upload, the Tahoe2PeerSelector should keep them (temporarily)
 around in a list of read-only peers; peers which may already have shares
 of a particular file, but which won't accept any new shares. We can then
 ask these peers (using
 [source:src/allmydata/storage/server.py?rev=3871#L413
 remote_get_buckets()]) which buckets (if any) they have for our storage
 index, using the results to populate {{{self.preexisting_shares}}}. The
 peer selection process then runs as it normally does, knowing about the
 shares on the peers that it would have thrown away before. I'm attaching
 updated behavior.txt and tests.txt with these fixes.

 Does this seem reasonable? Does anyone have other suggestions?

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