[tahoe-dev] servers of happiness, families, etc.

John Case case at SDF.LONESTAR.ORG
Fri Apr 22 13:39:28 PDT 2011


I understand the servers of happiness / shares.happy setting and why it 
exists.

But I feel that it doesn't fully address the problem of distribution of 
shares.  Specifically, I could specify 3/7/10, but 5 of these could all be 
in the same rack (or in the case of jails/vms the same machine).

N gives us something very clear, and so does k, but shares.happy doesn't 
seem to ensure what we'd like it to ensure.

I believe that it has been suggested that the family concept from Tor, 
wherein circuits are built using no more than 1 node from a particular 
family, is somehow applicable here ... and I think I agree with that.

I hate to see yet another metric, but even if shares.happy is clarified, 
possibly to the "servers.independent" that was suggested in ticket 1092, 
you still don't have the ability to define any kind of institutional 
resiliency.  As we just saw yesterday with Amazon, independent servers may 
not save you.

Is it possible to incorporate the concept of "families" into the metric 
that also defines server independency ?  If not, is 
institutional/organizational resiliency important enough to the project to 
add another variable ?


More information about the tahoe-dev mailing list