commit c126fac8e8d4b6149eda08857f7ad509ceb4a9a3
parent 8ea6f52bfe681623f4d77e8e2d8fedbf4c42a599
Author: Ivan Gankevich <igankevich@ya.ru>
Date: Sat, 18 Mar 2017 12:19:08 +0300
Fix minor typesetting errors.
Diffstat:
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/body.tex b/src/body.tex
@@ -120,12 +120,13 @@ hierarchy, there are two variants of this failure: then principal is gone and
then any subordinate is gone. Subordinate itself is not a valuable part of
execution, it is a simple worker. Our scheduler not stored any subordinate
states, but only principle state. Thus, to restore execution, scheduler finds
-last valid principle state and simply recreate ~\ref{fig:sc12} failed subordinate on most
-appropriate daemon. When principle is gone ~\ref{fig:sc1} we need to restore it only once and
-only on one node. To archive this limitation, each subordinate will try to find
-any available daemon from its addresses list in reverse order. If such daemon
-exists and available, finding process will stop, as current subordinate kernel
-will assume that the kernel found will take principal restoration process.
+last valid principle state and simply recreate~\ref{fig:sc12} failed
+subordinate on most appropriate daemon. When principle is gone~\ref{fig:sc1} we
+need to restore it only once and only on one node. To archive this limitation,
+each subordinate will try to find any available daemon from its addresses list
+in reverse order. If such daemon exists and available, finding process will
+stop, as current subordinate kernel will assume that the kernel found will take
+principal restoration process.
\begin{figure}
\centering
@@ -172,7 +173,7 @@ in memory and will not stop execution of whole task if some part of it was
placed on failed node. But occasionally, all nodes of cluster may fail at same
time. That case is describe in third scenario. The main difference of this case
is a log usage. Log is stored on trusted storage and contains kernel states at a
-beginning of execution and each <<updated>> state. By term <<updated>> state we
+beginning of execution and each ``updated'' state. By term ``updated'' state we
define principal state after subordinates \Method{react} calls. Files of
execution log is individual for each daemon, but have replicas on selected
number of nodes to provide hardware redundancy. Scheduler at startup have empty
