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

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

 

SUSE Linux Enterprise Serverのルートパーティションは、デフォルトでBtrfsとスナップショットを使用して設定されます。スナップショットを使用すると、更新適用後に必要に応じてシステムを容易にロールバックしたり、ファイルをバックアップしたりできます。スナップショットは、Book “管理ガイド”, Chapter 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マウントオプションを使用し、圧縮アルゴリズムをzstd、lzo、または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.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. btrfsの編集ウィンドウで、サブボリュームのクォータの有効化チェックボックスをオンにして、次へで確定します。

   

   図 1.1: Btrfsクオータの有効化 #

    

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

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

   

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

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

ただし、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. 更新したデバイスにバックアップからデータを復元します。

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

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

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

2006年に、Ext4はExt3の後継として登場しました。これは、拡張ファイルシステムバージョンの最新ファイルシステムです。Ext4はもともと、最大1エクスビバイトのサイズのボリューム、最大16テビバイトのサイズのファイル、および無制限の数のサブディレクトリをサポートすることによって、ストレージサイズを増やすように設計されました。Ext4は、従来の直接および間接ブロックポインタの代わりにエクステントを使用して、ファイルコンテンツをマッピングします。エクステントを使用することにより、ディスクからのデータの保存と取得の両方が向上しています。

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

注記: Ext4でのExt3の機能

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

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をクリックします。

  

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パーティションにセットアップされたルートファイルシステムをブートするには、ext4とjbdの各モジュールをinitramfsに追加します。/etc/dracut.conf.d/filesystem.confを開くか作成し、次の行を追加します。

   force_drivers+=" ext4 jbd"

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

   dracut -f

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

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

OpenZFSファイルシステムもZFSファイルシステムもSUSEではサポートされていません。ZFSはもともとオープンソースライセンス下でSunによってリリースされていましたが、現在のOracle Solaris ZFSはクローズドソースであるため、SUSEでは使用できません。OpenZFS (元のZFSに基づく)はGPLライセンスとの互換性がないCDDLライセンス下にあるため、カーネルに含めることができません。ただし、Btrfsには同様の設計哲学を持つOpenZFSの優れた代替品があり、SUSEによって完全にサポートされています。

tmpfsは、RAMベースの仮想メモリファイルシステムです。ファイルシステムは一時的なものです。つまり、ファイルはハードディスクに保存されず、ファイルシステムがアンマウントされると、すべてのデータが破棄されます。

このファイルシステムのデータはカーネル内部キャッシュに保存されます。必要なカーネルキャッシュスペースは拡大または縮小できます。

ファイルシステムの特徴は次のとおりです。

詳細については、以下を参照してください。

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

セキュリティ上の理由によって、自動マウントからブロックされるファイルシステムがあります。これらのファイルシステムは通常、これ以上保持されず、一般的には使用されません。ただし、このファイルシステムのカーネルモジュールをロードできます。これは、カーネル内の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パッケージが更新されると、これらのファイルは必ず上書きされるため、編集しないでください。ブロックされるファイルシステムの自動マウントを許可するには、次の方法があります。

ファイルシステムを自動マウントできない場合でも、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に呼び出します。したがって、このファイルシステムはブロックリストから削除されます。

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

現在、弊社のすべての標準ファイルシステムでは、LFS (大規模ファイルサポート)を提供しています。LFSは、理論的には、2⁶³バイトの最大ファイルサイズをサポートします。表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ブロックサイズ)」は、ディスクフォーマット時の制限について説明しています。Linuxカーネルは、操作するファイルとファイルシステムのサイズについて、独自の制限を課しています。管理の初期設定には、次のオプションがあります。

ファイルサイズ

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

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

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

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

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列の値が0以外の場合、デバイスはTRIM操作をサポートします。

> sudo systemctl enable fstrim.timer

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

1.14.2 オンラインTRIM #

 

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

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

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

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

> sudo tune2fs -o discard DEVICE

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

> sudo mount -o discard DEVICE

注記: オンラインTRIMの欠点

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

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

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

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

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

パーティションまたは論理ボリュームのサイズ変更には、YaSTパーティショナを使用することをお勧めします。その際、ファイルシステムは自動的にパーティションまたはボリュームの新しいサイズに合わせて調整されます。ただし、YaSTではファイルシステムのサイズ変更はサポートされていないので、次のようなケースでは手動でサイズを変更する必要があります。

ファイルシステムのサイズ変更には、データを失う可能性をはらむリスクが伴います。

警告: データのバックアップ

データの喪失を避けるには、データを必ずバックアップしてから、サイズ変更タスクを開始します。

ファイルシステムのサイズを変更する場合は、次のガイドラインに従ってください。

2.2.3 ファイルシステムのサイズの削減 #

 

デバイス上のファイルシステムのサイズを削減する際には、新しいサイズが次の条件を満たすかどうかを必ず確認してください。

• 新しいサイズは、既存データのサイズより大きくなければなりません。さもないと、データが失われます。

• ファイルシステムのサイズは使用可能な容量より大きくできないので、新しいサイズは、現在のデバイスサイズ以下でなければなりません。

ファイルシステムが保存されている論理ボリュームのサイズを削減する場合は、デバイス、または論理ボリュームのサイズを削減しようとする前に、必ずファイルシステムのサイズを削減しておきます。

重要: XFS

XFSでフォーマットされたファイルシステムのサイズを縮小することはできません。XFSではそのような機能がサポートされていないためです。

Btrfsファイルシステムのサイズは、ファイルシステムがマウントされているときに、btrfs filesystem resizeコマンドを使用して変更できます。ファイルシステムのマウント中にサイズの増加と縮小の両方を実行できます。

XFSファイルシステムのサイズは、ファイルシステムがマウントされているときに、xfs_growfsコマンドを使用して増加できます。XFSファイルシステムのサイズを縮小することはできません。

Ext2、Ext3、およびExt4ファイルシステムのサイズは、各パーティションがマウントされているかどうかにかかわらず、resize2fsコマンドを使用して増加できます。Extファイルシステムのサイズを減らすには、ファイルシステムをアンマウントする必要があります。

UUID (Universally Unique Identifier)は、ファイルシステムの128ビットの番号であり、ローカルシステムと他のシステム全体に渡る固有な識別子です。UUIDは、システムハードウェア情報とタイムスタンプをそのシードの一部として、ランダムに生成されます。UUIDは、通常、デバイスに固有なタグを付けるために使用されます。

非永続的な「従来の」デバイス名(/dev/sda1など)を使用すると、ストレージを追加したときに、システムがブートできなくなる可能性があります。たとえば、root (/)が/dev/sda1に割り当てられている場合、SANを接続した後またはシステムにハードディスクを追加した後に、/dev/sdg1に再割り当てされる可能性があります。この場合、ブートローダ設定と/etc/fstabファイルを調整する必要があり、そうしないとシステムは起動できなくなります。

デフォルトで、UUIDはブートローダと、ブートデバイスの/etc/fstabファイルで使用されます。UUIDは、ファイルシステムのプロパティであり、ドライブを再フォーマットすれば変更できます。デバイス名のUUIDを使用することの代替案として、IDまたはラベルでデバイスを識別する方法があります。

UUIDは、ソフトウェアRAIDデバイスのアセンブルと起動の基準としても使用できます。RAIDが作成されると、mdドライバは、デバイスのUUIDを生成し、その値をmdスーパーブロックに保存します。

どのブロックデバイスのUUIDも、/dev/disk/by-uuidディレクトリ内で見つけることができます。たとえば、UUIDエントリは次のようになります。

> ls -og /dev/disk/by-uuid/
lrwxrwxrwx 1 10 Dec  5 07:48 e014e482-1c2d-4d09-84ec-61b3aefde77a -> ../../sda1

Linuxカーネル2.6以降、udevによって、永続的なデバイス名を使用した動的な/devディレクトリのユーザスペースソリューションが提供されます。システムに対してデバイスを追加または削除する場合は、ホットプラグシステムの一部としてudevが実行されます。

ルールのリストが特定デバイス属性との比較に使用されます。udevルールのインフラストラクチャ(/etc/udev/rules.dディレクトリで定義)は、すべてのディスクデバイスに、それらの認識順序や当該デバイスに使用される接続に関わらず、安定した名前を提供します。udevツールは、カーネルが作成するすべての該当ブロックデバイスを調べ、一定のバス、ドライブタイプ、またはファイルシステムに基づいて、ネーミングルールを適用します。udev用の独自ルールを定義する方法については、「Writing udev Rules」を参照してください。

動的なカーネル提供のデバイスノード名に加えて、udevは、/dev/diskディレクトリ内のデバイスをポイントする永続的なシンボリックリンクのクラスを保持します。このディレクトリは、さらに、by-id、by-label、by-path、およびby-uuidの各サブディレクトリに分類されます。

注記: UUIDジェネレータ

udev以外のプログラム(LVMやmdなど)も、UUIDを生成することがありますが、それらのUUIDは/dev/diskにリストされません。

udevによるデバイス管理の詳細については、Book “管理ガイド”, Chapter 29 “udevによる動的カーネルデバイス管理”を参照してください。

udevコマンドの詳細については、man 7 udevを参照してください。

ストレージデバイスの種類によっては、systemd.mountがデバイスのマウントを開始する前にネットワークが設定され、利用可能になっている必要があります。これらのタイプのデバイスのマウントを延期するには、該当するそれぞれのネットワークストレージデバイスの/etc/fstabファイルに_netdevオプションを追加します。次に例を示します。

mars.example.org:/nfsexport  /shared   nfs  defaults,_netdev    0  0

本項では、キャッシュ関連機能の説明でよく使用されるいくつかの用語について説明します。

多層キャッシュで使用される基本的なキャッシングモードは、「ライトバック」、「ライトスルー」、「ライトアラウンド」、および「パススルー」です。

bcacheはLinuxカーネルブロック層のキャッシュです。1台以上の高速なディスクドライブ(SSDなど)を1台以上の低速なハードディスクのキャッシュとして動作させることができます。bcacheは、ライトスルーとライトバックをサポートし、使用するファイルシステムから独立しています。デフォルトでは、SSDの強みである、ランダム読み込みとランダム書き込みのみのキャッシュを実行します。デスクトップやサーバのほか、ハイエンドのストレージアレイにも適しています。

lvmcacheは、論理ボリューム(LV)で構成されるキャッシングメカニズムです。dm-cacheカーネルドライバを使用し、ライトスルー(デフォルト)およびライトバックのキャッシングモードをサポートします。lvmcacheは、データの一部をより高速で小容量のLVに動的に移行することによって、大容量で低速なLVのパフォーマンスを向上させます。LVMの詳細については、パートII「論理ボリューム(LVM)」を参照してください。

LVMでは、この小容量で高速なLVを「キャッシュプールLV」と呼びます。一方、大容量で低速なLVを「起点LV」と呼びます。dm-cacheの要件があるため、LVMは、キャッシュプールLVをさらに「キャッシュデータLV」と「キャッシュメタデータLV」という2つのデバイスに分割します。キャッシュデータLVは、速度の向上を目的として、起点LVからのデータブロックのコピーが保持される場所です。キャッシュメタデータLVには、データブロックが保存されている場所を指定するアカウンティング情報が格納されます。

> sudo lvconvert --splitcache vg/origin_lv

> sudo lvremove vg/cache_data_lv

> sudo lvconvert --uncache vg/origin_lv

> sudo lvremove vg/origin_lv

LVMは、複数の物理ボリューム(ハードディスク、パーティション、LUN)にハードディスクスペースを柔軟に分散することができます。LVMが開発された理由は、インストール中に初期パーティショニングが終了した後でのみ、ハードディスクスペースのセグメンテーションを変更するニーズが発生する可能性があるためです。実行中のシステムでパーティションを変更することは困難なので、LVMは必要に応じて論理ボリューム(LV)を作成できるストレージスペースの仮想プール(ボリュームグループ(VG))を提供します。オペレーティングシステムは物理パーティションの代わりにこれらのLVにアクセスします。ボリュームグループは2つ以上のディスクにまたがることができます。したがって、複数のディスクまたはそれらの一部で1つのVGを構成できます。この方法で、LVMは物理ディスクスペースから一種の抽象化を行います。この抽象化により、物理パーティショニングを使用する場合よりはるかに簡単で安全な方法でセグメンテーションを変更できます。

図5.1「物理パーティショニング対LVM」では物理パーティショニング(左)とLVM区分(右)を比較しています。左側は、1つのディスクが割り当てられたマウントポイント(MP)をもつ3つの物理パーティション(PART)に分かれています。これによりオペレーティングシステムはそれぞれのパーティションにアクセスできます。右側では2つのディスクがそれぞれ3つの物理パーティションに分かれています。2つのLVMボリュームグループ(VG 1およびVG 2)が定義されています。VG 1にはDISK 1からのパーティションが2つ、DISK 2からのパーティションが1つ含まれています。VG 2には、ディスク2の残りの2つのパーティションが含まれています。

図 5.1: 物理パーティショニング対LVM #

 

LVMでは、ボリュームグループに組み込まれた物理ディスクをPV (物理ボリューム)と呼びます。図5.1「物理パーティショニング対LVM」のボリュームグループ内には、4つの論理ボリューム(LV 1からLV 4)が定義されています。これらのボリュームは、関連付けられたマウントポイント(MP)を介してオペレーティングシステムに使用されます。別の論理ボリュームとの境界とパーティションの境界を並べることはできません。この例ではLV 1およびLV 2の間に境界があります。

LVMの機能:

注記: LVMとRAID

LVMではRAIDレベル0、1、4、5、6もサポートしていますが、mdraidを使用することをお勧めします(第7章 「ソフトウェアRAIDの設定」を参照)。ただし、LVMはRAID 0および1では適切に動作します。これは、RAID 0は一般的な論理ボリューム管理と同様である(個々の論理ブロックが物理デバイス上のブロックにマップされる)ためです。RAID 1上でLVMを使用した場合は、ミラーの同期を追跡して同期プロセスを完全に管理することができます。それより高いRAIDレベルでは、接続されたディスクの状態を監視するほか、ディスクアレイで問題が発生した場合に管理者に通知することのできる、管理デーモンが必要になります。LVMにはこのようなデーモンが組み込まれていますが、デバイス障害などの例外的な状況では、このデーモンは正しく機能しません。

警告: IBM Z: LVMルートファイルシステム

LVMまたはソフトウェアRAIDアレイでルートファイルシステムを使用してシステムを設定する場合、/bootを別個の非LVMまたは非RAIDパーティションに配置する必要があります。そうしないと、システムは起動しません。このパーティションの推奨サイズは500MBで、推奨ファイルシステムはExt4です。

これらの機能とともにLVMを使用することは、頻繁に使用されるホームPCや小規模サーバではそれだけでも意義があります。データベース、音楽アーカイブ、またはユーザディレクトリのように増え続けるデータストックがある場合は、LVMが特に役に立ちます。LVMを使用すると、物理ハードディスクより大きなファイルシステムの作成が可能になります。ただし、LVMでの作業は従来のパーティションでの作業とは異なることに留意してください。

YaSTパーティショナの使用によって、新規および既存のLVMストレージオブジェクトを管理できます。LVMの設定に関する指示や詳細情報については、公式のLVM HOWTOを参照してください。

LVMボリュームグループ(VG)は、Linux LVMパーティションをスペースの論理プールにします。グループ内の使用可能なスペースから論理ボリュームを作成できます。グループ内のLinux LVMパーティションは、同じディスクに存在することも、さまざまなディスクに存在することも可能です。パーティションまたはディスク全体を追加することにより、グループのサイズを拡張できます。

ディスク全体を使用する場合、そのディスクにパーティションを含めることはできません。パーティションを使用した場合、それらをマウントしないでください。YaSTは、パーティションをVGに追加する際に自動的にパーティションタイプを0x8E Linux LVMに変更します。

論理ボリュームは、ハードディスクと同様に領域のプールを提供します。この領域を使用可能にするには、論理ボリュームを定義する必要があります。論理ボリュームは通常のパーティションに似ており、フォーマットやマウントが可能です。

YaSTパーティショナを使用して、既存のボリュームグループから論理ボリュームを作成します。各ボリュームグループに少なくとも1つの論理ボリュームを割り当ててください。ボリュームグループ内の空き領域を使い果たすまで、必要に応じて新しい論理ボリュームを作成できます。LVM論理ボリュームをオプションでシンプロビジョニングすることによって、使用可能な空き領域を超えるサイズで論理ボリュームを作成することもできます(詳しくは5.3.1項 「シンプロビジョニング論理ボリューム」を参照)。

5.3.1 シンプロビジョニング論理ボリューム #

 

LVM論理ボリュームはシンプロビジョニング可能です(オプション)。シンプロビジョニングを使用すると、利用可能な空き領域を超えるサイズの論理ボリュームを作成できます。任意の数のシンボリューム用に予約した未使用領域が含まれるシンプールを作成します。シンボリュームは疎ボリュームとして作成され、必要に応じてシンプールから領域が割り当てられます。ストレージ領域をコスト効果の高い方法で割り当てなければならなくなった場合、シンプールを動的に拡張できます。シンプロビジョニングボリュームは、Snapperで管理可能なスナップショットもサポートします。詳細については、Book “管理ガイド”, Chapter 10 “Snapperを使用したシステムの回復とスナップショット管理”を参照してください。

シンプロビジョニング論理ボリュームを設定するには、手順5.1「論理ボリュームの設定」の説明に従って作業を進めます。ボリュームタイプを選択する手順になったら、通常ボリュームを選択せずに、シンボリュームまたはシンプールを選択します。

シンプール

この論理ボリュームは、シンボリューム用に予約された領域のプールです。シンボリュームでは、必要な領域をそのプールからオンデマンドで割り当てることができます。

シンボリューム

ボリュームは疎ボリュームとして作成されます。このボリュームでは、必要な領域はシンプールからオンデマンドで割り当てられます。

重要: クラスタにおけるシンプロビジョニングボリューム

クラスタでシンプロビジョニングボリュームを使用するには、クラスタを使用するシンプールとシンボリュームを1つのクラスタリソースで管理する必要があります。これにより、シンボリュームとシンプールを常に同じノードに排他的にマウントできます。

> sudo lvcreate -L 500G -m 2 -n lv1 vg1

> sudo lvcreate --type raid1 -m 1 -L 1G -n lv1 vg1

非ルートLVMボリュームグループのアクティブ化の動作は、/etc/lvm/lvm.confファイルとauto_activation_volume_listパラメータで制御されます。デフォルトでは、このパラメータは空で、すべてのボリュームがアクティブ化されます。一部のボリュームグループのみをアクティブ化するには、その名前を引用符で囲んで追加し、カンマで区切ります。次に例を示します。

auto_activation_volume_list = [ "vg1", "vg2/lvol1", "@tag1", "@*" ]

リストをauto_activation_volume_listパラメータで定義した場合、次のように処理されます。

デフォルトでは、非ルートLVMボリュームグループは、システムの再起動時にdracutによって自動的にアクティブ化されます。このパラメータにより、システムの再起動時にすべてのボリュームグループをアクティブにすることも、または指定した非ルートLVMボリュームグループのみをアクティブにすることもできます。

ボリュームグループによって提供される領域は、物理ボリュームを追加することによっていつでも拡張できます。これは、システムの稼働中であっても、サービスを中断することなく実行できます。これにより、グループに論理ボリュームを追加したり、既存のボリュームのサイズを拡張したりできます。5.6項 「論理ボリュームのサイズ変更」を参照してください。

また、物理ボリュームを削除してボリュームグループのサイズを縮小することもできます。YaSTで削除できる物理ボリュームは、現在未使用の物理ボリュームだけです。現在使用中の物理ボリュームを確認するには、次のコマンドを実行します。PE Ranges列に表示されているパーティション(物理ボリューム)が使用中のものです。

> sudo pvs -o vg_name,lv_name,pv_name,seg_pe_ranges
root's password:
  VG   LV    PV         PE Ranges
             /dev/sda1
  DATA DEVEL /dev/sda5  /dev/sda5:0-3839
  DATA       /dev/sda5
  DATA LOCAL /dev/sda6  /dev/sda6:0-2559
  DATA       /dev/sda7
  DATA       /dev/sdb1
  DATA       /dev/sdc1

ボリュームグループ内に利用可能な未使用の空き領域がある場合、論理ボリュームを拡張して使用可能な領域を増やすことができます。また、ボリュームのサイズを縮小してボリュームグループの領域を解放し、他の論理ボリュームで使用できるようにすることもできます。

注記: 「オンライン」でのサイズ変更

ボリュームのサイズを縮小すると、そのファイルシステムのサイズもYaSTによって自動的に縮小されます。現在マウントされているボリュームのサイズを「オンライン」で(つまりマウント中に)変更できるかどうかは、ファイルシステムによって異なります。オンライン拡張をサポートするファイルシステムは、Btrfs、XFS、Ext3、およびExt4です。

オンライン縮小をサポートするファイルシステムは、Btrfsのみです。Ext2/3/4ファイルシステムを縮小するには、アンマウントする必要があります。XFSはファイルシステムの縮小をサポートしないため、XFSでフォーマットされたボリュームは縮小できません。

LVMストレージでエラーが発生した場合、LVMボリュームをスキャンすると、緊急/レスキューシェルが起動しなくなる場合があります。その結果、問題を詳細に診断できなくなります。LVMストレージで障害が発生した場合にこのスキャンを無効にするために、カーネルコマンドラインのnolvmオプションを渡すことができます。

LVMコマンドの使用の詳細については、次の表で説明されている各コマンドのmanページを参照してください。すべてのコマンドはroot特権で実行する必要があります。sudo COMMANDを使用するか(推奨)、直接rootとして実行します。

ヒント: ボリューム作成時のudevのバイパス

udevルールではなくLVMを使用してLVデバイスノードとシンボリックリンクを管理する場合は、次のいずれかの方法でudevからの通知を無効にすることによって可能になります。

• /etc/lvm/lvm.confで、activation/udev_rules = 0とactivation/udev_sync = 0を設定する。

  lvcreateコマンドで--nodevsyncを指定しても、activation/udev_sync = 0と同じ結果になります。この場合も、activation/udev_rules = 0の設定が必要です。

• 環境変数DM_DISABLE_UDEVを設定する。

  export DM_DISABLE_UDEV=1

  この方法でも、udevからの通知が無効になります。さらに、/etc/lvm/lvm.confのudev関連の設定はすべて無視されます。

5.9.1 コマンドによる論理ボリュームのサイズ変更 #

 

lvresize、lvextend、およびlvreduceコマンドが論理ボリュームのサイズ変更に使用されます。構文とオプションについては、これらの各コマンドのマニュアルページを参照してください。LVを拡大するには、VG上に十分な未使用スペースがなければなりません。

論理ボリュームを拡大または縮小する場合、YaSTパーティショナを使用することをお勧めします。YaSTを使用すると、そのボリュームのファイルシステムのサイズも自動的に調整されます。

LVは使用中に手動で拡大または縮小できますが、LV上のファイルシステムについてはこれが不可能な場合があります。LVを拡大、縮小しても、そのボリューム内のファイルシステムのサイズは自動的に変更されません。後でファイルシステムを拡大するには、別のコマンドを使用する必要があります。ファイルシステムのサイズ変更の詳細については、第2章 「ファイルシステムのサイズ変更」を参照してください。

手動でLVのサイズを変更する場合は、次に示すように正しい順序に従ってください。

• LVを拡大する場合は、ファイルシステムを拡大する前にLVを拡大する必要があります。

• LVを縮小する場合は、LVを縮小する前にファイルシステムを縮小する必要があります。

論理ボリュームのサイズを拡張するには:

1. 端末を開きます。

2. 論理ボリュームにExt2またはExt4ファイルシステム(オンライン拡張がサポートされていません)が含まれる場合、マウント解除します。仮想マシン(Xen VMなど)用に提供されているファイルシステムが含まれている場合は、最初にVMをシャットダウンします。

3. 端末のプロンプトに対して、次のコマンドを入力し、論理ボリュームのサイズを拡大します。

   > sudo lvextend -L +SIZE /dev/VG_NAME/LV_NAME

   SIZEの場合は、10GBのように、論理ボリュームに追加したい容量を指定してください。/dev/VG_NAME/LV_NAMEを、/dev/LOCAL/DATAなどの論理ボリュームへのLinuxパスに入れ替えます。例:

   > sudo lvextend -L +10GB /dev/vg1/v1

4. ファイルシステムのサイズを調整します。詳細については第2章 「ファイルシステムのサイズ変更」を参照してください。

5. ファイルシステムをマウント解除した場合は、再びマウントします。

たとえば、LVをLV上の(マウント済みでアクティブな) Btrfsで10GB拡張するには:

> sudo lvextend −L +10G /dev/LOCAL/DATA
> sudo btrfs filesystem resize +10G /dev/LOCAL/DATA

論理ボリュームのサイズを縮小するには:

1. 端末を開きます。

2. 論理ボリュームにBtrfsファイルが含まれていない場合は、論理ボリュームをマウント解除します。仮想マシン(Xen VMなど)用に提供されているファイルシステムが含まれている場合は、最初にVMをシャットダウンします。XFSファイルシステムを使用しているボリュームのサイズは縮小できません。

3. ファイルシステムのサイズを調整します。詳細については第2章 「ファイルシステムのサイズ変更」を参照してください。

4. 端末のプロンプトに対して、次のコマンドを入力し、論理ボリュームのサイズをファイルシステムのサイズまで縮小します。

   > sudo lvreduce /dev/VG_NAME/LV_NAME

5. ファイルシステムをアンマウントしてあった場合は、再びマウントします。

たとえば、LVをLV上のBtrfsで5GB縮小するには:

> sudo btrfs filesystem resize -size 5G /dev/LOCAL/DATA
sudo lvreduce /dev/LOCAL/DATA

ヒント: 1つのコマンドでのボリュームとファイルシステムのサイズ変更

SUSE Linux Enterprise Server 12 SP1から、lvextend、lvresize、およびlvreduceで--resizefsオプションがサポートされるようになりました。このオプションは、ボリュームのサイズを変更するだけでなく、ファイルシステムのサイズも変更します。したがって、上に示すlvextendおよびlvreduceの例は、次のように実行することもできます。

> sudo lvextend --resizefs −L +10G /dev/LOCAL/DATA
> sudo lvreduce  --resizefs -L -5G /dev/LOCAL/DATA

--resizefsは、ext2/3/4、Btrfs、およびXFSの各ファイルシステムでサポートされます。このオプションを使用したBtrfsのサイズ変更は、まだ上流では許可されていないため、SUSE Linux Enterprise Serverでのみ可能です。

タグは、ストレージオブジェクトのメタデータに割り当てられる順序付けのないキーワードまたは用語です。タグを使用すると、順序付けのないタグのリストをLVMストレージオブジェクトのメタデータに添付することによって、それらのオブジェクトのコレクションを有用になるように分類できます。

tags {
   # Enable hostname tags
   hosttags = 1
}

tags {

   tag1 { }
      # Tag does not require a match to be set.

   tag2 {
      # If no exact match, tag is not set.
      host_list = [ "hostname1", "hostname2" ]
   }
}

  activation {
      volume_list = [ "vg1/lvol0", "@database" ]
  }

ファイルシステムのスナップショットには、それ自体のメタデータと、スナップショットの作成後に変更されたソース論理ボリュームのデータブロックが含まれています。スナップショットを介してデータにアクセスすると、ソース論理ボリュームのその時点のコピーが表示されます。バックアップ媒体からデータを復元したり、変更されたデータを上書きする必要はありません。

重要: スナップショットによるボリュームのマウント

スナップショットのライフタイム中は、スナップショットを先にマウントしないと、ソース論理ボリュームをマウントできません。

LVMボリュームスナップショットでは、ファイルシステムのその時点のビューからバックアップを作成できます。スナップショットは瞬時に作成され、削除するまで保存されます。ボリューム自体はユーザが引き続き利用できるようにしながら、スナップショットからファイルシステムのバックアップを作成できます。当初のスナップショットには、スナップショットに関するメタデータが含まれていますが、ソース論理ボリュームの実際のデータは含まれていません。スナップショットはコピーオンライト技術を使用して、オリジナルデータブロックのデータ変更を検出します。スナップショットをとった際に保存されていた値をスナップショットボリューム内のブロックにコピーし、ソースブロックに新しいデータを保存することができます。ソース論理ボリュームで元の値から変更されるブロックが増えると、スナップショットのサイズが増えます。

スナップショットのサイズを決定する際には、ソース論理ボリュームに対して予想されるデータ変更量、およびスナップショットの保存期間を考慮する必要があります。スナップショットボリュームに割り当てるスペースの量は、ソース論理ボリュームのサイズ、スナップショットの保持予定期間、およびスナップショットのライフタイム中に変更が予期されるデータブロックの数によって異なります。スナップショットボリュームは、作成後のサイズ変更はできません。目安として、元の論理ボリュームの約10%のサイズで、スナップショットボリュームを作成してください。スナップショットの削除前に、ソース論理ボリューム内のすべてのブロックが1回以上変更されると予期される場合は、スナップボリュームのサイズを、少なくともソース論理ボリュームサイズにそのボリュームに関するメタデータ用スペースを加えたサイズにする必要があります。データ変更が頻繁でないか、またはライフタイムが十分短いと予期される場合、必要なスペースは少なくなります。

LVM2では、スナップショットはデフォルトで読み書き可能です。データをスナップショットに直接書き込む際は、そのブロックは例外テーブルで使用中とマークされ、ソース論理ボリュームからのコピーは行われません。スナップショットボリュームをマウントし、そのスナップショットボリュームにデータを直接書き込むことによって、アプリケーションの変更をテストできます。スナップショットをマウント解除してスナップショットを削除し、ソース論理ボリュームを再マウントするだけで、変更を簡単に破棄できます。

仮想ゲスト環境では、物理サーバの場合と同様に、サーバのディスク上に作成するLVM論理ボリュームに対してスナップショット機能を使用できます。

仮想ホスト環境では、スナップショット機能を使用して、仮想マシンのストレージバックエンドをバックアップしたり、仮想マシンイメージに対する変更(パッチやアップグレードなど)を、ソース論理ボリュームを変更せずにテストしたりできます。仮想マシンは、仮想ディスクファイルの使用ではなく、ストレージバックエンドとして、LVM論理ボリュームを使用する必要があります。LVM論理ボリュームをマウントし、ファイルに格納されたディスクとして仮想マシンイメージを保存するために使用できます。また、そのLVM論理ボリュームを物理ディスクとして割り当てて、ブロックデバイスとして書き込むことができます。

LVM論理ボリュームスナップショットは、シンプロビジョニングできます。サイズを指定しないでスナップショットを作成した場合は、シンプロビジョニングと想定されます。スナップショットは、シンプールから必要な領域を使用するシンボリュームとして作成されます。シンスナップショットボリュームは、他のシンボリュームと同じ特性を持ちます。ボリュームは個別にアクティブ化、拡張、名前変更、および削除でき、そのスナップショットを作成することもできます。

重要: クラスタにおけるシンプロビジョニングボリューム

クラスタでシンプロビジョニングスナップショットを使用するには、ソース論理ボリュームとそのスナップショットを1つのクラスタリソースで管理する必要があります。これにより、ボリュームとそのスナップショットを常に同じノードに排他的にマウントできます。

スナップショットが不要になったら、必ず、システムからスナップショットを削除してください。ソース論理ボリュームでデータブロックが変化していくのに応じて、スナップショットは最終的に満杯になります。スナップショットは満杯になると使用不可になるので、ソース論理ボリュームの再マウントができなくなります。

ソース論理ボリュームのスナップショットを複数作成している場合、スナップショットの削除は、最後に作成したものを最初に削除するという順番で行います。

LVM (Logical Volume Manager)は、ファイルシステムのスナップショットの作成に使用できます。

端末を開いて、次のコマンドを入力します。

> sudo lvcreate -s [-L <size>] -n SNAP_VOLUME SOURCE_VOLUME_PATH

サイズを指定しない場合、スナップショットはシンスナップショットとして作成されます。

例:

> sudo lvcreate -s -L 1G -n linux01-snap /dev/lvm/linux01

スナップショットが/dev/lvm/linux01-snapボリュームとして作成されます。

端末を開いて、次のコマンドを入力します。

> sudo lvdisplay SNAP_VOLUME

例:

> sudo lvdisplay /dev/vg01/linux01-snap

--- Logical volume ---
  LV Name                /dev/lvm/linux01
  VG Name                vg01
  LV UUID                QHVJYh-PR3s-A4SG-s4Aa-MyWN-Ra7a-HL47KL
  LV Write Access        read/write
  LV snapshot status     active destination for /dev/lvm/linux01
  LV Status              available
  # open                 0
  LV Size                80.00 GB
  Current LE             1024
  COW-table size         8.00 GB
  COW-table LE           512
  Allocated to snapshot  30%
  Snapshot chunk size    8.00 KB
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           254:5

端末を開いて、次のコマンドを入力します。

> sudo lvremove SNAP_VOLUME_PATH

例:

> sudo lvremove /dev/lvmvg/linux01-snap

仮想マシンのバックエンドストレージにLVM論理ボリュームを使用すると、基礎となるデバイスを柔軟に管理でき、ストレージオブジェクトの移動、スナップショットの作成、データのバックアップなどの操作を容易に行うことができるようになります。LVM論理ボリュームをマウントし、ファイルに格納されたディスクとして仮想マシンイメージを保存するために使用できます。また、そのLVM論理ボリュームを物理ディスクとして割り当てて、ブロックデバイスとして書き込むことができます。LVM論理ボリューム上に仮想ディスクイメージを作成してから、LVMのスナップショットを作成できます。

スナップショットの読み込み/書き込み機能を利用して、1つの仮想マシンのインスタンスを複数作成できます。この場合、変更は、仮想マシンの特定のインスタンスのスナップショットに対して行われます。LVM論理ボリューム上に仮想ディスクイメージを作成してソース論理ボリュームのスナップショットを作成し、仮想マシンの特定のインスタンスのスナップショットを変更できます。ソース論理ボリュームのスナップショットをもう1つ作成して、仮想マシンの別のインスタンス用に変更できます。複数の仮想マシンインスタンスのデータの大部分は、ソース論理ボリューム上のイメージと共に存在します。

スナップショットの読み込み/書き込み機能を利用すると、仮想ディスクイメージを維持したまま、ゲスト環境でパッチやアップグレードをテストすることもできます。そのイメージが含まれるLVMボリュームのスナップショットを作成し、そのスナップショットの場所で仮想マシンを実行します。ソース論理ボリュームは変更されず、そのマシンに対する変更はすべてスナップショットに書き込まれます。仮想マシンイメージのソース論理ボリュームに戻るには、仮想マシンの電源をオフにした後、ソース論理ボリュームからスナップショットを削除します。もう一度やり直すには、スナップショットを再作成してマウントしてから、スナップショットイメージ上で仮想マシンを再起動します。

次の手順では、ファイルに格納された仮想ディスクイメージとXenハイパーバイザを使用します。本項の手順は、KVMなど、SUSE Linux Enterpriseプラットフォーム上で動作する他のハイパーバイザに適用できます。スナップショットボリュームからファイルに格納された仮想マシンイメージを実行するには:

スナップショットは、ボリューム上のデータを前の状態にロールバックまたは復元する必要がある場合に役立ちます。たとえば、管理者の手違いがあった場合、またはパッケージのインストールやアップグレードが失敗したり望む内容と違ったりした場合、データ変更を元に戻さなければならないことがあります。

lvconvert --mergeコマンドを使用して、LVM論理ボリュームの変更を元に戻すことができます。マージは次のように開始されます。

マージが開始されると、サーバ再起動後もマージは自動的に続行され、これはマージが完了するまで続きます。マージの進行中は、マージ中のソース論理ボリュームの新しいスナップショットを作成することはできません。

マージの進行中は、ソース論理ボリュームに対する読み込みまたは書き込みは、マージ中のスナップショットに透過的にリダイレクトされます。これにより、ユーザは直接、スナップショット作成時のデータを表示したり、そのデータにアクセスしたりできます。マージが完了するまで待つ必要はありません。

マージが完了すると、ソース論理ボリュームにはスナップショット作成時と同じデータと、マージ開始後に行われたデータ変更がすべて含まれます。生成された論理ボリュームの名前、マイナー番号、およびUUIDは、ソース論理ボリュームと同じです。ソース論理ボリュームは自動的に再マウントされ、スナップショットボリュームは削除されます。

本項では、通常のRAIDレベル(0、1、2、3、4、5)とネストしたRAIDレベルについて説明します。

YaSTソフトRAID設定には、YaST Expert Partitionerからアクセスできます。このパーティション設定ツールを使用すると、既存のパーティションを編集および削除したり、ソフトウェアRAIDで使用する新規パーティションを作成したりすることもできます。これらの方法は、RAIDレベル0、1、5、および6の設定に適用されます。RAID 10の設定については、第9章 「ソフトウェアRAID 10デバイスの作成」で説明されています。

重要: ディスク上のRAID

パーティショナはパーティションの代わりにディスクの上にRAIDを作成することを可能にしますが、いくつかの理由のため、このアプローチは推奨されません。このようなRAIDにブートローダをインストールすることはサポートされていないため、ブート用に別のデバイスを使用する必要があります。fdiskやpartedなどのツールは当該RAIDでは適切に機能しないため、RAIDの特定のセットアップを知らない人によって誤った診断やアクションが行われる可能性があります。

デフォルトでは、ストライプサイズは4KBに設定されています。デフォルトのストライプサイズを変更する必要がある場合、たとえば、AArch64の一般的なページサイズの64KBに合わせるには、CLIを使用してストライプサイズを手動で設定できます。

> sudo echo 16384  > /sys/block/md1/md/stripe_size

上記のコマンドを実行すると、ストライプサイズは16KBに設定されます。4096、8192など他の値を設定できますが、値は2のべき乗である必要があります。

monitorモードでデーモンとしてmdadmを実行し、ソフトウェアRAIDを監視することができます。monitorモードでは、mdadmはアレイのディスク障害を定期的に確認します。障害が発生した場合、mdadmは管理者に電子メールを送信します。チェックの時間間隔を定義するには、次のコマンドを実行します。

mdadm --monitor --mail=root@localhost --delay=1800 /dev/md2

先に示したコマンドは1800秒間隔で/dev/md2アレイの監視をオンにします。障害が発生した場合、電子メールがroot@localhostに送信されます。

注記: デフォルトでは、RAIDチェックが有効化されています

デフォルトでは、RAIDチェックが有効化されています。各チェックの間隔が十分な長さではなく、警告が表示される場合があります。このように、delayオプションでより高い値を設定することにより、間隔を増やすことができます。

ソフトウェアRAIDの設定方法と詳細情報が、次のHOWTOにあります。

「linux-raid」(https://marc.info/?l=linux-raid)などのLinux RAIDメーリングリストもあります。

設定が次の要件を満たしていることを確認してください。

ネストしたRAIDデバイスは、物理ディスクを使用する代わりに、その基本エレメントとして別のRAIDアレイを使用するRAIDアレイで構成されます。この構成の目的は、RAIDのパフォーマンスと耐障害性を向上することです。ネストしたRAIDレベルの設定はYaSTではサポートされていませんが、mdadmコマンドラインツールを使用して実行できます。

ネストの順序に基づいて、2つの異なるネストしたRAIDを設定できます。このマニュアルでは、次の用語を使用します。

次の表では、RAID 10ネスティングの欠点と利点を、1+0対0+1という形式で説明します。使用するストレージオブジェクトは、それぞれが専用のI/Oをもつ別々のディスクに常駐すると想定しています。

9.1.1 mdadmによるネストしたRAID 10 (1+0)デバイスの作成 #

 

ネストしたRAID 1+0は、2つ以上のRAID 1(ミラー)デバイスを作成し、それらのRAID 1デバイスをRAID 0のコンポーネントデバイスとして使用することで構築します。

重要: マルチパス処理

デバイスに対する複数の接続を管理する必要がある場合は、マルチパスI/Oを設定してから、RAIDデバイスを設定する必要があります。詳細については、第18章 「デバイスのマルチパスI/Oの管理」を参照してください。

本項の手順では、次の表に示すデバイス名を使用します。それらのデバイス名は、必ず、ご使用のデバイスの名前で変更してください。

表 9.2: ネスティングでRAID 10 (1+0)を作成するシナリオ #

 

rawデバイス	RAID 1(ミラー)	RAID 1+0(ストライピングミラー)
/dev/sdb1 /dev/sdc1	/dev/md0	/dev/md2
/dev/sdd1 /dev/sde1	/dev/md1

1. 端末を開きます。

2. 必要に応じて、partedなどのディスクパーティショナを使用して、同じサイズの0xFD Linux RAIDパーティションを4つ作成します。

3. 1デバイスごとに2つの異なるデバイスを使用して、2つのソフトウェアRAID 1デバイスを作成します。コマンドプロンプトで、次の2つのコマンドを入力します。

   > sudo mdadm --create /dev/md0 --run --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1
   sudo mdadm --create /dev/md1 --run --level=1 --raid-devices=2 /dev/sdd1 /dev/sde1

4. ネストしたRAID 1+0デバイスを作成します。コマンドプロンプトで、前の手順で作成したソフトウェアRAID 1デバイスを使用して、次のコマンドを入力します。

   > sudo mdadm --create /dev/md2 --run --level=0 --chunk=64 \
   --raid-devices=2 /dev/md0 /dev/md1

   デフォルトのチャンクサイズは 64KBです。

5. RAID 1+0デバイス/dev/md2上でファイルシステム(XFSファイルシステムなど)を作成します。

   > sudo mkfs.xfs /dev/md2

   これとは別のファイルシステムを使用するには、コマンドを変更します。

6. /etc/mdadm.confファイルを編集するか、ファイルがまだ存在しない場合は作成します(たとえば、sudo vi /etc/mdadm.confを実行します)。次の行を追加します(ファイルが既に存在する場合、最初の行は記述済みの可能性があります)。

   DEVICE containers partitions
   ARRAY /dev/md0 UUID=UUID
   ARRAY /dev/md1 UUID=UUID
   ARRAY /dev/md2 UUID=UUID

   各デバイスのUUIDは次のコマンドで取得できます。

   > sudo mdadm -D /dev/DEVICE | grep UUID

7. /etc/fstabファイルを編集して、RAID 1+0デバイス /dev/md2のエントリを追加します。次の例は、XFSファイルシステム、およびマウントポイントとして/dataを使用するRAIDデバイスのエントリを示しています。

   /dev/md2 /data xfs defaults 1 2

8. RAIDデバイスをマウントします。

   > sudo mount /data

9.1.2 mdadmによるネストしたRAID 10 (0+1)デバイスの作成 #

 

ネストしたRAID 0+1は、2個から4個のRAID 0(ストライプ)デバイスで構築され、それらのRAID 0デバイスをミラーリングしてRAID 1のコンポーネントデバイスとします。

重要: マルチパス処理

デバイスに対する複数の接続を管理する必要がある場合は、マルチパスI/Oを設定してから、RAIDデバイスを設定する必要があります。詳細については、第18章 「デバイスのマルチパスI/Oの管理」を参照してください。

この構成では、RAID 0がデバイスの喪失に耐えられないので、ベースのRAID 0デバイスにスペアデバイスを指定できません。デバイスがミラーの1つのサイドでエラーになった場合は、置き換え用のRAID 0デバイスを作成して、ミラーに追加します。

本項の手順では、次の表に示すデバイス名を使用します。それらのデバイス名は、必ず、ご使用のデバイスの名前で変更してください。

表 9.3: ネスティングでRAID 10 (0+1)を作成するシナリオ #

 

rawデバイス	RAID 0 (ストライプ)	RAID 0+1 (ミラー化ストライピング)
/dev/sdb1 /dev/sdc1	/dev/md0	/dev/md2
/dev/sdd1 /dev/sde1	/dev/md1

1. 端末を開きます。

2. 必要に応じて、partedなどのディスクパーティショナを使用して、同じサイズの0xFD Linux RAIDパーティションを4つ作成します。

3. RAID 0デバイスごとに2つの異なるデバイスを使用して、2つのソフトウェアRAID 0デバイスを作成します。コマンドプロンプトで、次の2つのコマンドを入力します。

   > sudo mdadm --create /dev/md0 --run --level=0 --chunk=64 \
   --raid-devices=2 /dev/sdb1 /dev/sdc1
   sudo mdadm --create /dev/md1 --run --level=0 --chunk=64 \
   --raid-devices=2 /dev/sdd1 /dev/sde1

   デフォルトのチャンクサイズは 64KBです。

4. ネストしたRAID 0+1デバイスの作成コマンドプロンプトで、前の手順で作成したソフトウェアRAID 0デバイスを使用して、次のコマンドを入力します。

   > sudo mdadm --create /dev/md2 --run --level=1 --raid-devices=2 /dev/md0 /dev/md1

5. RAID 1+0デバイス/dev/md2上でファイルシステム(XFSファイルシステムなど)を作成します。

   > sudo mkfs.xfs /dev/md2

   これとは別のファイルシステムを使用するには、コマンドを変更します。

6. /etc/mdadm.confファイルを編集するか、ファイルがまだ存在しない場合は作成します(たとえば、sudo vi /etc/mdadm.confを実行します)。次の行を追加します(ここでも、ファイルが既に存在する場合、最初の行は記述済みの可能性があります)。

   DEVICE containers partitions
   ARRAY /dev/md0 UUID=UUID
   ARRAY /dev/md1 UUID=UUID
   ARRAY /dev/md2 UUID=UUID

   各デバイスのUUIDは次のコマンドで取得できます。

   > sudo mdadm -D /dev/DEVICE | grep UUID

7. /etc/fstabファイルを編集して、RAID 1+0デバイス /dev/md2のエントリを追加します。次の例は、XFSファイルシステム、およびマウントポイントとして/dataを使用するRAIDデバイスのエントリを示しています。

   /dev/md2 /data xfs defaults 1 2

8. RAIDデバイスをマウントします。

   > sudo mount /data

YaST(およびmdadmと--level=10オプション)では、RAID 0 (ストライピング)およびRAID 1 (ミラーリング)の両方の機能を組み合わせた単一のコンプレックスソフトウェアRAID 10デバイスが作成されます。すべてのデータブロックの複数のコピーが、ストライピングの規則に従って、複数のドライブ上に配置されます。コンポーネントデバイスは、すべて同じサイズにする必要があります。

コンプレックスRAIDは、ネストしたRAID 10 (1+0)と目的は同じですが、次の点で異なります。

9.2.2 レイアウト #

 

コンプレックスRAID 10のセットアップでは、ディスクにデータブロックを配置する方法を定義するレイアウトが3つサポートされています。利用可能なレイアウトは、near (デフォルト)、far、およびoffsetです。各レイアウトはパフォーマンス特性が異なるため、ワークロードに適したレイアウトを選択することが重要です。

9.2.2.1 nearレイアウト #

 

nearレイアウトでは、異なるコンポーネントデバイス上で、データブロックのコピーが互いに接近してストライプされます。つまり、あるデータブロックの複数のコピーが異なるデバイス内で同様にオフセットされます。nearは、RAID 10のデフォルトレイアウトです。たとえば、奇数個のコンポーネントデバイスとデータの2コピーを使用する場合は、一部のコピーが、1チャンク分、デバイス内を前進します。

コンプレックスRAID 10のnearレイアウトは、半数のドライブ上のRAID 0と同様の読み書きパフォーマンスを提供します。

偶数個のディスクと2つのレプリカを使用したnearレイアウト

sda1 sdb1 sdc1 sde1
  0    0    1    1
  2    2    3    3
  4    4    5    5
  6    6    7    7
  8    8    9    9

奇数個のディスクと2つのレプリカを使用したnearレイアウト

sda1 sdb1 sdc1 sde1 sdf1
  0    0    1    1    2
  2    3    3    4    4
  5    5    6    6    7
  7    8    8    9    9
  10   10   11   11   12

9.2.2.2 farレイアウト #

 

farレイアウトは、すべてのドライブの前半部分にデータをストライプし、次に、2つ目のデータコピーをすべてのドライブの後半部分にストライプして、ブロックのすべてのコピーが異なるドライブに配置されるようにします。値の2つ目のセットは、コンポーネントドライブの中ほどから開始します。

farレイアウトでは、コンプレックスRAID 10の読み込みパフォーマンスは、すべてのドライブを使用したRAID 0と同様ですが、書き込みパフォーマンスは、ドライブヘッドのシーク回数が増えるので、RAID 0よりかなり遅くなります。このレイアウトは、 読み込み専用ファイルサーバなどの、読み込み集約型操作に最適です。

RAID 10の書き込み速度は、nearレイアウトを使用しているRAID 1やRAID 10などの他のミラーリングRAIDの種類と同等です。これは、ファイルシステムのエレベータが生の書き込みよりも効率のよい書き込みのスケジュールを行うためです。RAID 10をfarレイアウトで使用する方法は、ミラーリングによる書き込みアプリケーションに適しています。

偶数個のディスクと2つのレプリカを使用したfarレイアウト

sda1 sdb1 sdc1 sde1
  0    1    2    3
  4    5    6    7
  . . .
  3    0    1    2
  7    4    5    6

奇数個のディスクと2つのレプリカを使用したfarレイアウト

sda1 sdb1 sdc1 sde1 sdf1
  0    1    2    3    4
  5    6    7    8    9
  . . .
  4    0    1    2    3
  9    5    6    7    8

9.2.2.3 offsetレイアウト #

 

offsetレイアウトでは、あるチャンクの複数のコピーが連続したドライブ上で連続したオフセットにレイアウトされるよう、ストライプが複製されます。実際は、それぞれのストライプが複製され、コピーが1つのデバイスでオフセットされます。これにより、適度な大きさのチャンクサイズを使用している場合は、farレイアウトと同様の読み込み特性が得られますが、書き込みのシーク回数は少なくなります。

偶数個のディスクと2つのレプリカを使用したoffsetレイアウト

sda1 sdb1 sdc1 sde1
  0    1    2    3
  3    0    1    2
  4    5    6    7
  7    4    5    6
  8    9   10   11
 11    8    9   10

奇数個のディスクと2つのレプリカを使用したoffsetレイアウト

sda1 sdb1 sdc1 sde1 sdf1
  0    1    2    3    4
  4    0    1    2    3
  5    6    7    8    9
  9    5    6    7    8
 10   11   12   13   14
 14   10   11   12   13

9.2.2.4 YaSTおよびmdadmによるレプリカ数とレイアウトの指定 #

 

レプリカ数とレイアウトは、YaSTではパリティアルゴリズム、mdadmでは--layoutパラメータで指定します。使用できる値は次のとおりです。

nN

nearレイアウトの場合、nを指定し、Nをレプリカ数で置き換えます。レイアウトおよびレプリカ数を設定しない場合、デフォルトでn2が使用されます。

fN

farレイアウトの場合、fを指定し、Nをレプリカ数で置き換えます。

oN

offsetレイアウトの場合、oを指定し、Nをレプリカ数で置き換えます。

注記: レプリカの数

YaSTでは、パリティアルゴリズムパラメータに設定可能なすべての値が自動的に表示されます。

ソフトウェアRAIDのサイズを増やすには、複数のタスクを所定の順序で実行する必要があります。まずRAIDを構成するすべてのパーティションのサイズを増加させ、次にRAID自体のサイズを増加させます。そして最後に、ファイルシステムのサイズを増加させます。

警告: データ消失の可能性

RAIDに、ディスクの耐障害性がないか、単に一貫性がない場合、パーティションのどれかを削除すると、データが失われます。パーティションの削除は注意深く行い、必ず、データのバックアップをとってください。

ソフトウェアRAIDのサイズを減らすには、複数のタスクを所定の順序で実行する必要があります。まずファイルシステムのサイズを縮小し、次にRAIDを構成するすべてのパーティションのサイズを縮小します。そして最後に、RAID自体のサイズを縮小します。

警告: データ消失の可能性

RAIDに、ディスクの耐障害性がないか、単に一貫性がない場合、パーティションのどれかを削除すると、データが失われます。パーティションの削除は注意深く行い、必ず、データのバックアップをとってください。

重要: XFS

XFSでフォーマットされたファイルシステムのサイズを縮小することはできません。XFSではそのような機能がサポートされていないためです。そのため、XFSファイルシステムを使用するRAIDのサイズを縮小することはできません。