Mercurial > hg > Papers > 2022 > ikki-master
diff Paper/chapter/5-Implementation.tex @ 22:bd9284f9151d
tweak
author | ichikitakahiro <e165713@ie.u-ryukyu.ac.jp> |
---|---|
date | Wed, 09 Feb 2022 23:58:05 +0900 |
parents | f8a089dbfe06 |
children | 90e6ac8805e2 |
line wrap: on
line diff
--- a/Paper/chapter/5-Implementation.tex Wed Feb 09 22:43:17 2022 +0900 +++ b/Paper/chapter/5-Implementation.tex Wed Feb 09 23:58:05 2022 +0900 @@ -46,7 +46,7 @@ \begin{center} \includegraphics[width=150mm]{./images/GearsFile.pdf} \end{center} - \caption{GearsFSのread/writeAPI} + \caption{GearsFSの呼び出し/書き込み} \label{fig:gearsFile} \end{figure} @@ -54,12 +54,12 @@ ファイルに対して書き込み、つまり従来のwriteにあたる処理を行う場合はInputQueueのkeyを指定してput操作を行う。 最終的にInputQueueに格納されたデータはInputQueueから取り出され、mainQueueに対して格納される。 -ファイルの読み込み(read)を行う際はOutputQueueに対してTake操作を行えば良い。 +ファイルの読み込み(既存のファイルシステムでのread)を行う際はOutputQueueに対してTake操作を行えば良い。 OutputQueueにはmainQueueの要素が複製されており、OutputQueue内の要素を全てTakeのループにより呼び出す。 ファイルを呼び出す側は取り出したレコードを順番に読むことでファイルを構築する。 GearsOSのファイルは大域的な資源として同時に複数のプロセスから参照が可能になる作りにしたい。 -OutputQueueは複数のプロセスからファイルreadが行われた際に、データの整合性が失われてしまう危険性がある。 +OutputQueueは複数のプロセスからファイル読み込みが行われた際に、データの整合性が失われてしまう危険性がある。 そのため、OutputQueueはCAS(Compare And Swap)を実装したSynchronizedQueueを用いる。 しかしファイルのアクセス権限の設定などにより、データアクセスが単一のプロセスからしか許さないもしくは想定されない環境では 読み込みの高速化とメモリの軽量化のため、 @@ -87,7 +87,7 @@ \section{WordCount例題} GearsFSのAPIの構成をWordCount例題を通して行った。 WordCount例題とは、指定したファイルの中身を読み取り、文字数と行数列、加えて文字列を出力するという例題である。 -この例題により連続したレコードをQueueから順次読みだすreadAPIを構築した。 +この例題により連続したレコードをQueueから順次読みだす処理を構築した。 コード\ref{src:WcImpl}にCbCで記述した、Unixファイルに対してWordCountを行うプログラムの一部を示す。 ファイルとWordCountの接続はUNIXのシェルのようにプログラムの外で行われる。 @@ -98,6 +98,8 @@ putStringはstrTableの中身がなくなった(EOF)ならshowResultへ遷移する形となる。 図\ref{fig:WordCount}にCGの遷移図を示す。 +WordCountのFileOpenとWordCount処理を別ノード上で行うことで、ファイルの読み込みとファイルの送信の構成が行える。 + \lstinputlisting[label=src:WcImpl, caption=Unixファイルに対するWordCount.cbcの一部]{src/WcImpl.cbc} \begin{figure}[h] @@ -226,7 +228,7 @@ \section{ディレクトリシステム} 本研究と並行する形で又吉雄斗によるGearsFileSystemのディレクトリ構造の構築が行われている\cite{mata-thesis}。 -GearsFSのディレクトリシステムはUnixOSのディレクトリシステムのinodeの仕組みを用いて再現することを試みている。 +GearsFSのディレクトリシステムはUnixOSのディレクトリシステムのi-nodeの仕組みを用いて再現することを試みている。 通常のUnixのディレクトリシステムと異なる点として、ディレクトリを赤黒木(RedBlackTree)を用いて構成する。 図\ref{fig:GearsDirectory}にGearsFSの構成図を示す。 @@ -244,13 +246,13 @@ \label{fig:GearsDirectory} \end{figure} -GearsのディレクトリシステムはUnixのinodeの仕様を用いる。 -inodeとはファイルごとのユニークな番号(inode番号)。データ領域へのポインタや作成日時、サイズなどのメタデータを保存するための領域である。 +GearsのディレクトリシステムはUnixのi-nodeの仕様を用いる。 +i-nodeとはファイルごとのユニークな番号(i-node番号)。データ領域へのポインタや作成日時、サイズなどのメタデータを保存するための領域である。 GearsFSの赤黒木を用いたディレクトリシステムに実際に保存されるノードはkeyがFileName、 -valueがinodeのペアを保持している。 -DirectoryTreeをファイル名で探索を行うことで任意のファイルのinode番号を手に入れ、DirectroyTreeとは別に実装されたkeyにinode番号とペアとして -ファイルのディスクアドレスを保持させるTreeをinode番号で探索させる形となる。 -この形で実装することにより、ファイル自身が所属するDirectoryをinodeが保持でき、 +valueがi-nodeのペアを保持している。 +DirectoryTreeをファイル名で探索を行うことで任意のファイルのi-node番号を手に入れ、DirectroyTreeとは別に実装されたkeyにi-node番号とペアとして +ファイルのディスクアドレスを保持させるTreeをi-node番号で探索させる形となる。 +この形で実装することにより、ファイル自身が所属するDirectoryをi-nodeが保持でき、 ファイルの複数のアカウントでの共有などによる親Directoryが複数存在する場合や、 親DirectoryのFileNameが変更された場合においてもDirectoryの構造の障害の発生を防げぐことができる。