--- a/Paper/chapter/5-Implementation.tex	Mon Jan 31 21:27:24 2022 +0900
+++ b/Paper/chapter/5-Implementation.tex	Sat Feb 05 04:49:27 2022 +0900
@@ -4,14 +4,21 @@
 複数のプロセスから競合的なアクセスが可能を可能としたい。
 
 GearsFSは分散フレームワークChristieの仕組みの一部を応用する。
-Christieの仕組みを取り入れることで、ファイルの送受信に関して、
+ファイルはChristieにおけるDataGearManager的に実装を行い、ファイルの送受信は、
 ファイル内データをレコード単位で分割し、DataGearとして送受信することで実現する。
 
+Christieは自律分散システムを目指した分散フレームワークである。
+Christieの仕組みにより、GearsFSは通信の中枢となるサーバーノードが必要なくなるような、自律分散なファイルシステムを目指す。
 
 
 \section{GearsFSのファイル構成}
 GearsOSにおけるファイルのデータは任意の型を持ったレコード(構造体)に断続的に分割されて構成され、
 それを保持するファイルは単なるDataGearのListQueueとして実装される。
+つまり、GearsFSにおけるファイルの読み書きは従来の分散ファイルシステムのようなプロトコルを用いず、データベースアクセス的な処理で構成される。
+プロトコルを用いず、最低限なデータアクセスによる通信を構成することで、分散通信技術の見通しをよくする狙いがある。
+また、CodeGearはTransactionと言えるのでkeyの書き込みはTransactionに閉じられ、動作が明確になる。
+
+
 ファイルの読み込みの際はQueueに対して順次データレコードのTake操作を繰り返し、連続したレコードからファイルの中身を構築することで実現する。
 つまり、一見としてChristieのファイルはQueueとその要素(Element)として構成される。
 データのリストとなるQueueの構造を図\ref{fig:QueueElement}に示す。
@@ -26,7 +33,7 @@
 \end{figure}
 
 
-しかし、単純に一つのQueueをファイルとして直接読み書きを行うと、複数のノードからのアクセスされた際の整合性や、セキュリティの面で問題が発生する。
+しかし、単純に一つのQueueに対しファイルとして直接読み書きを行うと、複数のノードからのアクセスされた際の整合性や、セキュリティの面で問題が発生する。
 そのため、GearsFSのファイルは主体となるデータを保持する主要なQueueとは別にinputもしくはoutputStreamとなるQueueを持ち合わせている。
 そのためGearsFSファイルは複数の役割を持ったDataGearを持つリストとして実装される。
 GearsOSのファイル構造へのアクセスを図\ref{fig:gearsFile}に示す。
@@ -54,7 +61,8 @@
 GearsOSのファイルは大域的な資源として同時に複数のプロセスから参照が可能になる作りにしたい。
 OutputQueueは複数のプロセスからファイルreadが行われた際に、データの整合性が失われてしまう危険性がある。
 そのため、OutputQueueはCAS(Compare And Swap)を実装したSynchronizedQueueを用いる。
-しかしファイルのアクセス権限の設定などにより、データアクセスが単一のプロセスからしか許さないもしくは想定されない環境では読み込みの高速化とメモリの軽量化のため、
+しかしファイルのアクセス権限の設定などにより、データアクセスが単一のプロセスからしか許さないもしくは想定されない環境では
+読み込みの高速化とメモリの軽量化のため、
 SingleLinkedな(単純な)Queueを用いることも考えられる。
 ファイルに対する書き込みやMainQueueは単一プロセスのみからのアクセスとなるためSingleLickedなキューで実装する。
 
@@ -65,9 +73,10 @@
 
 FileStringはテストに用いられる単純なレコードである。
 実用性のあるレコードを考察した場合、ファイルに変更が加えられた場合Queueに格納するレコードを行順に構成し直す必要性が生じるなど多くの問題が存在する。
-また、GearsFSではファイルの型をOSが区別できることを目指したい。
+また、GearsFSではファイルの型をOSが区別できることを目指しており、
 レコードの型を最適な形に変更することによって複数のファイルの型に対応したい。
-例として、テキストデータの場合、変更差分をレコードとしてQueueに格納し、QueueのレコードをTopから参照していくことで構築を行う。
+例として、テキストデータの場合、gitやMercurialなどのバージョン管理システムのように、
+変更差分をレコードとしてQueueに格納し、QueueのレコードをTopから参照していくことで構築を行う。
 また、画像ファイルなどファイルの中身の変更が行われない形式は、ファイル内のデータをブロック長に区切り扱うといった手段が考えられるなど、
 ファイルの型に応じてレコードの構造体を任意に構成することができる。
 
@@ -76,7 +85,7 @@
 
 
 \section{WordCount例題}
-GearsFSのAPIの構成をWordCount例題を通して行う。
+GearsFSのAPIの構成をWordCount例題を通して行った。
 WordCount例題とは、指定したファイルの中身を読み取り、文字数と行数列、加えて文字列を出力するという例題である。
 この例題により連続したレコードをQueueから順次読みだすreadAPIを構築した。
 コード\ref{src:WcImpl}にCbCで記述した、Unixファイルに対してWordCountを行うプログラムの一部を示す。
@@ -134,7 +143,8 @@
 
 
 \section{Socket付きQueue}
-RemoteDGMとLocalDGMの接続の際にはLocalDGMが持つsocketに対してRemoteDGMが接続を行い、Dataの書き込み先のkeyを指定してsocket経由でコマンドとして送信する。
+RemoteDGMとLocalDGMの接続の際にはLocalDGMが持つsocketに対してRemoteDGMが接続を行い、
+Dataの書き込み先のkeyを指定してsocket経由でコマンドとして送信する。
 
 socketを所有したQueueによるWordCount例題の記述を行うことでGearsOSにおけるsocketの取り扱いと実用性を検証した。
 接続元と接続先のsocketは、Queueの作成時に行われ、
@@ -165,8 +175,9 @@
 将来的にはJavaにおけるmessagePackに相当する機能になどによるシリアライズしたデータを送信する形にする。
 Socketの処理中に問題が発生した場合はinputDataGearとして指定した\texttt{\_\_}code whenError()として入力されたCodeGearに対して遷移する。
 
-
+\newpage{}
 \lstinputlisting[label=src:LDGMQueue, caption=LocaDGMQueueのgetData]{src/LocalDGMQueue.cbc}
+\newpage{}
 \lstinputlisting[label=src:RDGMQueue, caption=RemoteDGMQueueのsendData]{src/RemoteDGMQueue.cbc}
 
 
@@ -181,6 +192,9 @@
 赤黒木は平衡二分木であり、木に対する操作時に行われる操作によりノードの階層が平衡化される
 そのため各操作の最悪時間計算量O(logN)となり、二分木の中でも実用性を備えている。
 
+Queueを所持するリストはTreeでなくとも単純な単方向あるいは双方向リストなどでも実現は可能であるが、
+GearsOSにおけるファイルは複数のプロセスからのアクセスが行われ、アクセスが増えるほどDataGearのkeyの数が増加するため赤黒木での実装を行う。
+
 DataGearはkeyごとに作られたQueueに保存される、従ってQueueのリストとなる赤黒木にはkeyごとのQueueがノードとして保持される。
 図\ref{fig:GearsDGM}にファイルとなるDataGearManagerの任意のkeyに対してput/take操作を行う際の処理を示す。
 いずれの場合もリストとなる赤黒木に対して任意のkeyのQueueのget操作を行い、そのQueueに対してputもしくはtake操作を行う。
@@ -193,9 +207,11 @@
 
 図に示した手順のDataアクセスではファイルの呼び出しなどDataGearの断続的な参照が行われる場合、
 Treeへの探索処理がボトルネックになってしまう可能性が考えられる。
-これは特定のkeyのQueueをmain部分で直接参照できるように、
+これは特定のkeyのQueueをmainプログラムで直接参照できるように、
 TreeにQueue自体のポインタをOutputさせるAPIを実装することで解決が行える。
 
+
+
 \begin{figure}[h]
     \begin{center}
         \includegraphics[width=150mm]{./images/newGearsFile.pdf}
@@ -231,10 +247,11 @@
 inodeとはファイルごとのユニークな番号(inode番号)。データ領域へのポインタや作成日時、サイズなどのメタデータを保存するための領域である。
 GearsFSの赤黒木を用いたディレクトリシステムに実際に保存されるノードはkeyがFileName、
 valueがinodeのペアを保持している。
-DirectoryTreeをファイル名で探索を行い、任意のファイルのinode番号を手に入れ、DirectroyTreeとは別に実装されたkeyにinode番号、ペアとして
-ファイルのポインタを保持させるTreeをinode番号で探索させる形となる。
-この形で実装することにより、ファイル自身が所属するDirectoryをinode番号で保持でき、親Directoryが複数存在していたり、
-親DirectoryのFileNameが変更された場合においてもDirectoryの構造の障害が起きない。
+DirectoryTreeをファイル名で探索を行うことで任意のファイルのinode番号を手に入れ、DirectroyTreeとは別に実装されたkeyにinode番号とペアとして
+ファイルのディスクアドレスを保持させるTreeをinode番号で探索させる形となる。
+この形で実装することにより、ファイル自身が所属するDirectoryをinodeが保持でき、
+ファイルの複数のアカウントでの共有などによる親Directoryが複数存在する場合や、
+親DirectoryのFileNameが変更された場合においてもDirectoryの構造の障害の発生を防げぐことができる。
 
 
 
@@ -286,10 +303,13 @@
 par gotoとはGearsOSにおける並列処理構文である。
 par gotoによる並列処理ではTaskをContextで表現し、TaskのInputDataGearが揃ったTaskをWorkerで処理を行う。
 図\ref{fig:WorkerRun}にpar goto構文による並列処理を示す。
-GearsFSではファイル送受信自体をTaskの一つとして実装する他に、
-socketに対してファイルデータの確認と取り出しを行う待ち合わせの処理を一つのTaskとする必要がある。
+GearsFSではstreamに対する書き込みや取り出しとqueueに蓄えられたデータレコードの送受信を並列に実行する。
+当然複数のファイルが同時に通信される場合はそれらも並行に処理が行われる。
 
-
+現状、GearsOSのpar gotoは実装にいくつか問題点があり、処理速度が比較的遅いことに加え、
+トランスコンパイラによる書き出しが多くバグが発生しやすい。
+そのため、par gotoによる並列処理の構成をより軽量なものに改良する、
+もしくはファイル通信用の並列処理を独自に開発してしまうという案も考えられる。
 
 \begin{figure}[h]
     \begin{center}
@@ -306,3 +326,14 @@
 リスト(DataGearManager)の中のQueueである、ファイルデータそのものを保持しているmainDataQueueを格納すれば良い。
 持続性デバイスは単なるメモリとして扱ってよく、メモリ上のデータ構造と同様に構築する。
 逆にメモリ上へファイルを展開する場合、デバイス上に保存されているQueueを呼び出し、メモリ上でLocalDataGearManagerとして構築すれば良い。
+図\ref{fig:fp}にデバイス上に保存されたDGMをLocalDGMとして呼び出す際の遷移図を示す。
+ストレージ上のブロックのアドレスはunixファイルシステム同様に、ファイルが保持しているi-nodeが認知していればよい。
+
+
+\begin{figure}[h]
+    \begin{center}
+        \includegraphics[width=120mm]{./images/filePersistency.pdf}
+    \end{center}
+    \caption{file Persistency}
+    \label{fig:fp}
+\end{figure}