Mercurial > hg > Papers > 2022 > ikki-master

comparison Paper/chapter/5-Implementation.tex @ 9:cc4cb64f9af9

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
add impl
author ichikitakahiro <e165713@ie.u-ryukyu.ac.jp>
date Tue, 25 Jan 2022 22:27:11 +0900
parents 25cf5b9b74a2
children a3cda2aa18aa
comparison
equal deleted inserted replaced
8:25cf5b9b74a2 9:cc4cb64f9af9
2 本章ではGearsOSのFileSystem(以下GearsFS)の実装について解説する。 2 本章ではGearsOSのFileSystem(以下GearsFS)の実装について解説する。
3 GearsOSのファイルは分散ファイルシステム的に大域的な資源として、 3 GearsOSのファイルは分散ファイルシステム的に大域的な資源として、
4 複数のプロセスから競合的なアクセスが可能を可能としたい。 4 複数のプロセスから競合的なアクセスが可能を可能としたい。
5 5
6 GearsFSは分散フレームワークChristieの仕組みの一部を応用する。 6 GearsFSは分散フレームワークChristieの仕組みの一部を応用する。
7 Christieの仕組みを取り入れることで、ファイルの送受信に関しては、 7 Christieの仕組みを取り入れることで、ファイルの送受信に関して、
8 ファイル内データをDataGearとして送受信することで実現する。 8 ファイル内データをレコード単位で分割し、DataGearとして送受信することで実現する。
9 9
10 10
11 11
12 \section{GearsFSのファイル構成} 12 \section{GearsFSのファイル構成}
13 GearsOSのファイルは単なるDataGearのListQueueとして実装する。 13 GearsOSのファイルは単なるDataGearのListQueueとして実装する。
14 また、ファイルのデータを貯蓄する主要なQueueとは別にinputもしくはoutputStreamとなるQueueを持ち合わせている。 14 ファイルのデータはレコードとして特定の型へ断続的に分割されたDataGearとして保存される。
15 15 ファイルの読み込みの際にはQueueに対してレコードが無くなるまでTake処理を繰り返し、レコードを参照してファイルの中身を構築することで実現する。
16 GearsFSではファイル読み込みもしくは書き込みの際、それぞれinputもしくはoutputの際にストリームのキューに対してアクセスを行う。 16
17 それぞれのキューはkey名としてinput/OutputstreamをもつQueueとして呼び出される。 17 GearsファイルはDataGearのリストとしてファイルのデータを保持する主要なQueueとは別にinputもしくはoutputStreamとなるQueueを持ち合わせており、
18 それぞれのキューはDataGearに相当し、GearsFSのファイルはChrsitieにおけるDataGearManagerに相当する。 18 ファイル読み込みもしくは書き込みの際、それぞれinputもしくはoutputの際にstreamに対してアクセスを行う。
19 それぞれのQueueはChristieにおけるkey名を持つDataGearとしてinput/OutputstreamをもつQueueとして呼び出される。
20 そのため、GearsFSのファイルはChrsitieにおけるDataGearManagerに相当する。
19 GearsOSのファイル構造へのアクセスを図\ref{fig:gearsFile}に示す。 21 GearsOSのファイル構造へのアクセスを図\ref{fig:gearsFile}に示す。
20 また、データのリストとなるQueueの構造を図\ref{fig:QueueElement}に示す。 22 また、データのリストとなるQueueの構造を図\ref{fig:QueueElement}に示す。
21 23
22
23
24 \begin{figure}[h] 24 \begin{figure}[h]
25 \begin{center} 25 \begin{center}
26 \includegraphics[width=150mm]{./images/GearsFile.pdf} 26 \includegraphics[width=150mm]{./images/GearsFile.pdf}
27 \end{center} 27 \end{center}
28 \caption{GearsFSのファイル構造} 28 \caption{GearsFSのファイル構造}
37 \caption{DataQueueの構造} 37 \caption{DataQueueの構造}
38 \label{fig:QueueElement} 38 \label{fig:QueueElement}
39 \end{figure} 39 \end{figure}
40 40
41 41
42 ファイルに対して変更、つまり新しく書き込みを行う際はInputQueueのkeyを指定してput操作を行う。 42 ファイルに対して書き込み、つまり従来のwriteにあたる処理を行う場合はInputQueueのkeyを指定してput操作を行う。
43 最終的にInputQueueに格納されたデータはInputQueueから取り出され、mainQueueに対して格納される。 43 最終的にInputQueueに格納されたデータはInputQueueから取り出され、mainQueueに対して格納される。
44 44
45 ファイルの読み込みを行う際はOutputQueueに対してTake操作を行えば良い。 45 ファイルの読み込み(read)を行う際はOutputQueueに対してTake操作を行えば良い。
46 OutputQueueにはmainQueueの要素が複製されており、OutputQueue内の要素を全てTakeで呼び出す。 46 OutputQueueにはmainQueueの要素が複製されており、OutputQueue内の要素を全てTakeで呼び出す。
47 ファイルを呼び出す側は取り出したElementのログを順番に読むことでファイルを構築する。 47 ファイルを呼び出す側は取り出したElementのログを順番に読むことでファイルを構築する。
48 48
49 GearsOSのファイルは大域的な資源として同時に複数のプロセスから参照が可能になる作りにしたい。 49 GearsOSのファイルは大域的な資源として同時に複数のプロセスから参照が可能になる作りにしたい。
50 そのため、OutputQueueは複数のプロセスから参照が行われた際に、データの整合性が失われてはならない。 50 そのため、OutputQueueは複数のプロセスから参照が行われた際に、データの整合性が失われてはならない。
51 そのため、OutputQueueはCAS(Compare And Swap)を実装したSynchronizedQueueを用いる。 51 そのため、OutputQueueはCAS(Compare And Swap)を実装したSynchronizedQueueを用いる。
52 データアクセスが単一のプロセスからしか許さないもしくは想定されていない環境では容量の軽量化のため、 52 データアクセスが単一のプロセスからしか許さないもしくは想定されていない環境では容量の軽量化のため、
53 SingleLinkedな(単純な)Queueを用いることも考えられる。 53 SingleLinkedな(単純な)Queueを用いることも考えられる。
54 ファイルに対する書き込みやMainQueueは単一プロセスのみからのアクセスとなるためSingleLickedなキューで実装する。 54 ファイルに対する書き込みやMainQueueは単一プロセスのみからのアクセスとなるためSingleLickedなキューで実装する。
55 55
56 ファイルのレコードは例題中では単純にファイル内文字列を行ごとに区切り、FileString構造体に書き込んだものとなる。
57 \ref{src:FS}にFileString構造体を示す。
58 str部分にファイル内文字列を格納し、レコードが全て送信したことを示すEoFフラグが付属している。
59 ファイルレコードはGears側のDataGearとして利用も行えるように、ContextにDataGearとして登録された構造体となる。
60
61 FileStringはテストに用いられる単純なレコードである。
62 実用性のあるレコードを考察した場合、ファイルに変更が加えられた場合Queueに格納するレコードを行順に構成し直す必要性が生じるなど多くの問題が存在する。
63 また、GearsFSではファイルの型をOSが区別できることを目指したい。
64 レコードの型を最適な形に変更することによって複数のファイルの型に対応したい。
65 例として、テキストデータの場合、変更差分をレコードとしてQueueに格納し、QueueのレコードをTopから参照していくことで構築を行う。
66 また、画像ファイルなどファイルの中身の変更が行われない形式は、ファイル内のデータをブロック長に区切り扱うといった手段が考えられる。
67
68 \lstinputlisting[label=src:FS, caption=例題のレコードとして使われるFileString構造体]{src/FileString.h}
56 69
57 70
58 71
59 \section{WordCount例題} 72 \section{WordCount例題}
60 GearsFSのAPIの構成をWordCount例題を通して行う。 73 GearsFSのAPIの構成をWordCount例題を通して行う。
61 WordCount例題とは、指定したファイルの中身を読み取り、文字数と行数列、加えて文字列などを出力するという例題である。 74 WordCount例題とは、指定したファイルの中身を読み取り、文字数と行数列、加えて文字列を出力するという例題である。
75 この例題を通すことでファイルに対するAPIを構築する。
62 コード\ref{src:WcImpl}にCbCで記述した、Unixファイルに対してWordCountを行うプログラムの一部を示す。 76 コード\ref{src:WcImpl}にCbCで記述した、Unixファイルに対してWordCountを行うプログラムの一部を示す。
63 77
64 ファイルとWordCountはUNIXのシェルのようにプログラムの外で行われる。 78 ファイルとWordCountはUNIXのシェルのようにプログラムの外で行われる。
65 ファイルは事前にC言語のFILE型構造体を用いて開かれ、行列であるwc->strTableへ内部文字列を行区切りで保存されている。 79 ファイルは事前にC言語のFILE型構造体を用いて開かれ、行列であるwc->strTableへ内部文字列を行区切りで保存されている。
66 MainからファイルのOpenが完了した後、CodeGear:putStrinに遷移し、strTableから文字列を行ごと呼び出しCountUpへ入力し遷移する。 80 MainからファイルのOpenが完了した後、CodeGear:putStrinに遷移し、strTableから文字列を行ごと呼び出しCountUpへ入力し遷移する。
69 putStringはstrTableの中身がなくなった(EOF)ならshowResultへ遷移する形となる。 83 putStringはstrTableの中身がなくなった(EOF)ならshowResultへ遷移する形となる。
70 図\ref{fig:WordCount}にCGの遷移図を示す。 84 図\ref{fig:WordCount}にCGの遷移図を示す。
71 このように特定の条件を満たすまであるCodeGear間をループ遷移する構成をGearBoxと名付けている。 85 このように特定の条件を満たすまであるCodeGear間をループ遷移する構成をGearBoxと名付けている。
72 86
73 87
88
74 \lstinputlisting[label=src:WcImpl, caption=Unixファイルに対するWordCount.cbcの一部]{src/WcImpl.cbc} 89 \lstinputlisting[label=src:WcImpl, caption=Unixファイルに対するWordCount.cbcの一部]{src/WcImpl.cbc}
75 90
76 \begin{figure}[tb] 91 \begin{figure}[tb]
77 \begin{center} 92 \begin{center}
78 \includegraphics[width=150mm]{./images/UnixWC.pdf} 93 \includegraphics[width=150mm]{./images/UnixWC.pdf}
81 \label{fig:WordCount} 96 \label{fig:WordCount}
82 \end{figure} 97 \end{figure}
83 98
84 99
85 100
86 \section{ChristieAPIによるWordCount} 101 \section{ChristieAPによるWordCount}
87 ChiristieのDataGearManagerの仕組みを基準としたGearsFSのファイル通信のAPIによるWordCountの設計を行った。 102 ChiristieのDataGearManagerの仕組みを基準としたChristieAPIによるWordCountの設計を行った。
88 図\ref{fig:ChristieAPI}にChristieAPIによるWordCountを示す。 103 図\ref{fig:ChristieAPI}にChristieAPIによるWordCountを示す。
89 ChristieAPIによるファイルデータ通信は2ペアのLocal/RemoteDGMを通して行われる。 104 ChristieAPIによるファイルデータ通信は2ペアのLocal/RemoteDGMを通して行われる。
105 RemoteDGMは接続先のノードが持つLocalDGMのプロキシであり、RemoteDGMに対してput操作を行うことで、相手の持つLocalDGMへのデータの送信が行える。
90 NodeA側が任意のファイルを開き、ファイル内の行ごとの文字列をデータとしてNodeB側に対応するRemoteDGMにputする。 106 NodeA側が任意のファイルを開き、ファイル内の行ごとの文字列をデータとしてNodeB側に対応するRemoteDGMにputする。
91 NodeB側は自身のLocalなDGMからデータを得て、WordCountの処理を行ったのちに 107 NodeB側は自身のLocalなDGMからデータを得て、WordCountの処理を行ったのちに
92 NodeAに対応するRemoteDGMに対してそのデータに対する処理が完了したことを通知するAck(acknowledgement)をputする。 108 NodeAに対応するRemoteDGMに対してそのデータに対する処理が完了したことを通知するAck(acknowledgement)をputする。
93 Ackを受け取ったOpen側のノードBは再び続きのファイル内文字列をデータとして送信する。 109 Ackを受け取ったOpen側のノードBは再び続きのファイル内文字列をデータとして送信する。
94 ここまでの処理が繰り返され、ファイル内の文字列が全て処理されたら、Open側はEoF(End of File)をCount側に対して通知、 110 ここまでの処理が繰り返され、ファイル内の文字列が全て処理されたら、Open側はEoF(End of File)をCount側に対して通知、
109 \label{fig:ChristieAPI} 125 \label{fig:ChristieAPI}
110 \end{figure} 126 \end{figure}
111 127
112 128
113 \section{Socket付きQueue} 129 \section{Socket付きQueue}
114 ChristieにおけるRocalDataGearManagerはプログラム内で使われるDataGearのkeyとデータを全て所持したコレクションにあたる。 130 ChristieにおけるLocalDataGearManagerはプログラム内で使われるDataGearのkeyとデータを全て所持したコレクションにあたる。
115 keyとデータの組み合わせは、keyの名前がつけられたQueueに対して保存される、 131 keyとデータの組み合わせは、keyの名前がつけられたQueueに対して保存される、
116 TakeコマンドではそのkeyのQueueからデータを取り出し、Peekの場合は先頭のデータを取り出さず参照のみを行っている。 132 TakeコマンドではそのkeyのQueueからデータを取り出し、Peekの場合は先頭のデータを取り出さず参照のみを行っている。
117 つまりChristieのDGMは詳細には単純なQueueの集合であると言える。 133 つまりChristieのDGMは詳細には単純なQueueの集合であると言える。
118 RemoteDGMとLocalDGMの通信の際にはLocalDGMが持つsocketに対してRemoteDGMが接続を行い、putされたkeyとDataをsocket経由でコマンドとして送信する。 134 RemoteDGMとLocalDGMの通信の際にはLocalDGMが持つsocketに対してRemoteDGMが接続を行い、putされたkeyとDataをsocket経由でコマンドとして送信する。
119 135
136
120 GearsOSのChristieAPIの定義のためにsocketに接続されたQueueによるWordCount例題を作成した。 137 GearsOSのChristieAPIの定義のためにsocketに接続されたQueueによるWordCount例題を作成した。
121 ソースコード\ref{src:LDGMQueue}にLocalDGM側にあたる、Socket付きのQueueのCodeGear:getData部分を示す。 138 ソースコード\ref{src:LDGMQueue}にLocalDGM側にあたる、Socket付きのQueueのCodeGear:getData部分を示す。
122 加えてソースコード\ref{src:RDGMQueue}にRemoteDGM側にあたるSocket付きのQueueのCodeGear:sendData部分を示す。 139 加えてソースコード\ref{src:RDGMQueue}にRemoteDGM側にあたるSocket付きのQueueのCodeGear:sendData部分を示す。
140 二つのQueueはmainプログラムによりsocketの接続が行われ、一方が文字列の送信を行い、もう一方がCount処理を行うことによってWordCountが行われる。
141
123 socketはC言語のSocketインターフェースを用いており、 142 socketはC言語のSocketインターフェースを用いており、
124 ImplementのコンストラクタにあたるcreateLocalDGMQueueにて呼び出され、 143 ImplementのコンストラクタにあたるcreateLocalDGMQueueにて呼び出され、
125 Implのメンバ変数であるsocketに置かれている。 144 Implのメンバ変数であるsocketに置かれている。
145 ソースコード\ref{src:LDGQh}に受信側となるLocalなQueueのImplementを示す。
146 socketはint型での取り扱いが行われる。Impl部分へ保存をすることで、Implを実装したプログラム内ならどのCodeGearからでもsocketの参照が行える。
147
126 また、既存のQueueから新たなAPIを追加するためにQueueInterfaceを新しく書き換えたcQueue(Communicate Queue)Interfaceを継承している。 148 また、既存のQueueから新たなAPIを追加するためにQueueInterfaceを新しく書き換えたcQueue(Communicate Queue)Interfaceを継承している。
127 Local側のgetDataはAPIとしての呼び出しが可能となっている。socketが受け取ったデータを最終的にdataとしてQueueに対してputを行う。 149 Local側のgetDataはAPIとしての呼び出しが可能となっている。socketが受け取ったデータを最終的にdataとしてQueueに対してputを行う。
128 Remote側のsendDataはAPIとしては呼び出しは行えず、putAPIが呼び出されQueueへのput処理が終了した後に遷移され、putしたDataを接続先のQueueに対して送信する。 150 Remote側のsendDataはAPIとしては呼び出しは行えず、putAPIが呼び出されQueueへのput処理が終了した後に遷移され、
129 送信データは全てのDataGearのUnionとなるData型で受け取る。 151 putしたDataを接続先のQueueに対して送信する。
152
153 \lstinputlisting[label=src:LDGQh, caption=LocalDGMQueueのImplement]{src/LocalDGMQueue.h}
154
155 現状ではデータの通信に行われるDataGearは全てのDataGearのUnion(共用体)となるData型を用いている。
130 送信データのサイズをUnion Data型のサイズにしている理由は、sizeof関数で返される値は共用体に含まれる構造体の中で最も大きなメモリサイズを返すためである。 156 送信データのサイズをUnion Data型のサイズにしている理由は、sizeof関数で返される値は共用体に含まれる構造体の中で最も大きなメモリサイズを返すためである。
157 これによりputされたDataGearの型がどのようなものであれ、受け取り側がDataGearの型を正しく選択している限りはデータの整合性を守ることができる。
158 しかし、受信側が受け取ったデータレコードの正しい型を把握しているとは限らないため、
159 将来的にはmessagePackなどによるシリアライズしたデータを送信する形にする。
131 Socketの処理中に問題が発生した場合はinputDataGearとして指定した\texttt{\_\_}code whenError()として入力されたCodeGearに対して遷移する。 160 Socketの処理中に問題が発生した場合はinputDataGearとして指定した\texttt{\_\_}code whenError()として入力されたCodeGearに対して遷移する。
132 161
133 GearsOSにおけるファイルはChristieのDGMとして見なすことができる。 162 GearsOSにおけるファイルはChristieのDGMとして見なすことができ、今回作成したQueueはそれぞれInput/OutputStreamに相当する。
134 今回作成したQueueはそれぞれInput/OutputStreamに相当する。 163
135 164
136 \lstinputlisting[label=src:LDGMQueue, caption=LocaDGMQueueのgetData]{src/LocalDGMQueue.cbc} 165 \lstinputlisting[label=src:LDGMQueue, caption=LocaDGMQueueのgetData]{src/LocalDGMQueue.cbc}
137 \lstinputlisting[label=src:RDGMQueue, caption=RemoteDGMQueueのsendData]{src/RemoteDGMQueue.cbc} 166 \lstinputlisting[label=src:RDGMQueue, caption=RemoteDGMQueueのsendData]{src/RemoteDGMQueue.cbc}
138 167
139 168
140 169
141 \section{GearsOSにおけるDataGearManager} 170 \section{GearsOSにおけるDataGearManager}
142 先で述べたSocket付きのQueueは、DataGearであるQueueとSocketが直接結びついているため、 171 先で述べたSocket付きのQueueは、DataGearであるQueueとSocketが直接結びついているため、
143 一つのDataGearを用いる場合となる最低限の通信しか行えない。 172 一つのDataGearを用いる場合となる最低限の通信しか行えない。
144 複数のDataGear(key)を用いての通信を構成するためには複数のQueueを備えることのできるリストを生成し、 173 複数のDataGear(key)を用いての通信を構成するためには複数のQueueを蓄えることのできるリストを生成し、
145 そのリスト自体がsocketを持つ必要がある。 174 そのリスト自体がsocketを持つ必要がある。
146 175
147 GearsOSではDataGearを保持するQueueのリストとして赤黒木を用いる。 176 GearsOSではDataGearを保持するQueueのリストとして赤黒木を用いる。
148 赤黒木は平衡二分木であり、木に対する操作時に行われる操作によりノードの階層が平衡化される 177 赤黒木は平衡二分木であり、木に対する操作時に行われる操作によりノードの階層が平衡化される
149 そのため各操作の最悪時間計算量O(logN)となり、二分木の中でも実用性を備えている。 178 そのため各操作の最悪時間計算量O(logN)となり、二分木の中でも実用性を備えている。
150 179
151 DataGearとなるのデータはkeyごとに作られたQueueに保存される、従ってQueueStoreとなる赤黒木にはkeyごとのQueueがノードとして保持される。 180 DataGearはkeyごとに作られたQueueに保存される、従ってQueueのstoreとなる赤黒木にはkeyごとのQueueがノードとして保持される。
152 図\ref{fig:GearsDGM}にファイルとなるDataGearManagerに対して任意のkeyに対してput/take操作を行う際の処理を示す。 181 図\ref{fig:GearsDGM}にファイルとなるDataGearManagerの任意のkeyに対してput/take操作を行う際の処理を示す。
153 いずれの場合もStoreとなる赤黒木に対して任意のkeyのQueueのget操作を行い、そのQueueに対してputもしくはtake操作を行う。 182 いずれの場合もStoreとなる赤黒木に対して任意のkeyのQueueのget操作を行い、そのQueueに対してputもしくはtake操作を行う。
154 あくまでこのDGMはファイルに相当するものなので、 183 あくまでこのDGMはファイルに相当するものなので、
155 赤黒木に含まれているQueueはInput/OutputStreamと実際にファイルデータを保持しておくmainDataQueueの三つとなる。 184 赤黒木に含まれているQueueはInput/OutputStreamと実際にファイルデータを保持しておくmainDataQueueの三つとなる。
156 しかし、WordCount例題のackや結果出力のようにStreamとなるkey以外を用いるために、ファイルに関連するkey以外にも任意にQueueを追加することもできる。 185 しかしWordCount例題のackや結果出力の通信など用途を持つ、Streamとなるkey以外を用いるために、
157 任意のQueueを追加したい場合はStoreとなるTreeに対して、 186 ファイルに関連するkey以外にも任意にQueueを追加することもできる。
187 任意のQueueを追加したい場合はstoreとなるTreeに対して、
158 Treeが保持していないkeyへputが行われた場合は新しくそのkeyを持つQueueを生成しTreeに持たせる処理を追加すれば良い。 188 Treeが保持していないkeyへputが行われた場合は新しくそのkeyを持つQueueを生成しTreeに持たせる処理を追加すれば良い。
159 189
160 図に示した手順のDataアクセスではファイルの呼び出しなどのDataGearの断続的な参照が行われる場合、 190 図に示した手順のDataアクセスではファイルの呼び出しなどDataGearの断続的な参照が行われる場合、
161 Treeへの探索処理がボトルネックになってしまう可能性が考えられる。 191 Treeへの探索処理がボトルネックになってしまう可能性が考えられる。
162 これは特定のkeyのQueueのアドレスをmain部分で直接行えるように、 192 これは特定のkeyのQueueをmain部分で直接参照できるように、
163 TreeにkeyのQueue自体のアドレスをOutputさせるAPIを記述することで解決が行えると考えられる。 193 TreeにQueue自体のポインタをOutputさせるAPIを記述することで解決が行える。
194
164 195
165 196
166 \begin{figure}[h] 197 \begin{figure}[h]
167 \begin{center} 198 \begin{center}
168 \includegraphics[width=180mm]{./images/GearsDGM.pdf} 199 \includegraphics[width=180mm]{./images/GearsDGM.pdf}
176 207
177 208
178 \section{ディレクトリシステム} 209 \section{ディレクトリシステム}
179 本研究と並行する形で又吉雄斗によるGearsFileSystemのディレクトリ構造の構築が行われている。[論文No.] 210 本研究と並行する形で又吉雄斗によるGearsFileSystemのディレクトリ構造の構築が行われている。[論文No.]
180 GearsFSのディレクトリシステムはUnixOSのディレクトリシステムと同じ仕組みを用いて再現することを試みている。 211 GearsFSのディレクトリシステムはUnixOSのディレクトリシステムと同じ仕組みを用いて再現することを試みている。
181 通常のUnixのディレクトリシステムと異なる点として、ディレクトリをRedBlackTreeを用いて構成する。 212 通常のUnixのディレクトリシステムと異なる点として、ディレクトリを赤黒木(RedBlackTree)を用いて構成する。
182 213
183 図\ref{fig:GearsDirectory}にGearsFSの構成図を示す。 214 図\ref{fig:GearsDirectory}にGearsFSの構成図を示す。
184 一つのディレクトリは赤黒木であり、あるディレクトリの中に位置するファイル(ディレクトリ含む)は赤黒木の中のノードにvalueとして同等に配置される。 215 一つのディレクトリは赤黒木を持ち、あるディレクトリの中に位置するファイル(ディレクトリ含む)は親ディレクトリが持つ赤黒木の中にノードとして同等に配置される。
185 赤黒木にはファイル下に配置された別のディレクトリもしくはファイルが保存される。 216 あるディレクトリに存在するファイルを参照する場合は、ディレクトリの持つTreeに対して探索を行えば良い。
186 図の例では/(ルートディレクトリ)からUsersディレクトリ下にあるDadというディレクトリ(もしくはファイル)を参照するには、 217 図の例では/(ルートディレクトリ)からUsersディレクトリ下にあるDadというディレクトリ(もしくはファイル)を参照するには、
187 /のTree内のUsersを探索、続いてUsersTreeの内部のDadを探索する形となる。 218 /のTree内のUsersを探索、続いてUsersTreeの内部のDadを探索する形となる。
219 また、親ディレクトリを持つ全てのファイルは、親のディレクトリの情報を保持している。
188 220
189 \begin{figure}[h] 221 \begin{figure}[h]
190 \begin{center} 222 \begin{center}
191 \includegraphics[width=80mm]{./images/GearsDirectory.pdf} 223 \includegraphics[width=80mm]{./images/GearsDirectory.pdf}
192 \end{center} 224 \end{center}
193 \caption{GearsDirectory} 225 \caption{GearsDirectory}
194 \label{fig:GearsDirectory} 226 \label{fig:GearsDirectory}
195 \end{figure} 227 \end{figure}
196 228
197 GearsのディレクトリシステムはUnixのinodeの仕様を用いる。 229 GearsのディレクトリシステムはUnixのinodeの仕様を用いる。
198 inodeとはファイルごとのユニークな番号(inode番号)データ領域へのポインタや作成日時、サイズなどのメタデータを保存するための領域である。 230 inodeとはファイルごとのユニークな番号(inode番号)。データ領域へのポインタや作成日時、サイズなどのメタデータを保存するための領域である。
199 GearsFSの赤黒木を用いたディレクトリシステムに実際に保存されるノードはkeyがFileName、 231 GearsFSの赤黒木を用いたディレクトリシステムに実際に保存されるノードはkeyがFileName、
200 valueがinodeのペアを保持している。 232 valueがinodeのペアを保持している。
201 DirectoryTreeで探索し任意のファイルのinode番号を手に入れ、DirectroyTreeとは別に実装されたkeyにinode番号とvalueとして 233 DirectoryTreeをファイル名で探索を行い、任意のファイルのinode番号を手に入れ、DirectroyTreeとは別に実装されたkeyにinode番号、ペアとして
202 ファイルのポインタを保持させるTreeをinode番号で探索させる形となる。 234 ファイルのポインタを保持させるTreeをinode番号で探索させる形となる。
203 この形で実装することにより、ファイル自身が所属するDirectoryをinode番号で保持でき、親Directoryが複数存在していたり、 235 この形で実装することにより、ファイル自身が所属するDirectoryをinode番号で保持でき、親Directoryが複数存在していたり、
204 親DirectoryのFileNameが変更された場合においてもDirectoryの構造の障害が起きない。 236 親DirectoryのFileNameが変更された場合においてもDirectoryの構造の障害が起きない。
205 237
206 238
220 ファイル構造体のバックアップについては、ファイルのDataレコードをファイルの変更差分を履歴として保持させる形にすることに加え、 252 ファイル構造体のバックアップについては、ファイルのDataレコードをファイルの変更差分を履歴として保持させる形にすることに加え、
221 変更日時を保持させることで可能となると考えられる。 253 変更日時を保持させることで可能となると考えられる。
222 特定の時点のファイルとDirectoryの状態を呼び出す際は、レコードの変更日時を確認し、参照するべきTree構造とレコードを呼び出す形となる。 254 特定の時点のファイルとDirectoryの状態を呼び出す際は、レコードの変更日時を確認し、参照するべきTree構造とレコードを呼び出す形となる。
223 255
224 非破壊的木構造の編集と変更履歴式のデータレコードはディレクトリやファイルの容量が変更が行われるたびに増加していくという問題が存在する。 256 非破壊的木構造の編集と変更履歴式のデータレコードはディレクトリやファイルの容量が変更が行われるたびに増加していくという問題が存在する。
225 この点については任意の期間経過、もしくはユーザの操作により定期的に過去のデータを自動削除することで容量がある程度削減が望める。 257 この点については任意の期間経過、もしくはユーザの操作により定期的に過去のデータを自動削除もしくは整形することで容量がある程度の削減が望める。
226 また、近年の電子記録媒体の容量増加に伴い問題の重要性が低下していくことが予想できる。 258 また、近年の電子記録媒体の容量増加に伴い問題の重要性が低下していくことが期待できる。
227 259
228 260
229 \begin{figure}[h] 261 \begin{figure}[h]
230 \begin{center} 262 \begin{center}
231 \includegraphics[width=150mm]{./images/nonDestroyTreeEdit.pdf} 263 \includegraphics[width=150mm]{./images/nonDestroyTreeEdit.pdf}
232 \end{center} 264 \end{center}
233 \caption{非破壊的なTree編集} 265 \caption{非破壊的なTree編集}
234 \label{fig:TreeEdit} 266 \label{fig:TreeEdit}
235 \end{figure} 267 \end{figure}
236 268
237 269 \section{GearsFSの分散処理}
238 270 分散フレームワークChristieとGearsOSFileSystemにおける分散処理について考察する。
239 \section{sokcet付きQueueによるDataGearPool} 271 GearsFSではファイルはDataGearのリストとして実装される。
272 ファイルの読み取り書き込みを含めた通信はDataGearリストにある特定のkeyのDataGearのQueueに対してDataを書き込み、
273 もしくは呼び出しを行うことで実現される。
274 そのためファイルはDataGearManagerであると言える。
275
276 GearsFSのファイルはChristieのDataGearManagerの仕組みを参考にするものであるが、ChristieのDGMとの明確な違いとして、
277 GearsFSのDGMはChristieのようにDataGearの差し込みによる通信を構成するだけの用途でなく、ファイルそのものとしての用途を持つという点が存在する。
278 そのため、ChristieDGMのように一つのスレッド(CGM)により管理されるものではなく、複数のスレッドから競合的にアクセスが行われるDGMである。
279 よってDataGearを保持するQueueは純粋なQueueでなく複数のアクセスが行われても、
280 データの整合性が保たれるSynchronizedなQueueを用いる必要が生じる場面がある。