ext4 の徹底調査

第 4 世代拡張ファイルシステム、ext4 の紹介

第 4 世代拡張ファイルシステム、ext4 は、その前世代のファイルシステム ext3 との後方互換性を有する次世代のジャーナリング・ファイルシステムです。現時点ではまだ標準になっていませんが、ほとんどの Linux® ディストリビューションでは、ext4 が次のデフォルト・ファイルシステムとなる予定です。この記事で ext4 について学び、なぜこれがユーザーお気に入りの新たなファイルシステムになるのかを理解してください。

M. Tim Jones, Consultant Engineer, Emulex Corp.

M. Tim JonesM. Tim Jones は組み込みソフトウェアのエンジニアであり、『Artificial Intelligence: A Systems Approach』、『GNU/Linux Application Programming』(現在、第 2 版です) や『AI Application Programming』(こちらも現在、第 2 版です)、それに『BSD Sockets Programming from a Multilanguage Perspective』などの著者でもあります。技術的な経歴は静止軌道衛星用のカーネル開発から、組み込みシステム・アーキテクチャーやネットワーク・プロトコル開発まで、広範にわたっています。また、コロラド州ロングモン所在のEmulex Corp. の顧問エンジニアでもあります。



2009年 2月 17日

Linux カーネルのリリースにはいつでも驚きが伴いますが、昨年 12月にリリースされた 2.6.28 も例外ではありません。2.6.28 は、安定版 ext4 ファイルシステムとしては初めてのリリースです (この他にも、Btrfs をはじめとする優れた内容のさまざまな開発が盛んに進められています)。この次世代の拡張ファイルシステムは、拡張性と信頼性の向上、そして多くの新機能をもたらします。ext4 の優れた拡張性について言えば、最大ファイルシステムで 1 テラバイト (TB) のディスクを 100 万枚使用できるほどまで拡張できます。

拡張ファイルシステムの略歴

仮想ファイルシステム・スイッチ

VFS (Virtual File System) は、ファイルシステムのユーザーに対し、ベースとなっているファイルシステムの詳細を抽象化するための層です。このように抽象化することによって、VFS は Linux システム上でいくつものファイルシステムを同時にサポートできるようにします。

Linux で最初にサポートされたファイルシステムは、Minix ファイルシステムです。このファイルシステムにはパフォーマンスに重大な問題があったため、Linux 専用の別のファイルシステムが作成されました。それが、拡張ファイルシステムです。最初の拡張ファイルシステム (ext) は Remy Card によって設計され、1992年4月に Linux に導入されました。0.96c カーネルに実装された仮想ファイルシステム (VFS) スイッチを使うようになったのは、この ext ファイルシステムが最初です。ext がサポートする最大のファイルシステム・サイズは 2 ギガバイト (GB) でした。

次に登場した拡張ファイルシステム (ext2) も同じく Remy Card によって実装されたもので、導入されたのは 1993年1月のことです。ext2 は当時の他のファイルシステム (Berkeley FFS (Fast File System) など) から、高度な概念を採り入れました。ext2 はサポートするファイルシステムのサイズを 2 TB に拡大しましたが、ext2 ファイルシステムの最大サイズを 32TB にまで拡大したのは 2.6 カーネルからでした。

3 番目の拡張ファイルシステム (ext3) は、競合する一部のファイルシステムにパフォーマンスでは劣るものの、Linux ファイルシステムを大きく進展させました。システムが突然停止した場合のファイルシステムの信頼性を向上させるため、ext3 ファイルシステムにはジャーナリングの概念が導入されています。さらに、競合するファイルシステムのほうがパフォーマンスに勝っていましたが (Silicon Graphics の XFS や IBM® JFS (Journaled File System) など)、ext3 では ext2 を使用しているシステムからのインプレース・アップグレードをサポートしました。ext3 が導入されたのは 2001年11月のことで、実装したのは Stephen Tweedie です。

時代を現在に移すと、今や 4 番目の拡張ファイルシステム (ext4) が登場しています。パフォーマンス、拡張性、信頼性の点で、ext4 はさまざまな進展を遂げています。とりわけ注目に値するのは、ext4 では 1 エクサバイトのファイルシステムをサポートすることです。ext4 は、Theodore Tso (ext3 保守管理者) が率いる開発者のチームによって実装され、2.6.19 カーネルで導入されました。現在の 2.6.28 カーネルの ext4 は、(2008年12月の時点で) 安定版となっています。

ext4 は、競合する各種のファイルシステムから多くの有益な概念を採り入れています。例えば、エクステント手法によるブロック管理は、これまで JSF に実装されてきたものです。また、別のブロック管理関連の機能として、XFS と Sun Microsystems の ZFS 両方で実装された、遅延アロケーションも挙げられます。

この新しい ext4 ファイルシステムには、さまざまな改善内容と革新的技術を見い出せるはずです。改善内容には、機能性 (新たな機能)、拡張性 (現在のファイルシステムが持つ制約を超えた拡張性)、信頼性 (障害発生時)、そしてもちろんパフォーマンスなど、さまざまな観点での改善が網羅されています。


機能性

ext4 には新しい機能性が盛り沢山に組み込まれていますが、なかでもとりわけ重要なのは、ext3 との後方互換性と前方互換性、そして Linux システムの今後のパフォーマンス向上を見据えたタイムスタンプの改善です。

前方互換性と後方互換性

ext3 は、現在 Linux で最もよく使用されているファイルシステムの 1 つです。そのため、ext4 へのマイグレーションは容易で面倒のない作業にしなければなりません。この理由から、ext4 は前方互換性と (ある程度の) 後方互換性を併せ持つように設計されました (図 1 を参照)。ext4 には、ext3 ファイルシステムを ext4 ファイルシステムとしてマウントできるという点で、前方互換性があります。ext4 をフルに活用するには、ファイルシステムを新しい ext4 フォーマットに変換してこのフォーマットを利用するために、ファイルシステムのマイグレーションが必要です。ext4 ファイルシステムを ext3 としてマウントすることもできますが (後方互換性)、ただしその場合には、ext4 ファイルシステムがエクステントを使用しないという条件が課せされます (これについては、「パフォーマンス」セクションで説明します)。

図 1. ext4 の前方互換性および後方互換性
ext4 の前方互換性および後方互換性

互換性の機能に加え、ext3 ファイルシステムを ext4 に移行したい場合には、徐々に移行するという方法もあります。つまり、まだ ext4 に移行していない古いファイルについては ext3 フォーマットのまま維持しながらも、新規のファイル (またはコピーした古いファイル) だけが新しい ext4 データ構造を占めるようにするということです。このようにして、ext3 ファイルシステムをオンラインで ext4 ファイルシステムへ移行することができます。

タイムスタンプの分解能と範囲の改善

驚くべきことに、ext4 より前の拡張ファイルシステムでは、タイムスタンプの単位は秒でした。大多数の設定ではこれで十分ですが、プロセッサーの高速化とインテグレーション (マルチコア・プロセッサー) が進んで Linux がハイパフォーマンス・コンピューティングなどの他のアプリケーション・ドメインでも利用されるようになるにつれ、秒単位のタイムスタンプでは間に合わなくなってきます。ext4 はタイムスタンプの LSB がナノ秒を表すように拡張することによって、事実上今後のタイムスタンプへの要求にも応えることができるようにしています。さらに表すことができる時間の範囲もビットを 2 つ追加して拡張されたことにより、サポート可能な範囲が 500 年延びています。


拡張性

ファイルシステムに対する要求がますます高まっていることを考えると、進化を続けるファイルシステムにとってとりわけ重要な側面となるのは、ファイルシステムがどれだけ拡張性に優れているかという点です。ext4 ではさまざまな形で拡張性を実現しており、ext3 での限界を超え、ファイルシステムのメタデータ管理の分野に新しい境地を開いています。

ファイルシステムに対する制限の緩和

ext4 でまず目に止まる違いの 1 つは、サポートするファイルシステムのボリューム数、ファイル・サイズ、そしてサブディレクトリー数が以前よりも増えていることです。ext4 は、最大 1 エクサバイト (1000 ペタバイト) のファイルシステムをサポートします。今日の標準に照らし合わせると、これは途方もないサイズのように思えますが、ストレージの使用量は増え続けています。つまり、ext4 が将来のことを念頭に置いて設計されたファイルシステムであることは間違いありません。また、ext4 の最大ファイル・サイズは 16 TB (4 KB のブロックを前提) です。これは、ext3 での許容サイズの 8 倍にも及びます。

ext4 ではサブディレクトリーに対する制限も大幅に緩和されました。以前はディレクトリーの深さは最大 32KB だったのが、実質的には無制限になっています。極端なようにも思えますが、エクサバイトのストレージを使用するファイルシステムの階層を考慮しなければなりません。また、ディレクトリーの索引付けもハッシュ B ツリーのような構造に最適化されました。そのため、ext4 ではさまざまな制限が大幅に緩和されているにもかかわらず、極めて高速な検索時間がサポートされます。

エクステント

ext3 で主な欠点の 1 つとなっていたのは、そのアロケーション方法です。ext3 では空きスペースのビット・マップを使用してファイルを割り当てますが、この方式は処理速度にも、拡張性にもそれほど優れていませんでした。ext3 のフォーマットは小さいファイルには非常に有効ですが、大きなファイルとなると恐ろしく非効率的です。そこで、ext4 では ext3 のメカニズムをエクステントに置き換えることでアロケーション方法を改善し、より効率的なストレージ構造をサポートするようになっています。エクステントとは、単に隣接するブロックの配列を表す手段です。エクステントでブロック配列を表すと、メタデータは縮小されます。なぜならエクステントは、ブロックごとの格納場所を管理する代わりに、隣接するブロックの格納場所を示す 1 つの長いリストを管理するからです (そのため、メタデータ・ストレージが全体的に少なくなります)。

ext4 でのエクステントは、小さなファイルを効率的に表す階層化手法だけでなく、大きなファイルを効率的に表すエクステント・ツリーも採用します。例えば、単一の ext4 i ノードには 4 つのエクステント (それぞれのエクステントが一連の隣接するブロックを表します) を参照するのに十分なスペースがあります。大きなファイルの場合には (フラグメント化されたファイルも含まれます)、i ノードが索引ノードを参照し、索引ノードのそれぞれが (複数のエクステントを参照する) リーフ・ノードを参照することができます。この一定の深さのエクステント・ツリーが、分散される可能性のある大きなファイルを表現するための充実したスキームを提供するというわけです。さらにこれらのノードには、ファイルシステムの破損防止に対して保護するための自己チェック・メカニズムも組み込まれます。


パフォーマンス

新しいファイルシステムを測定するための特性として特に重要なのは、ファイルシステムの基本パフォーマンスですが、パフォーマンスは最も難しい分野の 1 つでもあります。巨大なサイズに成長したファイルシステムに、非常に高い信頼性が要求される場合には、最終的にパフォーマンスが犠牲になる可能性があるからです。しかし、ext4 は拡張性と信頼性に対処すると同時に、パフォーマンスを向上させるための数々の機能強化も行っています。

ファイル・レベルのプリアロケーション

データベースやコンテンツ・ストリーミングなどといった特定のアプリケーションでは、ファイルが隣接するブロックに保存されることを大前提とします (ドライブの連続ブロックに対する Read 操作の最適化を活用するため、そして Read コマンド対ブロックの比率を最大限にするためです)。エクステントによって隣接するブロックのセグメントを提供することもできますが、もう 1 つの強力な方法は、必要なサイズの隣接ブロックからなる非常に大きなセクションを事前に割り当てることです (かつて XFS で実装していた方法です)。ext4 ではこの方法を実装する手段として、指定したファイル・サイズを事前に割り当てて初期化する新しいシステム・コールを使用します。こうすることで、事前に割り当てたセクションに必要なデータを書き込めば、そのデータに対する Read 操作のパフォーマンスを優れたものにすることができます。

ブロックの遅延アロケーション

ファイル・サイズを基準としたもう 1 つの最適化は、遅延アロケーションです。このパフォーマンス最適化では、物理ブロックがディスクにフラッシュされるまで、ディスク上での物理ブロックの割り当てを遅らせます。この最適化の鍵となるのは、物理ブロックの割り当てをディスクへの書き込みが必要になるまで遅らせることによって、より多くのブロックが隣接するようにブロックを割り当てて書き込むことです。これは、ファイルシステムがタスクを自動的に実行するという点を除き、永続的なプリアロケーションと似ています。ただし、ファイルのサイズが事前にわかっている場合の手段としては、永続的なプリアロケーションが最適です。

マルチブロック・アロケーション

最後に紹介する最適化 (同じく隣接ブロックに関連する最適化) は、ext4 のブロック・アロケーターです。ext3でのブロック・アロケーターは、一度に 1 つのブロックを割り当てることによって動作していましたが、複数のブロックが必要となった場合には、連続していないブロックに隣接データが見つかることもありました。ext4 ではこの問題を、ブロック・アロケーターがディスク上で隣接している可能性の高い複数のブロックを一度に割り当るようにすることによって解決しています。今まで紹介した最適化と同じく、この最適化でも連続ブロックに対する Read 操作の最適化を最大限に活用するために、ディスク上で関連データを収集します。

マルチブロック・アロケーションが持つもう一つの側面は、ブロックの割り当てに必要な処理量です。前述のように、ext3 では一度に 1 つのブロックを割り当てていたため、最も単純な場合でもブロックごとにブロック・アロケーターを呼び出さなければなりませんでした。複数のブロックを一度に割り当てることで、ブロック・アロケーターを呼び出す回数は少なくなり、その結果、アロケーション時間の短縮と処理量の削減が実現します。


信頼性

ext4 によってファイルシステムのサイズが大きくなるにつれ、当然、信頼性についての懸念も大きくなっていきます。この問題に対処するため、ext4 にはいくつもの自己保護メカニズム、自己修復メカニズムが組み込まれています。

ファイルシステム・ジャーナルのチェックサム

ext3 と同じく、ext4 もジャーナリング・ファイルシステムです。ジャーナリングとはファイルシステムに対する変更をジャーナルを使用して記録するプロセスのことで、ジャーナルとは、ディスクの隣接する領域にある専用の循環ログのことです。ジャーナリング・ファイルシステムでは、ログから物理ストレージに対する実際の変更はログから行われるため、処理の途中でシステム・クラッシュや電源断が発生したとしても、変更を確実に行い、整合性を保つことができます。したがって、ファイルシステムが破損する可能性も少なくなるというわけです。

しかしジャーナリングでさえも、エラーのあるエントリーがジャーナルに入り込んだとしたら破損の可能性は免れません。この問題の対処法として、ext4 ではジャーナルのチェックサムを実装し、基礎となるファイルシステムに有効な変更が確実に適用されるようにしています。ext4 の重要な側面であるジャーナリングについては、「参考文献」セクションで参考となる資料を紹介しています。

ext4 はユーザーの必要に応じた複数のジャーナリング・モードをサポートします。例えば、メタデータのみをジャーナルに記録する Writeback モード、メタデータをジャーナルに記録する一方、データの書き込みはメタデータがジャーナルから書き込まれた時点で行う Ordered モード、そしてメタデータとデータの両方をジャーナルに記録する Journal モード (最も信頼性の高いモード) です。注意する点として、Journal モードはファイルシステムの整合性を保つ最善の方法ですが、すべてのデータがジャーナルを通過することになるため、処理速度に関しては他のモードに比べて劣ります。

オンライン・デフラグ

ext4 にはファイルシステム内の断片化を抑える機能 (連続ブロック・アロケーション用のエクステント) が組み込まれているとは言え、長い時間が経過するうちに、ある程度の断片化がファイルシステムに発生するのは避けられません。この理由から存在するのが、ファイルシステムと個々のファイルの両方をデフラグしてパフォーマンスを向上させるオンライン・デフラグ・ツールです。オンライン・デフラグ・ツールは単純なツールで、隣接するエクステントを参照する新しい ext4 i ノードにファイルをコピーするだけに過ぎません。

オンライン・デフラグのもう 1 つの特徴は、ファイルシステム・チェック (fsck) の所要時間が短縮されることです。ext4 は i ノード・テーブルに含まれる使用されていないブロックのグループにマークを付け、fsck プロセスに未使用のブロックを完全にスキップさせてチェック・プロセスを迅速化します。ファイルシステムのサイズが大きくなり、分散の度合いが増すにつれて、内部破損が発生するのは避けられませんが、このような内部破損のためにオペレーティング・システムがファイルシステムの妥当性を検証する必要があるとを判断するということは、ext4 の全体設計が、全体的な信頼性を向上させているということを意味します。


今後の展開

1992年に初めて ext に導入されてから 2008年の ext4 導入に至るまで、拡張ファイルシステムが Linux のなかで長い充実した歴史を刻んでいることは確かです。Linux 専用に設計された最初のファイルシステム、ext1 は当時、効率性と安定性に最も優れた強力なファイルシステムの 1 つであることを実証しました。ファイルシステムの調査によって進化した ext4 は、他の新種のファイルシステムで採り入れられている概念 (XFS、JFS、Reiser、そして IRON 耐障害性ファイルシステムの手法など) を採り入れ、高度な機能を備えています。ext5 に何が用意されているのかを知るにはまだ早すぎますが、企業に対応した Linux システムへの道を進んでいくことは確かです。

参考文献

学ぶために

製品や技術を入手するために

  • kernel.org から最新のカーネル・リリースをダウンロードしてください。
  • developerWorks から直接ダウンロードできる IBM ソフトウェアの試用版を使用して、Linux で次の開発プロジェクトを構築してください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=376125
ArticleTitle=ext4 の徹底調査
publish-date=02172009