[tahoe-dev] Why no error message when I have only one storage node?
Brian Warner
warner at lothar.com
Mon Aug 10 11:45:23 PDT 2009
Shawn Willden wrote:
>
> In the case of a friendnet, the size isn't likely to change very much
> after you get it set up, and you'll probably tune your Tahoe nodes
> such that M is set to the size of the grid minus one (probably
> adjusting K as well), and then ensure that your node is the one that
> does not receive a share of your files.
Ah, this adds an important desiderata to the #573/#467 server-selection
configuration language: something to say "please do not use server X,
even if they're running a storage server", with a special case for
X==me. A very early version of Tahoe had this behavior hard-coded, but
we took that out when we started thinking about Tahoe has a
general-purpose storage system (instead of specifically as a backup
system), and about how in that frame of mind, files should always be
placed on the grid in the same way regardless of who happened to upload
them. Making this configurable is a great idea.
I've got a fairly short plan in mind for #467. Most of the code is
already in place (but commented out) for having tahoe.cfg define the
serverlist instead of the Introducer: the biggest obstacle deciding upon
a tahoe.cfg section name. "[client-server-selection]" is the current
working title, but it's way too complicated. Maybe it should be put in
the "[client]" section? The idea I'm aiming for is that this is a place
where you tell a Tahoe client where it ought to find the storage
servers. We already have:
[node]: general node configuration, not specific to client or server
[client]: client configuration: encoding parameters, introducer furl,
helper/keygen furls
[storage]: run and configure a storage server: reserved space,
lease expiration
[helper]: run and configure a Helper
So the section name needs to start with "client", to indicate that it's
configuring a client (as opposed to a server or a helper or whatever),
but it should also somehow express that we're talking about servers too.
Ideas?
The code that needs to be written after that is the part that influences
upload: control over how many shares go to each server, whether to use
permutation or not. There's a moderate amount of work to do for this
phase, but it isn't particularly deep.
Please take a look at #467 and let me know what you think tahoe.cfg
should look like.
thanks,
-Brian
More information about the tahoe-dev
mailing list