[Imported from Trac: page GSoCIdeas, version 6]

elb 2013-04-10 19:06:35 +00:00
parent 8d6bfa67ed
commit 7d6c8004c1

@ -16,5 +16,12 @@ You might end up working on one of the projects below even after going through t
| | |
|---|---|
|*Project*|*Difficulty*|
|Share rebalancing and repair|???|
... to be filled in...
## Share Rebalancing and Repair
Tahoe-LAFS is not as robust with regards to lost or corrupted shares as it could be. In part, this is because the repair functionality is limited in its efforts to spread shares out among new servers or servers which did not previously hold a given share (#699, #1130). In addition, mutable files do not spread out to new servers upon modification (#232). The servers-of-happiness metric is also not uniformly applied, with some operations succeeding even though an entity is not happy ([bugs](https://tahoe-lafs.org/trac/tahoe-lafs/query?status=!closed&keywords=~servers-of-happiness&order=priority)).
A Summer of Code project might tackle repair and rebalancing, ensuring that servers-of-happiness is met whenever possible on any upload, repair, or mutable modification. The notes on [ServerSelection](ServerSelection) and related configurations may also be relevant here.