SUSE Linux Enterprise Serverでは、多様なファイルシステムを選択できます。このセクションでは、それらのファイルシステムの機能および利点の概要を説明します。
ただし、すべてのアプリケーションに最適なファイルシステムは存在しません。各ファイルシステムには特定の利点と欠点があり、それらを考慮する必要があります。 最も高度なファイルシステムを選択する場合でも、適切なバックアップ戦略が必要です。
このセクションで使用されるデータの完全性およびデータの一貫性という用語は、ユーザスペースデータ(ユーザが使用するアプリケーションによりファイルに書き込まれるデータ)の一貫性を指す言葉ではありません。ユーザスペースのデータが一貫しているかどうかは、アプリケーション自体が管理する必要があります。
重要: このセクションで特に指定のない限り、パーティションおよびファイルシステムの設定または変更に必要なすべてのステップは、YaSTを使用して実行できます。
Ext2の起源は、Linuxの歴史の初期にさかのぼります。 その前身であったExtended File Systemは、1992年4月に実装され、Linux 0.96cに統合されました。 Extended File Systemは多くの変更を加えられ、Ext2として数年にわたって、最も人気のあるLinuxファイルシステムになりました。 その後、ジャーナルファイルシステムが作成され、回復時間が非常に短くなったため、Ext2の重要性は低下しました。
Ext2の利点の概要を読むと、Ext2が、かつて幅広く好まれ、そして今でも一部の分野で多くのLinuxユーザから好まれるLinuxファイルシステムである理由がわかります。
古くからある標準
として、Ext2は過去に多くの改良がなされ、繰り返しテストされてきました。 これが、Ext2がしばしば非常に堅実と評される理由かもしれません。ファイルシステムが正常にアンマウントできず、システムが機能停止した場合、e2fsckはファイルシステムのデータの分析を開始します。 メタデータは一貫した状態に戻り、保留されていたファイルとデータブロックは、指定のディレクトリ(lost+found)に書き込まれます。 ジャーナルファイルシステムとは対照的に、e2fsckは、最近変更されたわずかなメタデータだけではなく、ファイルシステム全体を分析します。 この結果、ジャーナルファイルシステムがログデータだけをチェックするのに比べて、かなり長い時間を要します。 ファイルシステムのサイズにもよりますが、この手順は30分またはそれ以上を要することがあります。 したがって、高可用性を必要とするどのようなサーバでも、Ext2を選択することは望ましくありません。 ただし、Ext2はジャーナルを維持せず、非常にわずかなメモリを使用するだけなので、時には他のファイルシステムより高速なことがあります。
Ext3は、Ext2のコードをベースとし、Ext2のオンディスクフォーマットとメタデータフォーマットも共用するので、Ext2からExt3へのアップグレードは非常に容易です。
Ext3は、Stephen Tweedieによって設計されました。 他のすべての次世代ファイルシステムとは異なり、Ext3は完全に新しい設計理念に基づいているわけではありません。 Ext3は、Ext2をベースとしています。 これら2つのファイルシステムは、互いに非常に似通っています。 Ext3ファイルシステムを、Ext2ファイルシステムの上に構築することも容易です。 Ext2とExt3の間にある最も重要な違いは、Ext3がジャーナルをサポートしていることです。 要約すると、Ext3には、次の3つの主要な利点があります。
Ext2のコードは、Ext3が次世代ファイルシステムであることを明確に主張するための強力な土台になりました。 Ext3では、Ext2の信頼性および堅実性がExt3で採用されたジャーナルファイルシステムの利点とうまく統合されています。ReiserFSまたはXFSのような他のファイルシステムへの移行はかなり手間がかかります(ファイルシステム全体のバックアップを作成し、移行先ファイルシステムを新規に作成する必要があります)が、それとは異なり、Ext3への移行は数分で完了します。 ファイルシステム全体を新たに作成しなおしても、それが完璧に動作するとは限らないので、Ext3への移行は非常に安全でもあります。ジャーナルファイルシステムへのアップグレードを必要とする既存のExt2システムの数を考慮に入れると、多くのシステム管理者にとってExt3が重要な選択肢となり得る理由が容易に分かります。Ext3からExt2へのダウングレードも、アップグレードと同じほど容易です。 Ext3ファイルシステムのアンマウントを正常に行い、Ext2ファイルシステムとして再マウントするだけです。
他のジャーナルファイルシステムは、メタデータのみ
のジャーナルアプローチに従っています。 つまり、メタデータは常に一貫した状態に保持されますが、ファイルシステムのデータ自体については、一貫性が自動的に保証されるわけではありません。Ext3は、メタデータとデータの両方に注意するよう設計されています。 注意
の度合いはカスタマイズできます。 Ext3のdata=journalモードを有効にした場合、最大の保護(データの完全性)を実現しますが、メタデータとデータの両方がジャーナル化されるので、システムの動作が遅くなります。 比較的新しいアプローチは、data=orderedモードを使用することです。これは、データとメタデータ両方の完全性を保証しますが、ジャーナルを適用するのはメタデータのみです。 ファイルシステムドライバは、1つのメタデータの更新に対応するすべてのデータブロックを収集します。 これらのブロックは、メタデータの更新前にディスクに書き込まれます。 その結果、パフォーマンスを犠牲にすることなく、メタデータとデータの両方に関する一貫性を達成できます。3番目のオプションは、data=writebackを使用することです。これは、対応するメタデータをジャーナルにコミットした後で、データをメインファイルシステムに書き込むことを可能にします。 多くの場合、このオプションは、パフォーマンスの点で最善と考えられています。 しかし、内部のファイルシステムの完全性が維持される一方で、クラッシュと回復を実施した後では、古いデータがファイル内に再登場することを許してしまう可能性があります。 Ext3では、デフォルトとして、data=orderedオプションを使用します。
Ext2ファイルシステムをExt3に変換するには、次の手順に従います。
Ext3ジャーナルの作成には、tune2fs -jをrootユーザとして実行します。
この結果、デフォルトのパラメータを使用してExt3ジャーナルが作成されます。
ジャーナルのサイズおよびジャーナルを常駐させるデバイスを指定するには、tune2fs -Jとともに適切なジャーナルオプションsize=およびdevice=を指定して、実行します。tune2fsプログラムの詳細については、tune2fsのマニュアルページを参照してください。
ファイル/etc/fstabをrootユーザとして編集して、該当するパーティションに指定されているファイルシステムタイプをext2からext3に変更し、その変更内容を保存します。
これにより、Ext3ファイルシステムが認識されるようになります。この変更結果は、次回の再起動後に有効になります。
Ext3パーティションとしてセットアップされたルートファイルシステムをブートするには、ext3とjbdの各モジュールをinitrdに組み込みます。
/etc/sysconfig/kernelをrootとして編集し、ext3およびjbdをINITRD_MODULES変数に追加し、最後に変更内容を保存します。
mkinitrdコマンドを実行します。
これにより新規のinitrdがビルドされ、すぐに使用できます。
システムを再起動します。
OCFS2は、クラスタリング設定用に作成されたジャーナルファイルシステムです。Ext3などの標準の単一ノードファイルシステムとは対照的に、OCFS2では複数ノードを管理することができます。OCFS2では、1つのファイルシステムを共有ストレージ全体に展開させることができます(SANやマルチパスセットアップなど）。
OCFS2セットアップの各ノードは、すべてのデータに対して同時に読み込み/書き込みアクセスを行うことができます。そのためには、OCFS2がクラスタに対応している必要があります。つまり、OCFS2は、どのノードがクラスタを構成しているか、それらのノードが実際に利用可能かどうかを判別する機能を含む必要があります。クラスタのメンバーシップを計算するため、OCFS2にはノードマネージャが組み込まれています。クラスタ内のノードの可用性を監視するために、OCFS2には簡単なハートビート機能が実装されています。多様なノードがファイルシステムに直接アクセスすることによって発生する問題を回避するため、OCFS2には分散ロックマネージャも組み込まれています。ノード間の通信は、TCPベースのメッセージングシステムにより処理されます。
OCFS2の主要機能と利点を次に示します。
メタデータのキャッシングとジャーナリング
データベースのパフォーマンスを向上する非同期、直接I/Oのサポート
最大16TBまでのボリュームで、最高4KBまでの複数ブロックサイズをサポート(各ボリュームで異なるブロックサイズを使用可能)
ノード間にまたがるファイルデータの整合性
255台までのクラスタノードをサポート
OCFS2の詳細については、『High Availability Storage Infrastructure Administration Guide』を参照してください。
2.4カーネルリリースから公式に主要機能として採用されたReiserFSは、SUSE 6.4以降、2.2.x SUSEカーネルのカーネルパッチとして利用可能となりました。ReiserFSは、Hans ReiserとNamesys開発チームにより設計されました。ReiserFSは、Ext2に代わる強力な選択肢であることを実証してきました。 ReiserFSの主要な利点としては、効率的なディスクスペース使用率、より良いディスクアクセスパフォーマンス、より高速なクラッシュリカバリ、およびデータジャーナリングの使用による信頼性の向上があります。
ReiserFSでは、すべてのデータは、B*-Tree(バランスドツリー)と呼ばれる構造で編成されています。このツリー構造は、より良いディスクスペース使用効率に貢献しています。小さなファイルは、B*-Treeのリーフノードに直接格納されるからです。そのようなファイルをどこか他の場所に格納して、ディスク上の実際の場所を指すポインタを維持するより優れています。 それに加えて、ストレージ(記憶領域)は 1KBまたは 4KBのチャンク単位で割り当てられるのではなく、実際に必要なサイズの構成部分(エクステント)を割り当てられます。もう1つの利点は、inodeの動的割り当てに関係しています。 これは、ファイルシステムの作成時にinodeの密度を指定する必要のある、Ext2のような従来のファイルシステムに比べて、ファイルシステムの柔軟性を高めます。
小規模なファイルでは、多くの場合、ファイルのデータとstat_data
(inode)情報が互いに隣り合って保存されます。 これらは1回のディスクI/O操作で読み取れるので、ただ1回のディスクアクセスで、必要な情報すべてを取得できることを意味します。
ジャーナルを使用して、メタデータに加えられた最新の変更結果を記録しているので、ファイルシステムが大規模な場合を含め、ファイルシステムを数秒でチェックできます。
ReiserFSは、「Ext3」に概略されているコンセプトに類似のデータジャーナリングおよびオーダードモードもサポートしています。デフォルトのモードは、data=orderedです。このモードでは、データとメタデータの完全性は保証されますが、メタデータのジャーナリングだけが行われます。
本来は、IRIX OS用のファイルシステムを意図してSGIがXFSの開発を開始したのは、1990年代初期です。 XFSの開発動機は、ハイパフォーマンスの64ビットジャーナルファイルシステムの作成により、非常に厳しいコンピューティングの課題に対応することでした。XFSは大規模なファイルを操作する点で非常に優れていて、ハイエンドのハードウェアを適切に活用します。 しかし、XFSには1つの欠点があります。 ReiserFSの場合と同様、XFSではメタデータの完全性は重視されていますが、データの完全性はそれほどではありません。
ただし、XFSの主要機能を一見すれば、XFSが、ハイエンドコンピューティングの分野で、他のジャーナリングファイルシステムの強力な競合相手となっている理由が分かります。
XFSファイルシステムの作成時に、ファイルシステムの基にあるブロックデバイスは、等しいサイズを持つ8つ以上の線形の領域に分割されます。 これらをアロケーショングループと呼びます。 各アロケーショングループは、独自のinodeと空きディスクスペースを管理します。 実用的には、アロケーショングループを、1つのファイルシステムの中にある複数のファイルシステムと見なすこともできます。 アロケーショングループは互いに独立しているのではなく、カーネルから複数を同時にアドレス指定できる、という特徴があります。 この機能は、XFSの高いスケーラビリティに大きく貢献しています。独立性の高いアロケーショングループは、性質上、マルチプロセッサシステムのニーズに適しています。
空きスペースとinodeは、各アロケーショングループ内のB+-Treeによって処理されます。 B+ツリーの採用は、XFSのパフォーマンスとスケーラビリティを大きく向上させています。XFSでは、プロセスを2分割して割り当てを処理する遅延割り当てを使用します。保留されているトランザクションはRAMの中に保存され、適切な量のスペースが確保されます。 XFSは、この時点では、データを正確にはどこに(ファイルシステムのどのブロックに)格納するか決定していません。決定可能な最後の瞬間まで、この決定は遅延(先送り)されます。 暫定的に使用される一時データは、ディスクに書き込まれません。XFSがデータの実際の保存場所を決定するまでに、その役割を終えているからです。このように、XFSは、書き込みのパフォーマンスを向上させ、ファイルシステムのフラグメンテーションを減少させます。遅延アロケーションは、他のファイルシステムより書き込みイベントの頻度を下げる結果をもたらすので、書き込み中にクラッシュが発生した場合、データ損失が深刻になる可能性が高くなります。
データをファイルシステムに書き込む前に、XFSはファイルが必要とする空きスペースを予約(プリアロケート、事前割り当て)します。 したがって、ファイルシステムの断片化は大幅に減少します。 ファイルの内容がファイルシステム全体に分散することがないので、パフォーマンスが向上します。