LogFS：新方式のフラッシュファイルシステム
既にLinuxユーザには、JFFS2とYAFFSという成熟した2つのフラッシュファイルシステムの選択肢がある。それなのになぜ、また新たなファイルシステムが必要なのだろうか。Engel氏がこれらの選択肢のどちらをも尊重しないのには、数々の理由がある。YAFFSについては「カーネルとの統合を本気で試みた形跡がなく」、多くの潜在的ユーザにとって「ふさわしくない」と彼は述べる。また、JFFS2については、フラッシュデバイスの容量が大きくなるとメモリ消費量とマウント時間が許容範囲を超えてしまうという。「ほとんどのファイルシステムとは異なり、（JFFS2では）メディア上にどんなツリー構造も存在しない。そのため、マウント時にはメディア全体をスキャンし、ファイルシステムのマウント中はツリー構造をメモリに保存しておく必要がある。デバイスの容量が大きくなるにつれ、マウント時間、メモリ消費量ともに線型に増加する」
LogFSはどれくらいのストレージ容量にまで対応しているのだろうか。実は、Engel氏にも明確な答えはないようだ。「正直なところ、私にもわからない。重要なデータ構造はみな64ビットになっているので、エクサバイト（10の18乗バイト）デバイスが現れても理論的にはすぐさま対応可能なはずだ。だが、LogFSが本当にそこまで対応できるかどうかは実証していない」
「まあ、64MBあたりが無理のないサイズだろう」というのがEngel氏の現実的な回答だ。LogFSは比較的容量の小さなデバイスでの動作に向いているが、ごく小さなサイズのフラッシュファイルシステムとしてはJFFS2の方が適している場合がある、と彼は述べる。「2MBのフラッシュメモリでも（LogFSは）確かに動作するが、その場合はJFFS2のほうがオーバヘッドが小さく、そうした小容量のデバイスではマウント時間の問題も気にはならない。もともと小容量デバイス向けに作られたものなので、やはりそうしたデバイスにはJFFS2が向いている」（Engel氏）
それなら、YAFFSやJFFS2の問題点を修正するか、フラッシュファイルシステム向けのext3相応のものに取り組めばよさそうなものだが、そうしなかったのはなぜだろうか。Engel氏は、既存のフラッシュファイルシステムを改良できるとは考えていない、と言う。「でなければ、そもそも私がこのプロジェクトに着手するはずがない」
ext3をフラッシュデバイスで利用する際の最大の問題は、フラッシュファイルシステムにおける消去の操作にある、とEngel氏は説明する。ハードディスクとは違ってフラッシュデバイスでは、一度ある「セクタ」にデータを書き込むと、いったん消去しないと再び書き込みができないのだという（以下を参照）。
消去は、フラッシュ内の比較的大きなブロックに対して行われる。こうした消去の単位となるブロックサイズはさまざまだが、通常は16～128KBである。
消去を行うと、ブロック内のすべてのデータが失われ、復元することはできない。そのため、フラッシュファイルシステムは、消去前に重要なデータが存在しないことを確認する必要がある。もしあれば、まずはそのデータを別の場所に移動させなければならない。
データを別の場所に移動できるということは、データのフラッシュデバイス上の物理的な位置と論理的な位置との間には、ファイルおよびファイルオフセットの点で固定された関係が存在しないことを意味する。ext2/ext3やその他ほとんどのディスクファイルシステムは固定された関係に依存しているため、フラッシュファイルシステムとしてはうまく機能しない。
Engel氏は、ext3の別の問題として消耗の均等化（wear leveling、メモリ全体を万遍なく利用して不均一な劣化を防ぐこと）を挙げている。フラッシュメモリのセグメントは、一定の回数を超えてデータの消去を行うと、劣化によって信頼性が失われる。普通のハードディスクを想定したファイルシステムはフラッシュメモリ用に最適化されていないため、不用意にセグメントを劣化させ、フラッシュメモリを事実上使いものにならなくしてしまう恐れがある。フラッシュメモリには寿命を延ばすために専用のファイルシステムが必要だ、とEngel氏は話す。
一方で、LogFSはハードディスクには向いていない、ともEngel氏は語る。「ほとんどの場合、LogFSはハードディスクに不向きだろう。ハードディスクにはアクセスの遅さという厄介な特性がある。平均シーク時間は依然として10ms程度かかる。つまり、ハードディスク上のファイルシステムを高速化するには、シーク時間を最小化できるようにデータの配置を調整しなければならない」
「だが、LogFSではこの問題をまったく考慮していない。その設計上の作用により、書き込み操作でシークが発生することは滅多にないため、ハードディスクでの書き込みのパフォーマンスはかなり良いだろう。だが、読み取りのパフォーマンスとなると、想定し得るどんなベンチマークでもLogFSが最低になるはずだ」（Engel氏）
今はまだ準備中
今のところ、LogFSはまだプロダクション環境向けには仕上がっていない。LogFSのFAQには、「2007年半ば」に予定している正式リリース版が出るまではこのファイルシステムを実務用のデータに対して利用しないように、との忠告が記されている。
LogFSに関してEngel氏は「私のテストケースはすべてパスした」と言っているが、このテストケースでは、フラッシュデバイスに対する読み取り/書き込み/消去の操作中のシステムクラッシュやエラーなど、期待されるであろういくつかの特定のテスト範囲がカバーされていないという。ただし、彼はシステムクラッシュへの対応をLogFSに関する今後の実行リスト中の「最上位項目」として挙げている。
また、エラー処理についてEngel氏は次のように話す。「デバイスが十分に信頼できるものであれば、ユーザにとって許容できる問題かもしれない。だが、この判断は軽はずみにすべきものではないので、まずはデバイスのテストを十分に行う必要があるだろう」
Engel氏によると、「本当の意味での」フラッシュデバイスの不足はまた別の問題だという。入手可能なフラッシュメモリデバイスは数多くあるが、大半のコンシューマデバイスには「あたかもハードディスクであるかのような動作をさせるために本来のフラッシュとファイルシステムの中間にレイヤが存在する」と彼は語る。
「USBスティックをフラッシュファイルシステムで使うために、こうしたブロックデバイスインタフェースは、Linuxでフラッシュを扱うMTD（Memory Technology Device）に変換し直す必要がある。この二重の変換は、きわめて非効率的だ。メーカー側が、デバイス内のフラッシュチップそのものに対するアクセスを一切の変換なしに可能にしてくれれば、フラッシュファイルシステムはもっと役に立つものになるのだが」（Engel氏）
LogFSが理想的なファイルシステムとなり得るプロジェクトの1つが、One Laptop Per Child（OLPC）プロジェクトだ。LogFSとOLPCとの提携関係は「漠然とした」ものに過ぎないとEngel氏は言う。OLPCには、もともとJFFS2ファイルシステムを書き上げ、LogFSにも貢献したDavid Woodhouse氏が、Red Hatを通じて参加している。Engel氏は、Woodhouse氏の紹介でOLPCのプログラマJim Gettys氏と知り合い、その後OLPCの試作品2台を受け取ったという。これらのマシンは、LogFSのテスト用ハードウェアとして使われている。
「自分のファイルシステムがOLPCマシンで利用されるのをぜひ見てみたい。きっとすばらしい改善結果が得られるだろう。だが、それはLogFSがどれだけ早く完成の域に達するかに大きくかかっている」（Engel氏）
