[tahoe-dev] Tahoe-LAFS is widely misunderstood

[Greg Troxel]

Chris Palmer <chris at noncombatant.org> writes:

> 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)

Sure, but it's going to get complicated.

>>   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

That's basically gc, and quotas are another issue, but sure.

> * 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

That breaks the primary security property.

> 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?"

Those are all fair points.  But, you're describing an architecture
within which one can make implementation choices and implementations,
and it's somewhat awkward to make simplicitly comparisons between an
architecture and running code.

But, I see your point about unix tools philosophy and keeping things
separate.


I understand your objections and stake-in-the-ground simpler system
point, but I think that we could have 90% of hte value of your approach
just by making the FUSE interface first-class.  I know I'm supposed to
file a ticket, and that you and I see this the same way, but for
everyone else, I mean:

  Be able to use FUSE to mount tahoe, and have that interface be
  sufficiently rich and usable that most people almost never want to use
  the CLI, and *never* want to use the WUI.

  I wouldn't mind a cron job to run "tahoe deep-check --repair --add-lease"
  every few days via the CLI, or using the CLI for making new roots to
  mount.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110202/f63be615/attachment.asc>