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

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の詳細については、第7章 「Snapperを使用したシステムの回復とスナップショット管理」を参照してください。

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

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

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

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

1.1 用語集

 
metadata

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

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

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

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

 

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

 
注記
注記: GRUB 2および圧縮ルート

GRUB 2はlzoまたはzstd圧縮ルートファイルシステムからブートできません。ルートにlzoまたはzstd圧縮を使用する場合は、zlib圧縮を使用するか、別の/bootパーティションを作成します。

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

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

例: 

root # mount -o compress=zstd /dev/sdx /mnt

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

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

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

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

root # 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
tux > 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
tux > 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
tux > 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ファイルシステムに変換するには、次のコマンドを実行します。 

root # btrfs-convert /path/to/device
重要
重要: /etc/fstabの確認

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

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

root # btrfs subvolume delete fs_root/reiserfs_saved

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

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

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

1.2.4 Btrfsの管理

 

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

Btrfsの管理ツールは、btrfsprogsパッケージ内に用意されています。Btrfsコマンドの使用については、man 8 btrfs、man 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. クォータサポートを有効にします。 

    tux > sudo btrfs quota enable /

  2. サブボリュームのリストを取得します。 

    tux > sudo btrfs subvolume list /

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

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

    tux > sudo btrfs qgroup limit 5G /var/tmp

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

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

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

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

tux > sudo btrfs qgroup limit none /var/tmp

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

tux > sudo btrfs quota disable /

1.2.5.3 詳細情報

 

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

1.2.6 Btrfsでのスワッピング

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

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

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

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

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

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

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

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

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

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という名前)を作成し、それがディスクに書き込まれていることを確認します。 

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

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

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

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

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

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

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

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

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

手順 1.2: インクリメンタルバックアップの実行
 

  1. ソース側に新しいスナップショットを作成し、それがディスクに書き込まれていることを確認します。次の例では、スナップショットにbkp_data_CURRENT_DATEという名前が付いています。 

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

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

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

    tux > 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. ソース側に最新のスナップショットのみを保持するには、次のコマンドを実行します。 

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

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

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

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

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

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

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

tux > 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オプションを使用します。 

tux > sudo duperemove --hashfile HASH_FILE file1 file2 file3

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

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

tux > sudo duperemove OPTIONS file1 file2 file3
tux > 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」であることに注意してください。 

    tux > 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. ルートパーティションをホストするデバイス名を見つけます:。 

    tux > 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)上にマウントします:。 

    tux > sudo mount -o subvolid=5 /dev/sda1 /mnt

  4. マウントされたルートファイルシステムから@/optパーティションを削除します:。 

    tux > sudo btrfs subvolume delete /mnt/@/opt

  5. 以前にマウントされたルートファイルシステムをアンマウントします:。 

    tux > sudo umount /mnt

1.3 XFS

 

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

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

1.3.1 アロケーショングループを使用した高スケーラビリティ

 

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

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

 

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

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

 

データをファイルシステムに書き込む前に、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.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 信頼性とパフォー\'83\'7dンス

 

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

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

 

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

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

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

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

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

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

  3. Ext3パーティションとしてセットアップされたルートファイルシステムをブートするには、ext3とjbdの各モジュールをinitrdに追加します。それには、次を実行します。

    1. /etc/dracut.conf.d/10-filesystem.confを開くか作成し、次の行を追加します(先立つ空白に注意してください): 

      force_drivers+=" ext3 jbd"

    2. dracut -fコマンドを実行します。

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

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

    tux > sudo mkfs.ext3 -b 4096 -i 8092 -I 128 /dev/sda2
tux > sudo mke2fs -t ext3 -b 4096 -i 8192 -I 128 /dev/sda2

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

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

    Image

  • 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>

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

1.6 Ext4

 

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

1.7 ReiserFS

 

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

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

 

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

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

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

説明

cramfs

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

hpfs

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

iso9660

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

minix

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

msdos

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

nfs

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

ntfs

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

exfat

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

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.9 Linux環境での大規模ファイルサポート

 

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

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

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

このマニュアルでの換算式: 1024バイト = 1KiB、1024KiB = 1MiB、1024MiB = 1GiB、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.10 Linuxのカーネルにおけるストレージの制限

 

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

表 1.3: ストレージの制限
 

ストレージの機能

制限

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

ターゲットあたり16384 LUN。

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

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

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

HBAの最大数

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

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

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

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

最大8EiB。

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

 

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

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

 

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

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

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

 

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

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

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

  1. 端末コンソールを開きます。

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

    tux > 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. 次のように入力します。 

    tux > sudo btrfs fi balance start MOUNTPOINT -dusage=5

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

  4. Snapperのスナップショットを一覧にします。次のように入力します。 

    tux > sudo snapper -c root list

  5. Snapperから1つ以上のスナップショットを削除します。次のように入力します。 

    tux > sudo snapper -c root delete SNAPSHOT_NUMBER(S)

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

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

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

1.11.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.11.2 未使用のファイルシステムブロックの解放

 

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

SUSE Linux Enterprise Serverでサポートされるファイルシステム(Btrfsを除く)のTrimの方法としては、/sbin/wiper.shを実行することをお勧めします。このスクリプトを実行する前に、必ず/usr/share/doc/packages/hdparm/README.wiperを読んでください。ほとんどのデスクトップおよびサーバシステムでは、Trimは週1回実行すれば十分です。ファイルシステムを-o discardでマウントすることは、パフォーマンスの低下を伴い、SSDの寿命に悪影響を与えることがあるため、推奨しません。

警告
警告: Btrfsでwiper.shを使用しない

wiper.shスクリプトは、読み書き可能でマウントされたExt4またはXFSファイルシステム、読み込み専用でマウント/マウント解除されたExt2、Ext3、Ext4、またはXFSファイルシステムにTrim操作を実行します。データを破損する可能性があるため、Btrfsファイルシステムでwiper.shを使用しないでください。代わりに、btrfsmaintenanceパッケージの一部である、/usr/share/btrfsmaintenance/btrfs-trim.shを使用してください。

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

 

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

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

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

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

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

    /etc/cron.weekly/btrfs-balanceスクリプトは週ベースで未使用のブロックグループのクリーンアップを実行します。

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

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

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

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

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

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

 

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

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

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

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

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

1.12 詳細情報

 

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

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