[tahoe-dev] Tahoe-LAFS is widely misunderstood
Chris Palmer
chris at noncombatant.org
Wed Feb 2 04:43:01 PST 2011
Greg Troxel writes:
> Removal of introducer; presumably each client has to be configured
> with all servers; I'm not sure this is a win.
True. However, since the server is resilient against a variety of server
policies, you can handle this in any number of ways. Examples:
* Anonymous registration for clients on my subnet
* Paid registration via web app; service gains reliability by having one
server (or family of servers) be front-ends for a vast array of additional
replicated servers on the backend
* Anonymous registration with quotas
* Pseudonymous registration with some new in-band protocol message types
RegistrationRequest and RegistrationResponse (pretty sure I'm going to
need these)
> You don't explain how you're dealing with repair, leases and garbage
> collection, or why you don't need them.
Same thing: servers can do whatever they want for garbage collection:
* Quotas
* Delete rarely-requested segments
* For clients and servers that trust each other and want to be tightly
integrated, the server could know the directory descriptors and thus could
compute what segments are no longer used
Repair is performed by the client, asynchronously, as described in a
previous email: "Hey, have I saved all my segments to all my servers? Oh,
good. Say, while I'm prefetching for performance, I think I'll do it
randomly across the set of servers and see how they are all doing. Is that
old guy still up and serving my segments?"
--
http://noncombatant.org/
More information about the tahoe-dev
mailing list