ファイルシステム

(原文はこちら)
ファイルシステムは永続的なデータを保守するコードであるため、どの OS でも大変重要な部分です。ファイルシステムには特に信頼性が重要です。あらゆるミスが、データの消失を招いたり、(さらに悪質なのは) ずっと発見されない微妙なデータ破損につながったりします。また、ファイルシステムはシステムのパフォーマンスにとってクリティカルな部分でもあります。出来の悪いファイルシステムでは、どのような負荷でも標準以下のパフォーマンスしか得られません。

従来のファイルシステムは、回転ストレージ、つまりディスク ドライブの要件によって開発されています。そのようなデバイスの場合、最小限のヘッド シークで読み書きできるように、メディア上のデータを注意深くレイアウトする必要があります。ディスク ヘッドを移動している間に大量のデータが転送される可能性があるため、不必要なシークはパフォーマンスを低下させます。最もよく使用される Linux ファイルシステムのレイアウト コードは高度に最適化されていますが、新しいファイルシステムは、さらにこの領域に力を注いでいます。

フラッシュベース ストレージ デバイスは大容量で安価になり、今やローエンド システムで回転ストレージを置換できるまでになりました。フラッシュ メモリは、異なる制約を生み出しました。つまり、ランダム アクセスが可能なため、データ レイアウトはあまり重要ではありませんが、フラッシュベースのファイルシステムは膨大な消去ブロック、ウェア レベリング (磨耗平滑化)、およびその他のデバイス特有の問題を処理しなければなりません。このため、フラッシュベース デバイス上で従来のファイルシステムを使用することは、ベスト ソリューションではありません。現在 Linux では、フラッシュ指向のファイルシステムとその他のファイルシステムとを併用しています。

ストレージ容量が拡大すると、通常どのファイルシステムでもスケーリング問題が発生します。テラバイトスケールのファイルシステムを処理する場合、特に整合性チェックに関しては、別のアプローチが必要です。巨大なアレイ上でファイルシステム チェッカーを実行すると、今でも数日かかることがありますが、この問題は悪化するばかりです。大変な作業ですが、まずは fsck 問題の修正を開始することです。

内容

Ext4

Ext4 は多くの Linux インストレーションで長年使用されている ext2 と ext3 の後継です。2.6.19 からメインライン カーネルの一部でしたが、現在は試験的なファイルシステムとして考えられており、製品用途としてはお勧めできません。現在の機能には、下記のようなものがあります。

  • 48 ビットのブロック番号とその他の拡張: 最大ファイルシステムサイズを大幅に拡大
  • エクステント: ファイルシステムの効率性を向上させる。特に大きなファイルで有効
  • ナノセカンド タイム スタンプ: 高速なシステムにおける相対的なファイル修正時間をトラックするのに必要
  • ブロック プリアロケーション (リソース予約と最適なブロック レイアウト用) とマルチブロック アロケーション
  • ジャーナル チェックサム
  • 超大型ファイルのサポート
  • 遅延アロケーション: ディスク上のレイアウト改善を促進

計画されているその他の機能として、「オンライン デフラグ」、「システム クラッシュ後のファイルシステム高速チェック」などがあります。ただし ext4 は便利な機能を大量に追加していますが、真の次世代ファイルシステムになるにはまだ不十分です。このため ext4 は、btrfs が完成するまでの暫定的なシステムのように思えます。

予報: 遅延アロケーションは 2.6.27 でマージされました。計画されている機能のうち、これを書いている時点でメインライン カーネルに入っていない唯一の機能は、オンライン デフラグです。2.6.28 の時点で、ext4 はもはや「開発中の」ファイルシステムとは考えられていませんが、まだ一般使用の準備ができているとは公言されていません。以前私は、2.6.30 あたりでこの宣言があると予測しましたが、外れていないようです。

詳細情報:

Btrfs

Btrfs は、Oracle の Chris Mason によってゼロから作られた新しいファイルシステムです。extent ベースのストレージ、ファイルシステムをサブボリュームに分割する機能、高速スナップショット機能、データやメタデータのチェックサム、オンライン整合性チェック、超高速オフライン チェックなど、多くの興味深い機能があります。

予報: btrfs は全く新しいプロジェクトです。この作業は進行中ですが、新しいファイルシステムが考えられるときには保守主義が君臨し、この領域の信頼性のハードルが非常に高くなります。Btrfs はさまざまな関心を呼び起こしましたが、するべきことがまだたくさんあります。たとえば Btrfs timeline では、2009 年 1 月まで新しい追加機能を募集しています。2010 年より前に Btrfs が 製品レベルになることはないでしょう。

Btrfs コードは 2.6.29 カーネル リリースでメインラインにマージされました。しかしまだまだ開発中の部分もあり、プロダクション用には使用できません。

詳細情報:

オブジェクト ストレージ デバイス

オブジェクト ストレージ デバイス (OSD) は、大量のファイルシステムとセキュリティ処理をホスト システムからハードウェアへ移すためのものです。そのために、これらが提供するインタフェースは、個々のブロックではなく「オブジェクト」(主にファイル) を処理します。したがって OSD をサポートするには、異なる種類のファイルシステムが必要です。これにより、あらゆる複雑なブロックレイアウト コードを高度なプロトコル コードとセキュリティ メカニズムへのインタフェースに置換します。

open-osd プロジェクトは Linux の OSD サポートに向けて作業しています。特にこのプロジェクトは「osd イニシエーター」(ローレベル インタフェース コード)、osdfs (osd イニシエーターのトップに内蔵されているファイルシステム)、およびソフトウェア OSD インプリメンテーションを実装しています。

予報: osd イニシエーターと osdfs コードは、2008 年 11 月に初めてレビュー用に公開されました。最初のレビューは肯定的で、このコードをメインラインに早く入れてみたいという意見がかなり多くありました。このコードは 2.6.30 か 2.6.31 でマージされる可能性があります。

詳細情報:

AdvFS

AdvFS (または "Tru64 Advanced Filesystem") は、1990 年代に Digital Equipment Corporation によって開発されました。2008 年 6 月、HP (その後この技術を取得したため) が AdvFS が GPL の下でリリースされたことを発表しました。このファイルシステムには、メインラインの Linux ファイルシステムにまだ適合しなかったスナップショットやボリューム管理機能などの注目すべき機能があります。

予報: AdvFS コードは GPL の下でリリースされましたが、Linux には移植されていませんし、これからもないでしょう。ただし進行中の Linux ファイルシステム エフォートにとって、有効な情報 (コード) 源 として機能するでしょう。

詳細情報:

Reiser4

Reiser4 は ReiserFS ファイルシステムの後継です。スモール ファイルにおけるパフォーマンス性 (およびすべてのファイルでの高パフォーマンス)、スペース効率、および圧縮、暗号化、新フォーマットなどの機能を比較的簡単に追加する「プラグイン」アーキテクチャなど、さまざまな機能を提供します。

予報: Reiser4 は長い間 -mm ツリーにありましたが、メインラインに入るための管理をしていませんでした。そのファイルシステムの一部は、Linux VFS 層に適合するよう設計されておらず、いくつもの機能が無効にされていました。最近 Reiser4 はリード開発者を失いました。このファイルシステムを使っている人々もいますが、最終的にメインライン Linux の一部になるには、新しいチャンピオンが必要です。

詳細情報:

LogFS

LogFS は、ソリッドステート (フラッシュ) メディアにおける効率的な操作を目的とした全く新しいファイルシステムです。ログ構造ファイルシステムですが、他とは異なり、メディア上にディレクトリ ツリーを含むので、マウント時にそのようなツリーを作成する必要がありません。

予報: LogFS はまだ比較的開発の初期段階にあり、資金不足のために停滞しています。完成してメインラインに入る可能性はまだありそうですが、今のところ UBIFS に人気を奪われているように見えます。

詳細情報:

Tux3

Tux3 は、Daniel Phillips が開発中のきわめて新しいファイルシステムで、現時点ではまだ利用できません。Daniel は、新しいバージョニング スキーマやその他のさまざまな新案をベースに、非常に熱意を持ってこの作業に取り組んでいます。

予報: まだ予報はできません。Daniel はアイデアにあふれた有能な開発者ですが、これらのアイデアを完全に実現した実績があるわけではありません。いずれにしても Tux3 は遅れているので、その準備が整うまでに btrfs が確かな形になっているはずです。しかし驚くことが起こらないとも限らないので、このプロジェクトを見守る価値はあります。

詳細情報:

UBIFS

UBIFS は、Nokia などのエンジニアによって開発中のフラッシュ ベースのファイルシステムです。LogFS より先に完結に近づいていますが、UBI フラッシュ管理層の使用が原因で、起動時にスケーリングの問題が発生する可能性があります。UBIFS は、現時点で LogFS より高パフォーマンスであるというテスト結果が出ているようです。

予報: UBIFS はそれほど遠くない将来のマージを配慮してパブリック コメントに掲載されました。このファイルシステムについてはまだあまり議論されていませんが、2.6.26 にマージされる見込みはほとんどありません。事がすべてうまく進んでも、マージされるのは 2.6.27 かその次ぐらいでしょう。

詳細情報:

ZFS

ZFS は Sun Microsystems が Solaris 用に作成したファイルシステムです。128 ビット サポート、ブロック チェックサム、統合ボリューム管理など、数多くの興味深い機能が含まれています。

予報: この開発についてここで言及するべきではないかもしれませんが、常に質問の的になっているため採り上げました。ZFS はオープンソース ファイルシステムですが、まだ Linux を対象には考えていないようです。ZFS に使用されるライセンスは GPL と互換性がなく、2 つのコード ベースを混合することは不可能です。ZFS が所有していて Linux で使用できないパテントもあります。

詳細情報:

 

FS-Cache

FS-Cache は、ネットワーク ファイルシステムで使用するための汎用ファイル キャッシング層です。多くのファイルシステムが、ローカル システムにおけるリモートファイルのキャッシングをサポート (または要求) します。FS-Cache は、それを利用するすべてのファイルシステムに、キャッシングのメカニズムを提供するこを目的としています。

予報: このパッチは、比較的落ち着いており、ここ数年普及しています。メインラインになかなか入れませんでしたが、2.6.30 か 2.6.31 でマージされることは間違いないでしょう。大きな前提条件となるパッチ - クレデンシャル パッチ セット - は 2.6.29 で承認されました。

詳細情報:

ラージ ブロックのサポート

Linux のファイルシステムはホスト プロセッサのネイティブ ページ サイズより大きなブロック サイズを使用できません。ほとんどのファイルは小さいため、この制限は、通常は問題ありません。大きなブロックは、システム全体のスペースと処理時間の非効率を招きます。ただし大きなブロックがあったほうがよい場合もあります。extent ベースのシステムに大きなファイルを保存する場合などがよい例です。またブロックが大きいと、異なるページ サイズのシステム間でファイルシステムを移植する場合も好都合です。

予報: Linux ページ キャッシュと仮想メモリ サブシステムにラージ ブロック サポートを追加するパッチセットが公開されました。mmap() サポートがないなど、まだ未完成で、そのアプローチが正しいかどうかも疑問です。2.6.25 にラージ ブロック サポートが入るかもしれませんが、あまり期待できません。

詳細情報:

unionfs

union ファイルシステムは、2 つ以上の独立したファイルシステムの組み合わせで、まとめて 1 つの独立したファイルシステムに見えます。このようなファイルシステムの典型的な使用例が、ライブ CD 配布です。書き込み可能なファイルシステムが、読み取り専用の CD ベース ファイルシステムと一緒に作成されることにより、CD の内容が全部入り、しかも変更可能なファイルシステムであるかのような見かけを作り出しました。ほかにも多くの用途があります。

unionfs コードは、Linux のための union ファイルシステム インプリメンテーションで、数年にわたって開発されました。現在、いくつものディストリビューターから提供されていますが、まだメインライン カーネルには入っていません。

予報:  unionfs を 2.6.25 にマージするための協調努力がありましたが、成功しませんでした。一部のファイルシステム開発者は、誤ったアプローチだと考え、反対を唱えています。彼らの好むアプローチ (仮想ファイルシステム層内で動作する "union mount") のほうがエレガントかもしれませんが、製品用途になるには程遠い状態です。したがって、近い将来 Linux がこの機能を提供するには、unionfs を使用するしかありません。どうなるのか、予測は困難です。

詳細情報:

 

88x31.png

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.