[tahoe-dev] [tahoe-lafs] #778: "shares of happiness" is the wrong measure; "servers of happiness" is better
tahoe-lafs
trac at allmydata.org
Fri Nov 6 18:21:25 PST 2009
#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):
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