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

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

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

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

メモ: SUSE Linux Enterprise Server 12 SP1 上のデフォルトのファイルシステム

SUSE Linux Enterprise Server 12 SP1のルートパーティションは、デフォルトでBtrfsとスナップショットサポートを使用して設定されます。詳細については、セクション 4.0, Snapperを使用したシステムの回復とスナップショット管理, (↑管理ガイド)を参照してください。データパーティション(別パーティションに存在する/homeなど)は、デフォルトでXFSでフォーマットされます。

重要: YaSTのパーティショナ

本項で特に指定のない限り、パーティションおよびファイルシステムの設定または変更に必要なすべての手順は、YaSTパーティショナを使用して実行できます(そうすることをお勧めします)。詳細については、セクション 14.0, 高度なディスクセットアップ, (↑導入ガイド)を参照してください。

1.2.1 Btrfs

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

主な機能

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

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

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

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

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

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

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

  • SUSE Linux Enterprise Server上でのYaSTパーティショナおよびAutoYaSTとの統合。その際、MD (複数デバイス)およびDM (デバイスマッパー)の各ストレージ設定ではBtrfsファイルシステムの作成も行われます。

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

  • /bootのブートローダサポート。Btrfsパーティションからの起動を可能にします。

  • マルチボリュームBtrfsは、SUSE Linux Enterprise Server 12 SP1では、RAID0、RAID1、およびRAID10プロファイルでサポートされます。それより高いレベルのRAIDは現時点サポートされませんが、将来のサービスパックでサポートされる可能性があります。

  • Btrfsのコマンドを使用して、透過圧縮を設定します。

SUSE Linux Enterprise Server上のルートファイルシステム設定

SUSE Linux Enterprise Serverのルートパーティションは、デフォルトでBtrfsとスナップショットを使用して設定されます。スナップショットを使用すると、更新適用後に必要に応じてシステムを容易にロールバックしたり、ファイルをバックアップしたりできます。スナップショットは、セクション 4.0, Snapperを使用したシステムの回復とスナップショット管理, (↑管理ガイド)で説明するSUSE Snapperインフラストラクチャを使用して簡単に管理できます。SUSEのSnapperプロジェクトの一般情報については、OpenSUSE.orgにあるSnapper Portal wiki (http://snapper.io)を参照してください。

スナップショットを使用してシステムをロールバックする場合、ユーザのホームディレクトリ、WebサーバとFTPサーバのコンテンツ、ログファイルなどのデータがロールバック中に失われたり、上書きされたりしないようにする必要があります。それには、ルートファイルシステムでBtrfsサブボリュームを使用します。サブボリュームは、スナップショットから除外できます。インストール時にYaSTによって提示されるSUSE Linux Enterprise Serverのルートファイルシステムのデフォルト設定には、次のサブボリュームが含まれます。これらがスナップショットから除外される理由を次に示します。

ルートパーティションのデフォルトのサブボリュームセットアップ
/boot/grub2/i386-pc、/boot/grub2/x86_64-efi、/boot/grub2/powerpc-ieee1275、/boot/grub2/s390x-emu

ブートローダ設定のロールバックはサポートされていません。これらのディレクトリは、アーキテクチャ固有です。最初の2つのディレクトリはx86_64マシン上に存在し、その後の2つのディレクトリはそれぞれIBM POWERとIBM System z上に存在します。

/home

/homeが独立したパーティションに存在していない場合、ロールバック時にデータが失われのを避けるために除外されます。

/opt/var/opt

サードパーティ製品およびアドオンは通常、/optにインストールされます。ロールバック時にこれらのアプリケーションがアンインストールされるのを避けるために除外されます。

/srv

WebおよびFTPサーバ用のデータが含まれています。ロールバック時にデータが失われるのを避けるために除外されます。

/tmp/var/tmp/var/crash

スナップショットから除外される一時ファイルを含むすべてのディレクトリ。

/usr/local

このディレクトリは、ソフトウェアの手動インストール時に使用します。ロールバック時にこれらのインストール済みソフトウェアがアンインストールされるのを避けるために除外されます。

/var/lib/libvirt/images

libvirtを使用して作成されたすべてのVMイメージのデフォルトディレクトリ。スナップショットから除外。デフォルトでは、このサブボリュームは、no copy on writeオプションを使用して作成されます。

/var/lib/named

DNSサーバ用のゾーンデータが含まれます。ネームサーバがロールバック後に確実に動作できるように、スナップショットから除外されます。

/var/lib/mailman/var/spool

電子メールキューまたは電子メールを含むディレクトリは、ロールバック後に電子メールが失われるのを避けるために除外されます。

/var/lib/mariadb

MariaDBデータの場合。スナップショットから除外。デフォルトでは、このサブボリュームは、no copy on writeオプションを使用して作成されます。

/var/lib/pgsql

PostgreSQLデータが含まれます。スナップショットから除外。デフォルトでは、このサブボリュームは、no copy on writeオプションを使用して作成されます。

/var/log

ログファイルの場所。壊れたシステムのロールバック後にログファイルを分析できるようにスナップショットから除外されます。

警告: ロールバックのサポート

SUSEサポートがロールバックをサポートするのは、事前設定されているサブボリュームがまったく削除されていない場合のみです。ただし、Yastパーティショナを使用して、サブボリュームを追加することはできます。

圧縮されたBtrfsファイルシステムのマウント

メモ: GRUB 2およびLZO圧縮ルート

GRUB 2は、lzo圧縮ルートを読み取ることができません。圧縮を使用する場合、別の/bootパーティションが必要です。

SLE12 SP1から、Btrfsファイルシステムの圧縮がサポートされるようになりました。compressまたはcompress-forceオプションを使用し、圧縮アルゴリズム(lzoまたはzlib)を選択します(zlibがデフォルト値です)。zlib圧縮は、より圧縮率が高く、一方lzo圧縮はより高速でCPU負荷が低くなります。

次に例を示します。

mount -o compress /dev/sdx /mnt

ファイルを作成し、そのファイルに書き込む場合で、圧縮された結果のサイズが未圧縮サイズよりも大きいか等しい場合、Btrfsはこのファイルに以後も書き込みができるように圧縮をスキップします。この動作が必要ない場合、compress-forceオプションを使用します。最初の圧縮できないデータを含むファイルには有効です。

圧縮は、新規ファイルのみに効果があることに注意してください。圧縮なしで書き込まれたファイルは、ファイルシステムがcompressオプションまたはcompress-forceオプションを使用してマウントされたときに圧縮されません。また、nodatacow属性を持つファイルのエクステントは圧縮されません。

chattr +C FILE
mount -o nodatacow  /dev/sdx /mnt

暗号化は、圧縮処理とは関係のない独立した処理です。このパーティションにデータを書き込んだら、詳細を印刷してください。

btrfs filesystem show /mnt
btrfs filesystem show /mnt
Label: 'Test-Btrfs'  uuid: 62f0c378-e93e-4aa1-9532-93c6b780749d
        Total devices 1 FS bytes used 3.22MiB
      devid    1 size 2.00GiB used 240.62MiB path /dev/sdb1

永続的に設定したい場合、compressオプションまたはcompress-forceオプションを/etc/fstab設定ファイルに追加します。次に例を示します。

UUID=1a2b3c4d /home btrfs subvol=@/home,compress 0 0

サブボリュームのマウント

SUSE Linux Enterprise Server上のスナップショットからシステムをロールバックするには、まずスナップショットからブートします。これにより、ロールバックを実行する前に、スナップショットを実行しながらチェックできます。スナップショットからブートできるようにするには、サブボリュームをマウントします(通常は不要な操作です)。

ルートパーティションのデフォルトのサブボリュームセットアップに一覧にされているサブボリューム以外に、@という名前のボリュームが存在します。これは、ルートパーティション(/)としてマウントされるデフォルトサブボリュームです。それ以外のサブボリュームは、このボリュームにマウントされます。

スナップショットからブートすると、@サブボリュームではなく、スナップショットが使用されます。スナップショットに含まれるファイルシステムの部分は、/として読み込み専用でマウントされます。それ以外のサブボリュームは、スナップショットに書き込み可能でマウントされます。この状態は、デフォルトでは一時的なものです。次回の再起動により、前の設定が復元されます。これを永久的なものにするには、snapper rollbackコマンドを実行します。これにより、今回のブートに使用したスナップショットが新しいデフォルトのサブボリュームになり、再起動後はこのサブボリュームが使用されます。

ExtおよびReiserFSの各ファイルシステムからBtrfsへのマイグレーション

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

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

sudo btrfs-convert <device>

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

sudo btrfs-convert -r <device>

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

Btrfsの管理

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

Btrfsの管理ツールは、btrfsprogsパッケージ内に用意されています。Btrfsコマンドの使用については、man 8 btrfsman 8 btrfsck、およびman 8 mkfs.btrfsの各コマンドを参照してください。Btrfsの機能については、Btrfs wiki (http://btrfs.wiki.kernel.org)を参照してください。

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

Btrfs rootファイルシステムのサブボリューム/var/log/var/crashおよび/var/cacheが、通常の操作時に利用可能なディスクスペースのすべてを使用でき、システムに不具合が発生します。この状況を回避するため、SUSE Linux Enterprise Serverではサブボリュームに対するBtrfsクォータのサポートを提供するようになりました。YaSTからの提案に従ってルートファイルシステムを設定する場合、ルートファイルシステムは必要に応じて準備されます。サブボリュームはすべて、クォータグループ(qgroup)を設定済みです。ルートファイルシステムのサブボリュームにクォータを設定するには、次の手順に従います。

  1. クォータサポートを有効にします。

    sudo btrfs quota enable /
  2. サブボリュームのリストを取得します。

    sudo btrfs subvolume list /

    クォータは既存のサブボリュームにのみ設定できます。

  3. 前の手順で表示されたサブボリュームの1つにクォータを設定します。サブボリュームは、パス(/var/tmpなど)または0/subvolume id (0/272など)のどちらかによって識別できます。次に、/var/tmpに5GBのクォータを設定する例を示します。

    sudo btrfs qgroup limit 5G /var/tmp

    サイズは、バイト(5000000000)、キロバイト(5000000K)、メガバイト(5000M)、またはギガバイト(5G)のいずれかの単位で指定できます。結果として得られるサイズは多少異なります。これは、1024バイト=1KiB、1024KiB=1MiBなどだからです。

  4. 既存のクォータを一覧にするには、次のコマンドを使用します。max_rfer列に、クォータがバイト単位で表示されます。

    sudo btrfs qgroup show -r /

ヒント: クォータの無効化

既存のクォータを無効にする場合、クォータサイズを0に設定します。

sudo btrfs qgroup limit 0 /var/tmp

特定のパーティションとそのすべてのサブボリュームのクォータサポートを無効にするには、btrfs quota disableを使用します。

sudo btrfs quota disable /

詳細については、man 8 btrfs-qgroupおよびman 8 btrfs-quotaを参照してください。Btrfs wiki (https://btrfs.wiki.kernel.org/index.php/UseCases)のUseCasesページにも詳細情報が記載されています。

データ重複排除のサポート

Btrfsはデータ重複排除をサポートします。そのための方法として、ファイルシステム内の複数の同一ブロックを、共通ストレージロケーションにある、そのブロックの1つのコピーを指す論理リンクで置き換えます。SUSE Linux Enterprise Serverでは、ファイルシステムをスキャンして同一ブロックをチェックするduperemoveツールを提供しています。このツールをBtrfsファイルシステムで使用した場合、該当するブロックを重複排除することもできます。duperemoveはデフォルトではインストールされません。使用できるようにするには、パッケージduperemoveをインストールします。

メモ: 使用例

SUSE Linux Enterprise Server 12 SP1の時点では、duperemoveはファイルシステム全体の重複排除という用途には適していません。このツールは、仮想マシンイメージなど、大量のブロックが共通する可能性がある10~50個の大容量ファイルの重複排除に使用することを想定しています。

duperemoveは、ファイルのリストを処理することも、ディレクトリを再帰的にスキャンすることもできます。

sudo duperemove [options] file1 file2 file3
sudo duperemove -r [options] directory

動作モードには、読み込み専用と重複排除の2つがあります。読み込み専用モードで実行した場合(-dスイッチを指定しない)、指定されたファイルまたはディレクトリをスキャンして重複ブロックをチェックし、出力します。これは、どのファイルシステムでも機能します。

重複排除モードでのduperemoveの実行は、Btrfsファイルシステムでのみサポートされています。指定されたファイルまたはディレクトリをスキャンした後、重複しているブロックは重複排除用に送信されます。

詳細については、man 8 duperemoveを参照してください。

1.2.2 XFS

本来は、IRIX OS用のファイルシステムを意図してSGIがXFSの開発を開始したのは、1990年代初期です。XFSの開発動機は、ハイパフォーマンスの64ビットジャーナルファイルシステムの作成により、非常に厳しいコンピューティングの課題に対応することでした。XFSは大規模なファイルを操作する点で非常に優れていて、ハイエンドのハードウェアを適切に活用します。XFSは、SUSE Linux Enterprise Serverのデータパーティション用のデフォルトファイルシステムです。

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

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

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

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

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

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

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

メモ: 新しいXFSオンディスクフォーマット

SUSE Linux Enterprise Serverはバージョン12以降、XFSファイルシステムの新しいオンディスクフォーマット (v5)をサポートしています。YaSTによって作成されるXFSファイルシステムは、この新しいフォーマットを使用します。このフォーマットの主な利点には、全XFSメタデータの自動チェックサム、ファイルタイプのサポート、および1つのファイルに対する大量のアクセス制御リストのサポートがあります。

このフォーマットは、SUSE Linux Enterpriseカーネルのバージョン3.12より古いバージョン、xfsprogsの3.2.0より古いバージョン、およびSUSE Linux Enterprise 12より前にリリースされたバージョンのGRUB 2ではサポートされていません。このことは、これらの前提条件を満たさないシステムからもこのファイルシステムを使用する必要がある場合に問題になります。

XFSファイルシステムと古いSUSEシステムまたは他のLinuxディストリビューションとの相互運用性が必要な場合は、mkfs.xfsコマンドを使用して手動でファイルシステムをフォーマットします。これにより、古いフォーマットでXFSファイルシステムが作成されます(-m crc=1オプションを使用する場合を除く)。

1.2.3 Ext2

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

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

堅実性と速度

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

容易なアップグレード性

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

1.2.4 Ext3

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

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

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への変換

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/dracut.conf.d/01-dist.confに追加します。

      force_drivers+="ext3 jbd"
    2. dracut -fコマンドを実行します。

  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ファイルシステムで可能だった数の半分となります。

重要: 既存のExt3ファイルシステムのInodeサイズの変更

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)コマンドに渡します。たとえば、次のコマンドのいずれかを使用します:

    sudo mkfs.ext3 -b 4096 -i 8092 -I 128 /dev/sda2
    sudo 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>
        </partitions>
      </drive>
    <partitioning>

詳細については、http://www.suse.com/support/kb/doc.php?id=7009075を参照してください(SLES11のExt3パーティションには、SLES10で格納できるファイルの50%しか格納することができません) [技術情報文書7009075]。

1.2.5 Ext4

2006年に、Ext4はExt3の後継として登場しました。最大1エクスビバイトのサイズのボリューム、最大16テビバイトのサイズのファイル、および無制限のサブディレクトリをサポートすることによって、Ext3のストレージに関する制限を解消しました。同時に、遅延ブロック割り当て、ファイルシステムチェックルーチンの大幅な高速化など、さまざまなパフォーマンス強化も施されています。また、Ext4は、ジャーナルチェックサムのサポートおよびナノ秒単位でのタイムスタンプの提供により、信頼性を高めています。Ext4には、Ext2とExt3との完全な後方互換性があり、どちらのファイルシステムもExt4としてマウントできます。

1.2.6 ReiserFS

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

重要: SUSE Linux Enterprise Server 12でのReiserFSのサポート

既存のReiserFSパーティションは、マイグレーション専用に、SUSE Linux Enterprise Server 12のライフタイム中はサポートされます。SUSE Linux Enterprise Server 12から、新しいReiserFSファイルシステムの作成はサポートされなくなりました。

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

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

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

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

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

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

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

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