Linux ジャーナリング・ファイルシステムの徹底調査

ジャーナリングの今と未来

最近まで、ジャーナリング・ファイルシステムは特異なものであり、主にファイルシステムに関する研究という側面から考えられていました。しかし今では、そのジャーナリング・ファイルシステム (ext3) が Linux® のデフォルトとなっています。この記事では、ジャーナリング・ファイルシステムの背後にある概念、そしてこのファイルシステムが電源断やシステムのクラッシュにもかかわらず整合性を維持する方法を説明します。現在使用されているさまざまなジャーナリング・ファイルシステムについて学ぶとともに、次世代のジャーナリング・ファイルシステムを覗いてみてください。

M. Tim Jones (mtj@mtjones.com), 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. の顧問エンジニアでもあります。



2008年 6月 04日

ジャーナリング・ファイルシステムはさまざまに定義することができますが、単刀直入に言わせてもらえば、ジャーナリング・ファイルシステムとは、ブート時に fsck、つまりファイルシステム整合性チェック・プロセスを監視するのに飽き飽きしている人々 (そして耐障害性ファイルシステムという考えに賛成するすべての人々) のためのファイルシステムです。システムがジャーナリング・ファイルシステムではない従来のファイルシステムを使用している場合、システムが不正にシャットダウンするとオペレーティング・システムがこれを検知し、fsck ユーティリティーによる整合性チェックを行います。このユーティリティーはファイルシステムをスキャンして (かなり長い時間がかかることがあります)、安全に修正できる問題すべてを修正します。それでもファイルシステムの状態がかなり悪い場合には、ユーザーがさらに修正プロセスを行えるように、オペレーシング・システムがシングル・ユーザー・モードで起動することもあります。

fsck を斬る

さらに面倒なことに、マウント時にファイルシステムのメタデータが正しいものであることに確認するために (破損が検出されていない場合でも) オペレーティング・システムが fsck プロセスを自動的に開始することもあります。したがって、ファイルシステム整合性チェックの必要性をなくすことがファイルシステムを改善する手立てであることは明らかです。

ジャーナリング・ファイルシステムがどのような人々を対象に作成されたかは上記のとおりですが、それではどうやって fsck の必要性をなくすのでしょうか。概して言うと、ジャーナリング・ファイルシステムはジャーナルを維持することによってファイルシステムの破損を防ぎます。ジャーナルとは、ファイルシステムに対して行われる変更を循環バッファーに記録する特殊なファイルのことです。ジャーナルは定期的にファイルシステムにコミット (フラッシュ) されます。そのためクラッシュが発生した場合には、ジャーナルをチェックポイントとして使用して、未保存の情報を回復し、ファイルシステムのメタデータの破損を回避することができます。

以上をまとめると、ジャーナリング・ファイルシステムは耐障害性ファイルシステムであり、ファイルシステムに変更がコミットされる前にジャーナルを使用してその変更をログに記録することによって、メタデータの破損を回避します (図 1 を参照)。しかし多くの Linux ソリューション同様、ジャーナリング・ファイルシステムには 1 つだけではなく、複数の選択肢があります。まずはジャーナリング・ファイルシステムの歴史を簡単に説明した後、選択可能なファイルシステムとそれぞれの違いを検討していきます。

メタデータとは何か

メタデータとは単に、ディスク上のデータ管理構造のことを指します。メタデータはファイルの作成と削除、ディレクトリーの作成と削除、ファイル拡張、ファイル切り捨てなどを表します。

図 1. 標準的なジャーナリング・ファイルシステム
標準的なジャーナリング・ファイルシステム

Linux ジャーナリング・ファイルシステムの歴史

最初にジャーナルを使用したファイルシステムは、IBM® JFS (Journaled File System) です。JFS は 1990年に初めてリリースされましたが、Linux で現在サポートされているバージョンは、その後開発された JFS2 です。1994年には Silicon Graphics が IRIX オペレーティング・システム向けハイパフォーマンス XFSを発表しました。XFS は 2001年に Linux に移植されています。SFS (Smart File System) は 1998年に Amiga を対象に開発されたジャーナリング・ファイルシステムですが、LGPL (GNU Lesser General Public License) のもとでリリースされ、2005年に Linux でサポートされるようになりました。最もよく使われているジャーナリング・ファイルシステムは ext3fs (第 3 世代の拡張ファイルシステム) で、これはジャーナリング機能を加えた ext2 の拡張版です。ext3fs は 2001年から Linux でサポートされています。さらに ReiserFS ジャーナリング・ファイルシステムが発表されて広範に採用されるようになると多くの新しい可能性が出てきましたが、作成者の法的問題からその進展は現在止まっています。


ジャーナリングのバリエーション

ジャーナリング・ファイルシステムは、ファイルシステムに対する変更をバッファーに入れるためにジャーナルを使用しますが (ジャーナルはクラッシュ・リカバリーにも使用されます)、ジャーナリングのタイミングと対象にはさまざまなストラテジーが用いられます。そのうち最もよく使用されているのが、writeback、ordered、data の 3 つのモードです。

writeback モードでは、メタデータのみがジャーナリングされて、データ・ブロックはディスク上のそれぞれのロケーションに直接書き込まれます。このモードはファイルシステムの構造を維持して破損を防ぎますが、データ破損が発生する可能性はあります (メタデータがジャーナリングされてからデータ・ブロックが書き込まれる前にシステムがクラッシュした場合など)。この問題を解決するには、ordered モードを使用できます。ordered モードでもジャーナルに記録するのはメタデータだけですが、データを書き込んでからメタデータのジャーナリングが行われるため、データとファイルシステムのリカバリー後の整合性が保証されます。さらに、データのジャーナリングもサポートできるのが、3 つ目のストラテジーである data モードです。このモードでは、メタデータとデータの両方がジャーナリングされるため、ファイルシステムの破損とデータ損失が最大限保護されることになります。ただし、すべてのデータが 2 度書き込まれるため (最初にジャーナルに書き込まれ、次にディスクに書き込まれます)、パフォーマンスが劣化するという問題があります。

ジャーナル・コミット・ポリシーにも、さまざまな方法があります。例えば、ジャーナルがいっぱいになりそうになったらコミットする、あるいはタイムアウトによってコミットするなどです。


ジャーナリング・ファイルシステムの現在

現在、いくつかのジャーナリング・ファイルシステムが盛んに使われていますが、それぞれに固有の利点と欠点があります。ここでは、現在最もよく使われている 4 つのジャーナリング・ファイルシステムを取り上げます。

JFS2

JFS2 (拡張ジャーナル・ファイルシステムとも呼ばれます) は最初にジャーナルを使用したファイルシステムで、Linux に移植されるまで長年、IBM AIX® オペレーティング・システムで使用されていました。JFS2 は最初の JFS をベースとして拡張性を高め、マルチプロセッサー・アーキテクチャーをサポートできるように強化した64 ビットのファイルシステムです。

JFS2 は ordered ジャーナリングをサポートし、高速なファイルシステム・リカバリーによるハイパフォーマンスを実現します。さらに、パフォーマンスを目的としてエクステント・ベースのファイル・アロケーションを行います。エクステント・ベースのアロケーションとは、単に 1 つのブロックを割り当てる代わりに連続した一連のブロックを割り当てるという意味です。これらのブロックはディスク上で連続していることから、ブロックの読み取りおよび書き込みパフォーマンスが向上します。エクステント・ベースのアロケーションには、メタデータの管理を最小限にできるという利点もあります。ブロック単位でスペースを割り当てるということは、ブロックごとにメタデータが更新されるということです。エクステントを使用すれば、メタデータはそのエクステント (多数のブロックを表す場合もあります) の分だけ更新されることになります。

JFS2 はまた、ディレクトリーも高速検索ならびにエクステント記述子の管理に B+木を利用します。JFS2 は内部ジャーナル・コミット・ポリシーを持たない代わりに、kupdate デーモンのタイムアウトを利用します。

XFS

XFS も初期のジャーナリング・ファイルシステムの 1 つで、元々は Silicon Graphics が 1995年に IRIX オペレーティング・システム向けに開発したものです。XFS は 2001年に Linux に移植されました。したがって、その時点ですでに完成度も信頼性も高いジャーナリング・ファイルシステムだったということです。

XFS は完全な 64 ビット・アドレッシングをサポートし、ディレクトリーとファイル・アロケーションの両方に B+木を使用して非常に優れたパフォーマンスを実現します。さらに、XFS は可変ブロック・サイズ (512 バイトから 64 KB まで) のサポートを備えたエクステント・ベースのアロケーションを使用します。エクステントの他に XFS が使用する遅延アロケーションでは、ブロックがディスクに書き込まれるまで、ディスク・ブロックの割り当てが遅延されます。この機能では必要となるブロック数の合計が既知になるため、連続したディスク・ブロックを割り当てられる確率が上がります。

その他の XFS の興味深い特徴としては、I/O速度の保証 (ファイルシステム・ユーザー用の帯域幅を予約することにより実現)、そしてデータを複数のバッファーに保存する代わりにディスクとユーザー空間バッファーとの間で直接コピーするダイレクト I./O があります。XFS は writeback ジャーナリング・ポリシーを使用します。

ext3fs

ext3fs (第 3 世代拡張ファイルシステム) は最もよく使用されているジャーナリング・ファイルシステムで、人気の高い ext2 ファイルシステムを進化させたものです。実際、ext3fs は ext2fs と互換性があります。ext3fs は ext2fs と同じ構造にジャーナルを追加しただけなので、ext3fs パーティションを ext2 ファイルシステムとしてマウントすることも、ext2 ファイルシステムを ext3 ファイルシステムに変換することもできます (tune2fs ユーティリティーを使用)。

ext3fs では 3 つのジャーナリング・タイプ (writeback、ordered、data) を使用できますが、デフォルトでは ordered モードが使用されます。ジャーナル・コミット・ポリシーは構成可能ですが、デフォルトではジャーナルの 4 分の 1 がいっぱいになった時点、あるいはコミット・タイマーの 1 つがタイムアウトになった時点を基準とします。

ext3fs の主な欠点の 1 つは、元々ジャーナリング・ファイルシステムとして設計されたものではないという点です。ext2fs がベースとなっているため、他のジャーナリング・ファイルシステムに備わっている最近の高度な機能 (エクステントなど) の一部を揃えていません。さらに、ReiserFS、JFS、XFS と比べるとパフォーマンスの点で劣りますが、競合ソリューションほどには CPU およびメモリーを必要としません。

ReiserFS

テール・パッキングについて

多くの場合、ファイルは論理ブロックのサイズに満たないサイズで存在します。テール・パッキングとは、小さなファイル (テール) ごとに論理ブロックを割り当ててスペースを無駄にする代わりに、複数のファイルを集めて 1 つの論理ブロックに格納する機能です。この機能により、他のファイルシステムに比べてディスク・スペースが 5% 増加することが明らかになっています (ただし、パフォーマンスには不利な条件となります)。

ReiserFS は、始めからジャーナリングを考慮して開発されたジャーナリング・ファイルシステムで、2001年に主流の 2.4 カーネルに導入されました (Linux が初めて採用したジャーナリング・ファイルシステムです)。デフォルトのジャーナリング方式は ordered 方式で、オンライン・サイズ変更によるファイルシステムの拡張をサポートします。ReiserFS には、動的に断片化を抑えるテール・パッキング (Tail Packing) という機能も組み込まれています。ファイルのサイズが小さい場合、ReiserFS は ext3fs よりも遥かに処理速度に優れています (Tail Packing が有効な場合)。

ReiserFS (ReiserFS v3 とも呼ばれます) には、B+木をはじめとする最近の新しい機能の多くが組み込まれています。ファイルシステムの基本的なフォーマットは単一の B+木をベースとするため、検索の動作が効率化されると同時に、極めてスケーラブルになります。コミット・ポリシーはジャーナルのサイズによって異なりますが、その基準となるのはコミットするブロックの数です。

ReiserFS はこれまで、いくつかの問題に悩まされてきました。最近の問題は、この作成者の法的問題です (詳細は「参考文献」を参照)。


ジャーナリング・ファイルシステムの今後

ここまでで現在 (そして過去) のジャーナリング・ファイルシステムを説明したので、ここからは将来期待できる (または期待できない) ジャーナリング・ファイルシステムに目を向けてみましょう。

Reiser4

ReiserFS が上手く Linux カーネルにマージされ、多くの Linux ディストリビューションで採用されるようになった後、Namesys (ReiserFS の開発を行った会社) は新しいジャーナリング・ファイルシステムに着手しました。この Reiser4 は、高度な機能を豊富に備えた新たなジャーナリング・ファイルシステムとしてスクラッチから設計されています。

Resier4 は、ジャーナリングの改善を目的として設計されました。その手段としては、柔軟なログ形式、そしてジャーナルがコミットされるまでのブロックの遅延アロケーション (XFS の場合と同様) を使用しています。また、Reiser4 は柔軟なプラグイン・アーキテクチャーで設計されていますが (圧縮や暗号化などの機能をサポートする目的)、これらの機能は仮想ファイルシステム (VFS) に最適だという見解から、Linux コミュニティーには拒否されました。

Namesys のオーナーに有罪判決が下されてからは、Reiser4 に関する一切の商業活動は停止しています。

ext4f (fourth extended file system)

ext4fs (第 4 世代拡張ファイルシステム) は ext3fs が進化したものです。ext4 ファイルシステムは ext3fs との後方互換性 (および前方互換性) を持つ代替ファイルシステムとして設計されている一方、多くの高度な機能も備わっています (ただし、そのうちの一部は互換性を損ねます)。 つまり、ext4fs パーティションを ext3fs としてマウントすることも、その逆も可能だということです。

まず、ext4fs は 64 ビットのファイルシステムであり、非常に大規模なボリューム (1 エクサバイト) をサポートするように設計されています。エクステントを使用するようにも設計されていますが、エクステントを使用すると ext3fs との互換性が失われます。XFS および Reiser4 と同じく、ext4fs には必要な場合にのみディスクにブロックを割り当てるための遅延アロケーションが組み込まれています (これにより断片化が抑えられます)。また ext4fs では、ジャーナルの中身に対してチェックサムの計算もすることから、より信頼性の高いジャーナルとなっています。標準の B+木または B*木ではなく、B木のバリエーションである H木を使用する ext4fs では、遥かに大規模なサブディレクトリーを使用することが可能です (ext3 は、最大32000 個のサブディレクトリをサポート)。

遅延アロケーション方式によって断片化は抑えられますが、それでも時間が経つうちに大規模なファイルシステムは断片化されていくものです。この問題に対処するため、オンライン・デフラグ・ツール (e4defrag) が開発されています。このツールでは、個々のファイル、またはファイルシステム全体のデフラグを行うことができます。

ext3fs と ext4fs との違いとしては、ファイルの日付分解能も興味深い点です。ext3 でのタイムスタンプの最小分解能は 1 秒でした。一方、Ext4fs は将来を見据えています。つまり、プロセッサーとインターフェースの速度がこのまま向上し続ければ、より優れた分解能が必要になってくるということです。そのため、タイムスタンプの最小分解能は ext4 では 1 ナノ秒となっています。

Ext4fs は Linux カーネル 2.6.19 から組み込まれるようになっていますが、安定しているとはまだ言えません。この次世代ファイルシステムの開発は引き続き行われています。そこに引き継がれた機能を考えれば、ext4fs が次世代の Linux ジャーナリング・ファイルシステムとなることでしょう。


さらに詳しく調べてください

ジャーナリング・ファイルシステムは信頼性をもたらし、システム・クラッシュや電源断の際の破損から保護します。さらに、ジャーナリング・ファイルシステムの場合、クラッシュ・リカバリーの時間が従来のファイルシステムでのリカバリー方法 (fsck を利用するなどの方法) に比べて大幅に短くなります。新しいジャーナリング機能の開発は引き続き将来に目を向けて新たなアルゴリズムを探すとともに、これまでのファイルシステムにも目を向け、JSF および XSF の機能を統合していくことになるでしょう。ジャーナリング・ファイルシステムが今後どのように進化するかははっきりしていませんが、その有用性は明らかになっています。ジャーナリング・ファイルシステムこそが、新しいファイルシステム標準です。

参考文献

学ぶために

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

  • IBM 製品の評価版をダウンロードして、DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® のアプリケーション開発ツールとミドルウェア製品を使ってみてください。

議論するために

コメント

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=316788
ArticleTitle=Linux ジャーナリング・ファイルシステムの徹底調査
publish-date=06042008