Mercurial > hg > Papers > 2022 > ikki-master
changeset 7:b31312c4d2de
add Debug
author | ichikitakahiro <e165713@ie.u-ryukyu.ac.jp> |
---|---|
date | Tue, 18 Jan 2022 21:03:13 +0900 |
parents | 38dfa4d8b0be |
children | 25cf5b9b74a2 |
files | Paper/chapter/0-introduction.tex Paper/chapter/5-Implementation.tex Paper/images/GearsDirectory.graffle.graffle Paper/images/nonDestroyTreeEdit.pdf Paper/master_paper.pdf |
diffstat | 5 files changed, 73 insertions(+), 4 deletions(-) [+] |
line wrap: on
line diff
--- a/Paper/chapter/0-introduction.tex Sun Jan 16 23:43:50 2022 +0900 +++ b/Paper/chapter/0-introduction.tex Tue Jan 18 21:03:13 2022 +0900 @@ -1,1 +1,36 @@ \chapter{要旨} +コンピュータにおけるファイルシステムは必要不可欠な存在であると言える。 +コンピュータで行われる計算やそれに使われるデータは全て記憶装置上にファイルとして保持され、 +ファイルという概念なしにはユーザーがコンピュータ上で用いられる資源の管理はほぼ不可能であると言える。 +コンピュータの技術発展と普及に伴いファイルは物理的な存在場所に囚われない、 +つまりネットワークへの接続を通して別マシン上のどこからでもアクセスが行える存在である必要が生じてきた。 +物理的な位置を問わずネットワークを通してファイルを共有する機能を有するファイルシステムを特に分散ファイルシステムと呼ぶ。 +分散ファイルシステムはネットワークに配置されたファイルに対して、ローカルに保存されたファイルとほとんど相違なく取り扱いが行える透過性が求められる。 + +・・・既存のファイルシステムとか語る?今のファイルシステムの問題点とか? + +・・・アプリケーションであるFSとOSに実装されたFS? + +また、当研究室では信頼性の保証と拡張性の高さを目指したOSプロジェクトである、GearsOSの開発を行なっている。 +GearsOSはテストコードでなく、AgdaやCoqなどの型式手法に含まれる定理証明支援系やモデル検査を用い、 +実施にOSとして動作するコードそのもののを検証することで信頼性の補償を目指している。 +また、GeasOSはノーマルレベルとメタレベルを分離して記述するContinuation based C(CbC)にて記述される。 +ノーマルレベルとはユーザが行いたい計算をさし、メタレベルとはノーマルレベルの計算を行うための計算をさす。 +ノーメルレベルのプログラムのメタレベルに対して自由に差し替えを行うことにより、 +コードの整合性の検証やプログラムのデバッグを行えるような作りとなっている。 + +現状においてGearsOSは言語フレームワークとして実装されており、 +実際にOSとして起動するためにはこれから実装が必要となる機能が複数存在している。 +その中の一つとして分散ファイルシステムが挙げられる。 +GearsOSのファイルシステムは既存のOSが持つファイルシステムの問題点の解決や +従来ではアプリケーションが担っているバックアップを始めとした機能を搭載したファイルシステムの構成を目指して開発を行いたいと考えた。 +問題点の解決の一部として、既存のファイルシステムとは異なりファイルシステムをデータベースとして構成したい。 +レコードでファイルデータを取り扱うことによりファイルの更新や操作を簡潔に行い、加えてFileSystemのAPIを総括してトランザクションとしたい。 +加えて、データのバックアップについてもOSに搭載したい。 +従来のようにバックアップデータをユーザが管理するのではなく、OSが管理をすることによりバックアップデータ自体の紛失を防ぎたい。 + +また、分散ファイルシステムは当研究室が開発している分散フレームワークであるChristieの仕組みを用いて構成する。 +Christieを基盤としたファイルシステムを構築する理由として、 +Christieの独自なシンタックスによる簡潔なプログラムにより複雑な分散処理の記述が行えるようにする目的が挙げられる。 +加えてChristieが持つ、処理を行うノードごとの接続(Topology形成)の自動化を行うTopologyManagerが用いることができるようになり、 +ファイルシステム上の通信接続は全てTopologyManagerに一任することができるようになる。
--- a/Paper/chapter/5-Implementation.tex Sun Jan 16 23:43:50 2022 +0900 +++ b/Paper/chapter/5-Implementation.tex Tue Jan 18 21:03:13 2022 +0900 @@ -80,6 +80,8 @@ SingleLinkedな(単純な)Queueを用いることも考えられる。 ファイルに対する書き込みやMainQueueは単一プロセスのみからのアクセスとなるためSingleLickedなキューで実装する。 + + \section{ディレクトリシステム} 本研究と並行する形で又吉雄斗によるGearsFileSystemのディレクトリ構造の構築が行われている。[論文No.] GearsFSのディレクトリシステムはUnixOSのディレクトリシステムと同じ仕組みを用いて再現することを試みている。 @@ -87,13 +89,10 @@ 図\ref{fig:GearsDirectory}にGearsFSの構成図を示す。 一つのディレクトリは赤黒木であり、あるディレクトリの中に位置するファイル(ディレクトリ含む)は赤黒木の中のノードにvalueとして同等に配置される。 -赤黒木にはファイル下に配置された別のディレクトリもしくはファイル構造が保存される。 +赤黒木にはファイル下に配置された別のディレクトリもしくはファイルが保存される。 図の例では/(ルートディレクトリ)からUsersディレクトリ下にあるDadというディレクトリ(もしくはファイル)を参照するには、 /のTree内のUsersを探索、続いてUsersTreeの内部のDadを探索する形となる。 - - - \begin{figure}[h] \begin{center} \includegraphics[width=80mm]{./images/GearsDirectory.pdf} @@ -102,10 +101,45 @@ \label{fig:GearsDirectory} \end{figure} +GearsのディレクトリシステムはUnixのinodeの仕様を用いる。 +inodeとはファイルごとのユニークな番号(inode番号)データ領域へのポインタや作成日時、サイズなどのメタデータを保存するための領域である。 +GearsFSの赤黒木を用いたディレクトリシステムに実際に保存されるノードはkeyがFileName、 +valueがinodeのペアを保持している。 +DirectoryTreeで探索し任意のファイルのinode番号を手に入れ、DirectroyTreeとは別に実装されたkeyにinode番号とvalueとして +ファイルのポインタを保持させるTreeをinode番号で探索させる形となる。 +この形で実装することにより、ファイル自身が所属するDirectoryをinode番号で保持でき、親Directoryが複数存在していたり、 +親DirectoryのFileNameが変更された場合においてもDirectoryの構造の障害が起きない。 + + \section{GearsFSのバックアップ} GearsOSは将来的にOS自体がバックアップの機能を保持する構成を目指している。 +GearsFSのDirectoryのバックアップは木構造の構築を非破壊的に行うことにより過去のデータを保持する。 +図\ref{fig:TreeEdit}に非破壊的な木構造の編集を図に示す。 +非破壊的木構造の編集とは編集元のノードのデータや接続を直接書き換えることなく、 +根(ルートノード)から必要なノードは新しく生成し一部のノードは過去のものを使い回すことで更新することを指す。 +図中の右側の編集後の木構造の赤く記されたノードは新規に作成、もしくはコピーされたノードとなる。 +変更されたノードと根から変更ノードまでの道筋のノードは、編集元のノードとは別に新しく作成される。 +それ以外のTreeに属していたノードは編集元のTreeのノードをポインタで接続することで使い回す。 +つまり、図中の黒いノード1から探索を行えば過去のデータのノードが参照でき、 +赤いノード1から探索を行えば編集後の木構造を参照することができる。 +ファイル構造体のバックアップについては、ファイルのDataレコードをファイルの変更差分を履歴として保持させる形にすることに加え、 +変更日時を保持させることで可能となると考えられる。 +特定の時点のファイルとDirectoryの状態を呼び出す際は、レコードの変更日時を確認し、参照するべきTree構造とレコードを呼び出す形となる。 + +非破壊的木構造の編集と変更履歴式のデータレコードはディレクトリやファイルの容量が変更が行われるたびに増加していくという問題が存在する。 +この点については任意の期間経過、もしくはユーザの操作により定期的に過去のデータを自動削除することで容量がある程度削減が望める。 +また、近年の電子記録媒体の容量増加に伴い問題の重要性が低下していくことが予想できる。 + + +\begin{figure}[h] + \begin{center} + \includegraphics[width=150mm]{./images/nonDestroyTreeEdit.pdf} + \end{center} + \caption{非破壊的なTree編集} + \label{fig:TreeEdit} +\end{figure} \section{ChristieAPIによるWordCount}