[tahoe-dev] uploading unhappiness error messages

Brian Warner warner at lothar.com
Wed Jan 5 01:27:51 UTC 2011

On 1/4/11 9:36 AM, Greg Troxel wrote:
> If the server status page had information about which servers had
> refused to take shares (and the smallest size that was refused)
> recently, that would help people figure things out.   Right now the only
> way to tell that servers are full is to get upload errors and then try
> to piece things together.

Oh, that's an awesome idea. I'll add that to the accounting
server-status page that I'm building for #666 now.

> Making the default be 1/10 would be ok.  I think the default needs to
> admit redundancy even if it doesn't require it.  One can then change
> From 1/1/10 to 1/3/10 just by changing configs, without any reencoding.
> The initial setup should be one that can be migrated to a useful setup
> without a restart.

I prefer k=3 H=1 N=10. That gets you good diversity if you have enough
servers, good redundancy, and works successfully for any number of
servers. I'm quite proud of the fact that tahoe will tolerate putting
multiple shares on a single server, to provide this sort of flexibility
to multiple use cases. (I'm less proud of the fact that it might do this
when you don't expect it to, especially in the "I'm only talking to
myself" case, but I think we're getting a handle on that).

If you know that you'll always have at least X servers, then you can set
H to something higher to force a failure when your expectations are
violated (maybe set H equal to X, but I believe the happiness
calculation is weirder than that).

k=1/N=10 is way too much expansion (at least for files.. we've talked
about making dirnodes use 1-of-10, since they're more important and
ususally smaller). k=1/N=1 won't fail, but it will silently fail to
protect you when you do have more than one server.


More information about the tahoe-dev mailing list