Mercurial > hg > Papers > 2022 > ikki-master
changeset 42:01b88c0dd337
tweak
| author | ichikitakahiro <e165713@ie.u-ryukyu.ac.jp> |
|---|---|
| date | Mon, 28 Feb 2022 22:11:26 +0900 |
| parents | 3959e0817369 |
| children | 9067e6c32410 |
| files | .DS_Store Paper/chapter/0-introduction.tex Paper/chapter/4-Christie.tex Paper/chapter/5-Implementation.tex Paper/chapter/conclusion.tex Paper/master_paper.pdf Paper/src/LocalDGMQueue.cbc Paper/src/RemoteDGMQueue.cbc finalSlide/finalSlide.html finalSlide/finalSlide.md finalSlide/finalSlide.pdf.html poster/.DS_Store poster/ikki-poster.graffle/data.plist |
| diffstat | 13 files changed, 94 insertions(+), 904 deletions(-) [+] |
line wrap: on
line diff
--- a/Paper/chapter/0-introduction.tex Thu Feb 17 23:24:09 2022 +0900 +++ b/Paper/chapter/0-introduction.tex Mon Feb 28 22:11:26 2022 +0900 @@ -23,11 +23,15 @@ 従来ではアプリケーションが担っているバックアップを始めとした機能を搭載したファイルシステムの構成を目指して開発を行いたいと考えた。 問題点の解決の一部として、既存のファイルシステムとは異なりファイルシステムをデータベースとして構成したい。 レコードでファイルデータを取り扱うことによりファイルの更新や操作を簡潔に行い、またFileSystemのAPIを総括してトランザクションとしたい。 +TransactionはGearsOSのCodeGearの性質を用いて実装される。 加えて、データのバックアップについてもOSに搭載したい。 従来のようにバックアップデータをユーザが管理するのではなく、OSが管理をすることによりバックアップデータ自体の紛失を防ぎたい。 また、GearsOSの分散ファイルシステムは当研究室が開発している分散フレームワークであるChristieの仕組みを用いて構成する。 Christieは通信を形成する接続形態(Topology)の中枢を持たない、自律分散の実現を目的に開発されている。 +ファイルデータの最小単位をGearsOSの処理単位であるDataGearにすることで、GearsOSの信頼性の保証が行える構成にしたい。 +また、Christieのデータ通信方式により、 +ネットワーク上に複数のプロトコルが使われることにより生じる煩雑性を抑えることで見通しを確保する。 GearsOSのファイルシステムでは、Christieによるファイル通信を構成することで自律分散なファイルシステムの構築を目指したい。 加えて、Christieの持つGear概念による簡潔な分散処理と、処理を行うノードごとの接続(Topology形成)
--- a/Paper/chapter/4-Christie.tex Thu Feb 17 23:24:09 2022 +0900 +++ b/Paper/chapter/4-Christie.tex Mon Feb 28 22:11:26 2022 +0900 @@ -173,6 +173,7 @@ 図中の場合、CGAがTopoplogyManagerを所持しており、 TopologyManagerによってCG:1がroot、CG:2とCG:3がCG:1の子として役を割り振られ、接続される形となる。 +将来的にTopologyManagerもGearsOSに取り込み、ファイル通信の接続のサポートとして用いる。 \begin{figure}[tb] \begin{center}
--- a/Paper/chapter/5-Implementation.tex Thu Feb 17 23:24:09 2022 +0900 +++ b/Paper/chapter/5-Implementation.tex Mon Feb 28 22:11:26 2022 +0900 @@ -5,21 +5,21 @@ GearsFSは分散フレームワークChristieの仕組みの一部を応用する。 ファイルはChristieにおけるDataGearManager的に実装を行い、ファイルの送受信は、 -ファイル内データをレコード単位で分割し、DataGearとして送受信することで実現する。 +ファイル内データを構造体の単位で分割し、DataGearとして送受信することで実現する。 Christieは自律分散システムを目指した分散フレームワークである。 Christieの仕組みにより、GearsFSは通信の中枢となるサーバーノードが必要なくなるような、自律分散なファイルシステムを目指す。 \section{GearsFSのファイル構成} -GearsOSにおけるファイルのデータは任意の型を持ったレコード(構造体)に断続的に分割されて構成され、 +GearsOSにおけるファイルのデータは任意の型を持った構造体に断続的に分割されて構成され、 それを保持するファイルは単なるDataGearのListQueueとして実装される。 -つまり、GearsFSにおけるファイルの読み書きは従来の分散ファイルシステムのようなプロトコルを用いず、データベースアクセス的な処理で構成される。 +ファイルの最小単位をDataGearとすることでファイルデータの扱いをCodeGearで記述できる。 +GearsFSにおけるファイルの読み書きは従来の分散ファイルシステムのようなプロトコルを用いず、データベースアクセス的な処理で構成される。 プロトコルを用いず、最低限なデータアクセスによる通信を構成することで、分散通信技術の見通しをよくする狙いがある。 また、CodeGearはTransactionと言えるのでkeyの書き込みはTransactionに閉じられ、動作が明確になる。 - -ファイルの読み込みの際はQueueに対して順次データレコードのTake操作を繰り返し、連続したレコードからファイルの中身を構築することで実現する。 +ファイルの読み込みの際はQueueに対して順次DataGearのTake操作を繰り返し、連続したDataGearからファイルの中身を構築することで実現する。 つまり、一見としてChristieのファイルはQueueとその要素(Element)として構成される。 データのリストとなるQueueの構造を図\ref{fig:QueueElement}に示す。 @@ -56,7 +56,7 @@ ファイルの読み込み(既存のファイルシステムでのread)を行う際はOutputQueueに対してTake操作を行えば良い。 OutputQueueにはmainQueueの要素が複製されており、OutputQueue内の要素を全てTakeのループにより呼び出す。 -ファイルを呼び出す側は取り出したレコードを順番に読むことでファイルを構築する。 +ファイルを呼び出す側は取り出したDataGearを順番に読むことでファイルを構築する。 GearsOSのファイルは大域的な資源として同時に複数のプロセスから参照が可能になる作りにしたい。 OutputQueueは複数のプロセスからファイル読み込みが行われた際に、データの整合性が失われてしまう危険性がある。 @@ -66,28 +66,28 @@ SingleLinkedな(単純な)Queueを用いることも考えられる。 ファイルに対する書き込みやMainQueueは単一プロセスのみからのアクセスとなるためSingleLinkedなキューで実装する。 -ファイルのレコードは例題中では単純にファイル内文字列を行ごとに区切り、FileString構造体に書き込んだものとなる。 +ファイルデータとなるDataGearは例題中では単純にファイル内文字列を行ごとに区切り、FileString構造体に書き込んだものとなる。 \ref{src:FS}にFileString構造体を示す。 -str部分にファイル内文字列を格納し、レコードが全て送信したことを示すEoFフラグが付属している。 -ファイルレコードはGears側のDataGearとして利用も行えるように、ContextにDataGearとして登録された構造体である。 +str部分にファイル内文字列を格納し、DataGearが全て送信したことを示すEoFフラグが付属している。 +ファイルデータDataGearはGears側のDataGearとして利用も行えるように、ContextにDataGearとして登録された構造体である。 -FileStringはテストに用いられる単純なレコードである。 -実用性のあるレコードを考察した場合、ファイルに変更が加えられた場合Queueに格納するレコードを行順に構成し直す必要性が生じるなど多くの問題が存在する。 +FileStringはテストに用いられる単純な構造体である。 +実用性のあるファイルデータ構造体を考察した場合、ファイルに変更が加えられた場合Queueに格納するDataGearを行順に構成し直す必要性が生じるなど多くの問題が存在する。 また、GearsFSではファイルの型をOSが区別できることを目指しており、 -レコードの型を最適な形に変更することによって複数のファイルの型に対応したい。 +DataGearの型を最適な形に変更することによって複数のファイルの型に対応したい。 例として、テキストデータの場合、gitやMercurialなどのバージョン管理システムのように、 -変更差分をレコードとしてQueueに格納し、QueueのレコードをTopから参照していくことで構築を行う。 +変更差分をファイルデータとしてQueueに格納し、QueueのDataGearをTopから参照していくことで構築を行う。 また、画像ファイルなどファイルの中身の変更が行われない形式は、ファイル内のデータをブロック長に区切り扱うといった手段が考えられるなど、 -ファイルの型に応じてレコードの構造体を任意に構成することができる。 +ファイルの型に応じてDataGearの構造体を任意に構成することができる。 -\lstinputlisting[label=src:FS, caption=例題のレコードとして使われるFileString構造体]{src/FileString.h} +\lstinputlisting[label=src:FS, caption=例題のファイルDataGearとして使われるFileString構造体]{src/FileString.h} \section{WordCount例題} GearsFSのAPIの構成をWordCount例題を通して行った。 WordCount例題とは、指定したファイルの中身を読み取り、文字数と行数列、加えて文字列を出力するという例題である。 -この例題により連続したレコードをQueueから順次読みだす処理を構築した。 +この例題により連続したDataGearをQueueから順次読みだす処理を構築した。 コード\ref{src:WcImpl}にCbCで記述した、Unixファイルに対してWordCountを行うプログラムの一部を示す。 ファイルとWordCountの接続はUNIXのシェルのようにプログラムの外で行われる。 @@ -128,11 +128,6 @@ NodeBは最後にWordCountの結果をRemoteDGMに対してputしOpen側に送信する。 そして、双方のRemoteDGMを閉じることにより通信を終了させる。 -図中ではRemoteDGMを複数作成することにより通信のやりとりを行っているが、 -WordCountでない純粋なファイルの送信などの場合、DGMのSocketが持つAckのみでも通信を構成することが可能である。 -そのためデータの一方的な送受信のみならDGMのペアは一つだけでも通信を行うことができる。 - - \begin{figure}[h] \begin{center} @@ -143,20 +138,18 @@ \end{figure} + \section{GearsOS上のSocket通信} RemoteDGMとLocalDGMの接続の際にはLocalDGMが持つsocketに対してRemoteDGMが接続を行い、 Dataの書き込み先のkeyを指定してsocket経由でコマンドとして送信する。 socketを所有したQueueによるWordCount例題の記述を行うことでGearsOSにおけるsocket通信の実装を行った。 接続元と接続先のsocketは、Queueの作成時に行われ、 -socketへのアクセスはQueueに新しくAPIとして追記を行った。 -ソースコード\ref{src:cQueue}にsocket操作を追加したQueueのInterfaceを示す。 +socketへのアクセスはQueueのAPIであるPut/Take/Peekの際に行われる。 ソースコード\ref{src:LDGMQueue}にLocalDGM側にあたる、Socket付きのQueueのCodeGear:getData部分を示す。 加えてソースコード\ref{src:RDGMQueue}にRemoteDGM側にあたるSocket付きのQueueのCodeGear:sendData部分を示す。 CodeGear:getDataではsocketなどによるError発生時やEoFフラグがあるデータを受信した場合の遷移先を指定する必要ある。 -\lstinputlisting[label=src:cQueue, caption=socketの操作を追加したQueue Interface]{src/TQueue.h} - 二つのQueueはmainプログラムによりsocketの接続が行われ、一方が文字列の送信を行い、もう一方がCount処理を行うことによってWordCountが行われる。 socketはC言語のSocketインターフェースを用いており、 socketのImplementのコンストラクタにあたるcreateLocalDGMQueueにて呼び出され、 @@ -165,16 +158,18 @@ socketはint型で宣言されている。Implementファイルで宣言したsocket変数へsocketを保存をすることで、 Implの実装となるプログラム内ならどのCodeGearからでもsocketの参照が行える。 -Local側のgetDataはAPIとしての呼び出しが可能となっている。socketが受け取ったデータを最終的にdataとしてQueueに対してputを行う。 -Remote側のsendDataはAPIとしては呼び出しは行えず、putAPIが呼び出されQueueへのput処理が終了した後に遷移され、 -putしたDataを接続先のQueueに対して送信する。 +CodeGearであるgetData/sendDataはそれぞれTake/PutAPIを呼び出した際に遷移が行われる。 +getDataはQueueの実際のTake処理の直前に、sendDataはPut処理の直後に遷移されsocketを通じてデータの出し入れを行う。 +sosketへのデータのやりとりはwrite/read関数で行われる。 +send/readでない理由はファイルのデータ通信の相手は他のノードにあるファイルのsocketのみでなく、 +記録デバイスへの書き込みも同様な記述で行うためである。 \lstinputlisting[label=src:LDGQh, caption=LocalDGMQueueで使われるデータ構造体]{src/LocalDGMQueue.h} 現状ではデータの通信に行われるDataGearは全てのDataGearのUnion(共用体)となるData型を用いている。 送信データのサイズをUnion Data型のサイズにしている理由は、sizeof関数で返される値は共用体に含まれる構造体の中で最も大きなメモリサイズを返すためである。 これによりputされたDataGearの型がどのようなものであれ、受け取り側がDataGearの型を正しく選択している限りはデータの整合性を守ることができる。 -しかし、受信側が受け取ったデータレコードの正しい型を把握しているとは限らないため、 +しかし、受信側が受け取ったデータDataGearの正しい型を把握しているとは限らないため、 将来的にはJavaにおけるMessagePackに相当する機能になどによるシリアライズしたデータを送信する形にする。 Socketの処理中に問題が発生した場合はinputDataGearとして指定した\texttt{\_\_}code whenError()として入力されたCodeGearに対して遷移する。 @@ -183,10 +178,25 @@ \newpage{} \lstinputlisting[label=src:RDGMQueue, caption=RemoteDGMQueueのsendData]{src/RemoteDGMQueue.cbc} +Queueによる通信で実装されたWordCount例題を記述した。 +ソースコード\ref{src:WCbyGears}にファイル送信側のmain部分を示す。 +Remote側は行ごとに分割した文字列が無くなるまでDataGearを送信し、なくなったらEoFデータを送る。 +ソースコード\ref{src:WCget}にファイル受信側のmain部分を示す。 +Local側では受け取ったデータのEoFフラグが1になるまでTake処理をループし、EoFが送られてきた場合は結果を出力する。 + +ソースコード\ref{src:wcResult}は Count側で表示される受け取った文字列とWordCountの結果出力である。 + +\lstinputlisting[label=src:WCbyGears, caption=Queueの通信による送信側WordCountのMain]{src/WordCOunt_Remote.cbc} + +\lstinputlisting[label=src:WCget, caption=Queueの通信による受信側WordCountの]{src/Local_test.cbc} + +\lstinputlisting[label=src:wcResult, caption=単一Queueによる簡易なWordCountの出力結果]{src/wcResult.txt} + \section{GearsOSにおけるDataGearManager} -先で述べたSocket付きのQueueは、DataGearであるQueueとSocketが直接結びついているため、 +先で述べたSocket付きのQueueは、GearsOS上でのsocket通信を構成するために記述を行った一例である。 +これはDataGearであるQueueとSocketが直接結びついているため、 一つのDataGearを用いる場合となる最低限の通信しか行えない。 複数のDataGear(key)を用いての通信を構成するためには複数のQueueを蓄えることのできるリストを生成し、 そのリスト自体がsocketを持つ必要がある。 @@ -270,14 +280,14 @@ つまり、図中の黒いノード1から探索を行えば過去のデータのノードが参照でき、 赤いノード1から探索を行えば編集後の木構造を参照することができる。 -ファイル構造体の変更履歴については、ファイルのDataレコードをファイルの変更差分を履歴として保持させる形にすることに加え、 +ファイル構造体の変更履歴については、ファイルのDataGearをファイルの変更差分を履歴として保持させる形にすることに加え、 変更日時を記録させることで実現したい。 -diffコマンドようなファイル差分をレコードにすることにより、gitやMercurialのようなバージョン管理を行う。 -特定の時点のファイルとDirectoryの状態を呼び出す際は、レコードの変更日時を確認し、参照するべきTree構造とレコードの時点まで参照する形となる。 +diffコマンドようなファイル差分をDataGearにすることにより、gitやMercurialのようなバージョン管理を行う。 +特定の時点のファイルとDirectoryの状態を呼び出す際は、DataGearの変更日時を確認し、参照するべきTree構造とDataGearの時点まで参照する形となる。 変更ログデータを定期的に任意または一定期間ごとに別のストレージに保存することでバックアップを実現する。 -また、非破壊的木構造の編集と変更履歴式のデータレコードは変更が行われるたびに、ディレクトリTreeやファイルの容量増加していくという問題が存在する。 +また、非破壊的木構造の編集と変更履歴式のDataGearは変更が行われるたびに、ディレクトリTreeやファイルの容量増加していくという問題が存在する。 この点については任意の期間経過、もしくはユーザの操作により定期的に過去のデータを自動削除もしくは整形することで容量がある程度の削減が望める。 また、近年の電子記録媒体の容量増加に伴い問題の重要性が低下していくことが期待できる。 @@ -308,7 +318,7 @@ par gotoとはGearsOSにおける並列処理構文である。 par gotoによる並列処理ではTaskをContextで表現し、TaskのInputDataGearが揃ったTaskをWorkerで処理を行う。 図\ref{fig:WorkerRun}にpar goto構文による並列処理を示す。 -GearsFSではstreamに対する書き込みや取り出しとqueueに蓄えられたデータレコードの送受信を並列に実行する。 +GearsFSではstreamに対する書き込みや取り出しとqueueに蓄えられたファイルDataGearの送受信を並列に実行する。 当然複数のファイルが同時に通信される場合はそれらも並行に処理が行われる。 現状、GearsOSのpar gotoは実装にいくつか問題点があり、処理速度が比較的遅いことに加え、 @@ -326,7 +336,7 @@ \section{GearsFSの持続性} -GearsFileSystemにおいてファイルは分割されたデータレコードを保持するQueueを持つリストになることを論じた。 +GearsFileSystemにおいてファイルは分割されたDataGearを保持するQueueを持つリストになることを論じた。 メモリ空間上に展開され、変更が行われたデータをSSDなどの持続性を持つデバイスへ保存する場合、 リスト(DataGearManager)の中のQueueである、ファイルデータそのものを保持しているmainDataQueueを格納すれば良い。 持続性デバイスは単なるメモリとして扱ってよく、メモリ上のデータ構造と同様に構築する。
--- a/Paper/chapter/conclusion.tex Thu Feb 17 23:24:09 2022 +0900 +++ b/Paper/chapter/conclusion.tex Mon Feb 28 22:11:26 2022 +0900 @@ -2,8 +2,8 @@ 本研究ではGearsOSに導入するファイルの構造、階層表現と分散ファイルシステムのAPIの設計を行った。 GearsOSにおけるファイルは競合的なアクセスを許した大域的な資源であり、 ファイルは分散フレームワークChristieのDataGearManagerに相当する。 -ファイル内のデータは任意の構造体によるレコード単位に分割されており、ファイルを読み込む場合、レコードを順番にTakeで呼び出せば良い。 -ファイルのデータとなるレコードはプログラマが任意の形の構造体で形成することができ、ファイルの種類によって実装を適切なものに構成することができる。 +ファイル内のデータは任意の構造体によるDataGear単位に分割されており、ファイルを読み込む場合、DataGearを順番にTakeで呼び出せば良い。 +ファイルのデータとなるDataGearはプログラマが任意の形の構造体で形成することができ、ファイルの種類によって実装を適切なものに構成することができる。 ファイルの共有による通信はRemoteDataGearManagerによるploxyに対して操作することで行われる。 そのため、GearsOSでのファイルはファイルそのものであると同時に分散処理の通信とも見ることができる。
--- a/Paper/src/LocalDGMQueue.cbc Thu Feb 17 23:24:09 2022 +0900 +++ b/Paper/src/LocalDGMQueue.cbc Mon Feb 28 22:11:26 2022 +0900 @@ -3,7 +3,7 @@ char send_buf; union Data* recv_data; - recv_size = recv(cQueue->socket, recv_data, sizeof(union Data), 0); + recv_size = read(tQueue->socket, recv_data, sizeof(union Data)); if (recv_size == -1) { printf("recv error\n"); goto whenError(...);
--- a/Paper/src/RemoteDGMQueue.cbc Thu Feb 17 23:24:09 2022 +0900 +++ b/Paper/src/RemoteDGMQueue.cbc Mon Feb 28 22:11:26 2022 +0900 @@ -2,7 +2,7 @@ char recv_buf; int send_size, recv_size; - send_size = send(cQueue->socket, data, sizeof(union Data), 0); + send_size = write(tQueue->socket, data, sizeof(union Data)); if (send_size == -1) { printf("send error\n"); close(cQueue->socket);
--- a/finalSlide/finalSlide.html Thu Feb 17 23:24:09 2022 +0900 +++ b/finalSlide/finalSlide.html Mon Feb 28 22:11:26 2022 +0900 @@ -121,15 +121,16 @@ <!-- _S9SLIDE_ --> <h2 id="研究目的">研究目的</h2> <ul> - <li>GearsOSにより信頼性が裏付けられる、分散ファイルシステムの開発/検証を行いたい</li> - <li>開発物はGearsOSによるAPIレベルなTransactionが実装される + <li>GearsOSにより信頼性が裏付けられる、分散ファイルシステムの開発/検証を行う</li> + <li>GearsOSの処理単位であるDataGearでファイルを構成したい</li> + <li>将来的にAPIやプロセスは定理支援証明系により整合性の検証が行われる</li> + <li>OSレベルでTransactionを持つ <ul> <li>Transactionとはデータ操作の不可分化による整合性の保護</li> <li>従来のアプリでは、ユーザーレベルで実装される</li> </ul> </li> <li>GearsOSが持つTransactionの実用性の検証</li> - <li>将来的にAPIやプロセスは定理支援証明系により整合性の検証が行われる</li> </ul> @@ -140,17 +141,17 @@ <!-- _S9SLIDE_ --> <h2 id="研究目的-1">研究目的</h2> <ul> - <li>分散フレームワークChristieの仕組みを用いた分散ファイルシステムの提案 + <li>分散フレームワークChristieの仕組みを用いた分散ファイルシステムの設計/開発 <ul> <li>純粋なデータの送り合いだけで構成されるシンプルな通信</li> <li>自律分散ファイルシステムを目指したい <ul> - <li>ネットワーク上で複数のプロトコルが使われることによる煩雑性を防ぐ</li> + <li>ネットワーク通信上で複数のプロトコルが送られることによる煩雑性を防ぐ</li> </ul> </li> + <li>通信のデータの整合性の保護はGearsOSが行う</li> </ul> </li> - <li>GearsOSの処理単位であるDataGearでファイルを構成できる</li> </ul> @@ -182,7 +183,7 @@ <div class='slide'> <!-- _S9SLIDE_ --> -<h2 id="スライド発表">スライド発表</h2> +<h2 id="ポスター発表">ポスター発表</h2> <ul> <li>GearsOSとChristieの解説 <ul> @@ -206,7 +207,7 @@ <div class='slide'> <!-- _S9SLIDE_ --> -<h2 id="ポスター発表">ポスター発表</h2> +<h2 id="ポスター発表-1">ポスター発表</h2> <ul> <li>GearsOSのChristie likeなファイルシステムの設計と実装 <ul> @@ -227,346 +228,6 @@ <li>まとめと課題</li> </ul> - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="この先保留">この先保留</h2> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="codegearとdatagear">CodeGearとDataGear</h2> -<ul> - <li>CodeGear - <ul> - <li>実行Codeの単位</li> - <li>入力/出力のDataGearを持つ</li> - <li>goto文(jump命令)で遷移する</li> - <li>割り込みが行われない(atomicity)</li> - </ul> - </li> - <li>DataGear - <ul> - <li>変数にあたり、構造体の型を持つ</li> - </ul> - </li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="codegearとdatagearの関係">CodeGearとDataGearの関係</h2> -<ul> - <li>InputDataGearを受け取って、CodeGearが処理し、OutputDataGearを出力する</li> - <li>OutputDataGearは次のCodeGearのInputDataGearとなる</li> - <li>CodeGear/DataGearはContextというオブジェクトで管理される</li> -</ul> -<div style="text-align: center;"> - <img src="images/cg-dg.pdf" alt="cgdgの関係図" width="600" /> -</div> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="研究概要">研究概要</h2> -<ul> - <li>GearsOSの分散ファイルシステムの設計・実装を行った - <ul> - <li>ファイル構造の設計</li> - <li>ファイルAPIの設計</li> - <li>複数streamを用いたファイル通信とデバイス保存</li> - </ul> - </li> - <li>最低限のデータを送信することにより通信が行える</li> - <li>分散フレームワークChristieの仕組みを利用している</li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="本研究の目的">本研究の目的</h2> -<ul> - <li>分散フレームワークChristieのファイルシステムへの応用 - <ul> - <li>プロトコルを用いず、最低限のデータの送受信で通信を構成する</li> - <li>複雑な分散通信の見通しの改善</li> - <li>自律分散通信を目指した設計</li> - </ul> - </li> - <li>OSレベルなTransactionによるファイル通信記述の検証 - <ul> - <li>GearsOSではAPIをTransactionとして構成できる</li> - <li>従来のファイルシステムはアプリケーションレベルで実装される</li> - </ul> - </li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="gearsos">GearsOS</h2> -<ul> - <li>OSの信頼性の向上と拡張性を目指している</li> - <li>CodeGear/DataGearという単位で記述される</li> - <li>ノーマルレベルとメタレベルを分離して記述できる - <ul> - <li>メタレベル処理を切り替えることで、信頼性検証やデバッグを行う</li> - <li>将来的に本研究の成果物も信頼性の検証を行う</li> - </ul> - </li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="codegearとdatagear-1">CodeGearとDataGear</h2> -<ul> - <li>CodeGear - <ul> - <li>実行Codeの単位</li> - <li>入力/出力のDataGearを持つ</li> - <li>goto文(jump命令)で遷移する</li> - </ul> - </li> - <li>DataGear - <ul> - <li>変数にあたり、構造体の型を持つ</li> - </ul> - </li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="codegearとdatagearの関係-1">CodeGearとDataGearの関係</h2> -<ul> - <li>InputDataGearを受け取って、CodeGearが処理し、OutputDataGearを出力する</li> - <li>OutputDataGearは次のCodeGearのInputDataGearとなる</li> - <li>CodeGear/DataGearはContextというオブジェクトで管理される</li> -</ul> -<div style="text-align: center;"> - <img src="images/cg-dg.pdf" alt="cgdgの関係図" width="600" /> -</div> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="分散フレームワークchristie-1">分散フレームワークChristie</h2> -<ul> - <li>Javaで記述された分散フレームワーク</li> - <li>GearsOSと似たGearという概念を持つ</li> - <li>CodeGearManagerと言うノードがCodeGear/DataGearを管理する - <ul> - <li>DataGearはDataGearManagerと言うデータプールに記録される</li> - </ul> - </li> - <li>DataGearをノード間で送り合うことで通信を行う</li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="christieの通信">Christieの通信</h2> -<ul> - <li>LocalDGM - <ul> - <li>そのノードに対応するデータプール</li> - <li>CodeGearはLocalDGMからDataGearを参照する</li> - </ul> - </li> - <li>RemoteDGM - <ul> - <li>他のノードのLocalDGMに対応するproxy</li> - <li>RemoteDGMに書き込むと対応したLocalDGMに送信される</li> - </ul> - </li> - <li>DataGearManagerの仕組みをGearsOSのファイルに利用する</li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="remotedgmによる通信">RemoteDGMによる通信</h2> -<ul> - <li>任意の相手のRemoteDGMを作成することで接続が形成される</li> - <li>RemoteDGMに書き込むと相手のLocalDGMに書き込みが行われる</li> -</ul> -<div style="text-align: center;"> - <img src="images/Remote_DataGearManager.pdf" alt="RemoteDGMの関係図" width="550" /> -</div> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="ポスター発表概要">ポスター発表概要</h2> -<ul> - <li>Christieの仕組みを用いたファイルシステム設計/実装の解説 - <ul> - <li>QueueとTreeを用いたファイル構造</li> - <li>ファイルAPI - <ul> - <li>Put/Take/Peek</li> - </ul> - </li> - <li>複数socketを用いたファイル通信の構成</li> - <li>WordCount例題</li> - </ul> - </li> - <li>まとめと課題</li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="まとめ">まとめ</h2> -<ul> - <li>GearsOSの通信を含めたファイルシステムの設計・開発を行った - <ul> - <li>DataGear単位によるファイル操作</li> - <li>複数のstreamを用いた通信の設計 - <ul> - <li>現時点では単一streamによる通信のみ開発済み</li> - </ul> - </li> - </ul> - </li> - <li>課題 - <ul> - <li>WordCount例題の再現</li> - <li>API/プロセスの信頼性や性能の調査</li> - </ul> - </li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="gearsosのファイルシステム">GearsOSのファイルシステム</h2> -<ul> - <li>ファイルデータの最小単位はDataGearとなる</li> - <li>ファイルデータとなるDataGearはQueueに格納される</li> - <li>APIはPut/Take/Peekの三つで操作する</li> -</ul> -<div style="text-align: center;"> - <img src="images/QueueElement.pdf" alt="Queue" width="800" /> -</div> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="gearsosにおけるファイル">GearsOSにおけるファイル</h2> -<ul> - <li>ファイルは複数のQueueを持つ赤黒木である</li> - <li>Queueはkeyでアクセスされる</li> - <li>Queueはstreamの役割を持つ</li> -</ul> - -<div style="text-align: center;"> - <img src="images/newGearsFile.pdf" alt="Queue" width="400" /> -</div> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="ファイルによる通信の構成">ファイルによる通信の構成</h2> -<ul> - <li>GearsOSのファイルは通信も担当する</li> - <li>通信先のファイルのproxyを生成し通信する</li> - <li>proxyに対してデータを書き込むことで通信が行われる</li> - <li>WordCount例題を通して設計を行った</li> -</ul> -<div style="text-align: center;"> - <img src="images/slideGearsWC.pdf" alt="Queue" width="500" /> -</div> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="gearsosの分散ファイルシステム">GearsOSの分散ファイルシステム</h2> -<ul> - <li>GearsOSのファイルは通信の役割も持つ</li> - <li>遠隔上のファイルに対応するproxyを作成して通信を行う - <ul> - <li>対象ファイルとproxyはsocketで接続される</li> - <li>proxyの操作はLocalなファイルと相違なく行える</li> - </ul> - </li> - <li>記録デバイスへの保存も同様な仕組みで行う</li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="gearsfsの展望">GearsFSの展望</h2> -<ul> - <li>ノードの配線を担当するTopologyManagerの実装 - <ul> - <li>参加表明したノードを任意の形のTopologyへ配線する</li> - </ul> - </li> - <li>将来的にAPIと通信プロセスは定理支援証明系Agdaで検証を行う</li> - <li>複数streamにより制御を行う分散ファイル通信の検証</li> - <li>GearsOSによるOSレベルTransactionの信頼性/実用性調査 - <ul> - <li>従来ではアプリケーションレベルにより実装される</li> - </ul> - </li> -</ul> - </div>
--- a/finalSlide/finalSlide.md Thu Feb 17 23:24:09 2022 +0900 +++ b/finalSlide/finalSlide.md Mon Feb 28 22:11:26 2022 +0900 @@ -18,19 +18,20 @@ ## 研究目的 -- GearsOSにより信頼性が裏付けられる、分散ファイルシステムの開発/検証を行いたい -- 開発物はGearsOSによるAPIレベルなTransactionが実装される +- GearsOSにより信頼性が裏付けられる、分散ファイルシステムの開発/検証を行う +- GearsOSの処理単位であるDataGearでファイルを構成したい +- 将来的にAPIやプロセスは定理支援証明系により整合性の検証が行われる +- OSレベルでTransactionを持つ - Transactionとはデータ操作の不可分化による整合性の保護 - 従来のアプリでは、ユーザーレベルで実装される - GearsOSが持つTransactionの実用性の検証 -- 将来的にAPIやプロセスは定理支援証明系により整合性の検証が行われる ## 研究目的 -- 分散フレームワークChristieの仕組みを用いた分散ファイルシステムの提案 +- 分散フレームワークChristieの仕組みを用いた分散ファイルシステムの設計/開発 - 純粋なデータの送り合いだけで構成されるシンプルな通信 - 自律分散ファイルシステムを目指したい - - ネットワーク上で複数のプロトコルが使われることによる煩雑性を防ぐ -- GearsOSの処理単位であるDataGearでファイルを構成できる + - ネットワーク通信上で複数のプロトコルが送られることによる煩雑性を防ぐ + - 通信のデータの整合性の保護はGearsOSが行う ## 分散フレームワークChristie - 当研究室が開発する、Javaで書かれた分散フレームワークである @@ -41,7 +42,7 @@ - DataGearManagerにはLocalなものとRemoteのものが存在する - GearsFSはDataGearManagerの仕組みを導入することで通信する -## スライド発表 +## ポスター発表 - GearsOSとChristieの解説 - DataGearManagerの仕組み - Chlistie likeなファイルシステムの設計の解説 @@ -63,151 +64,3 @@ - 複数streamを用いたファイル通信 - WordCount例題 - まとめと課題 - -## この先保留 - -## CodeGearとDataGear -- CodeGear - - 実行Codeの単位 - - 入力/出力のDataGearを持つ - - goto文(jump命令)で遷移する - - 割り込みが行われない(atomicity) -- DataGear - - 変数にあたり、構造体の型を持つ - -## CodeGearとDataGearの関係 -- InputDataGearを受け取って、CodeGearが処理し、OutputDataGearを出力する -- OutputDataGearは次のCodeGearのInputDataGearとなる -- CodeGear/DataGearはContextというオブジェクトで管理される -<div style="text-align: center;"> - <img src="images/cg-dg.pdf" alt=cgdgの関係図 width="600"> -</div> - -## 研究概要 -- GearsOSの分散ファイルシステムの設計・実装を行った - - ファイル構造の設計 - - ファイルAPIの設計 - - 複数streamを用いたファイル通信とデバイス保存 -- 最低限のデータを送信することにより通信が行える -- 分散フレームワークChristieの仕組みを利用している - - - -## 本研究の目的 -- 分散フレームワークChristieのファイルシステムへの応用 - - プロトコルを用いず、最低限のデータの送受信で通信を構成する - - 複雑な分散通信の見通しの改善 - - 自律分散通信を目指した設計 -- OSレベルなTransactionによるファイル通信記述の検証 - - GearsOSではAPIをTransactionとして構成できる - - 従来のファイルシステムはアプリケーションレベルで実装される - -## GearsOS -- OSの信頼性の向上と拡張性を目指している -- CodeGear/DataGearという単位で記述される -- ノーマルレベルとメタレベルを分離して記述できる - - メタレベル処理を切り替えることで、信頼性検証やデバッグを行う - - 将来的に本研究の成果物も信頼性の検証を行う - -## CodeGearとDataGear -- CodeGear - - 実行Codeの単位 - - 入力/出力のDataGearを持つ - - goto文(jump命令)で遷移する -- DataGear - - 変数にあたり、構造体の型を持つ - -## CodeGearとDataGearの関係 -- InputDataGearを受け取って、CodeGearが処理し、OutputDataGearを出力する -- OutputDataGearは次のCodeGearのInputDataGearとなる -- CodeGear/DataGearはContextというオブジェクトで管理される -<div style="text-align: center;"> - <img src="images/cg-dg.pdf" alt=cgdgの関係図 width="600"> -</div> - - -## 分散フレームワークChristie -- Javaで記述された分散フレームワーク -- GearsOSと似たGearという概念を持つ -- CodeGearManagerと言うノードがCodeGear/DataGearを管理する - - DataGearはDataGearManagerと言うデータプールに記録される -- DataGearをノード間で送り合うことで通信を行う - -## Christieの通信 -- LocalDGM - - そのノードに対応するデータプール - - CodeGearはLocalDGMからDataGearを参照する -- RemoteDGM - - 他のノードのLocalDGMに対応するproxy - - RemoteDGMに書き込むと対応したLocalDGMに送信される -- DataGearManagerの仕組みをGearsOSのファイルに利用する - -## RemoteDGMによる通信 -- 任意の相手のRemoteDGMを作成することで接続が形成される -- RemoteDGMに書き込むと相手のLocalDGMに書き込みが行われる -<div style="text-align: center;"> - <img src="images/Remote_DataGearManager.pdf" alt="RemoteDGMの関係図" width="550"> -</div> - - -## ポスター発表概要 -- Christieの仕組みを用いたファイルシステム設計/実装の解説 - - QueueとTreeを用いたファイル構造 - - ファイルAPI - - Put/Take/Peek - - 複数socketを用いたファイル通信の構成 - - WordCount例題 -- まとめと課題 - - - - -## まとめ -- GearsOSの通信を含めたファイルシステムの設計・開発を行った - - DataGear単位によるファイル操作 - - 複数のstreamを用いた通信の設計 - - 現時点では単一streamによる通信のみ開発済み -- 課題 - - WordCount例題の再現 - - API/プロセスの信頼性や性能の調査 - -## GearsOSのファイルシステム -- ファイルデータの最小単位はDataGearとなる -- ファイルデータとなるDataGearはQueueに格納される -- APIはPut/Take/Peekの三つで操作する -<div style="text-align: center;"> - <img src="images/QueueElement.pdf" alt=Queue width="800"> -</div> - -## GearsOSにおけるファイル -- ファイルは複数のQueueを持つ赤黒木である -- Queueはkeyでアクセスされる -- Queueはstreamの役割を持つ - -<div style="text-align: center;"> - <img src="images/newGearsFile.pdf" alt=Queue width="400"> -</div> - -## ファイルによる通信の構成 -- GearsOSのファイルは通信も担当する -- 通信先のファイルのproxyを生成し通信する -- proxyに対してデータを書き込むことで通信が行われる -- WordCount例題を通して設計を行った -<div style="text-align: center;"> - <img src="images/slideGearsWC.pdf" alt=Queue width="500"> -</div> - -## GearsOSの分散ファイルシステム -- GearsOSのファイルは通信の役割も持つ -- 遠隔上のファイルに対応するproxyを作成して通信を行う - - 対象ファイルとproxyはsocketで接続される - - proxyの操作はLocalなファイルと相違なく行える -- 記録デバイスへの保存も同様な仕組みで行う - -## GearsFSの展望 -- ノードの配線を担当するTopologyManagerの実装 - - 参加表明したノードを任意の形のTopologyへ配線する -- 将来的にAPIと通信プロセスは定理支援証明系Agdaで検証を行う -- 複数streamにより制御を行う分散ファイル通信の検証 -- GearsOSによるOSレベルTransactionの信頼性/実用性調査 - - 従来ではアプリケーションレベルにより実装される
--- a/finalSlide/finalSlide.pdf.html Thu Feb 17 23:24:09 2022 +0900 +++ b/finalSlide/finalSlide.pdf.html Mon Feb 28 22:11:26 2022 +0900 @@ -105,15 +105,16 @@ <!-- _S9SLIDE_ --> <h2 id="研究目的">研究目的</h2> <ul> - <li>GearsOSにより信頼性が裏付けられる、分散ファイルシステムの開発/検証を行いたい</li> - <li>開発物はGearsOSによるAPIレベルなTransactionが実装される + <li>GearsOSにより信頼性が裏付けられる、分散ファイルシステムの開発/検証を行う</li> + <li>GearsOSの処理単位であるDataGearでファイルを構成したい</li> + <li>将来的にAPIやプロセスは定理支援証明系により整合性の検証が行われる</li> + <li>OSレベルでTransactionを持つ <ul> <li>Transactionとはデータ操作の不可分化による整合性の保護</li> <li>従来のアプリでは、ユーザーレベルで実装される</li> </ul> </li> <li>GearsOSが持つTransactionの実用性の検証</li> - <li>将来的にAPIやプロセスは定理支援証明系により整合性の検証が行われる</li> </ul> @@ -124,17 +125,17 @@ <!-- _S9SLIDE_ --> <h2 id="研究目的-1">研究目的</h2> <ul> - <li>分散フレームワークChristieの仕組みを用いた分散ファイルシステムの提案 + <li>分散フレームワークChristieの仕組みを用いた分散ファイルシステムの設計/開発 <ul> <li>純粋なデータの送り合いだけで構成されるシンプルな通信</li> <li>自律分散ファイルシステムを目指したい <ul> - <li>ネットワーク上で複数のプロトコルが使われることによる煩雑性を防ぐ</li> + <li>ネットワーク通信上で複数のプロトコルが送られることによる煩雑性を防ぐ</li> </ul> </li> + <li>通信のデータの整合性の保護はGearsOSが行う</li> </ul> </li> - <li>GearsOSの処理単位であるDataGearでファイルを構成できる</li> </ul> @@ -166,7 +167,7 @@ <div class='slide'> <!-- _S9SLIDE_ --> -<h2 id="スライド発表">スライド発表</h2> +<h2 id="ポスター発表">ポスター発表</h2> <ul> <li>GearsOSとChristieの解説 <ul> @@ -190,7 +191,7 @@ <div class='slide'> <!-- _S9SLIDE_ --> -<h2 id="ポスター発表">ポスター発表</h2> +<h2 id="ポスター発表-1">ポスター発表</h2> <ul> <li>GearsOSのChristie likeなファイルシステムの設計と実装 <ul> @@ -211,346 +212,6 @@ <li>まとめと課題</li> </ul> - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="この先保留">この先保留</h2> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="codegearとdatagear">CodeGearとDataGear</h2> -<ul> - <li>CodeGear - <ul> - <li>実行Codeの単位</li> - <li>入力/出力のDataGearを持つ</li> - <li>goto文(jump命令)で遷移する</li> - <li>割り込みが行われない(atomicity)</li> - </ul> - </li> - <li>DataGear - <ul> - <li>変数にあたり、構造体の型を持つ</li> - </ul> - </li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="codegearとdatagearの関係">CodeGearとDataGearの関係</h2> -<ul> - <li>InputDataGearを受け取って、CodeGearが処理し、OutputDataGearを出力する</li> - <li>OutputDataGearは次のCodeGearのInputDataGearとなる</li> - <li>CodeGear/DataGearはContextというオブジェクトで管理される</li> -</ul> -<div style="text-align: center;"> - <img src="images/cg-dg.pdf" alt="cgdgの関係図" width="600" /> -</div> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="研究概要">研究概要</h2> -<ul> - <li>GearsOSの分散ファイルシステムの設計・実装を行った - <ul> - <li>ファイル構造の設計</li> - <li>ファイルAPIの設計</li> - <li>複数streamを用いたファイル通信とデバイス保存</li> - </ul> - </li> - <li>最低限のデータを送信することにより通信が行える</li> - <li>分散フレームワークChristieの仕組みを利用している</li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="本研究の目的">本研究の目的</h2> -<ul> - <li>分散フレームワークChristieのファイルシステムへの応用 - <ul> - <li>プロトコルを用いず、最低限のデータの送受信で通信を構成する</li> - <li>複雑な分散通信の見通しの改善</li> - <li>自律分散通信を目指した設計</li> - </ul> - </li> - <li>OSレベルなTransactionによるファイル通信記述の検証 - <ul> - <li>GearsOSではAPIをTransactionとして構成できる</li> - <li>従来のファイルシステムはアプリケーションレベルで実装される</li> - </ul> - </li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="gearsos">GearsOS</h2> -<ul> - <li>OSの信頼性の向上と拡張性を目指している</li> - <li>CodeGear/DataGearという単位で記述される</li> - <li>ノーマルレベルとメタレベルを分離して記述できる - <ul> - <li>メタレベル処理を切り替えることで、信頼性検証やデバッグを行う</li> - <li>将来的に本研究の成果物も信頼性の検証を行う</li> - </ul> - </li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="codegearとdatagear-1">CodeGearとDataGear</h2> -<ul> - <li>CodeGear - <ul> - <li>実行Codeの単位</li> - <li>入力/出力のDataGearを持つ</li> - <li>goto文(jump命令)で遷移する</li> - </ul> - </li> - <li>DataGear - <ul> - <li>変数にあたり、構造体の型を持つ</li> - </ul> - </li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="codegearとdatagearの関係-1">CodeGearとDataGearの関係</h2> -<ul> - <li>InputDataGearを受け取って、CodeGearが処理し、OutputDataGearを出力する</li> - <li>OutputDataGearは次のCodeGearのInputDataGearとなる</li> - <li>CodeGear/DataGearはContextというオブジェクトで管理される</li> -</ul> -<div style="text-align: center;"> - <img src="images/cg-dg.pdf" alt="cgdgの関係図" width="600" /> -</div> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="分散フレームワークchristie-1">分散フレームワークChristie</h2> -<ul> - <li>Javaで記述された分散フレームワーク</li> - <li>GearsOSと似たGearという概念を持つ</li> - <li>CodeGearManagerと言うノードがCodeGear/DataGearを管理する - <ul> - <li>DataGearはDataGearManagerと言うデータプールに記録される</li> - </ul> - </li> - <li>DataGearをノード間で送り合うことで通信を行う</li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="christieの通信">Christieの通信</h2> -<ul> - <li>LocalDGM - <ul> - <li>そのノードに対応するデータプール</li> - <li>CodeGearはLocalDGMからDataGearを参照する</li> - </ul> - </li> - <li>RemoteDGM - <ul> - <li>他のノードのLocalDGMに対応するproxy</li> - <li>RemoteDGMに書き込むと対応したLocalDGMに送信される</li> - </ul> - </li> - <li>DataGearManagerの仕組みをGearsOSのファイルに利用する</li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="remotedgmによる通信">RemoteDGMによる通信</h2> -<ul> - <li>任意の相手のRemoteDGMを作成することで接続が形成される</li> - <li>RemoteDGMに書き込むと相手のLocalDGMに書き込みが行われる</li> -</ul> -<div style="text-align: center;"> - <img src="images/Remote_DataGearManager.pdf" alt="RemoteDGMの関係図" width="550" /> -</div> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="ポスター発表概要">ポスター発表概要</h2> -<ul> - <li>Christieの仕組みを用いたファイルシステム設計/実装の解説 - <ul> - <li>QueueとTreeを用いたファイル構造</li> - <li>ファイルAPI - <ul> - <li>Put/Take/Peek</li> - </ul> - </li> - <li>複数socketを用いたファイル通信の構成</li> - <li>WordCount例題</li> - </ul> - </li> - <li>まとめと課題</li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="まとめ">まとめ</h2> -<ul> - <li>GearsOSの通信を含めたファイルシステムの設計・開発を行った - <ul> - <li>DataGear単位によるファイル操作</li> - <li>複数のstreamを用いた通信の設計 - <ul> - <li>現時点では単一streamによる通信のみ開発済み</li> - </ul> - </li> - </ul> - </li> - <li>課題 - <ul> - <li>WordCount例題の再現</li> - <li>API/プロセスの信頼性や性能の調査</li> - </ul> - </li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="gearsosのファイルシステム">GearsOSのファイルシステム</h2> -<ul> - <li>ファイルデータの最小単位はDataGearとなる</li> - <li>ファイルデータとなるDataGearはQueueに格納される</li> - <li>APIはPut/Take/Peekの三つで操作する</li> -</ul> -<div style="text-align: center;"> - <img src="images/QueueElement.pdf" alt="Queue" width="800" /> -</div> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="gearsosにおけるファイル">GearsOSにおけるファイル</h2> -<ul> - <li>ファイルは複数のQueueを持つ赤黒木である</li> - <li>Queueはkeyでアクセスされる</li> - <li>Queueはstreamの役割を持つ</li> -</ul> - -<div style="text-align: center;"> - <img src="images/newGearsFile.pdf" alt="Queue" width="400" /> -</div> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="ファイルによる通信の構成">ファイルによる通信の構成</h2> -<ul> - <li>GearsOSのファイルは通信も担当する</li> - <li>通信先のファイルのproxyを生成し通信する</li> - <li>proxyに対してデータを書き込むことで通信が行われる</li> - <li>WordCount例題を通して設計を行った</li> -</ul> -<div style="text-align: center;"> - <img src="images/slideGearsWC.pdf" alt="Queue" width="500" /> -</div> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="gearsosの分散ファイルシステム">GearsOSの分散ファイルシステム</h2> -<ul> - <li>GearsOSのファイルは通信の役割も持つ</li> - <li>遠隔上のファイルに対応するproxyを作成して通信を行う - <ul> - <li>対象ファイルとproxyはsocketで接続される</li> - <li>proxyの操作はLocalなファイルと相違なく行える</li> - </ul> - </li> - <li>記録デバイスへの保存も同様な仕組みで行う</li> -</ul> - - - -</div> - -<div class='slide'> - <!-- _S9SLIDE_ --> -<h2 id="gearsfsの展望">GearsFSの展望</h2> -<ul> - <li>ノードの配線を担当するTopologyManagerの実装 - <ul> - <li>参加表明したノードを任意の形のTopologyへ配線する</li> - </ul> - </li> - <li>将来的にAPIと通信プロセスは定理支援証明系Agdaで検証を行う</li> - <li>複数streamにより制御を行う分散ファイル通信の検証</li> - <li>GearsOSによるOSレベルTransactionの信頼性/実用性調査 - <ul> - <li>従来ではアプリケーションレベルにより実装される</li> - </ul> - </li> -</ul> - </div>
--- a/poster/ikki-poster.graffle/data.plist Thu Feb 17 23:24:09 2022 +0900 +++ b/poster/ikki-poster.graffle/data.plist Mon Feb 28 22:11:26 2022 +0900 @@ -1250,7 +1250,7 @@ \'81\'45\'83\'66\'81\'5b\'83\'5e\'82\'cdQueue\'82\'c9\'95\'db\'91\'b6\'82\'b3\'82\'ea\'82\'e9\ \'81\'45FileAPI\'82\'cdPut/Take/Peek\'82\'cc\'8e\'4f\'8e\'ed\'97\'de\'82\'c6\'82\'c8\'82\'e9\ - \'83\'74\'83\'40\'83\'43\'83\'8b\'82\'cc\'93\'c7\'82\'dd\'8f\'6f\'82\'b5\'82\'cdQueue\'82\'cc\'83\'66\'81\'5b\'83\'5e\'82\'f0\'91\'53\'82\'c4Take\'82\'b7\'82\'e9\ -\'81\'45Queue\'82\'cdCopare and Swap\'82\'aa\'93\'8b\'8d\'da\'82\'b3\'82\'ea\'82\'bd\'82\'e0\'82\'cc\'82\'f0\'8e\'67\'82\'a4}</string> +\'81\'45Copare and Swap\'82\'f0\'8e\'9d\'82\'bf\'81\'41\'95\'a1\'90\'94\'83\'76\'83\'8d\'83\'5a\'83\'58\'82\'a9\'82\'e7\'82\'cc\'83\'41\'83\'4e\'83\'5a\'83\'58\'82\'c9\'91\'ce\'89\'9e\'82\'b7\'82\'e9}</string> <key>VerticalPad</key> <real>0.0</real> </dict> @@ -1913,14 +1913,14 @@ \'81\'45CodeGear\'82\'cd\'93\'fc\'97\'cd/\'8f\'6f\'97\'cd\'82\'c6\'82\'b5\'82\'c4DataGear\'82\'f0\'8e\'f3\'82\'af\'8e\'e6\'82\'e9\ - \'8f\'6f\'97\'cd\'82\'b3\'82\'ea\'82\'bdDataGear\'82\'cd\'8e\'9f\'82\'ccCodeGear\'82\'aa\'93\'fc\'97\'cd\'82\'c6\'82\'b5\'82\'c4\'8e\'f3\'82\'af\'8e\'e6\'82\'e9\ \'81\'45CodeGear\'82\'cc\'8e\'c0\'8d\'73\'92\'bc\'91\'4f\'82\'c6\'92\'bc\'8c\'e3\'82\'cdMeta\'82\'c8CodeGear\'82\'aa\'8c\'c4\'82\'ce\'82\'ea\'82\'e9\ -\'81\'45CodeGear\'82\'cd\'8f\'6f\'97\'cd/\'93\'fc\'97\'cd\'82\'aaDG\'82\'c5\'95\'c2\'82\'b6\'82\'e7\'82\'ea\'82\'c4\'82\'a2\'82\'e9\'82\'bd\'82\'dfatomicity\'82\'f0\'8e\'9d\'82\'c2}</string> +\'81\'45CodeGear\'82\'cd\'8f\'6f\'97\'cd/\'93\'fc\'97\'cd\'82\'aaDG\'82\'c5\'95\'c2\'82\'b6\'82\'c4\'82\'a2\'82\'e9(atomicity)}</string> <key>VerticalPad</key> <real>1</real> </dict> </dict> <dict> <key>Bounds</key> - <string>{{16.493178292069672, 793.66926764166465}, {994.98516845703068, 796.56696725923041}}</string> + <string>{{16.493178292070468, 793.66926764166465}, {994.98516845703068, 796.56696725923041}}</string> <key>Class</key> <string>ShapedGraphic</string> <key>FontInfo</key> @@ -1954,7 +1954,7 @@ <key>Font</key> <string>HiraKakuProN-W3</string> <key>Size</key> - <real>28</real> + <real>30</real> </dict> <key>ID</key> <integer>3753</integer> @@ -1994,7 +1994,7 @@ - \'83\'74\'83\'40\'83\'43\'83\'8b\'82\'cdDataGearManager\'82\'cc\'8e\'64\'91\'67\'82\'dd\'82\'f0\'97\'70\'82\'a2\'81\'41\'92\'ca\'90\'4d\'82\'cd\'83\'74\'83\'40\'83\'43\'83\'8b\'82\'ccproxy\'82\'f0\'92\'ca\'82\'b6\'82\'c4\'8d\'73\'82\'ed\'82\'ea\'82\'e9\ - \'83\'74\'83\'40\'83\'43\'83\'8b\'92\'ca\'90\'4d\'8d\'5c\'90\'ac/\'83\'76\'83\'8d\'83\'5a\'83\'58\'83\'82\'83\'66\'83\'8b\'82\'c6\'82\'b5\'82\'c4WordCount\'97\'e1\'91\'e8\'82\'f0\'90\'dd\'8c\'76, \'8b\'4c\'8f\'71\'82\'f0\'8d\'73\'82\'c1\'82\'bd\ \'81\'45\'89\'db\'91\'e8\ - - \'83\'74\'83\'40\'83\'43\'83\'8b\'82\'cc\'92\'ca\'90\'4d\'90\'da\'91\'b1\'82\'f0\'83\'54\'83\'7c\'81\'5b\'83\'67\'82\'b7\'82\'e9\'8b\'40\'94\'5c\'82\'cc\'8e\'c0\'91\'95(Topology Manager)\ + - \'83\'74\'83\'40\'83\'43\'83\'8b\'82\'cc\'92\'ca\'90\'4d\'90\'da\'91\'b1\'82\'f0\'83\'54\'83\'7c\'81\'5b\'83\'67\'82\'b7\'82\'e9\'8b\'40\'94\'5c\'82\'cc\'8e\'c0\'91\'95\ - \'83\'74\'83\'40\'83\'43\'83\'8b\'82\'cc\'83\'41\'83\'4e\'83\'5a\'83\'58\'8c\'a0\'8c\'c0\'82\'c8\'82\'c7\'83\'5a\'83\'4c\'83\'85\'83\'8a\'83\'65\'83\'42\'82\'cc\'8e\'c0\'91\'95\ - \'92\'e8\'97\'9d\'8e\'78\'89\'87\'8f\'d8\'96\'be\'8c\'6eAgda\'82\'c9\'82\'e6\'82\'e9\'90\'4d\'97\'8a\'90\'ab\'82\'cc\'8c\'9f\'8f\'d8}</string> <key>VerticalPad</key> @@ -2796,14 +2796,14 @@ {\*\expandedcolortbl;;} \pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\slleading160\pardirnatural\partightenfactor0 -\f0\fs60 \cf0 \'81\'45\'95\'aa\'8e\'55\'83\'74\'83\'8c\'81\'5b\'83\'80\'83\'8f\'81\'5b\'83\'4eChristie\'82\'cc\'8d\'5c\'90\'ac\'82\'f0\'83\'74\'83\'40\'83\'43\'83\'8b\'83\'56\'83\'58\'83\'65\'83\'80\'82\'c9\'89\'9e\'97\'70\'82\'b7\'82\'e9\ - - Christie\'82\'cc\'8e\'64\'91\'67\'82\'dd\'82\'f0\'97\'70\'82\'a2\'82\'bd\'95\'aa\'8e\'55\'83\'74\'83\'40\'83\'43\'83\'8b\'83\'56\'83\'58\'83\'65\'83\'80\'82\'cc\'92\'f1\'88\'c4\ +\f0\fs60 \cf0 \'81\'45Christie\'82\'cc\'8e\'64\'91\'67\'82\'dd\'82\'f0\'97\'70\'82\'a2\'82\'bd\'95\'aa\'8e\'55\'83\'74\'83\'40\'83\'43\'83\'8b\'83\'56\'83\'58\'83\'65\'83\'80\'82\'cc\'92\'f1\'88\'c4\ - \'8d\'c5\'92\'e1\'8c\'c0\'82\'cc\'83\'66\'81\'5b\'83\'5e\'8f\'91\'82\'ab\'8d\'9e\'82\'dd\'82\'c9\'82\'e6\'82\'e8\'83\'6c\'83\'62\'83\'67\'83\'8f\'81\'5b\'83\'4e\'82\'cc\'8c\'a9\'92\'ca\'82\'b5\'82\'f0\'8a\'6d\'95\'db\'82\'b7\'82\'e9\ - \'8e\'a9\'97\'a7\'95\'aa\'8e\'55\'82\'c8\'95\'aa\'8e\'55\'83\'74\'83\'40\'83\'43\'83\'8b\'83\'56\'83\'58\'83\'65\'83\'80\'82\'f0\'96\'da\'8e\'77\'82\'b5\'82\'bd\'82\'a2\ \'81\'45\'83\'74\'83\'40\'83\'43\'83\'8b\'91\'80\'8d\'ec, \'92\'ca\'90\'4d\'82\'cdDataGear\'82\'c6\'82\'a2\'82\'a4\'92\'50\'88\'ca\'82\'c5\'8d\'73\'82\'ed\'82\'ea\'82\'e9\ + - GearsOS\'82\'c5\'82\'cc\'90\'4d\'97\'8a\'90\'ab\'8c\'9f\'8f\'d8\'82\'f0\'8d\'73\'82\'a2\'82\'bd\'82\'a2\ \'81\'45Transaction\'82\'cdGearsOS\'82\'c9\'82\'e6\'82\'e8API\'83\'8c\'83\'78\'83\'8b\'82\'c5\'8e\'c0\'91\'95\'82\'b7\'82\'e9\ - - \'83\'41\'83\'76\'83\'8a\'82\'cc\'93\'79\'91\'e4\'82\'c6\'82\'c8\'82\'e9OS\'82\'c5\'90\'4d\'97\'8a\'90\'ab\'82\'f0\'95\'db\'8f\'d8\'82\'b5\'82\'bd\'82\'a2\ - - GearsOS\'82\'ccOS\'83\'8c\'83\'78\'83\'8bTransaction\'82\'c9\'82\'e6\'82\'e9\'83\'41\'83\'76\'83\'8a\'8a\'4a\'94\'ad\'82\'cc\'8c\'9f\'8f\'d8}</string> + - GearsOS\'82\'ccOS\'83\'8c\'83\'78\'83\'8bTransaction\'82\'c9\'82\'e6\'82\'e9\'83\'41\'83\'76\'83\'8a\'8a\'4a\'94\'ad\'82\'cc\'8c\'9f\'8f\'d8\ +\'81\'45\'83\'6f\'83\'62\'83\'4e\'83\'41\'83\'62\'83\'76\'82\'c8\'82\'c7\'8f\'5d\'97\'88\'82\'c5\'82\'cd\'83\'41\'83\'76\'83\'8a\'82\'aa\'8e\'9d\'82\'c2\'8b\'40\'94\'5c\'82\'f0OS\'82\'c9\'8e\'e6\'82\'e8\'8d\'9e\'82\'dd\'82\'bd\'82\'a2}</string> <key>VerticalPad</key> <real>1</real> </dict> @@ -3154,7 +3154,7 @@ <key>MasterSheets</key> <array/> <key>ModificationDate</key> - <string>2022-02-17 14:15:28 +0000</string> + <string>2022-02-17 23:09:33 +0000</string> <key>Modifier</key> <string>一木貴裕</string> <key>NotesVisible</key> @@ -3185,7 +3185,7 @@ <key>NSPaperName</key> <array> <string>string</string> - <string>874F2774-D3ED-49A0-9D49-F6B2447C7740</string> + <string>91D80173-86E4-480F-A5DA-E8A8B192027B</string> </array> <key>NSPaperSize</key> <array> @@ -3235,7 +3235,7 @@ <key>Expanded_Canvases</key> <array/> <key>Frame</key> - <string>{{1280, -149}, {1920, 988}}</string> + <string>{{1280, -82}, {1920, 988}}</string> <key>ShowInfo</key> <true/> <key>Sidebar</key> @@ -3245,7 +3245,7 @@ <key>TopSlabHeight</key> <real>250</real> <key>VisibleRegion</key> - <string>{{840, 0}, {3216, 1882}}</string> + <string>{{0, 20}, {3216, 1722}}</string> <key>Zoom</key> <real>0.5</real> <key>ZoomValues</key>