Changes between Version 1 and Version 2 of GSoCIdeas/Notes

Timestamp:

2010-03-16T02:49:59Z (15 years ago)

Author:

kevan

Comment:

--

GSoCIdeas/Notes

@@ -37 +37 @@
 == 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.
+ === 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. [http://allmydata.org/trac/tahoe-lafs/browser/docs/architecture.txt architecture.txt],
+[http://allmydata.org/trac/tahoe-lafs/browser/docs/specifications/file-encoding.txt file-encoding.txt],
+[http://allmydata.org/trac/tahoe-lafs/browser/docs/specifications/mutable.txt mutable.txt],
+[http://allmydata.org/trac/tahoe-lafs/browser/src/allmydata/immutable/upload.py the immutable file upload code], and
+[http://allmydata.org/trac/tahoe-lafs/browser/src/allmydata/mutable/publish.py the mutable file upload code] are good
+places to do that.  Also, you might want to look at the
+[http://allmydata.org/trac/tahoe-lafs/browser/src/allmydata/storage/server.py storage server code] 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. [http://allmydata.org/trac/tahoe-lafs/query?status=!closed&order=priority&keywords=~availability Tickets labelled 'availability']