Mercurial > hg > Papers > 2022 > ikki-master

changeset 12:2c54886cebef

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
add evaluation
author ichikitakahiro <e165713@ie.u-ryukyu.ac.jp>
date Sun, 30 Jan 2022 04:52:30 +0900
parents a3cda2aa18aa
children 9991e90cff65
files .DS_Store Paper/chapter/0-introduction.tex Paper/chapter/5-Implementation.tex Paper/chapter/6-Evaluation.tex Paper/chapter/abstract.tex Paper/chapter/appendix.tex Paper/chapter/conclusion.tex Paper/chapter/signature.tex Paper/chapter/thanks.tex Paper/images/QueueElement.graffle.graffle Paper/master_paper.pdf Paper/reference.bib Paper/src/ErrorStub.cbc Paper/src/StubProblem.cbc Paper/src/mainDist.cbc Paper/src/missingParGoto.cbc
diffstat 16 files changed, 213 insertions(+), 16 deletions(-) [+]
line wrap: on
line diff
Binary file .DS_Store has changed
--- a/Paper/chapter/0-introduction.tex	Thu Jan 27 22:49:44 2022 +0900
+++ b/Paper/chapter/0-introduction.tex	Sun Jan 30 04:52:30 2022 +0900
@@ -1,4 +1,4 @@
-\chapter{要旨}
+\chapter{GearsOSにおけるファイルシステム}
 コンピュータにおけるファイルシステムは必要不可欠な存在であると言える。
 コンピュータで行われる計算やそれに使われるデータは全て記憶装置上にファイルとして保持され、
 ファイルという概念なしにはユーザーがコンピュータ上で用いられる資源の管理はほぼ不可能であると言える。
--- a/Paper/chapter/5-Implementation.tex	Thu Jan 27 22:49:44 2022 +0900
+++ b/Paper/chapter/5-Implementation.tex	Sun Jan 30 04:52:30 2022 +0900
@@ -162,7 +162,7 @@
 送信データのサイズをUnion Data型のサイズにしている理由は、sizeof関数で返される値は共用体に含まれる構造体の中で最も大きなメモリサイズを返すためである。
 これによりputされたDataGearの型がどのようなものであれ、受け取り側がDataGearの型を正しく選択している限りはデータの整合性を守ることができる。
 しかし、受信側が受け取ったデータレコードの正しい型を把握しているとは限らないため、
-将来的にはmessagePackなどによるシリアライズしたデータを送信する形にする。
+将来的にはJavaにおけるmessagePackに相当する機能になどによるシリアライズしたデータを送信する形にする。
 Socketの処理中に問題が発生した場合はinputDataGearとして指定した\texttt{\_\_}code whenError()として入力されたCodeGearに対して遷移する。
 
 
@@ -198,7 +198,7 @@
 
 \begin{figure}[h]
     \begin{center}
-        \includegraphics[width=180mm]{./images/GearsDGM.pdf}
+        \includegraphics[width=150mm]{./images/newGearsFile.pdf}
     \end{center}
     \caption{GearsOSにおけるファイル(DGM)}
     \label{fig:GearsDGM}
@@ -207,7 +207,6 @@
 
 
 
-
 \section{ディレクトリシステム}
 本研究と並行する形で又吉雄斗によるGearsFileSystemのディレクトリ構造の構築が行われている。[論文No.]
 GearsFSのディレクトリシステムはUnixOSのディレクトリシステムのinodeの仕組みを用いて再現することを試みている。
@@ -301,4 +300,9 @@
 \end{figure}
 
 
-\section{GearsOSの持続性}
+\section{GearsFSの持続性}
+GearsFileSystemにおいてファイルは分割されたデータレコードを保持するQueueを持つリストになることを論じた。
+メモリ空間上に展開され、変更が行われたデータをSSDなどの持続性を持つデバイスへ保存する場合、
+リスト(DataGearManager)の中のQueueである、ファイルデータそのものを保持しているmainDataQueueを格納すれば良い。
+持続性デバイスは単なるメモリとして扱ってよく、メモリ上のデータ構造と同様に構築する。
+逆にメモリ上へファイルを展開する場合、デバイス上に保存されているQueueを呼び出し、メモリ上でLocalDataGearManagerとして構築すれば良い。
--- a/Paper/chapter/6-Evaluation.tex	Thu Jan 27 22:49:44 2022 +0900
+++ b/Paper/chapter/6-Evaluation.tex	Sun Jan 30 04:52:30 2022 +0900
@@ -1,5 +1,67 @@
-\chapter{GearsOSとそのファイルシステムの評価}
-\section{GearsFileSystemのAPI}
-GearsOSに導入する分散ファイルシステムのAPIの設計を行った。
-GearsOSのファイルシステムは大域的な資源として同時に複数のプロセスからの参照が可能である。
-GearsFSはデータをレコードとして扱うことができ、
+\chapter{評価}
+当研究は純粋なGearsOSを用いて実装されるプロジェクトとしては初めてのものとなっている。
+本性ではファイルシステムの構築を通したGearsOSの評価を行う。
+
+
+
+\section{トランスコンパイラによるstubCodeGearの語生成}
+GearsOSの最大の特徴としてノーマルレベルとメタレベルのプログラムを分離して記述をする必要があるという点が存在する。
+メタレベルのプログラムは現状、Perlスクリプトを用いたトランスコンパイラにより自動生成されている形となっている。
+トランスコンパイラにより生成されるメタレベルなプログラムの中で最も重要な部分として、DataGearの受け渡しを担当するstubCodeGearの生成がある。
+本研究にて行われたGearsOSによるプログラムの記述の上で最も目立った問題点として、stubCodeGearの自動生成部分の仕様とバグが挙げられる。
+
+別のInterfaceを継承したCodeGearからDataGearの受け取りたい場合に、自動生成されたstubCodeGearにバグが生じるという問題点がある。
+
+ソースコード\ref{src:spro}にQueueからDataGearを受け渡しているstubCodeGearとその遷移前と遷移先のCodeGearを示す。
+このプログラムではTask2にてlocalDGMQueueに対してCodeGear:takeに遷移、Queueのtake処理によって取り出したFileString型のstringを
+Task3\texttt{\_}stubにて呼び出し、Task3へ引き渡している。
+12行目ではGearefコマンドにてTQueue構造体の中の変数dataをFileString型のstringに格納している。
+Gearef(context, TQueue)\texttt{->}dataには遷移前のCodeGearにて、take操作でQueueから取り出されたデータが格納されている。
+このプログラムは正常に動作するが、問題点としてTask3\texttt{\_}stubは自動生成が行われたものでなく、手動で記述されていることが挙げられる。
+
+ソースコード\ref{src:serro}にプログラマが記述したものではなく、トランスコンパイラにより自動生成されたエラーのあるTask3のstubCodeGearを示す。
+この出力されたstubCodeGearの場合、実際にプログラムが実行された場合、Segmentation Faultを起こしてプログラムが終了してしまう。
+string変数に格納したい、Queueから取り出されたデータの保管場所をstubCodeGearがうまく指定できていないためである。
+これはFileString構造体はGearsOS内でInterfaceとして見なされており、
+トランスコンパイラは変数の型を見てGearefコマンドの指定先をContextの保管場所としているために発生しているミスコードとなる。
+実際にQueueから取り出されたデータが保存さている場所への参照はGearef(context, TQueue)\texttt{->}dataであるためこれを指定するのが正しい。
+
+\lstinputlisting[label=src:spro, caption=takeCodeGearから遷移されるstubCodeGear]{src/StubProblem.cbc}
+
+\lstinputlisting[label=src:serro, caption=自動生成にて出力されたTask3のstubCodeGear]{src/ErrorStub.cbc}
+
+結論としてトランスコンパイラによる自動生成されたstubCodeGearは、別Interface上のCodeGearからDataGearを継承する場合、
+どのInterfaceからDataGearを呼び出せばいいか判断ができないことが分かった。
+この問題はstubCodeGearをプログラマが記述することにより解決できるが、
+GearsOSの理想はプログラマが特別な意図を持たない限りはstubCodeGearは記述の必要がないことが望ましい。
+加えて、CodeGearの処理が同一であっても、遷移前CodeGearが継承しているInterfaceが異っている場合、複数のCodeGearを記述しなくてはならない。
+
+この問題を解決する案として、ContextはstubCodeGearに参照される際に、遷移前のCodeGearが継承しているInterfaceをなんらかの変数などに記憶させるといったことが考えられる。
+DataGearは基本的に遷移する直前のCodeGearから引き継ぐ場合が多いため、直前のCodeGearのInterfaceへのGearefコマンドが行える形にすることが望ましい。
+
+\section{par goto構文のバグ}
+GearsFileSystemのAPI開発の上でpar goto構文を使った並列処理の利用を試みた。
+しかし、par goto構文から自動生成されるメタレベルなコード出力の誤りやTaskの終了を示す\texttt{\_\_}exitが機能しないといった問題が発生した。
+これらの問題はGearsOSの記述方法に統制が取られていないことが原因として挙げられる。
+
+ソースコード\ref{src:mainDist}にpar goto構文を用いているCodeGearを示す。
+加えてソースコード\ref{src:misspar}にソースコード\ref{src:mainDist}をトランスコンパイルした.cプログラムを示す。
+
+この問題点の一つとしてTaskの終了を示すCodeGearである\texttt{\_\_}exitが機能しないという問題がある。
+ソースコード\ref{src:mainDist}の4,5行目では本体par gotoにてTask:countUp->eNumが終了次第、
+Taskを処理したWorkerを解放せるための\texttt{\_\_}exitをnext\texttt{\_}codeとして指定したい。
+しかし、下記のコードではトランスコンパイルの時点でエラーを起こし、プログラムのコンパイルが行えない。
+
+6行目は別の並列プログラムtwiceでのpar gotoの記述である。異なる点として遷移先のCodeGearがInterfaceを継承したクラスに記述されたものでなく、
+そのCodeGear内で利用されるクラスをInputDataGearとして指定していることにある。
+この記述の場合、\texttt{\_\_}exitは問題なく動作することができるが、GearsOSに実装されたQueueやTreeといった多くのプログラムはInterfaceを継承したクラスとして実装されている。
+そのため従来のプログラムをTaskとして利用することが難しくなっている。
+
+加えてトランスコンパイラのバグも確認されている。
+クラス内部へ記述されたCodeGearへのpar gotoはInputCodeGearが存在する場合、
+ソースコード\ref{src:misspar}の15, 33行目のInterfaceのGET\texttt{\_}METAが生成されなくなってしまう。
+
+
+\lstinputlisting[label=src:mainDist, caption=takeCodeGearから遷移されるstubCodeGear]{src/mainDist.cbc}
+
+\lstinputlisting[label=src:misspar, caption=自動生成にて出力されたTask3のstubCodeGear]{src/missingParGoto.cbc}
--- a/Paper/chapter/abstract.tex	Thu Jan 27 22:49:44 2022 +0900
+++ b/Paper/chapter/abstract.tex	Sun Jan 30 04:52:30 2022 +0900
@@ -1,5 +1,30 @@
 \chapter*{要旨}
+当研究室ではOSの信頼性の検証を目的としたOSであるGearsOSを開発している。GearsOSはユーザレベルとメタレベルを分離して記述を行うことで拡張性と信頼性の補償を目指している。
+GearsOSはContinuation based C(以下CbC)で記述されており,Gearというプログラミング概念を持つ。
+GearsOSは現在開発途上であるため、現在は言語フレームワークとして実装されている。OSとして起動するためにこれから実装が必要な機能が多く存在しており、その中の一つとして分散ファイルシステムが挙げられる。
+GearsOSの分散ファイルシステムでは、当研究室が開発している分散フレームワークChristieの仕組みを用いる。
+ChrisitieはGearsOSと異なるGearというプログラミング概念をもち、DataGearManagerというDataPoolをノード間でsocket接続することで通信を実装している。
+GearsOSのファイルはDataGearManagerと同様な構成として、ファイルであると同時に通信処理そのものに相当する。
+
+GearsOSのファイルシステムは従来のファイルシステムの問題点を解決した実装を取り込めるような構成にしたい。
+従来のファイルシステムの問題点の一部として、ファイルシステムはデータベースでなくレコード単位での操作が行えない、バックアップや証明書などの機能はアプリケーションに依存している点などが挙げられる。
+将来的な実装を鑑みてファイルシステムの実装を行った。
+
+また、GearsOSを純粋に利用して記述を行うプロジェクトは本研究が初めてとなる。
+分散ファイルシステムの構成を行うと同時に、GearsOSの言語フレームワークとしての評価と検討を行った。
 
 
 \chapter*{Abstract}
-hogefuga
+In our laboratory, we are developing GearsOS, an operating system for verifying the reliability of operating systems, which aims to compensate for scalability and reliability by separating user-level and meta-level descriptions.
+GearsOS is written in Continuation based C (CbC) and has the programming concept of Gears.
+Since GearsOS is still under development, it is currently implemented as a language framework, and there are many functions that need to be implemented in order to run as an OS, one of which is a distributed file system.
+The distributed file system of GearsOS uses the distributed framework Christie, which is developed by our laboratory.
+Christie has a different programming concept called "Gear" from GearsOS, and implements communication by connecting a DataPool called DataGearManager to a socket between nodes.
+The files in GearsOS are structured in the same way as DataGearManager, so they are not only files but also correspond to the communication process itself.
+
+The file system of GearsOS should be configured in such a way that it can incorporate implementations that solve the problems of conventional file systems.
+Some of the problems with conventional file systems are that they are not databases and cannot be manipulated on a record-by-record basis, and that functions such as backup and certificates are dependent on the application.
+We implemented the file system in view of future implementations.
+
+In addition, this is the first project in which GearsOS is purely used for description.
+At the same time as constructing the distributed file system, we evaluated and examined GearsOS as a language framework.
--- a/Paper/chapter/appendix.tex	Thu Jan 27 22:49:44 2022 +0900
+++ b/Paper/chapter/appendix.tex	Sun Jan 30 04:52:30 2022 +0900
@@ -2,3 +2,7 @@
 \chapter{研究会業績}
 
 \section{研究会発表資料}
+\begin{itemize}
+  \item 分散フレームワークChristieによるBlock chainの実装 一木貴裕, 赤堀貴一, 河野真治  情報処理学会システムソフトウェアとオペレーティング・システム研究会(OS), May, 2019
+  \item GearsOS の分散ファイルシステムの設計 一木貴裕, 河野真治  情報処理学会システムソフトウェアとオペレーティング・システム研究会(OS), June, 2021
+\end{itemize}
--- a/Paper/chapter/conclusion.tex	Thu Jan 27 22:49:44 2022 +0900
+++ b/Paper/chapter/conclusion.tex	Sun Jan 30 04:52:30 2022 +0900
@@ -1,4 +1,27 @@
-\chapter{まとめ}
-\section{総括}
+\chapter{結論}
+本研究ではGearsOSに導入するファイルの構造、階層表現と分散ファイルシステムのAPIの設計を行った。
+GearsOSにおけるファイルは競合的なアクセスを許した大域的な資源であり、
+ファイルは分散フレームワークChristieのDataGearManagerに相当する。
+ファイル内のデータは任意の構造体によるレコード単位に分割されており、ファイルを読み込む場合、レコードを順番にTakeで呼び出せば良い。
+
+ファイルの共有による通信はRemoteDataGearManagerによるploxyに対して操作することで行われる。
+そのため、GearsOSでのファイルはファイルそのものであると同時に分散処理の通信とも見ることができる。
+その通信はWordCount例題の記述によって行い、GearsOSにおけるsocket通信の有用性の確認を行った。
+
+また、ファイルは赤黒木によるディレクトリによって階層が構築され、ファイル、ディレクトリは非破壊的な変更が行われる。
+そのため、変更の履歴はOSが参照できる形で残されており、定期的なバックアップや履歴データの削除などの機能を作成することで
+アプリケーションに頼らず、OSがバックアップを担当することができる。
+
 
 \section{今後の課題}
+ファイルの通信接続はChristieのTopologyManagerの機能を用いるが、詳細な設計は現時点で行えていない。
+DataGearMangerによる接続形成をTopologyManagerに一任する形にすることで、本来は煩雑な処理が必要となる通信の接続を簡潔に行いたい。
+しかしChristieのTopologyManagerはあくまで分散フレームワークであるChristieに向けて開発されたものである。
+そのため、ChristieのTopologyManagerを基準にしながら、分散ファイルシステムに向けた仕様を考案していく必要がある。
+例えば、TopologyManagerは参加を表明したノードを任意の形のTopologyに構成するというものだが、
+CodeGearManagerの存在しないGearsFSでは、RemoteDGMによる通信接続に加え、要求されたファイルを見つけ出しメモリ上へ呼び出すという機能を加える必要がある。
+
+ファイルシステムの基幹となるディレクトリやファイル通信の設計は行えている。
+しかし、ファイルシステムのアクセス権限やシェル上での実行などはこれからの実装が必要となる。
+ファイルのメタデータ生成やメモリの効率化などの問題はmetaCodeGear部分で行うことにより、
+ノーマルレベルのプログラミングでは意識する必要なくプログラミングが行える構成としたい。
--- a/Paper/chapter/signature.tex	Thu Jan 27 22:49:44 2022 +0900
+++ b/Paper/chapter/signature.tex	Sun Jan 30 04:52:30 2022 +0900
@@ -15,11 +15,11 @@
 
 		\vspace{1cm}
 		\underline{\hspace{6cm}印}\\
-		（副\hspace{1em}査）\hspace{1em}山田　孝治
+		（副\hspace{1em}査）\hspace{1em}岡崎 威生
 
 		\vspace{1cm}
 		\underline{\hspace{6cm}印}\\
-		（副\hspace{1em}査）\hspace{1em}當間　愛晃
+		（副\hspace{1em}査）\hspace{1em}長田 智和
 
 		\vspace{1cm}
 		\underline{\hspace{6cm}印}\\
--- a/Paper/chapter/thanks.tex	Thu Jan 27 22:49:44 2022 +0900
+++ b/Paper/chapter/thanks.tex	Sun Jan 30 04:52:30 2022 +0900
@@ -1,2 +1,10 @@
 \chapter*{謝辞}
 \addcontentsline{toc}{chapter}{謝辞}
+本研究の遂行、本論文の執筆にあたり、丁寧な御指導と御教授を賜りました河野真治准教授に心より感謝いたします。
+ご多忙の中にも関わらず、研究の引き継ぎと御教授を頂きました卒業生である清水隆博さん、赤堀貴一さんに感謝いたします。
+加えて、共に研究の遂行を行ってくれた又吉雄斗さんを始めとして、共に研究に励み心の支えとなってくださった並列信頼研の所属学生に感謝いたします。
+最後に、理工学研究科情報工学専攻の学友、教員方と職員、並びに生活と心の支えをくださった家族に深く感謝いたします。
+
+\begin{flushright}
+    2022年 3月 \\ 一木貴裕
+\end{flushright}
Binary file Paper/images/QueueElement.graffle.graffle has changed
Binary file Paper/master_paper.pdf has changed
--- a/Paper/reference.bib	Thu Jan 27 22:49:44 2022 +0900
+++ b/Paper/reference.bib	Sun Jan 30 04:52:30 2022 +0900
@@ -77,4 +77,3 @@
  publisher = {USENIX Association},
  address = {Berkeley, CA, USA},
 }
-
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Paper/src/ErrorStub.cbc	Sun Jan 30 04:52:30 2022 +0900
@@ -0,0 +1,5 @@
+__code Task3_stub(struct Context* context) {
+	TQueue* localDGMQueue = Gearef(context, TQueue);
+	FileString* string = Gearef(context, FileString);
+	goto Task3(context, localDGMQueue, string);
+}
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Paper/src/StubProblem.cbc	Sun Jan 30 04:52:30 2022 +0900
@@ -0,0 +1,14 @@
+__code Task2(TQueue* localDGMQueue){
+    goto localDGMQueue->take(Task3);
+}
+
+__code Task3(TQueue* localDGMQueue, FileString* string){
+    printf("take[%s] [num:%d]\n", string->str, string->size);
+    goto getData();
+}
+
+__code Task3_stub(struct Context* context){
+    TQueue* localDGMQueue = (struct TQueue*)Gearef(context, TQueue)->tQueue;
+    FileString* string = Gearef(context, TQueue)->data;
+    goto Task3(context, localDGMQueue, string);
+}
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Paper/src/mainDist.cbc	Sun Jan 30 04:52:30 2022 +0900
@@ -0,0 +1,8 @@
+__code createTask1(struct TaskManager* taskManager) {
+    struct CountUp* countUp = createCountUpImpl(context);
+    struct CountUp* countUp2 = createCountUpImpl(context);
+    par goto countUp->eNum(0, Task2);
+    par goto countUp2->eNum(0, Task2);
+    //par goto twice(array1, array2, iterate(split), __exit);
+    goto code2();
+}
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Paper/src/missingParGoto.cbc	Sun Jan 30 04:52:30 2022 +0900
@@ -0,0 +1,45 @@
+__code createTask1(struct Context *context,struct TaskManager* taskManager) {
+    struct CountUp* countUp = createCountUpImpl(context);
+    struct CountUp* countUp2 = createCountUpImpl(context);
+
+    struct Element* element;
+                    context->task = NEW(struct Context);
+                    initContext(context->task);
+                    context->task->next = countUp->eNum;
+                    context->task->idgCount = 1;
+                    context->task->idg = context->task->dataNum;
+                    context->task->maxIdg = context->task->idg + 1;
+                    context->task->odg = context->task->maxIdg;
+                    context->task->maxOdg = context->task->odg + 0;
+    GET_META(0)->wait = createSynchronizedQueue(context);
+    //GET_META(countUp)->wait = createSynchronizedQueue(context);
+    Gearef(context->task, CountUp)->countUp = (union Data*) countUp;
+    Gearef(context->task, CountUp)->num = (union Data*) 0;
+    Gearef(context->task, CountUp)->next = C_test;
+                    element = &ALLOCATE(context, Element)->Element;
+                    element->data = (union Data*)context->task;
+                    element->next = context->taskList;
+                    context->taskList = element;
+
+                    context->task = NEW(struct Context);
+                    initContext(context->task);
+                    context->task->next = countUp2->eNum;
+                    context->task->idgCount = 1;
+                    context->task->idg = context->task->dataNum;
+                    context->task->maxIdg = context->task->idg + 1;
+                    context->task->odg = context->task->maxIdg;
+                    context->task->maxOdg = context->task->odg + 0;
+    GET_META(0)->wait = createSynchronizedQueue(context);
+    //GET_META(countUp2)->wait = createSynchronizedQueue(context);     
+    Gearef(context->task, CountUp)->countUp = (union Data*) countUp2;
+    Gearef(context->task, CountUp)->num = (union Data*) 0;
+    Gearef(context->task, CountUp)->next = C_test;
+                    element = &ALLOCATE(context, Element)->Element;
+                    element->data = (union Data*)context->task;
+                    element->next = context->taskList;
+                    context->taskList = element;
+
+    Gearef(context, TaskManager)->taskList = context->taskList;
+    Gearef(context, TaskManager)->next1 = C_code2;
+    goto parGotoMeta(context, C_code2);
+}