目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Linux Enterprise Serverマニュアル / ストレージ管理ガイド / ファイルシステムとマウント / Linuxファイルシステムの概要
適用項目 SUSE Linux Enterprise Server 15 SP5

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

SUSE Linux Enterprise Serverにはいくつかの異なるファイルシステム(Btrfs、Ext4、Ext3、Ext2、XFSなど)が付属しており、そのいずれかを選択することができます。各ファイルシステムには、それぞれ独自の利点と欠点があります。SUSE Linux Enterprise Serverにおける主要ファイルシステムの機能の対照比較については、https://www.suse.com/releasenotes/x86_64/SUSE-SLES/15-SP3/#file-system-comparison(「Comparison of supported file systems (サポートされるファイルシステムの比較)」)を参照してください。この章では、それらのファイルシステムの機能および利点の概要を説明します。

SUSE Linux Enterprise 12では、オペレーティングシステム用のデフォルトファイルシステムはBtrfsであり、他はすべてXFSがデフォルトです。また、Extファイルシステムファミリ、およびOCFS2も引き続きサポートします。デフォルトでは、Btrfsファイルシステムは複数のサブボリュームと共に設定されます。ルートファイルシステムでは、Snapperインフラストラクチャを使用して、スナップショットが自動的に有効になります。Snapperの詳細については、第10章 「Snapperを使用したシステムの回復とスナップショット管理を参照してください。

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

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

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

本項で特に指定のない限り、パーティションおよびファイルシステムの設定または変更に必要なすべての手順は、YaSTパーティショナを使用して実行できます(そうすることをお勧めします)。詳細については、「第10章 「エキスパートパーティショナ」を参照してください。

1.1 用語集

metadata

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

inode

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

ジャーナル(journal)

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

1.2 Btrfs

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

1.2.1 主な特長

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 15 SP5では、RAID0、RAID1、およびRAID10プロファイルでサポートされます。それより高いレベルのRAIDは現時点サポートされませんが、将来のサービスパックでサポートされる可能性があります。

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

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

SUSE Linux Enterprise Serverのルートパーティションは、デフォルトでBtrfsとスナップショットを使用して設定されます。スナップショットを使用すると、更新適用後に必要に応じてシステムを容易にロールバックしたり、ファイルをバックアップしたりできます。スナップショットは、第10章 「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つのディレクトリはAMD64/Intel 64マシン上に存在し、その後の2つのディレクトリはそれぞれIBM POWERとIBM Z上に存在します。

/home

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

/opt

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

/srv

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

/tmp

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

/usr/local

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

/var

このディレクトリには、ログ、一時キャッシュ、/var/optのサードパーティ製品など、多くのバリアブルファイルが含まれており、仮想マシンのイメージとデータベースのデフォルトの場所です。したがって、このサブボリュームはスナップショットからすべてのこのバリアブルデータを除外するように作成され、コピーオンライトが無効になっています。

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

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

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

Btrfsファイルシステムは透過的な圧縮をサポートしています。有効にすると、Btrfsは書き込み時にファイルデータを圧縮し、読み込み時にファイルデータを解凍します。

compressまたはcompress-forceマウントオプションを使用し、圧縮アルゴリズム(zstdlzo、またはzlib)を選択します(zlibがデフォルト値です)。zlib圧縮は、より圧縮率が高く、一方lzo圧縮はより高速でCPU負荷が低くなります。zstdアルゴリズムは、lzoに近いパフォーマンスと、zlibと類似の圧縮率を備えた最新の妥協案を提供します。

例:

# mount -o compress=zstd /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

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

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

1.2.2項 「SUSE Linux Enterprise Server上のルートファイルシステム設定」の一覧に示されているサブボリューム以外に、@という名前のボリュームが存在します。これは、ルートパーティション(/)としてマウントされるデフォルトサブボリュームです。それ以外のサブボリュームは、このボリュームにマウントされます。

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

1.2.2.3 空き領域の確認

通常、ファイルシステムの使用量はdfコマンドで確認します。Btrfsファイルシステムでは、dfの出力は誤解を招く可能性があります。生データが割り当てる領域とは別に、Btrfsファイルシステムもメタデータ用の領域を割り当てて使用するからです。

その結果、まだ大量の領域を使用できるように見えても、Btrfsファイルシステムによって領域不足がレポートされることがあります。その場合、メタデータ用に割り当てられた領域はすべて使用されています。Btrfsファイルシステム上の使用済みの領域と使用可能な領域を確認するには、次のコマンドを使用します。

btrfs filesystem show
> sudo btrfs filesystem show /
Label: 'ROOT'  uuid: 52011c5e-5711-42d8-8c50-718a005ec4b3
        Total devices 1 FS bytes used 10.02GiB
        devid    1 size 20.02GiB used 13.78GiB path /dev/sda3

ファイルシステムの合計サイズとその使用量を表示します。最後の行のこれら2つの値が一致する場合、ファイルシステム上の領域はすべて割り当て済みです。

btrfs filesystem df
> sudo btrfs filesystem df /
Data, single: total=13.00GiB, used=9.61GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=768.00MiB, used=421.36MiB
GlobalReserve, single: total=144.00MiB, used=0.00B

ファイルシステムの割り当て済みの領域(total)および使用済みの領域の値を表示します。メタデータのtotalおよびusedの値がほぼ等しい場合、メタデータ用の領域はすべて割り当て済みです。

btrfs filesystem usage
> sudo btrfs filesystem usage /
Overall:
    Device size:                  20.02GiB
    Device allocated:             13.78GiB
    Device unallocated:            6.24GiB
    Device missing:                  0.00B
    Used:                         10.02GiB
    Free (estimated):              9.63GiB      (min: 9.63GiB)
    Data ratio:                       1.00
    Metadata ratio:                   1.00
    Global reserve:              144.00MiB      (used: 0.00B)

             Data     Metadata  System
Id Path      single   single    single   Unallocated
-- --------- -------- --------- -------- -----------
 1 /dev/sda3 13.00GiB 768.00MiB 32.00MiB     6.24GiB
-- --------- -------- --------- -------- -----------
   Total     13.00GiB 768.00MiB 32.00MiB     6.24GiB
   Used       9.61GiB 421.36MiB 16.00KiB

前の2つのコマンドを組み合わせたのと同様のデータを表示します。

詳細については、man 8 btrfs-filesystemおよびhttps://btrfs.wiki.kernel.org/index.php/FAQを参照してください。

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

btrfs-convertツールを使用して、既存のReiserFSまたはExt (Ext2、Ext3、またはExt4)からBtrfsファイルシステムにデータボリュームをマイグレートすることができます。これにより、アンマウントされた(オフライン)ファイルシステムのインプレース変換を実行できます。これにはbtrfs-convertツールとともにブート可能なインストールメディアが必要な場合があります。このツールは元のファイルシステムの空き領域内にBtrfsファイルシステムを構築し、それに含まれているデータに直接リンクします。メタデータを作成するにはデバイスに十分な空き領域が必要です。さもないと変換に失敗します。元のファイルシステムはそのままとなり、Btrfsファイルシステムによって空き領域が占有されることはありません。必要なスペースの量はファイルシステムのコンテンツによって決まりますが、そこに含まれるファイルシステムオブジェクト(ファイル、ディレクトリ、拡張属性)の数によって左右される場合があります。データは直接参照されるため、ファイルシステム上のデータ量は変換に必要なスペースに影響を与えません。ただし、テールパッキングを使用するファイルや2KiBを超えるサイズのファイルは除きます。

警告
警告: ルートファイルシステムの変換は未サポート

ルートファイルシステムをBtrfsに変換する操作はサポートも推奨もされません。さまざまなステップをそれぞれのセットアップに合わせる必要があるため、このような変換の自動化は不可能です。このプロセスには、適切なロールバックを実行するために複雑な設定を行う必要があり、/bootがルートファイルシステム上にある必要があり、システムに専用のサブボリュームが存在する必要があるなどの要件があります。そのため、既存のファイルシステムを保持するか、新たにシステム全体を再インストールしてください。

元のファイルシステムをBtrfsファイルシステムに変換するには、次のコマンドを実行します。

# btrfs-convert /path/to/device
重要
重要: チェック /etc/fstab

変換後は、/etc/fstabに記載されている元のファイルシステムへのすべての参照で、デバイスにBtrfsファイルシステムがあることが示されるように調整されていることを確認する必要があります。

変換時には、Btrfsファイルシステムのコンテンツにソースファイルシステムのコンテンツが反映されます。ソースファイルシステムは、fs_root/reiserfs_saved/imageで作成された関連する読み込み専用イメージを削除するまで保持されます。イメージファイルの実態は、変換前におけるReiserFSファイルシステムの「スナップショット」であり、Btrfsファイルシステムが変更されても変わりません。イメージファイルを削除するには、reiserfs_savedサブボリュームを削除します。

# btrfs subvolume delete fs_root/reiserfs_saved

ファイルシステムを元に戻すには、次のコマンドを使用します。

# btrfs-convert -r /path/to/device
警告
警告: 失われる変更

Btrfsファイルシステムとしてマウントされているファイルシステムへの変更はすべて失われます。マウント中には負荷分散操作を実行しないでください。さもないと、ファイルシステムが正しく復元されなくなります。

1.2.4 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)を参照してください。

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

Btrfsルートファイルシステムのサブボリューム(/var/log/var/crash、または/var/cacheなど)が、通常の操作時に利用可能なディスクスペースのすべてを使用でき、システムに不具合が発生します。この状況を回避するため、SUSE Linux Enterprise ServerではBtrfsサブボリュームに対するクォータのサポートを提供するようになりました。YaSTの提案からルートファイルシステムを設定すると、サブボリュームのクォータを有効にして設定する準備が整います。

1.2.5.1 YaSTを使用したBtrfsクォータの設定

YaSTを使用してルートファイルシステムのサブボリュームにクォータを設定するには、次の手順に従います。

  1. YaSTを起動し、システム › パーティショナを選択して、はいで警告を確認します。

  2. 左側のペインで、Btrfsをクリックします。

  3. メインウィンドウで、サブボリュームクォータを有効にするデバイスを選択して、下部にある編集をクリックします。

  4. Edit Btrfs (Btrfsの編集)ウィンドウで、サブボリュームのクオータの有効化チェックボックスを有効にし、次へで確定します。

    Btrfsクオータの有効化
    図 1.1: Btrfsクオータの有効化
  5. 既存のサブボリュームのリストから、クォータでサイズを制限するサブボリュームをクリックし、下部にある編集をクリックします。

  6. Edit subvolume of Btrfs (Btrfsのサブボリュームの編集)ウィンドウで、Limit size (サイズ制限)を有効にし、参照される最大サイズを指定します。受諾をクリックして確認します。

    サブボリュームのクォータの設定
    図 1.2: サブボリュームのクォータの設定

    サブボリューム名の横に新しいサイズ制限が表示されます。

    デバイスのサブボリュームのリスト
    図 1.3: デバイスのサブボリュームのリスト
  7. 次へで変更を適用します。

1.2.5.2 コマンドラインでのBtrfsクォータの設定

コマンドラインでルートファイルシステムのサブボリュームにクォータを設定するには、次の手順に従います。

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

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

    > sudo btrfs subvolume list /

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

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

    > sudo btrfs qgroup limit 5G /var/tmp

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

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

    > sudo btrfs qgroup show -r /
ヒント
ヒント: クォータの無効化

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

> sudo btrfs qgroup limit none /var/tmp

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

> sudo btrfs quota disable /

1.2.5.3 詳細情報

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

1.2.6 Btrfsでのスワッピング

重要
重要: スワッピングを使用したスナップショット

有効なスワップファイルがソースサブボリュームに含まれている場合、スナップショットを作成できません。

SLESでは、結果のスワップファイルに関連する次の条件が満たされている場合、Btrfsファイルシステム上のファイルへのスワッピングをサポートしています。

  • スワップファイルにはNODATACOWおよびNODATASUMマウントオプションが必要です。

  • スワップファイルは圧縮できません - NODATACOWおよびNODATASUMマウントオプションを設定することで、これを確認できます。両方のオプションにより、スワップファイルの圧縮が無効になります。

  • スワップファイルは、デバイスのサイズ変更、追加、削除、置換などの排他的な操作の実行中、またはバランシング操作の実行中は有効にできません。

  • スワップファイルはスパースにすることはできません。

  • スワップファイルはインラインファイルにすることはできません。

  • スワップファイルはsingle割り当てプロファイルファイルシステム上にある必要があります。

1.2.7 Btrfs send/receive

Btrfsでは、ファイルシステムの状態をキャプチャするためのスナップショットを作成できます。Snapperでは、たとえばこの機能を使用してシステムの変更前後のスナップショットを作成することで、ロールバックを可能にしています。ただし、send/receive機能とスナップショットを併用すると、リモートの場所にファイルシステムのコピーを作成して管理することもできます。たとえば、この機能を使用してインクリメンタルバックアップを実行できます。

btrfs send操作は、同じサブボリュームの2つの読み込み専用スナップショットの差分を計算して、それをファイルまたはSTDOUTに送信します。btrfs receive操作は、sendコマンドの結果を取得して、それをスナップショットに適用します。

1.2.7.1 前提条件

send/receive機能を使用するには、次の要件を満たす必要があります。

  • ソース側(send)とターゲット側(receive)にBtrfsファイルシステムが必要です。

  • Btrfs send/receiveはスナップショットを操作するため、それぞれのデータがBtrfsサブボリュームに存在する必要があります。

  • ソース側のスナップショットは読み込み専用である必要があります。

  • SUSE Linux Enterprise 12 SP2以上。それより古いバージョンのSUSE Linux Enterpriseはsend/receiveをサポートしていません。

1.2.7.2 インクリメンタルバックアップ

次の手順では、/data(ソース側)のインクリメンタルバックアップを/backup/data(ターゲット側)に作成する場合を例にして、Btrfs send/receiveの基本的な使用方法を示します。/dataはサブボリュームである必要があります。

手順 1.1: 初期セットアップ
  1. ソース側に初期スナップショット(この例ではsnapshot_0という名前)を作成し、それがディスクに書き込まれていることを確認します。

    > sudo btrfs subvolume snapshot -r /data /data/bkp_data
    sync

    新しいサブボリューム/data/bkp_dataが作成されます。これは次のインクリメンタルバックアップの基として使用されるので、参照用に保持しておく必要があります。

  2. 初期スナップショットをターゲット側に送信します。これは初期のsend/receive操作であるため、完全なスナップショットを送信する必要があります。

    > sudo bash -c 'btrfs send /data/bkp_data | btrfs receive /backup'

    ターゲット側に新しいサブボリューム/backup/bkp_dataが作成されます。

初期セットアップが完了したら、インクリメンタルバックアップを作成して、現在のスナップショットと以前のスナップショットの差分をターゲット側に送信できます。手順は常に同じです。

  1. ソース側に新しいスナップショットを作成します。

  2. 差分をターゲット側に送信します。

  3. オプション: 両側のスナップショットの名前変更またはクリーンアップ、あるいはその両方を行います。

手順 1.2: インクリメンタルバックアップの実行
  1. ソース側に新しいスナップショットを作成し、それがディスクに書き込まれていることを確認します。次の例では、スナップショットにbkp_data_CURRENT_DATEという名前が付いています。

    > sudo btrfs subvolume snapshot -r /data /data/bkp_data_$(date +%F)
    sync

    新しいサブボリューム(たとえば、/data/bkp_data_2016-07-07)が作成されます。

  2. 以前のスナップショットと新たに作成したスナップショットの差分をターゲット側に送信します。そのためには、オプション-p SNAPSHOTを使用して、以前のスナップショットを指定します。

    > sudo bash -c 'btrfs send -p /data/bkp_data /data/bkp_data_2016-07-07 \
    | btrfs receive /backup'

    新しいサブボリューム/backup/bkp_data_2016-07-07が作成されます。

  3. その結果、それぞれの側に2つずつ、合計4つのスナップショットが存在することになります。

    /data/bkp_data
    /data/bkp_data_2016-07-07
    /backup/bkp_data
    /backup/bkp_data_2016-07-07

    続行するには、次の3つのオプションがあります。

    • 両方の側のすべてのスナップショットを保持する。このオプションの場合、両方の側のどのスナップショットにもロールバックすることが可能であると同時に、すべてのデータの複製を保持していることになります。これ以上のアクションは必要ありません。次回のインクリメンタルバックアップを実行するときには、最後から2番目のスナップショットをsend操作の親として使用することに注意してください。

    • ソース側には最新のスナップショットのみを保持し、ターゲット側にはすべてのスナップショットを保持する。この場合も、両方の側のどのスナップショットにもロールバックできます。ソース側で特定のスナップショットへのロールバックを実行するには、ターゲット側からソース側に、完全なスナップショットのsend/receive操作を実行します。ソース側で削除/移動操作を実行します。

    • 両方の側に最新のスナップショットのみを保持する。この方法では、ソース側で作成された最新のスナップショットと同じ状態のバックアップがターゲット側にあります。ほかのスナップショットにロールバックすることはできません。ソース側とターゲット側で削除/移動操作を実行します。

    1. ソース側に最新のスナップショットのみを保持するには、次のコマンドを実行します。

      > sudo btrfs subvolume delete /data/bkp_data
      > sudo mv /data/bkp_data_2016-07-07 /data/bkp_data

      最初のコマンドで以前のスナップショットを削除し、2番目のコマンドで現在のスナップショットの名前を/data/bkp_dataに変更します。これにより、バックアップされた最新のスナップショットは常に/data/bkp_dataという名前になります。その結果、常にこのサブボリューム名をインクリメンタルsend操作の親として使用できます。

    2. ターゲット側に最新のスナップショットのみを保持するには、次のコマンドを実行します。

      > sudo btrfs subvolume delete /backup/bkp_data
      > sudo mv /backup/bkp_data_2016-07-07 /backup/bkp_data

      最初のコマンドで以前のバックアップスナップショットを削除し、2番目のコマンドで現在のスナップショットの名前を/backup/bkp_dataに変更します。これにより、最新のバックアップスナップショットは常に/backup/bkp_dataという名前になります。

ヒント
ヒント: リモートターゲット側への送信

スナップショットをリモートマシンに送信するには、SSHを使用します。

> btrfs send /data/bkp_data | ssh root@jupiter.example.com 'btrfs receive /backup'

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

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

注記
注記: 大量のデータセットの重複排除

大量のファイルを重複排除する場合は、--hashfileオプションを使用します。

> sudo duperemove --hashfile HASH_FILE file1 file2 file3

--hashfileオプションは、すべての指定されたファイルのハッシュをRAMではなくHASH_FILEに保存して、使い果たされるのを防ぎます。HASH_FILEは再利用可能です。ベースラインハッシュファイルを生成した最初の実行後、大量のデータセットへの変更を非常に迅速に重複排除できます。

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

> sudo duperemove OPTIONS file1 file2 file3
> sudo duperemove -r OPTIONS directory

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

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

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

1.2.9 ルートファイルシステムからのサブボリュームの削除

特定の目的のためにルートファイルシステムからデフォルトのBtrfsサブボリュームの1つを削除する必要がある場合があります。それらの1つはサブボリューム、たとえば@/homeまたは@/srvを別のデバイスのファイルシステムに変換します。次の手順は、Btrfsサブボリュームを削除する方法を示しています。

  1. 削除する必要のあるサブボリュームを特定します(たとえば、@/opt)。ルートパスのサブボリュームIDが常に「5」であることに注意してください。

    > sudo btrfs subvolume list /
    ID 256 gen 30 top level 5 path @
    ID 258 gen 887 top level 256 path @/var
    ID 259 gen 872 top level 256 path @/usr/local
    ID 260 gen 886 top level 256 path @/tmp
    ID 261 gen 60 top level 256 path @/srv
    ID 262 gen 886 top level 256 path @/root
    ID 263 gen 39 top level 256 path @/opt
    [...]
  2. ルートパーティションをホストするデバイス名を見つけます:。

    > sudo btrfs device usage /
    /dev/sda1, ID: 1
      Device size:            23.00GiB
      Device slack:              0.00B
      Data,single:             7.01GiB
      Metadata,DUP:            1.00GiB
      System,DUP:             16.00MiB
      Unallocated:            14.98GiB
  3. ルートファイルシステム(ID 5のサブボリューム)を別のマウントポイント(たとえば/mnt)上にマウントします。

    > sudo mount -o subvolid=5 /dev/sda1 /mnt
  4. マウントされたルートファイルシステムから@/optパーティションを削除します。

    > sudo btrfs subvolume delete /mnt/@/opt
  5. 以前にマウントされたルートファイルシステムをアンマウントします:。

    > sudo umount /mnt

1.3 XFS

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

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

高いスケーラビリティ

XFSはアロケーショングループを使用して高いスケーラビリティを実現する

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

高いパフォーマンス

XFSはディスクスペースの効率的な管理によって高いパフォーマンスを実現する

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

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

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

1.3.1 XFSフォーマット

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

このフォーマットは、SUSE Linux Enterpriseカーネルの3.12より古いバージョン、xfsprogsの3.2.0より古いバージョン、およびSUSE Linux Enterprise 12より前にリリースされたバージョンのGRUB 2ではサポートされていません。

重要
重要: V4は非推奨

XFSではV4フォーマットのファイルシステムが非推奨になっています。このファイルシステムフォーマットは次のコマンドで作成されました。

mkfs.xfs -m crc=0 DEVICE

このフォーマットはSLE 11以前のリリースで使用されましたが、現在このフォーマットを使用するとdmesgによって次の警告メッセージが表示されます。

Deprecated V4 format (crc=0) will not be supported after September 2030

dmesgコマンドの出力に上記のメッセージが表示されたら、ファイルシステムをV5フォーマットに更新することをお勧めします。

  1. データを別のデバイスにバックアップします。

  2. そのデバイスにファイルシステムを作成します。

    mkfs.xfs -m crc=1 DEVICE
  3. 更新したデバイスにバックアップからデータを復元します。

1.4 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.5 Ext3

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

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

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

1.5.2 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/filesystem.confを開くか作成し、次の行を追加します(行頭空白に注意してください):

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

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

1.6 Ext4

2006年に、Ext4はExt3の後継として登場しました。これは、拡張ファイルシステムバージョンの最新ファイルシステムです。当初、最大1エクスビバイトのサイズのボリューム、最大16テビバイトのサイズのファイルおよび無制限の数のサブディレクトリをサポートすることによってストレージサイズを拡大するために、Ext4は設計されました。Ext4では、従来の直接ブロックポインタおよび間接ブロックポインタの代わりにエクステントを使用してファイルの内容をマップします。エクステントの使用によって、ディスクにおけるデータ格納とデータ取得の両方が改善されています。

同時に、遅延ブロック割り当て、ファイルシステムチェックルーチンの大幅な高速化など、さまざまなパフォーマンス強化も図られています。また、Ext4は、ジャーナルチェックサムのサポートおよびナノ秒単位でのタイムスタンプの提供により、信頼性を高めています。Ext4には、Ext2およびExt3との完全な後方互換性があり、どちらのファイルシステムもExt4としてマウントできます。

注記
注記: Ext4でのExt3の機能

Ext3の機能は、Ext4カーネルモジュールのExt4ドライバによって完全にサポートされます。

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

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

1.6.2 Ext4ファイルシステムのinodeサイズとinode数

inodeには、ファイルシステム内のファイルとそのブロック位置に関する情報が格納されます。拡張された属性およびACL用にinodeのスペースを確保するために、デフォルトのinodeサイズが256バイトに拡大されました。

新規のExt4ファイルシステムを作成する際、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です。

重要
重要: 既存のExt4ファイルシステムにおけるinodeサイズの変更は不可能

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

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

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

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

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

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

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

inodeサイズとバイト数/inode数の比率を設定するには、次のいずれかの方法を使用します。

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

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

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

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

    Image

1.6.3 Ext4へのアップグレード

重要
重要: データのバックアップ

ファイルシステムの更新を実行する前に、ファイルシステムにあるすべてのデータをバックアップします。

手順 1.3: Ext4へのアップグレード
  1. Ext2またはExt3からアップグレードするには、以下を有効にする必要があります。

    Ext4で必要な機能
    エクステント

    各ファイルを近くに保持して断片化を防ぐために使用されるハードディスク上の連続ブロック

    unint_bg

    遅延inodeテーブルの初期化

    dir_index

    大きいディレクトリ用のハッシュされたbツリー検索

    Ext2: as_journal

    Ext2ファイルシステムでジャーナリングを有効にします。

    これらの機能を有効にするには、次のコマンドを実行します。

    • Ext3:

      # tune2fs -O extents,uninit_bg,dir_index DEVICE_NAME
    • Ext2:

      # tune2fs -O extents,uninit_bg,dir_index,has_journal DEVICE_NAME
  2. rootによって/etc/fstabファイルが編集されるとき、ext3またはext2のレコードをext4に変更します。この変更結果は、次回の再起動後に有効になります。

  3. Ext4パーティションでセットアップされたファイルシステムをブートするには、ext4jbdの各モジュールをinitramfsに追加します。/etc/dracut.conf.d/filesystem.confを開くか作成し、次の行を追加します。

    force_drivers+=" ext4 jbd"

    既存のdracut initramfsを上書きする必要があります。そのためには、次のコマンドを実行します。

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

1.7 ReiserFS

ReiserFSのサポートは、SUSE Linux Enterprise Server 15で廃止されました。既存のパーティションをBtrfsにマイグレートするには、1.2.3項 「ReiserFSおよびExtの各ファイルシステムからBtrfsへのマイグレーション」を参照してください。

1.8 OpenZFSとZFS

OpenZFSファイルシステムもZFSファイルシステムもSUSEではサポートされていません。ZFSは閉じられたソースファイルシステムであるため、SUSEでは使用できません。OpenZFSは、GPLライセンスと互換性のないCDDLライセンスの下にあります。ただし、BtrfsにはOpenZFS respのすばらしい代替品があります。ZFSはSUSEによって完全にサポートされています。

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

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

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

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

説明

iso9660

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

msdos

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

nfs

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

ntfs

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

exfat

USBフラッシュドライブやSDカードなど、フラッシュメモリで使用するために最適化されたファイルシステムです。

smbfs

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

ufs

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

umsdos

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

vfat

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

1.10 ブロックされるファイルシステム

セキュリティ上の理由によって、自動マウントからブロックされるファイルシステムがあります。これらのファイルシステムは通常維持されなくなり、一般的に使用されません。ただし、このファイルシステムのカーネルモジュールをロードできます。これは、カーネル内のAPIの互換性が保たれているためです。ユーザがマウントできるファイルシステムとファイルシステムの自動マウントを取り外し可能デバイスで組み合わせると、特権のないユーザがカーネルモジュールの自動ロードをトリガする状況が発生し、悪意のあるデータが取り外し可能デバイスに格納される危険性があります。

自動マウントが許可されていないファイルシステムのリストを取得するには、次のコマンドを実行します。

> sudo rpm -ql suse-module-tools  | sed -nE 's/.*blacklist_fs-(.*)\.conf/\1/p'

mountコマンドを使用してブロックされるファイルシステムでデバイスをマウントしようとすると、このコマンドはエラーメッセージを出力します。次に例を示します。

mount: /mnt/mx: unknown filesystem type 'minix' (hint: possibly blacklisted, see mount(8)).

ファイルシステムのマウントを有効にするには、ブロックリストからそのファイルシステムを削除する必要があります。ブロックされるファイルシステムそれぞれに独自の設定ファイルがあります。たとえば、efsでは/lib/modules.d/60-blacklist_fs-efs.confです。ただし、suse-module-toolsパッケージが更新されると、これらのファイルは必ず上書きされるため、編集しないでください。ブロックされるファイルシステムの自動マウントを許可するには、次の方法があります。

  • /dev/nullヘのシンボリックリンクを作成します。たとえば、efsファイルシステムの場合には次のようにします。

    > sudo ln -s /dev/null /etc/modules.d/60-blacklist_fs-efs.conf
  • 設定ファイルを/etc/modprobe.dにコピーします。

    > sudo cp /lib/modules.d/60-blacklist_fs-efs.conf /etc/modprobe.d/60-blacklist_fs-efs.conf

    設定ファイルの次のステートメントをコメントにします。

    # blacklist omfs

ファイルシステムを自動マウントできない場合でも、modprobeを直接使用して、そのファイルシステムの対応するカーネルモジュールをロードできます。

> sudo modprobe FILESYSTEM

たとえば、cramfsファイルシステムの場合、出力は次のようになります。

unblacklist: loading cramfs file system module
unblacklist: Do you want to un-blacklist cramfs permanently (<y>es/<n>o/n<e>ver)? y
unblacklist: cramfs un-blacklisted by creating /etc/modprobe.d/60-blacklist_fs-cramfs.conf

yesを選択すると、modprobeコマンドは、指定したファイルシステムの設定ファイルからシンボリックリンクを作成するスクリプトを/dev/nullに呼び出します。したがって、このファイルシステムはブロックリストから削除されます。

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

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

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

注記
注記: バイナリの倍数

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

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

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

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

ファイルの最大サイズ

Btrfs

16EiB

16EiB

Ext3

16TiB

2TiB

Ext4

1EiB

16TiB

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

16TiB

1EiB

XFS

16EiB

8EiB

NFSv2 (クライアント側)

8EiB

2GiB

NFSv3/NFSv4 (クライアント側)

8EiB

8EiB

重要
重要: 制限

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

ファイルサイズ

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

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

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

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

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

表 1.3: ストレージの制限

ストレージの機能

制限

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

ターゲットあたり16384 LUN。

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

デフォルトで無制限。それぞれのパスが、通常のLUNとして扱われます。

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

HBAの最大数

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

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

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

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

最大8EiB。

1.13 未使用のファイルシステムブロックの解放

SSD(Solid-State Drive)およびシンプロビジョニングされたボリュームでは、ファイルシステムによって使用されていないブロックに対してTrimを実行すると効果的です。SUSE Linux Enterprise Serverは、unmapおよびTRIMの操作をサポートするすべてのファイルシステムで、これらの操作を完全にサポートします。

2つのタイプの一般的に使用されるTRIM(オンラインTRIMと定期TRIM)があります。デバイスをトリムする最も適切な方法は使用例によって異なります。一般的に、定期TRIMの使用をお勧めします(特に、デバイスに十分な未使用ブロックがある場合)。デバイスの容量が一杯に近くなることが多い場合はオンラインTRIMをお勧めします。

重要
重要: デバイスでのTRIMのサポート

TRIMを使用する前に、デバイスがこの操作をサポートしていることを必ず確認してください。確認を怠ると、そのデバイスのデータが喪失する危険性があります。TRIMのサポートを確認するには、次のコマンドを実行します。

> sudo lsblk --discard

このコマンドを実行すると、使用可能なすべてのブロックデバイスに関する情報が出力されます。DISC-GRAN列およびDISC-MAX列の値がゼロ以外の場合、デバイスはTRIM操作をサポートしています。

1.13.1 定期TRIM

定期TRIMは、定期的にsystemdによって呼び出されるfstrimコマンドによって処理されます。コマンドを手動で実行することもできます。

定期TRIMをスケジュールするには、次のようにfstrim.timerを有効にします。

> sudo systemctl enable fstrim.timer

systemd/usr/lib/systemd/systemにユニットファイルを作成します。デフォルトでは、このサービスは1週間に1回実行されます。通常はこれで十分です。ただし、OnCalendarオプションを目的の値に設定することによって頻度を変更できます。

fstrimのデフォルト動作は、ファイルシステムですべてのブロックを破棄することです。コマンドを呼び出すときにオプションを使用してこの動作を変更できます。たとえば、offsetオプションを渡してトリミング手順の開始地点を定義できます。詳細については、man fstrimを参照してください。

fstrimコマンドを実行すると、/etc/fstabファイルに保存されているすべてのデバイスでトリミングを実行できます。これはTRIM操作をサポートしています。この目的でコマンドを呼び出すときには-Aオプションを使用します。

特定のデバイスのトリミングを無効にするには、次のようにX-fstrim.notrimオプションを/etc/fstabファイルに追加します。

UID=83df497d-bd6d-48a3-9275-37c0e3c8dc74  /  btrfs  defaults,X-fstrim.notrim                      0  0

1.13.2 オンラインTRIM

デバイスのオンラインTRIMは、デバイスにデータを書き込むたびに実行されます。

デバイスのオンラインTRIMを有効にするには、次のようにdiscardオプションを/etc/fstabファイルに追加します。

UID=83df497d-bd6d-48a3-9275-37c0e3c8dc74  /  btrfs  defaults,discard

また、Ext4ファイルシステムでtune2fsコマンドを使用して/etc/fstabdiscardオプションを設定します。

> sudo tune2fs -o discard DEVICE

discardオプションを指定してmountによってデバイスがマウントされた場合も、discardオプションは/etc/fstabに追加されます。

> sudo mount -o discard DEVICE
注記
注記: オンラインTRIMの欠点

discardオプションを使用すると、一部の低品質SSDデバイスの寿命が短くなる場合があります。オンラインTRIMによってデバイスのパフォーマンスに悪影響が及ぶ場合もあります(大量のデータが削除される場合など)。この状況では、消去ブロックが再割り当てされ、そのすぐ後に同じ消去ブロックが未使用として再度マークされる場合があります。

1.14 ファイルシステムのトラブルシューティング

本項では、ファイルシステムに関するいくつかの既知の問題と、考えられる解決手段について説明します。

1.14.1 Btrfsエラー: デバイスに空き領域がない

Btrfsファイルシステムを使用しているルート(/)パーティションにデータを書き込めなくなります。No space left on deviceというエラーが発生します。

考えられる原因とこの問題の回避策については、この後の各項を参照してください。

1.14.1.1 Snapperスナップショットによるディスク容量の使用

BtrfsファイルシステムでSnapperが動作している場合、No space left on deviceが表示される問題は、通常は、システム上にスナップショットとして保存されているデータが多すぎるために発生します。

Snapperからいくつかのスナップショットを削除することはできますが、スナップショットはすぐには削除されないので、必要な容量が解放されない可能性があります。

Snapperからファイルを削除するには:

  1. 端末を開きます。

  2. コマンドプロンプトで、たとえば「btrfs filesystem show」と入力します。

    > sudo btrfs filesystem show
    Label: none uuid: 40123456-cb2c-4678-8b3d-d014d1c78c78
     Total devices 1 FS bytes used 20.00GB
     devid 1 size 20.00GB used 20.00GB path /dev/sda3
  3. 以下を入力してください。

    > sudo btrfs fi balance start MOUNTPOINT -dusage=5

    このコマンドは、データを空またはほぼ空のデータチャンクに再配置して、その容量を回収し、メタデータに再割り当てしようとします。この処理にはしばらくかかります(1 TBで数時間)が、処理中もシステムは使用可能です。

  4. Snapperのスナップショットを一覧にします。以下を入力してください。

    > sudo snapper -c root list
  5. Snapperから1つ以上のスナップショットを削除します。以下を入力してください。

    > sudo snapper -c root delete SNAPSHOT_NUMBER(S)

    必ず最も古いスナップショットを最初に削除してください。古いスナップショットほど、多くの容量を使用します。

この問題が発生しないように、Snapperのクリーンアップアルゴリズムを変更できます。詳細については10.6.1.2項 「クリーンアップアルゴリズム」を参照してください。スナップショットクリーンアップを制御する設定値は、EMPTY_*NUMBER_*、およびTIMELINE_*です。

ファイルシステムディスクでBtrfsとSnapperを使用する場合、標準のストレージ案の2倍のディスク容量を確保しておくことが推奨されます。YaSTパーティショナは、ルートファイルシステムでBtrfsを使用する場合のストレージ案として、自動的に標準の2倍のディスク容量を提案します。

1.14.1.2 ログ、クラッシュ、およびキャッシュのファイルによるディスク容量の使用

システムディスクがデータでいっぱいになりつつある場合、/var/log/var/crash/var/lib/systemd/coredumpおよび/var/cacheからファイルを削除する方法があります。

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

テストおよび開発用のマシンでは、特にアプリケーションが頻繁にクラッシュする場合、コアダンプが保存されている/var/lib/systemd/coredumpを確認することもできます。

1.14.2 Btrfs: デバイス間でデータのバランスを取る

btrfs balanceコマンドは、btrfs-progsパッケージの一部です。次の状況例では、Btrfsファイルシステムのブロックグループのバランスを取ります。

  • 600GBをデータで使用される1TBのドライブがあり、さらに1TBドライブを追加するとします。バランスを取ることで、理論的には、各ドライブに300GBの使用済みスペースができます。

  • デバイスには空に近い多数のチャンクがあります。バランスを取ることによりこれらのチャンクがクリアされるまで、それらのスペースは利用できません。

  • 使用率に基づいて半分空のブロックグループを圧縮する必要があります。次のコマンドは、使用率が5%以下のブロックグループのバランスを取ります。

    > sudo btrfs balance start -dusage=5 /
    ヒント
    ヒント

    /usr/lib/systemd/system/btrfs-balance.timerタイマによって、未使用ブロックグループが毎月クリーンアップされます。

  • ブロックデバイスのフルでない部分をクリアし、データをより均等に分散する必要があります。

  • 異なるRAIDタイプ間でデータを移行する必要があります。たとえば、一連のディスク上のデータをRAID1からRAID5に変換するには、次のコマンドを実行します。

    > sudo btrfs balance start -dprofiles=raid1,convert=raid5 /
ヒント
ヒント

Btrfsファイルシステム上のデータのバランスを取るデフォルトの動作(たとえば、バランスを取る頻度やマウントポイント)を微調整するには、/etc/sysconfig/btrfsmaintenanceを検査してカスタマイズします。関連するオプションは、BTRFS_BALANCE__で開始されます。

btrfs balanceコマンドの使用に関する詳細については、そのマニュアルページ(man 8 btrfs-balance)を参照してください。

1.14.3 SSDでデフラグメンテーションしない

Linuxファイルシステムには、データフラグメンテーションを回避するメカニズムがあり、通常はデフラグメントする必要はありません。ただし、データフラグメンテーションを回避できない場合、およびハードディスクのデフラグメンテーションによってパフォーマンスが大幅に向上する場合に使用するケースがあります。

これは従来のハードディスクにのみ適用されます。フラッシュメモリを使用してデータを保存するソリッドステートディスク(SSD)では、ファームウェアによってデータを書き込むチップを判断するアルゴリズムが提供されます。データは通常、ドライブ全体に分散されます。したがって、SSDのデフラグメンテーションは望ましい効果がなく、不要なデータを書き込むことにより、SSDの製品寿命を縮めます。

この理由のため、SUSEではSSDでデフラグメントしないことを明示的にお勧めします。一部のベンダーも、ソリッドステートディスクをデフラグメントすることについて警告しています。これには、次のものが含まれますが、これに限定されません。

  • HPE 3PAR StoreServオールフラッシュ

  • HPE 3PAR StoreServコンバージドフラッシュ

1.15 詳細情報

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

ファイルシステム(Linuxファイルシステムに限らない)の詳しい比較については、Wikipediaプロジェクトの「Comparison of file systems」(http://en.wikipedia.org/wiki/Comparison_of_file_systems#Comparison)を参照してください。