machi/edoc/machi_chain_repair.html
Scott Lystig Fritchie ae67e6698b EDoc update
2015-05-20 12:58:44 +09:00

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 &amp; 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) -&gt; 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:58:33.</i></p>
</body>
</html>