[tahoe-dev] revived: proposal to change the default to K=H=N=1
Zooko O'Whielacronx
zookog at gmail.com
Mon Jan 14 09:34:28 UTC 2013
Folks:
I remember getting angry about this topic the last time we discussed
it. It's strange how I get all hot under the collar about minor
technical details such as the default erasure coding parameters in a
secure distributed storage system.
Anyway, the topic has come up again. I just posted this note on the ticket:
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1082#comment:12
Regards,
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.
More information about the tahoe-dev
mailing list