Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
適用先 SUSE Linux Enterprise Server 11 SP4

1 Linuxファイルシステムの概要

SUSE Linux Enterprise Serverには、選択できる多数のさまざまなファイルシステム(Btrfs、Ext3、Ext2、ReiserFS、XFSなど)が付属しています。各ファイルシステムには、それぞれ独自の利点と欠点があります。

プロ級のハイパフォーマンスのセットアップには、可用性の高いストレージシステムが必要なことがあります。ハイパフォーマンスのクラスタリングシナリオの要件を満たすため、SUSE Linux Enterprise Serverでは、SLES HASI (High-Availability Storage Infrastructure)リリースにOCFS2 (Oracle Cluster File System 2)とDRBD (Distributed Replicated Block Device)を組み込んでいます。これらの高度なストレージシステムは、本書では扱いません。『SUSE Linux Enterprise 11 SP3 High Availability Extension Guide』を参照してください。

1.1 用語集

メタデータ(metadata)

ファイルシステムが内包するデータ構造です。これにより、すべてのオンディスクデータが正しく構成され、アクセス可能になります。本質的には、データに関するデータです。ほとんどすべてのファイルシステムに独自のメタデータ構造があり、それが各ファイルシステムに異なるパフォーマンス特性が存在する理由の1つになっています。メタデータが破損しないよう維持するのは、非常に重要なことです。もし破損した場合、ファイルシステム内にあるすべてのデータがアクセス不能になる可能性があるからです。

inode

サイズ、リンク数、ファイルの内容を実際に格納しているディスクブロックへのポインタ、作成日時、変更日時、クセス日時など、ファイルに関する各種の情報を含むファイルシステムのデータ構造。

ジャーナル(journal)

ファイルシステムのジャーナルは、ファイルシステムがそのメタデータ内で行う変更を特定のログに記録するオンディスク構造です。ジャーナル機能は、システム起動時にファイルシステム全体をチェックする長い検索プロセスが不要なため、ファイルシステムの回復時間を大幅に短縮します。ただし、それはジャーナルが再現できる場合に限定されます。

1.2 Linuxの主要なファイルシステム

SUSE Linux Enterprise Serverでは、多様なファイルシステムを選択できます。このセクションでは、それらのファイルシステムの機能および利点の概要を説明します。

ただし、すべてのアプリケーションに最適なファイルシステムは存在しません。各ファイルシステムには特定の利点と欠点があり、それらを考慮する必要があります。最も高度なファイルシステムを選択する場合でも、適切なバックアップ戦略が必要です。

本項で使用されるデータの完全性およびデータの一貫性という用語は、ユーザスペースデータ(ユーザが使用するアプリケーションによりファイルに書き込まれるデータ)の一貫性を指す言葉ではありません。ユーザスペースのデータが一貫しているかどうかは、アプリケーション自体が管理する必要があります。

重要
重要

このセクションで特に指定のない限り、パーティションおよびファイルシステムの設定または変更に必要なすべてのステップは、YaSTを使用して実行できます。

1.2.1 Btrfs

Btrfsは、Chris Masonが開発したCOW(コピーオンライト)ファイルシステムです。このシステムは、Ohad Rodehが開発したCOWフレンドリーなBツリーに基づいています。Btrfsは、ロギングスタイルのファイルシステムです。このシステムでは、ブロックの変更をジャーナリングする代わりに、それらの変更を新しい場所に書き込んで、リンクインします。新しい変更は、最後の書き込みまで確定されません。

重要
重要

Btrfsではファイルシステムのスナップショットを格納することができるため、標準のストレージ案の2倍のディスクスペースを確保しておくことが推奨されます。これは、YaSTパーティショナにより、ルートファイルシステムに対するBtrfsのストレージ案において、自動的に行われます。

1.2.1.1 主な機能

Btrfsは、次のような耐障害性、修復、容易な管理機能を提供します。

  • 書き込み可能なスナップショット。更新適用後に必要に応じてシステムを容易にロールバックしたり、ファイルをバックアップできます。

  • 複数デバイスのサポート。ファイルシステムを拡大したり、縮小できます。この機能は、YaSTパーティショナの今後のリリースで利用可能となる予定です。

  • 圧縮機能。ストレージスペースを効率的に使用できます。

    Btrfsのコマンドを使用して、透過圧縮を設定します。 Btrfsの圧縮および暗号化の機能は目下開発中であり、現在のところSUSE Linux Enterprise Serverではサポートされていません。

  • メタデータとユーザデータ用のさまざまなRAIDレベル。

  • メタデータとユーザデータ用のさまざまなチェックサム。エラー検出が向上します。

  • Linux LVM (Logical Volume Manager)ストレージオブジェクトとの統合。

  • SUSE Linux上でのYaSTパーティショナおよびAutoYaSTとの統合。

  • 既存のExt2、Ext3、およびExt4ファイルシステムからの、オフラインのマイグレーション 。

1.2.1.2 ブートローダのサポート

Btrfs上の/bootに対するブートローダのサポートは、SUSE Linux Enterprise 12から利用可能となる予定です。

1.2.1.3 Btrfsのサブボリューム

BtrFSでは、割り当てられたスペースのプールにデフォルトのサブボリュームが作成されます。BtrFSでは、同じスペースプール内で個々のファイルシステムとして機能する追加サブボリュームを作成できます。サブボリュームの数は、プールに割り当てられたスペースによってのみ制限されます。

Btrfsをルート(/)のファイルシステムに使用する場合は、YaSTパーティショナにより、Btrfsのサブボリュームとの使用のためのBtrfsファイルシステムが自動的に作成されます。いずれのサブディレクトリも、サブボリュームとして扱うことができます。たとえば、表1.1「YaSTにおける、Btrfs用のデフォルトのサブボリュームの扱い」には、サブボリュームとして扱うことをが推奨されるサブディレクトリを示しています。これらのサブディレクトリには、記載の理由によりスナップショットするべきではないファイルが含まれているからです。

表 1.1: YaSTにおける、Btrfs用のデフォルトのサブボリュームの扱い

パス

サブボリュームとして扱う理由

/opt

サードパーティのアドオンアプリケーションのソフトウェアパッケージを格納します。

/srv

httpファイルとftpファイルを格納します。

/tmp

一時ファイルを格納します。

/var/crash

クラッシュしたカーネルのメモリダンプを格納します。

/var/log

システムおよびアプリケーションのログファイルを格納します。これはロールバックできません。

/var/run

ランタイム変数のデータを格納します。

/var/spool

プログラム、ユーザ、または管理者による処理を待っているデータ(ニュース、メール、プリンタのキューなど)を格納します。

/var/tmp

システムの再起動間で保存する一時ファイルまたは一時ディレクトリを格納します。

インストール後は、YaST Expert Partitionerを使用して、Btrfsサブボリュームの追加や削除が可能です。詳細については、『SUSE Linux Enterprise Server 11 SP3導入ガイド』の、YaSTを使用したBtrfsサブボリュームの管理を参照してください。

1.2.1.4 ルートファイルシステムのスナップショット

Btrfsでは、SUSE Snapperのインフラストラクチャに書き込み可能なスナップショットが提供されており、これを使用して、更新プログラムの適用後に必要に応じてシステムをロールバックすることも、バックアップすることもできます。Snapperを使用すれば、スナップショットの作成や削除のほか、2つのスナップショットを比較してその相違を元に戻すこともできます。Btrfsをルート(/)ファイルシステムに使用した場合は、YaSTによりルートファイルシステムに対するスナップショットが自動的に有効化されます。

Snapperと、ZYpp (snapper-zypp-plugin)およびYaST (yast2-snapper)におけるその統合については、『SUSE Linux Enterprise Server 11 SP3管理ガイド』のSnapperを使用したスナップショット/ロールバックを参照してください。

システムディスクがスナップショットでいっぱいにならないように、/etc/snapper/configs/root設定ファイルまたは他のマウントポイントで、Snapperクリーンアップのデフォルトをより制約された値に変更できます。Snapperでは、日次のcronジョブで実行された古いスナップショットをクリーンアップするために、3つのアルゴリズムが提供されています。クリーンアップ頻度は、マウントポイントのSnapper設定で定義されています。日次、月次、年次のクリーンアップのTIMELINE_LIMITパラメータ値を下げると、スナップショットの数と保持期間を減らせます。詳細については、『SUSE Linux Enterprise Server 11 SP3管理ガイド』の設定ファイルの調整を参照してください。

SUSEのSnapperプロジェクトについては、OpenSUSE.orgにあるSnapper Portal wikiを参照してください。

1.2.1.5 オンラインでのチェックと修復の機能

scrubを使用したチェックと修復の機能が、Btrfsのコマンドラインツールの一部として利用できます。ツリー構造が正しいことを前提として、データとメタデータの完全性を検証します。マウントしたファイルシステム上で、scrubを定期的に実行することができます。これは、通常の操作中にバックグラウンドプロセスとして実行されます。

1.2.1.6 RAIDとMultipathのサポート

YaSTパーティショナを使用して、Multiple Devices (MD)およびDevice Mapper (DM)のストレージ構成上でBtrfsを作成することができます。

1.2.1.7 ExtファイルシステムからBtrfsへのマイグレーション

既存のExtファイルシステム(Ext2、Ext3、またはExt4)から、Btrfsファイルシステムへデータボリュームをマイグレートすることができます。変換プロセスはオフラインで、デバイス上において行われます。ファイルシステムは、デバイス上の空き領域の15%以上を必要とします。

ExtファイルシステムをBtrfsに変換するには、ファイルシステムをオフラインにしてから、次のように入力します。

btrfs-convert <device>

マイグレーションを、元のExtファイルシステムにロールバックするには、ファイルシステムをオフラインにしてから、次のように入力します。

btrfs-convert -r <device>
重要
重要

元のExtファイルシステムにロールバックする際、Btrfsへの変換後に追加したデータはすべて失われます。つまり、元のデータのみが、Extファイルシステムに逆変換されます。

1.2.1.8 Btrfsの管理

Btrfsは、YaSTパーティショナおよびAutoYaST内に統合されています。これはインストール時に利用可能で、ルートファイルシステム用のソリューションを設定することができます。インストール後に、YaSTパーティショナを使用して、Btrfsのボリュームの参照と管理を行うことができます。

Btrfsの管理ツールは、btrfsprogsパッケージ内に用意されています。Btrfsコマンドの使用については、btrfs(8)btrfsck(8)mkfs.btrfs(8)、およびbtrfsctl(8) のマニュアルページを参照してください。Btrfsの機能については、Btrfs wikiを参照してください。

fsck.btrfs(8)ツールは、SUSE Linux Enterpriseの更新リポジトリ内で近日中に利用可能となります。

1.2.1.9 サブボリュームに対するBtrfsクォータのサポート

Btrfs rootファイルシステムのサブボリューム/var/log/var/crashおよび/var/cacheが、通常の操作時に利用可能なディスクスペースのすべてを使用でき、システムに不具合が発生します。この状況を回避するため、SUSE Linux Enterpriseではサブボリュームに対するBtrfsクォータのサポートを提供するようになりました。詳細については、btrfs(8)のマニュアルページを参照してください。

1.2.2 Ext2

Ext2の起源は、Linuxの歴史の初期にさかのぼります。その前身であったExtended File Systemは、1992年4月に実装され、Linux 0.96cに統合されました。Extended File Systemは多くの変更を加えられ、Ext2として数年にわたって、最も人気のあるLinuxファイルシステムになりました。その後、ジャーナルファイルシステムが作成され、回復時間が非常に短くなったため、Ext2の重要性は低下しました。

Ext2の利点に関する短い要約を読むと、かつて幅広く好まれ、そして今でも一部の分野で多くのLinuxユーザから好まれるLinuxファイルシステムである理由を理解するのに役立ちます。

1.2.2.1 堅実性と速度

古くからある標準として、Ext2は過去に多くの改良がなされ、繰り返しテストされてきました。これが、Ext2がしばしば非常に堅実と評される理由かもしれません。ファイルシステムが正常にアンマウントできず、システムが機能停止した場合、e2fsckはファイルシステムのデータの分析を開始します。メタデータは一貫した状態に戻り、保留されていたファイルとデータブロックは、指定のディレクトリ(lost+found)に書き込まれます。ジャーナルファイルシステムとは対照的に、e2fsckは、最近変更されたわずかなメタデータだけではなく、ファイルシステム全体を分析します。この結果、ジャーナルファイルシステムがログデータだけをチェックするのに比べて、かなり長い時間を要します。ファイルシステムのサイズにもよりますが、この手順は30分またはそれ以上を要することがあります。したがって、高可用性を必要とするどのようなサーバでも、Ext2を選択することは望ましくありません。ただし、Ext2はジャーナルを維持せず、使用するメモリも非常にわずかであるため、他のファイルシステムよりも高速である場合があります。

1.2.2.2 容易なアップグレード性

Ext3は、Ext2のコードをベースとし、Ext2のオンディスクフォーマットとメタデータフォーマットも共用するので、Ext2からExt3へのアップグレードは非常に容易です。

1.2.3 Ext3

Ext3は、Stephen Tweedieによって設計されました。他のすべての次世代ファイルシステムとは異なり、Ext3は完全に新しい設計理念に基づいているわけではありません。Ext3は、Ext2をベースとしています。これら2つのファイルシステムは、非常に似ています。Ext3ファイルシステムを、Ext2ファイルシステムの上に構築することも容易です。Ext2とExt3の最も重要な違いは、Ext3がジャーナルをサポートしていることです。要約すると、Ext3には、次の3つの主要な利点があります。

1.2.3.1 Ext2からの容易で信頼性の高いアップグレード

Ext2のコードは、Ext3が次世代ファイルシステムであることを明確に主張するための強力な土台になりました。Ext3では、Ext2の信頼性および堅実性がExt3で採用されたジャーナルファイルシステムの利点とうまく統合されています。ReiserFSまたはXFSのような他のファイルシステムへの移行はかなり手間がかかります(ファイルシステム全体のバックアップを作成し、移行先ファイルシステムを新規に作成する必要があります)が、それとは異なり、Ext3への移行は数分で完了します。ファイルシステム全体を新たに作成し直しても、それが完璧に動作するとは限らないので、Ext3への移行は非常に安全でもあります。ジャーナルファイルシステムへのアップグレードを必要とする既存のExt2システムの数を考慮に入れると、多くのシステム管理者にとってExt3が重要な選択肢となり得る理由が容易にわかります。Ext3からExt2へのダウングレードも、アップグレードと同じほど容易です。Ext3ファイルシステムのアンマウントを正常に行い、Ext2ファイルシステムとして再マウントするだけです。

1.2.3.2 信頼性とパフォーマンス

他のジャーナルファイルシステムは、メタデータのみのジャーナルアプローチに従っています。つまり、メタデータは常に一貫した状態に保持されますが、ファイルシステムのデータ自体については、一貫性が自動的に保証されるわけではありません。Ext3は、メタデータとデータの両方に注意するよう設計されています。注意の度合いはカスタマイズできます。Ext3のdata=journalモードを有効にした場合、最大の保護(データの完全性)を実現しますが、メタデータとデータの両方がジャーナル化されるので、システムの動作が遅くなります。比較的新しいアプローチは、data=orderedモードを使用することです。これは、データとメタデータ両方の完全性を保証しますが、ジャーナルを適用するのはメタデータのみです。ファイルシステムドライバは、1つのメタデータの更新に対応するすべてのデータブロックを収集します。これらのブロックは、メタデータの更新前にディスクに書き込まれます。その結果、パフォーマンスを犠牲にすることなく、メタデータとデータの両方に関する一貫性を達成できます。3番目のオプションは、data=writebackを使用することです。これは、対応するメタデータをジャーナルにコミットした後で、データをメインファイルシステムに書き込むことを可能にします。多くの場合、このオプションは、パフォーマンスの点で最善と考えられています。しかし、内部のファイルシステムの完全性が維持される一方で、クラッシュと回復を実施した後では、古いデータがファイル内に再登場させてしまう可能性があります。Ext3では、デフォルトとして、data=orderedオプションを使用します。

1.2.3.3 Ext2ファイルシステムからExt3への変換

Ext2ファイルシステムをExt3に変換するには、次の手順に従います。

  1. Ext3ジャーナルの作成には、tune2fs -jrootユーザとして実行します。

    この結果、デフォルトのパラメータを使用してExt3ジャーナルが作成されます。

    ジャーナルのサイズおよびジャーナルを常駐させるデバイスを指定するには、tune2fs -Jとともに適切なジャーナルオプションsize=およびdevice=を指定して、実行します。tune2fsプログラムの詳細については、tune2fsのマニュアルページを参照してください。

  2. ファイル/etc/fstabrootユーザとして編集して、該当するパーティションに指定されているファイルシステムタイプをext2からext3に変更し、その変更内容を保存します。

    これにより、Ext3ファイルシステムが認識されるようになります。この変更結果は、次回の再起動後に有効になります。

  3. Ext3パーティションとしてセットアップされたルートファイルシステムをブートするには、ext3jbdの各モジュールをinitrdに組み込みます。

    1. /etc/sysconfig/kernelrootとして編集し、ext3およびjbdINITRD_MODULES変数に追加し、最後に変更内容を保存します。

    2. mkinitrdコマンドを実行します。

      これにより新規のinitrdがビルドされ、すぐに使用できます。

  4. システムを再起動します。

1.2.3.4 Ext3ファイルシステムのinodeサイズとinode数

inodeには、ファイルシステム内のファイルとそのブロック位置に関する情報が格納されます。拡張した属性とACLのためのスペースをinode内に確保するため、Ext3のデフォルトのinodeサイズは、SLES 10での128バイトから、SLES 11では256バイトに拡大されました。SLES 10と比較して、SLES 11上でExt3ファイルシステムを作成する際、同数のinodeに対する事前割り当てされたデフォルトのスペースの量は2倍になり、ファイルシステム内のファイルに対して使用可能なスペースは、その分少なくなっています。したがって、同数のinodeとファイルを収容するのに、SLES 10上のExt3ファイルシステムの場合より大きなパーティションを使用する必要があります。

新規のExt3ファイルシステムを作成する際、inodeテーブル内のスペースは、作成可能なinodeの総数に対して事前に割り当てられています。バイト数/inode数の比率と、ファイルシステムのサイズによって、inode数の上限が決まります。ファイルシステムが作成されると、バイト数/inode数のバイト数の各スペースに対して、1つのinodeが作成されます。

number of inodes = total size of the file system divided by the number of bytes per inode

inodeの数によって、ファイルシステム内に保有できるファイルの数が決まります。つまり、各ファイルにつき1つのinodeです。inodeサイズの増大と、利用可能なスペースの縮小に対応するため、バイト数/inode数の比率のデフォルトが、SLES 10での8192バイトから、SLES 11では16384バイトに増えています。この2倍に増えた比率により、作成可能なファイルの数は、SLES 10上のExt3ファイルシステムで可能だった数の半分となります。

重要
重要

inodeの割り当て後は、inodeサイズやバイト数/inode数の比率の設定を変えることはできません。異なる設定のファイルシステムを再度作成するか、ファイルシステムを拡張しない限り、新規のinodeは設定できません。inodeの最大数を超えると、ファイルをいくつか削除するまで、ファイルシステム上に新規のファイルを作成することはできません。

新規のExt3ファイルシステムを作成する際に、inodeのスペース使用をコントロールするためのinodeサイズとバイト数/inode数の比率、およびファイルシステム上のファイル数の上限を指定することができます。ブロックサイズ、inodeサイズ、およびバイト数/inode数の比率が指定されない場合は、/etc/mked2fs.confファイル内のデフォルト値が適用されます。詳細については、mke2fs.conf(5)マニュアルページを参照してください。

次のガイドラインを使用します。

  • inodeサイズ: デフォルトのinodeサイズは256バイトです。2の累乗で、ブロックサイズ以下の128以上のバイト数の値を指定します(128、256、512など)。Ext3ファイルシステムで拡張属性またはACLを使用しない場合は、128バイトのみを使用してください。

  • バイト数/inode数の比率: デフォルトのバイト数/inode数の比率は、16384バイトです。有効なバイト数/inode数の比率は、2の累乗で1024バイト以上(1024、2048、4096、8192、16384、32768など)です。この値は、ファイルシステムのブロックサイズより小さくはできません。なぜなら、ブロックサイズは、データを格納するために使用するスペースの最小チャンクだからです。Ext3ファイルシステムのデフォルトのブロックサイズは、4 KBです。

    また、格納する必要があるファイルの数とサイズを、検討する必要があります。たとえば、ファイルシステムに多数の小さなファイルを持つことになる場合は、バイト数/inode数の比率を小さめに指定すれば、inodeの数を増やすことができます。ファイルシステムに非常に大きなファイルを入れる場合は、バイト数/inode数の比率を大きめに指定できますが、それによって許容されるinodeの数は減ります。

    一般的に、inodeの数は、足りなくなるよりは多すぎる方が得策です。inodeの数が少な過ぎてファイルも非常に小さい場合、実際には空であってもディスク上のファイルの最大数に到達してしまいます。inodeの数が多すぎて、ファイルが非常に大きい場合は、空き領域があることが表示されたとしても、それを使うことができません。なぜなら、inode用に確保されたスペースに新規のファイルを作成することはできないからです。

Ext3ファイルシステムで拡張属性またはACLを使用しない場合は、ファイルシステムの作成時に、inodeサイズとして128バイト、バイト数/inode数の比率として8192バイトを指定して、SLES 10の動作を復元することができます。inodeサイズとバイト数/inode数の比率を設定するには、次のいずれかの方法を使用します。

  • すべての新規Ext3ファイルのデフォルト設定を変更する: テキストエディタで、/etc/mke2fs.confファイルのdefaultsセクションを変更して、inode_sizeおよびinode_ratioを、希望するデフォルト値に設定します。その値が、すべての新規のExt3ファイルシステムに適用されます。たとえば、

    blocksize = 4096
    inode_size = 128
    inode_ratio = 8192
  • コマンドラインで: Ext3ファイルシステムを作成する際に、inodeサイズ(-I 128)およびバイト数/inode数の比率(-i 8192)を、mkfs.ext3(8)コマンドまたはmke2fs(8)コマンドに渡します。たとえば、次のコマンドのいずれかを使用します:

    mkfs.ext3 -b 4096 -i 8092 -I 128 /dev/sda2
    
    mke2fs -t ext3 -b 4096 -i 8192 -I 128 /dev/sda2
  • YaSTを使用したインストール時に: インストール時に新規のExt3ファイルシステムを作成する際に、inodeサイズとバイト数/inode数の比率を渡します。YaSTフォーマット設定のオプションにあるパーティションの編集ページで、パーティションのフォーマットExt3を選択して、オプションをクリックします。ファイルシステムオプションダイアログボックスで、ブロックサイズ(バイト単位)inodeごとのバイト数、およびiノードのサイズドロップダウンリストから、希望の値を選択します。

    たとえば、ブロックサイズ(バイト単位)ドロップダウンリストから4096を選択し、ブロックサイズ(バイト単位)ドロップダウンリストから8192を選択し、iノードのサイズドロップダウンリストから128を選択して、OKをクリックします。

  • autoyastを使用したインストール時に: autoyastのプロファイルで、fs_optionsタグを使用して、opt_bytes_per_inodeの比率の値を、-iに対して8192に、opt_inode_densityの値を-Iに対して128に設定することができます。

    <partitioning config:type="list">
        <drive>
          <device>/dev/sda</device>
          <initialize config:type="boolean">true</initialize>
          <partitions config:type="list">
            <partition>
              <filesystem config:type="symbol">ext3</filesystem>
              <format config:type="boolean">true</format>
              <fs_options>
                <opt_bytes_per_inode>
                  <option_str>-i</option_str>
                  <option_value>8192</option_value>
                </opt_bytes_per_inode>
                <opt_inode_density>
                  <option_str>-I</option_str>
                  <option_value>128</option_value>
                </opt_inode_density>
              </fs_options>
              <mount>/</mount>
              <partition_id config:type="integer">131</partition_id>
              <partition_type>primary</partition_type>
              <size>25G</size>
            </partition>

SLES11のExt3パーティションには、SLES10で格納できるファイルの50%しか格納することができません。詳細については、を参照してください。[技術情報文書7009075]

1.2.4 ReiserFS

2.4カーネルリリースから公式に主要機能として採用されたReiserFSは、SUSE 6.4以降、2.2.x SUSEカーネルのカーネルパッチとして利用可能となりました。ReiserFSは、Hans ReiserとNamesys開発チームにより設計されました。ReiserFSは、Ext2に代わる強力な選択肢であることを実証してきました。ReiserFSの主要な利点としては、効率的なディスクスペース使用率、より良いディスクアクセスパフォーマンス、より高速なクラッシュリカバリ、およびデータジャーナリングの使用による信頼性の向上があります。

重要
重要

ReiserFSファイルシステムは、特にマイグレーション用として、SUSE Linux Enterprise Server 11のライフタイムの間、完全にサポートされます。SUSEでは、SUSE Linux Enterprise Server 12から、新しいReiserFSファイルシステムの作成をサポートしない予定です。

1.2.4.1 より良いディスクスペース使用効率

ReiserFSでは、すべてのデータが、B*-Tree(バランスドツリー)と呼ばれる構造で編成されています。このツリー構造は、より良いディスクスペース使用効率に貢献しています。小さなファイルは、B*-Treeのリーフノードに直接格納されるからです。そのようなファイルをどこか他の場所に格納して、ディスク上の実際の場所を指すポインタを維持するより優れています。それに加えて、ストレージ(記憶領域)は 1KBまたは 4KBのチャンク単位で割り当てられるのではなく、実際に必要なサイズの構成部分(エクステント)を割り当てられます。もう1つの利点は、inodeの動的割り当てに関係しています。これは、ファイルシステムの作成時にinodeの密度を指定する必要のある、Ext2のような従来のファイルシステムに比べて、ファイルシステムの柔軟性を高めます。

1.2.4.2 より良いディスクアクセスパフォーマンス

小規模なファイルでは、多くの場合、ファイルのデータとstat_data (inode)情報が互いに隣り合って保存されます。これらは1回のディスクI/O操作で読み取れるので、1回のディスクアクセスで、必要な情報すべてを取得できることを意味します。

1.2.4.3 高速なクラッシュ回復機能

ジャーナルを使用して、メタデータに加えられた最新の変更結果を記録しているので、ファイルシステムが大規模な場合を含め、ファイルシステムを数秒でチェックできます。

1.2.4.4 データジャーナリングによる信頼性

ReiserFSは、1.2.3項 「Ext3」に概略されているコンセプトに類似のデータジャーナリングおよびオーダードモードもサポートしています。デフォルトのモードは、data=orderedです。このモードでは、データとメタデータの完全性は保証されますが、メタデータのジャーナリングだけが行われます。

1.2.5 XFS

本来は、IRIX OS用のファイルシステムを意図してSGIがXFSの開発を開始したのは、1990年代初期です。XFSの開発動機は、ハイパフォーマンスの64ビットジャーナルファイルシステムの作成により、非常に厳しいコンピューティングの課題に対応することでした。XFSは大規模なファイルを操作する点で非常に優れていて、ハイエンドのハードウェアを適切に活用します。しかし、XFSには1つの欠点があります。ReiserFSの場合と同様、XFSではメタデータの完全性は重視されていますが、データの完全性はそれほどではありません。

ただし、XFSの主要機能を一見すれば、XFSが、ハイエンドコンピューティングの分野で、他のジャーナリングファイルシステムの強力な競合相手となっている理由がわかります。

1.2.5.1 アロケーショングループの採用による高いスケーラビリティ

XFSファイルシステムの作成時に、ファイルシステムの基にあるブロックデバイスは、等しいサイズをもつ8つ以上の線形の領域に分割されます。これらを「アロケーショングループ」と呼びます。各アロケーショングループは、独自のinodeと空きディスクスペースを管理します。実用的には、アロケーショングループを、1つのファイルシステムの中にある複数のファイルシステムと見なすこともできます。アロケーショングループは互いに独立しているものではないため、複数のアロケーショングループをカーネルから同時にアドレス指定できるという特徴があります。この機能は、XFSの高いスケーラビリティに大きく貢献しています。独立性の高いアロケーショングループは、性質上、マルチプロセッサシステムのニーズに適しています。

1.2.5.2 ディスクスペースの効率的な管理によるハイパフォーマンス

空きスペースとinodeは、各アロケーショングループ内のB+-Treeによって処理されます。B+ツリーの採用は、XFSのパフォーマンスとスケーラビリティを大きく向上させています。XFSでは、プロセスを2分割して割り当てを処理する遅延割り当てを使用します。保留されているトランザクションはRAMの中に保存され、適切な量のスペースが確保されます。XFSは、この時点では、データを正確にはどこに(ファイルシステムのどのブロックに)格納するか決定していません。決定可能な最後の瞬間まで、この決定は遅延(先送り)されます。暫定的に使用される一時データは、ディスクに書き込まれません。XFSがデータの実際の保存場所を決定するまでに、その役割を終えているからです。このように、XFSは、書き込みのパフォーマンスを向上させ、ファイルシステムのフラグメンテーションを減少させます。遅延アロケーションは、他のファイルシステムより書き込みイベントの頻度を下げる結果をもたらすので、書き込み中にクラッシュが発生した場合、データ損失が深刻になる可能性が高くなります。

1.2.5.3 事前割り当てによるファイルシステムの断片化の回避

データをファイルシステムに書き込む前に、XFSはファイルが必要とする空きスペースを予約(プリアロケート、事前割り当て)します。したがって、ファイルシステムの断片化は大幅に減少します。ファイルの内容がファイルシステム全体に分散することがないので、パフォーマンスが向上します。

1.2.6 ファイルシステムの機能比較

SUSE Linux Enterprise Serverにおける主要オペレーティングシステムの機能の対照比較については、ファイルシステムのサポートおよびサイズ(SUSE Linux Enterprise Server技術情報のWebサイトに記載)を参照してください。

1.3 サポートされている他のファイルシステム

表1.2「Linux環境でのファイルシステムのタイプ」は、Linuxがサポートしている他のいくつかのファイルシステムを要約したものです。これらは主に、他の種類のメディアや外部オペレーティングシステムとの互換性およびデータの相互交換を保証することを目的としてサポートされています。

表 1.2: Linux環境でのファイルシステムのタイプ

ファイルシステムのタイプ

説明

cramfs

Compressed ROM file system (圧縮ROMファイルシステム): ROM用の圧縮された読み込み専用ファイルシステムです。

hpfs

High Performance File System(ハイパフォーマンスファイルシステム) :IBM OS/2の標準ファイルシステム。読み取り専用モードでのみサポートされます。

iso9660

CD-ROMの標準ファイルシステム。

minix

このファイルシステムは、オペレーティングシステムに関する学術的なプロジェクトを起源とするもので、Linuxで最初に使用されたファイルシステムです。現在では、フロッピーディスク用のファイルシステムとして使用されています。

msdos

fat、つまり当初はDOSで使用されていたファイルシステムであり、現在はさまざまなオペレーティングシステムで使用されています。

nfs

Network File System (ネットワークファイルシステム) :ネットワーク内の任意のコンピュータにデータを格納でき、ネットワーク経由でアクセスを付与できます。

ntfs

Windows NT file system (NTファイルシステム) :読み取り専用です。

smbfs

Server Message Block (サーバメッセージブロック): Windowsのような製品が、ネットワーク経由でのファイルアクセスを可能にする目的で採用しています。

sysv

SCO UNIX、Xenix、およびCoherent (PC用の商用UNIXシステム)が採用。

ufs

BSD、SunOS、およびNextStepで使用されています。読み取り専用モードでサポートされています。

umsdos

UNIX on MS-DOS(MS-DOS上のUNIX) :標準fatファイルシステムに適用され、特別なファイルを作成することにより、UNIX機能(パーミッション、リンク、長いファイル名)を実現します。

vfat

Virtual FAT:fatファイルシステムを拡張したものです(長いファイル名をサポートします)。

1.4 Linux環境での大規模ファイルサポート

当初、Linuxは、最大ファイルサイズとして 2GiB (231バイト)をサポートしていました。また、ファイルシステムに大規模ファイルサポートが付いていない限り、32ビットシステム上での最大ファイルサイズは2GiBです。

現在、弊社のすべての標準ファイルシステムでは、LFS (大規模ファイルサポート)を提供しています。LFSは、理論的には、263バイトの最大ファイルサイズをサポートします。表1.3「ファイルおよびファイルシステムの最大サイズ(オンディスクフォーマット、4KiBブロックサイズ)」では、Linuxのファイルとファイルシステムの、現行のオンディスクフォーマットの制限事項を概説しています。表内の数字は、ファイルシステムで使用しているブロックサイズが、共通規格である4KiBであることを前提としています。異なるブロックサイズを使用すると結果は異なります。スパースブロックを使用している場合、表1.3「ファイルおよびファイルシステムの最大サイズ(オンディスクフォーマット、4KiBブロックサイズ)」に記載の最大ファイルサイズは、ファイルシステムの実際のサイズより大きいことがあります。

注記
注記

このマニュアルでの換算式: 1024バイト = 1KiB、1024KiB = 1MiB、1024MiB = 1GiB、1024GiB = 1TiB、1024TiB = 1PiB、1024PiB = 1EiB(「NIST: Prefixes for Binary Multiples」も参照してください)。

表 1.3: ファイルおよびファイルシステムの最大サイズ(オンディスクフォーマット、4KiBブロックサイズ)

ファイルシステム(4KiBブロックサイズ)

ファイルシステムの最大サイズ

ファイルの最大サイズ

Btrfs

16EiB

16EiB

Ext3

16TiB

2TiB

OCFS2 (High Availability Extensionで使用可能な、クラスタ認識のファイルシステム)

16TiB

1EiB

ReiserFS v3.6

16TiB

1EiB

XFS

8EiB

8EiB

NFSv2 (クライアント側)

8EiB

2GiB

NFSv3 (クライアント側)

8EiB

8EiB

重要
重要

表1.3「ファイルおよびファイルシステムの最大サイズ(オンディスクフォーマット、4KiBブロックサイズ)」は、ディスクフォーマット時の制限について説明しています。Linuxカーネルは、操作するファイルとファイルシステムのサイズについて、独自の制限を課しています。管理の初期設定には、次のオプションがあります。

ファイルサイズ

32ビットシステムでは、ファイルサイズが2TiB (241バイト)を超えることはできません。

ファイルシステムのサイズ

ファイルシステムのサイズは、最大273バイトまで可能です。しかし、この制限は、現在使用可能なハードウェアが到達可能な範囲を上回っています。

1.5 Linuxのカーネルにおけるストレージの制限

表1.4「ストレージの制限」は、SUSE Linux Enterprise 11 Service Pack 3に関連したストレージに関するカーネルの制限をまとめています。

表 1.4: ストレージの制限

ストレージの機能

制限

サポートされるLUNの最大数

ターゲットあたり16384 LUN。

単一LUNあたりのパスの最大数

それ自体は無制限。それぞれのパスが、通常のLUNとして扱われます。

実際の制限は、ターゲットあたりのLUNの数と、HBAあたりのターゲットの数(ファイバチャネルHBAの場合は16777215)により決まります。

HBAの最大数

無制限. 実際の制限は、システムのPCIスロットの量で決まります。

オペレーティングシステムあたりの、デバイスマッパーマルチパス付きパスの最大数(合計)

約1024。実際の数は、デバイス番号文字列の長さによります。これはマルチパスツール内のコンパイル時間によって変わり、この制限が問題となる場合は、引き上げることもできます。

最大サイズ(ブロックデバイスごと)

X86では、最大16TiB。

x86_64、ia64、s390x、およびppc64では、最大8 EiB。

1.6 YaST パーティショナによるデバイスの管理

YaST パーティションを使用すると、ファイルシステムとRAIDデバイスを作成し、管理できます。『SUSE Linux Enterprise Server 11 SP3導入ガイド』の「高度なディスクセットアップ」を参照してください。

1.7 追加情報

ここまでに説明した各ファイルシステムのプロジェクトには、独自のWebページがあります。そこで詳しいドキュメントとFAQ、さらにメーリングリストを参照することができます。

Linuxファイルシステムの総合的なマルチパートチュートリアルは、「Advanced File System Implementor’s Guide」にあるIBM developerWorksで見つけることができます。

ファイルシステム(Linuxファイルシステムに限らない)の詳しい比較については、「ファイルシステム」のWikipediaプロジェクトを参照してください。

このページを印刷