[tahoe-dev] [tahoe-lafs] #778: "shares of happiness" is the wrong measure; "servers of happiness" is better

[Jody Harris]

"Fail gracefully."
----
- Think carefully.
- Contra mundum - "Against the world" (St. Athanasius)
- Credo ut intelliga - "I believe that I may know" (St. Augustin of Hippo)


On Mon, Jan 18, 2010 at 10:08 PM, tahoe-lafs <trac at allmydata.org> wrote:

> #778: "shares of happiness" is the wrong measure; "servers of happiness" is
> better
>
> ---------------------------------------+------------------------------------
>  Reporter:  zooko                      |           Owner:  warner
>     Type:  defect                     |          Status:  new
>  Priority:  critical                   |       Milestone:  1.6.0
> Component:  code-peerselection         |         Version:  1.4.1
>  Keywords:  reliability review-needed  |   Launchpad_bug:
>
> ---------------------------------------+------------------------------------
>
> Comment(by zooko):
>
>  I realized as I was driving home just now that I don't know what the code
>  will do, after Kevan's behavior.txt patch is applied, when "servers of
>  happiness" can be achieved only by uploading redundant shares.  For
>  example, tests.txt adds a test in "test_upload.py" named
>  {{{test_problem_layout_comment_52}}} which creates a server layout like
>  this:
>
>  {{{
>         # server 0: shares 1 - 9
>         # server 1: share 0
>         # server 2: share 0
>         # server 3: share 0
>  }}}
>
>  Where server 0 is read-write and servers 1, 2 and 3 are read-only. (And by
>  the way Kevin, please make comments state that servers 1, 2 and 3 are
>  read-only.)
>
>  In this scenario (with {{{K == 3}}}) the uploader can't achieve "servers
>  of happiness" == 4 even though it can immediately see that all {{{M ==
>  10}}} of the shares are hosted on the grid.
>
>  But what about the case that servers 1, 2 and 3 were still able to accept
>  new shares?  Then our uploader could either abort and say "servers of
>  happiness couldn't be satisfied", due to the fact that it can't achieve
>  "servers of happiness" without uploading redundant copies of shares that
>  are already on the grid, or it could succeed by uploading a new copy of
>  shares 2 and 3.
>
>  We should have a test for this case.  If our uploader gives up in this
>  case then we should assert that the uploader gives up with a reasonable
>  error message and without wasting bandwidth by uploading shares.  If it
>  proceeds in this case then we should assert that it succeeds and that it
>  doesn't upload more shares than it has to (which is two in this case).
>
> --
> Ticket URL: <http://allmydata.org/trac/tahoe/ticket/778#comment:137>
> tahoe-lafs <http://allmydata.org>
> secure decentralized file storage grid
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at allmydata.org
> http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://allmydata.org/pipermail/tahoe-dev/attachments/20100119/19752d90/attachment.htm