91 lines
4.9 KiB
HTML
91 lines
4.9 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
|
<title>Module machi_chain_repair</title>
|
|
<link rel="stylesheet" type="text/css" href="stylesheet.css" title="EDoc">
|
|
</head>
|
|
<body bgcolor="white">
|
|
<div class="navbar"><a name="#navbar_top"></a><table width="100%" border="0" cellspacing="0" cellpadding="2" summary="navigation bar"><tr><td><a href="overview-summary.html" target="overviewFrame">Overview</a></td><td><a href="http://www.erlang.org/"><img src="erlang.png" align="right" border="0" alt="erlang logo"></a></td></tr></table></div>
|
|
<hr>
|
|
|
|
<h1>Module machi_chain_repair</h1>
|
|
<ul class="index"><li><a href="#description">Description</a></li><li><a href="#index">Function Index</a></li><li><a href="#functions">Function Details</a></li></ul>Perform "chain repair", i.e., resynchronization of Machi file
|
|
contents and metadata as servers are (re-)added to the chain.
|
|
|
|
|
|
<h2><a name="description">Description</a></h2><p>Perform "chain repair", i.e., resynchronization of Machi file
|
|
contents and metadata as servers are (re-)added to the chain.</p>
|
|
|
|
<p>The implementation here is a very basic one, and is probably a bit
|
|
slower than the original "demo day" implementation at
|
|
<a href="https://github.com/basho/machi/blob/master/prototype/demo-day-hack/file0_repair_server.escript" target="_top"><tt>https://github.com/basho/machi/blob/master/prototype/demo-day-hack/file0_repair_server.escript</tt></a></p>
|
|
|
|
<p>It's so easy to bikeshed this into a 1 year programming exercise.</p>
|
|
|
|
<p>General TODO note: There are a lot of areas for exploiting parallelism here.
|
|
I've set the bikeshed aside for now, but "make repair faster" has a
|
|
lot of room for exploiting concurrency, overlapping reads & writes,
|
|
etc etc. There are also lots of different trade-offs to make with
|
|
regard to RAM use vs. disk use.</p>
|
|
|
|
<p>There's no reason why repair can't be done:</p>
|
|
|
|
<ol>
|
|
<li> Repair in parallel across multiple repairees ... Optimization.
|
|
</li>
|
|
<li> Repair multiple byte ranges concurrently ... Optimization.
|
|
</li>
|
|
<li><p> Use bigger chunks than the client originally used to write the file
|
|
... Optimization ... but it would be the easiest to implement, e.g. use
|
|
constant-sized 4MB chunks. Unfortuntely, it would also destroy
|
|
the ability to verify here that the chunk checksums are correct
|
|
*and* also propagate the correct checksum metadata to the
|
|
destination FLU.</p>
|
|
|
|
As an additional optimization, add a bit of #2 to start the next
|
|
read while the current write is still in progress.
|
|
</li>
|
|
<li> The current method centralizes the "smarts" required to compare
|
|
checksum differences ... move some computation to each FLU, then use
|
|
a Merkle- or other-compression-style scheme to reduce the amount of
|
|
data sent across a network.
|
|
</li>
|
|
</ol>
|
|
|
|
<p>Most/all of this could be executed in parallel on each FLU relative to
|
|
its own files. Then, in another TODO option, perhaps build a Merkle tree
|
|
or other summary of the local files and send that data structure to the
|
|
repair coordinator.</p>
|
|
|
|
<p>Also, as another TODO note, repair_both_present() in the
|
|
prototype/demo-day code uses an optimization of calculating the MD5
|
|
checksum of the chunk checksum data as it arrives, and if the two MD5s
|
|
match, then we consider the two files in sync. If there isn't a match,
|
|
then we sort the lines and try another MD5, and if they match, then we're
|
|
in sync. In theory, that's lower overhead than the procedure used here.</p>
|
|
|
|
NOTE that one reason I chose the "directives list" method is to have an
|
|
option, later, of choosing to repair a subset of repairee FLUs if there
|
|
is a big discrepency between out of sync files: e.g., if FLU x has N
|
|
bytes out of sync but FLU y has 50N bytes out of sync, then it's likely
|
|
better to repair x only so that x can return to the UPI list quickly.
|
|
Also, in the event that all repairees are roughly comparably out of sync,
|
|
then the repair network traffic can be minimized by reading each chunk
|
|
only once.
|
|
<h2><a name="index">Function Index</a></h2>
|
|
<table width="100%" border="1" cellspacing="0" cellpadding="2" summary="function index"><tr><td valign="top"><a href="#repair-7">repair/7</a></td><td></td></tr>
|
|
</table>
|
|
|
|
<h2><a name="functions">Function Details</a></h2>
|
|
|
|
<h3 class="function"><a name="repair-7">repair/7</a></h3>
|
|
<div class="spec">
|
|
<p><tt>repair(ConsistencyMode, Src, Repairing, UPI, MembersDict, ETS, Opts) -> any()</tt></p>
|
|
</div>
|
|
<hr>
|
|
|
|
<div class="navbar"><a name="#navbar_bottom"></a><table width="100%" border="0" cellspacing="0" cellpadding="2" summary="navigation bar"><tr><td><a href="overview-summary.html" target="overviewFrame">Overview</a></td><td><a href="http://www.erlang.org/"><img src="erlang.png" align="right" border="0" alt="erlang logo"></a></td></tr></table></div>
|
|
<p><i>Generated by EDoc, May 20 2015, 12:50:53.</i></p>
|
|
</body>
|
|
</html>
|