Develop and Download Open Source Software

OpenSource Downloads

7-Zip  (4,208)  
HandBrake Japanese Language Version  (3,353)  
CrystalDiskInfo  (1,743)  
CotEditor  (1,120)  
CrystalDiskMark  (866)  
Boookends  (788)  
SMPlayer  (642)  
えこでこツール  (599)  
Tera Term  (595)  
10  FFFTP  (579)  
11  Cabos  (530)  
12  BathyScaphe  (494)  
13  ffdshow  (481)  
14  MergeDoc  (464)  
15  ギコナビ  (438)  
More >>

最近ブックマークされた記事

LogFS:新方式のフラッシュファイルシステム

2007年05月24日 19:30 Joe-'Zonker'-Brockmeier(2007年5月17日(木)) 1 2
 各ストレージ機器メーカーがソリッドステートディスクの出荷体制を整えつつあるためか、One Laptop Per ChildのXOやIntelのClassmateのようなLinuxベースのマシンには標準的なハードディスクが搭載されていない。現在入手可能な多様なフラッシュメモリ式ストレージデバイスのパフォーマンスを向上させるために、フラッシュデバイス専用のスケーラブルなファイルシステムLogFSがプロジェクトリーダのJörn Engel氏によって披露された。

 既に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氏)

最終更新:2007年07月01日 19:05