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

tahoe-lafs trac at allmydata.org
Sat Nov 7 02:21:25 UTC 2009

#778: "shares of happiness" is the wrong measure; "servers of happiness" is
 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):

 I'm attaching an updated behavior.txt with my solution from comment:55. It
 passes most of the new tests, with the exception of the one for the worst
 case in comment:71. This fails because of
 [source:src/allmydata/immutable/upload.py at 4045#L195 a check in
 Tahoe2PeerSelector] that filters the list of peers given to the selector
 instance to only those peers capable of accepting a share of this file,
 based on the largest sharesize they can accept, according to the results
 of [source:src/allmydata/storage/server.py at 3871#L232 remote_get_version()]
 in the storage server. If peers are full, they will be weeded out by this
 check, and their existing shares will not be accounted for in the peer
 selection process. However, removing the check entirely isn't a good
 option, either; according to the comment, the check is necessary to ensure
 that #439 is handled.

 Ideas? It'd be nice to handle this case, though it is kind of an edge
 case, so maybe it's okay to not handle it? That feels kind of dirty,
 though. Is there another criterion that we could use to address #439?
 Maybe we could modify Tahoe2PeerSelector to view these peers as "read-
 only" peers; that is, it will ask them if they have any existing shares,
 but not attempt to allocate any shares to them?

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

More information about the tahoe-dev mailing list