\chapter{結論}
本研究ではGearsOSに導入するファイルの構造、階層表現と分散ファイルシステムのAPIの設計を行った。
GearsOSにおけるファイルは競合的なアクセスを許した大域的な資源であり、
ファイルは分散フレームワークChristieのDataGearManagerに相当する。
ファイル内のデータは任意の構造体によるDataGear単位に分割されており、ファイルを読み込む場合、DataGearを順番にTakeで呼び出せば良い。
ファイルのデータとなるDataGearはプログラマが任意の形の構造体で形成することができ、ファイルの種類によって実装を適切なものに構成することができる。

ファイルの共有による通信はRemoteDataGearManagerによるploxyに対して操作することで行われる。
そのため、GearsOSでのファイルはファイルそのものであると同時に分散処理の通信とも見ることができる。
その通信はWordCount例題の記述によって行い、ChristieAPIの構築とGearsOSにおけるsocket通信の有用性の確認を行った。

また、ファイルは赤黒木によるディレクトリによって階層が構築され、ファイル、ディレクトリは非破壊的な変更が行われる。
そのため、変更の履歴はOSが参照できる形で残されており、定期的なバックアップや履歴データの削除などの機能を作成することで
アプリケーションに頼らず、OSがバックアップを担当することができる。

加えてファイルシステムの構築をしながら、GearsOS自体の改善点や利用の検証を行った。
現状のGearsOSはノーマルレベルとメタレベルの分離という目的を達成してはいるものの、
関数スタックを持たない軽量継続という記述の独自な特性や記述の難易度、トランスコンパイラによるバグなどにより
プログラマが慣れ親しみ問題を解決しながらプログラムが記述できるようになるまで時間がかかってしまう。
GearsOSは現在再実装の検討が行われており、トランスコンパイラによるメタレベルの記述を他の手段を用いるといった議論が行われている。


\section{今後の課題}
ファイルの通信接続はChristieのTopologyManagerの機能を用いるが、詳細な設計は現時点で行えていない。
DataGearMangerによる接続形成をTopologyManagerに一任する形にすることで、本来は煩雑な処理が必要となる通信の接続を簡潔に行いたい。
しかしChristieのTopologyManagerはあくまで分散フレームワークであるChristieに向けて開発されたものである。
そのため、ChristieのTopologyManagerを基準にしながら、分散ファイルシステムに向けた仕様を考案していく必要がある。
例えば、TopologyManagerは参加を表明したノードを任意の形のTopologyに構成するというものだが、
CodeGearManagerの存在しないGearsFSでは、RemoteDGMによる通信接続に加え、
DNSシステムによるファイルの呼び出しなど通信Topologyの中枢としての役割を持たせたい。


ファイルシステムの基幹となるディレクトリやファイル通信の設計は行えている。
しかし、実際にファイルシステムとして十分な運用が行えるようになるまでの課題は多く存在している。
ファイルのアクセス権限への対応やシェルアプリケーションの開発、ディスクスペースの効率の良い配置などはこれからの実装が必要となる。
ファイルのメタデータ生成やメモリの効率化などの問題はmetaCodeGear部分で行うことにより、
ノーマルレベルのプログラミングでは意識する必要なくプログラミングが行える構成としたい。

また、ファイルシステムの一貫性の保持やキャッシュの設計も行われていない。
GearsFSはinodeを用いるなどUnixFileSystemを参考とした開発を行っているが、key ストアによるデータ保存形式のため、
従来のfsckなどの仕組みに代わる機能などの必要性が生じる可能性が高い。