#1082 new defect

default servers-of-happiness=7 prevents single-server use case from working "out of the box"

Reported by: zooko Owned by: somebody
Priority: major Milestone: soon
Component: documentation Version: 1.7β
Keywords: defaults docs unfinished-business servers-of-happiness upload zookos-opinion-needed warners-opinion-needed Cc:
Launchpad Bug:

Description (last modified by zooko)

<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				   

Change History (15)

comment:2 Changed at 2010-06-17T01:02:22Z by davidsarah

Is this adequately fixed by the note added to soruce:docs/running.html in 4141d955884670e7?

Version 1, edited at 2010-06-17T01:02:42Z by davidsarah (previous) (next) (diff)

comment:3 Changed at 2010-06-17T03:43:30Z by zooko

I don't think the docs are good enough yet. Let's leave this ticket open. I hope to rewrite running.html to be a more imperative, story-oriented document such as suggested by Glyph in #1024. I'm not sure when I will have time to do this, though. :-( Maybe Saturday when I'm taking a flight from DEN to SFO?

comment:4 Changed at 2010-06-19T05:31:13Z by davidsarah

  • Keywords docs added
  • Milestone changed from 1.7.0 to 1.7.1

comment:5 Changed at 2010-07-17T05:49:18Z by davidsarah

  • Keywords unfinished-business added
  • Milestone changed from 1.7.1 to soon

comment:6 Changed at 2010-12-29T09:14:06Z by zooko

  • Keywords servers-of-happiness added

comment:7 Changed at 2010-12-29T09:19:20Z by zooko

  • Keywords upload added

comment:8 Changed at 2011-01-31T05:00:45Z by zooko

from IRC:

<pythonirc1012> can i build a tahoe-lafs with a few machines like 3-4?
...
<pythonirc1012> i read in the installation notes somewhere that i need at
		least some number of machines...
...
<pythonirc1012> This is what I read -- that stopped me -- If you are using
		Tahoe-LAFS on a     grid with fewer than 7 storage nodes, this
		won't work well for you     — none of your uploads will
		succeed						        [21:14]

comment:9 follow-up: Changed at 2012-06-29T13:12:29Z by davidsarah

  • Keywords zookos-opinion-needed warners-opinion-needed added

I think we had consensus to change the defaults to 1/1/1. Shall we do that for 1.10?

Last edited at 2012-08-06T23:30:53Z by davidsarah (previous) (diff)

comment:10 Changed at 2012-07-11T02:21:40Z by davidsarah

zooko wrote:

I've previously argued that we should set K, H, and N to 1 default settings, on the grounds that the default settings are for people to learn the system, not for people to use the default settings in production. I'd like to add to that argument that setting the defaults to 1 would help educate people that the most important difference between Tahoe-LAFS and another backup tool is the provider-independent security, not the erasure-coding. Currently, some people decide not to try using Tahoe-LAFS because they don't have multiple servers to run it on:

https://plus.google.com/u/0/102645752210227937753/posts/fng9AGMZWEk?hl=en

comment:11 in reply to: ↑ 9 Changed at 2012-08-06T23:30:36Z by davidsarah

Replying to davidsarah:

I think we had consensus to change the defaults to 1/1/1. Shall we do that for 1.10?

Judging by IRC and tahoe-dev discussions, we don't have consensus on this yet.

comment:12 Changed at 2013-01-14T07:51:37Z 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.

comment:13 Changed at 2013-01-14T09:44:42Z by zooko

Posted a letter to tahoe-dev about this.

comment:14 Changed at 2015-07-06T20:10:45Z by zooko

  • Description modified (diff)
  • Keywords defaults added

comment:15 Changed at 2015-07-06T21:03:29Z by cypher

Agreed on this. I suspect that one of the biggest barriers-to-adoption for potential users, in general, consists in having to manually tune configuration values (whose meanings are already arguably very opaque). N, K, and H are especially problematic in this regard since their appropriate values cannot be meaningfully determined without some prior knowledge of the size of the grid, however, in a typical first-time use-case, the size of the grid is not typically known until after the user is already up and running and hits the WUI landing page for the first time (I say this on the grounds that first-time users are more likely to join a pre-existing grid to experiment with than they are to set up one of their own, given the time and knowledge commitments required of the latter).

That said, a hypothetical first-time user would arguably experience less overall friction with N = 1, K = 1, and H = 1 (in which case, they face a low chance of a missing share, increasing over time) vs. N = 10, K = 3, and H = 7 (in which case, they face a high chance of a failed upload right away).

Note: See TracTickets for help on using tickets.