> From: Chris Palmer <[email protected]> > > 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.
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
