共通テーマ:アドバンスト・ファイルシステム・インプリメンター・ガイド: 第7回

ext3の概要

Linux 2.4のリリースとともに、ReiserFS、XFS、GFSをはじめとするさまざまなファイルシステムが新たに登場しました。これらのファイルシステムは、厳密には何ができ、何に適しているのでしょうか。そして、Linuxの実稼働環境で安全に使用するにはどのようにすれば良いのでしょうか。Daniel Robbins氏は、これらのアドバンスト・ファイルシステムをLinux 2.4環境にセットアップする方法を示し、これらの疑問に答えています。この記事では、ジャーナリング機能が追加されたext2の新しい改良版であるext3について考察しています。

Daniel Robbins (drobbins@gentoo.org), President/CEO, Gentoo Technologies, Inc.

Daniel Robbins氏は、ニューメキシコ州アルバカーキーに住んでいます。彼は、Gentooプロジェクトのチーフ・アーキテクト、Gentoo Technologies Inc. の社長/CEOです。著書に、Macmillanから出版されているCaldera OpenLinux Unleashed、SuSE Linux Unleashed、Samba Unleashed があります。Daniel氏は、小学2年のとき初めてLogoプログラム言語や、中毒になる恐れのあったPac Manに出会って以来、何らかの形でコンピューターに関係してきています。これで、彼がなぜSONY Electronic Publishing/Psygnosisでリード・グラフィック・アーチストを務めているかが分かるでしょう。愛妻Maryさんや、生まれたばかりの愛娘Hadassahちゃんとの時間をとても大切にしています。彼の連絡先はdrobbins@gentoo.org です。



2001年 11月 01日

前回までの数回の記事では、本筋から少し外れて、tmpfsやdevfsといった、従来とは異なるファイルシステムについて考察しました。今回は、ディスク・ベースのファイル・システムに戻り、ext3について考察します。ext3ファイルシステムは、Stephen Tweedie氏の設計によるもので、従来のext2ファイルシステムのフレームワークに基づいています。実際、ext3はext2と非常によく似ています。しかし、この2つの間には、小さくても重要な違いが1つあります。それはジャーナリングのサポートです。この小さな追加だけを見ても、ext3がいくつもの驚くほど魅力的な機能を備えていることがわかるはずです。この記事では、ext3について、現在利用できる他のジャーナリング・ファイルシステムと比較しながら説明します。そして、次回の記事で、実際にext3の導入を行うことにしましょう。

ext3を理解する

まず、ext3とReiserFSを比較してみましょう。以前の記事で、ReiserFSは小さいファイル(4K未満)の処理に適しており、状況によって、小さいファイルに対するReiserFSのパフォーマンスは、ext2やext3の「10~15倍」に達すると述べました。ReiserFSにはさまざまな長所がありますが、また、短所もあります。実際に、ReiserFSの現在の実装(バージョン3.6)では、特定のファイル・アクセス・パターンに対するパフォーマンスがext2やext3と比べて「著しく劣る」傾向があります。これは、特に大規模なメール・ディレクトリーの読み込みの場合に顕著です。また、ReiserFSは、NFSとの互換性に関して実績がなく、スパース・ファイルに対するパフォーマンスも振るいません。それにひきかえ、ext3は非常に「バランスの取れた」ファイルシステムです。ext2と同様、ReiserFSのように小さいファイルに対するパフォーマンスが特に優れているわけではありませんが、パフォーマンスや機能に関して予期しない問題が発生することもありません。

ext3の素晴らしい特長の1つは、それがext2コードをベースにしているため、ext2と共通のディスク・フォーマットを持っているということです。これは、ext3ファイルシステムを正しくアンマウントすれば、ext2ファイルシステムとしてまったく問題なく再マウントできることを意味します。それだけではありません。ext3はext2と同じメタデータを使用するため、「ext2からext3にそのままアップグレードする」ことも可能です。つまり、主要なシステム・ユーティリティーをいくつかアップグレードし、最新の2.4カーネルをインストールして、各ファイルシステムごとに「tune2fs」コマンドを実行するだけで、既存のext2サーバーをジャーナリングext3システムに移行することができます。この作業は、ext2ファイルシステムが「マウントされた状態」でも行うことができます。この移行は安全かつ取り消しが可能で、しかも驚くほど簡単です。また、XFS、JFS、ReiserFSなどへの移行とは異なり、ファイルシステムのバックアップやファイルシステムを最初から作成し直す必要はありません。ext3へのアップグレードが考えられる本番用ext2サーバーが数千台は存在することを考えれば、ext3がLinuxコミュニティーにとっていかに重要であるかがわかります。

ext3の特徴を一言で説明するなら、それは「安心感」でしょう。既存のext2システムをext3対応にする作業は驚くほど簡単であり、パフォーマンスの急激な変化もありません。また、ext3の優れている点は安心感だけではありません。それは、ext3がLinux向けジャーナリング・ファイルシステムの中で最も信頼性が高いものの1つであるということです。次に、この点について説明しましょう。


ext3の信頼性

ext2互換であることに加えて、ext3はext2と共通のメタデータ・フォーマットを採用することによって、その他の利点も受け継いでいます。その一例は、ext3ユーザーが堅牢なfsckツールを利用できるという点です。ジャーナリング・ファイルシステムを使用する目的の1つとしては、きわめて時間のかかるfsckの必要性をなくすということがまず挙げられますが、不安定なカーネルやハード・ドライブの故障などが原因でメタデータが破壊された場合、ext3がext2のfsckを継承していることは大きなメリットとなります。それに比べて、ReiserFSのfsckはまだ開発の初期段階にあり、破損したメタデータをそうしたツールで修復することは困難であると同時に危険であると言えます。

メタデータ限定のジャーナリング

興味深いことに、ext3のジャーナリングの方法は、ReiserFSや他のジャーナリング・ファイルシステムとはまったく異なります。ReiserFSやXFS、JFSの場合、ファイルシステム・ドライバーは「メタデータ」のジャーナリングは行いますが、「データ」のジャーナリングは行いません。「メタデータ限定」のジャーナリングにより、ファイルシステムのメタデータは堅牢なものとなり、時間のかかるfsckの実行はほとんど必要なくなります。しかし、予期しないリブートやシステムのロックアップが発生した場合には、直前に変更した「データ」が大幅に破壊される恐れがあります。ext3では、これらの問題を回避するいくつかの画期的な解決方法が採用されています。次に、この点について少し見てみましょう。

その前に、メタデータ限定のジャーナリングがなぜ問題となる恐れがあるのかを正しく理解しておくことが大切です。一例として、/tmp/myfile.txtというファイルの変更に伴い、マシンが突然ロックアップしてリブートせざるを得なくなった場合について考えてみましょう。もし、ReiserFS、XFS、JFSなどのメタデータ限定のジャーナリング・ファイルシステムを使用していたとすれば、メタデータ・ジャーナルのおかげで、ファイルシステムのメタデータは簡単に修復でき、時間のかかるfsckが完了するまでじっと待つ必要はないことになります。

ところが、/tmp/myfile.txtをテキスト・エディターにロードしてみると、直前の変更内容が失われているだけでなく、無意味なデータが大量に含まれていたり、場合によってはまったく読めなくなっていたりする可能性があることは明らかです。必ずそうなるとは限りませんが、その「可能性は高い」でしょう。

原因はこうです。ReiserFS、XFS、JFSのような一般的なジャーナル・ファイルシステムでは、メタデータに対して特別な配慮が払われていますが、データ自体はあまり考慮されていません。先の例では、ファイルシステム・ドライバーがファイルシステムの数ブロックを変更している最中で、該当するメタデータは更新されましたが、キャッシュからディスク上の新しいブロックにデータをフラッシュする時間はありませんでした。その結果、/tmp/myfile.txtをテキスト・エディターにロードした際、システムがロックする前に初期化されなかったデータのブロックが無意味なデータとして、そのファイルの一部(または全部)に含まれていたというわけです。


ext3のアプローチ

この問題についてだいたい理解できたと思いますので、ext3でのジャーナリングの方法について見てみましょう。ext3のジャーナリング・コードは、Journaling Block Device(JBD)レイヤーと呼ばれる専用APIを使用しています。JBDは、あらゆる種類のブロック・デバイスに対してジャーナリングを行うという明確な目的に基づき設計されています。ext3は、JBD APIへの「接続」によってジャーナリングを実現します。たとえば、ext3ファイルシステム・コードは、実行中の変更内容をJBDに知らせるだけでなく、ディスク上の特定のデータを変更する前にJBDの許可を求めます。それにより、JBDは適宜、ext3ファイルシステム・ドライバーに代わってジャーナルを管理することができるようになります。これは非常に素晴らしい仕組みです。また、JBDは別個の汎用エンティティーとして開発されているため、将来、他のファイルシステムにジャーナリング機能を追加する際に利用することができます。

JBDによって管理されるext3ジャーナルには、いくつかの優れた点があります。その1つは、ext3のジャーナルはiノードに格納されるという点です。これは、基本的には1つのファイルですが、ファイルシステムを「ext3対応」にする方法によっては、/.journalにあるこのファイルが見える場合とそうでない場合があります。当然ですが、ジャーナルをiノードに格納することにより、ext3はext2メタデータに互換性のない拡張を行わなくとも、必要なジャーナルをファイルシステムに追加することができます。これは、ext3ファイルシステムがext2メタデータならびにext2ファイルシステム・ドライバーと下位互換性を維持するための重要な手段の1つです。


ジャーナリングに対するさまざまなアプローチ

驚くほどのことではありませんが、ジャーナルにはいくつかの方法があります。たとえば、変更が必要な「バイト範囲」をホスト・ファイルシステム上に格納するようにジャーナルを設計する方法があります。このアプローチの特長は、変更が必要な個々のバイトだけが記録され、それ以外は記録されないため、数多くの小さな変更を非常に効率よくファイルシステムに格納できることです。

JBDは、それとは別の意味で優れたアプローチを採用しています。JBDは、変更すべきバイト範囲を記録するのではなく、変更されたファイルシステム・ブロック全体をそのまま格納します。ext3ファイルシステム・ドライバーもこのアプローチをとっており、処理中の入出力操作を追跡できるように、変更されたブロック(1K/2K/4K)の完全な複製をメモリー内に格納します。一見すると、これはちょっと無駄のように見えますが、なんと言っても、ブロック全体には変更されたデータだけでなく、変更されていない(ディスク上にある)データも含まれています。

JBDのアプローチは、「物理ジャーナリング」と呼ばれます。これは、JBDがジャーナリングの基本単位として物理ブロック全体を使用することを意味しています。対照的に、ブロック全体ではなく変更されたバイト範囲だけを格納するアプローチは「論理ジャーナリング」と呼ばれ、XFSによって採用されています。ext3は物理ジャーナリングを採用しているため、ext3ジャーナルはXFSジャーナルなどと比べて多くのディスク・スペースを「使い」ますが、内部およびジャーナル内でブロック全体を使用していることから、ext3の処理は論理ジャーナリングを行う必要がある場合ほど複雑にはなりません。また、ブロック全体を使用することで、1つのブロック内にある複数の処理中の入出力操作を同じメモリ内データ構造に「スキッシュイング(圧縮)」するといった最適化の実行も可能となります。これにより、ext3はこれらの複数の変更を、複数の書き込み操作ではなく1回の操作でディスクに書き込むことができます。さらに、リテラル・ブロック・データがメモリー内に格納されるため、ディスクへの書き込み前のメモリー内データの操作がほとんど必要なくなり、CPUのオーバーヘッドが大幅に減少します。


データのプロテクターとしてのext3

最後に、ext3ファイルシステムがどのようにしてメタデータとデータの「両方」をジャーナル処理し、前述のデータ破壊の問題を防止するのかについて見てみましょう。実際には、ext3は2つの方法によってデータとメタデータの保全性を確保します。

当初、ext3はフル・データ・ジャーナリングとフル・メタデータ・ジャーナリングを実行するように設計されていました。このモード(「data=journal」モード)では、JBDは、データとメタデータのどちらに対するものかに関係なくすべての変更をファイルシステムにジャーナル処理します。データとメタデータの両方がジャーナル処理されているため、JBDはジャーナルを使用してメタデータと「データ」ブロックのいずれも整合状態に維持することができます。フル・データ・ジャーナリングの欠点はその速度ですが、ジャーナルを比較的大きく設定すればパフォーマンスの低下を軽減することが可能となります。

最近、大幅なパフォーマンスの低下を伴わずにフル・ジャーナリングのメリットを提供する新しいジャーナリング・モードが、ext3に追加されました。この新しいモードは、メタデータのみのジャーナル処理を行いますが、ext3ファイルシステム・ドライバーが各メタデータの更新に対応する特定のデータ・ブロックを記録し、トランザクションと呼ばれる1つのエンティティーにそれらをグループ化します。正式にトランザクションをファイルシステムに適用すると、まずデータ・ブロックがディスクに書き込まれます。その書き込みが完了すると、メタデータの変更がジャーナルに書き込まれます。ext3は、この手法(「data=ordered」モード)により、メタデータの変更のみをジャーナルに記録しながら、その一方で、データとメタデータの整合性の維持を可能とします。ext3は、デフォルトではこのモードを使用します。


まとめ

最近では、多くの人がどのLinuxジャーナリング・ファイルシステムが「ベスト」であるかを決めようとしています。実際のところ、あらゆるアプリケーションに適する「有力」なファイルシステムはなく、また、どのファイルシステムにもそれぞれの長所があります。これは、選択候補となる次世代Linuxファイルシステムがそれだけ多くあることのメリットの1つと言えます。したがって、「ベスト」なファイルシステムを独断的に選んで、すべてのアプリケーションに使用するのではなく、各ファイルシステムの長所と短所を理解した上で賢く選ぶのがよいでしょう。

ext3にはさまざまな長所があります。まず第1に、きわめて簡単に導入できるように設計されています。また、堅牢なext2ファイルシステム・コードをベースにしており、優れたfsckツールを受け継いでいます。そして、ext3のジャーナリング機能は、メタデータとデータのいずれの保全性も確保できるように設計されています。全体として、ext3は実に優れたファイルシステムであり、今となっては時代遅れの感のあるext2ファイルシステムの後継と呼べるものです。次回の記事では実際にext3を導入しますので、お見逃しのないように。それまでに、以下の参考文献を確認しておいてください。

参考文献

コメント

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, Open source
ArticleID=228237
ArticleTitle=共通テーマ:アドバンスト・ファイルシステム・インプリメンター・ガイド: 第7回
publish-date=11012001