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

New issue

Open

opened 2010-06-15 23:04:59 +00:00 by zooko · 10 comments

zooko commented

2010-06-15 23:04:59 +00:00

<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

``` <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 ```

zooko added the

labels 2010-06-15 23:04:59 +00:00

zooko added this to the 1.7.0 milestone 2010-06-15 23:04:59 +00:00

zooko commented

2010-06-15 23:25:30 +00:00

Author

Wrote to tahoe-dev about it: http://allmydata.org/pipermail/tahoe-dev/2010-June/004447.html

Wrote to tahoe-dev about it: <http://allmydata.org/pipermail/tahoe-dev/2010-June/004447.html>

daira commented

2010-06-17 01:02:22 +00:00

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

zooko commented

2010-06-17 03:43:30 +00:00

Author

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?

daira modified the milestone from 1.7.0 to 1.7.1

2010-06-19 05:31:13 +00:00

daira modified the milestone from 1.7.1 to soon

2010-07-17 05:49:18 +00:00

zooko commented

2011-01-31 05:00:45 +00:00

Author

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]

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] ```

daira commented

2012-06-29 13:12:29 +00:00

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

daira commented

2012-07-11 02:21:40 +00:00

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

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>

daira commented

2012-08-06 23:30:36 +00:00

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.

Replying to [davidsarah](/tahoe-lafs/trac/issues/1082#issuecomment-378920): > 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.

zooko commented

2013-01-14 07:51:37 +00:00

Author

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.

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.

zooko commented

2013-01-14 09:44:42 +00:00

Author

Posted [//pipermail/tahoe-dev/2013-January/007920.html a letter to tahoe-dev] about this.

crwood commented

2015-07-06 21:03:29 +00:00

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).

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).