[tahoe-lafs-trac-stream] [tahoe-lafs] #1082: default servers-of-happiness=7 prevents single-server use case from working "out of the box"

[tahoe-lafs]

#1082: default servers-of-happiness=7 prevents single-server use case from working
"out of the box"
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:  somebody
         Type:  defect   |     Status:  new
     Priority:  major    |  Milestone:  soon
    Component:           |    Version:  1.7β
  documentation          |   Keywords:  docs unfinished-business servers-
   Resolution:           |  of-happiness upload zookos-opinion-needed
Launchpad Bug:           |  warners-opinion-needed
-------------------------+-------------------------------------------------

Old description:

> {{{
> <warner> one unfortunate result of the "happiness" patch is that a very
> common
>          first-time-user case (a single user setting up a small test
> grid)
>          fails unless you also modify your tahoe.cfg to lower the
>          shares_of_happiness threshold
> }}}

New description:

 {{{
 <warner> one unfortunate result of the "happiness" patch is that a very
 common
          first-time-user case (a single user setting up a small test grid)
          fails unless you also modify your tahoe.cfg to lower the
          shares_of_happiness threshold
 }}}

--

Comment (by zooko):

 This issue came up again. Omnifarious on IRC was explaining why he was
 giving up on his attempt to play with Tahoe-LAFS:

 {{{
 <Omnifarious> Yeah, I have to create a bunch of storage nodes (I think)
 and I think an introducer and figure out what the introducers furl is or
 something.
 }}}

 Also I was hanging out with Brian Warner a couple of nights ago and he
 tried to upload a file to a newly created test grid with only one server
 and was annoyed that it didn't work.

 For what it is worth, I have spent a lot of time over the years talking to
 people who deploy Tahoe-LAFS and paying attention to the process they go
 through and especially to what deters them or trips them up. I've probably
 learned about the experiences of more than 100 different people who've
 deployed, or attempted to deploy, Tahoe-LAFS over the last five or so
 years. I doubt that even one of those people would have accidentally used
 {{{K=H=N=1}}} in their production grid without realizing the reliability
 implications. I think every one of them would have chosen to change
 {{{K}}}, {{{H}}}, and {{{N}}} after testing it out and before starting to
 rely on it for long-term storage.

 Therefore, I would like to re-open this dormant ticket and *strongly*
 suggest that we change the default values of {{{K, H, N}}} from {{{3, 7,
 10}}}, to {{{1, 1, 1}}}, and we change the documentation to warn that if
 you want the erasure-coding features of Tahoe-LAFS then you have to choose
 your own {{{K}}}, {{{H}}}, and {{{N}}} based on your personal preferences
 and the shape of your grid.

 In addition to believing that this will not harm almost any users who are
 relying on Tahoe-LAFS for safe, long-term storage, and in addition to
 believing that this will greatly help newcomers who are trying to
 experiment with Tahoe-LAFS in a few spare minutes of their time, I also
 believe that it will help people understand the extremely important
 security properties of Tahoe-LAFS, most of which are actually independent
 of the erasure coding and are best understood without the complication of
 the erasure coding.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1082#comment:12>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage