From 138358a9388a8542be27e6d59a0e7b689e2d8618 Mon Sep 17 00:00:00 2001 From: zooko <> Date: Thu, 11 Apr 2013 05:42:56 +0000 Subject: [PATCH] Upload Strategy of Happiness [Imported from Trac: page GSoCIdeas, version 11] --- GSoCIdeas.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/GSoCIdeas.md b/GSoCIdeas.md index c66604f..9b4dda8 100644 --- a/GSoCIdeas.md +++ b/GSoCIdeas.md @@ -16,12 +16,16 @@ You might end up working on one of the projects below even after going through t | | | | |---|---|---| |*Project*|*Tickets*|*Difficulty*| -|[#ShareRebalancingandRepair Share rebalancing and repair]|#699,#232|tricky| +|[#ShareRebalancingandRepair Share rebalancing and repair]|#699, #232|tricky| +|[#UploadStrategyOfHappiness Upload Strategy Of Happiness]|##610, #1124, #1130, #1293, #1382, #1814|tricky| -... 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)). +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). In addition, mutable files do not spread out to new servers upon modification (#232). -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. \ No newline at end of file +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. + +## Upload Strategy Of Happiness + +The *Servers of Happiness* criterion is already in place for deciding whether a given distribution of shares over servers satisfies the user's requirements for fault-tolerant distribution. However, the algorithm that decides what shares to upload to which servers is not optimized to always satisfy the Servers of Happiness criterion. [Kevan Carstensen's master's thesis](https://zooko.com/uri/URI%3ADIR2-RO%3Aoljrwy5i2t3dhcx5mzrksegehe%3Axtac4ubcnr5eqo6d7h4wyj5sm522olj4mthizz2i3lfw2b5nla6q/Latest/compsci/Carstensen-2011-Robust_Resource_Allocation_In_Distributed_Filesystem.pdf) explains the context in great details and proposes an *Upload Strategy of Happiness* algorithm for allocating shares to servers. Implementing the *Upload Strategy of Happiness* should close the following tickets: #610, #1124, #1130, #1293, #1382, #1814. \ No newline at end of file