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

目次

1.1. 用語集
1.2. Linuxの主要なファイルシステム
1.3. サポートされている他のファイルシステム
1.4. Linux環境での大規模ファイルサポート
1.5. YaST 2パーティショナによるデバイスの管理
1.6. 追加情報

SUSE Linux Enterprise Serverには、選択できる多数のさまざまなファイルシステム(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 SP2 High Availability Extension Guide』を参照してください。

1.1. 用語集

メタデータ(metadata)

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

inode

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

ジャーナル(journal)

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

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

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

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

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

[Important]

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

1.2.1. BtrFS

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

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

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

  • 複数デバイスのサポート。ファイルシステムを拡大したり、縮小できます。

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

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

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

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

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

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

BtrFSをルート(/)ファイルシステムに使用する場合は、通常のように、あらゆるサブディレクトリもサブボリュームとして扱うことができます。また、以下のサブディレクトリを別個のサブボリュームとして扱うことも考慮すべきです。これらのサブディレクトリには、下記の理由でスナップショットしない可能性のあるファイルが格納されるからです。

パス

理由

/opt

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

/srv

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

/tmp

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

/var/log

ログファイルを格納します。

/var/opt

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

/var/run

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

/var/spool

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

/var/tmp

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

1.2.2. Ext2

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

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.4. ReiserFS

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

[Important]

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.3. サポートされている他のファイルシステム

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

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

File System Type

説明

cramfs

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

hpfs

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

iso9660

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

minix

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

msdos

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

ncpfs

Novellのボリュームをネットワーク経由でマウントするためのファイルシステム。

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は、最大ファイルサイズとして2GB (231バイト)をサポートしていました。現在、弊社のすべての標準ファイルシステムでは、LFS (大規模ファイルサポート)を提供しています。LFSは、理論的には、263バイトの最大ファイルサイズをサポートします。次の表の数字は、ファイルシステムのブロックサイズを4KiBと想定した数字です。異なるブロックサイズを使用すると結果は異なりますが、4 KiBは最も一般的な基準です。

[Note]

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

表1.2「ファイルとファイルシステムの最大サイズ(オンディスクフォーマット)」では、Linuxのファイルとファイルシステムの現在の制限事項を概説しています。

表1.2 ファイルとファイルシステムの最大サイズ(オンディスクフォーマット)

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

ファイルの最大サイズ

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

BtrFS

16EiB

16EiB

Ext2またはExt3

2TiB

16TiB

OCFS2 (High Availability Extensionで使用可能)

4PiB

4PiB

ReiserFS v3

2TiB

16TiB

XFS

8EiB

8EiB

NFSv2 (クライアント側)

2GiB

8EiB

NFSv3 (クライアント側)

8EiB

8EiB


[Important]

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

File Size

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

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

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

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

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

1.6. 追加情報

NovellのWebサイトに掲載されているFile System Primerは、Linux用の各種ファイルシステムについて記述しています。ファイルシステムの説明、多数のファイルシステムがある理由、ワークロードやデータごとに最適なファイルシステムについて述べています。

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

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

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


Linux Enterprise Server 11 SP2 ストレージ管理ガイド