"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 <[email protected]> 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 > [email protected] > http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev >
_______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
