tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

remove share migration -- it lives on wiki:GSoCIdeas now 

[Imported from Trac: page GSoCIdeas/Notes, version 11]
zooko 2010-03-17 04:04:39 +00:00
parent fd18eb5567
commit 6f8b184909
1 changed files with 0 additions and 37 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

37
GSoCIdeas/Notes.md

@ -16,44 +16,7 @@ Here are notes that should be added to wikiGSoCIdeas in a format emulating [this
## Server Selection
*Which servers are connected to your client, and which of them have which shares of your files?*
=== Dynamically migrate shares to maintain file health. ===
Difficulty: medium - hard
When uploading a file to a grid, Tahoe-LAFS will make sure that the file is
healthy (a good discussion of what healthy means is found in #778) before
reporting that the file is uploaded successfully. Tools to effectively
maintain file health (or to adapt to new definitions of health) aren't
quite complete, however -- our users have had several use cases that aren't
easily addressed with what we have. Students taking this project would be
building tools to address those use cases.
A good starting point would be to become familiar with how files are placed on
a grid. [architecture.txt](http://allmydata.org/trac/tahoe-lafs/browser/docs/architecture.txt),
[file-encoding.txt](http://allmydata.org/trac/tahoe-lafs/browser/docs/specifications/file-encoding.txt),
[mutable.txt](http://allmydata.org/trac/tahoe-lafs/browser/docs/specifications/mutable.txt),
[the immutable file upload code](http://allmydata.org/trac/tahoe-lafs/browser/src/allmydata/immutable/upload.py), and
[the mutable file upload code](http://allmydata.org/trac/tahoe-lafs/browser/src/allmydata/mutable/publish.py) are good
places to do that. Also, you might want to look at the
[storage server code](http://allmydata.org/trac/tahoe-lafs/browser/src/allmydata/storage/server.py) to understand that
better. Some good tickets to start looking at are #699, #543, and #232; you'll
find that those link to other tickets.
There are many ways to help address these issues. Some ideas:
* Alter the CLI and the WUI to give users the ability to rebalance
files that they've uploaded already. (#699)
* Build tools that allow node administrators to moves shares around
a grid (#543, #864)
* Alter Tahoe-LAFS to rebalance mutable files when uploading a new version
of them. (#232)
(it is doubtful that any one of these projects is enough to fill a summer, but, combined, they would be a big usability improvement for Tahoe-LAFS)
Depending on how you address this, this is tightly integrated with ideas of
file health and accounting, so prospective students would do well to explore
those open issues, too. A good accounting jumping-off point is #666. A good
jumping-off point for health is #778.
* Use Zeroconf or similar so nodes can find each other on a local network to enable quick local share migration.
* Deal with unreliable nodes and connections in general, getting away from allmydata.com's assumption that the grid is a big collection of reliable machines in a colo under a single administrative jurisdiction. [Tickets labelled 'availability'](http://allmydata.org/trac/tahoe-lafs/query?status=!closed&order=priority&keywords=~availability)
* Abstract out the server selection part of Tahoe-LAFS so that the projects in this category of "grid membership and server selection" can be mostly independent of the rest of Tahoe-LAFS. See also [this note about standardization of LAFS](http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html#2009-02-06).