[tahoe-lafs-trac-stream] [tahoe-lafs] #1382: immutable peer selection refactoring and enhancements
tahoe-lafs
trac at tahoe-lafs.org
Sat Nov 16 04:45:01 UTC 2013
#1382: immutable peer selection refactoring and enhancements
-------------------------+-------------------------------------------------
Reporter: kevan | Owner: markberger
Type: | Status: new
enhancement | Milestone: 1.11.0
Priority: major | Version: 1.8.2
Component: code- | Keywords: review-needed servers-of-happiness
peerselection | blocks-release
Resolution: |
Launchpad Bug: |
-------------------------+-------------------------------------------------
Comment (by zooko):
Here is another review of [https://github.com/markberger/tahoe-
lafs/blob/fa6f3cfb1e258e4427f35a7aada05c7ad2c9dd13/src/allmydata/immutable/upload.py
upload.py from the current tip of 1382-rewrite-2]. I'm looking at
[https://github.com/markberger/tahoe-
lafs/blob/fa6f3cfb1e258e4427f35a7aada05c7ad2c9dd13/src/allmydata/immutable/upload.py#L466
_get_next_allocation() on line 466], and it seems like it is doing some
complicated computations in order to yield just a simple data structure —
the ordered list of [(server, set(shnums))] that constitute the upload
plan. It seems like the "calculate upload plan" (a.k.a.
{{{_calculate_tasks()}}} method could just generate that list and return
it and {{{_get_next_allocation()}}} could disappear. Am I missing
anything?
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1382#comment:58>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list