Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

ストレージ管理ガイド

Red Hat Enterprise Linux 7

RHEL 7 での単一ノードストレージのデプロイおよび設定

概要

本ガイドでは、Red Hat Enterprise Linux 7 でストレージデバイスおよびファイルシステムを効果的に管理する方法を説明します。これは、Red Hat Enterprise Linux または Fedora に関する基本から中級の知識を持つシステム管理者向けのものです。

第1章 概要

『ストレージ管理ガイド』』 には、Red Hat Enterprise Linux 7 でサポートされるファイルシステムおよびデータストレージ機能に関する広範な情報が含まれています。本書は、単一ノード (非クラスター化) ストレージソリューションを管理する管理者向けのクイックリファレンスになります。
『ストレージ管理ガイド』は、「ファイルシステム」、「ストレージ管理」、および「VDO を使用したデータの重複排除と圧縮」の 3 つに分かれています。
「ファイルシステム」のセクションでは、Red Hat Enterprise Linux 7 がサポートするさまざまなファイルシステムについて詳しく説明します。ファイルシステムについての説明のほか、それらを最大限に活用する方法についても説明します。
ストレージ管理の部分では、Red Hat Enterprise Linux 7 がサポートするさまざまなツールとストレージ管理タスクについて詳しく説明します。ファイルシステムについての説明のほか、それらを最大限に活用する方法についても説明します。
「VDO を使用したデータの重複排除と圧縮」のセクションでは、VDO (Virtual Data Optimizer) について説明しています。VDO を使用して、ストレージ要件を減らす方法を説明します。

1.1. Red Hat Enterprise Linux 7 の新機能および改良された機能

Red Hat Enterprise Linux 7 におけるファイルシステムの機能拡張の特徴は、以下のとおりです。

eCryptfs は含まれていません。

Red Hat Enterprise Linux 7 の時点では、eCryptfs は含まれていません。ファイルシステムの暗号化の詳細については、Red Hat の『セキュリティーガイド』を参照してください。

System Storage Manager

Red Hat Enterprise Linux 7 には、コマンドラインインターフェースを提供してさまざまなストレージ技術を管理する System Storage Manager と呼ばれる新しいアプリケーションが含まれています。詳細は、16章System Storage Manager(SSM) を参照してください。

XFS はデフォルトのファイルシステムです。

Red Hat Enterprise Linux 7 以降、XFS がデフォルトのファイルシステムになります。XFS ファイルシステムの詳細は、3章XFS ファイルシステム を参照してください。

ファイルシステムの再構築

Red Hat Enterprise Linux 7 では、新しいファイルシステム構造が導入されています。/bin/sbin/lib、および /lib64 のディレクトリーは、/usr の下にネスト化されるようになりました。

Snapper

Red Hat Enterprise Linux 7 では、Snapper と呼ばれる新しいツールが導入されています。これにより、LVM および Btrfs のスナップショットの作成と管理が容易になります。詳細は、14章Snapper を使用したスナップショットの作成と保守 を参照してください。

Btrfs (テクノロジープレビュー)

注記
Btrfs は、Red Hat Enterprise Linux 7 ではテクノロジープレビューとして利用できますが、Red Hat Enterprise Linux 7.4 リリース以降では非推奨になりました。Red Hat Enterprise Linux の将来のメジャーリリースで削除される予定です。
詳細は、『Red Hat Enterprise Linux 7.4 リリースノート』の「非推奨の機能」を参照してください。
Btrfs は、統合 LVM 操作を含む、より優れたパフォーマンスとスケーラビリティーの提供を目指すローカルファイルシステムです。このファイルシステムは、Red Hat では完全にサポートされていないため、テクノロジープレビューとなります。Btrfs の詳細は、6章Btrfs (テクノロジープレビュー) を参照してください。

NFSv2 はサポートされなくなりました

Red Hat Enterprise Linux 7 以降、NFSv2 はサポートされなくなりました。

パート I. ファイルシステム

「ファイルシステム」のセクションでは、ファイルシステムの構造とメンテナンスに関する情報、Btrfs テクノロジープレビュー、および Red Hat が完全にサポートされるファイルシステム (ext3、ext4、GFS2、XFS、NFS、および FS-Cache) に関する情報を提供します。
注記
Btrfs は、Red Hat Enterprise Linux 7 ではテクノロジープレビューとして利用できますが、Red Hat Enterprise Linux 7.4 リリース以降では非推奨になりました。Red Hat Enterprise Linux の将来のメジャーリリースで削除される予定です。
詳細は、『Red Hat Enterprise Linux 7.4 リリースノート』の「非推奨の機能」を参照してください。
Red Hat Enterprise Linux ファイルシステムおよびストレージ制限の概要は、Red Hat ナレッジベースの「Red Hat Enterprise Linux technology capabilities and limits」を参照してください。
XFS は、Red Hat Enterprise Linux 7 および Red Hat におけるデフォルトのファイルシステムです。Red Hatでは、別のファイルシステムを使用する強い理由がない限り、XFS を使用することをお勧めします。一般的なファイルシステムとそのプロパティーに関する一般情報は、Red Hat ナレッジベースの記事「How to Choose your Red Hat Enterprise Linux File System」を参照してください。

第2章 ファイルシステム構造とメンテナンス

ファイルシステムの構造は、オペレーティングシステムの組織の最も基本的なレベルです。オペレーティングシステムがユーザー、アプリケーション、およびセキュリティーモデルと対話する方法は、オペレーティングシステムがストレージデバイスでファイルを編成する方法にほぼ常に依存します。一般的なファイルシステムの構造を提供することで、ユーザーとプログラムがファイルにアクセスして書き込むことができます。
ファイルシステムは、ファイルを 2 つの論理カテゴリーに分類します。
共有可能および共有不可能なファイル
共有可能 ファイルは、ローカルおよびリモートホストからアクセスできます。Unsharable ファイルはローカルでのみ利用可能です。
変数および静的ファイル
ドキュメントなどの 変数 ファイルはいつでも変更できます。バイナリー などの 静的 ファイルは、システム管理者のアクションなしでは変更されません。
この方法でファイルを分類すると、各ファイルの機能と、それらを保持するディレクトリーに割り当てられたパーミッションとを相互に関連付ける上で役立ちます。オペレーティングシステムとそのユーザーがファイルを操作する方法によって、ファイルが配置されるディレクトリー、そのディレクトリーが読み取り専用パーミッションまたは読み取りと書き込みのパーミッションでマウントされているかどうか、および各ユーザーがそのファイルにアクセスできるレベルが決まります。この組織のトップレベルは非常に重要です。基礎となるディレクトリーへのアクセスを制限できます。そうしないと、トップレベルから下のアクセスルールが厳密な構造に準拠していない場合に、セキュリティー問題が発生する可能性があります。

2.1. ファイルシステム階層標準 (FHS) の概要

Red Hat Enterprise Linux は、Filesystem Hierarchy Standard (FHS) のファイルシステム構造を使用します。これは、多くのファイルタイプやディレクトリーの名前、場所、およびパーミッションを定義します。
FHS ドキュメントは、すべての FHS 準拠のファイルシステムにとって信頼できるリファレンスですが、この標準では、多くの領域が未定義または拡張可能です。このセクションでは、標準の概要と、標準でカバーされていないファイルシステムの部分について説明します。
FHS コンプライアンスの 2 つの最も重要な要素は次のとおりです。
  • 他の FHS 準拠システムとの互換性
  • /usr/ パーティションを読み取り専用としてマウントする機能。/usr/ には一般的な実行可能ファイルが含まれており、ユーザーが変更すべきではないため、これは非常に重要となります。さらに、/usr/ は読み取り専用としてマウントされているため、CD-ROM ドライブまたは他のマシンから、読み取り専用 NFS マウント経由でマウントできる必要があります。

2.1.1. FHS 組織

ここで記載されているディレクトリーおよびファイルは、FHS ドキュメントで指定された小さなサブセットです。最も詳しい情報については、最新の FHS ドキュメント http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf を参照してください。file-hierarchy(7) の man ページにも概要が記載されています。
注記
利用可能なディレクトリーは、指定のシステムにインストールされた内容によって異なります。以下のリストは、見つかる可能性のあるものの一例になります。

2.1.1.1. ファイルシステム情報の収集

df コマンド
df コマンドは、システムのディスク領域の使用量を報告します。出力は以下のようになります。

例2.1 df コマンドの出力

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       11675568   6272120   4810348  57% / /dev/sda1
	                 100691      9281     86211  10% /boot
none                     322856         0    322856   0% /dev/shm
デフォルトでは、df はパーティションのサイズを 1 キロバイトブロック単位で表示し、使用中および利用可能なディスク領域の容量をキロバイト単位で表示します。メガバイトおよびギガバイトで情報を表示するには、df -h コマンドを使用します。-h 引数は「human-readable」の形式を表します。df -h の出力は以下のようになります。

例2.2 df -h コマンドの出力

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                        12G  6.0G  4.6G  57% / /dev/sda1
			99M  9.1M   85M  10% /boot
none 			316M     0  316M   0% /dev/shm
注記
上記の例では、マウントされたパーティション /dev/shm はシステムの仮想メモリーファイルシステムを表します。
du コマンド
du コマンドは、ディレクトリー内のファイルが使用している推定領域を表示し、各サブディレクトリーのディスク使用量を表示します。du の出力の最後の行は、ディレクトリーの合計ディスク使用量を表示します。人間が判読可能な形式でディレクトリーの合計ディスク使用量のみを表示するには、du -hs を使用します。その他のオプションは、man du を参照してください。
Gnome システムモニター
グラフィカル形式でシステムのパーティションとディスク領域の使用状況を表示するには、ApplicationsSystem ToolsSystem Monitor をクリックするか、gnome-system-monitor コマンドを使用して、Gnome System Monitor を使用します。ファイルシステム タブを選択して、システムのパーティションを表示します。以下の図は、ファイルシステム タブを示しています。

図2.1 GNOME システムモニターのファイルシステムタブ

GNOME システムモニターのファイルシステムタブ

2.1.1.2. /boot/ ディレクトリー

/boot/ ディレクトリーには、Linux カーネルなど、システムの起動に必要な静的ファイルが含まれます。これらのファイルは、システムが正しく起動するためには不可欠です。
警告
/boot/ ディレクトリーを削除しないでください。削除すると、システムが起動できなくなります。

2.1.1.3. /dev/ ディレクトリー

/dev/ ディレクトリーには、以下のデバイス種別を表すデバイスノードが含まれます。
  • システムに接続されているデバイス
  • カーネルが提供する仮想デバイス
これらのデバイスノードは、システムが適切に機能するために不可欠です。udevd デーモンは、必要に応じて /dev/ のデバイスノードを作成および削除します。
/dev/ ディレクトリーおよびサブディレクトリー内のデバイスは、文字 (マウスやキーボードなどの入力と出力のシリアルストリームのみを提供) またはブロック (ハードドライブやフロッピードライブなどのランダムにアクセス可能) のいずれかとして定義されます。GNOME または KDE がインストールされている場合は、一部のストレージデバイスは (USBなどで) 接続または (CDまたはDVDドライブなどの) 挿入時に自動的に検出され、内容を表示するポップアップウィンドウが表示されます。

表2.1 /dev ディレクトリーの一般的なファイルの例

ファイル 説明
/dev/hda プライマリー IDE チャネル上のマスターデバイス。
/dev/hdb プライマリー IDE チャンネル上のスレーブデバイス。
/dev/tty0 最初の仮想コンソール。
/dev/tty1 2 番目の仮想コンソール
/dev/sda プライマリー SCSI または SATA チャネル上の最初のデバイス。
/dev/lp0 最初の並列ポート。
有効なブロックデバイスは、以下の 2 種類のエントリーのいずれかになります。
マップされたデバイス
ボリュームグループの論理ボリューム (例: /dev/mapper/VolGroup00-LogVol02)。
静的デバイス
たとえば、/dev/sdbX (sdb はストレージデバイス名で X はパーティション番号) などの従来のストレージボリューム。/dev/sdbX は、/dev/disk/by-id/WWID または /dev/disk/by-uuid/UUID にすることもできます。詳細は、「永続的な命名」 を参照してください。

2.1.1.4. /etc/ ディレクトリー

/etc/ ディレクトリーは、マシンのローカルとなる設定ファイル用に予約されています。バイナリーを含めることはできません。バイナリーがある場合は、それらを /usr/bin/ または /usr/sbin/ に移動します。
たとえば、/etc/skel/ ディレクトリーには、「スケルトン」ユーザーファイルが格納されています。これは、ユーザーの初回作成時にホームディレクトリーを設定するために使用されます。また、アプリケーションはこのディレクトリーに設定ファイルを保存し、実行時にそれらを参照する可能性があります。/etc/exports ファイルは、どのファイルシステムをリモートホストにエクスポートするかを制御します。

2.1.1.5. /mnt/ ディレクトリー

/mnt/ ディレクトリーは、NFS ファイルシステムのマウントなどの、一時的にマウントされたファイルシステム用に予約されています。すべてのリムーバブルストレージメディアには、/media/ ディレクトリーを使用します。自動的に検出されたリムーバブルメディアは、/media ディレクトリーにマウントされます。
重要
/mnt ディレクトリーは、インストールプログラムでは使用しないでください。

2.1.1.6. /opt/ ディレクトリー

/opt/ ディレクトリーは通常、デフォルトのインストールの一部ではないソフトウェアおよびアドオンパッケージ用に予約されています。/opt/ にインストールするパッケージは、その名前を持つディレクトリーを作成します (例: /opt/packagename/)多くの場合、このようなパッケージは、予測可能なサブディレクトリー構造に従います。ほとんどの場合、バイナリーは /opt/packagename/bin/ に保存され、man ページは /opt/packagename/man/ に保存されます。

2.1.1.7. /proc/ ディレクトリー

/proc/ ディレクトリーには、カーネルから情報を抽出するか、カーネルに情報を送信する特別なファイルが含まれています。このような情報の例には、システムメモリー、CPU 情報、およびハードウェア設定が含まれます。/proc/ の詳細は、「/proc 仮想ファイルシステム」 を参照してください。

2.1.1.8. /srv/ ディレクトリー

/srv/ ディレクトリーには、Red Hat Enterprise Linux システムが提供するサイト固有のデータが含まれます。このディレクトリーは、FTP、WWW、または CVS などの特定サービスのデータファイルの場所をユーザーに提供します。特定のユーザーにのみ関連するデータは、/home/ ディレクトリー内になければなりません。

2.1.1.9. /sys/ ディレクトリー

/sys/ ディレクトリーは、カーネルに固有の新しい sysfs 仮想ファイルシステムを使用します。カーネルのホットプラグハードウェアデバイスのサポートが増えると、/sys/ ディレクトリーには、/proc/ が保持する情報と同様の情報が含まれますが、ホットプラグデバイスに固有のデバイス情報の階層ビューが表示されます。

2.1.1.10. /usr/ ディレクトリー

/usr/ ディレクトリーは、複数のマシンにまたがって共有できるファイル用です。多くの場合、/usr/ ディレクトリーは独自のパーティションにあり、読み取り専用でマウントされます。少なくとも、/usr/ には以下のサブディレクトリーが含まれている必要があります。
/usr/bin
このディレクトリーはバイナリーに使用されます。
/usr/etc
このディレクトリーは、システム全体の設定ファイルに使用されます。
/usr/games
このディレクトリにはゲームが保存されています。
/usr/include
このディレクトリーは C ヘッダーファイルに使用されます。
/usr/kerberos
このディレクトリーは、Kerberos 関連のバイナリーおよびファイルに使用されます。
/usr/lib
このディレクトリーは、シェルスクリプトまたはユーザーが直接使用するように設計されていないオブジェクトファイルやライブラリーに使用されます。
Red Hat Enterprise Linux 7.0 以降、/lib/ ディレクトリーは /usr/lib にマージされました。また、/usr/bin/ および /usr/sbin/ のバイナリーの実行に必要なライブラリーも含まれるようになりました。これらの共有ライブラリーイメージは、システムを起動したり、root ファイルシステム内でコマンドを実行したりするために使用されます。
/usr/libexec
このディレクトリーには、他のプログラムによって呼び出される小さなヘルパープログラムが含まれます。
/usr/sbin
Red Hat Enterprise Linux 7.0 以降、/sbin/usr/sbin に移動しました。これは、システムの起動、復元、復旧、または修復に不可欠なものを含む、すべてのシステム管理バイナリーが含まれていることを意味します。/usr/sbin/ のバイナリーを使用するには、root 権限が必要です。
/usr/share
このディレクトリーには、アーキテクチャー固有ではないファイルを保存します。
/usr/src
このディレクトリーには、ソースコードが保存されます。
/var/tmp にリンクされた /usr/tmp
このディレクトリーには、一時ファイルが保存されます。
/usr/ ディレクトリーには /local/ サブディレクトリーも含まれる必要があります。FHS によると、このサブディレクトリーは、ソフトウェアをローカルでインストールする際にシステム管理者によって使用されるので、システムの更新中に上書きされないようにする必要があります。/usr/local ディレクトリーの構造は /usr/ と似ており、以下のサブディレクトリーが含まれます。
  • /usr/local/bin
  • /usr/local/etc
  • /usr/local/games
  • /usr/local/include
  • /usr/local/lib
  • /usr/local/libexec
  • /usr/local/sbin
  • /usr/local/share
  • /usr/local/src
Red Hat Enterprise Linux の /usr/local/ の使用は、FHS と若干異なります。FHS は、/usr/local/ を使用して、システムソフトウェアをアップグレードする心配がないままのソフトウェアを保存するために使用する必要があることを記しています。RPM Package Manager はソフトウェアアップグレードを安全に実行できるため、ファイルを /usr/local/ に保存してファイルを保護する必要はありません。
代わりに、Red Hat Enterprise Linux はマシンにローカルなソフトウェアに /usr/local/ を使用します。たとえば、/usr/ ディレクトリーがリモートホストから読み取り専用の NFS 共有としてマウントされている場合でも、/usr/local/ ディレクトリーの下にパッケージまたはプログラムをインストールすることができます。

2.1.1.11. /var/ ディレクトリー

FHS では、Linux が /usr/ を読み取り専用としてマウントする必要があるため、ログファイルを書き込むプログラムや、spool/ または lock/ ディレクトリーが必要なプログラムは、それらを /var/ ディレクトリーに書き込む必要があります。FHS によると、/var/ は、spool ディレクトリーおよびファイル、ロギングデータ、一時的ファイルを含む変数データ用となります。
以下は、/var/ ディレクトリー内にあるディレクトリーの一部です。
  • /var/account/
  • /var/arpwatch/
  • /var/cache/
  • /var/crash/
  • /var/db/
  • /var/empty/
  • /var/ftp/
  • /var/gdm/
  • /var/kerberos/
  • /var/lib/
  • /var/local/
  • /var/lock/
  • /var/log/
  • /var/spool/mail/ にリンクされた /var/mail
  • /var/mailman/
  • /var/named/
  • /var/nis/
  • /var/opt/
  • /var/preserve/
  • /var/run/
  • /var/spool/
  • /var/tmp/
  • /var/tux/
  • /var/www/
  • /var/yp/
重要
/var/run/media/user ディレクトリーには、USB ストレージメディア、DVD、CD-ROM、Zip ディスクなどのリムーバブルメディアのマウントポイントとして使用されるサブディレクトリーが含まれます。以前は、/media/ ディレクトリーはこの目的で使用されていた点に留意してください。
messages および lastlog などのシステムログファイルは、/var/log/ ディレクトリーに移動します。/var/lib/rpm/ ディレクトリーには、RPM システムデータベースが含まれます。ロックファイルは、通常はファイルを使用するプログラムのディレクトリーにある /var/lock/ ディレクトリーに移動します。/var/spool/ ディレクトリーには、一部のプログラムのデータファイルを格納するサブディレクトリーがあります。これらのサブディレクトリーには以下が含まれます。
  • /var/spool/at/
  • /var/spool/clientmqueue/
  • /var/spool/cron/
  • /var/spool/cups/
  • /var/spool/exim/
  • /var/spool/lpd/
  • /var/spool/mail/
  • /var/spool/mailman/
  • /var/spool/mqueue/
  • /var/spool/news/
  • /var/spool/postfix/
  • /var/spool/repackage/
  • /var/spool/rwho/
  • /var/spool/samba/
  • /var/spool/squid/
  • /var/spool/squirrelmail/
  • /var/spool/up2date/
  • /var/spool/uucp/
  • /var/spool/uucppublic/
  • /var/spool/vbox/

2.2. 特別な Red Hat Enterprise Linux ファイルの場所

Red Hat Enterprise Linux は、特別なファイルに対応するために FHS 構造を若干拡張しています。
RPM に関連するほとんどのファイルは、/var/lib/rpm/ ディレクトリーに保持されます。RPM の詳細は、man rpm を参照してください。
/var/cache/yum/ ディレクトリーには、システムの RPM ヘッダー情報を含む Package Updater が使用するファイルが含まれます。この場所は、システムの更新中にダウンロードされた RPM を一時的に保存するためにも使用できます。Red Hat Network の詳細は https://rhn.redhat.com/ を参照してください。
Red Hat Enterprise Linux に固有の別の場所は /etc/sysconfig/ ディレクトリーです。このディレクトリーには、さまざまな設定情報が格納されています。システムの起動時に実行されるスクリプトの多くは、このディレクトリー内のファイルを使用します。

2.3. /proc 仮想ファイルシステム

ほとんどのファイルシステムとは異なり、/proc にはテキストファイルもバイナリーファイルも含まれていません。仮想ファイル を格納するため、/proc は仮想ファイルシステムと呼ばれます。これらの仮想ファイルは、大量の情報が含まれている場合でも、サイズは通常 0 バイトになります。
/proc ファイルシステムはストレージには使用されません。この主な目的は、ハードウェア、メモリー、実行中のプロセス、および他のシステムコンポーネントにファイルベースのインターフェースを提供することです。リアルタイム情報は、対応する /proc ファイルを表示することで、多くのシステムコンポーネントで取得できます。/proc 内のファイルの一部は、カーネルを設定するために (ユーザーとアプリケーションの両方で) 操作することもできます。
以下の /proc ファイルは、システムストレージの管理および監視に関連しています。
/proc/devices
現在設定されているさまざまな文字およびブロックデバイスを表示します。
/proc/filesystems
カーネルで現在対応しているすべてのファイルシステムタイプを一覧表示します。
/proc/mdstat
システム上の複数ディスクまたは RAID 設定に関する現在の情報が含まれます (存在する場合)。
/proc/mounts
システムで現在使用しているマウントをすべて一覧表示します。
/proc/partitions
パーティションブロック割り当て情報が含まれます。
/proc ファイルシステムの詳細は、『Red Hat Enterprise Linux 7 『デプロイメントガイド』』を参照してください。

2.4. 未使用ブロックの破棄

バッチ破棄とオンライン破棄操作は、ファイルシステムで使用されていないブロックを破棄するマウントされたファイルシステムの機能です。これは、ソリッドステートドライブおよびシンプロビジョニングされたストレージの両方に役立ちます。
  • バッチ破棄操作 は、ユーザーが fstrim コマンドを使用して明示的に実行します。このコマンドは、ファイルシステム内にある未使用のブロックで、管理者が指定した基準に一致するものをすべて破棄します。
  • オンライン破棄操作 は、マウント時に、mountコマンドの一部として -o discard オプションで指定するか、/etc/fstab ファイルの discard オプションで指定します。ユーザーによる介入なしでリアルタイムで実行されます。オンライン破棄操作は、使用中から空きに移行しているブロックのみを破棄します。
どちらの操作タイプも、Red Hat Enterprise Linux 6.2 以降の ext4 ファイルシステムと、Red Hat Enterprise Linux 6.4 以降のXFSファイルシステムでの使用がサポートされています。また、ファイルシステムの基礎となるブロックデバイスは、物理的な破棄操作に対応している必要があります。/sys/block/device/queue/discard_max_bytes ファイルに保存されている値がゼロではない場合は、物理的な破棄操作に対応しています。
fstrim コマンドを以下のいずれかで実行している場合:
  • 破棄操作をサポートしていないデバイス、または
  • 複数のデバイスから構成され、そのデバイスのいずれかが破棄操作をサポートしていない論理デバイス (LVM または MD)
以下のメッセージが表示されます。
fstrim -v /mnt/non_discard
fstrim: /mnt/non_discard: the discard operation is not supported
注記
mount コマンドを使用すると、-o discard オプションを使用した破棄操作をサポートしていないデバイスをマウントできます。
システムのワークロードがバッチ破棄を実行できない場合、またはパフォーマンスを維持するためにオンライン破棄操作が必要な場合を除いて、Red Hat はバッチ破棄操作を推奨します。
詳細は fstrim(8) および mount(8) の man ページを参照してください。

第3章 XFS ファイルシステム

XFS は、元々は Silicon Graphics, Inc で設計された非常に拡張性の高い、高性能のファイルシステムです。XFS は、Red Hat Enterprise Linux 7 のデフォルトのファイルシステムです。
XFS の主な機能
  • XFS は、メタデータジャーナリング をサポートしているため、クラッシュリカバリーを迅速に行うことができます。
  • XFS ファイルシステムは、マウントされ、アクティブな状態でデフラグし、拡張できます。
  • また、Red Hat Enterprise Linux 7 は XFS 固有のバックアップおよび復元ユーティリティーをサポートしています。
割り当て機能
XFS は、次の割り当てスキームを特長としています。
  • エクステント (領域) ベースの割り当て
  • ストライプを認識できる割り当てポリシー
  • 遅延割り当て
  • 領域の事前割り当て
遅延割り当てや他のパフォーマンスの最適化は、ext4 と同じように XFS に影響を与えます。つまり、XFS ファイルシステムへのプログラムの書き込みは、プログラムが後で fsync() 呼び出しを発行しない限り、ディスク上にあることが保証されません。
ファイルシステム (ext4 および XFS) での遅延割り当ての影響の詳細は、5章ext4 ファイルシステム割り当て機能 を参照してください。
注記
ディスク容量が十分であるように見えても、ファイルの作成または展開が予期しない ENOSPC 書き込みエラーで失敗することがあります。これは、XFS のパフォーマンス指向の設計が原因となります。実際には、残りの容量が数ブロックしかない場合にのみ発生するため、問題にはなりません。
その他の XFS 機能
XFS ファイルシステムは、以下もサポートしています。
拡張属性 (xattr)
これにより、システムが、ファイルごとに、名前と値の組み合わせを追加で関連付けられるようになります。これは、デフォルトで有効になっています。
クォータジャーナリング
クラッシュ後に行なわれる、時間がかかるクォータの整合性チェックが不要になります。
プロジェクト/ディレクトリークォータ
ディレクトリーツリー全体にクォータ制限を適用できます。
サブセカンド (一秒未満) のタイムスタンプ
これにより、タイムスタンプはサブセカンド (一秒未満) になることができます。
デフォルトの atime 動作は relatime です。
XFS では、デフォルトで Relatime がオンになっています。正常な atime の値を維持する一方で、noatime と比較してオーバーヘッドはほとんどありません。

3.1. XFS ファイルシステムの作成

  • XFS ファイルシステムを作成するには、以下のコマンドを使用します。
    # mkfs.xfs block_device
    • block_device をブロックデバイスへのパスに置き換えます。たとえば、/dev/sdb1/dev/disk/by-uuid/05e99ec8-def1-4a5e-8a9d-5945339ceb2a、または /dev/my-volgroup/my-lv になります。
    • 通常、デフォルトのオプションは、一般的な使用に最適なものです。
    • 既存のファイルシステムを含むブロックデバイスで mkfs.xfs を使用する場合は、そのファイルシステムを上書きする -f オプションを追加してください。

例3.1 mkfs.xfs コマンドの出力

以下は、mkfs.xfs コマンドの出力例です。
meta-data=/dev/device            isize=256    agcount=4, agsize=3277258 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=13109032, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal log           bsize=4096   blocks=6400, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
注記
XFS ファイルシステムの作成後、そのサイズを縮小することはできません。ただし、xfs_growfs コマンドを使用して拡大することはできます。詳細は、「XFS ファイルシステムのサイズの拡大」 を参照してください。

ストライプ化ブロックデバイス

ストライプ化されたブロックデバイス (RAID5 アレイなど) の場合は、ファイルシステムの作成時にストライプジオメトリーを指定できます。適切なストライプジオメトリーを使用すると、XFS ファイルシステムのパフォーマンスが向上します。
LVM ボリュームまたは MD ボリュームにファイルシステムを作成する場合、mkfs.xfs は最適なジオメトリーを選択します。これは、ジオメトリー情報をオペレーティングシステムにエクスポートする一部のハードウェア RAID でも当てはまる場合があります。
デバイスがストライプジオメトリー情報をエクスポートすると、mkfs ユーティリティー (ext3、ext4、xfs 用) は自動的にこのジオメトリーを使用します。ストレージに実際にストライプジオメトリーがあるにもかかわらず、mkfs ユーティリティーでストライプジオメトリーが検出されない場合は、以下のオプションを使用してファイルシステムを作成する際に手動で指定することができます。
su=value
ストライプユニットまたは RAID チャンクサイズを指定します。value は、バイトで指定する必要があります。オプションで、km、または g 接尾辞が付きます。
sw=value
RAID デバイス内のデータディスク数、または 1 ストライプ内のストライプユニット数を指定します。
以下の例では、4 つのストライプユニットを含む RAID デバイスで 64k のチャンクサイズを指定しています。
# mkfs.xfs -d su=64k,sw=4 /dev/block_device

関連情報

XFS ファイルシステムの作成に関する詳細は、以下を参照してください。

3.2. XFS ファイルシステムのマウント

XFS ファイルシステムは、追加オプションなしでマウントできます。以下に例を示します。
# mount /dev/device /mount/point
Red Hat Enterprise Linux 7 のデフォルトは inode64 です。
注記
mke2fs とは異なり、mkfs.xfs は設定ファイルを使用しません。これらはすべてコマンドラインで指定されます。

書き込みバリア

デフォルトでは、XFS は書き込みバリアを使用して、書き込みキャッシュが有効なデバイスの電源が失われた場合でも、ファイルシステムの整合性を確保します。書き込みキャッシュがないデバイス、またはバッテリーでバックアップされた書き込みキャッシュがあるデバイスの場合は、nobarrier オプションを使用してバリアを無効にします。
# mount -o nobarrier /dev/device /mount/point
書き込みバリアの詳細は、22章書き込みバリア を参照してください。

Direct Access テクノロジープレビュー

Red Hat Enterprise Linux 7.3 以降、ext4 および XFS のファイルシステムで Direct Access (DAX) がテクノロジープレビューとして利用できます。これは、アプリケーションが永続メモリーをそのアドレス空間に直接マッピングするための手段です。DAX を使用するには、システムで利用可能な永続メモリーの形式が必要です。通常は、NVDIMM (Non-Volatile Dual In-line Memory Module) の形式で、DAX に対応するファイルシステムを NVDIMM に作成する必要があります。また、ファイルシステムは dax マウントオプション でマウントする必要があります。これにより、dax をマウントしたファイルシステムのファイルの mmap が、アプリケーションのアドレス空間にストレージを直接マッピングされます。

3.3. XFS クォータ管理

XFS クォータサブシステムは、ディスク領域 (ブロック) およびファイル (inode) の使用量の制限を管理します。XFS クォータは、ユーザー、グループ、ディレクトリーレベル、またはプロジェクトレベルでこれらの項目の使用を制御または報告します。また、ユーザー、グループ、ディレクトリーまたはプロジェクトのクォータは個別に有効になりますが、グループとプロジェクトのクォータは相互に排他的であることに注意してください。
ディレクトリーまたはプロジェクトごとに管理する場合、XFS は特定のプロジェクトに関連付けられたディレクトリー階層のディスク使用量を管理します。そうすることで、XFS はプロジェクト間の組織間にまたがる「グループ」境界を認識します。これにより、ユーザーまたはグループのクォータを管理する際に使用できるレベルよりも、広いレベルの制御が提供されます。
XFS クォータは、特定のマウントオプションを指定して、マウント時に有効になります。各マウントオプションは noenforce として指定することもできます。これにより、制限を強制適用せずに使用状況の報告が可能になります。有効なクォータマウントオプションは以下の通りです。
  • uquota/uqnoenforce: ユーザークォータ
  • gquota/gqnoenforce: グループクォータ
  • pquota/pqnoenforce: プロジェクトクォータ
クォータを有効にすると、xfs_quota ツールを使用して制限を設定し、ディスク使用量を報告できます。xfs_quota は、デフォルトでは対話形式かつ basic mode で実行されます。基本モードのサブコマンドは使用量を報告するだけで、すべてのユーザーが使用できます。基本的な xfs_quota サブコマンドには以下が含まれます。
quota username/userID
指定の username または数値の userID の使用状況および制限を表示します。
df
ブロックおよび inode の空きおよび使用済みの数を表示します。
これとは対照的に、xfs_quota には エキスパートモード もあります。このモードのサブコマンドは、制限を実際に設定することができるため、昇格した特権を持つユーザーのみが利用できます。エキスパートモードサブコマンドを対話的に使用するには、以下のコマンドを使用します。
# xfs_quota -x
エキスパートモードのサブコマンドには以下が含まれます。
report /path
特定のファイルシステムのクォータ情報を報告します。
limit
クォータの制限を変更します。
基本モードまたはエキスパートモードのいずれかのサブコマンドの完全な一覧については、サブコマンド help を使用してください。
すべてのサブコマンドは、-c オプションを使用してコマンドラインから直接実行することもできます。エキスパートサブコマンドの場合は -x を使用します。

例3.2 サンプルクォータレポートの表示

たとえば、(/dev/blockdevice の) /home のクォータレポートのサンプルを表示するには、xfs_quota -x -c 'report -h' /home コマンドを使用します。これにより、以下のような出力が表示されます。
User quota on /home (/dev/blockdevice)
Blocks
User ID      Used   Soft   Hard Warn/Grace
---------- ---------------------------------
root            0      0      0  00 [------]
testuser   103.4G      0      0  00 [------]
...
ホームディレクトリーが /home/john のユーザー john に対して、inode 数のソフト制限およびハード制限をそれぞれ500 と 700 に設定するには、以下のコマンドを使用します。
# xfs_quota -x -c 'limit isoft=500 ihard=700 john' /home/
この場合は、マウントされた xfs ファイルシステムである mount_point を渡します。
デフォルトでは、limit サブコマンドはターゲットをユーザーとして認識します。グループに制限を設定する場合は、(前出の例のように) -g オプションを使用します。同様に、プロジェクトには -p を使用します。
ソフトブロックおよびハードブロック制限は、isoft または ihard の代わりに bsoft または bhard を使用して設定することもできます。

例3.3 ソフトブロックおよびハードブロック制限の設定

たとえば、/target/path のファイルシステムで accounting をグループ化するために、ソフトおよびハードのブロック制限をそれぞれ 1000m と 1200m に設定するには、以下のコマンドを使用します。
# xfs_quota -x -c 'limit -g bsoft=1000m bhard=1200m accounting' /target/path
注記
コマンド bsoft および bhard は、バイト単位でカウントされます。
重要
リアルタイムブロック (rtbhard/rtbsoft) は、クォータの設定時に有効な単位として man xfs_quota に記述されていますが、本リリースではリアルタイムサブボリュームが有効化されていません。そのため、rtbhard オプションおよび rtbsoft オプションは、適用されません。

プロジェクト制限の設定

プロジェクトが制御するディレクトリーに制限を設定する前に、最初に /etc/projects に追加します。プロジェクト名を /etc/projectid に追加して、プロジェクト ID をプロジェクト名にマップできます。プロジェクトを /etc/projects に追加したら、以下のコマンドを使用してプロジェクトディレクトリーを初期化します。
# xfs_quota -x -c 'project -s projectname' project_path
初期化したディレクトリーを持つプロジェクトのクォータは、以下を使用して設定できます。
# xfs_quota -x -c 'limit -p bsoft=1000m bhard=1200m projectname'
汎用クォータ設定ツール (例: quotarepquota、および edquota) を使用して XFS クォータを操作することもできます。ただし、このツールは XFS プロジェクトクォータでは使用できません。
重要
Red Hat は、他の利用可能なすべてのツールよりも xfs_quota を使用することを推奨します。
XFS クォータの設定に関する詳細は、man xfs_quotaman projid(5)、および man projects(5) を参照してください。

3.4. XFS ファイルシステムのサイズの拡大

xfs_growfs コマンドを使用して、マウントしたまま XFS ファイルシステムを大きくすることができます。
# xfs_growfs /mount/point -D size
-D size オプションは、指定した size にファイルシステムを拡張します (ファイルシステムブロックで表現)。xfs_growfs は、-D size のオプションなしでは、デバイスがサポートする最大サイズまでファイルシステムを拡張します。
-D size で XFS ファイルシステムを拡張する前に、基礎となるブロックデバイスが、後でファイルシステムを保持するのに適したサイズであることを確認します。該当するブロックデバイスのサイズを変更する場合は、ブロックデバイスに適した方法を選択してください。
注記
XFS ファイルシステムは、マウント中にサイズを大きくすることができますが、サイズを縮小することはできません。
ファイルシステムの拡張に関する詳細は、man xfs_growfs を参照してください。

3.5. XFS ファイルシステムの修復

XFS ファイルシステムを修復するには、xfs_repair を使用します。
# xfs_repair /dev/device
xfs_repair ユーティリティーは非常にスケーラブルで、inode が多数ある非常に大きなファイルシステムを効率的に修復するように設計されています。xfs_repair は、他の Linux ファイルシステムとは異なり、XFS ファイルシステムが正しくアンマウントされていなくても起動時には実行されません。クリーンでないアンマウントが発生した場合、xfs_repair はマウント時にログを再生するだけで、一貫したファイルシステムが保証されます。
警告
xfs_repair ユーティリティーは、ダーティーログで XFS ファイルシステムを修復できません。ログをクリアするには、XFS ファイルシステムをマウントおよびアンマウントします。ログが破損して再生できない場合は、- L オプション(「force log zeroing」)を使用してログを消去します(つまり、xfs_repair -L /dev/device です)。これにより、さらなる破損やデータの損失が生じる可能性があることに注意してください。
XFS ファイルシステムの修復に関する詳細は、man xfs_repair を参照してください。

3.6. XFS ファイルシステムの一時停止

ファイルシステムへの書き込み動作を一時停止または再開するには、以下のコマンドを使用します。
# xfs_freeze mount-point
書き込みアクティビティーを停止することで、ハードウェアベースのデバイスのスナップショットを使用して、一貫性のある状態でファイルシステムをキャプチャーできます。
注記
xfs_freeze ユーティリティーは、xfsprogs パッケージにより提供されます。これは、x86_64 でのみ利用できます。
XFS ファイルシステムを一時停止(フリーズ)するには、次のコマンドを実行します。
# xfs_freeze -f /mount/point
XFS ファイルシステムのフリーズを解除するには、次のコマンドを使用します。
# xfs_freeze -u /mount/point
LVM スナップショットを開始する場合は、最初に xfs_freeze を使用してファイルシステムを一時停止する必要はありません。代わりに、LVM 管理ツールは、スナップショットを作成する前に XFS ファイルシステムを自動的にサスペンドします。
XFS ファイルシステムのフリーズとアンフリーズに関する詳細は、man xfs_freeze を参照してください。

3.7. XFS ファイルシステムのバックアップおよび復元

XFS ファイルシステムのバックアップと復元には、以下のユーティリティーが含まれます。
  • バックアップを作成するための xfsdump
  • バックアップから復元するための xfsrestore

3.7.1. XFS バックアップおよび復元の機能

Backup

xfsdump ユーティリティーを使用して以下を行うことができます。
  • 通常のファイルイメージへのバックアップ
    通常のファイルに書き込むことができるバックアップは 1 つだけです。
  • テープドライブへのバックアップ
    xfsdump ユーティリティーを使用すると、同じテープに複数のバックアップを書き込むこともできます。バックアップは、複数のテープを分割して書き込むことができます。
    複数のファイルシステムのバックアップを 1 つのテープデバイスに作成するには、XFS バックアップがすでに含まれているテープにバックアップを書き込みます。これにより、古いバックアップに、新しいバックアップが追加されます。xfsdump は、デフォルトでは既存のバックアップを上書しません。
  • 増分バックアップの作成
    xfsdump ユーティリティーは ダンプレベル を使用して、他のバックアップの相対的なベースバックアップを決定します。0 から 9 までの数字は、ダンプレベルの増加を表します。増分バックアップは、下位レベルの最後のダンプ以降に変更したファイルのみが対象となります。
    • フルバックアップを実行する場合は、ファイルシステムで レベル 0 のダンプを実行します。
    • レベル 1 のダンプは、フルバックアップ後の最初の増分バックアップです。次の増分バックアップはレベル 2 になります。これは、最後のレベル 1 のダンプ以降に変更したファイルのみが対象となります。レベル 9 までです。
  • ファイルを絞り込むサイズ、サブツリー、または inode のフラグを使用して、バックアップからファイルを除外

復元

xfsrestore ユーティリティーは、xfsdump により生成されたバックアップからファイルシステムを復元します。xfsrestore ユーティリティーには 2 つのモードがあります。
  • simple モードでは、ユーザーはレベル 0 のダンプからファイルシステム全体を復元できます。これがデフォルトのモードです。
  • cumulative モードでは、増分バックアップ(つまりレベル 1 からレベル 9)からファイルシステムを復元できます。
各バックアップは、一意の session ID または session label で識別されます。複数のバックアップを含むテープからバックアップを復元するには、対応するセッション ID またはラベルが必要です。
バックアップから特定のファイルを抽出、追加、または削除するには、xfsrestore インタラクティブモードを入力します。インタラクティブモードでは、バックアップファイルを操作する一連のコマンドが提供されます。

3.7.2. XFS ファイルシステムのバックアップ

この手順では、XFS ファイルシステムのコンテンツのバックアップを、ファイルまたはテープに作成する方法を説明します。

手順3.1 XFS ファイルシステムのバックアップ

  • 次のコマンドを使用して、XFS ファイルシステムのバックアップを作成します。
    # xfsdump -l level[] -L label -f backup-destination path-to-xfs-filesystem
    • level をバックアップのダンプレベルに置き換えます。フルバックアップを実行する場合は 0 を使用し、それに続く増分バックアップを実行する場合は 1 から 9 を使用します。
    • backup-destination を、バックアップを保存するパスに置き換えます。保存場所は、通常のファイル、テープドライブ、またはリモートテープデバイスです。たとえば、ファイルの場合は /backup-files/Data.xfsdump、テープドライブの場合は /dev/st0 のようになります。
    • path-to-xfs-filesystem をバックアップを作成する XFS ファイルシステムのマウントポイントに置き換えます。たとえば、/mnt/data/ になります。ファイルシステムをマウントする必要があります。
    • 複数のファイルシステムのバックアップを作成して単一のテープデバイスに保存する場合は、復元時にそれらを簡単に識別できるように、- L label オプションを使用して各バックアップにセッションラベルを追加します。label をバックアップの任意の名前に置き換えます (例: backup_data)。

例3.4 複数の XFS ファイルシステムのバックアップ

  • /boot/ ディレクトリーおよび /data/ ディレクトリーにマウントされている XFS ファイルシステムのコンテンツのバックアップを作成し、ファイルとして / backup-files/ ディレクトリーに保存するには、次のコマンドを実行します。
    # xfsdump -l 0 -f /backup-files/boot.xfsdump /boot
    # xfsdump -l 0 -f /backup-files/data.xfsdump /data
  • 1 つのテープデバイスにある複数のファイルシステムのバックアップを作成するには、- L label オプションを使用して各バックアップにセッションラベルを追加します。
    # xfsdump -l 0 -L "backup_boot" -f /dev/st0 /boot
    # xfsdump -l 0 -L "backup_data" -f /dev/st0 /data

関連情報

  • XFS ファイルシステムのバックアップの詳細は、xfsdump(8) の man ページを参照してください。

3.7.3. バックアップからの XFS ファイルシステムの復元

この手順では、XFS ファイルシステムの内容を、ファイルまたはテープのバックアップから復元する方法を説明します。

前提条件

手順3.2 バックアップからの XFS ファイルシステムの復元

  • バックアップを復元するコマンドは、フルバックアップから復元するか、増分バックアップから復元するか、または 1 つのテープデバイスから複数のバックアップを復元するかによって異なります。
    # xfsrestore [-r][][][] -S session-id -L session-label -i
                 -f backup-location restoration-path
    • backup-location を、バックアップの場所に置き換えます。これは、通常のファイル、テープドライブ、またはリモートテープデバイスになります。たとえば、ファイルの場合は /backup-files/Data.xfsdump、テープドライブの場合は /dev/st0 のようになります。
    • restoration-path を、ファイルシステムを復元するディレクトリーへのパスに置き換えます。たとえば、/mnt/data/ になります。
    • ファイルシステムを増分(レベル 1 からレベル 9)バックアップから復元するには、- r オプションを追加します。
    • 複数のバックアップを含むテープデバイスからバックアップを復元するには、- S オプションまたは - L オプションを使用してバックアップを指定します。
      -S を使用するとセッション ID でバックアップを選択でき、- L を使用するとセッションラベルを選択できます。セッション ID およびセッションラベルを取得するには、xfsrestore -I コマンドを使用します。
      session-id を、バックアップのセッション ID に置き換えます。たとえば、b74a3586-e52e-4a4a-8775-c3334fa8ea2c に置き換えます。session-label を、バックアップのセッションラベルに置き換えます。たとえば、my_backup_session_label に置き換えます。
    • xfsrestore をインタラクティブに使用するには、- i オプションを使用します。
      インタラクティブダイアログは、xfsrestore が、指定したデバイスの読み取りが終了した後に始まります。インタラクティブな xfsrestore シェルで利用可能なコマンドには、cdlsadddelete、および extract が含まれます。コマンドの全一覧については、help コマンドを使用します。

例3.5 複数の XFS ファイルシステムの復元

XFS バックアップファイルを復元し、その内容を /mnt/ 配下のディレクトリーに保存します。
# xfsrestore -f /backup-files/boot.xfsdump /mnt/boot/
# xfsrestore -f /backup-files/data.xfsdump /mnt/data/
複数のバックアップを含むテープデバイスから復元するには、各バックアップをセッションラベルまたはセッション ID で指定します。
# xfsrestore -f /dev/st0 -L "backup_boot" /mnt/boot/
# xfsrestore -f /dev/st0 -S "45e9af35-efd2-4244-87bc-4762e476cbab" /mnt/data/

Tape からバックアップを復元するときの情報メッセージ

複数のファイルシステムのバックアップを使用してテープからバックアップを復元する場合は、xfsrestore ユーティリティーがメッセージを出力する 場合があります。このメッセージは、xfsrestore がテープ上の各バックアップを順番に調べたときに、要求されたバックアップと一致するかどうかを通知します。以下に例を示します。
xfsrestore: preparing drive
xfsrestore: examining media file 0
xfsrestore: inventory session uuid (8590224e-3c93-469c-a311-fc8f23029b2a) does not match the media header's session uuid (7eda9f86-f1e9-4dfd-b1d4-c50467912408)
xfsrestore: examining media file 1
xfsrestore: inventory session uuid (8590224e-3c93-469c-a311-fc8f23029b2a) does not match the media header's session uuid (7eda9f86-f1e9-4dfd-b1d4-c50467912408)
[...]
情報メッセージは、一致するバックアップが見つかるまで継続して表示されます。

関連情報

  • XFS ファイルシステムの復元の詳細は、xfsrestore(8) の man ページを参照してください。

3.8. エラー動作の設定

I/O 操作中にエラーが発生した場合には、XFS ドライバーは以下のいずれかの方法で応答します。
  • 以下のいずれかになるまで再試行を続行します。
    • I/O 操作に成功し、
    • I/O 操作の再試行回数または時間制限を超える。
  • エラーを永続的に考慮し、システムを停止します。
XFS は現在、以下のエラー条件を認識して、希望の動作を設定できます。
  • EIO: デバイスへの書き込み試行中にエラー
  • ENOSPC: デバイスに領域が残っていない
  • ENODEV: デバイスが見つかりません
特定のハンドラーが定義されていない、その他の可能なエラー条件はすべて、単一のグローバル設定を共有します。
XFS がエラーを永続化する条件は、再試行の最大数と最大期間(秒単位)の両方で設定できます。XFS は、いずれかの条件が満たされると再試行を停止します。
また、他の設定に関係なく、ファイルシステムのマウント解除時に再試行を即時にキャンセルするオプションもあります。これにより、永続的なエラーが発生した場合でも、マウント解除操作を成功できます。

3.8.1. 特定の条件および未定義の条件の設定ファイル

エラーの動作を制御する設定ファイルは、/sys/fs/xfs/device/error/ ディレクトリーにあります。
/sys/fs/xfs/デバイス/error/metadata/ ディレクトリーには、特定のエラー状態ごとにサブディレクトリーが含まれます。
  • EIO エラー条件の /sys/fs/xfs/デバイス/error/metadata/EIO /
  • /sys/fs/xfs/device/error/metadata/ENODEV/ENODEV エラー条件の場合)
  • /sys/fs/xfs/device/error/metadata/ENOSPC/ for the ENOSPC error condition
各設定ファイルには、以下の設定ファイルが含まれます。
  • /sys/fs/xfs/device/error/metadata/condition/max_retries: XFS が操作を再試行する最大回数を制御します。
  • /sys/fs/xfs/device/error/metadata/condition/retry_timeout_seconds: XFS が操作の再試行を停止するまでの時間(秒単位)
前のセクションで説明したものを除いて、他のすべての考えられるエラー状態は、これらのファイルで共通の設定を共有しています。
  • /sys/fs/xfs/device/error/metadata/default/max_retries: 再試行の最大数を制御します。
  • /sys/fs/xfs/device/error/metadata/default/retry_timeout_seconds: 再試行する時間制限を制御します。

3.8.2. 特定の条件および未定義条件でのファイルシステム動作の設定

再試行の最大数を設定するには、必要な数を max_retries ファイルに書き込みます。
  • 特定の条件の場合:
    # echo value > /sys/fs/xfs/device/error/metadata/condition/max_retries
  • 未定義の条件の場合:
    # echo value > /sys/fs/xfs/device/error/metadata/default/max_retries
value は、-1 から最大許容値の int (C 符号付き整数型)の間の数値です。これは、64 ビット Linux では 2147483647 です。
時間制限を設定するには、希望する秒数を retry_timeout_seconds ファイルに書き込みます。
  • 特定の条件の場合:
    # echo value > /sys/fs/xfs/device/error/metadata/condition/retry_timeout_seconds
  • 未定義の条件の場合:
    # echo value > /sys/fs/xfs/device/error/metadata/default/retry_timeout_seconds
value は、-1 から 86400 までの数字で、1 日の秒数です。
max_retries と retry_ timeout_seconds の両方のオプションでは、-1 は永久に再試行され、0 は即座に 停止します
device は、/dev/ ディレクトリーにあるデバイス名です。たとえば、sda などです。
注記
それぞれのエラー状態のデフォルトの動作は、エラーコンテキストによって異なります。ENODEV などの一部のエラーは、リトライ回数に関係なく致命的で回復不可能なものと見なされるため、デフォルト値は 0 になります。

3.8.3. アンマウント動作の設定

fail_at_unmount オプションが設定されている場合、ファイルシステムはアンマウント時に他のすべてのエラー設定を上書きし、I/O 操作を再試行せずにすぐにファイルシステムを通知します。これにより、永続的なエラーが発生した場合でも、マウント解除操作を成功できます。
アンマウント動作を設定するには、以下を実行します。
# echo value > /sys/fs/xfs/device/error/fail_at_unmount
値は 1 または 0 のいずれかになります。
  • 1 は、エラーが見つかった場合すぐに再試行することを意味します。
  • 0max_retries および retry_ timeout_seconds オプションを適用することを意味します。
device は、/dev/ ディレクトリーにあるデバイス名です。たとえば、sda などです。
重要
ファイルシステムのマウントを解除する前に、必要に応じて fail_at_unmount オプションを設定する必要があります。アンマウント操作が開始されたら、設定ファイルおよびディレクトリーが利用できなくなる可能性があります。

3.9. その他の XFS ファイルシステムユーティリティー

Red Hat Enterprise Linux 7 は、XFS ファイルシステムを管理するその他のユーティリティーも特長としています。
xfs_fsr
マウントされた XFS ファイルシステムのデフラグに使用します。引数なしで呼び出されると、xfs_fsr は、マウントされたすべての XFS ファイルシステムのすべての通常のファイルをデフラグします。また、このユーティリティーを使用すると、ユーザーは指定した時間にデフラグを中断し、後で停止した場所から再開することもできます。
さらに、xfs_fsr は、xfs_fsr /path/to/file のように、1 つのファイルのデフラグを許可します。XFS は、デフォルトでは断片化を回避するため、Red Hat はファイルシステム全体を定期的に非アクティブにしないことを推奨します。システム全体のデフラグにより、空き領域での断片化の副次的影響が生じる可能性があります。
xfs_bmap
XFS ファイルシステムのファイルが使用するディスクブロックのマッピングを出力します。このマップは、指定されたファイルで使用される各エクステントと、対応するブロックがないファイル(つまり holes)を持つリージョンを一覧表示します。
xfs_info
XFS ファイルシステム情報を出力します。
xfs_admin
XFS ファイルシステムのパラメーターを変更します。xfs_admin ユーティリティーは、マウント解除されたデバイスまたはファイルシステムのパラメーターのみを変更できます。
xfs_copy
XFS ファイルシステム全体のコンテンツを 1 つ以上のターゲットにコピーします。
以下のユーティリティーは、XFS ファイルシステムのデバッグおよび分析にも便利です。
xfs_metadump
XFS ファイルシステムのメタデータをファイルにコピーします。Red Hat は、xfs_metadump ユーティリティーを使用してアンマウントされたファイルシステムまたは読み取り専用のマウントされたファイルシステムをコピーすることのみをサポートします。それ以外の場合は、生成されたダンプが破損したり、一貫性のない可能性があります。
xfs_mdrestore
XFS メタダンプイメージ( xfs_metadumpを使用して生成)のファイルシステムイメージを復元します。
xfs_db
XFS ファイルシステムをデバッグします。
これらのユーティリティーの詳細は、それぞれの man ページを参照してください。

3.10. ext4 から XFS への移行

Red Hat Enterprise Linux 7.0 以降、デフォルトのファイルシステムは ext4 ではなく XFS になります。本セクションでは、XFS ファイルシステムを使用または管理する際の相違点を説明します。
ext4 ファイルシステムは、引き続き Red Hat Enterprise Linux 7 で完全にサポートされており、インストール時に選択できます。ext4 から XFS への移行は可能ですが、必須ではありません。

3.10.1. Ext3/4 と XFS の相違点

ファイルシステムの修復
Ext3/4 は、起動時にユーザースペースで e2fsck を実行して、必要に応じてジャーナルを復元します。比較すると、XFS はマウント時にカーネル空間でジャーナルリカバリーを実行します。fsck.xfs シェルスクリプトが提供されていますが、initscript 要件を満たすためだけに存在するため、有用なアクションは実行されません。
XFS ファイルシステムの修復またはチェックが要求されたら、xfs_repair コマンドを使用します。読み取り専用チェックには、 -n オプションを使用します。
xfs_repair コマンドは、ダーティーログがあるファイルシステムでは動作しません。このようなファイルシステムを修復するには、最初に mountunmount を実行してログを再生する必要があります。ログが破損し、再生できない場合は、-L オプションを使用して、ログでゼロアウトすることができます。
XFS ファイルシステムのファイルシステム修復の詳細は、「XFS」 を参照してください。
メタデータエラーの動作
メタデータエラーが発生した場合は、ext3/4 ファイルシステムには設定可能な動作があり、デフォルトは単純になります。XFS が復元できないメタデータエラーが発生すると、ファイルシステムをシャットダウンし、EFSCORRUPTED エラーを返します。システムログにはエラーの詳細が含まれ、必要な場合は xfs_repair を実行することが推奨されます。
クォータ
XFS クォータは再マウントできるオプションではありません。クォータを有効にするには、-o quota オプションを初期マウントに指定する必要があります。
クォータパッケージ内の標準ツールは基本的なクォータ管理タスク( setquotarepquotaなど)を実行できますが、xfs_quota ツールは、プロジェクトのクォータ管理などの XFS 固有の機能に使用できます。
quotacheck コマンドは、XFS ファイルシステムには影響しません。XFS で初めてクォータアカウンティングがオンになっていると、内部的には自動クォータチェックが行われ ます。XFS クォータメタデータはファーストクラスであるため、ジャーナル化されたメタデータオブジェクトは、クォータを手動でオフにされるまでクォータシステムが常に一貫しています。
ファイルシステムのサイズ変更
XFS ファイルシステムには、ファイルシステムを縮小するユーティリティーがありません。XFS ファイルシステムは、xfs_growfs コマンドでオンラインで拡張できます。
Inode 番号
256 バイトの inode を持つ 1 TB を超えるファイルシステムの場合、または 512 バイトの inode を持つ 2 TB を超えるファイルシステムの場合は、XFS の inode 数が 2^32 を超える可能性があります。このような inode 番号が大きいと、32 ビットの統計呼び出しが EOVERFLOW の戻り値で失敗します。上記の問題は、デフォルトの Red Hat Enterprise Linux 7 設定を使用する場合は、4 つの割り当てグループでトリップすると発生する可能性があります。ファイルシステムの拡張や XFS ファイルシステムパラメーターの変更など、カスタム設定により、動作が異なる場合があります。
通常、アプリケーションはこのような大きな inode 番号を正しく処理します。必要に応じて、- o inode32 パラメーターを使用して XFS ファイルシステムをマウントし、2^32 未満の inode 番号を実施します。inode32 を使用しても、すでに 64 ビットの数値が割り当てられている inode には影響しません。
重要
特定の環境 で必要でない限り、inode32 オプションは使用しないでください。inode32 オプションは割り当ての動作を変更します。その結果、下層のディスクブロックに inode を割り当てるための領域がない場合に、ENOSPC エラーが発生する可能性があります。
投機的事前割り当て
XFS は、ファイルの書き込み時に、投機的事前割り当て を使用して、過去 EOF のブロックを割り当てます。これにより、NFS サーバーで書き込みワークロードを同時ストリーミングするので、ファイルの断片化が回避されます。デフォルトでは、この事前割り当てはファイルのサイズを大きくし、「du」出力に明確になります。投機的事前割り当てのあるファイルが 5 分間ダーティーではない場合、事前割り当ては破棄されます。inode がキャッシュからその時間前にサイクルされた場合には、inode が回収されると、事前割り当ては破棄されます。
投機的事前割り当てによりプリ成熟した ENOSPC の問題が発生する場合には、- o allocsize=amount マウントオプションを指定して、固定の事前割り当て量を指定できます。
断片化関連のツール
断片化は、遅延割り当てや投機的事前割り当てなど、ヒューリスティックや動作が原因で XFS ファイルシステムでは大きな問題が発生することはほとんどありません。ただし、ファイルシステムの断片化やファイルシステムのデフラグを測定するためのツールは存在します。この使用は推奨されていません。
xfs_db frag コマンドは、ファイルシステムの割り当てを 1 つの断片化数値に分割しようとします。これはパーセンテージで示されます。コマンドの出力には、その意味を理解するための重要な専門知識が必要です。たとえば、断片化係数 75% は、ファイルごとの平均 4 エクステントのみを意味します。このため、xfs_db の frag の出力が有用とみなされず、断片化の問題をより注意深く分析することが推奨されます。
警告
xfs_fsr コマンドは、個々のファイルのデフラグや、ファイルシステムのすべてのファイルをデフラグするために使用できます。ファイルの局所性を破棄し、空き領域が断片化された可能性があるため、後での使用は推奨されません。

ext3 および ext4 Compared のコマンドと XFS の比較

以下の表は、ext3 および ext4 で使用する一般的なコマンドを、XFS 固有の対応と比較しています。

表3.1 ext3 および ext4 の比較のための一般的なコマンド

タスク ext3/4 XFS
ファイルシステムを作成する mkfs.ext4 or mkfs.ext3 mkfs.xfs
ファイルシステムを確認する e2fsck xfs_repair
ファイルシステムのサイズ変更 resize2fs xfs_growfs
ファイルシステムのイメージを保存する e2image xfs_metadump and xfs_mdrestore
ファイルシステムのラベル付けまたはチューニングを行う tune2fs xfs_admin
ファイルシステムをバックアップする。 dump および restore xfsdump and xfsrestore
以下の表は、XFS ファイルシステムで機能する汎用ツールを示していますが、XFS バージョンにはより具体的な機能があるため、その方法が推奨されます。

表3.2 ext4 および XFS のための汎用ツール

タスク ext4 XFS
クォータ quota xfs_quota
ファイルマッピング filefrag xfs_bmap
一覧表示された XFS コマンドの詳細は、3章XFS ファイルシステム に含まれています。詳細は、リスト化された XFS 管理ツールの man ページも参照してください。

第4章 ext3 ファイルシステム

ext3 ファイルシステムは、基本的に、ext2 ファイルシステムが拡張されたバージョンです。これらの改善により、以下の利点があります。
可用性
予期しない電源障害やシステムクラッシュ(または不 完全なシステムシャットダウン)を行った後に、マシンにマウントされている各 ext2 ファイルシステムを、e2fsck プログラムが整合性することをチェックする必要があります。これは、特に多数のファイルを含む大規模なボリュームで、システムの起動時間を大幅に遅延させる時間のかかるプロセスです。この間、ボリュームのデータには到達できなくなります。
ライブファイルシステムで fsck -n を実行できます。ただし、変更は加えられず、部分的に書き込まれたメタデータが発生した場合に、誤解を招く結果が表示される可能性があります。
LVM がスタックで使用されている場合は、別のオプションとして、ファイルシステムの LVM スナップショットを作成し、代わりに fsck を実行します。
最後に、ファイルシステムを読み取り専用で再マウントするオプションがあります。保留中のメタデータの更新(および書き込み)はすべて、再マウント前にディスクに強制されます。これにより、以前の破損がないため、ファイルシステムが一貫した状態になります。fsck -n を実行できるようになりました。
ext3 ファイルシステムにより提供されるジャーナリングは、システムのシャットダウンが適切に行われなかった場合にファイルシステムチェックの並べ替えが不要になることを示しています。ext3 を使用して整合性チェックが行われるのは、ハードドライブの失敗など、まれにハードウェア障害が発生する可能性があります。不完全なシステムのシャットダウン後に ext3 ファイルシステムを復元する時間は、ファイルシステムのサイズやファイルの数により異なります。この方法は、一貫性を維持するために使用する ジャーナル のサイズによって異なります。デフォルトのジャーナルサイズは、ハードウェアの速度に応じて、復旧に約 1 秒かかります。
注記
Red Hat がサポートする ext3 のジャーナリングモードは data=ordered (デフォルト)です。
データの整合性
ext3 ファイルシステムは、不完全なシステムシャットダウンが発生した場合にデータの整合性が失われないようにします。ext3 ファイルシステムでは、データを受け取る保護の種類とレベルを選択できます。ファイルシステムの状態に関して、ext3 ボリュームは、デフォルトで高レベルのデータの一貫性を維持するために設定されます。
速度
一部のデータを複数回書き込みても、ext3 のジャーナリングによりハードドライブのヘッドモーションが最適化されるため、ほとんどの場合、ext3 のスループットは ext2 よりも高くなります。速度を最適化するために 3 つのジャーナリングモードを選択できますが、システムが障害が発生する場合は、データの整合性に関してトレードオフが発生します。
注記
Red Hat がサポートする ext3 のジャーナリングモードは data=ordered (デフォルト)です。
簡単な移行
ext2 から ext3 に簡単に移行でき、再フォーマットをせずに、堅牢なジャーナリングファイルシステムの恩恵を受けることができます。このタスクの実行方法は、「ext3 ファイルシステムへの変換」 を参照してください。
注記
Red Hat Enterprise Linux 7 は、統一された extN ドライバーを提供します。これは、ext2 設定および ext3 設定を無効にすることによって実行され、それらのオンディスクフォーマットに ext4.ko を使用します。つまり、使用される ext ファイルシステムに関係なく、カーネルメッセージは常に ext4 を参照します。

4.1. ext3 ファイルシステムの作成

インストール後に、新しい ext3 ファイルシステムを作成する必要がある場合があります。たとえば、新しいディスクドライブがシステムに追加される場合は、ドライブをパーティションに分割して、ext3 ファイルシステムを使用する場合があります。
  1. mkfs.ext3 ユーティリティーを使用して、ext3 ファイルシステムでパーティションまたは LVM ボリュームをフォーマット します。
    # mkfs.ext3 block_device
    • block_device をブロックデバイスへのパスに置き換えます。たとえば、/dev/sdb1/dev/disk/by-uuid/05e99ec8-def1-4a5e-8a9d-5945339ceb2a、または /dev/my-volgroup/my-lv になります。
  2. e2label ユーティリティーを使用してファイルシステムにラベルを付けます。
    # e2label block_device volume_label

UUID の設定

また、ファイルシステムに特定の UUID を設定することもできます。ファイルシステムの作成時に UUID を指定するには、-U オプションを使用します。
# mkfs.ext3 -U UUID device
  • UUID を設定する UUID (例: 7cd65de3-e0be-41d9-b66d-96d749c02da7) に置き換えます。
  • device を ext3 ファイルシステムへのパス (例: /dev/sda8) に置き換え、UUID を追加します。
既存のファイルシステムの UUID を変更するには、「永続的な命名属性の変更」 を参照してください。

関連情報

  • mkfs.ext3(8) の man ページ
  • e2label(8) の man ページ

4.2. ext3 ファイルシステムへの変換

tune2fs コマンドは、ext2 ファイルシステムを ext3 に変換します。
注記
ext2 を ext3 に変換するには、tune2fs を使用する前後に、常に e2fsck ユーティリティーを使用してファイルシステムを確認してください。ext2 から ext3 への変換を試みる前に、エラーが発生した場合に備えてすべてのファイルシステムをバックアップしてください。
さらに、Red Hat は、可能な限り ext2 から ext3 に変換するのではなく、新しい ext3 ファイルシステムを作成し、データを移行することを推奨します。
ext2 ファイルシステムを ext3 に変換するには、root としてログインし、ターミナルに以下のコマンドを入力します。
# tune2fs -j block_device
block_device には、変換する ext2 ファイルシステムが含まれます。
df コマンドを実行して、マウントされたファイルシステムを表示します。

4.3. Ext2 ファイルシステムへの復元

ext2 ファイルシステムに戻すには、以下の手順に従います。
分かりやすくするため、本セクションのコマンド例は、ブロックデバイスに以下の値を使用します。
/dev/mapper/VolGroup00-LogVol02

手順4.1 ext3 から ext2 に戻す

  1. root としてログインし、パーティションをアンマウントして以下を入力します。
    # umount /dev/mapper/VolGroup00-LogVol02
  2. 以下のコマンドを入力して、ファイルシステムの種類を ext2 に変更します。
    # tune2fs -O ^has_journal /dev/mapper/VolGroup00-LogVol02
  3. 以下のコマンドを入力して、パーティションでエラーの有無を確認します。
    # e2fsck -y /dev/mapper/VolGroup00-LogVol02
  4. 次に、以下を入力して ext2 ファイルシステムとしてパーティションを再度マウントします。
    # mount -t ext2 /dev/mapper/VolGroup00-LogVol02 /mount/point
    /mount/point をパーティションのマウントポイントに置き換えます。
    注記
    .journal ファイルがパーティションの root レベルに存在する場合は、これを削除します。
パーティションを ext2 に永続的に変更するには、/etc/fstab ファイルを更新することを忘れないでください。そうしないと、起動後に元に戻されます。

第5章 ext4 ファイルシステム

ext4 ファイルシステムは、ext3 ファイルシステムの拡張性を高めたファイルシステムです。Red Hat Enterprise Linux 7 では、最大 16 テラバイトのファイルシステムしかサポートしていなかった Red Hat Enterprise Linux 6 とは異なり、最大 16 テラバイトの個別のファイルサイズと、最大 50 テラバイトのファイルシステムをサポートすることができます。また、サブディレクトリーの数を無制限にサポートします (ext3 ファイルシステムは最大 32,000 までしかサポートしません)。ただし、リンク数が 65,000 を超えると 1 にリセットされ、増加しなくなります。bigalloc 機能は現在サポートされていません。
注記
ext3 と同様に、fsck を実行するには、ext4 ボリュームをアンマウントする必要があります。詳細は、4章ext3 ファイルシステム を参照してください。
主な特長
ext4 ファイルシステムは(ext2 および ext3)で使用される従来のブロックマッピングスキームではなく、エクステントを使用します。これにより、大きなファイルを使用する場合のパフォーマンスが向上し、大型のファイルのメタデータのオーバーヘッドが削減されます。さらに、ext4 は、未割り当てのブロックグループと、inode テーブルセクションに適宜ラベルを付けます。これにより、ファイルシステムのチェック時に省略できます。これにより、ファイルシステムのチェックを迅速化し、ファイルシステムがサイズが大きくなるとより有益になります。
割り当て機能
ext4 ファイルシステムには、以下の割り当てスキームが含まれます。
  • 永続的な事前割り当て
  • 遅延割り当て
  • マルチブロック割り当て
  • ストライプ認識割り当て
遅延している割り当てやその他のパフォーマンスの最適化により、ディスクにファイルを書き込む ext4 の動作は、ext3 とは異なります。ext4 では、プログラムがファイルシステムに書き込みを行う際に、プログラムが fsync() 呼び出しを発行する場合を除き、ディスク上の送信は保証されません。
デフォルトでは、ext3 は、fsync() がなくても、新しく作成されたファイルをディスクに自動的にディスクへ強制します。この動作は、fsync() を使用せず、書き込まれたデータがオンディスクであることを確認するプログラムのバグが生じました。一方、ext4 ファイルシステムは、ディスクへの変更を書き込むのに数秒待機します。これにより、ディスクのパフォーマンスが ext3 よりも良くなるため、書き込みを結合して並べ替えます。
警告
ext3 とは異なり、ext4 ファイルシステムは、トランザクションのコミット時にディスクにデータを強制しません。そのため、バッファーされた書き込みがディスクにフラッシュされるのに時間がかかります。ファイルシステムと同様に、fsync() などのデータ整合性呼び出しを使用して、データが永続ストレージに書き込まれるようにします。
その他の ext4 機能
ext4 ファイルシステムは、以下にも対応しています。
  • 拡張属性 (xattr): これにより、システムは、ファイルごとに、名前と値の組み合わせを追加で関連付けられるようになります。
  • クォータジャーナリング - クラッシュ後に時間がかかるクォータの整合性チェックが不要になります。
    注記
    ext4 でサポートされるジャーナルモードは data=ordered (デフォルト)のみです。
  • サブセカンド(一秒未満 )のタイムスタンプ - サブセカンドのタイムスタンプを指定します。

5.1. ext4 ファイルシステムの作成

  • ext4 ファイルシステムを作成するには、以下のコマンドを使用します。
    # mkfs.ext4 block_device
    • block_device をブロックデバイスへのパスに置き換えます。たとえば、/dev/sdb1/dev/disk/by-uuid/05e99ec8-def1-4a5e-8a9d-5945339ceb2a、または /dev/my-volgroup/my-lv になります。
    • 一般的な用途では、デフォルトのオプションが最適です。

例5.1 mkfs.ext4 コマンドの出力

以下は、作成されるファイルシステムのジオメトリーと機能を表示するコマンドの出力例です。
~]# mkfs.ext4 /dev/sdb1
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
245280 inodes, 979456 blocks
48972 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1006632960
30 block groups
32768 blocks per group, 32768 fragments per group
8176 inodes per group
Superblock backups stored on blocks: 
 32768, 98304, 163840, 229376, 294912, 819200, 884736

Writing inode tables: done                            
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
重要
tune2fs を使用して、ext3 ファイルシステムで特定の ext4 機能を有効にすることができます。ただし、この方法で tune2fs の使用は完全にテストされていないため、Red Hat Enterprise Linux 7 ではサポートされていません。したがって、Red Hat は、tune2fs を使用して、変換またはマウントされた ext3 ファイルシステムのパフォーマンスと予測可能な動作を保証できません。

ストライプ化ブロックデバイス

ストライプ化されたブロックデバイス (RAID5 アレイなど) の場合は、ファイルシステムの作成時にストライプジオメトリーを指定できます。適切なストライプジオメトリーを使用すると、ext4 ファイルシステムのパフォーマンスが向上します。
LVM ボリュームまたは MD ボリュームでファイルシステムを作成する場合、mkfs.ext4 は最適なジオメトリーを選択します。これは、ジオメトリー情報をオペレーティングシステムにエクスポートするハードウェア RAID で当てはまります。
ストライプジオメトリーを指定するには、以下のサブオプションとともに mkfs.ext4-E オプション (拡張ファイルシステムオプション) を使用します。
stride=value
RAID チャンクサイズを指定します。
stripe-width=value
RAID デバイス内のデータディスク数、または 1 ストライプ内のストライプユニット数を指定します。
両方のサブオプションの場合、value は、ファイルシステムのブロック単位で指定する必要があります。たとえば、4k ブロックのファイルシステムに 64k ストライド(16 x 4096)のファイルシステムを作成する場合は、以下のコマンドを使用します。
# mkfs.ext4 -E stride=16,stripe-width=64 /dev/block_device

UUID の設定

また、ファイルシステムに特定の UUID を設定することもできます。ファイルシステムの作成時に UUID を指定するには、-U オプションを使用します。
# mkfs.ext4 -U UUID device
  • UUID を設定する UUID (例: 7cd65de3-e0be-41d9-b66d-96d749c02da7) に置き換えます。
  • device を、ext4 ファイルシステムへのパス(例: /dev/sda8)に置き換え、UUID を追加します
既存のファイルシステムの UUID を変更するには、「永続的な命名属性の変更」 を参照してください。

関連情報

ext4 ファイルシステムの作成に関する詳細は、以下を参照してください。
  • mkfs.ext4(8) の man ページ

5.2. ext4 ファイルシステムのマウント

ext4 ファイルシステムは、追加のオプションなしでマウントできます。以下に例を示します。
# mount /dev/device /mount/point
ext4 ファイルシステムは、動作に影響を与える複数のマウントオプションもサポートします。たとえば、acl パラメーターは アクセス制御リストを有効にし、user_xattr パラメーターはユーザー拡張属性を有効にします。両方のオプションを有効にするには、以下のように -o でそれぞれのパラメーターを使用します。
# mount -o acl,user_xattr /dev/device /mount/point
ext3 と同様に、ファイル データでエラーが発生した場合には、data_err=abort オプションを使用してジャーナルを中止できます。
# mount -o data_err=abort /dev/device /mount/point
tune2fs ユーティリティーを使用すると、管理者はファイルシステムのスーパーブロックにデフォルトのマウントオプションを設定することもできます。詳細は、man tune2fs を参照してください。

書き込みバリア

デフォルトでは、ext4 は書き込みバリアを使用して、書き込みキャッシュが有効なデバイスに電源が失われた場合でもファイルシステムの整合性を確保します。キャッシュの書き込みキャッシュまたはバッテリーバックアップの書き込みキャッシュを使用したデバイスの場合は、以下のように nobarrier オプションを使用してバリアを無効にします。
# mount -o nobarrier /dev/device /mount/point
書き込みバリアの詳細は、22章書き込みバリア を参照してください。

Direct Access テクノロジープレビュー

Red Hat Enterprise Linux 7.3 以降、Direct Access (DAX)は、ext4 ファイルシステムおよび XFS ファイルシステムではテクノロジープレビューとして、永続メモリーをそのアドレス空間に直接マッピングする手段を提供します。DAX を使用するには、システムで利用可能な永続メモリーの形式が必要になります。通常は、NVDIMM (Non-Volatile Dual In-line Memory Module) の形式で、DAX に対応するファイルシステムを NVDIMM に作成する必要があります。また、ファイルシステムは dax マウントオプション でマウントする必要があります。これにより、dax をマウントしたファイルシステムのファイルの mmap が、アプリケーションのアドレス空間にストレージを直接マッピングされます。

5.3. ext4 ファイルシステムのサイズ変更

ext4 ファイルシステムを拡張する前に、基となるブロックデバイスのサイズが、後でファイルシステムを保持するのに適したサイズであることを確認します。該当するブロックデバイスのサイズを変更する場合は、ブロックデバイスに適した方法を選択してください。
ext4 ファイルシステムは、resize2fs コマンドを使用して、マウントしたままの状態でサイズを大きく することができます。
# resize2fs /mount/device サイズ
resize2fs コマンドは、マウントが解除された ext 4 ファイルシステムのサイズも縮小できます。
# resize2fs /dev/device size
ext4 ファイルシステムのサイズを変更すると、resize2fs ユーティリティーは、特定の単位を示すサフィックスが使用されていない限り、ファイルシステムのブロックサイズの単位でサイズを読み取ります。以下のサフィックスは、特定の単位を示しています。
  • s - 512 バイトセクター
  • k - キロバイト
  • M - メガバイト
  • G - ギガバイト
注記
拡張時のサイズパラメーターは任意です (多くの場合は必要ありません)。resize2fs は自動的に展開され、コンテナーの利用可能な領域(通常は論理ボリュームまたはパーティション)を埋めます。
ext4 ファイルシステムのサイズ変更に関する詳細は、man resize2fs を参照してください。

5.4. ext2、ext3、または ext4 ファイルシステムのバックアップ

この手順では、ext4、ext3、または ext2 ファイルシステムの内容をファイルにバックアップする方法を説明します。

前提条件

  • システムを長時間実行している場合は、バックアップの前にパーティションで e2fsck ユーティリティーを実行します。
    # e2fsck /dev/device

手順5.1 ext2、ext3、または ext4 ファイルシステムのバックアップ

  1. /etc/fstab ファイルの内容と fdisk -l コマンドの出力を含む設定情報のバックアップ。これは、パーティションの復元に役立ちます。
    この情報を取得するには、sosreport ユーティリティーまたは sysreport ユーティリティーを実行します。sosreport の詳細は、「What is a sosreport and how to create one in Red Hat Enterprise Linux 4.6 and later?」を参照してください。Kdowledgebase 記事
  2. パーティションのロールにより異なります。
    • バックアップしたパーティションがオペレーティングシステムのパーティションの場合は、システムをレスキューモードで起動します。『 システム管理者のガイド』の「レスキューモードへの起動」セクションを参照してください』。
    • 通常のデータパーティションをバックアップする場合は、これをアンマウントします。
      マウントされたデータパーティションがマウントされるときにデータパーティションのバックアップを作成することは可能ですが、マウントされたデータパーティションのバックアップの結果は予測できません。
      dump ユーティリティーを使用してマウントされたファイルシステムのバックアップが必要な場合は、ファイルシステムの負荷が高くなる場合に実行してください。バックアップ時のファイルシステムでのより多くのアクティビティーが発生するため、バックアップ破損のリスクが高くなります。
  3. dump ユーティリティーを使用して、パーティションのコンテンツのバックアップを作成します。
    # dump -0uf backup-file /dev/device
    backup-file を、バックアップを保存するファイルへのパスに置き換えます。device を、バックアップを作成する ext4 パーティションの名前に置き換えます。バックアップしたパーティションとは異なるパーティションにマウントされたディレクトリーにバックアップを保存するようにしてください。

    例5.2 複数の ext4 パーティションのバックアップ

    /dev/sda1、/dev/sda 2、および /dev/sda3 パーティションのコンテンツを、/ backup-files/ ディレクトリーに保存されているバックアップファイルにバックアップするには、以下のコマンドを使用します。
    # dump -0uf /backup-files/sda1.dump /dev/sda1
    # dump -0uf /backup-files/sda2.dump /dev/sda2
    # dump -0uf /backup-files/sda3.dump /dev/sda3
    リモートバックアップを実行するには、ssh ユーティリティー を使用するか、パスワードなしの ssh ログインを設定します。ssh およびパスワードレスログインの詳細は、『『システム管理者のガイド』』の「Using the ssh Utility」および「Using Key-based Authentication」を参照してください。
    たとえば、ssh を使用する場合には、以下のようになります

    例5.3 sshを使用したリモートバックアップの実行

    # dump -0u -f - /dev/device | ssh root@remoteserver.example.com dd of=backup-file
    標準のリダイレクトを使用する場合は、- f オプション を個別に渡す必要があります。

関連情報

  • 詳細は、dump(8) の man ページを参照してください。

5.5. ext2、ext3、または ext4 ファイルシステムの復元

この手順では、ファイルバックアップから ext4、ext3、または ext2 ファイルシステムを復元する方法を説明します。

前提条件

手順5.2 ext2、ext3、または ext4 ファイルシステムの復元

  1. オペレーティングシステムのパーティションを復元する場合は、システムをレスキューモードで起動します。『 システム管理者のガイド』の「レスキューモードへの起動」セクションを参照してください』。
    このステップは、通常のデータパーティションには必要ありません。
  2. fdisk または parted ユーティリティを使用して、復元するパーティションを再構築します。
    パーティションが存在しない場合は再作成します。新しいパーティションは、復元されたデータを格納するのに十分な大きさである必要があります。開始番号と終了番号を取得することが重要になります。これらは、バックアップ時に fdisk ユーティリティーから取得したパーティションの開始および終了セクター番号になります。
    パーティションの変更に関する詳細は、13章Partitions を参照してください。
  3. mkfs ユーティリティーを使用して、宛先パーティションをフォーマットします。
    # mkfs.ext4 /dev/device
    重要
    バックアップファイルを格納するパーティションをフォーマット しないでください
  4. 新しいパーティションを作成した場合は、すべてのパーティションにラベルを再設定し、/etc/fstab ファイルのエントリーと一致するようにします
    # e2label /dev/device ラベル
  5. 一時的なマウントポイントを作成し、そのマウントポイントにパーティションをマウントします。
    # mkdir /mnt/device
    # mount -t ext4 /dev/device /mnt/device
  6. マウントされたパーティションのバックアップからデータを復元します。
    # cd /mnt/device
    # restore -rf device-backup-file
    リモートマシンで復元したり、リモートホストに保存されているバックアップファイルから復元したりする場合は、ssh ユーティリティー を使用できます。ssh の詳細は、『『システム管理者のガイド』』の「Using the ssh Utility」セクションを参照してください。
    以下のコマンドには、パスワードを使用しないログインを設定する必要があることに注意してください。パスワードレス ssh ログインの設定に関する詳細は、『『システム管理者のガイド』』の「Using Key-based Authentication」のセクションを参照してください。
    • 同じマシンに保存されているバックアップファイルから、リモートマシンでパーティションを復元するには、以下を行います。
      # ssh remote-address "cd /mnt/device && cat backup-file | /usr/sbin/restore -r -f -"
    • 別のリモートマシンに保存されているバックアップファイルから、リモートマシンでパーティションを復元するには、以下を行います。
      # ssh remote-machine-1 "cd /mnt/device && RSH=/usr/bin/ssh /usr/sbin/restore -rf remote-machine-2:backup-file"
  7. reboot:
    # systemctl reboot

例5.4 複数の ext4 パーティションの復元

例5.2「複数の ext4 パーティションのバックアップ」 から /dev/sda1、/dev/sda2、および /dev/sda3 パーティションを復元するには、以下を行います。
  1. fdisk コマンドを使用して、復元するパーティションを再構築します。
  2. 宛先パーティションをフォーマットします。
    # mkfs.ext4 /dev/sda1
    # mkfs.ext4 /dev/sda2
    # mkfs.ext4 /dev/sda3
  3. すべてのパーティションに /etc/fstab ファイルに一致するようにラベルを付けます。
    # e2label /dev/sda1 Boot1
    # e2label /dev/sda2 Root
    # e2label /dev/sda3 Data
  4. 作業ディレクトリーを準備します。
    新しいパーティションをマウントします。
    # mkdir /mnt/sda1
    # mount -t ext4 /dev/sda1 /mnt/sda1
    # mkdir /mnt/sda2
    # mount -t ext4 /dev/sda2 /mnt/sda2
    # mkdir /mnt/sda3
    # mount -t ext4 /dev/sda3 /mnt/sda3
    バックアップファイルが含まれるパーティションをマウントします。
    # mkdir /backup-files
    # mount -t ext4 /dev/sda6 /backup-files
  5. バックアップからマウントされたパーティションにデータを復元します。
    # cd /mnt/sda1
    # restore -rf /backup-files/sda1.dump
    # cd /mnt/sda2
    # restore -rf /backup-files/sda2.dump
    # cd /mnt/sda3
    # restore -rf /backup-files/sda3.dump
  6. reboot:
    # systemctl reboot

関連情報

  • 詳細は、restore(8) の man ページを参照してください。

5.6. その他の ext4 ファイルシステムユーティリティー

Red Hat Enterprise Linux 7 は、ext4 ファイルシステムを管理するその他のユーティリティーも特長としています。
e2fsck
ext4 ファイルシステムの修復に使用します。このツールは、ext4 ディスク構造の更新により、ext3 よりも ext4 ファイルシステムをより効率的に確認および修復します。
e2label
ext4 ファイルシステムのラベルを変更します。このツールは、ext2 ファイルシステムおよび ext3 ファイルシステムでも機能します。
quota
ext4 ファイルシステムのユーザーおよびグループによるディスク領域(ブロック)およびファイル(inode)の使用に対する制御とレポート。quota の使用に関する詳細は、man quota および 「ディスククォータの設定」 を参照してください。
fsfreeze
ファイルシステムへのアクセスを一時停止するには、コマンド # fsfreeze -f mount-point を使用してフリーズし、# fsfreeze -u mount-point to unfreeze に設定します。これにより、ファイルシステムへのアクセスが停止され、ディスクに安定したイメージを作成します。
注記
device-mapper ドライブに fsfreeze を使用する必要はありません。
詳細は、fsfreeze(8) man ページを参照してください。
「ext4 ファイルシステムのマウント」 にあるように、tune2fs ユーティリティーは、ext2、ext3、および ext4 ファイルシステムの設定可能なファイルシステムパラメーターも調整できます。さらに、以下のツールは、ext4 ファイルシステムのデバッグおよび分析にも役立ちます。
debugfs
ext2、ext3、または ext4 のファイルシステムをデバッグします。
e2image
重要な ext2、ext3、または ext4 ファイルシステムのメタデータをファイルに保存します。
これらのユーティリティーの詳細は、それぞれの man ページを参照してください。

第6章 Btrfs (テクノロジープレビュー)

注記
Btrfs は、Red Hat Enterprise Linux 7 ではテクノロジープレビューとして利用できますが、Red Hat Enterprise Linux 7.4 リリース以降では非推奨になりました。Red Hat Enterprise Linux の将来のメジャーリリースで削除される予定です。
詳細は、『Red Hat Enterprise Linux 7.4 リリースノート』の「非推奨の機能」を参照してください。
Btrfs は次世代 Linux ファイルシステムで、高度な管理、信頼性、および拡張性機能を提供します。これは、スナップショット、圧縮、統合デバイス管理において一意です。

6.1. btrfs ファイルシステムの作成

基本的な btrfs ファイルシステムを作成するには、以下のコマンドを使用します。
# mkfs.btrfs /dev/device
デバイスが追加された btrfs ファイルシステムの作成、およびメタデータとデータのマルチデバイスプロファイルの指定に関する詳細は、「複数のデバイスの統合ボリューム管理」 を参照してください。

6.2. btrfs ファイルシステムのマウント

btrfs ファイルシステムにデバイスをマウントするには、以下のコマンドを使用します。
# mount /dev/device /mount-point
その他の便利なマウントオプションは、以下のとおりです。
device=/dev/name
mount コマンドにこのオプションを追加すると、名前付きデバイスを btrfs ボリュームをスキャンするように btrfs に指示します。これは、btrfs ではないマウントデバイスの試行によりマウントに失敗するため、マウントが正常に実行されるようにするために使用されます。
注記
これは、すべてのデバイスがファイルシステムに追加されるわけではなく、スキャンのみをスキャンします。
max_inline=number
このオプションを使用して、メタデータの B-tree リーフ内のインラインデータに使用可能な領域の最大量(バイト単位)を設定します。デフォルトは 8192 バイトです。4k ページの場合、リーフに収まる必要のある追加のヘッダーにより 3900 バイトに制限されます。
alloc_start=number
このオプションを使用して、ディスクの割り当て開始場所を設定します。
thread_pool=number
このオプションは、割り当てられたワーカースレッドの数を割り当てます。
破棄
このオプションを使用して、解放したブロックで discard/TRIM を有効にします。
noacl
ACL の使用を無効にするには、このオプションを使用します。
space_cache
このオプションを使用して、空きスペースデータをディスクに保存して、ブロックグループをより迅速にキャッシュさせます。これは永続的な変更であり、古いカーネルでブートしても安全です。
nospace_cache
このオプションを使用して、上記の space_cache を無効にします。
clear_cache
このオプションは、マウント中にすべての空き領域キャッシュを消去します。これは安全なオプションですが、再構築するスペースキャッシュをトリガーします。したがって、再構築プロセスを終了するには、ファイルシステムをマウントしたままにしておきます。このマウントオプションは、1 回のみ使用することを目的としています。これは、空き領域で問題がある場合に限り使用します。
enospc_debug
このオプションは、「空白なし」の問題をデバッグするために使用されます。
recovery
このオプションは、マウント時に自動回復を有効にします。

6.3. btrfs ファイルシステムのサイズ変更

btrfs ファイルシステムのサイズを変更することはできませんが、使用している各デバイスのサイズを変更できます。使用中のデバイスが 1 つしかない場合は、ファイルシステムのサイズ変更と同じものになります。複数のデバイスが使用されている場合は、必要な結果を得るために手動でサイズを変更する必要があります。
注記
ユニットサイズはケース固有ではなく、G または g を GiB にも受け入れます。
このコマンドは、ペタバイトの場合は t を受け入れません。k、m、および g のみを受け入れます。

btrfs ファイルシステムの無効化

1 つのデバイスでファイルシステムを拡大するには、以下のコマンドを使用します。
# btrfs filesystem resize amount /mount-point
以下に例を示します。
# btrfs filesystem resize +200M /btrfssingle
Resize '/btrfssingle' of '+200M'
マルチデバイスファイルシステムを拡大するには、拡大するデバイスを指定する必要があります。まず、指定したマウントポイントに btrfs ファイルシステムがあるデバイスをすべて表示します。
# btrfs filesystem show /mount-point
以下に例を示します。
# btrfs filesystem show /btrfstest
Label: none  uuid: 755b41b7-7a20-4a24-abb3-45fdbed1ab39
	Total devices 4 FS bytes used 192.00KiB
	devid    1 size 1.00GiB used 224.75MiB path /dev/vdc
	devid    2 size 524.00MiB used 204.75MiB path /dev/vdd
	devid    3 size 1.00GiB used 8.00MiB path /dev/vde
	devid    4 size 1.00GiB used 8.00MiB path /dev/vdf

Btrfs v3.16.2
次に、拡大するデバイスの devid を特定した後に、以下のコマンドを使用します。
# btrfs filesystem resize devid:amount /mount-point
以下に例を示します。
# btrfs filesystem resize 2:+200M /btrfstest
Resize '/btrfstest/' of '2:+200M'
注記
量は、指定した ではなく max にすることもできます。これは、デバイス上の残りの空き領域をすべて使用します。

btrfs ファイルシステムの縮小

1 つのデバイスでファイルシステムを縮小するには、以下のコマンドを使用します。
# btrfs filesystem resize amount /mount-point
以下に例を示します。
# btrfs filesystem resize -200M /btrfssingle
Resize '/btrfssingle' of '-200M'
マルチデバイスファイルシステムを縮小するには、縮小するデバイスを指定する必要があります。まず、指定したマウントポイントに btrfs ファイルシステムがあるデバイスをすべて表示します。
# btrfs filesystem show /mount-point
以下に例を示します。
# btrfs filesystem show /btrfstest
Label: none  uuid: 755b41b7-7a20-4a24-abb3-45fdbed1ab39
	Total devices 4 FS bytes used 192.00KiB
	devid    1 size 1.00GiB used 224.75MiB path /dev/vdc
	devid    2 size 524.00MiB used 204.75MiB path /dev/vdd
	devid    3 size 1.00GiB used 8.00MiB path /dev/vde
	devid    4 size 1.00GiB used 8.00MiB path /dev/vdf

Btrfs v3.16.2
次に、縮小するデバイスの devid を特定した後に、以下のコマンドを使用します。
# btrfs filesystem resize devid:amount /mount-point
以下に例を示します。
# btrfs filesystem resize 2:-200M /btrfstest
Resize '/btrfstest' of '2:-200M'

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

1 つのデバイスでファイルシステムを特定のサイズに設定するには、以下のコマンドを使用します。
# btrfs filesystem resize amount /mount-point
以下に例を示します。
# btrfs filesystem resize 700M /btrfssingle
Resize '/btrfssingle' of '700M'
マルチデバイスファイルシステムのファイルシステムのサイズを設定するには、変更するデバイスを指定する必要があります。まず、指定したマウントポイントに btrfs ファイルシステムがあるデバイスをすべて表示します。
# btrfs filesystem show /mount-point
以下に例を示します。
# btrfs filesystem show /btrfstest
Label: none  uuid: 755b41b7-7a20-4a24-abb3-45fdbed1ab39
	Total devices 4 FS bytes used 192.00KiB
	devid    1 size 1.00GiB used 224.75MiB path /dev/vdc
	devid    2 size 724.00MiB used 204.75MiB path /dev/vdd
	devid    3 size 1.00GiB used 8.00MiB path /dev/vde
	devid    4 size 1.00GiB used 8.00MiB path /dev/vdf

Btrfs v3.16.2
次に、変更するデバイスの devid を特定した後に、以下のコマンドを使用します。
# btrfs filesystem resize devid:amount /mount-point
以下に例を示します。
# btrfs filesystem resize 2:300M /btrfstest
Resize '/btrfstest' of '2:300M'

6.4. 複数のデバイスの統合ボリューム管理

btrfs ファイルシステムは、多くのデバイスに作成でき、ファイルシステムの作成後にさらにデバイスを追加できます。デフォルトでは、メタデータは 2 つのデバイスにミラーリングされ、データはすべてのデバイスにストライプ化されますが、デバイスが 1 つしか存在する場合は、そのデバイスでメタデータが複製されます。

6.4.1. 複数のデバイスを持つファイルシステムの作成

「btrfs ファイルシステムの作成」 で説明する mkfs.btrfs コマンドは、データ用の -d オプション、およびメタデータに -m を受け入れます。有効な仕様は以下のとおりです。
  • raid0
  • raid1
  • raid10
  • dup
  • single
-m single オプションは、メタデータの重複がないよう指示します。これは、ハードウェア RAID を使用する場合に推奨されます。
注記
RAID 10 では、少なくとも 4 つのデバイスを正常に実行する必要があります。

例6.1 RAID 10 btrfs ファイルシステムの作成

4 つのデバイスにファイルシステムを作成します(metadata はミラーリングされ、データのストライプ化)。
# mkfs.btrfs /dev/device1 /dev/device2 /dev/device3 /dev/device4
ミラーリングなしでメタデータをストライプします。
# mkfs.btrfs -m raid0 /dev/device1 /dev/device2
データとメタデータの両方に RAID10 を使用します。
# mkfs.btrfs -m raid10 -d raid10 /dev/device1 /dev/device2 /dev/device3 /dev/device4
1 つのドライブでメタデータを複製しないでください。
# mkfs.btrfs -m single /dev/device
ドライブが異なる場合は、ドライブの全容量を使用する場合には 、1 つの オプションを使用してください。
# mkfs.btrfs -d single /dev/device1 /dev/device2 /dev/device3
作成したマルチデバイスファイルシステムに新規デバイスを追加するには、以下のコマンドを使用します。
# btrfs device add /dev/device1 /mount-point
btrfs モジュールを再起動または再読み込みしたら、btrfs デバイススキャン コマンドを使用して、すべての複数デバイスファイルシステムを検出します。詳細は、「btrfs デバイスのスキャン」 を参照してください。

6.4.2. btrfs デバイスのスキャン

btrfs デバイススキャン を使用して、/dev 下のすべてのブロックデバイスをスキャンし、btrfs ボリューム用にプローブします。これは、ファイルシステム内で複数のデバイスで実行している場合は、btrfs モジュールをロードした後に実行する必要があります。
すべてのデバイスをスキャンするには、次のコマンドを実行します。
# btrfs device scan
単一デバイスをスキャンするには、以下のコマンドを使用します。
# btrfs device scan /dev/device

6.4.3. btrfs ファイルシステムへの新規デバイスの追加

btrfs の filesystem show コマンドを使用して、すべての btrfs ファイルシステムと、含まれるデバイスを一覧表示します。
btrfs device add コマンドは、マウントされたファイルシステムに新しいデバイスを追加するために使用されます。
btrfs ファイルシステムの balance コマンドは、既存のすべてのデバイスに割り当てられたエクステントをすべて分散(トリッピング)します。
新しいデバイスを追加するコマンドはすべて、以下のとおりです。

例6.2 btrfs ファイルシステムへの新規デバイスの追加

まず、btrfs ファイルシステムを作成してマウントします。btrfs ファイルシステムの作成に関する詳細は 「btrfs ファイルシステムの作成」 を、btrfs ファイルシステムのマウント方法に関する詳細は 「btrfs ファイルシステムのマウント」 を参照してください。
# mkfs.btrfs /dev/device1
# mount /dev/device1
次に、マウントされた btrfs ファイルシステムに 2 番目のデバイスを追加します。
# btrfs device add /dev/device2 /mount-point
これらのデバイスのメタデータとデータは、引き続き /dev/device1 に保存されます。すべてのデバイスに分散するには、バランスを取る必要があります。
# btrfs filesystem balance /mount-point
ファイルシステムのすべてのデータとメタデータを読み込み、新しいデバイスに書き込みを行うため、ファイルシステムの分散には多少時間がかかります。

6.4.4. btrfs ファイルシステムの変換

非 RAID ファイルシステムを raid に変換するには、デバイスを追加し、チャンク割り当てプロファイルを変更する balance フィルターを実行します。

例6.3 btrfs ファイルシステムの変換

今回の例では、既存の単一デバイスシステム(/dev/sdb 1)を、1 つのディスク障害から保護するために raid1 システム の 2 つのデバイスに変換するには、次のコマンドを使用します。
# mount /dev/sdb1 /mnt
# btrfs device add /dev/sdc1 /mnt
# btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt
重要
メタデータがシングルデバイスのデフォルトから変換されない場合は、DUP のままになります。これは、ブロックのコピーが別々のデバイスにあることを保証するものではありません。データが変換されていない場合、冗長コピーはありません。

6.4.5. btrfs デバイスの削除

btrfs device delete コマンドを使用して、オンラインデバイスを削除します。安全に削除するために、使用中のエクステントをファイルシステム内の他のデバイスに再配布します。

例6.4 btrfs ファイルシステム上のデバイスの削除

まず、いくつかの btrfs ファイルシステムを作成してマウントします。
# mkfs.btrfs /dev/sdb /dev/sdc /dev/sdd /dev/sde
# mount /dev/sdb /mnt
ファイルシステムに一部のデータを追加します。
最後に、必要なデバイスを削除します。
# btrfs device delete /dev/sdc /mnt

6.4.6. btrfs ファイルシステムでの障害が発生したデバイスの置き換え

スーパーブロックを引き続き読み取ることができる場合は、障害が発生したデバイスを削除するために 「btrfs デバイスの削除」 を使用できます。ただし、デバイスが見つからないか、スーパーブロックが破損している場合は、ファイルシステムを degraded モードでマウントする必要があります。
# mkfs.btrfs -m raid1 /dev/sdb /dev/sdc /dev/sdd /dev/sde


  ssd is destroyed or removed, use -o degraded to force the mount
  to ignore missing devices


# mount -o degraded /dev/sdb /mnt


  'missing' is a special device name


# btrfs device delete missing /mnt
btrfs デバイスの削除が欠落している と、ファイルシステムのメタデータが記述されているが、ファイルシステムがマウントされたときに存在しない最初のデバイスが削除されます。
重要
特定の raid レイアウトに必要な最小数のデバイス(見つからないデバイスを含む)を下に移動することはできません。障害が発生したデバイスを削除するために、新しいデバイスを追加する必要がある場合があります。
たとえば、2 つのデバイスを持つ raid1 レイアウトの場合、デバイスに障害が発生した場合は、以下を行います。
  1. 動作が低下したモードでのマウント
  2. 新しいデバイスの追加
  3. 不足しているデバイスの削除

6.4.7. /etc/fstab での btrfs ファイルシステムの登録

initrd がない場合や、btrfs デバイススキャンを実行しない場合は、ファイルシステム内のすべてのデバイスを mount コマンドに渡すことで、マルチボリュームの btrfs ファイルシステムをマウント できます。

例6.5 /etc/fstab エントリーの例

適切な /etc/fstab エントリーの例を以下に示します。
/dev/sdb    /mnt    btrfs    device=/dev/sdb,device=/dev/sdc,device=/dev/sdd,device=/dev/sde    0
UUID (Universally Unique Identifier) の使用も機能し、デバイスパスを使用するよりも安定していることに注意してください。

6.5. SSD の最適化

btrfs ファイルシステムを使用すると SSD を最適化できます。これには 2 つの方法があります。
最初の方法は、指定された単一のデバイスの /sys/block/device/queue/rotational がゼロの場合、mkfs.btrfs が単一のデバイスでのメタデータの複製をオフにすることです。これは、コマンドラインで -m single を指定することと同じです。-m dup オプションを指定することで、メタデータを上書きして複製することができます。SSD ファームウェアは両方のコピーを失う可能性があるため、複製は必要ありません。これはスペースを浪費し、パフォーマンスが犠牲になります。
2 つ目の方法は、SSD マウントオプションのグループ (ssdnossd、および ssd_spread) を使用することです。
ssd オプションは、以下のようにいくつかのことを行います。
  • より大きなメタデータのクラスターの割り当てを許可します。
  • 可能な場合は、より順序立ててデータを割り当てます。
  • 鍵とブロック順序に一致するように btree リーフの書き換えを無効にします。
  • 複数のプロセスをバッチ処理せずにログフラグメントをコミットします。
注記
ssd マウントオプションは、ssd オプションのみを有効にします。nossd オプションを使用して無効にします。
一部の SSD は、ブロック数を再利用する際に最適に実行する一方で、クラスタリングが未使用領域の大きいチャンクを厳密に割り当てる場合は、はるかに改善します。デフォルトでは、mount -o ssd はブロックのグループを検索します。このブロックには、ブロックが混在する可能性がある空きブロックがいくつかあります。mount -o ssd_spread コマンドにより、割り当て済みのブロックが混同されないようにします。これにより、ローエンド SSD のパフォーマンスが向上します。
注記
ssd_spread オプションを使用すると、ssd オプションと ssd_spread オプションの両方が有効になります。nossd を使用して、これら両方のオプションを無効にします。
ssd オプションが提供されておらず、いずれのデバイスも提供していない場合でも、ssd_spread オプションは自動的に設定されません。
これらのオプションはすべて特定のビルドでテストして、SSD ファームウェアとアプリケーションの読み込みの各組み合わせが異なるため、使用を改善または縮小するかどうかを確認してください。

6.6. Btrfs リファレンス

man ページの btrfs(8) は、重要なすべての管理コマンドを説明します。特に以下のものが含まれます。
  • スナップショットを管理するためのすべてのサブボリュームコマンド。
  • デバイスを管理するための device コマンド。
  • scrub コマンド、balance コマンド、および defragment コマンド。
man ページの mkfs.btrfs(8) には、btrfs ファイルシステムの作成に関する情報が含まれています。これには、そのシステムに関するすべてのオプションが含まれます。
btrfs システムの fsck の詳細は、man ページの btrfsck(8) を参照してください。

第7章 Global File System 2

Red Hat Global File System 2(GFS2)は、Linux カーネルファイルシステムインターフェース(VFS レイヤー)に直接インターフェースするネイティブファイルシステムです。クラスターファイルシステムとして実装すると、GFS2 は分散メタデータと複数のジャーナルを採用します。
GFS2 は、理論的には 8 エクサバイトのファイルシステムに対応できる 64 ビットアーキテクチャーに基づいています。ただし、現在対応している GFS2 ファイルシステムの最大サイズは 100 TB です。システムで 100 TB を超える GFS2 ファイルシステムが必要な場合は、Red Hat サービスの担当者にお問い合わせください。
ファイルシステムのサイズを決定する際には、その復旧のニーズを考慮してください。非常に大きなファイルシステムで fsck コマンドを実行すると、長い時間がかかり、大量のメモリーを消費する可能性があります。また、ディスクまたはディスクサブシステムに障害が発生した場合、復旧時間はバックアップメディアの速度によって制限されます。
Red Hat Cluster Suite で設定する場合、Red Hat GFS2 ノードは Red Hat Cluster Suite 設定および管理ツールを使用して、設定および管理できます。Red Hat GFS2 は、Red Hat クラスターの GFS2 ノード間でデータ共有を提供します。これにより、GFS2 ノード全体でファイルシステム名前空間の単一一貫性のあるビューを利用できます。これにより、異なるノード上のプロセスは、同じノード上のプロセスがローカルファイルシステム上のファイルを共有できるのと同じ方法で GFS2 ファイルを共有でき、それでも異なる違いはありません。Red Hat Cluster Suite に関する情報は、『Red Hat の 『クラスター管理』 』ガイドを参照してください。
GFS2 は、リニアボリュームまたはミラーリングされたボリュームである論理ボリューム(LVM で作成)に構築する必要があります。Red Hat Cluster スイートの LVM で作成した論理ボリュームは、CLVM デーモン clvmd により有効化され、Red Hat Cluster Suite クラスターで実行します。このデーモンにより、LVM2 を使用してクラスター全体で論理ボリュームの管理が可能となり、クラスター内のすべてのノードで論理ボリュームを共有できるようになります。論理ボリュームマネージャーの詳細は、Red Hat の『Logical Volume Manager Administration』ガイドを参照してください。
gfs2.ko カーネルモジュールは GFS2 ファイルシステムを実装しており、GFS2 クラスターノードにロードされます。
クラスター化ストレージおよび非クラスター化ストレージでの GFS2 ファイルシステムの作成および設定に関する包括的な情報は、Red Hat の『Global File System 2』ガイドを参照してください。

第8章 Network File System (NFS)

ネットワークファイルシステム (NFS)により、リモートホストはネットワーク経由でファイルシステムをマウントでき、そのファイルシステムをローカルにマウントされているかのように対話できます。これにより、システム管理者は、リソースをネットワーク上の集中化サーバーに統合できるようになります。
本章では、基本的な NFS の概念および補足情報について説明します。

8.1. NFS の概要

現在、Red Hat Enterprise Linux には NFS のメジャーバージョンが 2 つあります。
  • NFS バージョン 3(NFSv3)は安全な非同期書き込みに対応し、以前の NFSv2 よりもエラー処理において堅牢です。64 ビットのファイルサイズとオフセットにも対応し、クライアントは 2 GB を超えるファイルデータにアクセスできます。
  • NFS バージョン 4(NFSv4)は、ファイアウォールとインターネットを介して動作し、rpcbind サービスが不要になり、ACL に対応し、ステートフルな操作を利用します。
Red Hat Enterprise Linux 7.4 リリース以降、Red Hat Enterprise Linux 4.2(NFSv4.2)は、NFS バージョン 4.2(NFSv4.2)を完全にサポートします。
以下は、Red Hat Enterprise Linux における NFSv4.2 の機能です。
  • sparse Files: ファイルの領域効率を検証し、プレースホルダーがストレージの効率を向上できるようにします。これは、1 つ以上のホールを持つファイルです。ホールとは、割り当てられていない、またはゼロのみで構成される未初期化データブロックです。lseek() NFSv4.2 の操作は seek_hole() および seek_data() をサポートし、これによりアプリケーションはスパースファイルのホールの場所をマップできます。
  • Space Reservation: ストレージサーバーが空き領域を予約することを許可します。これにより、サーバーで領域が不足することができなくなります。NFSv4.2 は、領域を予約するための allocate() 操作、領域の予約を解除するための deallocate() 操作、およびファイル内の領域の事前割り当てまたは割り当て解除を行う fallocate() 操作に対応します。
  • ラベル付き NFS: データアクセス権を実施し、NFS ファイルシステムの個々のファイルに対して、クライアントとサーバー間の SELinux ラベルを有効にします。
  • レイアウトの機能強化: NFSv4.2 では、クライアントがレイアウトとの通信に関してメタデータサーバーに通知するために使用する新しい操作 layoutstats() が提供されます。
7.4 よりも前のバージョンの Red Hat Enterprise Linux は、バージョン 4.1 まで NFS をサポートします。
NFSv4.1 の機能は次のとおりです。
  • ネットワークのパフォーマンスおよびセキュリティーを強化し、Parallel NFS(pNFS)のクライアント側サポートも含みます。
  • コールバックに個別の TCP 接続を必要としなくなりました。これにより、クライアントと通信できない場合でも NFS サーバーは委任を許可できます。たとえば、NAT またはファイアウォールが干渉する場合などです。
  • これは 1 回のセマンティクスを提供します(再起動操作を除く)。これにより、応答が失われ、操作が 2 回送信された場合に特定の操作が不正確な結果を返す可能性がある以前の問題を防ぐことができます。
NFS クライアントはデフォルトで NFSv4.1 を使用してマウントを試行し、サーバーが NFSv4.1 に対応していない場合は NFSv4.0 にフォールバックします。サーバーが NFSv4.0 に対応していない場合、マウントは後で NFSv3 にフォールバックします。
注記
NFS バージョン 2 (NFSv2) は、Red Hat のサポート対象外になりました。
NFS のすべてのバージョンは、IP ネットワークで実行中のTCP( Transmission Control Protocol )を使用でき、NFSv4 でそれを要求することができます。NFSv3 は、IP ネットワーク上で実行されている UDP( User Datagram Protocol )を使用して、クライアントとサーバー間のステートレスネットワーク接続を提供できます。
UDP で NFSv3 を使用する場合、ステートレス UDP 接続(通常の状態以下)のプロトコルオーバーヘッドは TCP よりも低くなります。これにより、非常にクリーンなネットワークでは、パフォーマンスが良くなります。ただし、UDP はステートレスであるため、サーバーが予期せず停止した場合、UDP クライアントはサーバーの要求でネットワークを特長とし続けます。さらに、UDP でフレームが失われた場合、RPC 要求全体を再送信する必要があります。TCP は、失われたフレームのみを再送する必要があります。このような理由により、TCP は NFS サーバーへの接続時に推奨されるプロトコルです。
NFSv4 プロトコルには、マウントとロックのプロトコルが組み込まれています。サーバーは、既知の TCP ポート 2049 もリッスンします。したがって、NFSv4 は rpcbindと対話する必要はありません。[1]lockd、および rpc.statd デーモン。rpc.mountd デーモンは、エクスポートを設定するために NFS サーバーで引き続き必要ですが、ネットワーク上の操作には関与しません。
注記
TCP は、Red Hat Enterprise Linux 下の NFS バージョン 3 のデフォルトのトランスポートプロトコルです。UDP は必要に応じて互換性の目的で使用できますが、幅広く使用することは推奨されません。NFSv4 には TCP が必要です。
すべての RPC/NFS デーモンには、ポートの設定が可能な 「-p」 コマンドラインオプションがあり、ファイアウォールの設定がより容易になります。
TCP ラッパーがクライアントへのアクセス権限を付与すると、NFS サーバーは /etc/exports 設定ファイルを参照して、エクスポートしたファイルシステムにアクセスできるかどうかを確認します。アクセスが可能なことが確認されると、そのユーザーは、ファイルおよびディレクトリーへの全操作を行えるようになります。
重要
NFS がファイアウォールを有効にして Red Hat Enterprise Linux のデフォルトインストールと連携するには、デフォルトの TCP ポート 2049 で IPTables を設定します。適切な IPTable 設定がないと、NFS が適切に機能しなくなります。
NFS の初期化スクリプトと rpc.nfsd プロセスにより、システムの起動時に、指定したポートにバインドできるようになりました。ただし、これはポートが利用できない場合にはエラーになるか、別のデーモンとの競合が発生する可能性があります。

8.1.1. 必要なサービス

Red Hat Enterprise Linux は、カーネルレベルのサポートとデーモンプロセスの組み合わせを使用して、NFS ファイル共有を提供します。すべての NFS バージョンは、クライアントとサーバー間の Remote Procedure Calls (RPC) に依存します。Red Hat Enterprise Linux 7 での RPC サービスは、rpcbind サービスによって制御されます。NFS ファイルシステムの共有やマウントには、実装されている NFS のバージョンに応じて、次のようなサービスが連携して動作することになります。
注記
Red Hat Enterprise Linux の以前のバージョンにおける RPC プログラム番号を IP アドレスポート番号とマッピングするのに portmap サービスが使用されました。このサービスは、Red Hat Enterprise Linux 7 の rpcbind に置き換え、IPv6 への対応が可能になりました。
nfs
systemctl start nfs は NFS サーバーを起動し、共有 NFS ファイルシステムのリクエストに対応する適切な RPC プロセスを実行します。
nfslock
systemctl start nfs-lock は、該当する RPC プロセスを開始する必須サービスをアクティブにし、NFS クライアントがサーバー上のファイルをロックできるようにします。
rpcbind
rpcbind は、ローカルの RPC サービスからのポート予約を受け入れます。その後、これらのポートは、対応するリモートの RPC サービスによりアクセス可能であることが公開されます。rpcbind は、RPC サービスの要求に応答し、要求された RPC サービスへの接続を設定します。このプロセスは NFSv4 では使用されません。
以下の RPC プロセスは、NFS サービスを容易にします。
rpc.mountd
NFS サーバーは、このプロセスを使用して NFSv3 クライアントの MOUNT 要求を処理します。要求されている NFS 共有が現在 NFS サーバーによりエクスポートされているか、またその共有へのクライアントのアクセスが許可されているかを確認します。マウント要求が許可されると、rpc.mountd サーバーは Success ステータスで応答し、この NFS 共有の File-Handle を NFS クライアントに戻します。
rpc.nfsd
rpc.nfsd は、サーバーが公開している明示的な NFS のバージョンとプロトコルを定義できます。NFS クライアントが接続するたびにサーバースレッドを提供するなど、NFS クライアントの動的な要求に対応するため、Linux カーネルと連携して動作します。このプロセスは、nfs サービスに対応します。
lockd
lockd は、クライアントとサーバーの両方で実行するカーネルスレッドです。Network Lock Manager (NLM)プロトコルを実装し、これにより、NFSv3 クライアントがサーバー上のファイルをロックできるようになります。NFS サーバーが実行中で、NFS ファイルシステムがマウントされていれば、このプロセスは常に自動的に起動します。
rpc.statd
このプロセスは、Network Status Monitor (NSM)RPC プロトコルを実装します。NFS サーバーが正常に停止せずに再起動されると NFS クライアントに通知します。rpc.statdnfslock サービスが自動的に起動するため、ユーザー設定は必要ありません。このプロセスは NFSv4 では使用されません。
rpc.rquotad
このプロセスは、リモートユーザーのユーザークォーター情報を提供します。rpc.rquotadnfs サービスにより自動的に起動するため、ユーザー設定は必要ありません。
rpc.idmapd
rpc.idmapd は NFSv4 クライアントとサーバーのアップコールを提供します。これは、ネットワーク上の NFSv4 名( user@domainの形式の文字列)とローカルの UID と GID 間のマッピング間のマッピングです。NFSv4 で idmapd が機能するには、/etc/idmapd.conf ファイルを設定する必要があります。少なくとも、NFSv4 マッピングドメインを定義する "Domain" パラメーターを指定する必要があります。NFSv4 マッピングドメインが DNS ドメイン名と同じ場合は、このパラメーターは必要ありません。クライアントとサーバーが ID マッピングの NFSv4 マッピングドメインに合意しないと、適切に動作しません。
注記
Red Hat Enterprise Linux 7 では、NFSv4 サーバーのみが rpc.idmapd を使用します。NFSv4 クライアントは、キーリングベースの idmapper nfsidmap を使用します。nfsidmap は、ID マッピングを実行するためにオンデマンドでカーネルによって呼び出されるスタンドアロンプログラムです。nfsidmap に問題がある場合は、クライアントが rpc.idmapd の使用にフォールバックします。nfsidmap の詳細は、man ページの nfsidmap を参照してください。

8.2. NFS クライアントの設定

mount コマンドは、クライアント側に NFS 共有をマウントします。形式は以下のようになります。
# mount -t nfs -o options server:/remote/export /local/directory
このコマンドは、以下のような変数を使用します。
オプション
マウントオプションのカンマ区切りリスト。有効な NFS マウントオプションの詳細は、「一般的な NFS マウントオプション」 を参照してください。
server
マウントするファイルシステムをエクスポートするサーバーのホスト名、IP アドレス、または完全修飾ドメイン名
/remote/export
サーバー からエクスポートされるファイルシステムまたはディレクトリー、つまり、マウントするディレクトリー
/local/directory
/remote/export がマウントされているクライアントの場所
Red Hat Enterprise Linux 7 で使用される NFS プロトコルのバージョンは、mount オプションの nfsvers または vers で識別されます。デフォルトでは、mount は、mount -t nfs で NFSv4 を使用します。サーバーが NFSv4 に対応していない場合は、クライアントはサーバーがサポートしているバージョンに自動的にステップダウンします。サーバーでサポートされていない特定のバージョンを渡すために nfsvers/vers オプションを使用した場合、マウントに失敗します。レガシーの理由により、ファイルシステムタイプ nfs4 も利用可能です。これは、mount -t nfs -o nfsvers=4 host:/remote/export /local/directory を実行することと同じになります。
詳細は man mount を参照してください。
NFS 共有が手動でマウントされた場合は、再起動時に共有は自動的にマウントされません。Red Hat Enterprise Linux は、システムの起動時にリモートファイルシステムを自動的にマウントする方法( /etc/fstab ファイルおよび autofs サービス)を提供します。詳細は、/etc/fstab を使用した NFS ファイルシステムのマウント」 および autofs を参照してください。

8.2.1. /etc/fstab を使用した NFS ファイルシステムのマウント

別のマシンから NFS 共有をマウントする別の方法は、/etc/fstab ファイルに行を追加することです。この行は、NFS サーバーのホスト名、エクスポートされているサーバーのディレクトリー、NFS 共有がマウントされるローカルマシンのディレクトリーを指定する必要があります。/etc/fstab ファイルを変更するには、root でなければなりません。

例8.1 構文の例

/etc/fstab の行の一般的な構文は以下の通りです。
server:/usr/local/pub    /pub   nfs    defaults 0 0
このコマンドを実行する前に、マウントポイント /pub がクライアントマシンに存在している必要があります。この行をクライアントシステムの /etc/fstab に追加した後に、コマンド mount /pub を使用すると、マウントポイント /pub がサーバーからマウントされます。
NFS エクスポートをマウントする有効な /etc/fstab エントリーには、以下の情報が含まれている必要があります。
server:/remote/export /local/directory nfs options 0 0
変数 server/remote/export/local/directory、および options は、NFS 共有を手動でマウントする際に使用されるものと同じです。詳細は、「NFS クライアントの設定」 を参照してください。
注記
/etc/fstab を読み取る前に、マウントポイント /local/directory はクライアントに存在している必要があります。それ以外の場合は、マウントに失敗します。
/etc/fstab の編集後に、システムが新しい設定を登録するようにマウントユニットを再生成します。
# systemctl daemon-reload

関連情報

  • /etc/fstab の詳細は、man fstab を参照してください。

8.3. autofs

/etc/fstab を使用する場合の欠点の 1 つは、NFS マウントされたファイルシステムにユーザーがアクセスする頻度に関わらず、マウントされたファイルシステムを所定の場所で維持するために、システムがリソースを割り当てる必要があることです。これは 1 つまたは 2 つのマウントでは問題になりませんが、システムが一度に多くのシステムへのマウントを維持している場合、システム全体のパフォーマンスに影響を与える可能性があります。/etc/fstab に代わるのは、カーネルベースの automount ユーティリティーを使用することです。自動マウント機能は以下の 2 つのコンポーネントで構成されます。
  • ファイルシステムを実装するカーネルモジュール
  • 他のすべての機能を実行するユーザー空間デーモン
automount ユーティリティーは、NFS ファイルシステムを自動的にマウントおよびアンマウント (オンデマンドマウント) できるため、システムリソースを節約できます。これは、AFS、SMBFS、CIFS、およびローカルファイルシステムを含む他のファイルシステムをマウントするために使用できます。
重要
nfs-utils パッケージは、「NFS ファイルサーバー」と「ネットワークファイルシステムクライアント」グループの両方に含まれるようになりました。そのため、Base グループではデフォルトでインストールされなくなりました。NFS 共有の自動マウントを試みる前に、最初に nfs-utils がシステムにインストールされていることを確認してください。
autofs は、「ネットワークファイルシステムクライアント」グループに含まれます。
autofs は、デフォルトのプライマリー設定ファイルとして /etc/auto.master (マスターマップ) を使用します。これは、autofs 設定( /etc/sysconfig/autofs )を Name Service Switch(NSS)メカニズムとともに使用することで、対応している別のネットワークソースと名前を使用するように変更できます。autofs バージョン 4 デーモンのインスタンスは、マスターマップに設定された各マウントポイントに対して実行されていたため、指定したマウントポイントのコマンドラインから手動で実行することができます。autofs バージョン 5 では、1 つのデーモンを使用して設定済みのマウントポイントをすべて管理できないため、この方法はできません。そのため、すべての自動マウントをマスターマップで設定する必要があります。これは、他の業界標準自動マウント機能 の通常の要件に行に記述されます。マウントポイント、ホスト名、エクスポートされたディレクトリー、およびオプションはすべて、ホストごとに手動で設定するのではなく、一連のファイル(またはサポートされているその他のネットワークソース)で指定できます。

8.3.1. バージョン 4 と比較した autofs バージョン 5 の改善点

autofs バージョン 5 では、バージョン 4 と比較して、以下の機能拡張が行われています。
ダイレクトマップのサポート
autofs のダイレクトマップは、ファイルシステム階層の任意の時点でファイルシステムを自動的にマウントするメカニズムを提供します。ダイレクトマップは、マスターマップの /- のマウントポイントによって示されます。ダイレクトマップのエントリーには、(間接マップで使用される相対パス名の代わりに) 絶対パス名がキーとして含まれています。
レイジーマウントとアンマウントのサポート
マルチマウントマップエントリーは、単一のキーの下にあるマウントポイントの階層を記述します。この良い例として、-hosts マップがあります。これは通常、マルチマウントマップエントリーとして、/net/host の下のホストからのすべてのエクスポートを自動マウントするために使用されます。-hosts マップを使用する場合は、/net/hostls が、host からの各エクスポートの autofs トリガーマウントをマウントします。次に、これらはマウントされ、アクセスされると期限切れとなります。これにより、エクスポートが多数あるサーバーにアクセスする際に必要なアクティブなマウントの数を大幅に減らすことができます。
強化された LDAP サポート
autofs 設定ファイル (/etc/sysconfig/autofs) は、サイトが実装する autofs スキーマを指定するメカニズムを提供するため、アプリケーション自体で試行錯誤してこれを判断する必要がなくなります。さらに、共通の LDAP サーバー実装でサポートされるほとんどのメカニズムを使用して、LDAP サーバーへの認証済みバインドがサポートされるようになりました。このサポートには、新しい設定ファイル (/etc/autofs_ldap_auth.conf) が追加されました。デフォルトの設定ファイルは自己文書化されており、XML 形式を使用します。
Name Service Switch (nsswitch) 設定の適切な使用
Name Service Switch 設定ファイルは、特定の設定データがどこから来るのかを判別する手段を提供するために存在します。この設定の理由は、データにアクセスするための統一されたソフトウェアインターフェイスを維持しながら、管理者が最適なバックエンドデータベースを柔軟に使用できるようにするためです。バージョン 4 の自動マウント機能は、今まで以上に NSS 設定を処理できるようになっていますが、まだ完全ではありません。一方、autofs バージョン 5 は完全な実装です。
このファイルのサポートされる構文の詳細は、man nsswitch.conf を参照してください。すべての NSS データベースが有効なマップソースである訳ではなく、パーサーは無効なデータベースを拒否します。有効なソースは、ファイル、ypnisnisplusldap および hesiod です。
autofs マウントポイントごとの複数のマスターマップエントリー
頻繁に使用されますが、まだ記述されていないのは、直接マウントポイント /- の複数のマスターマップエントリーの処理です。各エントリーのマップキーはマージされ、1 つのマップとして機能します。

例8.2 autofs マウントポイントごとの複数のマスターマップエントリー

以下は、ダイレクトマウントの connectathon テストマップの例です。
/- /tmp/auto_dcthon
/- /tmp/auto_test3_direct
/- /tmp/auto_test4_direct
 

8.3.2. autofs の設定

自動マウント機能の主な設定ファイルは /etc/auto.master です。これは、「バージョン 4 と比較した autofs バージョン 5 の改善点」 で説明されているように変更される可能性のあるマスターマップとも呼ばれます。マスターマップは、システムの autofsで制御されるマウントポイントと、それに対応する設定ファイルまたは自動マウントマップと呼ばれるネットワークソースを一覧表示します。マスターマップの形式は次のとおりです。
mount-point map-name options
この形式で使用されている変数を以下に示します。
mount-point
autofs マウントポイント (例: /home)
map-name
マウントポイントの一覧を含むマップソースの名前、およびマウントポイントがマウントされるファイルシステムの場所。
オプション
指定した場合には、それら自体にオプションが指定されていなければ、指定されたマップ内のすべてのエントリーに適用されます。この動作は、オプションの累積 が含まれる autofs バージョン 4 とは異なります。これは、混合環境の互換性を実装するように変更されました。

例8.3 /etc/auto.master ファイル

以下は、/etc/auto.master ファイルからのサンプル行です( cat /etc/auto.master で表示)。
/home /etc/auto.misc
マップの一般的な形式はマスターマップに似ていますが、マスターマップの場合と同様に、エントリーの末尾ではなく「オプション」と、マウントポイントと場所の間に表示されます。
mount-point   [options]   location
この形式で使用されている変数を以下に示します。
mount-point
これは autofs マウントポイントを参照します。これは 1 つのインダイレクトマウント用の 1 つのディレクトリー名にすることも、複数のダイレクトマウント用のマウントポイントの完全パスにすることもできます。ダイレクトマップおよび間接マップエントリーキー(マウントポイント)の後に、オフセットディレクトリー( /で始まるサブディレクトリー名)のリストが、マルチマウントエントリーと呼ばれるものとなる可能性があります。
オプション
指定した場合は、これらは、独自のオプションを指定しないマップエントリーのマウントオプションになります。
location
これは、ローカルファイルシステムのパス(Sun マップ形式のエスケープ文字 ":" で事前にあり、マップ名が /で始まるマップ名)、NFS ファイルシステムまたはその他の有効なファイルシステムの場所などのファイルシステムの場所を参照します。
以下は、マップファイルのコンテンツの例になります(例: /etc/auto.misc)。
payroll -fstype=nfs personnel:/dev/hda3
sales -fstype=ext3 :/dev/hda4
マップファイルの最初の列は、autofs マウントポイント(personnel と呼ばれるサーバーからのsalespayroll を示します。2 列目は、3 列目は マウント のソースを示しています。任意の設定に従い、autofs マウントポイントは、/home/payroll/home/sales になります-fstype= オプションは省略されることが多く、通常は正しい操作には必要ありません。
ディレクトリーが存在しない場合、自動マウント機能はディレクトリーを作成します。ディレクトリーが存在している状況で自動マウント機能が起動した場合は、自動マウント機能の終了時にディレクトリーが削除されることはありません。
自動マウントデーモンを起動するには、以下のコマンドを使用します。
# systemctl start autofs
自動マウントデーモンを再起動するには、以下のコマンドを使用します。
# systemctl restart autofs
与えられた設定を使用して、プロセスが /home/payroll/2006/July.sxc などのアンマウントされたディレクトリー autofs へのアクセスを要求すると、自動マウントデーモンはディレクトリーを自動的にマウントします。タイムアウトを指定した場合は、タイムアウト期間中ディレクトリーにアクセスしないと、ディレクトリーが自動的にアンマウントされます。
自動マウントデーモンのステータスを表示するには、以下のコマンドを使用します。
# systemctl status autofs

8.3.3. サイト設定ファイルの上書きまたは拡張

クライアントシステムの特定のマウントポイントで、サイトのデフォルトを上書きすることが役に立つ場合があります。たとえば、次の条件を検討します。
  • 自動マウント機能マップは NIS に保存され、/etc/nsswitch.conf ファイルには以下のディレクティブがあります。
    automount:    files nis
  • auto.master ファイルには以下が含まれます。
    +auto.master
  • NIS の auto.master マップファイルに以下が含まれます。
    /home auto.home
  • NIS の auto.home マップには以下が含まれます。
    beth        fileserver.example.com:/export/home/beth
    joe        fileserver.example.com:/export/home/joe
    *       fileserver.example.com:/export/home/&
  • ファイルマップ /etc/auto.home は存在しません。
このような条件下では、クライアントシステムが NIS マップの auto.home を上書きして、別のサーバーからホームディレクトリーをマウントする必要があるとします。この場合、クライアントは以下の /etc/auto.master マップを使用する必要があります。
/home ­/etc/auto.home
+auto.master
/etc/auto.home マップにはエントリーが含まれます。
*    labserver.example.com:/export/home/&
自動マウント機能は最初に出現したマウントポイントのみを処理するため、/home には NIS の auto.home マップではなく、/etc/auto.home の内容が含まれます。
別の方法として、サイト全体の auto.home マップを少しのエントリーで拡張し、/etc/auto.home ファイルマップを作成し、新しいエントリーを追加します。最後に、NIS の auto.home マップを含めます。次に、/etc/auto.home ファイルマップは次のようになります。
mydir someserver:/export/mydir
+auto.home
これらの NIS の auto.home マップ条件を使用すると、ls /home コマンドの出力は以下のようになります。
beth joe mydir
autofs には、読み取りしているファイルマップと同じ名前のファイルマップの内容が含まれていないので、この最後の例は期待どおりに動作します。そのため、autofs は、nsswitch 設定内の次のマップソースに移動します。

8.3.4. LDAP を使用した自動マウント機能マップの格納

LDAP から自動マウント機能マップを取得するように設定されているすべてのシステムに、LDAP クライアントライブラリーをインストールする必要があります。Red Hat Enterprise Linux では、openldap パッケージを自動的に automounter の依存関係としてインストールされます。LDAP アクセスを設定するには、/etc/openldap/ldap.conf を変更します。BASE、URI、および schema がサイトに対して適切に設定されていることを確認します。
自動マウントマップを LDAP に格納するために最近確立された最新のスキーマは、rfc2307bis によって記述されています。このスキーマを使用するには、スキーマ定義からコメント文字を削除して、autofs 設定(/etc/sysconfig/autofs)で設定する必要があります。以下に例を示します。

例8.4 autofs の設定

DEFAULT_MAP_OBJECT_CLASS="automountMap"
DEFAULT_ENTRY_OBJECT_CLASS="automount"
DEFAULT_MAP_ATTRIBUTE="automountMapName"
DEFAULT_ENTRY_ATTRIBUTE="automountKey"
DEFAULT_VALUE_ATTRIBUTE="automountInformation"
これらが設定にはコメント化されていない唯一のスキーマエントリーであることを確認します。automountKey は、rfc2307bis スキーマの cn 属性を置き換えます。以下は、LDAP データ交換形式(LDIF)設定の例です。

例8.5 LDF の設定

# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: (&(objectclass=automountMap)(automountMapName=auto.master))
# requesting: ALL
#

# auto.master, example.com
dn: automountMapName=auto.master,dc=example,dc=com
objectClass: top
objectClass: automountMap
automountMapName: auto.master

# extended LDIF
#
# LDAPv3
# base <automountMapName=auto.master,dc=example,dc=com> with scope subtree
# filter: (objectclass=automount)
# requesting: ALL
#

# /home, auto.master, example.com
dn: automountMapName=auto.master,dc=example,dc=com
objectClass: automount
cn: /home

automountKey: /home
automountInformation: auto.home

# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: (&(objectclass=automountMap)(automountMapName=auto.home))
# requesting: ALL
#

# auto.home, example.com
dn: automountMapName=auto.home,dc=example,dc=com
objectClass: automountMap
automountMapName: auto.home

# extended LDIF
#
# LDAPv3
# base <automountMapName=auto.home,dc=example,dc=com> with scope subtree
# filter: (objectclass=automount)
# requesting: ALL
#

# foo, auto.home, example.com
dn: automountKey=foo,automountMapName=auto.home,dc=example,dc=com
objectClass: automount
automountKey: foo
automountInformation: filer.example.com:/export/foo

# /, auto.home, example.com
dn: automountKey=/,automountMapName=auto.home,dc=example,dc=com
objectClass: automount
automountKey: /
automountInformation: filer.example.com:/export/&

8.4. 一般的な NFS マウントオプション

リモートホストに NFS を使用してファイルシステムをマウントする以外に、マウント時に他のオプションを指定して、マウントされた共有を使いやすくすることもできます。これらのオプションは、手動 マウント コマンド、/etc/fstab 設定、autofs と併用できます。
以下は、NFS マウントに一般的に使用されるオプションです。
lookupcache=mode
任意のマウントポイントに対して、カーネルがディレクトリーエントリーのキャッシュを管理する方法を指定します。mode の有効な引数は、allnone、または pos/positive です。
nfsvers=version
使用する NFS プロトコルのバージョンを指定します。version は 3 または 4 です。これは、複数の NFS サーバーを実行するホストに役に立ちます。バージョンを指定しないと、NFS は、kernel および mount コマンドで対応している最新バージョンを使用します。
vers オプションは nfsvers と同じで、互換性のためにこのリリースに含まれています。
noacl
ACL の処理をすべてオフにします。これは、古いバージョンの Red Hat Enterprise Linux、Red Hat Linux、または Solaris と相互向けとなる場合に必要となることがあります。最新の ACL テクノロジーは古いシステムとの互換性がないためです。
nolock
ファイルのロック機能を無効にします。この設定は、非常に古いバージョンの NFS サーバーに接続する場合に必要となる場合があります。
noexec
マウントしたファイルシステムでバイナリーが実行されないようにします。互換性のないバイナリーを含む、Linux 以外のファイルシステムをマウントしている場合に便利です。
nosuid
set-user-identifier または set-group-identifier ビットを無効にします。これにより、リモートユーザーが setuid プログラムを実行してより高い権限を取得できなくなります。
port=num
NFS サーバーポートの数値を指定します。num0 (デフォルト値)の場合、mount は、使用するポート番号をリモートホストの rpcbind サービスにクエリーします。リモートホストの NFS デーモンがその rpcbind サービスに登録されていない場合は、代わりに TCP 2049 の標準 NFS ポート番号が使用されます。
rsize=num および wsize=num
これらのオプションは、単一の NFS の読み取りまたは書き込み操作で転送される最大バイト数を設定します。
rsize およびwsize には、固定のデフォルト値がありません。デフォルトでは、NFS はサーバーとクライアントの両方がサポートしている最大の値を使用します。Red Hat Enterprise Linux 7 では、クライアントおよびサーバーの最大値は 1,048,576 バイトです。詳細は、「NFS マウントを使用した場合の rsize と wsize のデフォルト値と最大値」を参照してください。https://access.redhat.com/solutions/753853KBase の記事。
sec=flavors
マウントされたエクスポート上のファイルにアクセスするために使用するセキュリティーフレーバーです。flavors の値は、1 つ以上のセキュリティーフレーバーのコロンで区切られた一覧です。
デフォルトでは、クライアントは、クライアントとサーバーの両方をサポートするセキュリティーフレーバーの検索を試みます。サーバーが選択したフレーバーのいずれかに対応していない場合、マウント操作は失敗します。
sec=sys は、ローカルの UNIX UID および GID を使用します。AUTH_SYS を使用して NFS 操作を認証します。
sec=krb5 は、ユーザーを認証するのに、ローカルの UNIX UID および GID の代わりに Kerberos V5 を使用します。
sec=krb5i はユーザー認証に Kerberos V5 を使用し、データの改ざんを防ぐ安全なチェックサムを使用して NFS 操作の整合性チェックを実行します。
sec=krb5p は、ユーザー認証に Kerberos V5 を使用し、整合性チェックを行い、トラフィックの傍受を防ぐため NFS トラフィックの暗号化を行います。これが最も安全な設定になりますが、パフォーマンスのオーバーヘッドも最も高くなります。
tcp
NFS マウントが TCP プロトコルを使用するよう指示します。
UDP
NFS マウントが UDP プロトコルを使用するように指示します。
詳細は、man mount および man nfs を参照してください。

8.5. NFS サーバーの起動と停止

前提条件

  • NFSv2 または NFSv3 の接続に対応しているサーバーでは、rpcbind[1] サービスを実行している必要があります。rpcbind がアクティブであることを確認するには、次のコマンドを実行します。
    $ systemctl status rpcbind
    rpcbind を必要としない NFSv4 専用サーバーを設定する場合は、「NFSv4 専用サーバーの設定」 を参照してください。
  • Red Hat Enterprise Linux 7.0 では、NFS サーバーが NFSv3 をエクスポートし、システムの起動時に起動するようにするには、nfs-lock サービスを手動で開始して有効にする必要があります。
    # systemctl start nfs-lock
    # systemctl enable nfs-lock
    Red Hat Enterprise Linux 7.1 以降では、必要に応じて nfs-lock を自動的に起動し、手動で有効にすると失敗します。

手順

  • NFS サーバーを起動するには、以下のコマンドを使用します。
    # systemctl start nfs
  • システムの起動時に NFS が起動するようにするには、以下のコマンドを使用します。
    # systemctl enable nfs
  • サーバーを停止するには、以下を使用します。
    # systemctl stop nfs
  • restart オプションは、停止して NFS を起動する簡単な方法です。これは、NFS の設定ファイルを編集した後に設定変更を行う最も効率的な方法です。サーバータイプを再起動するには、以下を実行します。
    # systemctl restart nfs
  • /etc/sysconfig/nfs ファイルを編集したら、新しい値を有効にするために nfs-config サービスを再起動します。
    # systemctl restart nfs-config
  • try-restart コマンドは、現在実行している場合にのみ nfs を起動します。このコマンドは、Red Hat init スクリプトの condrestart条件付き再起動)と同等であり、NFS が実行されていない場合にデーモンを起動しないことに役立ちます。
    サーバーを条件付きで再起動するには、以下を入力します。
    # systemctl try-restart nfs
  • サービスタイプを再起動せずに NFS サーバー設定ファイルを再読み込みするには、以下を実行します。
    # systemctl reload nfs

8.6. NFS サーバーの設定

NFS サーバーでエクスポートを設定するには、2 つの方法があります。
  • NFS 設定ファイル( /etc/exports、および手動で編集)
  • コマンド exportfsを使用して、

8.6.1. /etc/exports 設定ファイル

/etc/exports ファイルは、リモートホストにどのファイルシステムをエクスポートするかを制御し、オプションを指定します。以下の構文ルールに従います。
  • 空白行は無視する。
  • コメントを追加するには、ハッシュ記号(#)で行を開始します。
  • 長い行は、バックスラッシュ(\)でラップできます。
  • エクスポートするファイルシステムは、それぞれ 1 行で指定する。
  • 許可するホストの一覧は、エクスポートするファイルシステムの後に空白文字を追加し、その後に追加する。
  • 各ホストのオプションは、ホストの識別子の直後に括弧を追加し、その中に指定する。ホストと最初の括弧の間には空白を使用しない。
エクスポートするファイルシステムの各エントリーは、以下のように指定します。
export host(options)
上記の構造では、以下の変数を使用します。
export
エクスポートするディレクトリー
host
エクスポートを共有するホストまたはネットワーク
オプション
ホストに使用されるオプション
各ホストに、複数のホストを指定できます。また、ホストごとに特定のオプションを指定できます。これを行うには、以下のように、各ホスト名の後に、各オプション(括弧内)を指定して、スペースで区切られた一覧と同じ行に追加します。
export host1(options1) host2(options2) host3(options3)
ホスト名を指定するためのその他の方法は、「ホスト名の形式」 を参照してください。
最も単純な形式で、/etc/exports ファイルは、エクスポートしたディレクトリーと、そのディレクトリーへのアクセスが許可されるホストのみを指定します。以下に例を示します。

例8.6 /etc/exports ファイル

/exported/directory bob.example.com
ここでは、bob.example.com は NFS サーバーから /exported/directory/ をマウントできます。この例ではオプションが指定されていないため、NFS はデフォルト設定 を使用します。
デフォルト設定は以下のとおりです。
ro
エクスポートするファイルシステムは読み取り専用です。リモートホストは、このファイルシステムで共有されているデータを変更できません。システムが変更(読み取り/書き込み)を可能にするには、rw オプションを指定します。
sync
NFS サーバーは、以前の要求で発生した変更がディスクに書き込まれるまで、要求に応答しません。代わりに非同期書き込みを有効にするには、async オプションを指定します。
wdelay
NFS サーバーは、別の書き込み要求が差し迫っていると判断すると、ディスクへの書き込みを遅らせます。これにより、複数の書き込みコマンドが同じディスクにアクセスする回数を減らすことができるため、書き込みのオーバーヘッドが低下し、パフォーマンスが向上します。これを無効にするには、no_wdelay を指定します。no_wdelay は、デフォルトの sync オプションが指定されている場合に限り使用できます。
root_squash
(ローカルからではなく) リモートから 接続している root ユーザーが root 権限を持つことを阻止します。代わりに、NFS サーバーはユーザー ID nfsnobody を割り当てます。これにより、リモートの root ユーザーの権限を、最も低いローカルユーザーレベルにまで下げて (squash)、高い確率でリモートサーバーへの書き込む権限を与えないようにすることができます。root squashing を無効にするには、no_root_squash を指定します。
(root を含む)すべてのリモートユーザーの権限を下げるには、all _squash を使用します。特定のホストからリモートユーザーに NFS サーバーが割り当てるユーザー ID とグループ ID を指定するには、以下のように anonuid オプションと an ongid オプションをそれぞれ使用します。
export host(anonuid=uid,anongid=gid)
uidgid は、それぞれユーザー ID 番号とグループ ID 番号になります。anonuid オプションおよび anongid オプションにより、共有するリモート NFS ユーザー用に、特別なユーザーおよびグループアカウントを作成できます。
デフォルトでは、アクセス制御リスト(ACL )は、Red Hat Enterprise Linux の NFS で対応しています。この機能を無効にするには、ファイルシステムをエクスポートする際に no_acl オプションを指定します。
エクスポートするすべてのファイルシステムの各デフォルトは、明示的に上書きする必要があります。たとえば、rw オプションを指定しないと、エクスポートするファイルシステムが読み取り専用として共有されます。以下は、/etc/exports の一例で、2 つのデフォルトオプションを上書きします。
/another/exported/directory 192.168.0.3(rw,async)
この例では、192.168.0.3/another/exported/directory/ の読み書きをマウントでき、ディスクへの書き込みすべてが非同期になります。エクスポートオプションの詳細は、man exportfs を参照してください。
デフォルト値が指定されていない他のオプションが利用できます。これには、サブツリーチェックを無効にし、セキュアでないポートからのアクセスを許可し、非セキュアなファイルロックを許可します(特定の初期の NFS クライアント実装には不要になります)。これらのあまり使用されないオプションの詳細は、man exports を参照してください。
重要
/etc/exports ファイルのフォーマットは、特に空白文字の使用に非常に正確です。ホストからエクスポートするファイルシステムの間、そしてホスト同士の間には、必ず空白文字を挿入してください。また、それ以外の場所 (コメント行を除く) には、空白文字を追加しないでください。
たとえば、以下の 2 つの行は意味が異なります。
/home bob.example.com(rw)
/home bob.example.com (rw)
最初の行は、/home ディレクトリーへの bob.example.com の読み取りおよび書き込みアクセスのみを許可します。2 番目の行では、bob.example.com からのユーザーがディレクトリーを読み取り専用(デフォルト)としてマウントし、その他のユーザーはそのディレクトリーを読み取り/書き込みでマウントできるようにします。

8.6.2. exportfs コマンド

NFS を使用してリモートユーザーにエクスポートするすべてのファイルシステム、およびそのファイルシステムのアクセスレベルは、/etc/exports ファイルに一覧表示されています。nfs サービスが起動すると、/usr/sbin/exportfs コマンドが 起動してこのファイルを読み取り、実際のマウントプロセスの rpc.mountd (NFSv3)に制御を渡してから、ファイルシステムがリモートユーザーが利用可能な rpc.nfsd へ渡します。
手動で実行すると、/usr/sbin/exportfs コマンドを使用すると、NFS サービスを再起動せずに、root ユーザーはディレクトリーを選択的にエクスポートまたは非エクスポートできます。適切なオプションを指定すると、/usr/sbin/exportfs コマンドは、エクスポートしたファイルシステムを /var/lib/nfs/xtab に書き込みます。rpc.mountd は、ファイルシステムに アクセス権を決定する際に xtab ファイルを参照するため、エクスポートしたファイルシステムの一覧に変更が即座に反映されます。
以下は、/usr/sbin/exportfs で利用可能な一般的に使用されるオプションの一覧です。
-r
/var/lib/nfs/etab に新しいエクスポート一覧を作成して、/etc/exports に記載されているすべてのディレクトリーをエクスポートします。このオプションを使用すると、/etc/exports に行った変更でエクスポート一覧が更新されます。
-a
/usr/sbin/exportfs に渡されるその他のオプションに応じて、すべてのディレクトリーをエクスポートするか、または非エクスポートされます。その他のオプションを指定しないと、/usr/sbin/exportfs は、/ etc/exports で指定されたすべてのファイルシステムをエクスポートします
-o file-systems
/etc/exports に記載されていない、エクスポート先のディレクトリーを指定します。file-systems を、エクスポートする追加のファイルシステムに置き換えます。これらのファイルシステムは、/etc/exports で指定されたのと同じ方法でフォーマットする必要があります。このオプションは、多くの場合、エクスポートするファイルシステムの一覧に永続的に追加する前に、エクスポートしたファイルシステムをテストするために使用されます。/etc/exports 構文の詳細は、/etc/exports 設定ファイル」 を参照してください。
-i
/etc/exports を無視します。コマンドラインで指定されたオプションのみが、エクスポートするファイルシステムの定義に使用されます。
-u
すべての共有ディレクトリーをエクスポートしなくなります。/usr/sbin/exportfs -ua コマンドは、すべての NFS デーモンを稼働状態に維持する間に NFS ファイルの共有を一時停止します。NFS 共有を再度有効にするには、exportfs -r を使用します。
-v
詳細な操作。exportfs コマンドを実行するときに、エクスポートまたは非エクスポートのファイルシステムが、より詳細に表示されます。
exportfs コマンドにオプションが渡されていない場合は、現在エクスポートされているファイルシステムのリストが表示されます。exportfs コマンドの詳細は、man exportfs を参照してください。

8.6.2.1. NFSv4 での exportfs の使用

Red Hat Enterprise Linux 7 では、上記のファイルシステムも、同じパスを使用して NFSv3 および NFSv4 クライアントで使用できるため、NFSv4 エクスポートの設定に追加の手順は必要ありません。これは、以前のバージョンでの場合ではありませんでした。
クライアントが NFSv4 を使用しないようにするには、/etc/sysconfig/nfs に RPCNFSDARGS= -N 4 を設定して無効にします

8.6.3. ファイアウォール内における NFS の実行

NFS には rpcbind が必要です。これは RPC サービスのポートを動的に割り当て、ファイアウォールルールの設定で問題が発生する可能性があります。クライアントがファイアウォールの背後にある NFS 共有にアクセスできるようにするには、/etc/sysconfig/nfs ファイルを編集して、RPC サービスを実行するポートを設定します。クライアントがファイアウォールを介して RPC クォータにアクセスできるようにするには、「ファイアウォールからの RPC クォータへのアクセス」 を参照してください。
デフォルトでは、すべてのシステムでは /etc/sysconfig/nfs ファイルが存在しません。/etc/sysconfig/nfs が存在しない場合は作成し、以下を指定します。
RPCMOUNTDOPTS="-p port"
これにより、rpc.mount コマンドラインに「-p port"」が追加されます( rpc.mount -p ポート )。
thenlock mgr サービスで使用するポートを指定するには、/etc/modprobe.d/lockd.conf ファイルで nlm_tcpport および nlm_udpport オプションのポート番号を設定します。
NFS が起動しない場合は、/var/log/messages を確認してください。通常、すでに使用されているポート番号を指定すると、NFS が起動しません。/etc/sysconfig/nfs を編集した後、nfs -config サービスを再起動して、Red Hat Enterprise Linux 7.2 で新しい値を有効にし、以下のコマンドを実行してください。
#  systemctl restart nfs-config
次に、NFS サーバーを再起動します。
#  systemctl restart nfs-server
rpcinfo -p を実行して、変更が反映されていることを確認します。
注記
NFSv4.0 コールバックがファイアウォールを通過できるようにするために、/proc/sys/fs/nfs/nfs_callback_tcpport を設定して、サーバーがクライアントのそのポートに接続できるようにします。
このプロセスは NFSv4.1 以降には必要ありません。純粋な NFSv4 環境では mountd、statd、および lockd の他のポートは必要ありません。

8.6.3.1. NFS エクスポートの検出

NFS サーバーがエクスポートするファイルシステムを検出する方法は 2 つあります。
  • NFSv3 に対応しているサーバーで、show mount コマンドを使用します。
    $ showmount -e myserver
    Export list for mysever
    /exports/foo
    /exports/bar
  • NFSv4 に対応しているサーバーで root ディレクトリーをマウントして確認します。
    # mount myserver:/ /mnt/
    # cd /mnt/
    exports
    # ls exports
    foo
    bar
NFSv4 と NFSv3 の両方に対応するサーバーでは、上記の方法はいずれも有効で、同じ結果となります。
注記
以前の NFS サーバーで、Red Hat Enterprise Linux 6 の設定方法によっては、異なるパスでファイルシステムを NFSv4 クライアントにエクスポートすることが可能です。これらのサーバーはデフォルトでは NFSv4 を有効にしないため、これは問題となるべきではありません。

8.6.4. ファイアウォールからの RPC クォータへのアクセス

ディスククォータを使用するファイルシステムをエクスポートする場合は、クォータの RPC (Remote Procedure Call) サービスを使用して、NFS クライアントにディスククォータデータを提供できます。

手順8.1 RPC クォータアクセスのファイアウォール内

  1. rpc-rquotad サービスを有効にするには、以下のコマンドを使用します。
    # systemctl enable rpc-rquotad 
  2. rpc-rquotad サービスを起動するには、以下のコマンドを使用します。
    # systemctl start rpc-rquotad 
    rpc-rquotad が有効になっている場合は、nfs-server サービスの起動後に自動的に開始されることに注意してください。
  3. ファイアウォールの内側で、クォータの RPC サービスにアクセスできるようにするには、UDP または TCP port 875 を開放する必要があります。デフォルトのポート番号は /etc/services ファイルで定義されます。
    デフォルトのポート番号を上書きするには、/etc/sysconfig/rpc -rquotad ファイルの RPCRQUOTADOPTS 変数に -p port-number を追加します。
  4. rpc-rquotad を再起動して、/etc/sysconfig/rpc-rquotad ファイルの変更を反映します。
    # systemctl restart rpc-rquotad

リモートホストからのクォータの設定

デフォルトでは、クォータはリモートホストによってのみ読み込むことができます。クォータの設定を許可するには、/etc/sysconfig/rpc-rquotad ファイルの RPCRQUOTADOPTS 変数に -S オプションを追加します。
rpc-rquotad を再起動して、/etc/sysconfig/rpc-rquotad ファイルの変更を反映します。
# systemctl restart rpc-rquotad

8.6.5. ホスト名の形式

ホストは以下の形式になります。
単独のマシン
完全修飾ドメイン名(サーバーにより解決)、ホスト名(サーバーにより解決)、または IP アドレス。
ワイルドカードで指定された一連のマシン
* または ? 文字を使用して、文字列の一致を指定します。ワイルドカードは IP アドレスと併用されませんが、逆引き DNS ルックアップが失敗する場合は誤って機能する可能性があります。完全修飾ドメイン名でワイルドカードを指定する場合、ドット(.)はワイルドカードに含まれません。たとえば、*.example.com には one.example.com が含まれていますが、include one.two.example.com は含まれません。
IP ネットワーク
a.b.c.d/z を使用します 。a.b.c.d はネットワークで、z はネットマスクのビット数(例: 192.168.0.0/24) です。もう 1 つの形式には a.b.c.d/ネットマスク があります。ここで a.b.c.d はネットワークであり、netmask はネットマスクになります(例: 192.168.100.8/255.255.255.0)。
Netgroups
@group-name 形式を使用します。group-name は NIS netgroup 名です。

8.6.6. NFS over RDMA の有効化 (NFSoRDMA)

Red Hat Enterprise Linux 7 では、RDMA に対応するハードウェアが存在すると、RDMA(Remote Direct Memory Access)サービスは自動的に機能します。
RDMA で NFS を有効にするには、以下を実行します。
  1. rdma および rdma-core パッケージをインストールします。
    /etc/rdma/rdma.conf ファイルには、デフォルトで XPRTRDMA_LOAD=yes を設定する行が含まれています。これは、rdma サービスが NFSoRDMA クライアントモジュールを読み込む ように要求します。
  2. NFSoRDMA サーバーモジュール の自動読み込みを有効にするには、/etc/rdma/rdma.conf の新しい行に SVCRDMA_LOAD=yes を追加します。
    RPCNFSDARGS="--rdma=20049" /etc/sysconfig/nfs ファイルで、NFSoRDMA サービスがクライアントをリッスンするポート番号を指定します。RFC 5667 は、RDMA を介して NFSv4 サービスを提供する場合に、サーバーが 20049 ポートをリッスンする必要があることを指定します。
  3. /etc/rdma/rdma.conf ファイルを編集したら、nfs サービスを再起動します。
    # systemctl restart nfs
    以前のカーネルバージョンでは、/etc/rdma/rdma.conf を編集して変更を有効にするために、システムの再起動が必要なことに注意してください。

8.6.7. NFSv4 専用サーバーの設定

デフォルトでは、NFS サーバーは Red Hat Enterprise Linux 7 の NFSv2、NFSv3、および NFSv4 の接続に対応します。ただし、バージョン 4.0 以降の NFS のみに対応するように NFS を設定することもできます。NFSv4 では、rpcbind サービスがネットワークをリッスンする必要がないため、これにより、システムで開いているポートと実行中のサービスの数が最小限に抑えられます。
NFS サーバーが NFSv4 専用として設定されていると、NFSv2 または NFSv3 を使用して共有をマウントしようとするクライアントは、次のようなエラーでマウントに失敗します。
Requested NFS version or transport protocol is not supported.

手順8.2 NFSv4 専用サーバーの設定

NFS サーバーが NFS バージョン 4.0 以降のみに対応するように設定するには、以下を行います。
  1. /etc/sysconfig/nfs 設定ファイルに以下の行を追加して、NFSv2、NFSv3、および UDP を無効にします。
    RPCNFSDARGS="-N 2 -N 3 -U"
    
  2. 必要に応じて、RPCBINDMOUNT、および NSM のプロトコル呼び出しのリッスンを無効にします。これは NFSv4 専用の場合は不要です。
    これらのオプションを無効にすると、以下のような影響があります。
    • NFSv2 または NFSv3 を使用してサーバーから共有をマウントしようとするクライアントが応答しなくなります。
    • NFS サーバー自体が、NFSv2 および NFSv3 のファイルシステムをマウントできなくなります。
    以下のオプションを無効にするには、以下を実行します。
    • 以下を /etc/sysconfig/nfs ファイルに追加します。
      RPCMOUNTDOPTS="-N 2 -N 3"
      
    • 関連するサービスを無効にします。
      # systemctl mask --now rpc-statd.service rpcbind.service rpcbind.socket
  3. NFS サーバーを再起動します。
    # systemctl restart nfs
    変更は、NFS サーバーを起動または再起動するとすぐに反映されます。

NFSv4 専用の設定の確認

netstat ユーティリティーを使用して、NFS サーバーが NFSv4 専用モードで設定されていることを確認します。
  • 以下は NFSv4 専用サーバーでの netstat の出力例です。RPCBIND、MOUNT、および NSM のリッスンも無効になります。nfs が唯一リッスンする NFS サービスになります。
    # netstat -ltu
    
    Active Internet connections (only servers)
    Proto Recv-Q Send-Q Local Address           Foreign Address         State      
    tcp        0      0 0.0.0.0:nfs             0.0.0.0:*               LISTEN     
    tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN     
    tcp        0      0 localhost:smtp          0.0.0.0:*               LISTEN     
    tcp6       0      0 [::]:nfs                [::]:*                  LISTEN     
    tcp6       0      0 [::]:12432              [::]:*                  LISTEN     
    tcp6       0      0 [::]:12434              [::]:*                  LISTEN     
    tcp6       0      0 localhost:7092          [::]:*                  LISTEN     
    tcp6       0      0 [::]:ssh                [::]:*                  LISTEN     
    udp        0      0 localhost:323           0.0.0.0:*                          
    udp        0      0 0.0.0.0:bootpc          0.0.0.0:*                          
    udp6       0      0 localhost:323           [::]:*
    
  • 対照的に、NFSv4 専用サーバーを設定する前の netstat 出力には、sunrpc サービスと mountd サービスが含まれています。
    # netstat -ltu
    
    Active Internet connections (only servers)
    Proto Recv-Q Send-Q Local Address           Foreign Address         State      
    tcp        0      0 0.0.0.0:nfs             0.0.0.0:*               LISTEN     
    tcp        0      0 0.0.0.0:36069           0.0.0.0:*               LISTEN     
    tcp        0      0 0.0.0.0:52364           0.0.0.0:*               LISTEN     
    tcp        0      0 0.0.0.0:sunrpc          0.0.0.0:*               LISTEN     
    tcp        0      0 0.0.0.0:mountd          0.0.0.0:*               LISTEN     
    tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN     
    tcp        0      0 localhost:smtp          0.0.0.0:*               LISTEN     
    tcp6       0      0 [::]:34941              [::]:*                  LISTEN     
    tcp6       0      0 [::]:nfs                [::]:*                  LISTEN     
    tcp6       0      0 [::]:sunrpc             [::]:*                  LISTEN     
    tcp6       0      0 [::]:mountd             [::]:*                  LISTEN     
    tcp6       0      0 [::]:12432              [::]:*                  LISTEN     
    tcp6       0      0 [::]:56881              [::]:*                  LISTEN     
    tcp6       0      0 [::]:12434              [::]:*                  LISTEN     
    tcp6       0      0 localhost:7092          [::]:*                  LISTEN     
    tcp6       0      0 [::]:ssh                [::]:*                  LISTEN     
    udp        0      0 localhost:323           0.0.0.0:*                          
    udp        0      0 0.0.0.0:37190           0.0.0.0:*                          
    udp        0      0 0.0.0.0:876             0.0.0.0:*                          
    udp        0      0 localhost:877           0.0.0.0:*                          
    udp        0      0 0.0.0.0:mountd          0.0.0.0:*                          
    udp        0      0 0.0.0.0:38588           0.0.0.0:*                          
    udp        0      0 0.0.0.0:nfs             0.0.0.0:*                          
    udp        0      0 0.0.0.0:bootpc          0.0.0.0:*                          
    udp        0      0 0.0.0.0:sunrpc          0.0.0.0:*                          
    udp6       0      0 localhost:323           [::]:*                             
    udp6       0      0 [::]:57683              [::]:*                             
    udp6       0      0 [::]:876                [::]:*                             
    udp6       0      0 [::]:mountd             [::]:*                             
    udp6       0      0 [::]:40874              [::]:*                             
    udp6       0      0 [::]:nfs                [::]:*                             
    udp6       0      0 [::]:sunrpc             [::]:*
    

8.7. NFS のセキュア化

NFS は、多数の既知のホストを持つファイルシステム全体の透過的な共有に適しています。ただし、使いやすさに伴い、さまざまなセキュリティー上の問題があります。サーバーで NFS ファイルシステムをエクスポートする場合や、クライアントにマウントする際に、NFS セキュリティーリスクを最小限に抑え、サーバーのデータを保護するには、以下のセクションを検討してください。

8.7.1. AUTH_SYS とエクスポート制御による NFS セキュリティー

従来は、NFS には、エクスポートしたファイルへのアクセスを制御するための 2 つのオプションが指定されています。
まず、IP アドレスまたはホスト名を使用して、どのホストにどのファイルシステムをマウントできるかを制限します。
次にサーバーは、ローカルユーザーの場合と同じ方法で、NFS クライアントのユーザーにファイルシステムの権限を強制します。従来は、AUTH _SYS (AUTH _UNIXとも呼ばれます)を使用してこれを行います。これはクライアントに依存してユーザーの UID と GID を示します。これは、悪意のあるクライアントや間違った設定クライアントが簡単にこの間違いを招き、ユーザーがアクセスすべきではないファイルにアクセスを許可する可能性があることを意味します。
潜在的なリスクを制限するために、多くの場合、管理者は共通のユーザー ID およびグループ ID への読み取り専用アクセスまたは権限の付与(squash)アクセスを許可します。ただし、このソリューションにより、NFS 共有が元々想定されている方法では使用されなくなります。
さらに、攻撃者が NFS ファイルシステムをエクスポートするシステムが使用する DNS サーバーを制御できる場合、特定のホスト名または完全修飾ドメイン名に関連付けられたシステムは、承認されていないマシンにポイントできます。この時点で、権限のないマシンは、NFS 共有をマウント できるシステム になります。これは、ユーザー名やパスワード情報が交換されず、NFS マウントに追加のセキュリティーが確保されないためです。
NFS 経由でディレクトリーのエクスポートを行う際にワイルドカードを使用する場合は慎重に行ってください。ワイルドカードの対象が予定よりも広い範囲のシステムを対象とする可能性があります。
TCP ラッパーを使用して rpcbind[1] サービスへのアクセスを制限することもできます。iptables でルールを作成することにより、rpcbind、rpc.mountd、および rpc. nfsd が使用するポートへのアクセスを制限することもできます。
NFS および rpcbind のセキュリティー保護の詳細は、man iptables を参照してください。

8.7.2. AUTH_GSSによる NFS セキュリティー

NFSv4 は、RPCSEC_GSS および Kerberos バージョン 5 GSS-API メカニズムの実装を廃止することで、NFS セキュリティーを再作成します。ただし、RPCSEC_GSS および Kerberos メカニズムも、すべてのバージョンの NFS で利用できます。FIPS モードでは、FIPS 承認アルゴリズムのみを使用できます。
AUTH_SYS とは異なり、RPCSEC_GSS Kerberos メカニズムでは、サーバーは、どのユーザーがそのファイルにアクセスしているかを正確に表すことをクライアントに依存しません。代わりに、暗号を使用してサーバーにユーザーを認証し、悪意のあるクライアントがそのユーザーの Kerberos 認証情報を持たずにユーザーを偽装しないようにします。RPCSEC_GSS Kerberos メカニズムを使用することが、マウントを保護する最も簡単な方法になります。Kerberos の設定後は、追加の設定が不要になるためです。

Kerberos の設定

NFSv4 Kerberos 対応のサーバーを設定する前に、Kerberos Key Distribution Centre(KDC)をインストールして設定する必要があります。Kerberos はネットワーク認証システムであり、対称暗号化と、信頼できるサードパーティー (KDC) を使用してクライアントとサーバーが相互に認証できるようにします。Red Hat では、Kerberos の設定に Identity Management (IdM) を使用することを推奨します。

手順8.3 IdM が RPCSEC_GSS を使用するように NFS サーバーおよびクライアントを設定

    • NFS サーバー側で nfs/hostname.domain@REALM プリンシパルを作成します。
    • サーバーとクライアントに host/hostname.domain@REALM を作成します。
    • クライアントとサーバーのキータブに、対応する鍵を追加します。
  1. サーバーで、sec= オプションを使用して、希望するセキュリティーフレーバーを有効にします。すべてのセキュリティーフレーバーと非暗号化マウントを有効にするには、以下のコマンドを実行します。
    /export *(sec=sys:krb5:krb5i:krb5p)
    
    sec= オプションで使用する有効なセキュリティーフレーバーは以下のとおりです。
    • sys - 暗号化の保護なし (デフォルト)
    • krb5 - 認証のみ
    • krb5i - インテグリティー保護
    • krb5p - プライバシー保護
  2. クライアントで、sec=krb5 (もしくは設定に応じて sec=krb5i または sec=krb5p) をマウントオプションに追加します。
    # mount -o sec=krb5 server:/export /mnt
    

関連情報

8.7.2.1. NFSv4 を使用した NFS セキュリティー

NFSv4 には、Microsoft Windows NT モデルの機能や幅広いデプロイメントが原因で、POSIX モデルではなく、Microsoft Windows NT モデルをベースとした ACL サポートが含まれています。
NFSv4 のもう 1 つの重要なセキュリティー機能は、ファイルシステムのマウントに MOUNT プロトコルを使用しなくなることです。MOUNT プロトコルは、プロトコルがファイルを処理する方法により、セキュリティー上のリスクが発生します。

8.7.3. ファイル権限

リモートホストにより NFS ファイルシステムを読み取りまたは読み書きとしてマウントした場合は、パーティションが、各共有ファイルに対する唯一の保護となります。同じユーザー ID の値を共有する 2 つのユーザーが同じ NFS ファイルシステムをマウントした場合は、他のすべてのファイルを修正できます。さらに、クライアントシステムで root としてログインした場合は、su - コマンドを使用して、NFS 共有を持つファイルにアクセスできます。
デフォルトでは、アクセス制御リスト (ACL) は、Red Hat Enterprise Linux では NFS が対応しています。Red Hat では、この機能を有効にしておくことを推奨します。
デフォルトでは、NFS はファイルシステムをエクスポートする際に root squashing を使用します。これにより、NFS 共有にアクセスするユーザーのユーザー ID が、ローカルマシンの root ユーザーとして nobody に設定されます。root squashing は、デフォルトのオプション root_squash で制御されます。このオプションの詳細は、/etc/exports 設定ファイル」 を参照してください。可能な場合は、root squashing を無効にしないでください。
NFS 共有を読み取り専用としてエクスポートする場合は、all_squash オプションの使用を検討してください。このオプションでは、エクスポートしたファイルシステムにアクセスするすべてのユーザーが、nfsnobody ユーザーのユーザー ID を取得します。

8.8. NFS および rpcbind

注記
以下の項は、後方互換性に rpcbind サービスを必要とする NFSv3 実装にのみ適用されます。
rpcbind を必要としない NFSv4 専用サーバーを設定する方法は、「NFSv4 専用サーバーの設定」 を参照してください。
rpcbind[1] ユーティリティーは、RPC サービスを、リッスンするポートにマッピングします。RPC プロセスは、開始時に rpcbind に通知し、そのプロセスがリッスンしているポートと、処理することが予想される RPC プログラム番号を登録します。クライアントシステムは、特定の RPC プログラム番号でサーバーの rpcbind と通信します。rpcbind サービスは、クライアントを適切なポート番号にリダイレクトし、要求されたサービスと通信できるようにします。
RPC ベースのサービスは、rpcbind を使用して、クライアントの受信要求ですべての接続を確立するため、これらのサービスを開始する前に rpcbind が利用可能でなければなりません。
rpcbind サービスは、アクセス制御に TCP ラッパーを使用し、rpcbind のアクセス制御ルールは、すべての RPC ベースのサービスに影響します。あるいは、NFS RPC デーモンごとにアクセス制御ルールを指定することもできます。rpc. mountd および rpc. statdman ページには、これらのルールの正確な構文に関する情報が記載されています。

8.8.1. NFS および rpcbindのトラブルシューティング

rpcbind[1] は、RPC サービスとその通信に使用するポート番号との間の調整を提供するため、トラブルシューティングの際に rpcbind を使用して現在の RPC サービスの状態を表示していただくと役に立ちます。rpcinfo コマンドは、RPC ベースの各サービスとポート番号、RPC プログラム番号、バージョン番号、および IP プロトコルタイプ(TCP または UDP)が表示されます。
rpcbind に対して適切な RPC ベースの NFS サービスが有効になっていることを確認するには、次のコマンドを使用します。
# rpcinfo -p

例8.7 rpcinfo -p コマンドの出力

以下に、上記コマンドの出力例を示します。
program vers proto  port service
      100021    1   udp  32774  nlockmgr
      100021    3   udp  32774  nlockmgr
      100021    4   udp  32774  nlockmgr
      100021    1   tcp  34437  nlockmgr
      100021    3   tcp  34437  nlockmgr
      100021    4   tcp  34437  nlockmgr
      100011    1   udp    819  rquotad
      100011    2   udp    819  rquotad
      100011    1   tcp    822  rquotad
      100011    2   tcp    822  rquotad
      100003    2   udp   2049  nfs
      100003    3   udp   2049  nfs
      100003    2   tcp   2049  nfs
      100003    3   tcp   2049  nfs
      100005    1   udp    836  mountd
      100005    1   tcp    839  mountd
      100005    2   udp    836  mountd
      100005    2   tcp    839  mountd
      100005    3   udp    836  mountd
      100005    3   tcp    839  mountd
NFS サービスの 1 つが正しく起動しないと、rpcbind は、そのサービスに対するクライアントからの RPC 要求を、正しいポートにマッピングできなくなります。多くの場合、NFS が rpcinfo の出力に表示されていない場合は、NFS を再起動すると、サービスが rpcbind に適切に登録され、動作を開始します。
rpcinfo に関する詳細とオプションの一覧については、man ページを参照してください。

8.9. pNFS

NFS v4.1 標準の一部として Parallel NFS(pNFS)のサポートは、Red Hat Enterprise Linux 6.4 から入手できます。pNFS アーキテクチャーでは、パフォーマンスを改善し、NFS のスケーラビリティーを向上させます。つまり、サーバーが pNFS も実装されると、クライアントは複数のサーバーで同時にデータにアクセスできるようになります。ファイル、オブジェクト、ブロックの 3 つのストレージプロトコルまたはレイアウトをサポートします。
注記
このプロトコルでは、ファイル、オブジェクト、ブロックの 3 つの pNFS レイアウトタイプを使用できます。Red Hat Enterprise Linux 6.4 クライアントは、ファイルのレイアウトタイプのみをサポートしますが、Red Hat Enterprise Linux 7 は、ファイルレイアウトタイプをサポートし、オブジェクトおよびブロックレイアウトタイプはテクノロジープレビューとして提供されます。

pNFS Flex ファイル

柔軟なファイルは、スタンドアロンの NFSv3 および NFSv4 サーバーの集約を可能にする pNFS の新しいレイアウトです。Flex Files 機能は、RFC 7862 仕様で説明されているように NFSv4.2 標準仕様に含まれます。
Red Hat Enterprise Linux は、Red Hat Enterprise Linux 7.4 以降、Flex ファイルサーバーから NFS 共有をマウントできます。

pNFS 共有のマウント

  • pNFS 機能を有効にするには、NFS バージョン 4.1 以降を使用して pNFS 対応サーバーから共有をマウントします。
    # mount -t nfs -o v4.1 server:/remote-export /local-directory
    サーバーに pNFS-enabled すると、nfs_layout_nfsv41_files カーネルが最初のマウントで自動的に読み込まれます。出力内のマウントエントリーには minorversion=1 が含まれているはずです。以下のコマンドを使用して、モジュールが読み込まれたことを確認します。
    $ lsmod | grep nfs_layout_nfsv41_files
  • Flex ファイルをサポートするサーバーから、Flex Files 機能で NFS 共有をマウントするには、NFS バージョン 4.2 以降を使用します。
    # mount -t nfs -o v4.2 server:/remote-export /local-directory
    nfs_layout_flexfiles モジュールが読み込まれていることを確認します。
    $ lsmod | grep nfs_layout_flexfiles

関連情報

pNFS の詳細は、http://www.pnfs.com を参照してください。

8.10. NFS での pNFS SCSI レイアウトの有効化

データのアクセスに pNFS SCSI レイアウトを使用するように、NFS サーバーおよびクライアントを設定できます。pNFS SCSI は、ファイルへの長期接続のシングルクライアントアクセスに伴うユースケースで利点があります。

前提条件

  • クライアントとサーバーの両方で、SCSI コマンドを同じブロックデバイスに送信する必要があります。つまり、ブロックデバイスは共有 SCSI バス上になければなりません。
  • ブロックデバイスに XFS ファイルシステムが含まれている必要があります。
  • SCSI デバイスは、 SCSI-3 Primary Commands 仕様で説明されているように、SCSI Persistent Reservation に対応している必要があります。

8.10.1. pNFS SCSI レイアウト

SCSI レイアウトは、pNFS ブロックレイアウトの作業に基づいています。このレイアウトは、SCSI デバイス全体に定義されます。これには、SCSI 永続予約に対応する必要がある論理ユニット (lUS) として、固定サイズのブロックが連続的に含まれています。LU デバイスは、SCSI デバイスの識別子で識別されます。
pNFS SCSI は、ファイルへの長期接続のシングルクライアントアクセスのユースケースで適切に実行されます。例として、メールサーバーまたはクラスターを格納している仮想マシンなどが挙げられます。

クライアントとサーバー間の操作

NFS クライアントが、ファイルからの読み取り、またはファイルへの書き込みを行うと、クライアントは LAYOUTGET 操作を実行します。サーバーは、SCSI デバイスのファイルの場所に反応します。このクライアントは、使用する SCSI デバイスを判断するために、GETDEVICEINFO の追加操作が必要になる場合があります。正しく動作するのであれば、クライアントは、READ 操作および WRITE 操作をサーバーに送信する代わりに、SCSI デバイスに直接 I/O 要求を発行することができます。
クライアント間のエラーまたは競合により、サーバーがレイアウトを再び呼び出したり、クライアントにレイアウトを発行しなくなることがあります。この場合、クライアントは SCSI デバイスに I/O 要求を直接送信するのではなく、サーバーへの READ 操作および WRITE 操作の発行にフォールバックします。
操作を監視するには、「pNFS SCSI レイアウト機能の監視」 を参照してください。

デバイスの予約

pNFS SCSI は、予約の割り当てを通じてフェンシングを処理します。サーバーがレイアウトをクライアントに発行する前に、SCSI デバイスを予約して、登録したクライアントのみがデバイスにアクセスできるようにします。クライアントが、その SCSI デバイスに対してコマンドを実行できても、そのデバイスに登録されていない場合は、クライアントからの多くの操作が、そのデバイス上で失敗します。たとえば、サーバーがそのデバイスのレイアウトをクライアントに指定していないと、クライアントの blkid コマンドは XFS ファイルシステムの UUID を表示できません。
サーバーは、独自の永続予約を削除しません。これにより、クライアントやサーバーの再起動時に、デバイスのファイルシステム内のデータが保護されます。SCSI デバイスを他の目的で使用するには、NFS サーバーで、手動で永続予約を削除する必要があります。

8.10.2. pNFS で SCSI デバイスの互換性の確認

この手順では、SCSI デバイスが pNFS SCSI レイアウトに対応しているかどうかを確認します。

前提条件

  • sg3_utils パッケージをインストールします。
    # yum install sg3_utils

手順8.4 pNFS で SCSI デバイスの互換性の確認

  • サーバーおよびクライアントの両方で、適切な SCSI デバイスサポートを確認します。
    # sg_persist --in --report-capabilities --verbose path-to-scsi-device
    Persist Through Power Loss Active (PTPL_A)ビットが設定されるようにします。

    例8.8 pNFS SCSI をサポートする SCSI デバイス

    以下は、pNFS SCSI に対応する SCSI デバイスにおける sg_persist 出力の例になります。PTPL _A ビットが 1 を報告します。
        inquiry cdb: 12 00 00 00 24 00
        Persistent Reservation In cmd: 5e 02 00 00 00 00 00 20 00 00
      LIO-ORG   block11           4.0
      Peripheral device type: disk
    Report capabilities response:
      Compatible Reservation Handling(CRH): 1
      Specify Initiator Ports Capable(SIP_C): 1
      All Target Ports Capable(ATP_C): 1
      Persist Through Power Loss Capable(PTPL_C): 1
      Type Mask Valid(TMV): 1
      Allow Commands: 1
      Persist Through Power Loss Active(PTPL_A): 1
        Support indicated in Type mask:
          Write Exclusive, all registrants: 1
          Exclusive Access, registrants only: 1
          Write Exclusive, registrants only: 1
          Exclusive Access: 1
          Write Exclusive: 1
          Exclusive Access, all registrants: 1
    

関連情報

  • sg_persist(8) の man ページ

8.10.3. サーバーで pNFS SCSI の設定

この手順では、NFS サーバーが pNFS SCSI レイアウトをエクスポートするように設定します。

手順8.5 サーバーで pNFS SCSI の設定

  1. サーバーで、SCSI デバイスで作成した XFS ファイルシステムをマウントします。
  2. NFS バージョン 4.1 以降をエクスポートするように NFS サーバーを設定します。/etc/nfs.conf ファイルの [nfsd] セクションに、以下のオプションを設定します。
    [nfsd]
    
    vers4.1=y
    
  3. pnfs オプションを指定して、NFS で XFS ファイルシステムをエクスポートするように NFS サーバーを設定します。

    例8.9 pNFS SCSI をエクスポートする /etc/exports のエントリー

    /etc/exports 設定ファイルの以下のエントリーは、/ exported/directory/ にマウントされているファイルシステムを pNFS SCSI レイアウトとして allowed.example.com クライアントにエクスポートします。
    /exported/directory allowed.example.com(pnfs)

関連情報

8.10.4. クライアントで pNFS SCSI の設定

この手順では、pNFS SCSI レイアウトをマウントするように NFS クライアントを設定します。

前提条件

手順8.6 クライアントで pNFS SCSI の設定

  • クライアントで、NFS バージョン 4.1 以降を使用して、エクスポートした XFS ファイルシステムをマウントします。
    # mount -t nfs -o nfsvers=4.1 host:/remote/export /local/directory
    NFS なしで XFS ファイルシステムを直接マウントしないでください。

関連情報

8.10.5. サーバーで pNFS SCSI 予約のリリース

この手順では、NFS サーバーが SCSI デバイスを維持している永続的な予約を解放します。これにより、pNFS SCSI をエクスポートする必要がなくなったら、SCSI デバイスを別の目的で使用できるようになります。
サーバーから予約を削除する必要があります。別の IT Nexus から削除することはできません。

前提条件

  • sg3_utils パッケージをインストールします。
    # yum install sg3_utils

手順8.7 サーバーで pNFS SCSI 予約のリリース

  1. サーバーで、既存の予約をクエリーします。
    # sg_persist --read-reservation path-to-scsi-device

    例8.10 /dev/sda での予約のクエリー

    # sg_persist --read-reservation /dev/sda
    
      LIO-ORG   block_1           4.0
      Peripheral device type: disk
      PR generation=0x8, Reservation follows:
        Key=0x100000000000000
        scope: LU_SCOPE,  type: Exclusive Access, registrants only
    
  2. サーバーにある既存の登録を削除します。
    # sg_persist --out \
                 --release \
                 --param-rk=reservation-key \
                 --prout-type=6 \
                 path-to-scsi-device

    例8.11 /dev/sda の予約の削除

    # sg_persist --out \
                 --release \
                 --param-rk=0x100000000000000 \
                 --prout-type=6 \
                 /dev/sda
    
      LIO-ORG   block_1           4.0
      Peripheral device type: disk
    

関連情報

  • sg_persist(8) の man ページ

8.10.6. pNFS SCSI レイアウト機能の監視

pNFS クライアントとサーバーで、pNFS SCSI 操作が適切に行われることを犠牲にしているかどうか、または通常の NFS 操作にフォールバックするかどうかを監視できます。

前提条件

  • pNFS SCSI クライアントとサーバーが設定されている。

8.10.6.1. nfsstat を使用したサーバーからの pNFS SCSI 操作の確認

この手順では、nfsstat ユーティリティーを使用して、サーバーから pNFS SCSI 操作を監視します。

手順8.8 nfsstat を使用したサーバーからの pNFS SCSI 操作の確認

  1. サーバーから操作サービスを監視します。
    # watch --differences \
            "nfsstat --server | egrep --after-context=1 read\|write\|layout"
    
    Every 2.0s: nfsstat --server | egrep --after-context=1 read\|write\|layout
    
    putrootfh    read         readdir      readlink     remove	 rename
    2         0% 0         0% 1         0% 0         0% 0         0% 0         0%
    --
    setcltidconf verify	  write        rellockowner bc_ctl	 bind_conn
    0         0% 0         0% 0         0% 0         0% 0         0% 0         0%
    --
    getdevlist   layoutcommit layoutget    layoutreturn secinfononam sequence
    0         0% 29        1% 49        1% 5         0% 0         0% 2435     86%
    
  2. クライアントとサーバーは、以下の場合に pNFS SCSI 操作を使用します。
    • layoutget カウンター、layoutreturn カウンター、および layoutcommit カウンターがインクリメントします。これは、サーバーがレイアウトを提供することを意味します。
    • サーバーの read カウンターおよび write カウンターはインクリメントしません。これは、クライアントが SCSI デバイスに直接 I/O 要求を実行していることを意味します。

8.10.6.2. mountstats を使用したクライアントからの pNFS SCSI 操作の確認

この手順では、/proc/self/mountstats ファイルを使用して、クライアントからの pNFS SCSI 操作を監視します。

手順8.9 mountstats を使用したクライアントからの pNFS SCSI 操作の確認

  1. マウントごとの操作カウンターを一覧表示します。
    # cat /proc/self/mountstats \
          | awk /scsi_lun_0/,/^$/ \
          | egrep device\|READ\|WRITE\|LAYOUT
    
    device 192.168.122.73:/exports/scsi_lun_0 mounted on /mnt/rhel7/scsi_lun_0 with fstype nfs4 statvers=1.1
        nfsv4:  bm0=0xfdffbfff,bm1=0x40f9be3e,bm2=0x803,acl=0x3,sessions,pnfs=LAYOUT_SCSI
                READ: 0 0 0 0 0 0 0 0
               WRITE: 0 0 0 0 0 0 0 0
            READLINK: 0 0 0 0 0 0 0 0
             READDIR: 0 0 0 0 0 0 0 0
           LAYOUTGET: 49 49 0 11172 9604 2 19448 19454
        LAYOUTCOMMIT: 28 28 0 7776 4808 0 24719 24722
        LAYOUTRETURN: 0 0 0 0 0 0 0 0
         LAYOUTSTATS: 0 0 0 0 0 0 0 0
    
  2. 結果は以下のようになります。
    • LAYOUT 統計は、クライアントとサーバーが pNFS SCSI 操作を使用する要求を示します。
    • READ および WRITE の統計は、クライアントとサーバーが NFS 操作にフォールバックする要求を示します。

8.11. NFS リファレンス

NFS サーバーの管理はチャレンジとしても使用できます。本章で説明するいくつかのオプションが多数あり、NFS 共有のエクスポートやマウントに利用できます。詳細は、以下のソースを参照してください。

インストールされているドキュメント

  • man mount: NFS サーバーおよびクライアント設定両方のマウントオプションについて、包括的な手順が含まれます。
  • man fstab: システムの起動時にファイルシステムをマウントする /etc/fstab ファイルの形式の詳細を提供します。
  • man nfs - NFS 固有のファイルシステムのエクスポートおよびマウントオプションの詳細を提供します。
  • man エクスポート: NFS ファイルシステムをエクスポートする際に、/etc/exports ファイルで使用される一般的なオプションを表示します。

便利な Web サイト



[1] rpcbind サービスは 、以前のバージョンの Red Hat Enterprise Linux で使用されていたポート マップから、RPC プログラム番号の組み合わせを IP アドレスポート番号をマッピングします。詳細は、「必要なサービス」 を参照してください。

第9章 サーバーメッセージブロック(SMB)

Server Message Block (SMB) プロトコルは、アプリケーション層のネットワークプロトコルを実装します。これは、ファイル共有や共有プリンターなど、サーバー上のリソースにアクセスするために使用されます。SMB は、Microsoft Windows にはデフォルトで実装されています。Red Hat Enterprise Linux を実行する場合は、Samba を使用して SMB 共有と cifs-utils ユーティリティーを提供し、リモートサーバーから SMB 共有をマウントします。
注記
SMB のコンテキストでは、SMB の方言である Common Internet File System(CIFS)プロトコルを読み取ることがあります。SMB プロトコルと CIFS プロトコルの両方がサポートされており、SMB 共有および CIFS 共有のマウントに関連するカーネルモジュールとユーティリティーはどちらも cifs という名前を使用します。

9.1. SMB 共有の提供

Red Hat System Administrator's Guide の 『Samba』 セクションを参照してください。

9.2. SMB 共有のマウント

Red Hat Enterprise Linux では、カーネルの cifs.ko ファイルシステムモジュールが SMB プロトコルに対応します。ただし、SMB 共有をマウントして機能するには、cifs-utils パッケージもインストールする必要があります。
# yum install cifs-utils
cifs-utils パッケージは、以下を行うユーティリティーを提供します。
  • SMB 共有と CIFS 共有をマウントする
  • カーネルのキーリングで NT Lan Manager(NTLM)認証情報を管理します。
  • SMB 共有および CIFS 共有のセキュリティー記述子で、アクセス制御リスト (ACL) を設定して、表示する

9.2.1. 対応している SMB プロトコルバージョン

cifs.ko カーネルモジュールは、以下の SMB プロトコルバージョンをサポートします。
  • SMB 1
  • SMB 2.0
  • SMB 2.1
  • SMB 3.0
注記
プロトコルのバージョンによっては、一部の SMB 機能しか実装されていません。

9.2.1.1. UNIX 拡張機能のサポート

Samba は、SMB プロトコルの CAP_UNIX 機能ビットを使用して UNIX 拡張機能を提供します。これらの拡張機能は、cifs.ko カーネルモジュールでも対応しています。ただし、Samba とカーネルモジュールはいずれも、SMB 1 プロトコルでのみ UNIX 拡張機能に対応します。
UNIX 拡張機能を使用するには、以下の手順を実行します。
  1. /etc/samba/smb.conf ファイルの [global] セクションの server min protocol オプションを NT1 に設定します。これは Samba サーバーのデフォルトです。
  2. マウントコマンドに -o vers=1.0 オプションを指定し、SMB 1 プロトコルを使用して 共有をマウント します。以下に例を示します。
    mount -t cifs -o vers=1.0,username=user_name //server_name/share_name /mnt/
    デフォルトで、カーネルモジュールは、SMB 2 またはサーバーでサポートされている最新のプロトコルバージョンを使用します。-o vers=1.0 オプションを mount コマンドに渡すと、UNIX 拡張機能の使用に必要な SMB 1 プロトコルをカーネルモジュールが使用することが強制されます。
UNIX 拡張機能が有効になっているかどうかを確認するには、マウントされた共有のオプションを表示します。
# mount
...
//server/share on /mnt type cifs (...,unix,...)
unix エントリーがマウントオプションのリストに表示されると、UNIX 拡張機能が有効になります。

9.2.2. SMB 共有の手動マウント

SMB 共有を手動でマウントするには、-t cifs パラメーターで mount ユーティリティーを使用します。
# mount -t cifs -o username=user_name //server_name/share_name /mnt/
Password for user_name@//server_name/share_name:  ********
-o options パラメーターでは、ファイル共有のマウントに使用されるオプションを指定できます。詳細は、mount.cifs(8) man ページの 「よく使用されるマウントオプション」 および 『OPTIONS』 セクションを参照してください。

例9.1 暗号化された SMB 3.0 接続を使用した共有のマウント

暗号化された SMB 3.0 接続でDOMAIN \ 管理者ユーザーとして \\サーバー\ の例を /mnt/ ディレクトリーにマウントするには、以下のコマンドを実行します。
# mount -t cifs -o username=DOMAIN\Administrator,seal,vers=3.0 //server/example /mnt/
Password for user_name@//server_name/share_name:  ********

9.2.3. システムの起動時の SMB 共有の自動マウント

システムの起動時に SMB 共有を自動的にマウントするには、共有のエントリーを /etc/fstab ファイルに追加します。以下に例を示します。
//server_name/share_name  /mnt  cifs  credentials=/root/smb.cred  0 0
重要
システムが自動的に共有をマウントできるようにするには、ユーザー名、パスワード、およびドメイン名を認証情報ファイルに保存する必要があります。詳細は 「認証情報ファイルを使用した SMB 共有への認証」 を参照してください。
/etc/fstab ファイルの 4 番目のフィールドに、認証情報ファイルへのパスなど、マウントオプションを指定します。詳細は、mount.cifs(8) man ページの 「よく使用されるマウントオプション」 および 『OPTIONS』 セクションを参照してください。
共有が正常にマウントされたことを確認する場合は、次のコマンドを実行します。
# mount /mnt/

9.2.4. 認証情報ファイルを使用した SMB 共有への認証

特定の状況では、ユーザー名とパスワードを入力することなく、管理者は共有をマウントする必要があります。これを実装するには、認証情報ファイルを作成します。以下に例を示します。

手順9.1 認証情報ファイルの作成

  1. ~/smb.cred などのファイルを作成し、そのファイルのユーザー名、パスワード、およびドメイン名を指定します。
    username=user_name
    password=password
    domain=domain_name
  2. 所有者だけがファイルにアクセスできるようにパーミッションを設定します。
    # chown user_name ~/smb.cred
    # chmod 600 ~/smb.cred
mount ユーティリティーに credentials=file_name マウントオプションを渡すか、/etc/fstab ファイルで使用して、ユーザー名とパスワードの入力を求められずに共有をマウントできます。

9.2.5. マルチユーザー SMB マウントの実行

共有をマウントするために指定した認証情報により、デフォルトでマウントポイントのアクセス権が決まります。たとえば、共有をマウントするときに DOMAIN\example ユーザーを使用する場合には、どのローカルユーザーが操作を実行するかにかかわらず、共有に対するすべての操作はこのユーザーとして実行されます。
ただし、特定の状況では、システムの起動時に管理者が自動的に共有をマウントしたい場合でも、ユーザーは自分の認証情報を使用して共有のコンテンツに対してアクションを実行する必要があります。multiuser マウントオプションを使用すると、このシナリオを設定できます。
重要
マルチユーザーを使用するには 認証情報ファイルの krb5 オプションや ntlmssp オプションなど、非対話式の方法で認証情報の提供に対応するセキュリティータイプに sec=security_type マウントオプションも設定する必要があります。「ユーザーとして共有へのアクセス」 を参照してください。
root ユーザーは、multiuser オプションと、共有のコンテンツへの最小限のアクセスを持つアカウントを使用して、共有をマウントします。通常のユーザーは、cifscreds ユーティリティーを使用して、現在のセッションのカーネルキーリングにユーザー名とパスワードを提供できます。マウントされた共有のコンテンツにユーザーがアクセスすると、カーネルは、共有のマウントに最初に使用されたものではなく、カーネルキーリングからの認証情報を使用します。

multiuser オプションを使用した共有のマウント

システムの起動時に、multiuser オプションを使用して自動的に共有をマウントするには、以下のコマンドを実行します。

手順9.2 multiuser オプションを使用した /etc/fstab ファイルパスの作成

  1. /etc/fstab ファイルに共有のエントリーを作成します。以下に例を示します。
    //server_name/share_name  /mnt  cifs  multiuser,sec=ntlmssp,credentials=/root/smb.cred  0 0
    
  2. 共有をマウントします。
    # mount /mnt/
システムの起動時に共有を自動的にマウントしない場合は、-o multiuser,sec=security_type を mount コマンドに渡すことで手動でマウントします SMB 共有の手動マウントの詳細は、「SMB 共有の手動マウント」 を参照してください。

SMB 共有がマルチユーザーオプションでマウントされている かどうかの確認

共有が multiuser オプションを使用してマウントされているかどうかを確認するには、以下を実行します
# mount
...
//server_name/share_name on /mnt type cifs (sec=ntlmssp,multiuser,...)

ユーザーとして共有へのアクセス

SMB 共有が multiuser オプションを使用して マウントされている場合、ユーザーはサーバーの認証情報をカーネルのキーリングに提供できます。
# cifscreds add -u SMB_user_name server_name
Password: ********
ユーザーがマウントされた SMB 共有を含むディレクトリーで操作を実行すると、サーバーは、共有がマウントされたときに最初に使用されたものではなく、このユーザーのファイルシステムのパーミッションを適用するようになりました。
注記
複数のユーザーが、マウントされた共有で、自身の認証情報を使用して同時に操作を実行できます。

9.2.6. よく使用されるマウントオプション

SMB 共有をマウントすると、マウントオプションにより次のことが決まります。
  • サーバーとの接続がどのように確立されるか。たとえば、サーバーに接続するときに使用される SMB プロトコルバージョンはどれか。
  • 共有が、ローカルファイルシステムにどのようにマウントされるか。たとえば、複数のローカルユーザーが、サーバーのコンテンツにアクセスできるようにするために、システムがリモートファイルとディレクトリーのパーミッションを上書きする場合など。
/etc/fstab ファイルの 4 番目のフィールド、またはマウント コマンドの -o パラメーターで複数のオプションを設定するには、コンマで区切ります。たとえば、手順9.2「multiuser オプションを使用した /etc/fstab ファイルパスの作成」 を参照してください。
以下は、よく使用されるマウントオプションの概要を示しています。

表9.1 よく使用されるマウントオプション

オプション 説明
credentials=file_name 認証情報ファイルへのパスを設定します。「認証情報ファイルを使用した SMB 共有への認証」 を参照してください。
dir_mode=mode サーバーが CIFS UNIX 拡張機能をサポートしていない場合は、ディレクトリーモードを設定します。
file_mode=mode サーバーが CIFS UNIX 拡張機能をサポートしていない場合は、ファイルモードを設定します。
password=password SMB サーバーへの認証に使用されるパスワードを設定します。または、credentials オプションを使用して 認証情報ファイルを指定します
seal SMB 3.0 以降のプロトコルバージョンを使用した接続に対する暗号化サポートを有効にします。そのため、seal、3.0 以降に設定された vers マウントオプションを一緒に使用します。例9.1「暗号化された SMB 3.0 接続を使用した共有のマウント」 を参照してください。
sec=security_mode
ntlmsspi などのセキュリティーモードを設定して、NTLMv2 パスワードハッシュとパケット署名を有効にします。サポートされる値の一覧は、mount.cifs(8) man ページのオプションの説明を参照してください。
サーバーが ntlmv2 セキュリティーモードに対応していない場合は、sec =ntlmssp (デフォルト)を使用します。セキュリティー上の理由から、安全でない ntlm セキュリティーモードは使用しないでください。
username=user_name SMB サーバーへの認証に使用されるユーザー名を設定します。または、credentials オプションを使用して 認証情報ファイルを指定します
vers=SMB_protocol_version サーバーとの通信に使用される SMB プロトコルバージョンを設定します。
完全なリストは、mount.cifs(8) man ページの 『OPTIONS』 セクションを参照してください。

第10章 FS-Cache

FS-Cache は、ファイルシステムがネットワーク経由で取得したデータをローカルディスクにキャッシュするためにファイルシステムで使用できる永続的なローカルキャッシュです。これは、ネットワーク経由でマウントされたファイルシステムからデータにアクセスするユーザーのネットワークトラフィックを最小限に抑えます (例: NFS)。
以下の図は、FS-Cache の仕組みの概要を示しています。

図10.1 FS-Cache の概要

FS-Cache の概要
FS-Cache は、システムのユーザーおよび管理者が可能な限り透過的になるように設計されています。Solaris では cachefs とは異なり、サーバー上のファイルシステムは、オーバーマウントしたファイルシステムを作成せずにクライアントのローカルキャッシュと直接対話できます。NFS では、マウントオプションにより、FS-cache が有効になっている NFS 共有をマウントするようにクライアントに指示します。
FS-Cache はネットワーク上で機能するファイルシステムの基本操作を変更せず、単にデータをキャッシュできる永続的な場所でファイルシステムを提供するだけです。たとえば、クライアントは FS-Cache が有効になっているかどうかに関わらず、NFS 共有をマウントできます。さらに、キャッシュされた NFS は、ファイルが部分的にキャッシュされ、事前完全に読み込む必要がないため、ファイル(個別または一括)に収まらないファイルを処理できます。また、FS-Cache は、クライアントファイルシステムドライバーからキャッシュで発生するすべての I/O エラーも非表示にします。
キャッシングサービスを提供するには、キャッシュバックエンド が必要です。キャッシュバックエンドは、キャッシュサービスを提供するように設定されたストレージドライバーです(例: cachefiles)。この場合、FS-Cache では、キャッシュバックエンドとして、bmap および拡張属性(ext3 など)に対応するブロックベースのファイルシステムをマウントする必要があります。
FS-Cache は、ネットワーク経由の有無に関係なく、ファイルシステムを任意にキャッシュすることはできません。共有ファイルシステムのドライバーを変更して、FS-Cache、データストレージ/検索、メタデータのセットアップと検証を操作できるようにする必要があります。FS-Cache では、永続性に対応するためにキャッシュされたファイルシステムのインデックス キーと 整合性データ が必要です。インデックスキーはファイルシステムオブジェクトをキャッシュオブジェクトに一致させ、一貫性データを使用してキャッシュオブジェクトが有効であるかどうかを判断します。
注記
Red Hat Enterprise Linux 7 では、cachefilesd パッケージはデフォルトでインストールされていないため、手動でインストールする必要があります。

10.1. Performance Guarantee

FS-Cache はパフォーマンスを改善し ませんが、ネットワークの輻輳を回避することで、パフォーマンスの一貫性が確保されます。キャッシュバックエンドを使用するとパフォーマンスが低下します。たとえば、キャッシュされた NFS 共有の場合、ネットワーク間のルックアップにディスクアクセスが追加されます。FS-Cache は可能な限り非同期となりますが、これができない同期パス(読み取りなど)があります。
たとえば、FS-Cache を使用して、本来はladen GigE ネットワークを介して 2 台のコンピューター間の NFS 共有をキャッシュしても、ファイルアクセスのパフォーマンスは向上するわけではありません。代わりに、NFS 要求はローカルディスクからではなく、サーバーメモリーより早く満たされます。
したがって、FS-Cacheの使用は、さまざまな要因における 妥協 です。たとえば、NFS トラフィックのキャッシュに FS-Cache を使用すると、クライアントは多少遅くなりますが、ネットワークの帯域幅を消費せずにローカルに読み取り要求を満たすことでネットワークおよびサーバーの読み込み負荷が大幅に削減されます。

10.2. キャッシュの設定

現在、Red Hat Enterprise Linux 7 は cachefiles キャッシュバックエンド のみを提供します。cachefilesd デーモンは cachefiles を開始し、管理します。/etc/cachefilesd.conf ファイルは、cachefiles がキャッシュサービスを提供する方法を制御します。
キャッシュバックエンドで設定する最初の設定は、キャッシュとして使用するディレクトリーになります。これを設定するには、以下のパラメーターを使用します。
$ dir /path/to/cache
通常、キャッシュバックエンドディレクトリーは、以下のように /etc/cachefilesd.conf/var/cache/fscache として設定されます。
$ dir /var/cache/fscache
キャッシュバックエンドディレクトリーを変更する場合は、selinux コンテキストを /var/cache/fscache と同じにする必要があります。
# semanage fcontext -a -e /var/cache/fscache /path/to/cache
# restorecon -Rv /path/to/cache
キャッシュの設定中に、/path/to/cache をディレクトリー名に置き換えます。
注記
selinux コンテキストを設定するコマンドが機能しない場合は、以下のコマンドを使用します。
# semanage permissive -a cachefilesd_t
# semanage permissive -a cachefiles_kernel_t
FS-Cache は、/path/to/cache をホストするファイルシステムにキャッシュを保存します。ラップトップでは、root ファイルシステム(/)をホストのファイルシステムとして使用することが推奨されますが、デスクトップマシンでは、キャッシュ専用のディスクパーティションをマウントする方がはるかに優れています。
FS-Cache のキャッシュバックエンドで必要とされる機能をサポートするファイルシステムには、以下のファイルシステムの Red Hat Enterprise Linux 7 実装が含まれます。
  • ext3 (拡張属性が有効)
  • ext4
  • Btrfs
  • XFS
ホストファイルシステムはユーザー定義の拡張属性に対応する必要があります。FS-Cache はこの属性を使用して、整合性のメンテナンス情報を保存します。ext3 ファイルシステム(つまり デバイス)のユーザー定義の拡張属性を有効にするには、以下を使用します。
# tune2fs -o user_xattr /dev/device
または、以下のように、マウント時にファイルシステムの拡張属性を有効にできます。
# mount /dev/device /path/to/cache -o user_xattr
キャッシュバックエンドは、キャッシュをホストしているパーティション上の一定の空き領域を維持することで動作します。空き領域を使用する他の要素に応じてキャッシュを増大および縮小し、root ファイルシステム (ラップトップなど) で安全に使用できるようにします。FS-Cache はこの動作にデフォルトを設定し、キャッシュカリング制限 で設定できます。キャッシュカリング制限の設定に関する詳細は、「キャッシュカリング制限の設定」 を参照してください。
設定ファイルが導入されたら、cachefilesd サービスを起動します。
# systemctl start cachefilesd
起動時に cachefilesd が起動するように設定するには、root で以下のコマンドを実行します。
# systemctl enable cachefilesd

10.3. NFS でのキャッシュの使用

明示的に指示されない限り、NFS はキャッシュを使用しません。FS-Cache を使用するように NFS マウントを設定するには、mount コマンドに -o fsc オプションを追加します。
# mount nfs-share:/ /mount/point -o fsc
ファイルがダイレクト I /O や書き込みのために開いていない限り、/mount/point の下にあるファイルへのアクセスはすべてキャッシュを通過します。詳細は、「NFS とのキャッシュ制限」 を参照してください。NFS インデックスは NFS ファイルハンドルを使用してコンテンツをキャッシュします。ファイル名ではなく、ハードリンクされたファイルはキャッシュを正しく共有します。
キャッシュは、NFS のバージョン 2、3、および 4 でサポートされます。ただし、各バージョンはキャッシュに異なるブランチを使用します。

10.3.1. キャッシュ共有

NFS キャッシュの共有には潜在的な問題がいくつかあります。キャッシュは永続的であるため、キャッシュ内のデータブロックは 4 つのキーのシーケンスでインデックス化されます。
  • レベル 1: サーバーの詳細
  • レベル 2: 一部のマウントオプション、セキュリティータイプ、FSID、識別子
  • レベル 3: ファイルハンドル
  • レベル 4: ファイル内のページ番号
スーパーブロック間の整合性の管理の問題を回避するには、データのキャッシュが必要なすべての NFS スーパーブロックには、一意のレベル 2 キーがあります。通常、同じソースボリュームとオプションを持つ 2 つの NFS マウントはスーパーブロックを共有しているため、そのボリューム内に異なるディレクトリーをマウントする場合でもキャッシュを共有することになります。

例10.1 キャッシュ共有

以下の 2 つの マウント コマンドを取ります。
mount home0:/disk0/fred /home/fred -o fsc
mount home0:/disk0/jim /home/jim -o fsc
/home/fred および /home/jim には同じオプションがあるため、スーパーブロックを共有する可能性が高くなります。特に NFS サーバーの同じボリューム/パーティションからのものである場合(home0)。ここで、次の 2 つの mount コマンドについて見てみましょう。
mount home0:/disk0/fred /home/fred -o fsc,rsize=230
mount home0:/disk0/jim /home/jim -o fsc,rsize=231
この場合、/home/fred/home/jim は、レベル 2 キーの一部であるネットワークアクセスパラメーターが異なるため、スーパーブロックを共有しません。以下のマウントシーケンスでも同じことが言えます。
mount home0:/disk0/fred /home/fred1 -o fsc,rsize=230
mount home0:/disk0/fred /home/fred2 -o fsc,rsize=231
ここでは、2 つのサブツリー(/home/fred1/home/fred2)の内容が 2 回 キャッシュされます。
スーパーブロックの共有を回避するもう 1 つの方法は、nosharecache パラメーターで明示的に共有を抑制することです。同じ例を使用します。
mount home0:/disk0/fred /home/fred -o nosharecache,fsc
mount home0:/disk0/jim /home/jim -o nosharecache,fsc
ただし、この場合は、レベル 2 キーの home0:/disk0/fred および home0:/disk0/ jim を区別するものがないため、スーパーブロックは 1 つのみとなります。これに対処するには、少なくとも 1 つのマウント に一意の ID (つまり. fsc=unique-identifier )を追加します。以下に例を示します。
mount home0:/disk0/fred /home/fred -o nosharecache,fsc
mount home0:/disk0/jim /home/jim -o nosharecache,fsc=jim
ここでは、/home/jim のキャッシュで使用されるレベル 2 キーに一意の識別子の jim が追加されます。

10.3.2. NFS とのキャッシュ制限

  • ダイレクト I/O で共有ファイルシステムからファイルを開くと、自動的にキャッシュが回避されます。これは、この種のアクセスがサーバーに直接行なわれる必要があるためです。
  • 共有ファイルシステムからファイルを開いて書き込みを行うと、NFS バージョン 2 および 3 で動作しません。これらのバージョンのプロトコルでは、クライアントが別のクライアントから同じファイルへの同時書き込みを検出できるように十分な一貫性管理情報が提供されていません。
  • ダイレクト I/O または書き込みのいずれかで共有ファイルシステムからファイルを開くと、キャッシュされたファイルのコピーがフラッシュされます。ダイレクト I/O や書き込みのためにファイルが開かれなくなるまで、FS-Cache はファイルを再キャッシュしません。
  • さらに、FS-Cache の今回のリリースでは、通常の NFS ファイルのみをキャッシュします。FS-Cache はディレクトリー、シンボリックリンク、デバイスファイル、FIFO、ソケットを キャッシュしません

10.4. キャッシュカリング制限の設定

cachefilesd デーモンは、共有ファイルシステムからのリモートデータをキャッシュして、ディスクの空き領域を解放することで機能します。これにより、利用可能な空き領域がすべて消費される可能性があり、ディスクがルートパーティションも格納している場合は問題になる可能性があります。これを制御するために、cachefilesd は古いオブジェクト(つまり最近のアクセスが少ないオブジェクト)をキャッシュから破棄して、一定量の空き領域を維持しようとします。この動作は キャッシュカリング と呼ばれます
キャッシュカリングは、基盤となるファイルシステムで使用可能なブロックのパーセンテージとファイルのパーセンテージに基づいて行われます。/etc/cachefilesd.conf には、設定の制御が 6 つあります。
brun N%(ブロックのパーセンテージ) , frun N%(ファイルのパーセンテージ)
キャッシュの空き領域と利用可能なファイルの数がこれらの制限を上回ると、カリングはオフになります。
bcull N%(ブロックのパーセンテージ), % ファイルのパーセンテージ)
キャッシュの空き領域と利用可能なファイルの数がこれらの制限のいずれかを下回ると、カリング動作が開始します。
bstop N%(ブロックのパーセンテージ), fstop N%(ファイルのパーセンテージ)
キャッシュ内の使用可能な領域または使用可能なファイルの数がこの制限のいずれかを下回ると、カリングによってこれらの制限を超える状態になるまで、ディスク領域またはファイルのそれ以上の割り当ては許可されません。
各設定の N のデフォルト値は以下の通りです。
  • brun/frun - 10%
  • bcull/fcull - 7%
  • bstop/fstop - 3%
この設定を行う場合は、以下の条件を満たす必要があります。
  • 0 dNSName bstop <bcull <brun < 100
  • 0 ≤ fstop < fcull < frun < 100
これは、利用可能な領域と利用可能なファイルの割合であり、100 から df プログラムで表示される割合を引いたものではありません。
重要
カリングは、bxxx と fxxx のペアを同時に依存せず、個別に処理することはできません。

10.5. 統計情報

FS-Cache は一般的な統計情報も追跡します。この情報を表示するには、以下を使用します。
# cat /proc/fs/fscache/stats
FS-Cache の統計にはディシジョンポイントとオブジェクトカウンターに関する情報が含まれます。詳細は、以下のカーネルドキュメントを参照してください。
/usr/share/doc/kernel-doc-version/Documentation/filesystems/caching/fscache.txt

10.6. FS-Cache リファレンス

cachefilesd の詳細および設定方法は、man cachefilesd および man cachefilesd.conf を参照してください。その他にも、以下のカーネルドキュメントを参照してください。
  • /usr/share/doc/cachefilesd-version-number/README
  • /usr/share/man/man5/cachefilesd.conf.5.gz
  • /usr/share/man/man8/cachefilesd.8.gz
設計の制約、利用可能な統計、および機能など、FS-Cache に関する一般的な情報は、/usr/share/doc/kernel-doc-バージョン/Documentation/filesystems/caching/fscache.txtを参照してください。

パート II. ストレージ管理

「ストレージ管理」のセクションは、Red Hat Enterprise Linux 7 におけるストレージに関する考慮事項から始まります。パーティション、論理ボリューム管理、および swap パーティションに関する手順は、次のとおりです。ディスククォータ、RAID システムの横には、mount コマンド、volume_key、および acls の関数が続きます。SSD のチューニング、書き込みバリア、I/O 制限およびディスクレスシステムは、これに従います。Online Storage の大きな章は次に行われ、最後にデバイスマッパーのマルチパスおよび仮想ストレージを終了させます。

第11章 インストール時のストレージの考慮事項

多くのストレージデバイスおよびファイルシステムの設定は、インストール時にのみ設定できます。ファイルシステムタイプなどの他の設定は、再フォーマットを必要とせずに特定の時点までしか変更できません。そのため、Red Hat Enterprise Linux 7 をインストールする前に、ストレージ設定の計画を立てることが推奨されます。
本章では、システムのストレージ設定を計画する際に、いくつかの考慮事項を説明します。インストールの手順(インストール時のストレージ設定を含む)については、Red Hat が提供する インストールガイド を参照してください。
Red Hat がサイズおよびストレージの制限に関して正式にサポートする内容については、アーティクル を参照してください http://www.redhat.com/resourcelibrary/articles/articles-red-hat-enterprise-linux-6-technology-capabilities-and-limits

11.1. 特別な考慮事項

本セクションでは、複数の問題および特定のストレージ設定について考慮すべき要素について説明します。

/home、/opt、/usr/local の個別パーティション

システムを今後アップグレードできる場合は、別のデバイスに /home、/opt、および /usr/local を配置します。これにより、ユーザーおよびアプリケーションデータを保存しながら、デバイスまたはオペレーティングシステムが含まれるファイルシステムを再フォーマットできます。

IBM System Z の DASD および zFCP デバイス

IBM System Z プラットフォームでは、DASD デバイスおよび zFCP デバイスは、Channel Command Word (CCW)メカニズムで設定されます。CCW パスはシステムに明示的に追加してから、オンラインに取り込む必要があります。DASD デバイスの場合は、ブートコマンドラインまたは CMS 設定ファイルに、デバイス番号(またはデバイス番号の範囲)を DASD= パラメーターとして一覧表示します。
zFCP デバイスの場合は、デバイス番号、論理ユニット番号(LUN)、および World wide port name (WWPN)を一覧表示する必要があります。zFCP デバイスを初期化すると、CCW パスにマッピングされます。ブートコマンドライン(または CMS 設定ファイル)の FCP_x= 行で、インストーラー用にこの情報を指定できます。

LUKS を使用したブロックデバイスの暗号化

LUKS/dm-crypt を使用して暗号化用にブロックデバイスをフォーマットすると、そのデバイスにある既存のフォーマットがなくなります。したがって、インストールプロセスの一部として、新しいシステムのストレージ設定をアクティベートする前に、暗号化するデバイス(ある場合)を決定する必要があります。

古くなった BIOS RAID メタデータ

ディスクから RAID メタデータ を削除せずに、ファームウェア RAID 用に設定したシステムからディスクを移動すると、Anaconda がディスク を正しく検出できなくなります。
警告
ディスクから RAID メタデータを削除/削除すると、保存されたデータがすべて破棄される可能性があります。Red Hat は、先に進む前にデータのバックアップを作成することを推奨します。
注記
非推奨となった dmraid を使用して RAID ボリュームを作成したら、dmraid ユーティリティーを使用して削除します。
# dmraid -r -E /device/
RAID デバイスの管理に関する詳細は、man dmraid および 18章RAID(Redundant Array of Independent Disks) を参照してください。

iSCSI の検出および設定

iSCSI ドライブのプラグインおよびプレイの検出の場合は、iBFT ブート対応 ネットワークインターフェースカード (NIC)のファームウェアで設定します。iSCSI ターゲットの CHAP 認証は、インストール時にサポートされます。ただし、iSNS 検出はインストール時にはサポートされません。

FCoE の検出および設定

FCoE( Fibre Channel over Ethernet )ドライブのプラグインおよびプレイ検出には、EDD ブート対応 NIC のファームウェアを設定します。

DASD

DASD (ダイレクトアクセス ストレージデバイス)は、インストール時に追加または設定することはできません。このようなデバイスは、CMS 設定ファイルで指定します。

DIF/DIX が有効になっているブロックデバイス

DIF/DIX は、特定の SCSI ホストバスアダプターおよびブロックデバイスが提供するハードウェアのチェックサム機能です。DIF/DIX が有効になっている場合、ブロックデバイスが汎用ブロックデバイスとして使用されているとエラーが発生します。バッファーされた I/O または mmap(2)- ベースの I/O は、バッファー書き込みパスに相互ロックがなく、DIF/DIX チェックサムが計算された後にバッファーデータが上書きされないようにします。
これにより、I/O はチェックサムエラーで失敗します。この問題は、すべてのブロックデバイス(またはファイルシステムベース)バッファー I/O または mmap(2) I/O に共通しているので、上書きによってこれらのエラーを回避することはできません。
したがって、DIF/DIX が有効になっているブロックデバイスは、O _DIRECT を使用するアプリケーションとのみ使用してください。このようなアプリケーションは raw ブロックデバイスを使用する必要があります。別の方法として、ファイルシステムを介して O_DIRECT I/O のみを発行している限り、DIF/DIX が有効なブロックデバイスで XFS ファイルシステムを安全に使用できます。XFS は、特定の割り当て操作を実行する際にバッファー I/O にフォールバックしない唯一のファイルシステムです。
DIF/DIX チェックサムがアプリケーションとともに計算された後に I/O データが変更されないようにする責任は、引き続き O_DIRECT I/O および DIF/DIX ハードウェアで使用するように設計されたアプリケーションのみが DIF/DIX を使用する必要があります。

第12章 ファイルシステムチェック

ファイルシステムは、ファイルシステム固有のユーザー空間ツールと共に一貫性があり、オプションで修復することができます。このツールは、通常 fsck ツールとも呼ばれていますfsck は、ファイルシステムチェックの短いバージョンです
注記
これらのファイルシステムチェッカーは、ファイルシステム全体でメタデータの整合性を保証するだけです。ファイルシステムに含まれる実際のデータを認識せず、データ復旧ツールではありません。
ファイルシステムの不整合は、ハードウェアエラー、ストレージ管理エラー、ソフトウェアバグなどのさまざまな理由で発生する可能性があります。
最新のメタデータジャーナリングファイルシステムが一般的になる前に、システムがクラッシュしたときや電源が失われた時に、ファイルシステムのチェックが必要でした。これは、ファイルシステムの更新が中断されたためにあり、その結果、整合性のない状態があったためです。その結果、ファイルシステムの確認は、通常、起動時に /etc/fstab に記載されている各ファイルシステムで実行されます。ジャーナリングファイルシステムの場合、ファイルシステムのメタデータジャーナリングによりクラッシュ後も一貫性が確保されるため、通常は非常に短い操作になります。
ただし、ジャーナリングファイルシステムであっても、ファイルシステムが不整合や破損が発生する場合もあります。この場合は、ファイルシステムチェッカーを使用してファイルシステムを修復する必要があります。以下は、この手順を実行する際にベストプラクティスおよび他の有用な情報を提供します。
重要
Red Hat は、マシンが起動しない、ファイルシステムが非常に大きいか、ファイルシステムがリモートストレージ上にある限り、Red Hat はこれを推奨しません。/etc/fstab の 6 番目のフィールドを 0 に設定すると、システムの起動時にファイルシステムの確認を無効にできます。

12.1. fsck のベストプラクティス

通常、ファイルシステムの確認および修復のツールを実行すると、検出された不整合の少なくとも一部が自動的に修復されることが期待できます。inode やディレクトリーが大幅に損傷し、修復できない場合は、破棄される可能性があります。ファイルシステムが大きく変更する場合があります。予期しない変更や望ましくない変更が永続的に行われないようにするには、以下の予防手順を実行してください。
ドライラン
ほとんどのファイルシステムチェッカーにはチェックする操作モードがありますが、ファイルシステムを修復しない操作モードがあります。このモードでは、チェッカーは、実際にファイルシステムを変更せずに、作成したこととアクションを見つけたエラーを出力します。
注記
整合性の確認後のフェーズでは、修復モードで実行していた場合に前のフェーズで修正されていた不整合が検出される可能性があるため、追加のエラーが出力される場合があります。
ファイルシステムイメージで初めて操作
ほとんどのファイルシステムは、メタデータイメージの作成、メタデータのみを含むファイルシステムのスパースコピーの作成をサポートします。ファイルシステムチェッカーはメタデータでのみ動作するため、このようなイメージを使用して、実際のファイルシステムの修復のドライランを実行し、実際にどのような変更が行われているかを評価できます。変更が許容可能である場合は、ファイルシステム自体で修復を実行できます。
注記
ファイルシステムが大幅に損傷している場合は、メタデータイメージの作成に関連して問題が発生する可能性があります。
サポート調査のためにファイルシステムイメージを保存する
修復前のファイルシステムメタデータイメージは、ソフトウェアのバグにより破損している可能性がある場合に、サポート調査に役立ちます。修復前のイメージに含まれる破損のパターンは、根本原因の分析に役に立つ場合があります。
アンマウントされたファイルシステムでのみ操作
ファイルシステムの修復は、マウント解除されたファイルシステムでのみ実行する必要があります。このツールは、ファイルシステムにアクセスできるか、またはそれ以上の破損が発生する可能性があります。ほとんどのファイルシステムツールは、この要件を修復モードで強制します。ただし、マウントされたファイルシステムでの check-only モードのみをサポートするものもあります。マウントされたファイルシステムで check-only モードを実行すると、マウント解除されたファイルシステムで実行した場合に検出されない誤ったエラーが発生する可能性があります。
ディスクエラー
ファイルシステムの確認ツールは、ハードウェアの問題を修復できません。修復を正常に動作させるには、ファイルシステムが完全に読み取り可能かつ書き込み可能である必要があります。ハードウェアエラーが原因でファイルシステムが破損した場合は、まず dd(8) ユーティリティーなどを使用して、ファイルシステムを適切なディスクに移動する必要があります。

12.2. fsck のファイルシステム固有の情報

12.2.1. ext2、ext3、および ext4

これらのファイルはすべて、e2fsck バイナリーを使用して、ファイルシステムの確認と修復を実行します。ファイル名の fsck.ext2fsck.ext3、および fsck.ext4 はこの、同じバイナリーへのハードリンクです。これらのバイナリーは、システムの起動時に自動的に実行し、その動作は確認されるファイルシステムと、そのファイルシステムの状態によって異なります。
完全なファイルシステムの確認および修復は、メタデータジャーナリングファイルシステムではない ext2 や、ジャーナルのない ext4 ファイルシステムに対して呼び出されます。
メタデータジャーナリング機能を備えた ext3 ファイルシステムおよび ext4 ファイルシステムの場合、ジャーナルはユーザー空間で再生され、バイナリーは終了します。これは、ジャーナルの再生がデフォルトとなるため、クラッシュ後にファイルシステムの一貫性が確保されます。
このファイルシステムで、マウント中にメタデータの不整合が生じると、その事実がファイルシステムのスーパーブロックに記録されます。e2fsck が、このようなエラーでファイルシステムがマークされていることを検出すると、e2fsck はジャーナル(ある場合)の再生後にフルチェックを実行します。
e2fsck は、- p オプションが指定されていない場合に、実行時にユーザー入力を要求する可能性があります。-p オプションは、e2fsck に対して、安全に実行できるすべての修復を自動的に実行するように指示します。ユーザーの介入が必要な場合は、e2fsck が出力の未修正の問題を示し、このステータスを終了コードに反映させます。
一般的に使用される e2fsck ランタイムオプションは次のとおりです。
-n
変更なしモード。チェックのみの操作。
-b superblock
プライマリーが破損している場合は、別の suprerblock のブロック番号を指定します。
-f
スーパーブロックにエラーが記録されなくても、強制的に完全なチェックを行います。
-j journal-dev
外部ジャーナルデバイスを指定します(ある場合)。
-p
ユーザー入力のないファイルシステムを自動的に修復するか、または「preen」します。
-y
すべての質問に対する「yes」の回答を想定します。
e2fsck のすべてのオプションは、man ページの e2fsck(8) で指定します。
以下の 5 つの基本的なフェーズは、実行中に e2fsck により実行されます。
  1. inode、ブロック、およびサイズチェック。
  2. ディレクトリー構造はチェックします。
  3. ディレクトリーの接続性チェック。
  4. 参照カウントチェック。
  5. グループサマリー情報チェック。
e2image(8) ユーティリティーを使用すると、診断またはテスト目的で修復する前にメタデータイメージを作成できます。ファイルシステム自体と同じサイズのスパースファイルを作成するには、- r オプションは、テスト目的に使用する必要があります。その後、e2fsck は、作成されたファイルで直接操作できます。イメージがアーカイブ化または診断用に提供されている場合は、- Q オプションを指定する必要があります。これにより、転送に適したよりコンパクトなファイル形式が作成されます。

12.2.2. XFS

システムの起動時に自動的に修復は実行されません。ファイルシステムの確認または修復を開始するには、xfs_repair ツールを使用します。
注記
fsck.xfs バイナリーは xfsprogs パッケージに存在しますが、起動時に fsck.ファイルシステム バイナリーを検索する initscripts を満たすためにのみ存在します。fsck.xfs は、すぐに終了コード 0 で終了します。
以前の xfsprogs パッケージには xfs_check ツールが含まれています。このツールは非常に遅いため、大きなファイルシステムで適切にスケーリングできません。このため、xfs_repair -n が導入されたため非推奨になりました。
xfs_repair が機能するには、ファイルシステムでクリーンなログが必要です。ファイルシステムがクリーンにアンマウントされていない場合は、xfs_repair を使用する前にマウントしてアンマウントする必要があります。ログが破損し、再生できない場合は、- L オプションを使用してログゼロを使用できます。
重要
-L オプションは、ログを再生できない場合に限り使用する必要があります。このオプションは、ログ内のすべてのメタデータ更新を破棄して、さらに不整合が生じます。
-n オプションを使用して、xfs_repair をドライランモードで実行することが可能です。このオプションを指定すると、ファイルシステムに変更を加えません。
xfs_repair は、非常に多くのオプションを取ります。一般的に使用されるオプションは次のとおりです。
-n
変更モードがありません。チェックのみの操作。
-L
メタデータログ以外のもの。マウントでログを再生できない場合に限り使用してください。
-m maxmem
実行中に使用されるメモリーを maxmem MB に制限します。0 を指定すると、必要な最小メモリー量の推定値を取得できます。
-L logdev
外部ログデバイスが存在する場合は指定します。
xfs_repair のすべてのオプションは、man ページの xfs_repair(8) で指定します。
以下の 3 つの基本的なフェーズは、実行中の xfs_repair によって実行されます。
  1. inode および inode ブロックマップ(アドレス)チェック。
  2. inode の割り当てマップをチェックします。
  3. inode のサイズチェック。
  4. ディレクトリーをチェックします。
  5. パス名のチェック。
  6. リンクカウントチェック。
  7. Freemap チェック。
  8. スーパーブロックチェック。
詳細は、xfs_repair(8) の man ページを参照してください。
xfs_repair は対話的ではありません。すべての操作は、ユーザーからの入力なしで自動的に実行されます。
診断またはテスト目的で修復する前にメタデータイメージを作成する場合は、xfs_metadump(8) ユーティリティーおよび xfs_mdrestore(8) ユーティリティーを使用できます。

12.2.3. Btrfs

注記
Btrfs は、Red Hat Enterprise Linux 7 ではテクノロジープレビューとして利用できますが、Red Hat Enterprise Linux 7.4 リリース以降では非推奨になりました。Red Hat Enterprise Linux の将来のメジャーリリースで削除される予定です。
詳細は、『Red Hat Enterprise Linux 7.4 リリースノート』の「非推奨の機能」を参照してください。
btrfsck ツールは、btrfs ファイルシステムの確認および修復に使用されます。このツールは開発の初期段階にあり、すべてのタイプのファイルシステムの破損を検出または修復することができません。
デフォルトでは、btrfsck はファイルシステムに変更を加えません。つまり、デフォルトではチェックモードが実行されます。修復が必要な場合は 、--repair オプションを指定する必要があります。
以下の 3 つのフェーズは、実行中に btrfsck により実行されます。
  1. エクステントのチェック。
  2. ファイルシステムの root チェック
  3. ルート参照数チェック。
btrfs-image(8) ユーティリティーを使用すると、診断またはテスト目的で修復する前にメタデータイメージを作成できます。

第13章 Partitions

注記
ブロックデバイスでパーティションを使用する長所と短所の概要は、ナレッジベースの記事を参照してください https://access.redhat.com/solutions/163853
parted ユーティリティーを使用すると、以下が可能になります。
  • 既存のパーティションテーブルを表示します。
  • 既存パーティションのサイズを変更します。
  • 空き領域または追加のハードドライブからパーティションを追加します。
parted パッケージは、Red Hat Enterprise Linux 7 にデフォルトでインストールされています。parted を起動するには、root でログインして以下のコマンドを入力します。
# parted /dev/sda
/dev/sda を、設定するドライブのデバイス名に置き換えます。

使用中のデバイスでのパーティションの操作

デバイスを使用しないようにするには、デバイスのパーティションを何もマウントできず、デバイスの swap 領域は有効にできません。
パーティションを削除またはサイズ変更する場合は、パーティションが存在するデバイスは使用されていない。
使用中のデバイスに新しいパーティションを作成することは可能ですが、これは推奨されません。

パーティションテーブルの変更

同じディスクの別のパーティションが使用中の間にパーティションテーブルを変更することは、通常、パーティションテーブルを再読み取りできないため推奨されません。したがって、変更は実行中のシステムには適用されません。このような場合、システムを再起動するか、以下のコマンドを使用して、システムが新規または変更されたパーティションを登録するようにします。
# partx --update --nr partition-number disk
現在使用中のディスクを変更する最も簡単な方法は、以下のとおりです。
  1. システムディスクの場合など、ディスクのパーティションをアンマウントできない場合には、レスキューモードでシステムを起動します。
  2. ファイルシステムをマウントするように指示されたら、スキップ を選択します。
ドライブに使用中のパーティションが含まれていない場合には、ファイルシステムをアンマウントしたりロックしたりするシステムプロセスがない場合は、umount コマンドを使用してパーティションをアンマウントし、swapoff コマンドを使用して、ハードドライブ上のスワップ領域をすべてオフにできます。
一般的に使用される parted コマンドの詳細は表13.1「parted コマンド」 を参照してください。
重要
parted ユーティリティーを使用してファイルシステムを作成しないでください。代わりに mkfs ツールを使用してください。

表13.1 parted コマンド

コマンド 説明
help 利用可能なコマンド一覧の表示
mklabel label パーティションテーブルのディスクラベルを作成
mkpart part-type [fs-type] start-mb end-mb 新しいファイルシステムを作成せずにパーティションを作成する
name minor-num name Mac および PC98 ディスクラベルのパーティションのみに名前を付けます
print パーティションテーブルの表示
quit parted の終了
rescue start-mb end-mb 失われたパーティションを start-mb から end-mb にレスキューする
rm minor-num パーティションを削除する
デバイスの選択 設定する別のデバイスを選択する
set minor-num flag state パーティションにフラグを設定します。状態は オンまたはオフになります。
[NUMBER [FLAG] の切り替え パーティション NUMBERFLAG の状態の切り替え
ユニット UNIT デフォルトのユニットを UNITに設定します。

13.1. パーティションテーブルの表示

パーティションテーブルを表示するには、次のコマンドを実行します。
  1. parted を起動します。
  2. パーティションテーブルを表示するには、次のコマンドを使用します。
    (parted) print
以下のような表が表示されます。

例13.1 パーティションテーブル

Model: ATA ST3160812AS (scsi)
Disk /dev/sda: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size    Type      File system  Flags
 1      32.3kB  107MB  107MB   primary   ext3         boot
 2      107MB   105GB  105GB   primary   ext3
 3      105GB   107GB  2147MB  primary   linux-swap
 4      107GB   160GB  52.9GB  extended		      root
 5      107GB   133GB  26.2GB  logical   ext3
 6      133GB   133GB  107MB   logical   ext3
 7      133GB   160GB  26.6GB  logical                lvm
パーティションテーブルの説明は次のとおりです。
  • Model: ATA ST3160812AS(scsi) は、ディスクタイプ、製造元、モデル番号、インターフェースについて説明しています。
  • ディスク /dev/sda: 160GB: ブロックデバイスへのファイルパスとストレージ容量を表示します。
  • Partition Table: msdos : ディスクラベル の種類を表示します。
  • パーティションテーブルの Number は、パーティション番号です。たとえば、マイナー番号 1 のパーティションは、/dev/sda1 に対応します。Start および End の値はメガバイトです。有効な Types はメタデータ、フリー、プライマリー、拡張、または論理です。File system はファイルシステムタイプです。The Flags column: パーティションに設定したフラグを一覧表示します。利用可能なフラグは、boot、root、swap、hidden、raid、lvm、または lba です。
パーティションテーブルの File system は、以下のいずれかです。
  • ext2
  • ext3
  • fat16
  • fat32
  • hfs
  • jfs
  • linux-swap
  • ntfs
  • reiserfs
  • hp-ufs
  • sun-ufs
  • xfs
デバイスの File system に値が表示されない場合は、そのファイルシステムタイプが不明であることを示します。
注記
parted を再起動することなく別のデバイスを選択するには、以下のコマンドを使用して、/dev/sda を、選択したデバイスに置き換えます。
(parted) select /dev/sda
これにより、デバイスのパーティションテーブルを表示または設定できます。

13.2. パーティションの作成

警告
使用中のデバイスにパーティションを作成しないでください。

手順13.1 パーティションの作成

  1. パーティションを作成するか、レスキューモードで起動する前に、デバイスのパーティションをアンマウントして、デバイスの swap 領域をオフにします。
  2. parted を起動します。
    # parted /dev/sda
    /dev/sda を、パーティションを作成するデバイス名に置き換えます。
  3. 現在のパーティションテーブルを表示し、十分な空き領域があるかどうかを確認します。
    (parted) print
    十分な空き容量がない場合は、既存のパーティションのサイズを変更できます。詳細は、「fdisk を使用したパーティションのサイズ変更」 を参照してください。
    パーティションテーブルから、新しいパーティションの開始点と終了点と、そのパーティションタイプを決定します。デバイスに拡張パーティションがない、4 つのプライマリーパーティションのみを使用できます。4 つ以上のパーティションが必要な場合は、拡張内に 3 つのプライマリーパーティション、1 つの拡張パーティション、および複数の論理パーティションを設定できます。ディスクパーティションの概要は、『Red Hat Enterprise Linux 7 インストールガイド』の「ディスクパーティションの概要 」を参照してください
  4. パーティションを作成するには、以下を行います。
    (parted) mkpart part-type name fs-type start end
    part-type を、要件に応じて primary、logical、または extended に置き換えます。
    name を partition-name に置き換えます。GPT パーティションテーブルには名前が必要です。
    fs-type を、btrfs、ext2、ext2、ext4、fat16、fat32、hfs、hfs+、linux-swap、ntfs、reiserfs、または xfs のいずれかに置き換えます。fs-type はオプションです。
    start を、要件に応じてメガバイト単位のサイズに置き換えます。
    たとえば、ハードドライブで ext3 ファイルシステムを 1024 メガバイトから 2048 メガバイトまでのプライマリーパーティションを作成するには、以下のコマンドを入力します。
    (parted) mkpart primary 1024 2048
    注記
    代わりに mkpartfs コマンドを使用すると、パーティションの作成後にファイルシステムが作成されます。ただし、parted は ext3 ファイルシステムの作成に対応していません。したがって、ext3 ファイルシステムを作成する場合は、m kpart を使用して、 後述した mkfs コマンドでファイルシステムを作成します。
    Enter を押すとすぐに変更が行われるので、コマンドを実行する前にコマンドを確認します。
  5. パーティションテーブルを表示して、作成されたパーティションが、パーティションタイプ、ファイルシステムタイプ、およびサイズを正しいパーティションタイプで、パーティションテーブルに含まれていることを確認します。
    (parted) print
    また、新しいパーティションのマイナー番号を念頭に置いて、任意のファイルシステムにラベルを付けることができます。
  6. parted シェルを終了します。
    (parted) quit
  7. parted を閉じた後に次のコマンドを使用すると、カーネルが新しいパーティションを認識するようにします。
    # cat /proc/partitions 
parted が作成できるパーティションの最大数は 128 です。GUID パーティションテーブル(GPT )仕様では、パーティションテーブルに予約されている領域を増やすことで、より多くのパーティションを設定できますが、parted で使用しているエリアは 128 個に制限されます。

13.2.1. パーティションのフォーマットおよびラベル付け

パーティションのフォーマットおよびラベルを変更するには、以下の手順を使用します。

手順13.2 パーティションのフォーマットおよびラベル

  1. このパーティションにはファイルシステムがありません。ext4 ファイルシステム を作成するには、以下を使用します。
    # mkfs.ext4 /dev/sda6
    警告
    パーティションをフォーマットすると、パーティションに現在存在するデータがすべて永続的に破棄されます。
  2. パーティション上のファイルシステムにラベルを付けます。たとえば、新しいパーティションのファイルシステムが /dev/sda6 で、そのファイルにラベルを付ける場合は 次のコマンドを使用します。
    # e2label /dev/sda6 "work"
    デフォルトでは、インストールプログラムはパーティションのマウントポイントをラベルとして使用し、ラベルが一意になるようにします。任意のラベルを使用できます。
  3. root でマウントポイント(例: /work)を作成します。

13.2.2. パーティションを /etc/fstab に追加します

  1. root で /etc/fstab ファイルを編集し、パーティションの UUID を使用して新しいパーティションを追加します。
    パーティション UUID の完全なリストや、個々の デバイス情報については blkid -o list コマンドを実行します。
    /etc/fstab で、
    • 最初の列には、UUID= の後にファイルシステムの UUID が含まれている必要があります。
    • 2 列目には、新しいパーティションのマウントポイントが含まれている必要があります。
    • 3 列目はファイルシステムのタイプ( ext4swap など)である必要があります。
    • 4 番目のコラムには、ファイルシステムのマウントオプションをまとめています。ここでの 単語 は、システムの起動時にパーティションがデフォルトのオプションでマウントされることを意味します。
    • fifth および 6 番目のフィールドは、バックアップおよびチェックオプションを指定します。非ルートパーティションの値の例は 0 2 です。
  2. システムが新しい設定を登録するように、マウントユニットを再生成します。
    # systemctl daemon-reload
  3. ファイルシステムをマウントして、設定が機能することを確認します。
    # mount /work

追加情報

  • /etc/fstab のフォーマットに関する詳細は、fstab(5) man ページを参照してください。

13.3. パーティションの削除

警告
使用中のデバイスのパーティションの削除は試行しないでください。

手順13.3 パーティションを削除する

  1. パーティションを削除する前に、以下のいずれかを行います。
    • レスキューモードでブートする
    • デバイスでパーティションをアンマウントし、デバイスの swap 領域をオフにします。
  2. parted ユーティリティーを起動します。
    # parted device
    device を、パーティションを削除するデバイス(例: /dev/sda )に置き換えます。
  3. 現在のパーティションテーブルを表示して、削除するパーティションのマイナー番号を確認します。
    (parted) print
  4. rm コマンドでパーティションを削除します。たとえば、マイナー番号 3 のパーティションを削除するには、次のコマンドを実行します。
    (parted) rm 3
    Enter を押すとすぐに変更が行われるので、コマンドを確認してからコミットしてください。
  5. パーティションを削除したら、print コマンドを使用して、パーティションテーブルから削除されていることを確認します。
    (parted) print
  6. parted シェルを終了します。
    (parted) quit
  7. /proc/partitions ファイルの内容を調べ、カーネルがパーティションが削除されていることを確認します。
    # cat /proc/partitions
  8. /etc/fstab ファイルからパーティションを削除します。削除したパーティションを宣言している行を見つけ、ファイルから削除します。
  9. システムが新しい /etc/fstab 設定を登録するように、マウントユニットを再生成します。
    # systemctl daemon-reload

13.4. パーティションタイプの設定

パーティションタイプ(ファイルシステムタイプと混同しない)は、実行中のシステムではほとんど使用されません。ただし、パーティションタイプは、systemd-gpt-auto-generator など、デバイスを自動的に特定してマウントするパーティションタイプを使用するオンザフライジェネレーターにとって重要です。
fdisk ユーティリティーを起動し、t コマンドを使用してパーティションタイプを設定できます。以下の例は、最初のパーティションのパーティションタイプを 0x83(Linux ではデフォルト)に変更する方法を示しています。
# fdisk /dev/sdc
Command (m for help): t
Selected partition 1
Partition type (type L to list all types): 83
Changed type of partition 'Linux LVM' to 'Linux'.
parted ユーティリティーは、パーティションタイプを 'flags' にマッピングしようとするとパーティションタイプを制御します。これはエンドユーザーにとって便利ではありません。parted ユーティリティーは、LVM や RAID など、特定のパーティションタイプのみを処理できます。たとえば、parted で最初のパーティションから lvm フラグを削除するには、以下を使用します。
# parted /dev/sdc 'set 1 lvm off'
一般的に使用されるパーティションタイプと 16 進数の一覧は、パーティション内のパーティションタイプの表を参照してください。1 つのドライブを『 『Red Hat Enterprise Linux 7 インストールガイド』の「多数の付録』 」を参照してください

13.5. fdisk を使用したパーティションのサイズ変更

fdisk ユーティリティーを使用すると、GPT、MBR、SGI、および BSD パーティションテーブルを作成および操作できます。GUID パーティションテーブル(GPT)を持つディスクでは、fdisk GPT サポートが実験的なフェーズであるため、parted ユーティリティーの使用を推奨します。
パーティションのサイズ変更前に、ファイルシステム に保存されている データのバックアップを作成し、その手順をテストします。fdisk を使用してパーティションサイズを変更する唯一の方法は、パーティションの削除と再作成です。
重要
サイズを変更するパーティションは、特定のディスクの最後のパーティションでなければなりません。
Red Hat は、LVM パーティションの拡張およびサイズ変更のみをサポートします。

手順13.4 パーティションのサイズ変更

以下の手順は参考のためにのみ提供されます。 fdisk を使用してパーティションのサイズを変更するには、次のコマンドを実行します。
  1. デバイスをアンマウントします。
    # umount /dev/vda
  2. Run fdisk disk_name.以下に例を示します。
    # fdisk /dev/vda
    Welcome to fdisk (util-linux 2.23.2).
    
    Changes will remain in memory only, until you decide to write them. Be careful before using the write command.
    
    Command (m for help):
    
  3. p オプションを使用して、削除するパーティションの行数を決定します。
    Command (m for help): p
    Disk /dev/vda: 16.1 GB, 16106127360 bytes, 31457280 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk label type: dos
    Disk identifier: 0x0006d09a
    
    Device    Boot      Start         End      Blocks   Id  System
    /dev/vda1   *        2048     1026047      512000   83  Linux
    /dev/vda2         1026048    31457279    15215616   8e  Linux LVM
    
  4. d オプションを使用してパーティションを削除します。複数のパーティションが利用可能な場合は、fdisk により、削除するパーティションの数の入力が求められます。
    Command (m for help): d
    Partition number (1,2, default 2): 2
    Partition 2 is deleted
    
  5. n オプションを使用してパーティションを作成し、プロンプトに従います。将来のサイズ変更に十分な領域を許可します。fdisk のデフォルト動作( Enter)は、デバイス上のすべての領域を使用します。セクターでパーティションの最後を指定するか、+ <size> <suffix> を使用して人間が判読可能なサイズを指定できます(例: +500M、または +10G)。
    fdisk は、パーティションの末尾を物理セクターに合わせて調整するため、人間が判読可能なサイズ仕様を使用することを推奨しています。正確な数(セクター単位)を指定してサイズを指定すると、fdisk はパーティションの最後と一致しません。
    Command (m for help): n
    Partition type:
       p   primary (1 primary, 0 extended, 3 free)
       e   extended
    Select (default p): *Enter*
    Using default response p
    Partition number (2-4, default 2): *Enter*
    First sector (1026048-31457279, default 1026048): *Enter*
    Using default value 1026048
    Last sector, +sectors or +size{K,M,G} (1026048-31457279, default 31457279): +500M
    Partition 2 of type Linux and of size 500 MiB is set
    
  6. パーティションタイプを LVM に設定します。
    Command (m for help): t
    Partition number (1,2, default 2): *Enter*
    Hex code (type L to list all codes): 8e
    Changed type of partition 'Linux' to 'Linux LVM'
    
  7. エラーが発生し 選択したパーティションで不安定になる可能性があります。
  8. デバイスで e2fsck を実行し、一貫性を確認します。
    # e2fsck /dev/vda
    e2fsck 1.41.12 (17-May-2010)
    Pass 1:Checking inodes, blocks, and sizes
    Pass 2:Checking directory structure
    Pass 3:Checking directory connectivity
    Pass 4:Checking reference counts
    Pass 5:Checking group summary information
    ext4-1:11/131072 files (0.0% non-contiguous),27050/524128 blocks
    
  9. デバイスをマウントします。
    # mount /dev/vda
詳細は、fdisk(8) の man ページを参照してください。

第14章 Snapper を使用したスナップショットの作成と保守

スナップショットボリュームは、ファイルシステムを以前の状態に戻す方法を提供する、ターゲットボリュームの特定の時点のコピーです。snapper は、Btrfs およびシンプロビジョニングされた LVM ファイルシステムのスナップショットを作成し、維持するためのコマンドラインツールです。

14.1. 初期スプラー設定の作成

snapper には、操作する各ボリュームに個別の設定ファイルが必要です。設定ファイルは手動で設定する必要があります。デフォルトでは、snapper コマンドを実行できるのは root ユーザーのみです。
警告
シンプロビジョニングを使用する場合は、シンプール内の空き領域を監視します。完全に使用されているシンプールを使用すると、データが失われる可能性があります。詳細は、『『Red Hat Enterprise Linux 7 Logical Volume Manager Administration Guide』』の「Thinly-Provisioned Logical Volumes (Thin Volumes)」を参照してください。
Btrfs ツールおよびファイルシステムはテクノロジープレビューとして提供され、実稼働システムに不安定な状態になる可能性があります。
root 以外のユーザーまたはグループが特定の Snapper コマンドを使用できるようにするには、権限のないユーザーまたはグループに昇格したパーミッションを追加 しないことを推奨します。このような設定は SELinux をバイパスし、セキュリティーリスクを招く可能性があります。Red Hat では、この機能をセキュリティーチームで確認し、代わりに sudo インフラストラクチャーの使用を検討してください。
注記
Btrfs は、Red Hat Enterprise Linux 7 ではテクノロジープレビューとして利用できますが、Red Hat Enterprise Linux 7.4 リリース以降では非推奨になりました。Red Hat Enterprise Linux の将来のメジャーリリースで削除される予定です。
詳細は、『Red Hat Enterprise Linux 7.4 リリースノート』の「非推奨の機能」を参照してください。

手順14.1 スプラッパー設定ファイルの作成

  1. 以下のいずれかを作成または選択します。
    • シンプロビジョニングされた論理ボリュームに、Red Hat が対応するファイルシステムか、
    • Btrfs サブボリューム。
  2. ファイルシステムをマウントします。
  3. このボリュームを定義する設定ファイルを作成します。
    LVM2 の場合:
    # snapper -c config_name create-config -f "lvm(fs_type)" /mount-point
    たとえば、/lvm_mount にマウントされている ext4 ファイルシステムを含む LVM2 サブボリュームに lvm_config という設定ファイルを作成するには、以下のコマンドを使用します。
    # snapper -c lvm_config create-config -f "lvm(ext4)" /lvm_mount
    Btrfs の場合:
    # snapper -c config_name create-config -f btrfs /mount-point
    • -c config_name オプションは、設定ファイルの名前を指定します。
    • create-config は、設定ファイルを作成するように snapper に指示します。
    • -f file_system は、使用するファイルシステムの状態を示します。省略した場合、snapper はファイルシステムの検出を試みます。
    • /mount-point は、サブボリュームまたはシンプロビジョニングされた LVM2 ファイルシステムがマウントされる場所です。
    または、/ btrfs_mount にマウントされる Btrfs サブボリュームに、btrfs_ config という設定ファイルを作成します。
    # snapper -c btrfs_config create-config -f btrfs /btrfs_mount
設定ファイルは /etc/snapper/configs/ ディレクトリーに保存されます。

14.2. スナップショットの作成

snapper は、以下のようなスナップショットを作成できます。
スナップショット前のスナップショット
事前スナップショットは、スナップショットを投稿するための作成元のポイントとなります。この 2 つは密接に関連付けられており、この 2 つのポイント間でファイルシステムの変更を追跡するように設計されています。スナップショット前のスナップショットは、スナップショットの作成前に作成する必要があります。
スナップショットを投稿
ポストスナップショットは、事前のスナップショットへの終了点となります。結合前および後のスナップショットは、比較の範囲を定義します。デフォルトでは、関連するスナップショットが正常に作成された後に、新規の snapper ボリュームはすべてバックグラウンド比較を作成するように設定されます。
単一スナップショット
1 つのスナップショットは、特定の時点で作成されたスタンドアロンのスナップショットです。これらを使用して、変更のタイムラインを追跡し、後で返す一般的なポイントを持ちます。

14.2.1. スナップショット前およびポストスナップショットの作成

14.2.1.1. Snapper を使用した事前スナップショットの作成

スナップショットを事前に作成するには、以下を使用します。
# snapper -c config_name create -t pre
-c config_name オプションは、名前付き設定ファイルの仕様に従ってスナップショットを作成します。設定ファイルが存在しない場合は、「初期スプラー設定の作成」 を参照してください。
create -t オプションは、作成するスナップショットのタイプを指定します。許可されるエントリーは prepost、 または single です
たとえば、「初期スプラー設定の作成」 で作成した lvm_config 設定ファイルを使用して事前スナップショットを作成するには、以下を使用します。
# snapper -c SnapperExample create -t pre -p
1
-p オプションは、作成したスナップショットの数を出力します。

14.2.1.2. Snapper を使用したスナップショットの作成

スナップショットは、スナップショットの最後で、「Snapper を使用した事前スナップショットの作成」 の説明に従って、親の以前のスナップショットの後に作成する必要があります。

手順14.2 Post Snapshot の作成

  1. スナップショット前の数を決定します。
    # snapper -c config_name list
    たとえば、設定ファイル lvm_config を使用して作成されたスナップショットの一覧を表示するには、以下のコマンドを使用します。
    # snapper -c lvm_config list
    Type   | # | Pre # | Date              | User | Cleanup  | Description | Userdata
    -------+---+-------+-------------------+------+----------+-------------+---------
    single | 0 |       |                   | root |          | current     |
    pre    | 1 |       | Mon 06<...>       | root |          |             |
    
    この出力では、以前のスナップショットに数字が 1 であることを示しています。
  2. 以前に作成された事前スナップショットにリンクされているポストスナップショットを作成します。
    # snapper -c config_file create -t post --pre-num pre_snapshot_number
    • -t post オプションは、スナップショットのアップロードタイプの作成を指定します。
    • --pre-num オプションは、対応する事前スナップショットを指定します。
    たとえば、lvm_config 設定ファイルを使用してポストスナップショットを作成し、スナップショットの前に 1 にリンクするには、以下を使用します。
    # snapper -c lvm_config create -t post --pre-num 1 -p
    2
    
    -p オプションは、作成したスナップショットの数を出力します。
  3. 現在は、スナップショット前およびポストスナップショット 1 と 2 が作成され、ペアになりました。list コマンドを使用して、これを確認します。
    # snapper -c lvm_config list
    Type   | # | Pre # | Date              | User | Cleanup  | Description | Userdata
    -------+---+-------+-------------------+------+----------+-------------+---------
    single | 0 |       |                   | root |          | current     |
    pre    | 1 |       | Mon 06<...>       | root |          |             |
    post   | 2 | 1     | Mon 06<...>       | root |          |             |
    

14.2.1.3. スナップショット前およびスナップショット後のコマンドのラッピング

スナップショット前および投稿内でコマンドをラップすることも可能です。これは、テストの場合に役立ちます。次の手順は、手順14.3「スナップショット前およびスナップショット後のコマンドのラッピング」 を参照してください。
  1. snapper create pre snapshot コマンドを実行します。
  2. コマンドまたはコマンドの一覧を実行して、ファイルシステムのコンテンツに影響を与える可能性があるアクションを実行します。
  3. snapper create snapshot コマンドの実行中

手順14.3 スナップショット前およびスナップショット後のコマンドのラッピング

  1. スナップショット前および投稿でコマンドをラップするには、以下のコマンドを実行します。
    # snapper -c lvm_config create --command "command_to_be_tracked"
    たとえば、/lvm_mount/hello_file ファイルの作成を追跡するには、次のコマンドを実行します。
    # snapper -c lvm_config create --command "echo Hello > /lvm_mount/hello_file"
  2. これを確認するには、status コマンドを使用します。
    # snapper -c config_file status first_snapshot_number..second_snapshot_number
    たとえば、最初のステップで行った変更を追跡するには、次のコマンドを実行します。
    # snapper -c lvm_config status 3..4
    +..... /lvm_mount/hello_file
    
    list コマンドを使用して、必要に応じてスナップショットの数を確認します。
    status コマンドの詳細は、「スナップショット間の変更の追跡」 を参照してください。
この例のコマンドは、スナップショットをキャプチャーする唯一の方法であるという保証はありません。また、snapper は、ユーザーが変更するものだけでなく、システムが変更した内容も記録します。

14.2.2. 単一の Snapper スナップショットの作成

単一の snapper スナップショットの作成は、スナップショットの前またはポストのスナップショットを作成するのと似ています。作成 -t オプションは 1 つだけ指定します。1 つのスナップショットは、他のスナップショットに関連することなく、1 つのスナップショットを作成するために使用されます。ただし、その他の情報を自動的に生成したり、一覧表示したりする必要はありません。ただし、「snapshot」 で説明されているように、Red Hat は、この目的のために Snapper の代わりに System Storage Manager を使用することを推奨します。
1 つのスナップショットを作成するには、以下を使用します。
# snapper -c config_name create -t single
たとえば、次のコマンドは、lvm_config 設定ファイルを使用して単一のスナップショットを作成します。
# snapper -c lvm_config create -t single
1 つのスナップショットは特に変更を追跡するように設計されていませんが、snapper diff コマンド、xadiff、および status コマンドを使用して 2 つのスナップショットを比較できます。これらのコマンドの詳細は、「スナップショット間の変更の追跡」 を参照してください。

14.2.3. 自動化のスナップショットを作成するように Snapper を設定

自動スナップショットの作成は、Snapper の主要な機能の 1 つです。デフォルトでは、ボリュームの Snapper を設定する場合、Snapper は 1 時間ごとにボリュームのスナップショットを作成します。
デフォルト設定の Snapper は以下を保持します。
  • 1 時間ごとに 10 時間のスナップショットで、最後の毎時スナップショットは「daily」スナップショットとして保存されます。
  • 10 日次スナップショット、および月ごとの最後のスナップショットは「monthly」のスナップショットとして保存されます。
  • スナップショット 10 カ月に、最終的なスナップショットは「年」のスナップショットとして保存されます。
  • 10 年目でスナップショット。
デフォルトでは、Snapper は合計 50 のスナップショットをデフォルトで保持していることに注意してください。ただし、Snapper はデフォルトで 1,800 秒前よりも後に作成されたすべてのスナップショットを保持します。
デフォルト設定は /etc/snapper/config-templates/default ファイルに指定されます。snapper create-config コマンドを使用して設定を作成すると、デフォルト設定に基づいて指定されていない値が設定されます。/etc/snapper/configs/config_name ファイルで、定義されたボリュームの設定を編集できます。

14.3. スナップショット間の変更の追跡

status コマンド、diff コマンド および xadiff コマンドを使用して、スナップショット間のサブボリュームに加えた変更を追跡します。
status
status コマンドは、2 つのスナップショット間での変更に関する包括的な一覧である 2 つのスナップショット間で作成、変更、または削除されているファイルおよびディレクトリーの一覧を表示します。このコマンドを使用すると、過剰な詳細なしに変更の概要を取得できます。
詳細は、status コマンドによる変更の比較」 を参照してください。
diff
diff コマンドは、変更が検出された場合に、status コマンドから受信された 2 つのスナップショット間で、変更されたファイルおよびディレクトリーの差異を表示します。
詳細は、diff コマンドによる変更の比較」 を参照してください。
xadiff
xadiff コマンドは、2 つのスナップショット間でファイルやディレクトリーの拡張属性が変更された方法を比較します。
詳細は、xadiff コマンドを使用した変更の比較」 を参照してください。

14.3.1. status コマンドによる変更の比較

status コマンドは、2 つのスナップショット間で作成、変更、または削除されたファイルおよびディレクトリーの一覧を表示します。
2 つのスナップショット間のファイルの状態を表示するには、以下を使用します。
# snapper -c config_file status first_snapshot_number..second_snapshot_number
list コマンドを使用して、必要に応じてスナップショット番号を決定します。
たとえば、次のコマンドは、設定ファイル lvm_config を使用して、スナップショット 1 から 2 の間で加えられた変更を表示します。
#snapper -c lvm_config status 1..2
tp.... /lvm_mount/dir1
-..... /lvm_mount/dir1/file_a
c.ug.. /lvm_mount/file2
+..... /lvm_mount/file3
....x. /lvm_mount/file4
cp..xa /lvm_mount/file5
出力の最初の部分の文字とドットを列として読み取ります。
+..... /lvm_mount/file3
||||||
123456
列 1 は、ファイル(ディレクトリーエントリー)タイプの変更を示唆します。以下の値が使用できます。
列 1
出力意味
.何も変更されていません。
+ファイルが作成されました。
-ファイルが削除されました。
cコンテンツが変更されました。
tディレクトリーエントリーのタイプが変更になりました。たとえば、以前のシンボリックリンクは、同じファイル名を持つ通常のファイルに変更されています。
列 2 は、ファイルパーミッションの変更を示します。以下の値が使用できます。
列 2
出力意味
.パーミッションは変更されていません。
pパーミッションが変更されました。
列 3 は、ユーザーの所有権の変更を示します。以下の値が使用できます。
列 3
出力意味
.ユーザーの所有権は変更されていません。
uユーザーの所有権が変更されました。
列 4 は、グループの所有権の変更を示します。以下の値が使用できます。
列 4
出力意味
.グループの所有権は変更されていません。
gグループの所有権が変更されました。
列 5 は、拡張属性の変更を示します。以下の値が使用できます。
列 5
出力意味
.拡張属性は変更されません。
x拡張属性が変更されました。
列 6 は、アクセス制御リスト(ACL)の変更を示します。以下の値が使用できます。
列 6
出力意味
.ACL は変更されていません。
aACL が変更されました。

14.3.2. diff コマンドによる変更の比較

diff コマンドは、2 つのスナップショット間の修正したファイルおよびディレクトリーの変更を示しています。
# snapper -c config_name diff first_snapshot_number..second_snapshot_number
list コマンドを使用して、必要に応じてスナップショットの数を確認します。
たとえば、lvm_config 設定ファイルを使用して作成されたスナップショット 1 とスナップショット 2 の間でファイルに加えられた変更を比較するには、以下を使用します。
# snapper -c lvm_config diff 1..2
--- /lvm_mount/.snapshots/13/snapshot/file4	19<...>
+++ /lvm_mount/.snapshots/14/snapshot/file4	20<...>
@@ -0,0 +1 @@
+words
この出力では、ファイル4 が「キーワード」をファイルに追加するように変更されました。

14.3.3. xadiff コマンドを使用した変更の比較

xadiff コマンドは、2 つのスナップショット間でファイルまたはディレクトリーの拡張属性が変更された方法を比較します。
# snapper -c config_name xadiff first_snapshot_number..second_snapshot_number
list コマンドを使用して、必要に応じてスナップショットの数を確認します。
たとえば、lvm_config 設定ファイルを使用して作成されたスナップショット番号 1 とスナップショット番号 2 間の xadiff 出力を表示するには、以下を使用します。
# snapper -c lvm_config xadiff 1..2

14.4. スナップショット間の変更の取り消し

2 つの既存 Snapper スナップショット間で行われる変更を元に戻すには、以下の形式で undochange コマンドを使用します。1 は最初のスナップショットで 、2 つ目の スナップショットになります。
snapper -c config_name undochange 1..2
重要
undochange コマンドを使用しても、Snapper ボリュームを元の状態に元に戻さず、データの一貫性は維持されません。スナップショット 2 など、指定された範囲外で発生するファイルの変更は、スナップショット 1 の状態などに戻っても変更されないままになります。たとえば、元に戻す)」 変更を実行してユーザーの作成を元に戻すと、そのユーザーが所有するすべてのファイルはそのまま残ります。
スナップショットには、ファイルの一貫性を確保するためのメカニズムもないため、元に戻すchange コマンドが使用されたときにすでにスナップショットに転送される不整合も移動できます。
Snapper undochange コマンドを root ファイルシステムと併用しないでください。これは、障害が発生する可能性があるためです。
以下の図は、元に戻すchange コマンドが機能する仕組みを示しています。

図14.1 毎回の snapper ステータス

毎回の snapper ステータス
この図は、snapshot_1 が作成される時点で、file_a が作成されてから file_b が削除されるかを示します。次に Snapshot_2 が作成され、そのファイル_a が編集され、file_c が作成されます。システムの現在の状態です。現在のシステムでは、file_a、file_ b、および新たに作成された file_ c の編集バージョンがあります。
undochange コマンドが呼び出されると、Snapper は最初に一覧表示されたスナップショットと 2 番目のスナップショットの間に変更されたファイルの一覧を生成します。この図では、snapper -c SnapperExample undochange 1..2 コマンドを使用する場合、Snapper は変更されたファイルのリストを作成します(つまり file_a が作成されます)。file_a が削除され、現在のシステムに適用されます。したがって、以下のようになります。
  • 現在のシステムには、snapshot_1 の作成時に作成されるため、file_a がありません。
  • file_b は存在し、snapshot_1 から現在のシステムにコピーされます。
  • file_c は、作成が指定の時間外にあるので存在します。
file_b と file_ c の競合が発生すると、システムが破損してしまう可能性があります。
snapper -c SnapperExample undochange 2..1 コマンドを使用することもできます。この場合、現在のシステムは、編集したバージョンの file_asnapshot_1 からコピーされたものに置き換え、snapshot_2 の作成後に作成されたファイルの編集を元に戻します。

mount コマンドおよび unmount コマンドを使用した変更の取り消し

undochange コマンドは常に変更を元に戻すための最良の方法ではありません。status および diff コマンドを使用すると、認定の決定を行い、Snapper の代わりに mount コマンドおよび unmount コマンドを使用できます。mount および unmount コマンドは、スナップショットをマウントし、Snapper ワークフローとは独立してコンテンツを参照する場合に便利です。
必要に応じて、mount コマンドは、マウント 前にそれぞれの LVM Snapper スナップショットをアクティベートします。たとえば、スナップショットの マウントや複数ファイルの古いバージョンを手動で抽出するなど、mount コマンドおよび unmount コマンドを使用してください。ファイルを手動で元に戻するには、ファイルをマウントされたスナップショットから現在のファイルシステムにコピーします。現在のファイルシステムスナップショット 0 は、手順14.1「スプラッパー設定ファイルの作成」 で作成されたライブファイルシステムです。元の /mount-point のサブツリーにファイルをコピーします。
クライアント側要求を明示的に行うには、mount コマンドおよび unmount コマンドを使用します。/etc/snapper/configs/config_name ファイルには ALLOW_USERS= および ALLOW_GROUPS= 変数が含まれ、ここでユーザーおよびグループを追加できます。次に 、snapperd を使用すると、追加されたユーザーおよびグループのマウント操作を実行できます。

14.5. スプラッパースナップショットの削除

スナップショットを削除するには、以下のコマンドを実行します。
# snapper -c config_name snapshot_number の削除
list コマンドを使用して、スナップショットが正常に削除されたことを確認できます。

第15章 swap 領域

Linux の スワップ領域 は、物理メモリー(RAM)が不足すると使用されます。システムに多くのメモリーリソースが必要で、RAM が不足すると、メモリーの非アクティブなページがスワップ領域に移動します。スワップ領域は、RAM が少ないマシンで役に立ちますが、RAM の代わりに使用しないようにしてください。スワップ領域はハードドライブにあり、そのアクセス速度は物理メモリーに比べると遅くなります。スワップ領域の構成は、専用のスワップパーティション (推奨)、スワップファイル、またはスワップパーティションとスワップファイルの組み合せが考えられます。Btrfs はスワップ領域 に対応していない ことに注意してください。
過去数年、推奨されるスワップ領域のサイズは、システムの RAM サイズに比例して増加していました。しかし、最近のシステムには通常、数百ギガバイトの RAM が含まれます。結果として、推奨されるスワップ領域は、システムのメモリーではなく、システムメモリーのワークロードの機能とみなされます。
表15.1「システムの推奨 swap 領域」 では、システムの RAM の容量別に推奨されるスワップパーティションのサイズと、システムをハイバネートするのに十分なメモリーが必要かどうかを示しています。推奨されるスワップパーティションのサイズは、インストール時に自動的に確定されます。ハイバネートを可能にするには、カスタムのパーティション分割段階でスワップ領域を編集する必要があります。
表15.1「システムの推奨 swap 領域」 の推奨内容は、メモリーが少ないシステム(1 GB 以下)で特に重要になります。このようなシステムで十分なスワップ領域を割り当てられないと、不安定になる問題が生じたり、インストールしたシステムが起動できなくなる可能性があります。
表15.1「システムの推奨 swap 領域」 に記載されている各範囲の境界線上にある(例: システムの RAM が 2 GB、8 GB、または 64 GB のシステム RAM の場合)、スワップ領域やハイバネートへのサポートは適宜判断してください。システムリソースに余裕がある場合は、スワップ領域を増やすとパフォーマンスが向上することがあります。
高速のドライブ、コントローラー、およびインターフェースを搭載したシステムでは、複数のストレージデバイスにスワップ領域を分散すると、スワップ領域のパフォーマンスも向上します。
重要
スワップ領域として割り当てたファイルシステムおよび LVM2 ボリュームは、変更時に 使用しない でください。システムプロセスまたはカーネルがスワップ領域を使用していると、スワップの修正に失敗します。free コマンドおよび cat /proc/swaps コマンドを使用して、スワップの使用量と、使用中の場所を確認します。
システムがレスキューモードで起動している間にスワップ領域を変更してください。『Red 『Hat Enterprise Linux 7 インストールガイド』 レスキューモードで コンピューターの起動」を参照してください』。ファイルシステムをマウントするように指示されたら、スキップ を選択します。

15.1. スワップ領域の追加

インストール後にさらにスワップ領域を追加する必要がある場合があります。たとえば、システムの RAM 容量を 1 GB から 2 GB にアップグレードするときに、スワップ容量が 2 GB しかないとします。メモリーを大幅に消費する操作を実行している場合や、大量のメモリーを必要とするアプリケーションを実行する場合は、スワップ領域を 4 GB に増やすことが有益となる可能性があります。
新しい swap パーティションの作成、スワップファイルの新規作成、または既存の LVM2 論理ボリュームでスワップを拡張する 3 つのオプションがあります。この中では、既存論理ボリュームを拡張することが推奨されます。

15.1.1. LVM2 論理ボリュームでのスワップの拡張

デフォルトでは、Red Hat Enterprise Linux 7 はインストール時に利用可能なすべての領域を使用します。ご使用のシステムでこのような場合は、最初に、swap 領域が使用するボリュームグループに新しい物理ボリュームを追加する必要があります。
スワップ領域のボリュームグループにストレージを追加したら、そのストレージを拡張できます。これを実行するには、以下の手順を実行します( /dev/VolGroup00/LogVol01 は 2 GB で拡張するボリュームになります)。

手順15.1 LVM2 論理ボリュームでのスワップの拡張

  1. 関連付けられている論理ボリュームのスワップ機能を無効にします。
    # swapoff -v /dev/VolGroup00/LogVol01
  2. LVM2 論理ボリュームのサイズを 2 GB 増やします。
    # lvresize /dev/VolGroup00/LogVol01 -L +2G
  3. 新しいスワップ領域をフォーマットします。
    # mkswap /dev/VolGroup00/LogVol01
  4. 拡張論理ボリュームを有効にします。
    # swapon -v /dev/VolGroup00/LogVol01
  5. スワップの論理ボリュームの拡張に成功したかどうかをテストするには、アクティブなスワップ容量を調べます。
    $ cat /proc/swaps
    $ free -h

15.1.2. スワップの LVM2 論理ボリュームの作成

スワップボリュームグループ 2 GB をサイズに追加するには、スワップボリューム /dev/VolGroup00/LogVol02 を追加します。
  1. サイズが 2 GB の LVM2 論理ボリュームを作成します。
    # lvcreate VolGroup00 -n LogVol02 -L 2G
  2. 新しいスワップ領域をフォーマットします。
    # mkswap /dev/VolGroup00/LogVol02
  3. 以下のエントリーを /etc/fstab ファイルに追加します。
    /dev/VolGroup00/LogVol02   swap     swap    defaults     0 0
  4. システムが新しい設定を登録するように、マウントユニットを再生成します。
    # systemctl daemon-reload
  5. 論理ボリュームでスワップをアクティブにします。
    # swapon -v /dev/VolGroup00/LogVol02
  6. スワップ論理ボリュームの作成に成功したかどうかをテストするには、アクティブなスワップ容量を調べます。
    $ cat /proc/swaps
    $ free -h

15.1.3. スワップファイルの作成

スワップファイルを追加するには、次のコマンドを実行します。

手順15.2 スワップファイルの追加

  1. 新しいスワップファイルのサイズをメガバイト単位で指定してから、そのサイズに 1024 をかけてブロック数を指定します。たとえばスワップファイルのサイズが 64 MB の場合は、ブロック数が 65536 になります。
  2. 空のファイルの作成:
    # dd if=/dev/zero of=/swapfile bs=1024 count=65536
    count を、希望のブロックサイズと同等の値に置き換えます。
  3. 次のコマンドでスワップファイルをセットアップします。
    # mkswap /swapfile
  4. スワップファイルのセキュリティーを変更して、全ユーザーで読み込みができないようにします。
    # chmod 0600 /swapfile
  5. システムの起動時にスワップファイルを有効にするには、root で /etc/fstab に、以下のエントリーを追加します。
    /swapfile          swap            swap    defaults        0 0
    次にシステムが起動すると新しいスワップファイルが有効になります。
  6. システムが新しい /etc/fstab 設定を登録するように、マウントユニットを再生成します。
    # systemctl daemon-reload
  7. スワップファイルをすぐに有効にするには、次のコマンドを実行します。
    # swapon /swapfile
  8. 新しいスワップファイルを作成して有効にできたことをテストするには、アクティブなスワップ容量を調べます。
    $ cat /proc/swaps
    $ free -h

15.2. スワップ領域の削除

インストール後にスワップ領域を減らすことが必要になるかもしれません。たとえば、システムの RAM 容量を 1 GB から 512 MB にダウングレードするとします。しかし、依然として 2 GB のスワップ容量が割り当てられています。ディスク領域が大きくなる (2 GB など) と無駄になる可能性があるため、スワップ領域を 1 GB に減らすことでメリットを得られることがあります。
スワップに使用する LVM2 論理ボリューム全体を削除する方法、スワップファイルの削除、または既存の LVM2 論理ボリュームのスワップ領域を縮小する方法の 3 つのオプションがあります。

15.2.1. LVM2 論理ボリュームでのスワップの縮小

LVM2 スワップ論理ボリュームを縮小するには( /dev/VolGroup00/LogVol01 が縮小するボリュームになります)。

手順15.3 LVM2 スワップ論理ボリュームの縮小

  1. 関連付けられている論理ボリュームのスワップ機能を無効にします。
    # swapoff -v /dev/VolGroup00/LogVol01
  2. LVM2 論理ボリュームのサイズを変更して 512 MB 削減します。
    # lvreduce /dev/VolGroup00/LogVol01 -L -512M
  3. 新しいスワップ領域をフォーマットします。
    # mkswap /dev/VolGroup00/LogVol01
  4. 論理ボリュームでスワップをアクティブにします。
    # swapon -v /dev/VolGroup00/LogVol01
  5. スワップ論理ボリュームの縮小に成功したかどうかをテストするには、アクティブなスワップ容量を調べます。
    $ cat /proc/swaps
    $ free -h

15.2.2. スワップの LVM2 論理ボリュームの削除

スワップボリュームグループを削除するには(削除する スワップボリュームを /dev/VolGroup00/LogVol 02)します。

手順15.4 スワップボリュームグループの削除

  1. 関連付けられている論理ボリュームのスワップ機能を無効にします。
    # swapoff -v /dev/VolGroup00/LogVol02
  2. LVM2 論理ボリュームを削除します。
    # lvremove /dev/VolGroup00/LogVol02
  3. /etc/fstab ファイルから、以下の関連エントリーを削除します。
    /dev/VolGroup00/LogVol02   swap     swap    defaults     0 0
  4. システムが新しい設定を登録するように、マウントユニットを再生成します。
    # systemctl daemon-reload
  5. 論理ボリュームの削除に成功したかどうかをテストするには、アクティブなスワップ容量を調べます。
    $ cat /proc/swaps
    $ free -h

15.2.3. スワップファイルの削除

スワップファイルを削除するには、次のコマンドを実行します。

手順15.5 スワップファイルの削除

  1. シェルプロンプトで以下のコマンドを実行し、スワップファイルを無効にします( /swapfile は swap ファイルに置き換えます)。
    # swapoff -v /swapfile
  2. /etc/fstab ファイルからエントリーを削除します。
  3. システムが新しい設定を登録するように、マウントユニットを再生成します。
    # systemctl daemon-reload
  4. 実際のファイルを削除します。
    # rm /swapfile

15.3. スワップ領域の移動

ある場所から別の場所にスワップ領域を移動するには、次のコマンドを実行します。
  1. スワップ領域 「スワップ領域の削除」 を削除しています。
  2. スワップ領域 「スワップ領域の追加」 を追加します。

第16章 System Storage Manager(SSM)

System Storage Manager (SSM)は、さまざまなテクノロジーでストレージを管理するコマンドラインインターフェースを提供します。ストレージシステムは、デバイスマッパー(DM)、論理ボリュームマネージャー(LVM)、および複数のデバイス(MD)の使用により複雑になります。これにより、ユーザーフレンドリーではないシステムが作成され、エラーや問題が発生する可能性があります。SSM は、統一されたユーザーインターフェースを作成してこれを軽減します。このインターフェースを使用すると、ユーザーはシンプルな方法で複雑なシステムを実行できます。たとえば、SSM なしで新しいファイルシステムを作成してマウントするには、5 つのコマンドを使用する必要があります。SSM が必要なのは 1 つのみです。
本章では、SSM がさまざまなバックエンドと、一般的なユースケースと対話する方法を説明します。

16.1. SSM バックエンド

SSM は、基礎となるテクノロジー の詳細を無視し、デバイス、プール、およびボリュームの抽象化を行うsmlib/main.py 内のコア抽象化層を使用します。バックエンドは、ssmlib/main.py に登録して、ボリュームとプールの作成、スナップショット または削除 などの特定のストレージ技術メソッドを処理します。
SSM にバックエンドが複数登録されています。以下のセクションでは、その基本情報と、プール、ボリューム、スナップショット、およびデバイスの処理方法に関する定義を説明します。

16.1.1. Btrfs バックエンド

注記
Btrfs は、Red Hat Enterprise Linux 7 ではテクノロジープレビューとして利用できますが、Red Hat Enterprise Linux 7.4 リリース以降では非推奨になりました。Red Hat Enterprise Linux の将来のメジャーリリースで削除される予定です。
詳細は、『Red Hat Enterprise Linux 7.4 リリースノート』の「非推奨の機能」を参照してください。
Btrfs は、高度な機能が多数あるファイルシステムである SSM のボリューム管理バックエンドとして使用されます。プール、ボリューム、およびスナップショットは Btrfs バックエンドを使用して作成できます。

16.1.1.1. Btrfs プール

Btrfs ファイルシステム自体はプールです。デバイスを削除して拡張するには、デバイスを削除します。SSM は、Btrfs プールの作成時に Btrfs ファイルシステムを作成します。つまり、新しい Btrfs プールには、プール全体を削除せずに削除できないプールと同じ名前のボリュームが 1 つあります。デフォルトの Btrfs プール名は btrfs_pool です。
プールの名前は、ファイルシステムのラベルとして使用されます。ラベルのないシステムに既存の Btrfs ファイルシステムがある場合、Btrfs プールは btrfs_device_base_name の形式で内部で使用する名前を生成します。

16.1.1.2. Btrfs ボリューム

プールの最初のボリュームの後に作成されるボリュームはサブボリュームと同じです。SSM は、サブボリュームを作成するためにアンマウントされている場合は Btrfs ファイルシステムを一時的にマウントします。
ボリュームの名前は、Btrfs ファイルシステムのサブボリュームパスとして使用されます。たとえば、サブボリュームは /dev/lvm_pool/lvol001 として表示されます。ボリュームを作成するためには、このパスの全オブジェクトが存在している必要があります。ボリュームは、マウントポイントで参照することもできます。

16.1.1.3. Btrfs スナップショット

スナップショットは、SSM を使用してシステムの Btrfs ボリュームから取得できます。Btrfs は、サブボリュームとスナップショットを区別しないことに注意してください。これは、SSM が Btrfs スナップショットの宛先を認識できませんが、特別な名前形式を認識しようとします。スナップショットの作成時に指定された名前が特定のパターンではない場合には、スナップショットは認識されず、代わりに通常の Btrfs ボリュームとして一覧表示されます。

16.1.1.4. Btrfs デバイス

Btrfs には、特別なデバイスを作成する必要はありません。

16.1.2. LVM バックエンド

プール、ボリューム、およびスナップショットは LVM で作成できます。以下の定義は、LVM の観点から見受けられます。

16.1.2.1. LVM プール

LVM プールは、LVM ボリュームグループと同じです。つまり、LVM プールから、デバイスと新しい論理ボリュームを作成できます。デフォルトの LVM プール名は lvm_pool です。

16.1.2.2. LVM ボリューム

LVM ボリュームは通常の論理ボリュームと同じです。

16.1.2.3. LVM スナップショット

LVM ボリュームからスナップショットを作成すると、スナップショットボリューム が新たに作成されます。スナップショットボリュームは、他の LVM ボリュームと同じように処理できます。Btrfs とは異なり、LVM は通常のボリュームとスナップショットを区別できるため、特定のパターンに一致するスナップショット名は必要ありません。

16.1.2.4. LVM デバイス

SSM は、ユーザー用に、物理デバイスに LVM バックエンドを作成する必要がなくなります。

16.1.3. Crypt バックエンド

SSM の crypt バックエンドは、cryptsetup および dm-crypt ターゲット を使用して、暗号化されたボリュームを管理します。Crypt バックエンドは、通常のブロックデバイス(または LVM や MD ボリュームなどの他のボリューム)に暗号化されたボリュームを作成する通常のバックエンドとして使用するか、1 つの手順で暗号化された LVM ボリュームを作成できます。
crypt バックエンドでボリュームのみを作成できます。プーリングはサポートされておらず、特別なデバイスは必要ありません。
以下のセクションでは、暗号化の観点からのボリュームおよびスナップショットを定義します。

16.1.3.1. Crypt ボリューム

Crypt ボリュームは dm-crypt により作成され、暗号化されていない形式で、元の暗号化デバイスのデータを表します。RAID またはデバイスの連結には対応していません。
2 つのモード(拡張子)がサポートされます(luks および plain)。LUKS はデフォルトで使用されます。拡張機能の詳細は、man cryptsetup を参照してください。

16.1.3.2. Crypt Snapshot

crypt バックエンドはスナップショット化をサポートしませんが、暗号化されたボリュームが LVM ボリューム上に作成される場合、ボリューム自体のスナップショットを作成できます。このスナップショットは、cryptsetup を使用して開くことができます。

16.1.4. 複数のデバイス(MD)バックエンド

現在、MD バックエンドは、システム内の MD ボリュームに関する情報のみを収集することに限定されます。

16.2. 一般的な SSM タスク

以下のセクションでは、一般的な SSM タスクを説明します。

16.2.1. SSM のインストール

SSM をインストールするには、以下のコマンドを使用します。
# yum install system-storage-manager
サポートするパッケージがインストールされている場合のみ、複数のバックエンドが有効化されます。
  • LVM バックエンドには、lvm2 パッケージが必要です。
  • Btrfs バックエンドには btrfs-progs パッケージが必要です。
  • Crypt バックエンドでは、device-mapper パッケージおよび cryptsetup パッケージが必要です。

16.2.2. 検出されたすべてのデバイスに関する情報の表示

list コマンドを使用して、検出されたすべてのデバイス、プール、ボリューム、およびスナップショットに関する情報を表示します。オプションなしで The ssm list コマンドは、以下の出力を表示します。
# ssm list
----------------------------------------------------------
Device        Free      Used      Total  Pool  Mount point
----------------------------------------------------------
/dev/sda                        2.00 GB        PARTITIONED
/dev/sda1                      47.83 MB        /test
/dev/vda                       15.00 GB        PARTITIONED
/dev/vda1                     500.00 MB        /boot
/dev/vda2  0.00 KB  14.51 GB   14.51 GB  rhel
----------------------------------------------------------
------------------------------------------------
Pool  Type  Devices     Free      Used     Total
------------------------------------------------
rhel  lvm   1        0.00 KB  14.51 GB  14.51 GB
------------------------------------------------
---------------------------------------------------------------------------------
Volume          Pool  Volume size  FS     FS size       Free  Type    Mount point
---------------------------------------------------------------------------------
/dev/rhel/root  rhel     13.53 GB  xfs   13.52 GB    9.64 GB  linear  /
/dev/rhel/swap  rhel   1000.00 MB                             linear
/dev/sda1                47.83 MB  xfs   44.50 MB   44.41 MB  part    /test
/dev/vda1               500.00 MB  xfs  496.67 MB  403.56 MB  part    /boot
---------------------------------------------------------------------------------
この表示は、引数を使用して表示すべき内容を指定してさらに絞り込むことができます。利用可能なオプションの一覧は、s ssm list --help コマンドで確認することができます。
注記
指定された引数によっては、SSM は何も表示されないことがあります。
  • devices または dev 引数を実行すると、一部のデバイスが省略されます。たとえば、CDRoms デバイスおよび DM/MD デバイスは、ボリュームとして記載されるので、意図的に非表示にされます。
  • 一部のバックエンドはスナップショットをサポートしないため、スナップショットと通常のボリュームを区別できません。これらのバックエンドのいずれかで スナップショット 引数を実行すると、スナップショットを識別するために SSM がボリューム名を認識しようとします。SSM 正規表現がスナップショットパターンに一致しない場合、スナップショットは認識されません。
  • メインの Btrfs ボリューム(ファイルシステム自体)を除き、マウントを解除した Btrfs ボリュームは表示されません。

16.2.3. 新規プール、論理ボリューム、およびファイルシステムの作成

本セクションでは、/dev/vdb デバイス、/dev/vdb デバイス、論理ボリューム 1G および XFS ファイルシステムを持つデフォルトの名前で、新しいプールが作成されます。
このシナリオを作成するコマンドは、sm create --fs xfs -s 1G /dev/vdb /dev/inodesFree です。以下のオプションが使用されます。
  • --fs オプションは、必要なファイルシステムタイプを指定します。現在対応しているファイルシステムのタイプは以下のとおりです。
    • ext3
    • ext4
    • xfs
    • btrfs
  • -s は、論理ボリュームのサイズを指定します。ユニットを定義するには、以下のサフィックスがサポートされます。
    • キロバイトの場合は k または k
    • メガバイトの場合は m または m
    • ギガバイトの 場合は g または g
    • テラバイトの場合は T または t
    • ペタ バイトの場合は p または p
    • エクサバイトの場合は E または e
  • 一覧表示された 2 つのデバイス( /dev/vdb および /dev/maprule )は、作成する 2 つのデバイスです。
# ssm create --fs xfs -s 1G /dev/vdb /dev/vdc
  Physical volume "/dev/vdb" successfully created
  Physical volume "/dev/vdc" successfully created
  Volume group "lvm_pool" successfully created
  Logical volume "lvol001" created
便利なsm コマンドには、他に 2 つのオプションがあります。1 番目は -p pool コマンドです。ボリュームを作成するプールを指定します。存在していない場合、SSM はこれを作成します。この例では省略され、SSM はデフォルトの名前 lvm_pool を使用していました。ただし、既存の命名規則に合わせて特定の名前を使用する場合は、- p オプションを使用する必要があります。
2 つ目の便利なオプションは、-n name コマンドです。新規作成された論理ボリュームに名前を付けます。-p と同様に、既存の命名規則に合わせて特定の名前を使用する必要があります。
これら 2 つのオプションが使用される例は次のとおりです。
# ssm create --fs xfs -p new_pool -n XFS_Volume /dev/vdd
  Volume group "new_pool" successfully created
  Logical volume "XFS_Volume" created
SSM は、1 つのコマンドを簡単に、2 つの物理ボリューム、プール、および論理ボリューム 2 つを作成しました。

16.2.4. ファイルシステムの不整合の確認

The ssm check コマンドは、ボリューム上のファイルシステムの整合性を確認します。確認する複数のボリュームを指定できます。ボリュームにファイルシステムがない場合、ボリュームはスキップされます。
ボリューム lvol001 のすべてのデバイスを確認するには、 /dev/lvm_pool/lvol001をチェックしてください
# ssm check /dev/lvm_pool/lvol001
Checking xfs file system on '/dev/mapper/lvm_pool-lvol001'.
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

16.2.5. ボリュームサイズの拡大

Thesm resize コマンドは、指定したボリュームおよびファイルシステムのサイズを変更します。ファイルシステムがない場合、ボリューム自体のみがリサイズされます。
この例では、現在、lvol001 という 900 MB に論理ボリュームが 1 つあります。
# ssm list
-----------------------------------------------------------------
Device          Free       Used      Total  Pool      Mount point
-----------------------------------------------------------------
/dev/vda                          15.00 GB            PARTITIONED
/dev/vda1                        500.00 MB            /boot
/dev/vda2    0.00 KB   14.51 GB   14.51 GB  rhel
/dev/vdb   120.00 MB  900.00 MB    1.00 GB  lvm_pool
/dev/vdc                           1.00 GB
-----------------------------------------------------------------
---------------------------------------------------------
Pool      Type  Devices       Free       Used       Total
---------------------------------------------------------
lvm_pool  lvm   1        120.00 MB  900.00 MB  1020.00 MB
rhel      lvm   1          0.00 KB   14.51 GB    14.51 GB
---------------------------------------------------------
--------------------------------------------------------------------------------------------
Volume                 Pool      Volume size  FS     FS size       Free  Type    Mount point
--------------------------------------------------------------------------------------------
/dev/rhel/root         rhel         13.53 GB  xfs   13.52 GB    9.64 GB  linear  /
/dev/rhel/swap         rhel       1000.00 MB                             linear
/dev/lvm_pool/lvol001  lvm_pool    900.00 MB  xfs  896.67 MB  896.54 MB  linear
/dev/vda1                          500.00 MB  xfs  496.67 MB  403.56 MB  part    /boot
--------------------------------------------------------------------------------------------
論理ボリュームは、別の 500MB で増やす必要があります。プールに別のデバイスを追加する必要があります。
~]# ssm resize -s +500M /dev/lvm_pool/lvol001 /dev/vdc
  Physical volume "/dev/vdc" successfully created
  Volume group "lvm_pool" successfully extended
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.
  Extending logical volume lvol001 to 1.37 GiB
  Logical volume lvol001 successfully resized
meta-data=/dev/mapper/lvm_pool-lvol001 isize=256    agcount=4, agsize=57600 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0
data     =                       bsize=4096   blocks=230400, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal               bsize=4096   blocks=853, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 230400 to 358400

SSM はデバイスでチェックを実行してから、指定された容量でボリュームを拡張します。これは、ssm list コマンドで検証できます。
# ssm list
------------------------------------------------------------------
Device          Free        Used      Total  Pool      Mount point
------------------------------------------------------------------
/dev/vda                           15.00 GB            PARTITIONED
/dev/vda1                         500.00 MB            /boot
/dev/vda2    0.00 KB    14.51 GB   14.51 GB  rhel
/dev/vdb     0.00 KB  1020.00 MB    1.00 GB  lvm_pool
/dev/vdc   640.00 MB   380.00 MB    1.00 GB  lvm_pool
------------------------------------------------------------------
------------------------------------------------------
Pool      Type  Devices       Free      Used     Total
------------------------------------------------------
lvm_pool  lvm   2        640.00 MB   1.37 GB   1.99 GB
rhel      lvm   1          0.00 KB  14.51 GB  14.51 GB
------------------------------------------------------
----------------------------------------------------------------------------------------------
Volume                 Pool      Volume size  FS      FS size        Free  Type    Mount point
----------------------------------------------------------------------------------------------
/dev/rhel/root         rhel         13.53 GB  xfs    13.52 GB     9.64 GB  linear  /
/dev/rhel/swap         rhel       1000.00 MB                               linear
/dev/lvm_pool/lvol001  lvm_pool      1.37 GB  xfs     1.36 GB     1.36 GB  linear
/dev/vda1                          500.00 MB  xfs   496.67 MB   403.56 MB  part    /boot
----------------------------------------------------------------------------------------------
注記
LVM ボリュームのサイズを縮小することはできません。他のボリューム種別ではサポートされていません。これは、+ の代わりに - を使用して 行います。たとえば、LVM ボリュームのサイズを 50M で縮小するには、次のコマンドを実行します。
# ssm resize -s-50M /dev/lvm_pool/lvol002
  Rounding size to boundary between physical extents: 972.00 MiB
  WARNING: Reducing active logical volume to 972.00 MiB
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce lvol002? [y/n]: y
  Reducing logical volume lvol002 to 972.00 MiB
  Logical volume lvol002 successfully resized
+ または - を指定しないと、値は絶対値として取られます。

16.2.6. snapshot

既存のボリュームのスナップショットを作成するには、s ssm snapshot コマンドを使用します。
注記
ボリュームが属するバックエンドがスナップショットに対応していない場合、この操作は失敗します。
lvol001 のスナップショットを作成するには、以下のコマンドを使用します。
# ssm snapshot /dev/lvm_pool/lvol001
  Logical volume "snap20150519T130900" created
これを確認するには、ssm 一覧 を使用し、追加のスナップショットのセクションをメモします。
# ssm list
----------------------------------------------------------------
Device        Free        Used      Total  Pool      Mount point
----------------------------------------------------------------
/dev/vda                         15.00 GB            PARTITIONED
/dev/vda1                       500.00 MB            /boot
/dev/vda2  0.00 KB    14.51 GB   14.51 GB  rhel
/dev/vdb   0.00 KB  1020.00 MB    1.00 GB  lvm_pool
/dev/vdc                          1.00 GB
----------------------------------------------------------------
--------------------------------------------------------
Pool      Type  Devices     Free        Used       Total
--------------------------------------------------------
lvm_pool  lvm   1        0.00 KB  1020.00 MB  1020.00 MB
rhel      lvm   1        0.00 KB    14.51 GB    14.51 GB
--------------------------------------------------------
----------------------------------------------------------------------------------------------
Volume                 Pool      Volume size  FS      FS size        Free  Type    Mount point
----------------------------------------------------------------------------------------------
/dev/rhel/root         rhel         13.53 GB  xfs    13.52 GB     9.64 GB  linear  /
/dev/rhel/swap         rhel       1000.00 MB                               linear
/dev/lvm_pool/lvol001  lvm_pool    900.00 MB  xfs   896.67 MB   896.54 MB  linear
/dev/vda1                          500.00 MB  xfs   496.67 MB   403.56 MB  part    /boot
----------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------
Snapshot                           Origin   Pool      Volume size     Size  Type
----------------------------------------------------------------------------------
/dev/lvm_pool/snap20150519T130900  lvol001  lvm_pool    120.00 MB  0.00 KB  linear
----------------------------------------------------------------------------------

16.2.7. アイテムの削除

The sm remove は、デバイス、プール、またはボリュームのいずれか、項目を削除するために使用されます。
注記
デバイスがプールで使用されていると、そのデバイスがプールで使用されていると失敗します。これは、- f 引数を使用して強制できます。
ボリュームが削除時にマウントされると、そのボリュームは失敗します。デバイスとは異なり、- f 引数で強制 することはできません。
lvm_pool とその中にすべてを削除するには、以下のコマンドを使用します。
# ssm remove lvm_pool
Do you really want to remove volume group "lvm_pool" containing 2 logical volumes? [y/n]: y
Do you really want to remove active logical volume snap20150519T130900? [y/n]: y
  Logical volume "snap20150519T130900" successfully removed
Do you really want to remove active logical volume lvol001? [y/n]: y
  Logical volume "lvol001" successfully removed
  Volume group "lvm_pool" successfully removed

16.3. SSM リソース

SSM の詳細は、以下の資料を参照してください。

第17章 ディスククォータ

ディスク領域は、ユーザーがディスク領域を過剰に消費したり、パーティションが満杯になる前にシステム管理者に警告するディスククォータを実装することで制限できます。
ディスククォータは、個々のユーザーおよびユーザーグループに設定できます。これにより、ユーザー固有のファイル(電子メールなど)に割り当てられる領域を、ユーザーが作業するプロジェクトに割り当てられたスペースとは別に管理できます(プロジェクトには独自のグループが付与されていることを前提とします)。
さらに、クォータは、消費するディスクブロックの数を制御するだけでなく、inode の数を制御するだけでなく、UNIX ファイルシステムのファイルに関する情報を含むデータ構造などを設定できます。inode はファイル関連の情報が含まれるため、作成できるファイルの数を制御できます。
ディスククォータを実装するには、クォータ RPM がインストールされている必要があります。
注記
本章ではすべてのファイルシステムについて説明しますが、一部のファイルシステムには独自のクォータ管理ツールがあります。適用可能なファイルシステムに対応する説明を参照してください。
XFS ファイルシステムは、「XFS クォータ管理」 を参照してください。
Btrfs にはディスククォータがないため、対象外です。

17.1. ディスククォータの設定

ディスククォータを実装するには、以下の手順を行います。
  1. /etc/fstab ファイルを変更して、ファイルシステムごとにクォータを有効にします。
  2. ファイルシステムを再マウントします。
  3. クォータデータベースファイルを作成し、ディスク使用状況の表を生成します。
  4. クォータポリシーを割り当てます。
この各ステップは、以下のセクションで詳しく説明します。

17.1.1. クォータの有効化

手順17.1 クォータの有効化

  1. root でログインします。
  2. /etc/fstab ファイルを編集します。
  3. クォータを必要とするファイルシステムに、usrquota または grpquota または両方のオプションを追加します。

例17.1 Edit /etc/fstab

たとえば、テキストエディター vim を使用するには、以下を入力します。
# vim /etc/fstab

例17.2 クォータの追加

/dev/VolGroup00/LogVol00 /         ext3    defaults        1 1
LABEL=/boot              /boot     ext3    defaults        1 2
none                     /dev/pts  devpts  gid=5,mode=620  0 0
none                     /dev/shm  tmpfs   defaults        0 0
none                     /proc     proc    defaults        0 0
none                     /sys      sysfs   defaults        0 0
/dev/VolGroup00/LogVol02 /home     ext3    defaults,usrquota,grpquota  1 2
/dev/VolGroup00/LogVol01 swap      swap    defaults        0 0 . . .
この例では、/home ファイルシステムでは、ユーザーおよびグループ両方のクォータが有効化されています。
備考
以下の例では、Red Hat Enterprise Linux のインストール時に別の /home パーティションが作成されたことを仮定します。root(/)パーティションは、/etc/fstab ファイルでクォータポリシーを設定するために使用できます。

17.1.2. ファイルシステムの再マウント

usrquota または grpquota のいずれかのオプションを追加したら、fstab エントリー が変更された各ファイルシステムを再マウントします。ファイルシステムがプロセスで使用されていない場合は、以下のいずれかの方法で行います。
  • umount コマンドの後に mount コマンドを実行して、ファイルシステムを再マウントします。umountmount の両方で、さまざまなファイルシステムタイプをマウントおよびアンマウントする特定の構文の man ページを参照してください
  • mount -o remount file-system コマンドを実行します(file-system はファイルシステムの名前に置き換えます)。たとえば、/home ファイルシステムを再マウントするには、mount -o remount /home コマンドを実行します。
ファイルシステムが現在使用されている場合は、ファイルシステムを再マウントする最も簡単な方法でシステムを再起動します。

17.1.3. クォータデータベースファイルの作成

クォータが有効な各ファイルシステムを再マウントすると、quotacheck コマンドを実行します。
quotacheck コマンドは、クォータが有効なファイルシステムを検証し、現在のディスク使用状況のテーブルをファイルシステムごとに構築します。このテーブルは、ディスク使用状況のオペレーティングシステム用コピーを更新するのに使用されます。また、ファイルシステムのディスククォータが更新されます。
注記
ディスク使用量の表はマウント時に自動的に完了するため、quotacheck コマンドは XFS に効果がありません。詳細は、man ページの xfs_quota(8) を参照してください。

手順17.2 クォータデータベースファイルの作成

  1. 以下のコマンドを使用して、ファイルシステムにクォータファイルを作成します。
    # quotacheck -cug /file system
  2. 以下のコマンドを使用して、ファイルシステムごとの現在のディスク使用量の表を生成します。
    # quotacheck -avug
以下は、クォータファイルの作成に使用されるオプションです。
c
クォータ enable を使用して、各ファイルシステムにクォータファイルを作成する必要があることを指定します。
u
ユーザークォータをチェックします。
g
グループクォータをチェックします。-g のみを指定すると、グループクォータファイルのみが作成されます。
-u オプションまたは -g オプションがいずれも指定されていないと、ユーザーのクォータファイルのみが作成されます。
以下のオプションは、現在のディスク使用量の表を生成するために使用されます。
a
ローカルにマウントされたすべてのファイルシステムを確認します。
v
クォータチェックが続行されると詳細なステータス情報を表示します。
u
ユーザーディスクのクォータ情報の確認
g
グループのディスククォータ情報の確認
quotacheck の実行が終了すると、有効なクォータ(ユーザーまたはグループ、またはその両方)に対応するクォータファイルに、/home などのローカルにマウントされた各ファイルシステムのデータが設定されます。

17.1.4. ユーザーごとにクォータの割り当て

最後のステップは、edquota コマンドを使用したディスククォータ割り当てです。
前提条件
  • ユーザーは、ユーザークォータを設定する前に存在する必要があります。

手順17.3 ユーザーごとにクォータの割り当て

  1. ユーザーにクォータを割り当てるには、以下のコマンドを使用します。
    # edquota username
    username を、クォータを割り当てるユーザーに置き換えます。
  2. ユーザーのクォータが設定されていることを確認するには、次のコマンドを使用します。
    # quota username

例17.3 ユーザーへのクォータの割り当て

たとえば、クォータが / home パーティションに対して / etc/fstab で有効にされている場合(以下の例では /dev/VolGroup00/LogVol 02)および edquota testuser コマンドを実行すると、システムのデフォルトとして設定されたエディターに以下が表示されます。
Disk quotas for user testuser (uid 501):
		Filesystem                blocks     soft     hard    inodes   soft   hard
		/dev/VolGroup00/LogVol02  440436        0        0     37418      0      0
備考
EDITOR 環境変数により定義されたテキストエディターは、edquota により使用されます。エディターを変更するには、~/.bash_profile ファイルの EDITOR 環境変数を、使用するエディターのフルパスに設定します。
最初の列は、クォータが有効になっているファイルシステムの名前です。2 列目には、ユーザーが現在使用しているブロック数が示されます。その次の 2 列は、ファイルシステム上のユーザーのソフトブロック制限およびハードブロック制限を設定するのに使用されます。inodes 列には、ユーザーが現在使用している inode の数が表示されます。最後の 2 列は、ファイルシステムのユーザーに対するソフトおよびハードの inode 制限を設定するのに使用されます。
ハードブロック制限は、ユーザーまたはグループが使用できる最大ディスク容量 (絶対値) です。この制限に達すると、それ以上のディスク領域は使用できなくなります。
ソフトブロック制限は、使用可能な最大ディスク容量を定義します。ただし、ハード制限とは異なり、ソフト制限は一定時間超過する可能性があります。この時間は 猶予期間 として知られています。猶予期間の単位は、秒、分、時間、日、週、または月で表されます。
いずれかの値が 0 に設定されていると、その制限は設定されません。テキストエディターで必要な制限を変更します。

例17.4 Change Desired Limits

以下に例を示します。
Disk quotas for user testuser (uid 501):
Filesystem                blocks     soft     hard   inodes   soft   hard
/dev/VolGroup00/LogVol02  440436   500000   550000    37418      0      0
ユーザーのクォータが設定されていることを確認するには、以下のコマンドを使用します。
# quota testuser
Disk quotas for user username (uid 501):
   Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
     /dev/sdb    1000*   1000    1000               0       0       0

17.1.5. グループごとのクォータの割り当て

クォータは、グループごとに割り当てることもできます。
前提条件
  • グループは、グループクォータを設定する前に存在している必要があります。

手順17.4 グループごとのクォータの割り当て

  1. グループクォータを設定するには、以下のコマンドを使用します。
    # edquota -g groupname
  2. グループクォータが設定されていることを確認するには、次のコマンドを使用します。
    # quota -g groupname

例17.5 グループへのクォータの割り当て

たとえば、devel グループのグループクォータを設定するには、以下のコマンドを使用します。
# edquota -g devel
このコマンドにより、グループの既存クォータがテキストエディターに表示されます。
Disk quotas for group devel (gid 505):
Filesystem                blocks    soft     hard    inodes    soft    hard
/dev/VolGroup00/LogVol02  440400       0        0     37418       0       0
この制限を変更して、ファイルを保存します。
グループクォータが設定されていることを確認するには、以下のコマンドを使用します。
# quota -g devel

17.1.6. Soft 制限の Grace Period の設定

特定のクォータにソフト制限がある場合、以下のコマンドを使用して猶予期間(ソフト制限を超過できる時間など)を編集できます。
# edquota -t
このコマンドは、ユーザーまたはグループに対して、inode またはブロックのクォータで機能します。
重要
他の edquota コマンドは特定のユーザーまたはグループのクォータで機能しますが、- t オプションはクォータが有効になっているすべてのファイルシステムで動作します。

17.2. ディスククォータの管理

クォータが実装されている場合には、クォータを超過し、クォータが正しいことを確認するためを監視するという形で、ほとんどメンテナンスが必要になります。
ユーザーが繰り返しクォータを超過したり、常にソフト制限に達している場合、システム管理者には、ユーザーのタイプや、ユーザーの作業にディスク容量が及ぼす影響の度合に応じて 2 つの選択肢があります。管理者は、ユーザーが使用するディスク領域を節約する方法をわかるようにするか、ユーザーのディスククォータを拡大するかのいずれかを行うことができます。

17.2.1. 有効化と無効化

クォータは 0 に設定せずに無効にすることができます。すべてのユーザーおよびグループのクォータをオフにするには、以下のコマンドを使用します。
# quotaoff -vaug
-u オプションまたは -g オプションがいずれも指定されていないと、ユーザーのクォータのみが無効になります。-g のみを指定すると、グループのクォータのみが無効になります。-v スイッチにより、コマンドの実行時に詳細なステータス情報が表示されます。
ユーザーとグループのクォータを再度有効にするには、以下のコマンドを使用します。
# quotaon
すべてのファイルシステムでユーザーおよびグループのクォータを有効にするには、以下のコマンドを使用します。
# quotaon -vaug
-u オプションまたは -g オプションがいずれも指定されていないと、ユーザーのクォータのみが有効になります。-g のみを指定すると、グループクォータのみが有効になります。
/home などの特定のファイルシステムのクォータを有効にするには、以下のコマンドを使用します。
# quotaon -vug /home
注記
quotaon コマンドは、マウント時に自動的に実行されるため、XFS に常に必要な訳ではありません。詳細は、man ページの quotaon(8) を参照してください。

17.2.2. ディスククォータに関するレポート

ディスク使用状況レポートを作成すると、repquota ユーティリティーが実行されます。

例17.6 repquota コマンドの出力

たとえば、コマンド repquota /home により、以下のような出力が表示されます。
*** Report for user quotas on device /dev/mapper/VolGroup00-LogVol02
Block grace time: 7days; Inode grace time: 7days
			Block limits			File limits
User		used	soft	hard	grace	used	soft	hard	grace
----------------------------------------------------------------------
root      --      36       0       0              4     0     0
kristin   --     540       0       0            125     0     0
testuser  --  440400  500000  550000          37418     0     0
クォータが有効なすべてのファイルシステム (オプション -a) のディスク使用状況レポートを表示するには、次のコマンドを使用します。
# repquota -a
レポートは読みやすいですが、いくつか説明しておくべき点があります。各ユーザーに続いて表示される -- は、ブロックまたは inode の制限を超えたかどうかを簡単に判断できます。ソフト制限のいずれかを超えると、対応する - の代わりに + が表示されます。最初の - はブロック制限を表し、2 つ目は inode の制限を表します。
grace 列は通常空白です。ソフト制限が超過した場合、その列には猶予期間に残り時間量に相当する時間指定が含まれます。猶予期間の期間が過ぎると、none がその場所に表示されます。

17.2.3. クォータの精度維持

システムクラッシュなどの理由でファイルシステムを正常にアンマウントできない場合は、以下のコマンドを実行する必要があります。
# quotacheck
ただし、システムがクラッシュした場合でも、quotacheck は定期的に実行できます。quotacheck を定期的に実行する安全な方法には、以下が含まれます。
クォータチェックを次回再起動で実行するようにする
大半のシステムの最良の方法
この方法は、定期的に再起動する(busy)マルチユーザーシステムにとって最適です。
シェルスクリプトを /etc/cron.daily/ ディレクトリーまたは /etc/cron.weekly/ ディレクトリーに保存するか、以下のコマンドを実行してそのスクリプトをスケジュールします。
# crontab -e
crontab -e コマンドには、touch /forcequotacheck コマンドが含まれます。これにより、root ディレクトリーに空の forcequotacheck ファイルが作成され、システムの起動時にシステムの init スクリプトが検索されます。見つかった場合、init スクリプトは quotacheck を実行します。その後、init スクリプトは /forcequotacheck ファイルを削除し、このファイルを cron で定期的に作成すると、次回の再起動時に quotacheck が実行されるようにします。
cron の詳細は、man cron を参照してください。
単一ユーザーモードでの quotacheck の実行
quotacheck を安全に実行する別の方法として、システムをシングルユーザーモードで起動して、クォータファイルでのデータ破損を防ぎ、以下のコマンドを実行します。
# quotaoff -vug /file_system
# quotacheck -vug /file_system
# quotaon -vug /file_system
実行中のシステムでの quotacheck の実行
必要に応じて、ユーザーがログインしない場合に、マシンでクォータ チェックを実行することができ、その結果、ファイルシステムのファイルがチェックされません。quotacheck -vug file_system コマンドを実行します。このコマンドは、quotacheck が読み取り専用として所定の file_system を再マウントできない場合に失敗します。この確認を行うと、ファイルシステムは読み取り/書き込みで再マウントされることに注意してください。
警告
クォータファイルが破損する可能性があるため、読み取り/書き込みがマウントされているライブファイルシステムで quotacheck を実行することは推奨されません。
cron の設定に関する詳細は、man cron を参照してください。

17.3. ディスククォータの参照

ディスククォータの詳細は、次のコマンドの man ページを参照してください。
  • quotacheck
  • edquota
  • repquota
  • quota
  • quotaon
  • quotaoff

第18章 RAID(Redundant Array of Independent Disks)

RAID の背後にある基本的な概念は、複数の小さいディスクドライブをアレイに統合し、1 つの大規模で高価なドライブでは実現できないパフォーマンスや冗長性の目標を達成することです。このドライブは、1 つの論理ストレージユニットまたはドライブとしてコンピューターに表示されます。
RAID により、情報を複数のディスクに分散させることができます。RAID は、ディスクストライピング (RAID レベル 0)、ディスクミラーリング (RAID レベル 1)、および パリティーによるディスクストライピング (RAID レベル 5)などのテクニックを使用して冗長性を実現し、レイテンシーが拡大し、帯域幅を最大化し、ハードディスククラッシュからの復旧能力を最大化します。
RAID は、データを一貫して使用するチャンク(通常は 256K または 512k、他の値は受け入れ可能)に分割することで、アレイ内の各ドライブにデータを分散します。各チャンクは、使用している RAID レベルに応じて、RAID アレイのハードドライブに書き込まれます。データが読み込まれると、プロセスは逆の場合、アレイ内の複数のドライブが実際に 1 つの大きなドライブであることを確認できます。
システム管理者や大容量のデータを管理しているユーザーは、RAID 技術を使用することでメリットが得られます。RAID をデプロイする主な理由を以下に示します。
  • 速度を高める
  • 1 台の仮想ディスクを使用してストレージ容量を増加する
  • ディスク障害によるデータ損失を最小限に抑える

18.1. RAID のタイプ

考えられる RAID アプローチには、ファームウェア RAID、ハードウェア RAID、およびソフトウェア RAID の 3 つがあります。

ファームウェア RAID

ファームウェア RAID (ATARAID とも呼ばれる)は、ソフトウェア RAID の種類で、ファームウェアベースのメニューを使用して RAID セットを設定できます。このタイプの RAID で使用されるファームウェアは BIOS にもフックされるため、その RAID セットから起動できます。異なるベンダーは、異なるオンディスクメタデータ形式を使用して、RAID セットのメンバーをマークします。Intel Matrix RAID は、ファームウェア RAID システムの一例を示しています。

ハードウェア RAID

ハードウェアベースのアレイは、RAID サブシステムをホストとは別に管理します。RAID アレイごとに 1 つのディスクをホストに提示します。
ハードウェア RAID デバイスは、システムに内部または外部となる場合があります。内部デバイスは、通常、特殊なコントローラーカードで構成されており、オペレーティングシステムに対して RAID タスクを透過的に、外部のデバイスとともに、SCSI、ファイバーチャネル、iSCSI、InfiniBand などの高速度のネットワーク相互接続を介してシステムへ一般的に接続し、システムへの論理ボリュームを表示します。
RAID コントローラーカードは、オペレーティングシステムへの SCSI コントローラーのように動作し、実際のドライブ通信をすべて処理します。ドライブを RAID コントローラーにプラグインし(通常の SCSI コントローラーのように)、RAID コントローラーの設定に追加します。オペレーティングシステムはこの違いを認識できません。

ソフトウェア RAID

ソフトウェア RAID は、カーネルディスク(ブロックデバイス)コードにさまざまな RAID レベルを実装します。高価ディスクコントローラーカードやホットスワップシャーシなど、最優先的な解決策を提供します。 [2] 必須ではありません。ソフトウェア RAID は、シャーカー IDE ディスク、および SCSI ディスクでも機能します。現在高速 CPU では、ソフトウェア RAID は通常、ハードウェア RAID を上回ります。
Linux カーネルには、RAID ソリューションは完全にハードウェアに依存しない マルチディスク( MD)ドライバーが含まれています。ソフトウェアベースのアレイのパフォーマンスは、サーバーの CPU パフォーマンスと負荷によって異なります。
Linux ソフトウェア RAID スタックの主な機能:
  • マルチスレッド設計
  • 再構築なしで Linux マシン間でのアレイの移植性
  • アイドルシステムリソースを使用したバックグラウンドのアレイ再構築
  • ホットスワップ可能なドライブのサポート
  • CPU の自動検出は、ストリーミング SIMD サポートなどの特定の CPU 機能を活用します。
  • アレイ内のディスク上にある不良セクターの自動修正
  • RAID データの整合性を定期的にチェックしアレイの健全性を確保
  • 重要なイベントで指定された電子メールアドレスに送信された電子メールアラートによるアレイのプロアクティブな監視
  • アレイ全体を再同期するのではなく、ディスクのどの部分を再同期する必要があるかをカーネルが正確に把握できるようにすることで、再同期イベントの速度を大幅に向上させる書き込み統合のビットマップ
  • チェックポイントを再同期して、再同期中にコンピューターを再起動すると、起動時に再同期が中断したところから再開し、最初からやり直さないようにします。
  • インストール後にアレイのパラメーターを変更する機能。たとえば、新しいディスクを追加しても、4 つのディスクの RAID5 アレイを 5 つのディスク RAID5 アレイに拡張できます。この拡張操作はライブで行うため、新しいアレイで再インストールする必要はありません。

18.2. RAID レベルとリニアサポート

RAID は、レベル 0、1、4、5、6、10、リニアなどのさまざまな設定に対応します。これらの RAID タイプは以下のように定義されます。
レベル 0
RAID レベル 0 は、多くの場合「ストライプ化」と呼ばれていますが、パフォーマンス指向のストライプ化データマッピング技術です。これは、アレイに書き込まれるデータが取り除かれ、アレイ内のメンバーディスク全体に書き込まれることを意味します。これにより、固有のコストで高い I/O パフォーマンスを実現できますが、冗長性は提供されません。
多くの RAID レベル 0 実装は、アレイ内の最小デバイスのサイズまで、メンバーデバイス全体にデータをストライプ化します。つまり、複数のデバイスのサイズが少し異なる場合、それぞれのデバイスは最小ドライブと同じサイズであるかのように処理されます。そのため、レベル 0 アレイの一般的なストレージ容量は、ハードウェア RAID 内の最小メンバーディスクの容量と同じか、アレイ内のディスク数またはパーティション数で乗算したソフトウェア RAID 内の最小メンバーパーティションの容量と同じになります。
レベル 1
RAID レベル 1 または「ミラーリング」は、他の RAID 形式よりも長く使用されています。レベル 1 は、アレイ内の各メンバーディスクに同一データを書き込むことで冗長性を提供し、各ディスクに対して「ミラーリング」コピーをそのまま残します。ミラーリングは、データの可用性の単純化と高レベルにより、いまでも人気があります。レベル 1 は 2 つ以上のディスクと連携して、非常に優れたデータ信頼性を提供し、読み取り集中型のアプリケーションに対してパフォーマンスが向上しますが、比較的コストが高くなります。[3]
レベル 1 アレイのストレージ容量は、ハードウェア RAID 内でミラーリングされている最小サイズのハードディスクの容量と同じか、ソフトウェア RAID 内でミラーリングされている最小のパーティションと同じ容量になります。レベル 1 の冗長性は、すべての RAID タイプの中で最も高いレベルであり、アレイは 1 つのディスクのみで動作できます。
レベル 4
レベル 4 でパリティーを使用 [4] データを保護するため、1 つのディスクドライブで連結します。専用パリティーディスクは RAID アレイへのすべての書き込みトランザクションに固有のボトルネックを表すため、レベル 4 は、ライトバックキャッシュなどの付随技術なしで、またはシステム管理者がこれを使用してソフトウェア RAID デバイスを意図的に設計する特定の状況で使用されることはほとんどありません。ボトルネック (配列にデータが入力されると、書き込みトランザクションがほとんどまたはまったくない配列など) を念頭に置いてください。RAID レベル 4 にはほとんど使用されないため、Anaconda ではこのオプションとしては使用できません。ただし、実際には必要な場合は、ユーザーが手動で作成できます。
ハードウェア RAID レベル 4 のストレージ容量は、最小メンバーパーティションの容量にパーティションの数を掛けて、-1 を引いたものになります。RAID レベル 4 アレイのパフォーマンスは常に非対称になります。つまり、読み込みは書き込みを上回ります。これは、パリティーを生成するときに書き込みが余分な CPU 帯域幅とメインメモリーの帯域幅を消費し、データだけでなくパリティーも書き込むため、実際のデータをディスクに書き込むときに余分なバス帯域幅も消費するためです。読み取りが必要なのは、アレイが劣化状態にない限り、パリティーではなくデータでを読み取るだけです。その結果、通常の動作条件下で同じ量のデータ転送用に、読み取りによってドライブおよびコンピューターのバス全体へのトラフィック量が少なくなります。
レベル 5
これは RAID の最も一般的なタイプです。RAID レベル 5 は、アレイのすべてのメンバーディスクドライブにパリティーを分散することにより、レベル 4 に固有の書き込みボトルネックを排除します。パリティー計算プロセス自体のみがパフォーマンスのボトルネックです。最新の CPU とソフトウェア RAID では、最近の CPU がパリティーが非常に高速になるため、通常はボトルネックではありません。ただし、ソフトウェア RAID5 アレイに多数のメンバーデバイスがあり、組み合わせたすべてのデバイス間のデータ転送速度が十分であれば、このボトルネックは再生できます。
レベル 4 と同様に、レベル 5 のパフォーマンスは非対称であり、読み取りは書き込みを大幅に上回ります。RAID レベル 5 のストレージ容量は、レベル 4 と同じです。
レベル 6
パフォーマンスではなくデータの冗長性と保存が最重要事項であるが、レベル 1 の領域の非効率性が許容できない場合は、これが RAID の一般的なレベルです。レベル 6 では、複雑なパリティースキームを使用して、アレイ内の 2 つのドライブから失われたドライブから復旧できます。複雑なパリティースキームにより、ソフトウェア RAID デバイスで CPU 幅が大幅に高くなり、書き込みトランザクションの際に増大度が高まります。したがって、レベル 6 はレベル 4 や 5 よりもパフォーマンスにおいて、非常に非対称です。
RAID レベル 6 アレイの合計容量は、RAID レベル 5 および 4 と同様に計算されますが、デバイス数から追加パリティーストレージ領域用に 2 つのデバイス (1 ではなく) を引きます。
レベル 10
この RAID レベルでは、レベル 0 のパフォーマンスとレベル 1 の冗長性を組み合わせます。また、2 を超えるデバイスを持つレベル 1 アレイで領域の一部を軽減するのに役立ちます。レベル 10 では、データごとに 2 つのコピーのみを格納するように設定された 3 ドライブアレイを作成できます。これにより、全体のアレイサイズが最小デバイスのみと同じサイズ(3 つのデバイス、レベル 1 アレイなど)ではなく、最小デバイスのサイズが 1.5 倍になります。
レベル 10 アレイを作成し、特定のユースケースに適切なオプションを選択する際の複雑なオプションを選択する際のオプションの数により、インストール時に作成することが難しくなります。コマンドラインの mdadm ツールを使用して手動で作成できます。オプションおよび各パフォーマンスのトレードオフに関する詳細は、man md を参照してください。
リニア RAID
リニア RAID は、より大きな仮想ドライブを作成するドライブのグループ化です。リニア RAID では、あるメンバードライブからチャンクが順次割り当てられます。最初のドライブが完全に満杯になったときにのみ次のドライブに移動します。これにより、メンバードライブ間の I/O 操作が分割される可能性はないため、パフォーマンスの向上は見られません。リニア RAID には冗長性がなく、信頼性は低下します。メンバードライブに障害が発生した場合は、アレイ全体を使用することはできません。容量はすべてのメンバーディスクの合計になります。


[3] RAID レベル 1 は、アレイ内のすべてのディスクに同じ情報を書き込むため、コストが高まり、データの信頼性を提供しますが、レベル 5 のようなパリティーベースの RAID レベルよりもはやくなり領域の効率が低くなります。ただし、この領域の非効率性にはパフォーマンス上の利点があります。パリティーベースの RAID レベルは、パリティーを生成するためにかなり多くの CPU 電力を消費しますが、RAID レベル 1 は単に同じデータを、CPU オーバーヘッドが非常に少ない複数の RAID メンバーに同じデータを複数回書き込むだけです。そのため、RAID レベル 1 は、ソフトウェア RAID が使用されているマシンや、マシンの CPU リソースが一貫して RAID アクティビティー以外の操作でアレイ化されます。
[4] パリティー情報は、アレイ内の残りのメンバーディスクのコンテンツに基づいて計算されます。この情報は、アレイ内のいずれかのディスクに障害が発生した場合にデータの再構築に使用できます。その後、再構築されたデータを使用して、交換前に失敗したディスクに I/O 要求に対応でき、交換後に失敗したディスクを接続します。

18.3. Linux RAID サブシステム

Linux の RAID は、以下のサブシステムで構成されます。

Linux ハードウェア RAID のコントローラードライバー

Linux には、ハードウェア RAID コントローラーに固有の RAID サブシステムがありません。特殊な RAID チップセットを使用するため、ハードウェア RAID コントローラーには独自のドライバーが含まれます。これらのドライバーにより、システムは通常のディスクとして RAID セットを検出できるようになります。

mdraid

mdraid サブシステムは Linux 向けのソフトウェア RAID ソリューションとして設計されており、Linux 下のソフトウェア RAID に推奨されるソリューションです。このサブシステムは独自のメタデータ形式を使用し、通常はネイティブの mdraid メタデータと呼ばれます。
mdraid は外部メタデータとして知られる他のメタデータ形式もサポートします。Red Hat Enterprise Linux 7 は、外部メタデータで mdraid を使用して ISW / IMSM(Intel ファームウェア RAID)セットにアクセスします。mdraid セットは、mdadm ユーティリティーを使用して設定および制御します。

dmraid

dmraid ツールは、さまざまなファームウェア RAID 実装で使用されます。dmraid は Intel ファームウェア RAID もサポートしますが、Red Hat Enterprise Linux 7 は mdraid を使用して Intel ファームウェア RAID セットにアクセスします。
注記
dmraid は、Red Hat Enterprise Linux 7.5 リリース以降非推奨になりました。Red Hat Enterprise Linux の将来のメジャーリリースで削除される予定です。詳細は、『Red Hat Enterprise Linux 7.5 リリースノート』の「非推奨の機能」を参照してください。

18.4. Anaconda インストーラーにおける RAID サポート

Anaconda インストーラーは、システムのハードウェアおよびファームウェアの RAID セットを自動的に検出し、インストールを可能にします。Anaconda は、mdraid を使用したソフトウェア RAID にも対応し、既存の mdraid セットを認識できます。
Anaconda は、インストール時に RAID セットを作成するためのユーティリティーを提供します。ただし、このユーティリティーは、(ディスク全体ではなく)パーティションのみを新規セットのメンバーに許可します。セットにディスク全体を使用するには、ディスク全体にまたがるパーティションを作成し、そのパーティションを RAID セットメンバーとして使用します。
root ファイルシステムが RAID セットを使用する場合、Anaconda は、root ファイルシステムを検索する前に、ブートローダー設定に特別なカーネルのコマンドラインオプションを追加して、initrd セットをアクティベートするよう指示します。
インストール時の RAID の設定方法は『Red Hat Enterprise Linux 7 インストールガイド』を参照してください

18.5. インストール後の root ディスクの RAID1 への変換

Red Hat Enterprise Linux 7 のインストール後に非 RAID ルートディスクを RAID1 mirror に変換する必要がある場合は、Red Hat ナレッジベースの記事「 How do I convert my root disk to RAID1 after installation of Red Hat Enterprise Linux 7?」を参照してください。
PowerPC (PPC) アーキテクチャーでは、以下の追加手順を行う必要があります。
  1. PowerPC Reference Platform (PReP) 起動パーティションの内容を /dev/sda1 から /dev/sdb1 にコピーします。
    # dd if=/dev/sda1 of=/dev/sdb1 
  2. 両方のディスクの最初のパーティションで Prep フラグおよび boot フラグを更新します。
    $ parted /dev/sda set 1 prep on
    $ parted /dev/sda set 1 boot on
    
    $ parted /dev/sdb set 1 prep on
    $ parted /dev/sdb set 1 boot on 
注記
PowerPC マシンでは grub2-install /dev/sda コマンドを実行しても機能せず、エラーが返されますが、システムは想定どおりに起動します。

18.6. RAID セットの設定

ほとんどの RAID セットは、一般的にファームウェアメニューまたはインストーラーから設定されます。システムのインストール後に RAID セットを作成または変更する必要がある場合があります。マシンを再起動してファームウェアメニューを入力する必要はありません。
ハードウェア RAID コントローラーによっては、RAID セットをオンザフライで設定したり、追加のディスクを追加した後に完全に新しいセットを定義したりできます。これには標準 API がないため、ドライバー固有のユーティリティーを使用する必要があります。詳細は、ハードウェア RAID コントローラーのドライバーのドキュメントを参照してください。

mdadm

mdadm コマンドラインツールは、Linux のソフトウェア RAID の管理に使用されます( mdraid )。mdadm モードおよびオプションの詳細は、man mdadm を参照してくださいman ページには、ソフトウェア RAID アレイの作成、監視、アセンブルなどの一般的な操作に関する便利な例も含まれています。

dmraid

この名前が示すように、dmraid は device-mapper RAID セットを管理するために使用されます。dmraid ツールは、複数のメタデータ形式ハンドラーを使用して ATARAID デバイスを検索し、それぞれが対応するさまざまな形式に対応します。対応している形式の全一覧については、dmraid -l を実行します。
「Linux RAID サブシステム」 で説明したように、dmraid ツールは作成後に RAID セットを設定できません。dmraid の使用に関する詳細は、man dmraid を参照してください。

18.7. 高度な RAID デバイスの作成

インストール完了後に作成できないアレイにオペレーティングシステムをインストールする場合があります。通常、/boot または root ファイルシステムアレイを複雑な RAID デバイスに設定することを意味します。このような場合は、Anaconda で対応していないアレイオプションを使用する必要がある場合があります。これを回避するには、以下の手順を行います。

手順18.1 高度な RAID デバイスの作成

  1. インストールディスクを挿入します。
  2. 初回起動時に、Install または Upgrade ではなく、Rescue Mode を選択します。システムが レスキューモード で完全に起動すると、コマンドラインターミナルが表示されます。
  3. このターミナルで parted を使用して、ターゲットのハードドライブに RAID パーティションを作成します。mdadm を使用して、使用できるすべての設定およびオプションを使用して、このパーティションから RAID アレイを手動で作成します。これらの実行方法の詳細は、13章Partitionsman parted、および man mdadm を参照してください。
  4. アレイを作成したら、必要に応じてアレイにファイルシステムを作成することもできます。
  5. コンピューターを再起動し、この時間では Install or Upgrade を選択して通常通りにインストールします。Anaconda がシステム内のディスクを検索すると、既存の RAID デバイスが見つかります。
  6. システムのディスクの使用方法を求められたら、カスタムレイアウト を選択して 次へ をクリックします。デバイス一覧に、既存の MD RAID デバイスが表示されます。
  7. RAID デバイスを選択し、編集 をクリックしてそのマウントポイントと (必要に応じて) 使用するファイルシステムのタイプを設定し、完了 をクリックします。Anaconda は、この既存の RAID デバイスにインストールを実行し、レスキューモード で作成したときに選択したカスタムオプションを保持します。
注記
インストーラーの制限された レスキューモード には man ページは含まれません。man mdadm および man md の両方には、カスタムの RAID アレイ作成に役立つ情報が含まれています。回避策全体にわたって必要になる場合があります。このため、man ページが含まれるマシンにアクセスしたり、レスキューモード で起動する前に出力したり、カスタムアレイを作成すると便利です。


[2] ホットスワップシャーシを使用すると、システムの電源を切らずにハードドライブを削除できます。

第19章 mount コマンドの使用

Linux、UNIX、および同様のオペレーティングシステムでは、さまざまなパーティションおよびリムーバブルデバイス(CD、DVD、または USB フラッシュドライブなど)にあるファイルシステムをディレクトリーツリーの特定のポイント( マウントポイント)に接続して、再度切り離すことができます。ファイルシステムをアタッチまたは切断するには、mount または umount コマンドをそれぞれ使用します。本章では、これらのコマンドの基本的な使用方法と、マウントポイントの移動、共有サブツリーの作成など、高度なトピックについて説明します。

19.1. 現在マウントされているファイルシステムの一覧表示

現在割り当てられているファイルシステムをすべて表示するには、引数なしで次のコマンドを使用します。
$ mount
このコマンドは、既知のマウントポイントの一覧を表示します。各行は、デバイス名、ファイルシステムタイプ、マウントされるディレクトリー、および以下のような形式の適切なマウントオプションに関する重要な情報を提供します。
ディレクトリー タイプ 上の デバイスオプション
マウントされたファイルシステムをツリーのような形式でリストできる findmnt ユーティリティーは、Red Hat Enterprise Linux 6.1 からも利用できます。現在割り当てられているファイルシステムをすべて表示するには、引数なしで findmnt コマンドを実行します。
$ findmnt

19.1.1. ファイルシステムタイプの指定

デフォルトでは、mount コマンドの出力には、sysfstmpfs などのさまざまな仮想ファイルシステムが含まれます。特定のファイルシステムタイプを持つデバイスのみを表示するには、- t オプションを指定します。
$ mount -t type
同様に、findmnt コマンドを使用して、特定のファイルシステムを持つデバイスのみを表示するには、次のコマンドを実行します。
$ findmnt -t type
一般的なファイルシステムのタイプの一覧は、表19.1「一般的なファイルシステムのタイプ」 を参照してください。使用方法例については、例19.1「現在マウントされている ext4 ファイルシステム の一覧表示」 を参照してください。

例19.1 現在マウントされている ext4 ファイルシステム の一覧表示

通常、/ パーティションと / boot の両方のパーティションが、ext4 を使用するようにフォーマットされています。このファイルシステムを使用するマウントポイントのみを表示するには、以下のコマンドを使用します。
$ mount -t ext4
/dev/sda2 on / type ext4 (rw)
/dev/sda1 on /boot type ext4 (rw)
findmnt コマンドを使用して、このようなマウントポイントを一覧表示するには、以下を入力します。
$ findmnt -t ext4
TARGET SOURCE    FSTYPE OPTIONS
/      /dev/sda2 ext4   rw,realtime,seclabel,barrier=1,data=ordered
/boot  /dev/sda1 ext4   rw,realtime,seclabel,barrier=1,data=ordered

19.2. ファイルシステムのマウント

特定のファイルシステムを添付する場合は、以下の形式で mount コマンドを使用します。
$ mount [option]… device directory
デバイスは 以下で識別できます。
  • ブロックデバイス への完全パス(例: /dev/sda3)
  • UUID( Universally unique Identifier )- UUID=34795a28-ca6d-4fd8-a347-73671d0c19cbなど
  • ボリュームラベル: LABEL=homeなど
ファイルシステムがマウントされている間は、ディレクトリーの 元のコンテンツにアクセスできない点に注意してください。
重要: Directory が使用されていない状態にする
Linux では、ユーザーが、ファイルシステムがすでに接続されているディレクトリーにファイルシステムをマウントできなくなります。特定のディレクトリーがマウントポイントとして機能しているかどうかを確認するには、ディレクトリーを引数として findmnt ユーティリティーを実行し、終了コードを確認します。
findmnt directory; echo $?
ファイルシステムがディレクトリーにアタッチされていない場合は、指定のコマンドは 1 を返します。
デバイス名、ターゲットディレクトリー、またはファイルシステムタイプがない、必要な情報なしで mount コマンドを実行すると、マウントは /etc/fstab ファイルの内容を読み取り、指定のファイルシステムがリストされていることを確認します。/etc/fstab ファイルには、選択したファイルシステムがマウントされるデバイス名およびディレクトリーのリストと、ファイルシステムタイプとマウントオプションが含まれます。したがって、/etc/fstab で指定されたファイルシステムをマウントする場合は、以下のいずれかのオプションを選択できます。
mount [option]… directory
mount [option]… device
コマンドが root として実行されていない限り、ファイルシステムをマウントするのにパーミッションが必要な点に注意してください( 「マウントオプションの指定」を参照してください)。
注記: パートデバイスの UUID とラベルの決定
そのデバイスが、特定のデバイスのラベルを使用している場合に、次の形式で blkid コマンドを使用します。
blkid device
たとえば、/dev/sda3 に関する情報を表示するには、次のコマンドを実行します。
# blkid /dev/sda3
/dev/sda3: LABEL="home" UUID="34795a28-ca6d-4fd8-a347-73671d0c19cb" TYPE="ext3"

19.2.1. ファイルシステムタイプの指定

ほとんどの場合、mount はファイルシステムを自動的に検出します。ただし、NFS (Network File System)や CIFS (Common Internet File System)などの特定のファイルシステムは、認識されないため、手動で指定する必要があります。ファイルシステムのタイプを指定するには、以下の形式で mount コマンドを使用します。
$ mount -t type デバイスディレクトリー
表19.1「一般的なファイルシステムのタイプ」 は、mount コマンドで使用できる一般的なファイルシステムのタイプの一覧を提供します。利用可能なファイルシステムタイプの完全なリストは、「man ページのドキュメント」 を参照してください。

表19.1 一般的なファイルシステムのタイプ

タイプ 説明
ext2 ext2 ファイルシステム。
ext3 ext3 ファイルシステム。
ext4 ext4 ファイルシステム。
btrfs btrfs ファイルシステム。
xfs xfs ファイルシステム。
iso9660 ISO 9660 ファイルシステム。通常、これは光学メディア (通常は CD) で使用されます。
nfs NFS ファイルシステム。通常、これはネットワーク経由でファイルにアクセスするために使用されます。
nfs4 NFSv4 ファイルシステム。通常、これはネットワーク経由でファイルにアクセスするために使用されます。
udf UDF ファイルシステム。通常、これは光学メディア (通常は DVD) で使用されます。
vfat FAT ファイルシステム。通常、これは Windows オペレーティングシステムを実行しているマシンや、USB フラッシュドライブやフロッピーディスクなどの特定のデジタルメディアで使用されます。
使用例は、例19.2「USB フラッシドライブのマウント」 を参照してください。

例19.2 USB フラッシドライブのマウント

多くの場合、古い USB フラッシュドライブは FAT ファイルシステムを使用します。このようなドライブが /dev/sdc1 デバイスを使用し、/media/flashdisk/ ディレクトリーが存在すると仮定して、root でシェルプロンプトに以下を入力し、このディレクトリーにマウントします。
~]# mount -t vfat /dev/sdc1 /media/flashdisk

19.2.2. マウントオプションの指定

追加のマウントオプションを指定するには、以下の形式でコマンドを実行します。
mount -o options device directory
複数のオプションを指定する場合は、コンマの後にスペースを挿入しないでください。挿入すると、mount はスペースに続く値を追加のパラメーターとして誤って解釈します。
表19.2「一般的なマウントオプション」 一般的なマウントオプションの一覧を提供します。利用可能なオプションの一覧は、「man ページのドキュメント」 に記載の関連する man ページを参照してください。

表19.2 一般的なマウントオプション

オプション 説明
async ファイルシステムで非同期の入出力操作を許可します。
auto mount -a コマンドを使用して、ファイルシステムを自動的にマウントできるようにします。
defaults async,auto,dev,exec,nouser,rw,suid のエイリアスを指定します。
exec 特定のファイルシステムでのバイナリーファイルの実行を許可します。
loop イメージをループデバイスとしてマウントします。
noauto デフォルトの動作では、mount -a コマンドを使用したファイルシステムの自動マウント ができません。
noexec 特定のファイルシステムでのバイナリーファイルの実行は許可しません。
nouser 通常のユーザー(つまり root以外のユーザー)によるファイルシステムのマウントおよびアンマウントは許可しません。
remount ファイルシステムがすでにマウントされている場合は再度マウントを行います。
ro 読み取り専用でファイルシステムをマウントします。
rw ファイルシステムを読み取りと書き込み両方でマウントします。
user 通常のユーザー(つまり root以外のユーザー)によるファイルシステムのマウントおよびアンマウントを許可します。
使用例は、例19.3「ISO イメージのダウンロード」 を参照してください。

例19.3 ISO イメージのダウンロード

ISO イメージ(または一般的なディスクイメージ)は、ループデバイスを使用してマウントできます。Fedora 14 インストールディスクの ISO イメージが現在の作業ディレクトリーに存在し、/media/cdrom/ ディレクトリーが存在する場合は、以下のコマンドを実行してイメージをこのディレクトリーにマウントします。
# mount -o ro,loop Fedora-14-x86_64-Live-Desktop.iso /media/cdrom
ISO 9660 は読み取り専用ファイルシステムを設計することで注意してください。

19.2.3. マウントの共有

場合によっては、特定のシステム管理タスクでは、ディレクトリーツリー内の複数の場所から同じファイルシステムにアクセスする必要がある場合があります(例: chroot 環境を準備する場合など)。これは可能で、Linux では、必要に応じて多くのディレクトリーに、同じファイルシステムをマウントできます。さらに、mount コマンドは、特定のマウント を複製する手段を提供する --bind オプションを実装します。以下のような使用法になります。
$ mount --bind old_directory new_directory
このコマンドは、両方の場所からファイルシステムにアクセスできますが、元のディレクトリー内にマウントされているファイルシステムには適用されません。これらのマウントも追加するには、以下のコマンドを使用します。
$ mount --rbind old_directory new_directory
また、可能な限り柔軟性を確保するために、Red Hat Enterprise Linux 7 は 共有サブツリー として知られる機能を実装します。この機能により、以下の 4 つのマウントタイプを使用できます。
共有マウント
共有マウントでは、指定したマウントポイントの正確なレプリカを作成できます。マウントポイントが共有マウントとしてマークされている場合は、元のマウントポイント内のすべてのマウントが複製マウントポイントに反映されます (その逆も同様です)。マウントポイントの種類を共有マウントに変更するには、シェルプロンプトで以下を入力します。
$ mount --make-shared mount_point
または、選択したマウントポイントと、その下のすべてのマウントポイントのマウントタイプを変更する場合は、次のコマンドを実行します。
$ mount --make-rshared mount_point
使用例は、例19.4「共有マウントポイントの作成」 を参照してください。

例19.4 共有マウントポイントの作成

その他のファイルシステムが一般的にマウントされている場所は、リムーバブルメディアの /media/ ディレクトリーと、ファイルシステムを一時的にマウントされた /mnt/ ディレクトリーという 2 つです。共有マウントを使用して、この 2 つのディレクトリーが同じコンテンツを共有できます。root として、/media/ ディレクトリーを共有 としてマークします。
# mount --bind /media /media
# mount --make-shared /media
以下のコマンドを使用して、/mnt/ 内に複製を作成します。
# mount --bind /media /mnt
これで、/media/ 内のマウントが /mnt/ にも表示されていることを確認できます。たとえば、CD-ROM ドライブに空でないメディアが含まれ、/media/cdrom/ ディレクトリーが存在する場合は、以下のコマンドを実行します。
# mount /dev/cdrom /media/cdrom
# ls /media/cdrom
EFI  GPL  isolinux  LiveOS
# ls /mnt/cdrom
EFI  GPL  isolinux  LiveOS
同様に、/mnt/ ディレクトリーにマウントされているファイルシステムが /media/ に反映されていることを確認できます。たとえば、/dev/sdc1 デバイスを使用する空でない USB フラッシュドライブがプラグインしており、/ mnt/flashdisk/ ディレクトリーが存在する場合は、以下を入力します。
# # mount /dev/sdc1 /mnt/flashdisk
# ls /media/flashdisk
en-US  publican.cfg
# ls /mnt/flashdisk
en-US  publican.cfg
スレーブマウント
スレーブマウントにより、指定したマウントポイントの限定的な複製の作成が可能になります。マウントポイントがスレーブマウントとしてマークされている場合は、元のマウントポイント内のすべてのマウントが複製マウントポイントに反映されますが、スレーブマウント内のマウントは元のポイントに反映されません。マウントポイントのタイプをスレーブマウントに変更するには、シェルプロンプトで以下を入力します。
mount --make-slave mount_point
または、選択したマウントポイントのマウントタイプと、その下のすべてのマウントポイントを変更することもできます。
mount --make-rslave mount_point
使用例は、例19.5「スレーブマウントポイントの作成」 を参照してください。

例19.5 スレーブマウントポイントの作成

この例は、/media/ ディレクトリーのコンテンツが /mnt/ にも表示されるが、/ mnt/ ディレクトリーのマウントは / media/ に反映されないことを示しています。root として、最初に /media/ ディレクトリーを共有としてマークします。
~]# mount --bind /media /media
~]# mount --make-shared /media
次に、/mnt/ に複製を作成しますが、その複製を「slave」としてマークします。
~]# mount --bind /media /mnt
~]# mount --make-slave /mnt
/media/ 内のマウントが /mnt/ にも表示されていることを確認します。たとえば、CD-ROM ドライブに空でないメディアが含まれ、/media/cdrom/ ディレクトリーが存在する場合は、以下のコマンドを実行します。
~]# mount /dev/cdrom /media/cdrom
~]# ls /media/cdrom
EFI  GPL  isolinux  LiveOS
~]# ls /mnt/cdrom
EFI  GPL  isolinux  LiveOS
また、/mnt/ ディレクトリーにマウントされているファイルシステムが / media/ に反映されていないことを確認します。たとえば、/dev/sdc1 デバイスを使用する空でない USB フラッシュドライブがプラグインしており、/ mnt/flashdisk/ ディレクトリーが存在する場合は、以下を入力します。
~]# mount /dev/sdc1 /mnt/flashdisk
~]# ls /media/flashdisk
~]# ls /mnt/flashdisk
en-US  publican.cfg
プライベートマウント
プライベートマウントはデフォルトのマウントタイプで、共有またはスレーブマウントとは異なり、伝播イベントは受信または転送されません。マウントポイントをプライベートマウントとして明示的にマークするには、シェルプロンプトで以下を入力します。
mount --make-private mount_point
または、選択したマウントポイントと、その下のすべてのマウントポイントのマウントタイプを変更できます。
mount --make-rprivate mount_point
使用例は、例19.6「プライベートマウントポイントの作成」 を参照してください。

例19.6 プライベートマウントポイントの作成

例19.4「共有マウントポイントの作成」 のシナリオを考慮して、以下のコマンドで root で以下のコマンドを使用して、共有マウントポイントが作成されていることを前提としています。
~]# mount --bind /media /media
~]# mount --make-shared /media
~]# mount --bind /media /mnt
/mnt/ ディレクトリーをプライベートとしてマークするには、以下を入力します。
~]# mount --make-private /mnt
これで、/media/ 内のマウントのいずれも /mnt/ にも表示されていないことを確認 できるようになりました。たとえば、CD-ROM ドライブに空でないメディアが含まれ、/media/cdrom/ ディレクトリーが存在する場合は、以下のコマンドを実行します。
~]# mount /dev/cdrom /media/cdrom
~]# ls /media/cdrom
EFI  GPL  isolinux  LiveOS
~]# ls /mnt/cdrom
~]#
また、/mnt/ ディレクトリーにマウントされているファイルシステムが /media/ に反映されていないことを確認することもできます。たとえば、/dev/sdc1 デバイスを使用する空でない USB フラッシュドライブがプラグインしており、/ mnt/flashdisk/ ディレクトリーが存在する場合は、以下を入力します。
~]# mount /dev/sdc1 /mnt/flashdisk
~]# ls /media/flashdisk
~]# ls /mnt/flashdisk
en-US  publican.cfg
バインド不可能なマウント
特定のマウントポイントが何度も複製されないようにするために、バインド解除可能なマウントが使用されます。マウントポイントのタイプをバインド不可なマウントに変更するには、シェルプロンプトで以下を入力します。
mount --make-unbindable mount_point
または、選択したマウントポイントと、その下のすべてのマウントポイントのマウントタイプを変更できます。
mount --make-runbindable mount_point
使用例は、例19.7「バインドできないマウントポイントの作成」 を参照してください。

例19.7 バインドできないマウントポイントの作成

/media/ ディレクトリーが root として共有されないようにするには、以下を実行します。
# mount --bind /media /media
# mount --make-unbindable /media
これにより、その後、このマウントの複製を作成しようとすると、エラーが発生して失敗します。
# mount --bind /media /mnt
mount: wrong fs type, bad option, bad superblock on /media,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail  or so

19.2.4. マウントポイントの移動

ファイルシステムがマウントされているディレクトリーを変更するには、以下のコマンドを使用します。
# mount --move old_directory new_directory
使用例は、例19.8「既存の NFS マウントポイントの移動」 を参照してください。

例19.8 既存の NFS マウントポイントの移動

NFS ストレージにはユーザーディレクトリーが含まれ、すでに /mnt/userdirs/ にマウントされます。root で次のコマンドを実行して、このマウントポイントを /home に移動します。
# mount --move /mnt/userdirs /home
マウントポイントが移動したことを確認するには、両方のディレクトリーの内容を一覧表示します。
# ls /mnt/userdirs
# ls /home
jill  joe

19.2.5. rootへの読み取りアクセスのみのパーミッションの設定

場合によっては、root ファイルシステムを読み取り専用パーミッションでマウントする必要があります。ユースケースの例には、システムの予期せぬ電源切断後に行うセキュリティーの向上またはデータ整合性の保持が含まれます。

19.2.5.1. システムの起動時に読み取り専用パーミッションでマウントするように root を設定する

  1. /etc/sysconfig/readonly-root ファイルで、READONLYyes に変更します。
    # Set to 'yes' to mount the file systems as read-only.
    READONLY=yes
    [output truncated]
  2. / etc/fstab ファイルの root エントリー(/)で、デフォルトを ro に変更します
    /dev/mapper/luks-c376919e... / ext4 ro,x-systemd.device-timeout=0 1 1
  3. /etc/default/grub ファイルの GRUB_CMDLINE_LINUX ディレクティブに ro を追加して、rw が含まれていないことを確認します。
    GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet ro"
  4. GRUB2 設定ファイルを再作成します。
    # grub2-mkconfig -o /boot/grub2/grub.cfg
  5. tmpfs ファイルシステムに書き込みパーミッションでマウントするファイルとディレクトリーを追加する必要がある場合は、/etc/rwtab.d/ ディレクトリーにテキストファイルを作成し、そこに設定を置きます。たとえば、/etc/example/file を書き込みパーミッションでマウントするには、以下の行を /etc/rwtab.d/サンプル ファイルに追加します。
    files /etc/example/file
    重要
    tmpfs のファイルおよびディレクトリーに加えた変更は、起動後は持続しません。
  6. システムを再起動します。

19.2.5.2. root の再マウント

システム起動時に root(/)が読み取り専用パーミッションでマウントした場合は、書き込み権限で再マウントできます。
# mount -o remount,rw /
これは、読み取り専用パーミッションで / が不適切にマウントされている場合に特に便利です。
読み取り専用パーミッションで / を再マウントするには、以下を実行します。
# mount -o remount,ro /
注記
このコマンドは、読み取り専用パーミッションで / 全体 をマウントします。より優れた方法は、「システムの起動時に読み取り専用パーミッションでマウントするように root を設定する」 で説明されているように、特定のファイルおよびディレクトリーに対して書き込みパーミッションを保持するには、それらを RAM にコピーして実行できます。

19.2.5.3. 書き込みパーミッションを保持するファイルおよびディレクトリー

システムが正しく機能するためには、一部のファイルやディレクトリーで書き込みパーミッションが必要とされます。root の読み取り専用モードでは、tmpfs 一時ファイルシステムの RAM にマウントされます。そのようなファイルとディレクトリーのデフォルトセットは、/etc/rwtab ファイルから読み取り、以下が含まれます。
dirs	/var/cache/man
dirs	/var/gdm
[output truncated]
empty	/tmp
empty	/var/cache/foomatic
[output truncated]
files	/etc/adjtime
files	/etc/ntp.conf
[output truncated]
/etc/rwtab ファイルのエントリー は、以下の形式に従います。
how the file or directory is copied to tmpfs       	path to the file or directory
ファイルまたはディレクトリーは、以下の 3 つの方法で tmpfs にコピーできます。
  • 空の パス: 空のパスが tmpfs にコピーされます。例: 空の /tmp
  • dirs path: ディレクトリーツリーが空の tmpfs にコピーされます。例: dirs /var/run
  • ファイルパス: ファイルまたはディレクトリーツリーが tmpfs intact にコピーされます。例: files /etc/resolv.conf
カスタムパスを /etc/rwtab.d/ に追加する場合、同じ形式が適用されます。

19.3. ファイルシステムのマウント解除

以前にマウントされたファイルシステムをデタッチするには、umount コマンドの以下のいずれかのバリアントを使用します。
$ umount directory
$ umount device
root としてログイン中にこの設定が実行されない限り、ファイルシステムのマウントを解除するために適切なパーミッションが利用可能である必要があることに注意してください。詳細は、「マウントオプションの指定」 を参照してください。使用例は、例19.9「CD/DVD のアンマウント」 を参照してください。
重要: Directory が使用されていない状態にする
ファイルシステムが使用されている場合(たとえば、プロセスがこのファイルシステムのファイルを読み取る場合や、カーネルがファイルを使用している場合など)、umount コマンドを実行すると、umount コマンドの実行に失敗し、エラーが発生します。ファイルシステムにアクセスするプロセスを確認するには、以下の形式で fuser コマンドを使用します。
$ fuser -m directory
たとえば、/media/cdrom/ ディレクトリーにマウントされたファイルシステムにアクセスするプロセスを一覧表示するには、以下のコマンドを実行します。
$ fuser -m /media/cdrom
/media/cdrom:         1793  2013  2022  2435 10532c 10672c

例19.9 CD/DVD のアンマウント

以前に /media/cdrom/ ディレクトリーにマウントされた CD をアンマウントするには、以下のコマンドを使用します。
$ umount /media/cdrom

19.4. マウント コマンドの参照

以下のリソースは、サブジェクトに関する詳細なドキュメントを提供します。

man ページのドキュメント

  • man 8 mount: mount コマンドの man ページは、その使用方法に関する完全なドキュメントを提供します。
  • man 8 umount: umount コマンドの man ページは、その使用方法に関する完全なドキュメントを提供します。
  • man 8 findmnt: findmnt コマンドの man ページは、その使用方法に関する完全なドキュメントを提供します。
  • man 5 fstab: /etc/fstab ファイル形式に関する詳細な説明を提供する man ページです。

便利な Web サイト

第20章 volume_key 機能

volume_key 関数は、libvolume_key と volume_key の 2 つのツールを提供します。libvolume_key は、ストレージボリュームの暗号化キーを操作し、ボリュームとは別に保存するためのライブラリーです。volume_key は、暗号化したハードドライブへのアクセスを復元するために鍵およびパスフレーズを抽出するために使用される関連するコマンドラインツールです。
これは、プライマリーユーザーが鍵とパスワードを取得するとき、従業員が突然残ったり、ハードウェアまたはソフトウェアの障害の発生後にデータを抽出したり、暗号化されたボリュームのヘッダーが破損する場合に役立ちます。IT の企業設定では、IT ヘルプで volume_key を使用して、コンピューターをエンドユーザーに管理する前に、暗号化キーをバックアップできます。
現在、volume_key は、LUKS ボリュームの暗号化形式のみをサポートします。
注記
volume_key は、Red Hat Enterprise Linux 7 サーバーの標準的なインストールには含まれていません。インストールに関する情報は、を参照してください http://fedoraproject.org/wiki/Disk_encryption_key_escrow_use_cases

20.1. volume_key コマンド

volume_key の形式は、以下のとおりです。
volume_key [OPTION]... OPERAND
volume_key に対する操作におけるオペランドおよびモードは、以下のオプションのいずれかを指定して決定されます。
--save
このコマンドは、オペランド ボリューム [packet] を想定します。パケット が提供されると、volume_key は、そこからキーおよびパスフレーズを抽出します。パケット が指定されていない場合、volume_key はボリュームから キーおよびパスフレーズを抽出し 必要に応じてユーザーに要求します。これらの鍵とパスフレーズは、1 つまたは複数の出力パケットに保存されます。
--restore
このコマンドは、オペランド ボリュームパケット を想定します。次に ボリューム を開き、パケットの 鍵とパスフレーズを使って ボリュームを 再度アクセス可能にし、必要に応じてユーザー(たとえば、ユーザーが新しいパスフレーズの入力を許可するなど)を求めるプロンプトを出します。
--setup-volume
このコマンドは、オペランドの ボリュームパケット名 を想定します。次に ボリューム を開き、パケットの 鍵とパスフレーズを使用して、復号化されたデータを 名前 として使用するための ボリューム を設定します。
name は、dm-crypt ボリュームの名前です。この操作は、復号化されたボリュームを /dev/mapper/ 名として利用可能にします
この操作は、新しいパスフレーズを追加すると ボリュームを 永続的に変更しません(例: )。ユーザーは復号化された ボリューム にアクセスし、変更できます。
--reencrypt、--secrets、および --dump
これらの 3 つのコマンドは、さまざまな出力方法で同様の機能を実行します。それぞれオペランド パケット が必要で、それぞれが パケット を開き、必要に応じて復号化を行います。次に 、--reencrypt は情報を 1 つ以上の新規出力パケットに保存します。--secrets は、パケット に含まれるキーおよびパスフレーズを出力します。--dumpパケット の内容を出力しますが、キーおよびパスフレーズはデフォルトで出力されません。これは、コマンドに --with-secrets を追加することで変更できます。また、--unencrypted コマンドを使用すると、パケットの暗号化されていない部分のみをダンプできます。パスフレーズや秘密鍵のアクセスは必要ありません。
各オプションは、以下のオプションで追加できます。
-o, --output packet
このコマンドは、デフォルトの鍵またはパスフレーズを パケット に書き込みます。デフォルトのキーまたはパスフレーズは、ボリュームの形式により異なります。有効期限が切れないものではなく 、--restore によるボリュームへのアクセスを復元できるようにしてください。
--output-format format
このコマンドは、すべての出力パケットに指定された 形式を使用します。現在、形式 は以下のいずれかになります。
  • 非対称: CMS を使用してパケット全体を暗号化し、証明書を必要とします。
  • asymmetric_wrap_secret_only: シークレットまたはキーおよびパスフレーズのみをラップし、証明書を必要とします。
  • パスフレーズ: GPG を使用してパケット全体を暗号化し、パスフレーズが必要です。
--create-random-passphrase packet
このコマンドは、ランダムの英数字のパスフレーズを生成し、ボリュームに追加して (他のパスフレーズに影響を与えずに)、このランダムパスフレーズを パケット に保存します。

20.2. volume_key を Individual User として使用

個々のユーザーとして、以下の手順に従って、volume_key を使用して暗号化キーを保存できます。
注記
このファイルのすべての例では、/path/to/volume は LUKS デバイスであり、内に含まれる平文デバイスではありません。blkid -s type /path/to/volume should report type="crypto_LUKS".

手順20.1 volume_key Stand-alone の使用

  1. 以下を実行します。
    volume_key --save /path/to/volume -o escrow-packet
    次に、キーを保護するために、パケットパスフレーズの入力を求めるプロンプトが表示されます。
  2. generatedescrow -packet ファイルを保存して、パスフレーズが記憶されないようにします。
ボリュームのパスフレーズが記憶されたら、保存された escrow パケットを使用してデータへのアクセスを復元します。

手順20.2 Escrow Packet を使用したデータへのアクセスの復元

  1. volume_key を実行できる環境でシステムを起動し、エスクローパケットが利用できる(例: レスキューモード)
  2. 以下を実行します。
    volume_key --restore /path/to/volume escrow-packet
    エスクローパケットの作成時に使用された escrow パケットパスフレーズ、およびボリュームの新しいパスフレーズ用にプロンプトが表示されます。
  3. 選択したパスフレーズを使用してボリュームをマウントします。
暗号化されたボリュームの LUKS ヘッダーでパスフレーズスロットを解放するには、cryptsetup luksKillSlot を使用して、以前のパスフレーズを削除します。

20.3. 大規模組織での volume_key の使用

大型の組織では、各システム管理者が認識するパスワード 1 つを使用して、各システムに個別のパスワードを追跡することは難しいため、セキュリティーリスクが伴います。これをカウンターするために、volume_key は非対称暗号を使用して、どのコンピューターで暗号化されたデータへのアクセスに必要なパスワードを知っている人の数を最小限に抑えます。
本セクションでは、暗号化キーの保存、暗号鍵の保存、ボリュームへのアクセスの復元、緊急パスフレーズの設定に必要な手順について説明します。

20.3.1. 暗号化キーをセービングするための準備

暗号化キーの保存を開始するために、準備が必要になります。

手順20.3 準備

  1. X509 証明書/プライベートのペアを作成します。
  2. 秘密鍵を侵害しないように信頼できるユーザーを指定します。これらのユーザーは escrow パケットを復号化できます。
  3. escrow パケットの復号に使用するシステムを選択します。このシステムでは、秘密鍵が含まれる NSS データベースを設定します。
    秘密鍵が NSS データベースに作成されていない場合は、以下の手順に従います。
    • 証明書および秘密鍵を PKCS#12 ファイルに保存します。
    • 以下を実行します。
      certutil -d /the/nss/directory -N
      この時点で、NSS データベースパスワードを選択できます。各 NSS データベースは異なるパスワードを持つことができるため、指定したユーザーは各ユーザーが別の NSS データベースが使用される場合に、単一のパスワードを共有する必要はありません。
    • 以下を実行します。
      pk12util -d /the/nss/directory -i the-pkcs12-file
  4. システムのインストールや既存システムに鍵を保存したり、証明書を配布します。
  5. 保存された秘密鍵については、マシンおよびボリュームで検索できるストレージを準備します。たとえば、マシンごとに 1 つのサブディレクトリーを持つ簡単なディレクトリーや、他のシステム管理タスクに使用されるデータベースも指定できます。

20.3.2. 暗号化鍵の保存

必要な準備が完了した後( 「暗号化キーをセービングするための準備」を参照)、以下の手順に従って暗号化キーを保存することができるようになりました。
注記
このファイルのすべての例では、/path/to/volume は LUKS デバイスであり、これに含まれるプレーンテキストデバイスではありません。blkid -s type /path/to/volumetype="crypto_LUKS" を報告します。

手順20.4 暗号化鍵の保存

  1. 以下を実行します。
    volume_key --save /path/to/volume -c /path/to/cert escrow-packet
  2. 準備済みストレージに generatedescrow -packet ファイルを保存して、システムとボリュームに関連付けます。
この手順は手動で実行することも、システムのインストールの一部としてスクリプト化したりできます。

20.3.3. ボリュームへのアクセスの復元

暗号化キーの保存後( 「暗号化キーをセービングするための準備」 および 「暗号化鍵の保存」)は、必要に応じてドライバーへのアクセスを復元できます。

手順20.5 ボリュームへのアクセスの復元

  1. パケットストレージからボリュームのエスクローパケットを取得し、これを復号化用に指定されたユーザーの 1 つに送信します。
  2. 指定されたユーザーは以下を実行します。
    volume_key --reencrypt -d /the/nss/directory escrow-packet-in -o escrow-packet-out
    NSS データベースのパスワードを指定したら、指定したユーザーは、暗号化用のパスフレーズを選択して、escrow -packet-out です。このパスフレーズは毎回異なる可能性があり、指定したユーザーからターゲットシステムに移動された間、暗号鍵を保護することができます。
  3. 指定したユーザーから、escrow-packet-out ファイルとパスフレーズを取得します。
  4. volume_key を実行し、レスキューモードなどでescrow -packet-out ファイルを利用できる環境でターゲットシステムを起動します。
  5. 以下を実行します。
    volume_key --restore /path/to/volume escrow-packet-out
    指定されたユーザーが選択したパケットパスフレーズ、およびボリュームの新しいパスフレーズを求めるプロンプトが表示されます。
  6. 選択したボリュームパスフレーズを使用してボリュームをマウントします。
cryptsetup luksKillSlot を使用して記憶されている古いパスフレーズを削除することも可能です。たとえば、暗号化されたボリュームの LUKS ヘッダーでパスフレーズスロットを解放することができます。これは、コマンド cryptsetup luksKillSlot デバイス key-slot コマンドで行います。詳細および例については、cryptsetup --help を参照してください。

20.3.4. 緊急パスフレーズの設定

(ビジネスの移動など)場合によっては、システム管理者が影響を受けるシステムと直接動作させるのが難しい場合がありますが、ユーザーは引き続きそのデータにアクセスする必要があります。この場合、volume_key は、パスフレーズと暗号鍵と連携できます。
システムのインストール時に、以下を実行します。
volume_key --save /path/to/volume -c /path/to/ert --create-random-passphrase passphrase-packet
これにより、ランダムのパスフレーズが生成され、指定したボリュームに追加され、そのパスフレーズが passphrase-packet に保存されます--create-random-passphrase-o オプションを組み合わせて両方のパケットを同時に生成することもできます。
パスワードを忘れると、指定したユーザーは以下を実行します。
volume_key --secrets -d /your/nss/directory passphrase-packet
これにより、ランダムのパスフレーズが表示されます。このパスフレーズをエンドユーザーに付与します。

20.4. volume_key 参照 s

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

第21章 ソリッドステートディスクデプロイメントのガイドライン

ソリッドステートディスク (SSD)は、データを永続的に保存するために NAND フラッシュチップを使用するストレージデバイスです。これにより、ローテーション、ミッチ、ビッターにデータを保存する以前のディスクの生成とは別に設定されます。SSD では、完全な論理ブロックアドレス(LBA)範囲におけるデータのアクセス時間は定数です。ただし、ローテートメディアを使用する古いディスクでは、大型のアドレス範囲を通るシークコストが及ぶアクセスパターンです。そのため、SSD デバイスのレイテンシーとスループットは向上します。
使用されるブロック数は、ディスク容量に近づけるため、パフォーマンスが低下します。パフォーマンスへの影響度は、ベンダーによって大きく異なります。ただし、すべてのデバイスでパフォーマンスが低下する可能性があります。
パフォーマンスの低下に対処するために、ホストシステム(Linux カーネルなど)は破棄要求を使用して、特定のブロックが使用されていないことをストレージに通知します。SSD はこの情報を使用して、対象レベルに空きブロックを使用して、内部で領域を解放できます。破棄は、ストレージプロトコル(ATA または SCSI 経由)でストレージサポートを公開する場合にのみ発行されます。破棄要求は、ストレージプロトコル固有の negotiated discard コマンドを使用してストレージに発行されます(ATA の場合はTRIM コマンド、および UNMAP セットでの WRITE SAME、SCSI 用の UNMAP コマンド)。
破棄 サポートの有効化は、次のポイントが true の場合に最も便利です。
  • ファイルシステムで空き領域が利用できる。
  • 基礎となるストレージデバイスの論理ブロックの多くは、すでに書き込まれています。
TRIM の詳細は、「Data Set Management T13 Specifications」を参照してください。
UNMAP の詳細は、「SCSI Block Commands 3 T10 Specification」のセクション 4.7.3.4 を参照してください。
注記
市場のすべてのソリッドステートデバイスが、破棄 サポートを持つわけではありません。ソリッドステートデバイスが破棄されたかどうかを判断するには /sys/block/sda/queue/discard_granularity (デバイスの内部割り当てユニットのサイズ)を確認します。

デプロイメントに関する考慮事項

SSD の内部レイアウトと操作により、内部 消去ブロック境界 のパーティション作成が最適です。Red Hat Enterprise Linux 7 でパーティショニングユーティリティーが、SSD トポロジー情報をエクスポートする場合は、デフォルトの sane を選択します。ただし、デバイスがトポロジー情報をエクスポートし ない場合は、最初のパーティションを 1MB の境界に作成することを推奨します。
SSD には、ベンダーの選択に応じてさまざまなタイプの TRIM メカニズムがあります。初期のバージョンのディスクでは、read コマンドの後に潜在的なデータ漏えいの可能性を侵害することで、パフォーマンスが向上しました。
以下は、TRIM メカニズムのタイプです。
  • 非決定的 TRIM
  • 決定 論的 TRIM (DRAT)
  • TRIM (RZAT)後の決定論的読み取りゼロ
最初の 2 つのタイプの TRIM メカニズムでは、TRIM が異なる データを返すと、read コマンドから LBA にデータリークが発生する可能性があります。RZAT は、read コマンドの後にゼロを返し、Red Hat は、データの漏えいを回避するために、この TRIM メカニズムを推奨します。これは SSD でのみ影響を受けます。RZAT メカニズムをサポートするディスクを選択します。
使用される TRIM メカニズムのタイプは、ハードウェア実装によって異なります。ATA で TRIM メカニズムのタイプを見つけるには、h dparm コマンドを使用します。TRIM メカニズムのタイプを確認するには、以下の例を参照してください。
# hdparm -I /dev/sda | grep TRIM
Data Set Management TRIM supported (limit 8 block)
Deterministic read data after TRIM
詳細は、man hdparm を参照してください。
論理ボリュームマネージャー(LVM)、device-mapper(DM)ターゲット、および LVM が破棄をサポートしている MD(software raid)ターゲット。破棄をサポートしない唯一の DM ターゲットは、dm-snapshot、dm-crypt、および dm-raid45 です。Red Hat Enterprise Linux 6.1 に dm-mirror への対応が破棄され、7.0 MD は破棄をサポートします。
SSD で RAID レベル 5 を使用すると、SSD が 破棄 を正しく処理しない場合、パフォーマンスが低下します。raid456.conf ファイル、または GRUB2 設定で破棄を設定できます。手順は、以下の手順を参照してください。

手順21.1 raid456.conf で discard の設定

devices_handle_discard_safely モジュールパラメーターは、raid456 モジュールで設定されます。raid456.conf ファイルで破棄を有効にするには、次のコマンドを実行します。
  1. ハードウェアが破棄をサポートしていることを確認します。
    # cat /sys/block/disk-name/queue/discard_zeroes_data
    返された値が 1 の場合、破棄がサポートされます。コマンドが 0 を返す場合は、RAID コードはディスク 0 になる必要があり、これには時間がかかります。
  2. /etc/modprobe.d/raid456.conf ファイルを作成し、以下の行を追加します。
    options raid456 devices_handle_discard_safely=Y
    
  3. dracut -f コマンドを使用して、初期 ramdisk(initrd)を再構築します。
  4. システムを再起動して、変更を有効にします。

手順21.2 GRUB2 設定での破棄の設定

devices_handle_discard_safely モジュールパラメーターは、raid456 モジュールで設定されます。GRUB2 設定で破棄を有効にするには、以下を行います。
  1. ハードウェアが破棄をサポートしていることを確認します。
    # cat /sys/block/disk-name/queue/discard_zeroes_data
    返された値が 1 の場合、破棄がサポートされます。コマンドが 0 を返す場合は、RAID コードはディスク 0 になる必要があり、これには時間がかかります。
  2. 以下の行を /etc/default/grub ファイルに追加します。
    raid456.devices_handle_discard_safely=Y
    
  3. GRUB2 設定ファイルの場所は、BIOS ファームウェアおよび UEFI があるシステムで異なります。以下のコマンドの 1 つを使用して、GRUB2 設定ファイルを再作成します。
    • BIOS ファームウェアを使用している場合は、以下のコマンドを使用します。
      # grub2-mkconfig -o /boot/grub2/grub.cfg
    • UEFI ファームウェアを使用している場合は、以下のコマンドを使用します。
      # grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
  4. システムを再起動して、変更を有効にします。
注記
Red Hat Enterprise Linux 7 では、ext4 ファイルシステムおよび XFS ファイルシステムでのみ、破棄に対応しています。
Red Hat Enterprise Linux 6.3 以前では、ext4 ファイルシステムのみが破棄を完全にサポートします。Red Hat Enterprise Linux 6.4 以降、ext4 ファイルシステムと XFS ファイルシステムの両方が、破棄を完全にサポートします。デバイスで discard コマンドを有効にするには、mount コマンドの discard オプションを使用します。たとえば、discard を有効にして /dev/sda2/mnt にマウントするには、以下を使用します。
# mount -t ext4 -o discard /dev/sda2 /mnt
デフォルトでは、ext4 は discard コマンドを発 揮せず、主に破棄が適切に実装されない可能性があるデバイスの問題を回避します。Linux swap コードは discard コマンドを発行して、有効なデバイスを破棄し、この動作を制御するオプションはありません。

パフォーマンスチューニングに関する留意事項

ソリッドステートディスクに関するパフォーマンスチューニングの考慮事項は、『Red 『Hat Enterprise Linux 7 パフォーマンスチューニングガイド』の「 Solid-State ディスク 」セクションを参照してください』。

第22章 書き込みバリア

書き込みバリア は、揮発性書き込みキャッシュのあるストレージデバイスが電源を失った場合でも、ファイルシステムのメタデータが正しく書き込まれ、永続ストレージに順序付けられます。書き込みバリアが有効にされたファイルシステムは、fsync()を介して送信されるデータ が電源損失時に永続的になるようにします。
書き込みバリアを有効にすると、一部のアプリケーションにパフォーマンスが大幅に低下します。具体的には、fsync() を大きく使用したり、小規模なファイルを作成したり、削除したりするアプリケーションは、非常に遅くなる可能性があります。

22.1. Write Barriers の重要性

ファイルシステムはメタデータを安全に更新して、一貫性を確保します。ジャーナル化されたファイルシステムバンドルメタデータがトランザクションに更新され、以下の方法で永続ストレージに送信します。
  1. ファイルシステムは、トランザクションの本文をストレージデバイスに送信します。
  2. ファイルシステムはコミットブロックを送信します。
  3. トランザクションと対応するコミットブロックがディスクに書き込まれると、ファイルシステムは、トランザクションが power failure 後も存続することを想定します。
ただし、電源の失敗時のファイルシステムの整合性は、追加のキャッシュを持つストレージデバイスの複雑になります。ローカルの S-ATA や SAS ドライブなどのストレージターゲットデバイスは、サイズが 32MB から 64MB(最新のドライブで)書き込みキャッシュを持つ可能性があります。ハードウェア RAID コントローラーには、多くの場合、内部書き込みキャッシュが含まれます。さらに、NetApp、IBM、Hitachi、EMC(その他)には大きなキャッシュがあります。
キャッシュに格納されると、データの書き込みキャッシュ I/O が「complete」として報告します。キャッシュが機能しなくなった場合は、データも失われます。キャッシュデステージから永続ストレージへのキャッシュのデメンテーションであるため、元のメタデータの順番が変わる可能性があります。これが発生すると、完全なトランザクションに関連するトランザクションがなくてもコミットブロックがディスクに存在する可能性があります。これにより、ジャーナルは、初期化されていないトランザクションブロックを非初期化されたトランザクションブロックをファイルシステムに再生できます。これにより、データの不整合や破損が発生します。

Write Barriers の仕組み

書き込みバリアは、I/O の前後にストレージ書き込みキャッシュのフラッシュにより Linux カーネルで実装されます( 順番は重要 )。トランザクションが書き込まれると、ストレージキャッシュがフラッシュされ、コミットブロックが書き込まれ、キャッシュは再度フラッシュされます。これにより、以下が確保されます。
  • ディスクにはすべてのデータが含まれます。
  • 順序の並べ替えは発生していません。
バリアが有効になると、fsync() 呼び出しでストレージキャッシュのフラッシュも発行されます。これにより、fsync() が返された直後に電源損失が発生した場合でも、ファイルデータがディスク上の永続化されるようになります。

22.2. Write Barriers の有効化と無効化

電源の損失時にデータ破損のリスクを軽減するには、ストレージデバイスの中には、バッテリーでバックアップされた書き込みキャッシュを使用します。通常、ハイエンドアレイや一部のハードウェアコントローラーはバッテリーベースの書き込みキャッシュを使用します。ただし、キャッシュのボランティはカーネルには表示されません。したがって、Red Hat Enterprise Linux 7 は、サポートされているすべてのジャーナルファイルシステムで、デフォルトで書き込みバリアを有効にします。
注記
書き込みキャッシュは、I/O パフォーマンスを向上させるように設計されています。ただし、書き込みバリアを有効にすると、これらのキャッシュを常にフラッシュします。そのため、パフォーマンスが大幅に低下する可能性があります。
不揮発性なデバイスと、バッテリーでバックアップされた書き込みキャッシュと、write-caching が無効になっているデバイスの場合、マウントに -o nobarrier オプションを使用して、マウント時の書き込みバリアを安全に無効にできます ただし、一部のデバイスは書き込みバリアに対応していません。このようなデバイスは、エラーメッセージを /var/log/messages に記録します。詳細は、表22.1「ファイルシステムごとの Barrier エラーメッセージの作成」 を参照してください。

表22.1 ファイルシステムごとの Barrier エラーメッセージの作成

ファイルシステムエラーメッセージ
ext3/ext4JBD: barrier-based sync failed on device - disabling barriers
XFSFilesystem device - Disabling barriers, trial barrier write failed
btrfsbtrfs: disabling barriers on dev device

22.3. アバージーの作成に関する留意事項

一部のシステム設定では、データを保護する書き込みバリアは必要ありません。ほとんどの場合、書き込みバリアを有効にすると、パフォーマンスが大幅に向上するため、その他の方法がバリアを書くことが推奨されます。

書き込みキャッシュの無効化

また、データの整合性の問題を回避する 1 つの方法は、書き込みキャッシュが power failures 時にデータを損失しないようにすることです。これを設定する最善の方法は、書き込みキャッシュを無効にすることです。1 つ以上の SATA ドライブ(ローカルの SATA コントローラー Intel AHCI の一部をオフ)を使用する簡単なサーバーまたはデスクトップでは、以下のコマンドで、ターゲット SATA ドライブで書き込みキャッシュを無効にすることができます。
# hdparm -W0 /device/

バッテリーバックグラウンド書き込みキャッシュ

また、システムがバッテリーベースの書き込みキャッシュを持つハードウェア RAID コントローラーを使用する場合は、書き込みバリアも不要になります。システムがこのようなコントローラーで備えられ、そのコンポーネントドライブで書き込みキャッシュが無効になっている場合は、コントローラーは write-through キャッシュとして機能します。これにより、書き込みキャッシュデータが電源損失後も持続するカーネルが表示されます。
ほとんどのコントローラーはベンダー固有のツールを使用して、ターゲットドライブをクエリーし、操作します。たとえば、LSI Megaraid SAS コントローラーはバッテリーベースの書き込みキャッシュを使用します。このタイプのコントローラーは、ターゲットドライブを管理するために MegaCli64 ツールを必要とします。LSI Megaraid SAS 用のすべてのバックエンドドライブの状態を表示するには、以下のコマンドを使用します。
# MegaCli64 -LDGetProp -DskCache -LAll -aALL
LSI Megaraid SAS 用のすべてのバックエンドドライブの書き込みキャッシュを無効にするには、以下のコマンドを使用します。
# MegaCli64 -LDSetProp -DisDskCache -Lall -aALL
注記
ハードウェア RAID カードは、システムが稼働中にバッテリーを再課金します。システムの電源が長期間オフになっている場合、バッテリーはその課金を失い、電源異常中に脆弱なデータを残します。

high-End Arrays

ハイエンドアレイは、電源障害時にデータを保護するさまざまな方法を提供します。そのため、外部 RAID ストレージで内部ドライブの状態を確認する必要はありません。

NFS

NFS クライアントでは、データの整合性が NFS サーバー側によって処理されるため、書き込みバリアを有効にする必要はありません。そのため、(書き込みバリアやその他の手段を介して)電源損失全体でデータの永続性を保証するように NFS サーバーを設定する必要があります。

第23章 ストレージ I/O アライメントとサイズ

SCSI および ATA 規格に対する最近の機能拡張により、ストレージデバイスが優先される(必要な場合は必須)の I/O 調整 I/O サイズ を示すことができます。この情報は、物理セクターサイズを 512 バイトから 4k バイトに増やす新しいディスクドライブで特に便利です。この情報は、RAID デバイスにも利点があります。この場合、チャンクサイズとストライプサイズがパフォーマンスに影響を及ぼす可能性があります。
Linux I/O スタックが強化され、ベンダー提供の I/O 調整と I/O サイズ情報を処理し、ストレージ管理ツール(partedlvmmkfs など)を処理し データの配置とアクセスを最適化できるようになりました。レガシーデバイスが I/O 調整データおよびサイズデータをエクスポートしない場合、Red Hat Enterprise Linux 7 のストレージ管理ツールは、4k(またはより大きな電源)の境界に集中します。これにより、必要な I/O 調整およびサイズを指定しなくても、4k-sector デバイスが正しく動作できるようになります。
デバイスから取得したオペレーティングシステムの情報を判断する方法は、「ユーザー空間アクセス」 を参照してください。このデータは、データの配置を決定するためにストレージ管理ツールによって使用されます。
Red Hat Enterprise Linux 7 の IO スケジューラーが変更されました。デフォルトの IO スケジューラーは Deadline (SATA ドライブを除く)になりました。CFQ は、SATA ドライブのデフォルト IO スケジューラーです。ストレージの速度を短縮するために、Deadline outperforms CFQ の使用時には、特別なチューニングなしにパフォーマンスが向上されます。
デフォルトが一部のディスク(SAS ローテーションディスクなど)に適切な場合は、IO スケジューラーを CFQ に変更します。このインスタンスはワークロードによって異なります。

23.1. ストレージアクセスのパラメーター

オペレーティングシステムは以下の情報を使用して、I/O 調整とサイズを決定します。
physical_block_size
デバイスが操作できる最小の内部単位。
logical_block_size
デバイスの場所を外部にアドレスするために使用します。
alignment_offset
Linux ブロックデバイスの開始(パーティション/MD/LVM デバイス)が下層の物理アライメントからのオフセットとなるバイト数
minimum_io_size
無作為な I/O に、デバイスの推奨最小単位
optimal_io_size
I/O ストリーミングにデバイスの優先単位
たとえば、特定の 4K セクターデバイスは、内部的に 4K physical_block_size を使用し、より粒度の 512 バイトの logical_block_size を Linux に公開します。この不一致により、不適切な I/O の可能性が発生します。これに対処するために、Red Hat Enterprise Linux 7の I/O スタックは、ブロックデバイスの開始点が基礎となる物理アライドからのオフセットである場合に alignment_offset の領域をすべて起動しようとします。
ストレージベンダーは、デバイスのランダム I/O(minimum _io_size)およびストリーミング I/O(optimal_io_size)に推奨される最小単位についての I/O ヒントを指定することもできます。たとえば、min _io_size および optimal_io_size は、それぞれ RAID デバイスのチャンクサイズとストライプのサイズに対応する場合があります。

23.2. ユーザー空間アクセス

常に適切に調整された I/O を使用し、サイズ付けされた I/O を使用するようにしてください。これは、ダイレクト I/O アクセスに特に重要です。ダイレクト I/O は logical_block_size の境界で調整する必要があり、また logical_block_size の倍数に調整する必要があります
ネイティブ 4K デバイス(つまり logical_block_size が 4K)の場合、アプリケーションはデバイスの logical_block_size の倍数に対してダイレクト I/O を実行することが重要になります。つまり、アプリケーションは 4k-aligned I/O ではなく、512 バイトのアラインメント I/O を実行するネイティブの 4k デバイスで失敗します。
これを回避するには、適切な I/O 調整とサイズを使用するように、アプリケーションはデバイスの I/O パラメーターを参照してください。上記のように、I/O パラメーターは sysfs インターフェースおよびブロックデバイス ioctl インターフェースの両方で公開されます。
詳細は、man libblkid を参照してください。この man ページは、lib blkid-devel パッケージで提供されます。

sysfs インターフェース

  • /sys/block/disk/alignment_offset
    または
    /sys/block/disk/partition/alignment_offset
    注記
    ファイルの場所は、ディスクが物理ディスク(ローカルディスク、ローカル RAID、またはマルチパスの LUN)か、仮想ディスクであるかによって異なります。最初のファイルの場所は物理ディスクに適用され、2 番目のファイルの場所は仮想ディスクに適用されます。なぜなら、virtio-blk はパーティションの調整値を常に報告するためです。物理ディスクは、調整値を報告することができるか、または報告しないことがあります。
  • /sys/block/disk/queue/physical_block_size
  • /sys/block/disk/queue/logical_block_size
  • /sys/block/disk/queue/minimum_io_size
  • /sys/block/disk/queue/optimal_io_size
カーネルは、I/O パラメーター情報を提供しない「レガシー」デバイスの sysfs 属性をエクスポートします。以下に例を示します。

例23.1 sysfs インターフェース

alignment_offset:    0
physical_block_size: 512
logical_block_size:  512
minimum_io_size:     512
optimal_io_size:     0

ブロックデバイス ioctls

  • BLKALIGNOFF: alignment_offset
  • BLKPBSZGET: physical_block_size
  • BLKSSZGET: logical_block_size
  • BLKIOMIN: minimum_io_size
  • BLKIOOPT: optimal_io_size

23.3. I/O 標準

本セクションでは、ATA デバイスおよび SCSI デバイスが使用する I/O 標準を説明します。

ATA

ATA デバイスは、IDENTIFY DEVICE コマンドで適切な情報を報告する必要があります。ATA デバイスは、physical_block_size、logical_block_size、および alignment_ offset の I/O パラメーターだけを報告します。追加の I/O ヒントは、ATA コマンドセットの範囲外にあります。

SCSI

Red Hat Enterprise Linux 7 で利用できる I/O パラメーターには、少なくとも SCSI Primary Commands (SPC-3) プロトコルのバージョン 3 が必要です。カーネルは、SPC-3 に準拠しを要求するデバイスに対して、拡張された inquiryBLOCK LIMITS VPD ページへのアクセスを取得する)および READ CAPACITY(16) コマンドのみを送信します。
READ CAPACITY(16) コマンドは、ブロックサイズと調整オフセットを提供します。
  • LOGICAL BLOCK LENGTH IN BYTES /sys/block/disk/queue/physical_block_sizeを派生するのに使用されます。
  • LOGICAL BLOCKS PER PHYSICAL BLOCK EXPONENT /sys/block/disk/queue/logical_block_sizeを派生するために使用されます。
  • LOWEST ALIGNED LOGICAL BLOCK ADDRESS 派生するのに使用されます。
    • /sys/block/disk/alignment_offset
    • /sys/block/disk/partition/alignment_offset
BLOCK LIMITS VPD ページ(0xb0)は、I/O ヒントを提供します。また、OPTIMAL TRANSFER LENGTH GRANULARITY および OPTIMAL TRANSFER LENGTH を使用して以下の派生します。
  • /sys/block/disk/queue/minimum_io_size
  • /sys/block/disk/queue/optimal_io_size
sg3_utils パッケージは、sg_inq ユーティリティーを提供します。これは、BLOCK LIMITS VPD ページにアクセスできます。これを行うには、以下を実行します。
# sg_inq -p 0xb0 disk

23.4. スタッキング I/O パラメーター

Linux I/O スタックのすべてのレイヤーがエンジンで、さまざまな I/O パラメーターをスタックに伝播します。レイヤーが属性を消費するか、多くのデバイスを集約すると、レイヤー層デバイスまたはツールが変換されるストレージの正確なビューを持つように、レイヤーは適切な I/O パラメーターを公開する必要があります。実用的な例は以下のとおりです。
  • I/O スタックにおける 1 つのレイヤーのみがゼロでない alignment_offset に対して調整する必要があります。レイヤーが調整されると、そのレイヤーがゼロの alignment_offset を持つデバイスをエクスポートします。
  • LVM で作成したストライプ化デバイスマッパー(DM)デバイスは、ストライプ数(ディスクの数) とユーザーが指定するチャンクサイズとの対比で、minimum _io _size と optimal _io_size をエクスポートする必要があります。
Red Hat Enterprise Linux 7 では、デバイスマッパーと Software Raid(MD)デバイスドライバーを使用して、デバイスと、異なる I/O パラメーターとデバイスを統合することができます。カーネルのブロック層は、個々のデバイスの I/O パラメーターを合理的に組み合わせます。カーネルは異種デバイスを組み合わせることはできませんが、実行に関連するリスクに注意してください。
たとえば、512 バイトのデバイスと 4K デバイスが 1 つの論理 DM デバイスに統合され、これにより logical_block_size が 4K になります。このようなハイブリッドデバイスでファイルシステムを重ねるのは、4K がアトミックに書き込まれていると仮定しますが、実際には 512 バイトデバイスに発行すると 8 つの論理ブロックアドレスにまたがることになります。より高いレベルの DM デバイスに 4K logical_block_size を使用すると、システムクラッシュがある場合、512 バイトデバイスへの部分的な書き込みが可能になります。
複数デバイスの I/O パラメーターを組み合わせると競合が生じると、ブロック層は、デバイスが部分的な書き込みの影響を受けたり、もしくはアグリーメントされていることに気付くという警告が表示される場合があります。

23.5. 論理ボリュームマネージャー

LVM は、カーネルの DM デバイスを管理するのに使用するユーザー空間ツールを提供します。LVM は、(指定の DM デバイスが使用するデータ領域の開始)を移動して、LVM が管理するデバイスに関連付けられたゼロ以外の alignment_offset に対応します。これは、論理ボリュームが正しく調整されることを意味します(alignment_offset=0)
デフォルトでは、LVM は alignment_offset に合わせて調整しますが、この動作を無効にするには、/etc/lvm/lvm.conf0data_alignment_offset_detection を設定します。これを無効にすることは推奨していません。
LVM は、デバイスの I/O ヒントも検出します。デバイスのデータ領域の開始は、sysfs に公開される minimum_io_size または optimal_io_size の倍数になります。optimal _io_size が定義されていない場合(例: 0)、LVM は minimum _io_size を使用します。
デフォルトでは、LVM は自動的にこれらの I/O ヒントを決定しますが、この動作を無効にするには、/ etc/lvm/lvm.confdata_alignment_detection0 に設定します。これを無効にすることは推奨していません。

23.6. パーティションおよびファイルシステムツール

このセクションでは、さまざまなパーティションおよびファイルシステム管理ツールがデバイスの I/O パラメーターと対話する方法を説明します。

util-linux-ng の libblkid および fdisk

util-linux-ng パッケージで提供される libblkid ライブラリーには、デバイスの I/O パラメーターにアクセスするためのプログラムによる API が含まれます。libblkid は、特に Direct I/O を使用するアプリケーションを使用して、I/O リクエストを適切にサイズできるようにします。util-linux-ngfdisk ユーティリティーは、libblkid を使用して、すべてのパーティションの配置を最適なデバイスの I/O パラメーターを決定します。fdisk ユーティリティーは、すべてのパーティションを 1MB 境界に合わせます。

parted および libparted

partedlibparted ライブラリーは、lib blkid の I/O パラメーター API も使用します。Red Hat Enterprise Linux 7 インストーラーである Anacondalibparted を使用します。つまり、インストーラーまたは parted のいずれかで作成されたすべてのパーティションが適切に調整されます。I/O パラメーターを提供していないデバイスで作成されたすべてのパーティションに対して、デフォルトの調整は 1MB になります。
ヒューリスティック parted が使用する機能は以下のとおりです。
  • 常に、最初のプライマリーパーティションの開始のオフセットとして、報告された alignment_offset を使用します。
  • optimal_io_size が定義されている場合(例: 0ではない)、すべてのパーティションを optimal_io_size 境界に合わせます。
  • optimal_io_size が未定義である場合(例: 0)、recon se _offset0 で、min_io_size は 2 の累乗の場合は、1MB のデフォルトの調整を使用します。
    これは、I/O ヒントを提供するように見えない「レガシー」デバイスの catch-all です。そのため、デフォルトではすべてのパーティションが 1MB の境界に調整されます。
    注記
    Red Hat Enterprise Linux 7 は、I/O ヒントを提供していないデバイスと、reconct _offset=0 と optimal_io_size=0 を持つデバイスを区別することができません。このようなデバイスは、SAS 4K デバイスに 1 つある可能性があります。したがって、ディスクの起動時に最も悪い 1 MB の領域が失われます。

ファイルシステムツール

異なる mkfs.filesystem ユーティリティーが強化され、デバイスの I/O パラメーターが使用されるようになりました。このユーティリティーを使用すると、ファイルシステムをフォーマットして、基になるストレージデバイスの logical_block_size よりも大きなブロックサイズを使用することができません。
mkfs.gfs2 を除き、他のすべての mkfs.ファイルシステム ユーティリティーは、I/O ヒントを使用して、ディスク上のデータ構造と、下層のストレージデバイスの minimum_io_sizeoptimal_io_size に関連するデータ領域のレイアウトも使用します。これにより、ファイルシステムをさまざまな RAID(ストライプ)レイアウトに対して最適にフォーマットできます。

第24章 リモートディスクレスシステムの設定

PXE 経由でブートする基本的なリモートディスクレスシステムを設定するには、以下のパッケージが必要です。
  • tftp-server
  • xinetd
  • dhcp
  • syslinux
  • dracut-network
    注記
    dracut-network パッケージをインストールしたら、以下の行を /etc/dracut.conf に追加します。
    add_dracutmodules+="nfs"
リモートディスクレスシステムの起動には、tftp サービス(tftp -serverが提供)と DHCP サービス(dhcp が提供)の両方が必要です tftp サービスは、PXE ローダーを介してネットワーク経由でカーネルイメージと initrd を取得するために使用されます。
注記
SELinux は、NFSv4.2 でのみサポートされます。SELinux を使用するには、/etc/sysconfig/nfs で行を追加して NFS を明示的に有効にする必要があります。
RPCNFSDARGS="-V 4.2"
次に、/var/lib/tftpboot/pxelinux.cfg/default で、root=nfs:server-ip:/exported/root/directoryroot=nfs:server-ip:/exported/root/directory,vers=4.2 に変更します。
最後に、NFS サーバーを再起動します。
次のセクションでは、ネットワーク環境にリモートディスクレスシステムをデプロイするのに必要な手順の概要を説明します。
重要
一部の RPM パッケージは、ファイル機能( setcap、getcap など を使用して開始しました。ただし、現在 NFS ではこれらの機能に対応していないため、ファイル機能を使用するパッケージのインストールまたは更新に失敗します。

24.1. ディスクレスクライアントの tftp サービスの設定

前提条件

手順

tftp を設定するには、以下の手順を実行します。

手順24.1 tftpを設定するには、以下を行います。

  1. ネットワーク上での PXE ブートを有効にします。
    # systemctl enable --now tftp
  2. tftp root ディレクトリー(chroot)は /var/lib/tftpboot にあります。/usr/share/syslinux/pxelinux.0/var/lib/tftpboot/ にコピーします。
    # cp /usr/share/syslinux/pxelinux.0 /var/lib/tftpboot/
  3. tftp の root ディレクトリーに pxelinux.cfg ディレクトリーを作成します。
    # mkdir -p /var/lib/tftpboot/pxelinux.cfg/
  4. tftp トラフィックを許可するようにファイアウォールルールを設定します。
    tftp は TCP ラッパーをサポートするため、/etc/hosts.allow 設定ファイルで tftp へのホストアクセスを設定できます。TCP ラッパーおよび /etc/hosts.allow 設定ファイルの設定に関する詳細は、『Red Hat Enterprise Linux 7 セキュリティーガイド』を参照してください。hosts_access(5) は、/etc/hosts.allow に関する情報も提供します。

次のステップ

ディスクレスクライアントの tftp を設定した後に、DHCP、NFS、エクスポートしたファイルシステムを適宜設定します。DHCP、NFS、およびエクスポートしたファイルシステムの設定方法は、「ディスクレスクライアントの DHCP の設定」 および 「ディスクレスクライアントのエクスポート済みファイルシステムの設定」 を参照してください。

24.2. ディスクレスクライアントの DHCP の設定

前提条件

手順

  1. tftp サーバーを設定したら、同じホストマシンに DHCP サービスを設定する必要があります。DHCP サーバーの設定に関する説明は、「DHCP サーバーの設定 」を参照してください。
  2. 以下の設定を /etc/dhcp/dhcpd.conf に追加して、DHCP サーバーで PXE ブートを有効にします。
    allow booting;
    allow bootp;
    class "pxeclients" {
       match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
       next-server server-ip;
       filename "pxelinux.0";
    }
    • server-ip を、tftp サービスおよび DHCP サービスが置かれているホストマシンの IP アドレスに置き換えます。
    注記
    libvirt 仮想マシンがディスクレスクライアントとして使用される場合、libvirt は DHCP サービスを提供し、スタンドアロンの DHCP サーバーは使用されません。このような場合は、libvirt ネットワーク設定 virsh net-editbootp file='filename' オプションを使用してネットワークブートを有効にする必要があります。

次のステップ

tftp および DHCP が設定されているので、NFS およびエクスポートしたファイルシステムを設定します。手順については、「ディスクレスクライアントのエクスポート済みファイルシステムの設定」 を参照してください。

24.3. ディスクレスクライアントのエクスポート済みファイルシステムの設定

前提条件

手順

  1. エクスポートしたファイルシステムのルートディレクトリー (ネットワーク上のディスクレスクライアントが使用) は、NFS 経由で共有されます。/etc/exports に root ディレクトリーを追加して、root ディレクトリーをエクスポートするように NFS サービスを設定します。その手順は、/etc/exports 設定ファイル」 を参照してください。
  2. ディスクレスクライアントに完全に対応できるようにするには、root ディレクトリーには Red Hat Enterprise Linux の完全なインストールが含まれている必要があります。既存のインストールのクローンを作成するか、新しいベースシステムをインストールできます。
    • 実行中のシステムで同期するには、rsync ユーティリティーを使用します。
      # rsync -a -e ssh --exclude='/proc/*' --exclude='/sys/*' \
             hostname.com:/exported-root-directory
      • hostname.com を、rsync を介して同期する実行中のシステムのホスト名に置き換えます。
      • exported-root-directory を、エクスポートしたファイルシステムへのパスに置き換えます。
    • Red Hat Enterprise Linux をエクスポートした場所にインストールするには 、--installroot オプションを指定して yum ユーティリティーを使用します。
      # yum install @Base kernel dracut-network nfs-utils \
            --installroot=exported-root-directory --releasever=/
      
エクスポートするファイルシステムは、ディスクレスクライアントが使用できるようにする前に追加で設定する必要があります。空き領域が足りない場合は、次の手順を実行します。

手順24.2 ファイルシステムの設定

  1. ディスクレスクライアントが使用するカーネル(vmlinuz-kernel-version)を選択し、tftp の boot ディレクトリーにコピーします。
    # cp /boot/vmlinuz-kernel-version /var/lib/tftpboot/
  2. NFS サポートで initrd (つまり initramfs-kernel-version.img)を作成します。
    # dracut --add nfs initramfs-kernel-version.img kernel-version
  3. 以下のコマンドを使用して、initrd のファイルパーミッションを 644 に変更します。
    # chmod 644 initramfs-kernel-version.img
    警告
    initrd のファイルパーミッションが変更されていない場合は、pxelinux.0 ブートローダーが「file not found」エラーで失敗します。
  4. 作成された initramfs-kernel-version.imgtftp のブートディレクトリーにコピーします。
  5. /var/lib/tftpboot/ ディレクトリーで initrd およびカーネルを使用するように、デフォルトのブート設定を編集します。この設定は、エクスポートしたファイルシステム(/exported/root/directory)を読み書きとしてマウントするように、ディスクレスクライアントの root に指示する必要があります。/var/lib/tftpboot/pxelinux.cfg/default ファイルに以下の設定を追加し ます。
    default rhel7
    
    label rhel7
      kernel vmlinuz-kernel-version
      append initrd=initramfs-kernel-version.img root=nfs:server-ip:/exported/root/directory rw
    server-ip を、tftp サービスおよび DHCP サービスが置かれているホストマシンの IP アドレスに置き換えます。
これで、NFS 共有がディスクレスクライアントにエクスポートできるようになりました。これらのクライアントは、PXE 経由でネットワーク経由で起動できます。

第25章 オンラインストレージ管理

多くの場合、オペレーティングシステムの実行中にストレージデバイスを追加、削除、または再作成する方が望ましいです。本章では、システムの実行中に Red Hat Enterprise Linux 7 ホストシステムでストレージデバイスを再設定するために使用できる手順の概要を説明します。iSCSI およびファイバーチャネルストレージ相互接続に対応し、他の相互接続タイプは今後追加される可能性があります。
本章では、ストレージデバイスの追加、削除、変更、およびモニタリングを中心に説明します。詳細は、ファイバーチャネルまたは iSCSI プロトコルについて説明しません。これらのプロトコルに関する詳細は、他のドキュメントを参照してください。
本章では、さまざまな sysfs オブジェクトを参照します。Red Hat は、sysfs オブジェクト名とディレクトリー構造は、主要な Red Hat Enterprise Linux リリースで変更される可能性があります。これは、アップストリームの Linux カーネルが安定した内部 API を提供しないためです。トランスポート可能な方法で sysfs オブジェクトを参照する方法については、ガイドラインについては、カーネルソースツリーの /usr/share/doc/kernel-doc-version/Documentation/sysfs-rules.txt のドキュメントを参照してください。
警告
オンラインストレージの再設定は注意して行う必要があります。プロセス中のシステム障害や中断により、予期しない結果が生じる可能性があります。Red Hat は、変更操作時に可能な最大エクステントへのシステムの負荷を軽減することを推奨します。これにより、I/O エラー、メモリー不足のエラー、または設定変更の midst で発生した同様のエラーが削減されます。以下のセクションでは、これに関するより具体的なガイドラインを説明します。
また、Red Hat は、オンラインストレージの再設定前にすべてのデータのバックアップを作成することを推奨します。 

25.1. ターゲットセットアップ

Red Hat Enterprise Linux 7 では、targetcli シェルをフロントエンドとして使用し、カーネルターゲットの設定ファイルを直接操作せずに Linux-IO ターゲットの設定を表示、編集、および保存します。targetcli ツールは、管理者が、ファイル、ボリューム、ローカル SCSI デバイス、または RAM ディスクのいずれかがサポートするローカルストレージリソースをリモートシステムにエクスポートできるようにするコマンドラインインターフェースです。targetcli ツールにはツリーベースのレイアウトがあり、組み込みのタブ補完が含まれ、完全なオートコンプリートサポートとインラインドキュメントを提供します。
targetcli の階層は、targetcli 可能な限り単純化されるため、常にカーネルインターフェースと一致しません。
重要
targetcli で行った変更が永続化されるようにするには、ターゲットサービスを起動して有効にします。
# systemctl start target
# systemctl enable target

25.1.1. targetcli のインストールおよび実行

targetcli をインストールするには、以下を使用します。
# yum install targetcli
ターゲット サービスを起動します。
# systemctl start target
システムの起動時に ターゲットが 起動するように設定するには、次のコマンドを実行します。
# systemctl enable target
ファイアウォールの 3260 ポートを開き、ファイアウォール設定を再読み込みします。
# firewall-cmd --permanent --add-port=3260/tcp
Success
# firewall-cmd --reload
Success
targetcli コマンドを使用し、その後にツリーインターフェースのレイアウトに ls コマンドを使用します。
# targetcli
:
/> ls
o- /........................................[...]
  o- backstores.............................[...]
  | o- block.................[Storage Objects: 0]           
  | o- fileio................[Storage Objects: 0]       
  | o- pscsi.................[Storage Objects: 0]         
  | o- ramdisk...............[Storage Ojbects: 0]         
  o- iscsi...........................[Targets: 0]   
  o- loopback........................[Targets: 0]
注記
Red Hat Enterprise Linux 7.0 では、Bash からの targetcli コマンド( targetcli iscsi/ create など)を使用しても機能しず、エラーを返さません。Red Hat Enterprise Linux 7.1 より、シェルスクリプトで targetcli を使用できるように エラーステータスコードが提供されます。

25.1.2. バックストアの作成

バックストアは、エクスポートした LUN のデータをローカルマシンに保存するさまざまな方法に対応します。ストレージオブジェクトを作成して、バックストアが使用するリソースを定義します。
注記
Red Hat Enterprise Linux 6 では、「backing-store」という用語を使用して、作成されたマッピングを参照します。ただし、各種の「backstores」を使用すると、様々な方法での混乱を避けるため、Red Hat Enterprise Linux 7 では、「ストレージオブジェクト」という用語は、作成されたマッピングと「backstores」という用語は異なるタイプのバッキングデバイスの記述に使用されます。
LIO がサポートするバックストアデバイスは次のとおりです。
FILEIO(Linux ファイルベースのストレージ)
FILEIO ストレージオブジェクトは、write_back 操作または write_thru 操作 のいずれかをサポートします。write_back は、ローカルファイルシステムキャッシュを有効にします。これにより、パフォーマンスが向上しますが、データの損失のリスクが高まります。write_ thru が優先されるため、write_back=false を使用して write_back を無効にすることが推奨されます。
fileio ストレージオブジェクトを作成するには、/ backstores/fileio create file_name file_location file_size write_ back=false コマンドを実行します。以下に例を示します。
/> /backstores/fileio create file1 /tmp/disk1.img 200M write_back=false
Created fileio file1 with size 209715200
BLOCK(Linux BLOCK デバイス)
ブロックドライバーにより、/sys/block に表示されるブロックデバイスを LIO で使用できます。これには物理デバイス (HDD、SSD、CD、DVD など) および論理デバイス (ソフトウェアまたはハードウェアの RAID ボリューム、LVM ボリュームなど) が含まれます。
注記
通常、BLOCK バックストアは最適なパフォーマンスを提供します。
ブロックデバイスを使用して BLOCK バックストアを作成するには、以下のコマンドを使用します。
# fdisk /dev/vdb
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0x39dc48fb.

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): *Enter*
Using default response p
Partition number (1-4, default 1): *Enter*
First sector (2048-2097151, default 2048): *Enter*
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-2097151, default 2097151): +250M
Partition 1 of type Linux and of size 250 MiB is set

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
/> /backstores/block create name=block_backend dev=/dev/vdb
Generating a wwn serial.
Created block storage object block_backend using /dev/vdb.
注記
論理ボリュームに BLOCK バックストアを作成することもできます。
PSCSI(Linux パススルー)
SCSI エミュレーションなしで SCSI コマンドの直接パススルーに対応するストレージオブジェクト、および /proc/scsi/scsi(SAS ハードドライブなど)の lsscsi で表示される基礎となる SCSI デバイスでは、バックストアとして設定できます。このサブシステムでは、SCSI-3 以降に対応しています。
警告
PSCSI は上級ユーザーのみが使用してください。Aysmmetric Logical Unit Assignment(ALUA)または永続予約(VMware ESX や vSphere で使用される永続予約)などの高度な SCSI コマンドは、通常はデバイスのファームウェアに実装されず、誤作動やクラッシュが発生する可能性があります。不明な場合は、代わりに実稼働設定に BLOCK を使用します。
この例では、/dev/sr0 を使用して物理 SCSI デバイス である TYPE_ROM デバイスの PSCSI バックストアを作成するには、以下を使用します。
/> backstores/pscsi/ create name=pscsi_backend dev=/dev/sr0
Generating a wwn serial.
Created pscsi storage object pscsi_backend using /dev/sr0
メモリーコピー RAM ディスク(Linux RAMDISK_MCP)
メモリーコピー RAM ディスク(ramdisk)は、完全な SCSI エミュレーションと、イニシエーターのメモリーコピーを使用した個別のメモリーマッピングを持つ RAM ディスクを提供します。これにより、マルチセッションの機能が提供され、実稼働環境での高速で揮発性マーシャルストレージに特に便利です。
1GB RAM ディスクバックストアを作成するには、以下のコマンドを使用します。
/> backstores/ramdisk/ create name=rd_backend size=1GB
Generating a wwn serial.
Created rd_mcp ramdisk rd_backend with size 1GB.

25.1.3. iSCSI ターゲットの作成

iSCSI ターゲットを作成するには、次のコマンドを実行します。

手順25.1 iSCSI ターゲットの作成

  1. targetcli を実行します。
  2. iSCSI 設定パスに移動します。
    /> iscsi/
    注記
    cd コマンドは、ディレクトリーの変更だけでなく、移動するパスの一覧を表示することもできます。
  3. デフォルトのターゲット名を使用して iSCSI ターゲットを作成します。
    /iscsi> create
    Created target
    iqn.2003-01.org.linux-iscsi.hostname.x8664:sn.78b473f296ff
    Created TPG1
    または、指定した名前を使用して iSCSI ターゲットを作成します。
    /iscsi > create iqn.2006-04.com.example:444
    Created target iqn.2006-04.com.example:444
    Created TPG1
  4. ターゲットが ls で一覧表示されると、新規に作成されたターゲットが表示されることを確認します。
    /iscsi > ls
    o- iscsi.......................................[1 Target]
        o- iqn.2006-04.com.example:444................[1 TPG]
            o- tpg1...........................[enabled, auth]
                o- acls...............................[0 ACL]
                o- luns...............................[0 LUN]
                o- portals.........................[0 Portal]
    
注記
Red Hat Enterprise Linux 7.1 より、ターゲットが作成されるたびに、デフォルトのポータルも作成されます。

25.1.4. iSCSI ポータルの設定

iSCSI ポータルを設定するには、最初に iSCSI ターゲットを作成し、TPG に関連付ける必要があります。方法は、「iSCSI ターゲットの作成」 を参照してください。
注記
iSCSI ターゲットの作成時に Red Hat Enterprise Linux 7.1 に加えて、デフォルトのポータルも作成されます。このポータルは、デフォルトのポート番号(0.0.0.0:3260)ですべての IP アドレスをリッスンするように設定されます。これを削除し、指定されたポータルだけを追加するには、/iscsi/iqn-name/tpg1/portals delete ip_address=0.0.0.0 ip_port=3260 を使用して、必要な情報で新しいポータルを作成します。

手順25.2 iSCSI ポータルの作成

  1. TPG に移動します。
    /iscsi> iqn.2006-04.example:444/tpg1/
  2. ポータルを作成するには、デフォル