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