目次


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

ext3の驚き

Comments

正直に言うと、この記事では、システム上でext3を起動および実行する方法を扱う予定でした。しかしそれはやめることにしました。Andrew Morton氏の優れた「Using the ext3 filesystem in 2.4 kernels」のページ (この記事の後半の参考文献を参照) で、システムをext3に対応させる方法について既に詳しく説明されているので、ここで私がまた基礎から繰り返す必要はないでしょう。代わりにここでは、皆さんにとって有用と思われるext3に関するいくつかのトピックについて詳しく説明します。この記事をお読みになり、ext3を手に入れて動かしてみようという気になられた方は、Morton氏のページをご覧ください。

2.4カーネルの最新情報

まず2.4カーネルの最新情報をお伝えすることから始めましょう。私は以前ReiserFSについて取り上げた際に、2.4カーネルの安定性について説明しました。当時は、安定した2.4カーネルを見つけることが難しかったのですが、2.4.4-ac9カーネルを是非お使いになるようお勧めしました(2.4.4-ac9カーネルはよく知られており、当時の最新のものでした)。とりわけ実稼働環境でReiserFSファイルシステムを使用する予定の方々には、強くお勧めしました。しかしお気付きのように、2.4.4-ac9以降多くの進展があり、より新しいカーネルについて検討する時期が来たことは明らかです。

カーネル2.4.10によって、2.4シリーズはパフォーマンスとスケーラビリティーの新たなレベルに達しました (長い間私たちが期待していたことです)。それでは、Linux 2.4がそのように成長した要因は何でしょうか。キーワードは、VMです。2.4シリーズのパフォーマンスが期待したほど高くないことを察知したLinus Torvalds氏は、問題のあるLinuxのVMコードを取り除き、Andrea Archangeli氏による効率のよい優れたVM実装に置き換えました。Archangeli氏の新しいVM実装 (2.4.10で初めて実装された) は、実に優れたものであり、カーネルを著しく高速化し、システム全体の反応を高めました。2.4.10は、2.4 Linuxカーネルの開発において明らかに大きなターニング・ポイントでした。それまでは開発に大きな進展が見られず、私たちの多くは、FreeBSDの開発に携わったほうが良かったと内心思っていたものです。既に安定した2.4カーネル・シリーズに対し、このように重大な (そして切実に望まれていた) 変更を行ったTorvalds氏の偉大さに、私たちはみな感謝すべきです。

Archangeli氏の新しいVMコードを他のカーネルとシームレスに統合するには少し時間を要したため、2.4.13+ を使用することをお勧めします。2.4.16+というのも一層お勧めできる選択です。2.4.15-pre2リリースから組み込まれた安定したext3ファイルシステム・コードが、ついこのリリースで公式のLinuxカーネルに統合されたからです。2.4.16+ カーネルを使わない手はありません。これによって、ext3の起動と実行が非常に容易になるでしょう。2.4.16+ カーネルを使用する場合は、Archangeli氏のページ (参考文献を参照) で説明されているext3パッチの適用は、もはや必要ではないことは覚えておいてください。Torvalds氏が皆さんのためにすでに適用済みです。

私が使用をお勧めするのは2.4.15+ ではなく2.4.16+ だとお気付きでしょう。そしてそれには、もっともな理由があるのです。カーネル2.4.15-pre9のリリースでは、実に悪質なファイルシステム破壊バグがカーネルに発生しました。問題の特定と修正には2.4.16-pre1までかかり、結果的に、どんなことがあっても使用を回避すべきリリースが、いくつか該当しまいました (2.4.15も含みます )。2.4.16+ カーネルを使用すれば、この悪質なパッチを完全に回避することができます。

ラップトップ...要注意 ?

ext3は安定したファイルシステムであるという優れた評価があるので、かなり多くのラップトップ・ユーザーがext3に移行した際に、ファイルシステム破壊の問題に遭遇したと知り驚きました。一般に、こうした類の報告を耳にすると、ext3の使用は絶対に止めようという気になりがちですが、いろいろ調べてみると、ユーザーが抱えているディスク破壊の問題は、ext3自体には何ら関係なく、特定のラップトップ・ハード・ディスクに原因があることがわかりました。

書き込みキャッシュ

ご存じないかもしれませんが、現代のほとんどのハード・ディスクには、保留中の書き込み操作を集める「書き込みキャッシュ」というものがあります。保留中の書き込みをキャッシュに入れることによって、ハード・ディスク・ファームウェアはそれらを再配列およびグループ化し、最も速くディスクに書き込めるようにすることができます。一般に、書き込みキャッシュは非常に巧みな仕掛けと見なされています (参考文献の 「Linus' explanation and opinion of write caching」をご覧ください)。

しかし残念ながら、現在市販されているラップトップ・ハード・ディスクには、(書き込みキャッシュ中のデータをディスクに書き出して、キャッシュをフラッシュするための)公式のATA要求を無視するという、怪しげな機能を持つものがあります。これは最近までATAスペックによって許容されていましたが、設計仕様としては、ほめられたものではありません。このようなタイプのドライブでは、カーネルは、特定のブロックが実際にディスク・プラッターに記録されたことを保証できません。これは一見厄介な問題のようですが、この特殊な問題単独では、ユーザーが遭遇したデータ破壊を引き起こすことは、恐らくないでしょう。

しかし、この問題はさらに悪い問題と結び付くのです。現代のラップトップ・ハード・ディスクには、システムがリブートまたは一時停止されるたびに書き込みキャッシュの内容を捨て去るというさらに厄介な特徴を持つものがあります。もしハード・ディスクがこれらがこの両方の問題を抱えているなら、データがしょっちゅう破壊されることになるのは間違いないでしょう。そしてそれを防ぐためにLinuxにできることは何もないのです。

では、どうすればよいでしょうか。ラップトップをご使用の場合は、注意して作業を行ってください。ファイルシステムに大きな変更を行う前には、重要なファイルをすべてバックアップしてください。特にext3を使用している場合に、上記のパターンに当てはまるようなデータ破壊の問題が発生したら、障害があるのはラップトップ・ハード・ディスクかもしれないということを思い出してください。この場合は、ラップトップのメーカーに連絡し、代わりのドライブを入手できるか問い合わせる必要があるかもしれません。うまくいけば数カ月で、これらの悪質なハード・ディスクが市場から姿を消し、このような問題に関して二度と心配しなくてもよいようになるかもしれません。

皆さんを驚かせたところで、次に、ext3の様々なデータ・ジャーナリングのオプションについて見てみましょう。

ジャーナリングのオプションと書き込み待ち時間

ext3によって、ファイルシステムのマウント時に3つのデータ・ジャーナリング・モード (data=writebackdata=ordered、およびdata=journal) から1つを選択することができるようになりました。

ジャーナル・モードを指定するには、適切な文字列 (たとえばdata=journal) を /etc/fstabのオプション・セクションに追加します。または、mount を直接呼び出すときに-o data=journal コマンド行オプションを指定します。ルート・ファイルシステムで使用されるデータ・ジャーナリング・メソッドを指定する場合 (デフォルトはdata=ordered) は、rootflags と呼ばれる特別なカーネル・ブート・オプションを使用することができます。ルート・ファイルシステムを完全なデータ・ジャーナリング・モードにする場合は、rootflags=data=journal をカーネル・ブート・オプションに追加します。

data=writebackモード

data=writeback モードでは、ext3はどのような形態のデータ・ジャーナリングも行わず、XFSやJFS、ReiserFSのファイルシステムのジャーナリングと同等のものを提供します (メタデータのみ)。前回の記事で説明したように、これによって、最近修正されたファイルが、予期しなかったリブートのイベントで破壊される可能性があります。しかしそのような欠点にもかかわらず、data=writeback モードは、ほとんどの状況下で最高のext3パフォーマンスを提供します。

data=orderedモード

data=ordered モードでは、ext3は公式にはメタデータをジャーナルするだけですが、論理的にはメタデータおよびデータ・ブロックをトランザクションと呼ばれる1つのユニットにグループ化します。新しいメタデータをディスクに書き出す段になると、関連するデータ・ブロックが最初に書き込まれます。data=ordered モードは、data=writeback mode とジャーナルされた他のほとんどのファイルシステムで発見された破壊の問題を効果的に解決します。しかも完全なデータ・ジャーナリングを必要とせずに解決するのです。一般に、data=ordered ext3ファイルシステムは、data=writeback ファイルシステムよりわずかに低速ですが、同様の完全なデータ・ジャーナリングより大幅に高速で実行します。

データをファイルに追加する場合、data=ordered モードが、ext3の完全なデータ・ジャーナリング・モードによって提供される保全性の保証をすべて提供します。しかし、ファイルの一部を上書き中にシステムがクラッシュした場合、書き込み中の領域には、元のブロックと更新されたブロックが混在した状態で含まれるでしょう。その理由は、どのブロックが最初に上書きされるかに関して、data=ordered が何の保証も提供しないからです。そのため、上書きされたブロックxが更新されたという理由だけで、上書きされたブロックx-1も更新されたと仮定することはできません。代わりにdata=ordered は、書き込みの順序付けをハード・ディスクの書き込みキャッシュに任せます。一般に、ファイルの追加はファイルの上書きよりもはるかに一般的なので、通常このような制限がユーザーに悪影響を与えることは多くありません。このような理由で、data=ordered モードは、完全なデータ・ジャーナリングに取って代わるものであり、そのパフォーマンスははるかに優れています。

data=journalモード

data=journal モードは、完全なデータおよびメタデータ・ジャーナリングを提供します。すべての新しいデータは最初にジャーナルに書き込まれ、次に最終格納場所に書き込まれます。クラッシュが起きた時も、ジャーナルは再生することができ、データおよびメタデータを一貫した状態にします。

データが1度ではなく2度ディスクに書き込まれるので、理論的には、data=journal モードが最も低速のジャーナリング・モードです。しかし特定の状況では、data=journal モードが非常に高速になります。Andrew Morton氏は、ext3のdata=journal ファイルシステムが、信じ難いほど優れたインタラクティブなファイルシステム・パフォーマンスをユーザーに提供したというLKMLの報告を聞いた後、ちょっとしたテストを行うことにしました。まず彼は、データをできるかぎり速くテスト・ファイルシステムに書き込むためにシンプルなシェル・スクリプトを作成しました。

急速な書き込み
while true
do
	dd if=/dev/zero of=largefile bs=16384 count=131072
done

データがテスト・ファイルシステムに書き込まれている間に、彼は16Mbのデータを同一ディスク上の別のext2ファイルシステムから読み込み、その結果を測定しました。

16Mbファイルの読み込み
time cat 16-meg-file > /dev/null

結果は驚くべきものでした。data=journal モードによって、16メガファイルは、他のext3のモード、ReiserFS、さらにはext2 (ジャーナリングのオーバーヘッドがない) の9倍から13倍以上の速度で読み込めるようになりました。

ファイルシステムへの書き込み16メガ読み込み時間 (秒)
ext278
ReiserFS67
ext3data=ordered93
ext3data=writeback74
ext3data=journal7

Morton氏はこのテストを繰り返し、(異なるファイルシステムではなく) テスト・ファイルシステムから16 Mbファイルを読み込み、同じ結果を得ました。さて、これは何を意味するのでしょうか。どういうわけか、ext3のdata=journal モードは、ディスクに対してデータの読み取りと書き込みを同時に行う必要のある状況に非常に適しています。したがって、ほとんどすべての状況においてext3のdata=journal モードがext3のすべてのモードの中で最も低速であると仮定していましたが、実際は、インタラクティブなIOパフォーマンスを最大化する必要のあるビジーな環境においてdata=journal モードがパフォーマンス面で大きな利点になることがわかりました。つまり、data=journal モードは決して低速ではないのです。

Morton氏は、data=journal モードが他のモードよりはるかに優れている理由を引続き詳しく調べています。その理由がわかれば、data=writeback モードとdata=ordered モードの利点も得られるように他のext3に必要な改良を加えることができます。

data=journalの改良

ビジーなサーバー、特に、ビジーなNFSサーバー上でext3のdata=journalモードを使用した際に特有のパフォーマンス上の問題を経験した方々もいらっしゃるでしょう。こうしたサーバーでは30秒ごとに大量のディスク書き込みアクティビティーが雨あられと行われ、これによって、システムがほとんど停止してしまいます。この問題でお悩みなら、簡単に解決できます。Linuxのダーティー・バッファーをフラッシュするアルゴリズムを改良するためにルート権限で、以下のコマンドを入力してください。

bdflushの改良
echo 40 0 0 0 60 300 60 0 0 > /proc/sys/vm/bdflush

このような新しいbdflushの設定によって、kupdateが5秒ごとではなく0.6秒ごとに実行されます。さらに、これらはカーネルに、デフォルトの30秒後ではなく3秒後にダーティー・バッファーをフラッシュするように伝えます。最近修正されたデータをより定期的にディスクにフラッシュすることによって、これらの大量の書き込みを回避することができます。カーネルは書き込みをまとめて行う機会がより少ないので、この方法では若干効率が落ちます。しかしビジーなサーバーに関しては、書き込みがより一貫性を持って発生するようになり、インタラクティブなパフォーマンスが大幅に向上します。

まとめ

今回は、ext3に関して説明しました。次回は、なぞめいた点の多いXFSについて考察します。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux, Open source
ArticleID=228238
ArticleTitle=共通テーマ: アドバンスト・ファイルシステム・インプリメンター・ガイド 第8回
publish-date=12012001