[tahoe-dev] #467 static-server-selection UI (was: web "control panel", static server selection UI)

[Shu Lin]

> From: Chris Palmer <chris at noncombatant.org>
>
> My plan for Octavia is/was along these lines, but design and implementation
> is made simpler by the lack of erasure coding. Octavia always mirrors every
> file segment to as many servers as it can. This is dumb, high cost, and
> high
> reliability, and it is ok because disk space is the cheapest computing
> resource we have. Wasting money here allows us to save on UI and
> implementation complexity, and also guarantees that the parallel-reads
> optimization is always available (because read time for a network
> filesystem
> is always a pain point). In Octavia, the Cost/Reliability slider merely
> means "How many servers should I copy files to: 1, 5, or Overkill?"
>
> Then, rather than letting slow servers block uploads ("not happy yet!",
> "slow server stopping us from reaching k!", et c.), we can merely provide a
> status indicator (red, yellow, green) telling the user how close we are to
> reaching their desired point on the Cost/Reliability slider.
>
> Writes are cached locally (hence seemingly "fast"); each client is at least
> a caching server to itself and possibly a server to friends in the grid.
> This gets us status = Red.
>
> Asynchronously, the client tries to copy segments to other servers,
> gradually reaching status = Green. If a server is offline, the client just
> keeps trying (like an email server) for the server to come back. A slow
> server is annoying (or completely ignorable, if enough faster servers are
> available), rather than fatal.
>
> Now, we have a situtation that normal users, expert users, and implementers
> can all understand. All the words have their colloquial meanings: status,
> green, yellow, red, 1, 5, overkill, cost, reliability. Advanced users can
> look up "asynchronous" in the dictionary and think, "Ohh, that's why it's
> always Red for a moment after I save something. Cool. One time it stayed
> Red
> for like 10 minutes and I was like whoa! Then it turned Yellow and I was
> like whew."
>
> Yes, we've pessimized storage efficiency and made fully Green writes slow
> (because many copies), so the design is "dumb" or "wasteful" or
> "embarrassing". But we've improved understandability (for all classes of
> person), read/write performance, and provider-independent reliability.
>


This simple elegant approach is exactly what I want. Asynchronous,
less-parallelized file sync works great in personal/private grid case. In
the personal grid case, we don't need care about one of the server will be
shut down by somebody else.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110125/619d09ec/attachment.html>