<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Message: 6<br>
Date: Wed, 12 Jan 2011 00:40:21 -0700<br>
From: "Zooko O'Whielacronx" <<a href="mailto:zooko@zooko.com">zooko@zooko.com</a>><br>
To: Tahoe-LAFS development <<a href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a>><br>
Subject: [tahoe-dev] default values of K, H, N (was: I assumed each<br>
share would go to a different server...)<br>
Message-ID:<br>
<AANLkTikEiOMwbfHW=WufvjjPXxqquo9J5REBq=_<a href="mailto:gG8k9@mail.gmail.com">gG8k9@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Dear Josh, Shawn, Greg, et al.:<br>
<br>
While it warms my heart to see people teaching each other, it's not<br>
"scalable" for new users to be surprised when the behavior doesn't<br>
match their assumptions, then post on the mailing list and get an<br>
explanation about why the actual behavior differs from their<br>
assumptions.<br>
<br>
I think we should either change the default behavior to match the<br>
common user expectations, or else add documentation to, if possible,<br>
explain the surprising thing for them when they begin trying to use<br>
it.<br>
<br>
Note that another user, more than one year ago, reported the same confusion:<br>
<br>
<a href="http://tahoe-lafs.org/pipermail/tahoe-dev/2009-August/002494.html" target="_blank">http://tahoe-lafs.org/pipermail/tahoe-dev/2009-August/002494.html</a><br>
<br>
Which is why I created ticket #778 (servers of happiness).<br>
<br>
There are some reasons (mostly to do with performance and<br>
availability) why someone might want N > H, but the newbies seem to<br>
expect H == N. Perhaps we should set H == N in the defaults and then<br>
let more sophisticated users tune the (K, H, N) for their particular<br>
grid and their preferences?<br>
<br>
Speaking generally, I think there are at least three different<br>
desiderata that we could have for our default settings, and we<br>
probably can't have all of what we want:<br>
<br>
1. (Safety) Users who entrust valuable data to it without changing the<br>
defaults won't lose integrity, confidentiality, or data-preservation.<br>
<br>
2. (Unsurprisingness) Users will rarely be surprised by the default behavior.<br>
<br>
3. (Performance and Features) Users will get good transfer speeds, the<br>
ability to migrate or rebalance files without having to re-encode<br>
them, better storage efficiency, higher fault-tolerance, etc.<br>
<br>
I would really like to prioritize them in this order.<br>
<br>
(Hm, in a sense Unsurprisingness is really the essence of Safety.<br>
Regardless of what the settings are, if the user understands the<br>
consequences of those settings then they won't be harmed.)<br>
<br>
I don't think default settings are a good way to accomplish<br>
desideratum 3 very well because the settings probably have to be tuned<br>
to the particular grid. Fran?ois has a grid with three physical<br>
machines and 60- or 70- odd storage server processes. I have a grid (I<br>
just set it up!) with eight storage server processes on a single<br>
Amazon EC2 virtual machine. The volunteergrid1 has 17 physical servers<br>
of hetergeneous size and performance, each one operated by a different<br>
volunteer. In the future, more people might set up their own "personal<br>
Tahoe-LAFS grid" consisting of only a single storage server owned by<br>
them. There are no default settings that are optimal for all of these<br>
cases.<br>
<br>
Documentation is probably the best way to accomplish desideratum 3.<br>
(Our documentation is already better than most open source projects,<br>
but it could also has lots of room for improvement. Volunteers<br>
needed!)<br>
<br>
So I would favor some default settings like (1, 1, 1) or (1, 3, 3) or<br>
(3, 10, 10), because those seem to score higher on Unsurprisingness in<br>
my book.<br>
<br>
Honestly at the moment I think I favor (1, 1, 1). It works on any grid<br>
(even "the 1-server grid", which I imagine might turn out to be a<br>
valuable use case), the safety qualities should be obvious to any<br>
user, and it arranges for users to learn about the confidentiality and<br>
integrity properties first, and then separately to learn about the<br>
consequences of erasure-coding.<br>
<br>
Thoughts?<br>
<br>
Regards,<br>
<br>
Zooko<br>
<br>
<a href="http://tahoe-lafs.org/trac/tahoe-lafs/ticket/778#" target="_blank">http://tahoe-lafs.org/trac/tahoe-lafs/ticket/778#</a> "shares of<br>
happiness" is the wrong measure; "servers of happiness" is better<br>
</blockquote></div><br> For a default how about H = N? <br><br> I notice that in:<br><br>
<a href="http://tahoe-lafs.org/pipermail/tahoe-dev/2009-August/002494.html" target="_blank">http://tahoe-lafs.org/pipermail/tahoe-dev/2009-August/002494.html</a><br>
<br> the user only used a one server grid in a an attempt to create an error, which would have happened had H = N been true in his case.<br><br> Isn't having H < N, a setup that trades off reliability for performance?<br>
<br> If so, then this is trading desideratum (1) (or some component thereof) for desideratum (3). <br><br> Seems like H = N meets (1) and (2) at a possible cost to (3). <br><br> Given the way you've ordered your values this choice seems good.<br>
<br><br>--J<br>