LogFS

この記事の出典や参考文献は、一次資料や記事主題の関係者による情報源に頼っています。 信頼できる第三者情報源とされる出典の追加が求められています。 出典検索?: "LogFS" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2013年2月）

LogFS
開発者	Jörn Engel, Prasad Joshi
導入	()
構造
限度
ファイル名の文字	{{{filename_character_set}}}
特徴
重複排除	{{{single_instance_storage}}}
対応OS	Linux
テンプレートを表示

LogFSは、Linuxのスケーラブルなログ構造（英語版）フラッシュファイルシステムである。

大容量デバイスでの使用を目的としている。

これはJörn Engelによって書かれ^[1]、一部は家電Linuxフォーラム（英語版）によって後援されている。

LogFSは、2010年5月16日にリリースされたバージョン2.6.34のメインラインLinuxカーネルに導入された。2016年12月のバージョン4.10のマージウィンドウ（英語版）中に、「何年もメンテナンスされておらず、一見未使用」であったため、コードベースから削除された^[2]。

2008年11月の時点で、LogFSはテストスイート全体に合格するほど成熟しており、2010年5月16日にリリースされたバージョン2.6.34で、「実験的」とマークされたメインラインのLinuxカーネルに含まれていた。大規模なユーザーベースであり、2016年12月にカーネルから削除された。

LogFSは、より大きなフラッシュメモリドライブを備えたJFFS2の難しさに動機付けられた。 LogFSはiノードツリー（英語版）をドライブに保存する; JFFS2はそうではなく、マウント時にドライブ全体をスキャンし、ツリー全体をRAMにキャッシュする必要がある。 大規模なドライブの場合、スキャンには数十秒かかることがあり、ツリーは大量のメインメモリを使用する可能性がある。LogFSはこれらのペナルティを回避するが、システムの実行中はより多くの作業を行い、iノードツリーを保持するためにドライブのスペースの一部を使用する。

LogFSは、ファイルのiノードツリーをドライブに保存する。つまり、ファイルへの書き込み時に、ツリー内の各祖先ノードを再書き込みする必要がある。これは、「さまようツリー」の更新によって行われる。 ツリーの最下位ノード（つまり、データ）が最初に書き込まれ、ルートiノードが更新されるまで、各ノードがツリーの昇順で書き込まれる。 ルートを最後に書き込むと、更新のアトミック性が維持される。

フラッシュメモリブロックは消去の単位であり、通常はファイルシステムブロックよりも大きくなる。LogFSは、複数のファイルシステムブロックを単一のフラッシュメモリブロックにパックすることにより、この不一致を処理する。フラッシュメモリブロックの最後にある「合計」エントリは、そこに格納されているデータを記録する。 フラッシュメモリブロックのすべてのファイルシステムブロックが移動または削除されると、消去して新しいデータに使用できる。

フラッシュメモリドライブのピーク使用量については、フラッシュメモリブロックが有用なデータでいっぱいになるようにデータを圧縮する必要がある。これはガベージコレクションによって実現される。LogFSのガベージコレクション戦略はファイルデータが特定の方法でフラッシュメモリブロックに配置されることに依存している: フラッシュメモリブロックは、iノードツリーの同じレベルのファイルデータのみを保持する。LogFSは、空のフラッシュメモリブロックを1つだけ使用して、ツリーのトップレベルをガベージコレクションできる。2つの空のフラッシュメモリブロックを使用して、ツリーの上位2レベルをガベージコレクションできる。また、N個の空のフラッシュメモリブロックを使用して、ツリーのNレベルすべてをガベージコレクションできる。アルゴリズムは最悪の場合は指数関数的時間（英語版）であるが、最悪の場合はまれであり、アルゴリズムはほんの一握りのフラッシュメモリブロックを予約する必要がある。

• UBIFS
• iノードポインタ構造体（英語版）

• logfs.org/logfs/ at the Wayback Machine (archived 2010-06-16)
• Introduction to LogFS (ビデオ)