[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