# HG changeset patch # User matac42 # Date 1704962623 -32400 # Node ID dcb4bb1e6bee5de7c425315c2e11cb3b79403f46 # Parent 91b67726191cc1e916d03bc01752f77ce3c347aa ... diff -r 91b67726191c -r dcb4bb1e6bee Paper/fig/rbtree_gc.drawio --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Paper/fig/rbtree_gc.drawio Thu Jan 11 17:43:43 2024 +0900 @@ -0,0 +1,151 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff -r 91b67726191c -r dcb4bb1e6bee Paper/fig/rbtree_gc.png Binary file Paper/fig/rbtree_gc.png has changed diff -r 91b67726191c -r dcb4bb1e6bee Paper/master_paper.pdf Binary file Paper/master_paper.pdf has changed diff -r 91b67726191c -r dcb4bb1e6bee Paper/master_paper.tex --- a/Paper/master_paper.tex Thu Jan 11 15:29:29 2024 +0900 +++ b/Paper/master_paper.tex Thu Jan 11 17:43:43 2024 +0900 @@ -393,6 +393,7 @@ \chapter{GearsFileSystemにおけるGCとレプリケーション} + \section{ファイルシステムの信頼性に関する機能} ファイルシステムはデータを保持することを基本的な機能としている. @@ -448,15 +449,56 @@ \section{GearsFileSystemのGC} GearsFileSystemのGCはCopying GCを基本的なアルゴリズムとする. +他のGC手法と比較して参照できるオブジェクトをコピーするだけであるため, +実装が簡単で,より高いスループットが期待できる. +Mark \& Sweep GCやReference counting GCの場合は, +GCを複数フェーズで実装したり,カウンターの扱いについて考える必要がある. +また,同様の構造をコピーするのみで実装することによって, +データの透過性の確保がしやすい. +ファイルやディレクトリを表現するRedBlackTreeは全てのデータの参照を持つ. +そのため,オブジェクトルートからオブジェクトを辿ってコピーを行うCopying GCとの相性が良い. -GearsFileSystemにおけるデータは全てRedBlackTreeに格納する. -また,ディスク上とメモリ上のデータ構造は同一である. -よって,RedBlackTreeの単なるコピーによってGCを行うことによって, -データの透過性が確保され,単純なプログラムで実装することが可能と考える. +一般的なCopying GCではFrom領域上のオブジェクトをTo領域にコピーする形で実装される. +一方,GearsFileSystemではファイルやディレクトリの基本構造であるRedBlackTreeをコピーする. +ファイルやディレクトリの操作を行うFromのRedBlackTreeから, +ルートから辿れるノードのみをToのRedBlackTreeとしてコピーする. +それにより,辿れなかったノード,つまり参照されていないノードはコピーされず, +不要なオブジェクトが回収された状態となる. + +\begin{figure}[ht] + \begin{center} + \includegraphics[width=160mm]{fig/rbtree_gc.png} + \end{center} + \caption{RedBlackTReeのCopyによるGC} + \label{fig:TreeCopyGC} +\end{figure} + +DBの重要な機能の一つにロールバックがある. +RDBのロールバックは, +コミットするまではトランザクションの開始時点に戻ることができる機能を持つ. +コミットが完了するとそれ以前の状態に戻すことはできないが, +データのバックアップをとっておくことで復元を行う. +このような,ロールバックとバックアップの仕組みをファイルシステムに実装したい. + +今回は,RedBlackTreeのルートノードがデータのバージョンの役割を果たしていることを利用し, +データの復元が行える仕組みを構築することを考える. +非破壊的なTree編集はアップデートのたびに,ルートノードを増やす. +つまり,ルートノードはアップデートのログと言えその時点のデータのバージョンを表していると考えることができる. +よって,ロールバックを行いたい場合は参照を過去のルートノードに切り替える. + +ルートノードはデータのアップデート時に増えるため, +データが際限なく増加していく問題がある. +この問題はCopyingGCを行うことによって解決する. +まず,RedBlackTreeを丸ごとコピーして最新のルートを残して他のルートは削除する. +その後,コピーしたものはバックアップないしログとしてディスクに書き込む. +そうすることで,データの増加によるリソースの枯渇を防ぎ, +かつデータのログ付きバックアップを作成することで信頼性の向上が期待できる. \section{GearsFileSystemのレプリケーション} + + \chapter{CopyRedBlackTreeの実装} データのバックアップやレプリケーション,GCの機能を実装するためには, @@ -483,26 +525,6 @@ \section{証明のしやすさについて} -DBの重要な機能の一つにロールバックがある. -RDBのロールバックは, -コミットするまではトランザクションの開始時点に戻ることができる機能を持つ. -コミットが完了するとそれ以前の状態に戻すことはできないが, -データのバックアップをとっておくことで復元を行う. -このような,ロールバックとバックアップの仕組みをファイルシステムに実装したい. - -今回は,RedBlackTreeのルートノードがデータのバージョンの役割を果たしていることを利用し, -データの復元が行える仕組みを構築することを考える. -非破壊的なTree編集はアップデートのたびに,ルートノードを増やす. -つまり,ルートノードはアップデートのログと言えその時点のデータのバージョンを表していると考えることができる. -よって,ロールバックを行いたい場合は参照を過去のルートノードに切り替える. - -ルートノードはデータのアップデート時に増えるため, -データが際限なく増加していく問題がある. -この問題はCopyingGCを行うことによって解決する. -まず,RedBlackTreeを丸ごとコピーして最新のルートを残して他のルートは削除する. -その後,コピーしたものはバックアップないしログとしてディスクに書き込む. -そうすることで,データの増加によるリソースの枯渇を防ぎ, -かつデータのログ付きバックアップを作成することで信頼性の向上が期待できる. % TODO: バックアップのフローを図にしたい diff -r 91b67726191c -r dcb4bb1e6bee mindmaps/gears_fs_db.mm --- a/mindmaps/gears_fs_db.mm Thu Jan 11 15:29:29 2024 +0900 +++ b/mindmaps/gears_fs_db.mm Thu Jan 11 17:43:43 2024 +0900 @@ -312,6 +312,10 @@ + + + + @@ -480,28 +484,46 @@ + + + + + + - - - - - - + + + + + - + + + + + + + + + + + + + +