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. cheers, -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
