[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