Red Hat Training

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

ストレージ管理ガイド

Red Hat Enterprise Linux 7

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

編集者

Marek Suchánek

Red Hat Customer Content Services

編集者

Apurva Bhide

Red Hat Customer Content Services

Milan Navrátil

Red Hat Customer Content Services

Jacquelynn East

Red Hat Customer Content Services

Don Domingo

Red Hat Customer Content Services

概要

このガイドでは、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 KB ブロック単位で表示し、使用済みおよび利用可能なディスク領域の量を KB 単位で表示します。情報をメガバイトおよびギガバイトで表示するには、コマンド df -h を使用します。-h 引数は、人間が読める形式を表します。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 -hs を使用します。その他のオプションについては、man du を参照してください。
Gnome システムモニター
システムのパーティションとディスク領域の使用状況をグラフィック形式で表示するには、アプリケーションシステムツールシステム をクリックするか、コマンド gnome-system-monitor を使用して Gnome システム モニターを使用します。ファイルシステム タブを選択して、システムのパーティションを表示します。次の図は、ファイルシステム タブを示しています。

図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/sdb X など)。sdb はストレージデバイス名、X はパーティション番号です。/dev/sdb X は /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
このディレクトリーには、ソースコードが保存されます。
/usr/tmp は/var/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/ は可変データ用であると述べています。これには、スプールディレクトリーとファイル、ログデータ、一時ファイルおよび一時ファイルが含まれます。
/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/mail は/var/spool/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/ユーザー ディレクトリーには、USB ストレージメディア、DVD、CD-ROM、Zip ディスクなどのリムーバブルメディアのマウントポイントとして使用されるサブディレクトリーが含まれています。以前は、/media/ ディレクトリーがこの目的に使用されていたことに注意してください。
messageslastlog などのシステムログファイルは、/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 に固有のもう 1 つの場所は 、/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 コマンドを使用して明示的に実行します。このコマンドは、ファイルシステム内にある未使用のブロックで、管理者が指定した基準に一致するものをすべて破棄します。
  • オンライン破棄操作は、マウント時に、マウント コマンドの一部として -o 破棄 オプションを使用するか、/etc/fstab ファイル内の 破棄 オプションを使用して指定されます。ユーザーによる介入なしでリアルタイムで実行されます。オンライン破棄操作は、使用中から空きに移行しているブロックのみを破棄します。
どちらの操作タイプも、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 に影響を与えます。つまり、プログラムが後で fsync () 呼び出しを発行しない限り、プログラムによる XFS ファイルシステムへの書き込みがディスク上にあることは保証されません。
ファイルシステム (ext4 および XFS) での遅延割り当ての影響の詳細は、5章ext4 ファイルシステム割り当て機能 を参照してください。
注記
ディスク容量が十分であるように見えても、ファイルの作成または展開が予期しない ENOSPC 書き込みエラーで失敗することがあります。これは、XFS のパフォーマンス指向の設計が原因となります。実際には、残りの容量が数ブロックしかない場合にのみ発生するため、問題にはなりません。
その他の XFS 機能
XFS ファイルシステムは、以下もサポートしています。
拡張属性 (xattr)
これにより、システムが、ファイルごとに、名前と値の組み合わせを追加で関連付けられるようになります。これは、デフォルトで有効になっています。
クォータジャーナリング
クラッシュ後に行なわれる、時間がかかるクォータの整合性チェックが不要になります。
プロジェクト/ディレクトリークォータ
ディレクトリーツリー全体にクォータ制限を適用できます。
サブセカンド (一秒未満) のタイムスタンプ
これにより、タイムスタンプはサブセカンド (一秒未満) になることができます。
デフォルトの atime 動作は relatime です
XFS では Relatime が デフォルトでオンになっています。noatime と比較してオーバーヘッドがほとんどなく、正常な atime 値を維持します。

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 チャンクサイズを指定します。値は バイト単位で指定する必要があり、オプションで 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 以降、Direct Access (DAX) は、ext4 および XFS ファイルシステムでテクノロジープレビューとして利用できます。これは、アプリケーションが永続メモリーをそのアドレス空間に直接マッピングするための手段です。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 は対話形式で 基本モード で実行されます。基本モードのサブコマンドは使用量を報告するだけで、すべてのユーザーが使用できます。基本的な xfs_quota サブコマンドには次のものがあります。
quota username/userID
指定された ユーザー名 または数値の ユーザー ID の使用量と制限を表示します
df
ブロックおよび inode の空きおよび使用済みの数を表示します。
対照的に、xfs_quota には エキスパートモード もあります。このモードのサブコマンドは、制限を実際に設定することができるため、昇格した特権を持つユーザーのみが利用できます。エキスパートモードサブコマンドを対話的に使用するには、以下のコマンドを使用します。
# xfs_quota -x
エキスパートモードのサブコマンドには以下が含まれます。
report /path
特定のファイルシステムのクォータ情報を報告します。
limit
クォータの制限を変更します。
基本モードまたはエキスパートモードのサブコマンドの完全なリストについては、サブコマンド help を使用してください。
すべてのサブコマンドは、-c オプション (エキスパートサブコマンドの場合は -x) を使用して、コマンドラインから直接実行することもできます。

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

たとえば、/home (/dev/blockdevice 上) のサンプルクォータレポートを表示するには、コマンド 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 に対して、ソフトおよびハード i ノード数制限をそれぞれ 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 ファイルシステム上のグループ アカウンティング に、それぞれ 1000m と 1200m のソフトブロック制限と 1200m のハードブロック制限を設定するには、次のコマンドを使用します。
# xfs_quota -x -c 'limit -g bsoft=1000m bhard=1200m accounting' /target/path
注記
コマンド bsoft および bhard は バイト単位でカウントします。
重要
man xfs_quota ではリアルタイムブロック (rtbhard/rtbsoft) がクォータ設定時の有効な単位として説明されていますが、リアルタイムサブボリュームはこのリリースでは有効になっていません。そのため、rtbhard および rtbsoft オプションは適用されません。

プロジェクト制限の設定

XFS ファイルシステムでは、マネージドツリーと呼ばれるファイルシステム内の個々のディレクトリー階層にクォーターを設定できます。各マネージドツリーは、プロジェクト ID とオプションの プロジェクト名 によって一意に識別されます。
  1. プロジェクトで制御されるディレクトリーを /etc/projects に追加します。たとえば、次の例では、一意の ID 11 を持つ /var/log パスを /etc/projects に追加します。プロジェクト ID には、プロジェクトにマッピングされる任意の数値を指定できます。
    # echo 11:/var/log >> /etc/projects
  2. プロジェクト名を /etc/projid に追加して、プロジェクト ID をプロジェクト名にマップします。たとえば、以下は、前のステップで定義されたように logfiles というプロジェクトをプロジェクト ID 11 に関連付けます。
    # echo logfiles:11 >> /etc/projid
  3. プロジェクトのディレクトリーを初期化します。たとえば、次のコマンドはプロジェクトディレクトリー /var を初期化します。
    # xfs_quota -x -c 'project -s logfiles' /var
  4. 初期化したディレクトリーでプロジェクトのクォータを設定します。
    # xfs_quota -x -c 'limit -p bhard=lg logfiles' /var
XFS クォータの操作には、汎用クォータ設定ツール (quotarepquota、および edquota など) も使用できます。ただし、このツールは XFS プロジェクトクォータでは使用できません。
重要
Red Hat では、他のすべての利用可能なツールよりも xfs_quota の使用を推奨します。
XFS クォータの設定の詳細については、man xfs_quotaman projid (5)、および man project (5) を参照してください。

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

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

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

XFS ファイルシステムを修復するには、xfs_repair を使用します。
# xfs_repair /dev/device
xfs_repair ユーティリティーは拡張性が高く、多くの i ノードを持つ非常に大規模なファイルシステムでも効率的に修復できるように設計されています。他の Linux ファイルシステムとは異なり、XFS ファイルシステムが完全にアンマウントされなかった場合でも、xfs_repair はブート時に実行されません。不正なアンマウントが発生した場合、xfs_repair は マウント時にログを再生するだけで、ファイルシステムの一貫性が確保されます。
警告
xfs_repair ユーティリティーは、ダーティーログのある XFS ファイルシステムを修復できません。ログをクリアするには、XFS ファイルシステムをマウントおよびアンマウントします。ログが破損していて再生できない場合は、-L オプション (ログの強制ゼロ化) を使用してログをクリアします (つまり、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 バックアップおよび復元の機能

バックアップ

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/。ファイルシステムをマウントする必要があります。
    • 複数のファイルシステムのバックアップを作成して 1 つのテープデバイスに保存する場合は、復元時にそれらを簡単に識別できるように -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-c3334fa8ea2csession-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/

テープからバックアップを復元する際の情報メッセージ

複数のファイルシステムからのバックアップを含むテープからバックアップを復元する場合、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 ドライバーは、以下の 2 つの方法のいずれかで応答します。
  • 以下のいずれかになるまで再試行を続行します。
    • I/O 操作が成功するか、または
    • I/O 操作の再試行回数または時間制限を超えた場合
  • エラーが永続化し、システムが停止することを考慮してください。
XFS は、現在、必要な動作を特別に設定できる以下のエラー条件を認識しています。
  • EIO : デバイスへの書き込み中にエラーが発生しました
  • ENOSPC : デバイスに空き領域がありません
  • ENODEV : デバイスが見つかりません
特定のハンドラーが定義されていない他のすべての考えられるエラー条件は、単一のグローバル設定を共有します。
XFS がエラーを永続的と見なす条件を、再試行の最大数と最大秒数の両方で設定できます。いずれかの条件が満たされると、XFS は再試行を停止します。
ファイルシステムのマウントを解除すると、その他の設定に関係なく、再試行をすぐにキャンセルするオプションもあります。これにより、永続的なエラーが発生した場合でも、マウント解除操作を成功できます。

3.8.1. 特定の条件および定義されていない条件の設定ファイル

エラー動作を制御する設定ファイルは 、/sys/fs/xfs/device/error/ ディレクトリーにあります。
/sys/fs/xfs/device/error/metadata/ ディレクトリーには、特定のエラー状態ごとにサブディレクトリーが含まれています。
  • /sys/fs/xfs/device/error/metadata/EIO/ (EIO エラー状態の場合)
  • /sys/fs/xfs/device/error/metadata/ENODEV/ (ENODEV エラー状態の場合)
  • ENOSPC エラー状態の場合は 、/sys/fs/xfs/device/error/metadata/ENOSPC/
各設定ファイルには、以下の設定ファイルが含まれます。
  • /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 から C の符号付き整数型である int の最大値までの数値です。これは、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. アンマウント動作の設定

failed_at_unmount オプションが設定されている場合、ファイルシステムはアンマウント中に他のすべてのエラー設定を上書きし、I/O 操作を再試行せずにただちにファイルシステムをマウント解除します。これにより、永続的なエラーが発生した場合でも、マウント解除操作を成功できます。
アンマウント動作を設定するには、以下を実行します。
# echo value > /sys/fs/xfs/device/error/fail_at_unmount
値は1 または 0 のいずれかです。
  • 1 は、 エラーが見つかった場合にすぐに再試行をキャンセルすることを意味します。
  • 0 は、 max_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 ファイルシステム内のファイル群で使用されているディスクブロックのマップを表示します。指定したファイルによって使用されているエクステントや、該当するブロックがないファイルの領域 (ホール) を一覧表示します。
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 ファイルシステムをデバッグします。
これらのユーティリティーの詳細については、それぞれの マニュアル ページを参照してください。

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 コマンドは、ダーティーログのあるファイルシステムでは動作しません。このようなファイルシステムを修復するには、まず マウントアンマウント を実行してログを再生する必要があります。ログが破損していて再生できない場合は、-L オプションを使用してログをゼロにすることができます。
XFS ファイルシステムのファイルシステム修復の詳細は、「XFS」 を参照してください。
メタデータエラーの動作
ext3/4 ファイルシステムでは、メタデータエラーが発生した場合の動作を設定できますが、デフォルトは単に継続します。XFS で回復不可能なメタデータエラーが発生すると、ファイルシステムがシャットダウンされ、EFSCORRUPTED エラーが返されます。システムログには、発生したエラーの詳細が含まれており、必要に応じて xfs_repair を実行することが推奨されます。
Quotas
XFS クォータは再マウントできるオプションではありません。クォータを有効にするには、最初のマウント時に -o quote オプションを指定する必要があります。
クォータパッケージの標準ツールは基本的なクォータ管理タスク (setquotarepquota などのツール) を実行できますが、xfs_quota ツールはプロジェクトクォータ管理などの XFS 固有の機能に使用できます。
quotacheck コマンドは、XFS ファイルシステムには影響しません。クォータアカウンティングが初めてオンになると、内部で自動的に quotacheck を実行します。XFS クォータメタデータは、ファーストクラスのジャーナル化されたメタデータオブジェクトであるため、クォータシステムは、クォータが手動でオフになるまで常に一貫しています。
ファイルシステムのサイズ変更
XFS ファイルシステムには、ファイルシステムを縮小するユーティリティーはありません。XFS ファイルシステムは、xfs_growfs コマンドを使用してオンラインで拡張できます。
Inode 番号
256 バイトの inode を持つ 1TB を超えるファイルシステム、または 512 バイトの inode を持つ 2TB を超えるファイルシステムでは、XFS の inode 番号が 2^32 を超える可能性があります。このような大きな inode 番号により、32 ビットの stat 呼び出しが EOVERFLOW の戻り値で失敗します。上記の問題は、デフォルトの Red Hat Enterprise Linux 7 設定 (4 つの割り当てグループでストライプ化されていない) を使用する場合に発生する可能性があります。ファイルシステムの拡張子や XFS ファイルシステムのパラメーターの変更など、カスタム設定では異なる動作が発生する場合があります。
通常、アプリケーションは、このように大きな inode 番号を正しく処理します。必要に応じて、-o inode32 パラメーターを使用して XFS ファイルシステムをマウントし、inode 番号を 2^32 未満に強制します。inode32 を使用しても、すでに 64 ビットの数値が割り当てられている inode には影響しないことに注意してください。
重要
特定の環境に必要な場合を除き、inode32 オプション は 使用しない でください。inode32 オプションは、割り当て動作を変更します。これにより、下層のディスクブロックに inode を割り当てるための領域がない場合に、ENOSPC エラーが発生する可能性があります。
投機的事前割り当て
XFS は、投機的事前割り当て を使用して、ファイルの書き込み時に EOF を超えてブロックを割り当てます。これにより、NFS サーバーでの同時ストリーミング書き込みワークロードによるファイルの断片化を回避します。デフォルトでは、この事前割り当てはファイルのサイズとともに増加し、"du" の出力で確認できます。投機的事前割り当てのあるファイルで 5 分間ダーティーが発生しない場合、事前割り当ては破棄されます。その時間より前に、inode がキャッシュからサイクルアウトされると、inode が回収される際に、事前割り当てが破棄されます。
投機的な事前割り当てが原因で時期尚早の ENOSPC 問題が発生した場合は、-o allocsize= amount マウントオプションを使用して固定の事前割り当て量を指定できます。
フラグメンテーション関連のツール
フラグメント化は、割り当ての遅延や投機的な事前割り当てなどのヒューリスティックおよび動作のために、XFS ファイルシステムで重大な問題になることはめったにありません。ただし、ファイルシステムの断片化を測定したり、ファイルシステムのデフラグを行うツールは存在します。それらの使用は推奨されていません。
xfs_db frag コマンドは、すべてのファイルシステム割り当てを単一の断片化数値 (パーセンテージで表現) に抽出しようとします。コマンドの出力には、その意味を理解するための十分な専門知識が必要です。たとえば、75% のフラグメント化ファクターの場合は、ファイルあたり平均 4 つのエクステントのみを意味します。このため、xfs_db のフラグメントの出力は有用とは見なされず、フラグメント化の問題を注意深く分析することが推奨されます。
警告
xfs_fsr コマンドは、ファイルシステム上の個々のファイルまたはすべてのファイルをデフラグするために使用できます。後者は、ファイルの局所性を破壊し、空き領域をフラグメント化する可能性があるため、特にお勧めしません。

XFS と比較した ext3 および ext4 で使用されるコマンド

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

表3.1 XFS と比較した ext3 および ext4 の共通コマンド

タスク ext3/4 XFS
ファイルシステムを作成する mkfs.ext4 or mkfs.ext3 mkfs.xfs
ファイルシステム検査 e2fsck xfs_repair
ファイルシステムのサイズ変更 resize2fs xfs_growfs
ファイルシステムのイメージを保存する e2image xfs_metadump および xfs_mdrestore
ファイルシステムのラベル付けまたはチューニングを行う tune2fs xfs_admin
ファイルシステムのバックアップ ダンプ復元 xfsdumpxfsrestore
次の表に、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=owned (デフォルト) です。
データの整合性
ext3 ファイルシステムは、クリーンでないシステムシャットダウンが発生した際にデータの整合性が失われることを防止します。ext3 ファイルシステムにより、データが受けることのできる保護のタイプとレベルを選択できるようになります。ファイルシステムの状態に関しては、ext3 のボリュームはデフォルトで高度なレベルのデータ整合性を維持するように設定されています。
速度
一部のデータを複数回書き込みますが、ext3 のジャーナリングにより、ハードドライブのヘッドモーションが最適化されるため、ほとんどの場合、ext3 のスループットは ext2 よりも高くなります。速度を最適化するために 3 つのジャーナリングモードから選択できますが、システムに障害が発生する可能性のある状況では、モードの選択はデータの整合性がトレードオフの関係になることがあります。
注記
Red Hat がサポートする ext3 の唯一のジャーナリングモードは data=owned (デフォルト) です。
簡単なトランジション
ext2 から ext3 に簡単に移行でき、再フォーマットをせずに、堅牢なジャーナリングファイルシステムの恩恵を受けることができます。このタスクの実行方法は、「ext3 ファイルシステムへの変換」 を参照してください。
注記
Red Hat Enterprise Linux 7 は、統合 extN ドライバーを提供します。これは、ext2 および ext3 設定を無効にすることで実現され、代わりにこれらのディスク上のフォーマットに ext4.ko を使用します。つまり、カーネルメッセージは、使用されている ext ファイルシステムに関係なく、常に ext4 を参照します。

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

インストール後、ext3 ファイルシステムを新たに作成しないといけない場合があります。たとえば、システムに新しいディスクドライブを追加した時に、そのドライブにパーティション設定して ext3 ファイルシステムを使用します。
  1. mkfs.ext3 ユーティリティーを使用して、パーティションまたは LVM ボリュームを ext3 ファイルシステムでフォーマットします。
    # 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 ファイルシステムへのパスに置き換えて、UUID を追加します (例: /dev/sda8)。
既存のファイルシステムの 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 ファイルが存在する場合は、それを削除します。
パーティションを 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) — これにより、システムはファイルごとにいくつかの追加の名前と値のペアを関連付けることができます。
  • Quota journaling: クラッシュ後に行なわれる時間がかかるクォータの整合性チェックが不要になります。
    注記
    ext4 でサポートされているジャーナリングモードは、data=owned (デフォルト) のみです。
  • サブセカンド (一秒未満) のタイムスタンプ - サブセカンドのタイムスタンプを指定します。

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 ストライプ内のストライプユニット数を指定します。
どちらのサブオプションでも、値は ファイルシステムのブロック単位で指定する必要があります。たとえば、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)
  • UUID を追加するには、device を ext4 ファイルシステムへのパスに置き換えます (/dev/sda8 など)。
既存のファイルシステムの 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 ユーティリティーを使用すると、管理者はファイルシステムスーパーブロックにデフォルトのマウントオプションを設定できます。詳細については、mantune2fs を参照してください。

書き込みバリア

書き込みキャッシュが有効になっているデバイスへの電力供給が停止した場合でも、ファイルシステムの整合性を確保できるようにするため、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 size
size2fs コマンドを使用すると、アンマウントされた ext4 ファイルシステムのサイズを減らすこともできます。
# resize2fs /dev/device size
ext4 ファイルシステムのサイズを変更する場合、特定の単位を示す接尾辞が使用されていない限り、resize2fs ユーティリティーはファイルシステムのブロックサイズの単位でサイズを読み取ります。以下の接尾辞は、特定の単位を示しています。
  • s — 512 バイトのセクター
  • K — キロバイト
  • M — メガバイト
  • G — ギガバイト
注記
拡張時のサイズパラメーターは任意です (多くの場合は必要ありません)。size2fs は、コンテナー (通常は論理ボリュームまたはパーティション) の利用可能なスペースをすべて埋めるように自動的に拡張します。
ext4 ファイルシステムのサイズ変更の詳細については、man raise2fs を参照してください。

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 の詳細については、sosreport とは何か、Red Hat Enterprise Linux 4.6 以降で sosreport を作成する方法を参照してください。ナレッジベースの記事
  2. パーティションのロールに応じて、以下を行います。
    • バックアップを作成しているパーティションがオペレーティングシステムのパーティションの場合は、システムをレスキューモードで起動します。『System Administrator's Guide』 の Booting to Rescue Mode セクションを参照してください。
    • 通常のデータパーティションのバックアップを作成する場合は、パーティションのマウントを解除します。
      マウント中にデータパーティションのバックアップを作成することは可能ですが、マウントしたデータパーティションのバックアップを作成する結果は予測できない場合があります。
      ダンプ ユーティリティーを使用してマウントされたファイルシステムをバックアップする必要がある場合は、ファイルシステムに大きな負荷がかかっていないときにバックアップしてください。バックアップ作成時にファイルシステムで発生しているアクティビティーが多いほど、バックアップの破損のリスクが高くなります。
  3. ダンプ ユーティリティーを使用して、パーティションの内容をバックアップします。
    # dump -0uf backup-file /dev/device
    backup-file を、バックアップを保存するファイルへのパスに置き換えます。device を、バックアップを作成する ext4 パーティションの名前に置き換えます。バックアップを、バックアップを作成しているパーティションとは別のパーティションにマウントされているディレクトリーに保存していることを確認してください。

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

    /dev/sda1/dev/sda2、および /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 およびパスワードなしのログインの詳細については、『システム管理者ガイド』 の ssh ユーティリティーの使用 および キーベースの認証の使用 セクションを参照してください。
    たとえば、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. オペレーティングシステムパーティションを復元する場合は、システムをレスキューモードで起動します。『System Administrator's Guide』 の Booting to Rescue Mode セクションを参照してください。
    この手順は、通常のデータパーティションには不要です。
  2. fdisk または parted ユーティリティーを使用して、復元するパーティションを再構築します。
    パーティションが存在しなくなった場合は、再作成します。新しいパーティションは、復元したデータを含めるのに十分な大きさである必要があります。開始番号と終了番号を正しく設定することが重要です。これらは、バックアップ時に fdisk ユーティリティーから取得されるパーティションの開始セクター番号と終了セクター番号です。
    パーティションの変更に関する詳細は、13章Partitions を参照してください。
  3. mkfs ユーティリティーを使用して、宛先パーティションをフォーマットします。
    # mkfs.ext4 /dev/device
    重要
    バックアップファイルを保存するパーティションをフォーマットしないでください。
  4. 新しいパーティションを作成した場合は、/etc/fstab ファイル内のエントリーと一致するように、すべてのパーティションにラベルを付け直します。
    # e2label /dev/device label
  5. 一時的なマウントポイントを作成し、そこにパーティションをマウントします。
    # mkdir /mnt/device
    # mount -t ext4 /dev/device /mnt/device
  6. マウントしたパーティションのバックアップからデータを復元します。
    # cd /mnt/device
    # restore -rf device-backup-file
    リモートマシンに復元する場合、またはリモートホストに保存されているバックアップファイルから復元する場合は、ssh ユーティリティーを使用できます。ssh の詳細については、『システム管理者ガイド』 の ssh ユーティリティーの使用 セクションを参照してください。
    以下のコマンドには、パスワードを使用しないログインを設定する必要があることに注意してください。パスワードなしの ssh ログインの設定の詳細については、『システム管理者ガイド』 の キーベースの認証の使用 セクションを参照してください。
    • 同じマシンに保存されているバックアップファイルから、リモートマシンのパーティションを復元する場合は、次のコマンドを実行します。
      # 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. 再起動します。
    # systemctl reboot

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

/dev/sda1/dev/sda2、および /dev/sda3 パーティションを復元するには例5.2「複数の ext4 パーティションのバックアップの作成」:
  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. 再起動します。
    # 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 の使用方法の詳細については、manquota「ディスククォータの設定」
fsfreeze
ファイルシステムへのアクセスを一時停止するには、コマンド # fsfreeze -f mount-point 使用してファイルシステムをフリーズし、# fsfreeze -u mount-point を 使用してフリーズを解除します。これにより、ファイルシステムへのアクセスが停止し、ディスクに安定したイメージが作成されます。
注記
デバイスマッパードライブに fsfreeze を使用する必要はありません。
詳細については、fsfreeze (8) マンページを参照してください。
で実証されているように、「ext4 ファイルシステムのマウント」tune2fs ユーティリティーは、ext2、ext3、および ext4 ファイルシステムの設定可能なファイルシステムパラメーターを調整することもできます。また、ext4 ファイルシステムのデバッグや分析を行う際には次のツールが役に立ちます。
debugfs
ext2、ext3、ext4 の各ファイルシステムのデバッグを行います。
e2image
ext2、ext3、または ext4 の重要なファイルシステムメタデータをファイルに保存します。
これらのユーティリティーの詳細については、それぞれの マニュアル ページを参照してください。

第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
このオプションは、空きブロックで discard/TRIM を有効にする場合に使用します。
noacl
このオプションを使用して、ACL の使用を無効にします。
space_cache
このオプションを使用して空き領域データをディスクに保存し、ブロックグループのキャッシュを高速化します。これは永続的な変更であり、古いカーネルで安全に起動できます。
nospace_cache
このオプションを使用して、上記の space_cache を無効にします。
clear_cache
このオプションを使用して、マウント中にすべての空き領域キャッシュをクリアします。これは安全なオプションですが、スペースキャッシュの再構築がトリガーされます。そのため、再構築プロセスを終了させるために、ファイルシステムをマウントしたままにしておきます。このマウントオプションは、空き領域に問題が明らかになった後でのみ、一度使用することを目的としています。
enospc_debug
このオプションは、"no space left" 問題をデバッグするために使用します。
recovery
マウント時に自動リカバリーを有効にするには、このオプションを使用します。

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

btrfs ファイルシステムのサイズを変更することはできませんが、使用する各デバイスのサイズを変更することはできます。使用中のデバイスが 1 つしかない場合は、ファイルシステムのサイズを変更する場合と同じように機能します。複数のデバイスを使用中の場合は、手動でサイズを変更して、必要なサイズにする必要があります。
注記
単位サイズは大文字と小文字の区別がありません。G または GiB の g の 両方を受け入れます。
このコマンドは、テラバイトを表す t やペタバイトを表す p を受け入れません。km、および 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
次に、拡大するデバイスの デバイス を特定した後、次のコマンドを使用します。
# btrfs filesystem resize devid:amount /mount-point
以下に例を示します。
# btrfs filesystem resize 2:+200M /btrfstest
Resize '/btrfstest/' of '2:+200M'
注記
金額は、 指定された金額の代わりに 最大値 にすることもできます。これにより、デバイスに残っている空き領域がすべて使用されます。

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
次に、縮小するデバイスの デバイス を特定した後、次のコマンドを使用します。
# 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
次に、変更するデバイスの デバイス を特定した後、次のコマンドを使用します。
# 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. 複数のデバイスを使用したファイルシステムの作成

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

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

4 つのデバイスにファイルシステムを作成します (メタデータミラーリング、データのストライプ化)。
# 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
ドライブのサイズが異なる場合、各ドライブの全容量を使用するには、単一の オプションを使用します。
# mkfs.btrfs -d single /dev/device1 /dev/device2 /dev/device3
作成済みのマルチデバイスファイルシステムに、新しいデバイスを追加するには、次のコマンドを使用します。
# btrfs device add /dev/device1 /mount-point
btrfs モジュールを再起動またはリロードした後、btrfs device scan コマンドを使用して、すべてのマルチデバイスファイルシステムを検出します。詳細は、「btrfs デバイスのスキャン」 を参照してください。

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

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

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

btrfs filesystem show コマンドを使用して、すべての btrfs ファイルシステムとそれに含まれるデバイスをリストします。
btrfs device add コマンドは、マウントされたファイルシステムに新しいデバイスを追加するために使用されます。
btrfs ファイルシステムバランス コマンドは、すべての既存のデバイスにわたって割り当てられたエクステントのバランスをとります (再ストライピング)。
新規デバイスを追加するには、以下のコマンドを一緒に実行します。

例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 に変換するには、デバイスを追加し、チャンク割り当てプロファイルを変更するバランスフィルターを実行します。

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

単一ディスク障害から保護するために、既存の単一デバイスシステム (この場合は /dev/sdb1) を 2 デバイスの RAID1 システムに変換するには、次のコマンドを使用します。
# 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 デバイスの削除」 を使用できます。ただし、デバイスが見つからないか、スーパーブロックが破損している場合は、ファイルシステムを劣化モードでマウントする必要があります。
# 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 device delete missing は、 ファイルシステムのメタデータによって記述されているが、ファイルシステムのマウント時に存在しなかった最初のデバイスを削除します。
重要
見つからないデバイスを含め、特定の 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 つの方法があります。
1 つ目の方法は、指定された単一のデバイスの /sys/block/device/queue/rotational が 0 の場合に、mkfs.btrfs が 単一のデバイスでのメタデータの重複をオフにすることです。これは、コマンドラインで -m single を指定するのと同じです。-m dup オプションを指定すると、オーバーライドしてメタデータを強制的に複製できます。SSD ファームウェアは両方のコピーを失う可能性があるため、複製は必要ありません。これはスペースを浪費し、パフォーマンスが犠牲になります。
2 番目の方法は、SSD マウントオプションのグループ (ssdnossd、および ssd_spread) を使用する方法です。
ssd オプションはいくつかのことを行います。
  • より大きなメタデータのクラスターの割り当てを許可します。
  • 可能な場合は、より順序立ててデータを割り当てます。
  • 鍵とブロック順序に一致するように btree リーフの書き換えを無効にします。
  • 複数のプロセスをバッチ処理せずにログフラグメントをコミットします。
注記
ssd マウントオプションでは、ssd オプションのみが有効になります。無効にするには、nossd オプションを使用します。
一部の SSD は、ブロック番号を頻繁に再利用する場合に最高のパフォーマンスを発揮しますが、他の SSD は、クラスターリングが未使用スペースの大きなチャンクを厳密に割り当てる場合にはるかに優れたパフォーマンスを発揮します。デフォルトでは、mount -o ssd は、割り当てられたブロックが混在している可能性のあるいくつかの空きブロックが存在するブロックのグループを検索します。コマンド mount -o ssd_spread は、割り当てられたブロックが混在していないことを確認します。これにより、ローエンド SSD のパフォーマンスが向上します。
注記
ssd_spread オプションは、ssd オプションと ssd_spread オプションの両方を有効にします。これらのオプションを両方とも無効にするには、nossd を使用します。
ssd オプションがまったく指定されておらず、いずれかのデバイスが非回転型である場合、ssd_spread オプションは自動的に設定されません。
SSD ファームウェアとアプリケーションの負荷の組み合わせはそれぞれ異なるため、これらのオプションはすべて、特定のビルドでテストして、それらの使用によってパフォーマンスが向上または低下するかどうかを確認する必要があります。

6.6. Btrfs リファレンス

マニュアルページ btrfs (8) には、すべての重要な管理コマンドが記載されています。特に以下のものが含まれます。
  • スナップショットを管理するためのすべてのサブボリュームコマンド。
  • デバイスを管理するための デバイス コマンド。
  • スクラブバランス、および デフラグ コマンド。
man ページ mkfs.btrfs (8) には、 btrfs ファイルシステムの作成に関するすべてのオプションを含む情報が含まれています。
btrfs システム上の fsck に関する情報については、マニュアルページ 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 ファイルを共有できるようになります。これは、同じノードにあるプロセスでローカルファイルシステム上のファイルを共有する場合と同様で、両者にはっきり識別できる違いはありません。Red Hat Cluster Suite の詳細は、Red Hat の 『Cluster Administration』 ガイドを参照してください。
GFS2 はリニアボリュームまたはミラーボリュームとなる論理ボリューム (LVM で作成) 上に作成してください。Red Hat Cluster Suite の LVM で作成された論理ボリュームは、CLVM (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 ビットのファイルサイズとオフセットにも対応しているため、クライアントは 2GB 以上のファイルデータにアクセスできます。
  • NFS バージョン 4 (NFSv4) は、ファイアウォールを介してインターネット上で動作し、rpcbind サービスを必要とせず、ACL をサポートし、ステートフル操作を利用します。
Red Hat Enterprise Linux 7.4 リリース以降、Red Hat Enterprise Linux は NFS バージョン 4.2 (NFSv4.2) に完全に対応しています。
以下は、Red Hat Enterprise Linux における NFSv4.2 の機能です。
  • スパースファイル: ファイルの領域の効率を検証し、プレースホルダーがストレージの効率を向上できるようにします。これは、1 つ以上のホールがあるファイルです。ホールは、ゼロのみで設定される、割り当てられていないデータブロックまたは初期化されていないデータブロックです。lseek() NFSv4.2 での動作、サポートseek_hole()seek_data()これにより、アプリケーションはスパースファイル内のホールの位置をマッピングできるようになります。
  • 領域の予約: ストレージサーバーが空き領域を予約することを許可します。これにより、サーバーで領域が不足することがなくなります。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 やファイアウォールが干渉する場合です。
  • 応答が失われ、操作が 2 回送信された場合に特定の操作が不正確な結果を返すことがあるという以前の問題を防ぐために、1 回限りのセマンティクスを提供します (再起動操作を除く)。
NFS クライアントは、デフォルトで NFSv4.1 を使用してマウントを試行し、サーバーが NFSv4.1 に対応していない場合は NFSv4.0 にフォールバックします。サーバーが NFSv4.0 に対応していない場合、マウントは後で NFSv3 に戻ります。
注記
NFS バージョン 2 (NFSv2) は、Red Hat のサポート対象外になりました。
NFS の全バージョンで、IP ネットワーク経由で実行する Transmission Control Protocol (TCP) を使用することができ、NFSv4 の場合は TCP が必須になります。NFSv3 は、IP ネットワークで実行している User Datagram Protocol (UDP) を使用して、クライアントとサーバー間のステートレスなネットワーク接続を提供することができます。
UDP で NFSv3 を使用する場合は、(通常の条件下で) ステートレス UDP 接続のプロトコルオーバーヘッドが TCP より少なくなります。つまり、クリーンで適度なトラフィックのネットワーク上では、UDP の方がパフォーマンスがよくなります。ただし、UDP はステートレスのため、予期しないサーバーダウンなどが発生すると、UDP クライアントはサーバーの要求でネットワークを飽和させ続けます。また、UDP の場合にフレームがなくなると、RPC 要求全体を再転送しなければならなくなります。一方、TCP の場合、再送信が必要なのは失ったフレームのみになります。こうした理由から NFS サーバーへの接続には TCP プロトコルが推奨されます。
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 設定ファイルを参照して、クライアントがエクスポートされたファイルシステムにアクセスできるかどうかを判断します。アクセスが可能なことが確認されると、そのユーザーは、ファイルおよびディレクトリーへの全操作を行えるようになります。
重要
ファイアーウォールを有効にしている Red Hat Enterprise Linux のデフォルトインストールで NFS を正しく動作させるために、IPTables は、デフォルトの TCP ポート 2049 に設定してください。IPTables が正しく設定されていないと、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 のバージョンに応じて、次のようなサービスが連携して動作することになります。
注記
portmap サービスは、Red Hat Enterprise Linux の以前のバージョンでは、RPC プログラム番号を IP アドレスポート番号の組み合わせにマッピングするために使用されていました。このサービスは、IPv6 サポートを有効にするために、Red Hat Enterprise Linux 7 では rpcbind に置き換えられました。
nfs
systemctl start nfs は、 NFS サーバーと適切な RPC プロセスを開始して、共有 NFS ファイルシステムに対する要求を処理します。
nfslock
systemctl start nfs-lock は、 NFS クライアントがサーバー上のファイルをロックできるようにする適切な RPC プロセスを開始する必須サービスをアクティブにします。
rpcbind
rpcbind は、 ローカル RPC サービスからのポート予約を受け入れます。その後、これらのポートは、対応するリモートの RPC サービスによりアクセス可能であることが公開されます。rpcbind は、 RPC サービスの要求に応答し、要求された RPC サービスへの接続を設定します。このプロセスは NFSv4 では使用されません。
以下の RPC プロセスは、NFS サービスを容易にします。
rpc.mountd
このプロセスは、NFSv3 クライアントからの MOUNT リクエストを処理するために NFS サーバーによって使用されます。要求されている NFS 共有が現在 NFS サーバーによりエクスポートされているか、またその共有へのクライアントのアクセスが許可されているかを確認します。マウント要求が許可される場合、rpc.mountd サーバーは 成功 ステータスで応答し、この NFS 共有の ファイルハンドル を 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.statd はnfslock サービスによって自動的に開始され、ユーザー設定は必要ありません。このプロセスは NFSv4 では使用されません。
rpc.rquotad
このプロセスは、リモートユーザーのユーザークォーター情報を提供します。rpc.rquotad はnfs サービスによって自動的に開始されるため、ユーザー設定は必要ありません。
rpc.idmapd
rpc.idmapd は、NFSv4 クライアントとサーバーのアップコールを提供します。これは、回線上の NFSv4 名 (user @domain の形式の文字列) とローカル UID および GID の間でマッピングされます。idmapd が NFSv4 で機能するには、/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 の詳細については、nfsidmap のマニュアルページを参照してください。

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

mount コマンドは、クライアント側で NFS 共有をマウントします。形式は以下のようになります。
# mount -t nfs -o options server:/remote/export /local/directory
このコマンドは、以下のような変数を使用します。
options
マウントオプションのコンマ区切りリスト。有効な NFS マウントオプションの詳細は、「一般的な NFS マウントオプション」 を参照してください。
server
マウントするファイルシステムをエクスポートするサーバーのホスト名、IP アドレス、または完全修飾ドメイン名
/remote/export
サーバー からエクスポートされるファイルシステムまたはディレクトリー、つまり、マウントするディレクトリー
/local/directory
/remote/export がマウントされているクライアントの場所
Red Hat Enterprise Linux 7 で使用される NFS プロトコルのバージョンは、マウント オプション nfsvers または vers によって識別されます。デフォルトでは、マウントは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 は、ブート時にリモートファイルシステムを自動的にマウントする 2 つの方法、/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 の代わりに、カーネルベースの 自動マウント ユーティリティーを使用することもできます。自動マウント機能は以下の 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 形式を使用します。
ネームサービススイッチ (nsswitch) 設定の適切な使用。
Name Service Switch 設定ファイルは、特定の設定データがどこから来るのかを判別する手段を提供するために存在します。この設定の理由は、データにアクセスするための統一されたソフトウェアインターフェイスを維持しながら、管理者が最適なバックエンドデータベースを柔軟に使用できるようにするためです。バージョン 4 の自動マウント機能は、今まで以上に NSS 設定を処理できるようになっていますが、まだ完全ではありません。一方、autofs バージョン 5 は完全な実装です。
このファイルでサポートされている構文の詳細については、man nsswitch.conf を参照してください。すべての NSS データベースが有効なマップソースである訳ではなく、パーサーは無効なデータベースを拒否します。有効なソースは、ファイル ypnisnisplusldap、および hesiod です。
autofs マウントポイントごとの複数のマスターマップエントリー
頻繁に使用されるものの、まだ言及されていないものの 1 つは、ダイレクトマウントポイント /- の複数のマスターマップエントリーの処理です。各エントリーのマップキーはマージされ、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 で制御されるマウントポイントと、それに対応する設定ファイルまたは automount マップと呼ばれるネットワークソースがリストされます。マスターマップの形式は次のとおりです。
mount-point map-name options
この形式で使用されている変数を以下に示します。
mount-point
autofs マウントポイント、/home など。
map-name
マウントポイントの一覧とマウントポイントがマウントされるファイルシステムの場所が記載されているマップソース名です。
options
指定されている場合は、それ自体にオプションが指定されていない場合に限り、指定されたマップのすべてのエントリーに適用されます。この動作は、オプションが累積的だった autofs バージョン 4 とは異なります。混合環境の互換性を実装させるため変更が加えられています。

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

以下は /etc/auto.master ファイルのサンプル行です (cat/etc/auto.master で表示されます)。
/home /etc/auto.misc
マップの一般的な形式はそのマスターマップと同じですが、マスターマップではエントリーの末尾に表示されるオプション (options) がマウントポイント (mount-point) と場所 (location) の間に表示されます。
mount-point   [options]   location
この形式で使用されている変数を以下に示します。
mount-point
これは autofs マウントポイントを指します。これは 1 つのインダイレクトマウント用の 1 つのディレクトリー名にすることも、複数のダイレクトマウント用のマウントポイントの完全パスにすることもできます。各直接および間接マップエントリーキー (mount-point) の後に、スペースで区切られたオフセットディレクトリー (/ で始まるサブディレクトリー名) のリストが続く場合があり、これをマルチマウントエントリーと呼びます。
options
指定した場合は、これらは、独自のオプションを指定しないマップエントリーのマウントオプションになります。
location
これは、ローカルファイルシステムパス (/ で始まるマップ名の場合は、先頭に Sun マップ形式のエスケープ文字: が付きます)、NFS ファイルシステム、またはその他の有効なファイルシステムの場所などのファイルシステムの場所を指します。
以下は、マップファイル (/etc/auto.misc など) の内容のサンプルです。
payroll -fstype=nfs personnel:/dev/hda3
sales -fstype=ext3 :/dev/hda4
マップファイルの最初の列は、autofs マウントポイント (personnel と呼ばれるサーバーからの 売上給与) を示します。2 番目の列は autofs マウントのオプションを示し、3 番目の列はマウントのソースを示します。指定された設定に従って、autofs マウントポイントは /home/payroll および /home/sales になります。-fstype= オプションは省略されることが多く、通常は正しい操作には必要ありません。
ディレクトリーが存在しない場合、自動マウント機能はディレクトリーを作成します。ディレクトリーが存在している状況で自動マウント機能が起動した場合は、自動マウント機能の終了時にディレクトリーが削除されることはありません。
自動マウントデーモンを起動するには、以下のコマンドを使用します。
# systemctl start autofs
自動マウントデーモンを再起動するには、以下のコマンドを使用します。
# systemctl restart autofs
指定された設定を使用して、プロセスが /home/payroll/2006/April.sxc などの autofs でアンマウントされたディレクトリーにアクセスする必要がある場合、automount デーモンは自動的にディレクトリーをマウントします。タイムアウトを指定した場合は、タイムアウト期間中ディレクトリーにアクセスしないと、ディレクトリーが自動的にアンマウントされます。
自動マウントデーモンのステータスを表示するには、以下のコマンドを使用します。
# 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、スキーマなどが使用するサイトに適した設定になっていることを確認してください。
自動マウントマップを 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 はカーネルと マウント コマンドでサポートされている最も高いバージョンを使用します。
オプション 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 サービスに登録されていない場合は、代わりに標準の NFS ポート番号 TCP 2049 が使用されます。
rsize=num および wsize=num
このオプションは、1 回の NFS 読み取り操作または書き込み操作で転送される最大バイト数を設定します。
rsizewsize には、固定のデフォルト値がありません。デフォルトでは、NFS はサーバーとクライアントの両方がサポートしている最大の値を使用します。Red Hat Enterprise Linux 7 では、クライアントとサーバーの最大値は 1,048,576 バイトです。詳細は、What are the default and maximum values for rsize and wsize with NFS mounts? 参照してください。KBase の記事。
sec=flavors
マウントされたエクスポート上のファイルにアクセスするために使用するセキュリティーフレーバーです。flavors の値は、複数のセキュリティーフレーバーのコロンで区切られたリストです。
デフォルトでは、クライアントは、クライアントとサーバーの両方をサポートするセキュリティーフレーバーの検索を試みます。サーバーが選択したフレーバーのいずれかに対応していない場合、マウント操作は失敗します。
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
エクスポートを共有するホストまたはネットワーク
オプション
host に使用されるオプション
各ホストにそれぞれオプションを付けて、複数のホストを 1 行で指定することができます。この場合は、以下のように、各ホスト名の後に、そのホストに対するオプションを括弧を付けて追加します。ホストは空白文字で区切ります。
export host1(options1) host2(options2) host3(options3)
ホスト名を指定するさまざまな方法は、「ホスト名の形式」 を参照してください。
最も単純な形式では、/etc/exports ファイルは、次の例に示すように、エクスポートされたディレクトリーとそのディレクトリーへのアクセスを許可されるホストのみを指定します。

例8.6 /etc/exports ファイル

/exported/directory bob.example.com
ここで、bob.example.com は NFS サーバーから /exported/directory/ をマウントできます。この例ではオプションが指定されていないため、デフォルト 設定が使用されます。
デフォルトの設定は以下のようになります。
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 オプションと anongid オプションを以下のように使用します。
export host(anonuid=uid,anongid=gid)
uidgid は、それぞれユーザー ID とグループ ID の番号になります。anonuid オプションと anongid オプションにより、共有するリモート NFS ユーザー用に、特別なユーザーアカウントおよびグループアカウントを作成できます。
デフォルトでは、アクセス制御リスト (ACLs) は、Red Hat Enterprise Linux では NFS が対応しています。この機能を無効にするには、ファイルシステムをエクスポートするときに no_acl オプションを指定します。
エクスポートするすべてのファイルシステムの各デフォルトは、明示的に上書きする必要があります。たとえば、rw オプションを指定しないと、エクスポートするファイルシステムが読み取り専用として共有されます。以下は、2 つのデフォルトオプションをオーバーライドする /etc/exports のサンプル行です。
/another/exported/directory 192.168.0.3(rw,async)
この例では、192.168.0.3 は/another/exported/directory/ をマウントして読み書きでき、ディスクへの書き込みはすべて非同期です。エクスポートオプションの詳細については、man exportfs を 参照してください。
さらに、デフォルト値が指定されていないオプションも利用できます。たとえば、サブツリーチェックを無効にする、安全でないポートからのアクセスの許可する、安全でないファイルロックを許可する (一部の初期 NFS クライアント実装で必要) などの機能があります。これらのあまり使用されないオプションの詳細については、 man エクスポート を参照してください。
重要
/etc/exports ファイルの形式は、特にスペース文字の使用に関して非常に正確です。ホストからエクスポートするファイルシステムの間、そしてホスト同士の間には、必ず空白文字を挿入してください。また、それ以外の場所 (コメント行を除く) には、空白文字を追加しないでください。
たとえば、以下の 2 つの行は意味が異なります。
/home bob.example.com(rw)
/home bob.example.com (rw)
最初の行では、bob.example.com のユーザーのみに /home ディレクトリーへの読み取りおよび書き込みアクセスが許可されます。2 行目では 、bob.example.com のユーザーがディレクトリーを読み取り専用 (デフォルト) でマウントできるようにしますが、その他のユーザーは読み取り/書き込みでマウントできます。

8.6.2. importfs コマンド

NFS を使用してリモートユーザーにエクスポートされるすべてのファイルシステムと、それらのファイルシステムのアクセスレベルは、/etc/exports ファイルにリストされます。nfs サービスが開始されると、/usr/sbin/exportfs コマンドが起動してこのファイルを読み取り、制御を rpc.mountd (NFSv3 の場合) に渡して実際のマウントプロセスを実行し、次に rpc.nfsd に渡して、ファイルシステムをリモートユーザーが使用できるようにします。
/usr/sbin/exportfs コマンドを手動で発行すると、root ユーザーは NFS サービスを再起動せずにディレクトリーを選択的にエクスポートまたはアンエクスポートできます。適切なオプションを指定すると、/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/nfsRPCNFSDARGS= -N 4 を設定して NFSv4 をオフにします。

8.6.3. ファイアウォール背後での NFS の実行

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

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

NFS サーバーがエクスポートするファイルシステムを検出する方法は 2 種類あります。
  • NFSv3 をサポートする任意のサーバーで、showmount コマンドを使用します。
    $ showmount -e myserver
    Export list for mysever
    /exports/foo
    /exports/bar
  • NFSv4 をサポートするサーバーで、ルートディレクトリー をマウントし、周囲を調べます。
    # mount myserver:/ /mnt/
    # cd /mnt/
    exports
    # ls exports
    foo
    bar
NFSv4 と NFSv3 の両方に対応するサーバーでは、上記の方法はいずれも有効で、同じ結果となります。
注記
Red Hat Enterprise Linux 6 以前には、設定の仕方によって以前の NFS サーバーは別々のパス経由で 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 ポート 875 が 開いている必要があります。デフォルトのポート番号は /etc/services ファイルで定義されます。
    /etc/sysconfig/rpc-rquotad ファイルの RPCRQUOTADOPTS 変数に -p port-number を追加することで、デフォルトのポート番号をオーバーライドできます。
  4. /etc/sysconfig/rpc-rquotad ファイルの変更を有効にするには、rpc-rquotad を再起動します。
    # systemctl restart rpc-rquotad

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

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

8.6.5. ホスト名の形式

ホストは以下の形式にすることができます。
単独のマシン
完全修飾型ドメイン名 (サーバーで解決可能な形式)、ホスト名 (サーバーで解決可能な形式)、あるいは IP アドレス
ワイルドカードで指定された一連のマシン
* または ? を使用します。文字列の一致を指定する文字。ワイルドカードは IP アドレスでは使用しないことになっていますが、逆引き DNS ルックアップが失敗した場合には誤って動作する可能性があります。完全修飾ドメイン名にワイルドカードを指定する場合、ワイルドカードにはドット (.) は含まれません。たとえば、*.example.com には one.example.com が 含まれますが、one.two.example.com は含まれ ません。
IP ネットワーク
a.b.c.d/z を使用します。ここで、a.b.c.d はネットワーク、z はネットマスクのビット数です (たとえば、192.168.0.0/24)。別の使用可能形式は a.b.c.d/netmask となり、ここで 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 を追加します。
    /etc/sysconfig/nfs ファイルの RPCNFSDARGS="--rdma=20049" は、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. オプションで、RPC バインドMOUNT、および 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 出力の例です。RPC バインド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 アドレスまたはホスト名で、どのファイルシステムをマウントするかを制限します。
2 つ目は、ローカルユーザーと同じ方法で、サーバーが NFS クライアント上のユーザーに対してファイルシステムの権限を強制するオプションです。従来は、クライアントに依存してユーザーの UID と GID を指定する AUTH_SYS (AUTH_UNIX とも呼ばれます) を使用してこれを実行します。つまり、悪意のあるクライアントや誤って設定されたクライアントがこれを誤用し、ファイルへのアクセスを許可すべきではないユーザーに対して、ファイルへのアクセスを簡単に与えてしまうことができるため注意が必要です。
こうしたリスクを抑えるため、管理者によって共通のユーザーおよびグループ ID へのユーザー権限が取り消されたり、読み取り専用のアクセスに制限されたりすることがよくあります。ただし、このソリューションにより、NFS 共有が元々想定されている方法では使用されなくなります。
また、NFS ファイルシステムをエクスポートしているシステムで使用している DNS サーバーのコントロールが攻撃者に奪われると、特定のホスト名または完全修飾ドメイン名に関連付けられているシステムが、未承認のマシンに向かう可能性があります。この時、NFS マウントには、これ以上の安全確保を目的としたユーザー名やパスワード情報の交換が行われないため、この未承認のマシンが NFS 共有のマウントを許可されたシステムに なってしまいます
NFS 経由でディレクトリーのエクスポートを行う際にワイルドカードを使用する場合は慎重に行ってください。ワイルドカードの対象が予定よりも広い範囲のシステムを対象とする可能性があります。
rpcbind へのアクセスを制限することも可能です[1]TCP ラッパーを使用したサービス。iptables を使用してルールを作成すると、rpcbindrpc.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 RPCSEC_GSS を使用するための IdM 用の NFS サーバーとクライアントの設定

    • nfs/ホスト名を作成します。 NFS サーバー側の domain@REALM プリンシパル。
    • ホスト/ホスト名を作成します。 サーバー側とクライアント側の両方の ドメイン @REALM プリンシパル。
      注記
      ホスト名 は、NFS サーバーのホスト名 と同じでなければなりません。
    • クライアントとサーバーのキータブに、対応する鍵を追加します。
    手順は、Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy GuideAdding and Editing Service Entries and Keytabs and Setting up a Kerberos-aware NFS Server のセクションを参照してください。
  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
    
    NFS クライアントの設定方法の詳細は、Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy GuideSetting up a Kerberos-aware NFS Client セクションを参照してください。

関連情報

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 を使用します。これにより、ローカルマシン上の root ユーザーとして NFS 共有にアクセスするユーザー ID が nobody に設定されます。ルートスカッシュは、デフォルトオプション root_squash によって制御されます。このオプションの詳細については、を参照してください。/etc/exports 設定ファイル」。できる限りこの root squash 機能は無効にしないでください。
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.statdマニュアル ページには、これらのルールの正確な構文に関する情報が含まれています。

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

なぜなら rpcbind[1] RPC サービスとその通信に使用されるポート番号の間の調整を提供するため、トラブルシューティングの際に rpcbind を 使用して現在の RPC サービスのステータスを表示すると便利です。rpcinfo コマンドは、各 RPC ベースのサービスをポート番号、RPC プログラム番号、バージョン番号、および IP プロトコルタイプ (TCP または UDP) とともに表示します。
適切な NFS RPC ベースのサービスが rpcbind に対して有効になっていることを確認するには、次のコマンドを使用します。
# 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 の詳細とオプションのリストについては、マニュアル ページを参照してください。

8.9. pNFS

NFS v4.1 標準の一部としてのパラレル NFS (pNFS) のサポートは、Red Hat Enterprise Linux 6.4 以降で利用できます。pNFS アーキテクチャーは NFS の拡張性を向上させるため、パフォーマンスが強化される場合もあります。つまり、サーバーに pNFS も実装されると、クライアントは複数のサーバーで同時にデータにアクセスできるようになります。これは、ファイル、オブジェクト、ブロックの 3 つのストレージプロトコルまたはレイアウトに対応します。
注記
このプロトコルでは、pNFS のレイアウトタイプに、ファイル、オブジェクト、ブロックの 3 つを使用できます。Red Hat Enterprise Linux 6.4 クライアントではファイルレイアウトタイプのみをサポートしていましたが、Red Hat Enterprise Linux 7 ではファイルレイアウトタイプをサポートするほか、オブジェクトレイアウトタイプおよびブロックレイアウトタイプがテクノロジープレビューに含まれています。

pNFS の Flex ファイル

Flex ファイルは、スタンドアロンの NFSv3 サーバーおよび NFSv4 サーバーをスケールアウトした名前空間に集約できるようにする pNFS 用の新しいレイアウトです。Flex Flex 機能は、RFC 7862 仕様で説明されているように、NFSv4.2 標準に含まれています。
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 が有効になると、最初のマウント時に nfs_layout_nfsv41_files カーネルが自動的にロードされます。出力のマウントエントリーには、minorversion=1 が含まれている必要があります。次のコマンドを使用して、モジュールが読み込まれたことを確認します。
    $ lsmod | grep nfs_layout_nfsv41_files
  • Flex ファイルに対応するサーバーから、Flex ファイル機能で 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 要求を発行できます。
クライアント間のエラーまたは競合により、サーバーがレイアウトを再び呼び出したり、クライアントにレイアウトを発行しなくなることがあります。このような場合、クライアントは、I/O 要求を SCSI デバイスに直接送信する代わりに、サーバーに対して 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 操作を使用します。
    • layoutgetlayoutreturnlayoutcommit の 各カウンターが増加します。これは、サーバーがレイアウトを提供することを意味します。
    • サーバーの 読み取り および 書き込み カウンターは増加しません。これは、クライアントが 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 exports — NFS ファイルシステムをエクスポートするときに /etc/exports ファイルで使用される一般的なオプションを示します。

便利な Web サイト



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

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

Server Message Block (SMB) プロトコルは、アプリケーション層のネットワークプロトコルを実装します。これは、ファイル共有や共有プリンターなど、サーバー上のリソースにアクセスするために使用されます。SMB は、Microsoft Windows にはデフォルトで実装されています。Red Hat Enterprise Linux を実行している場合は、Samba を使用して SMB 共有を提供し、cifs-utils ユーティリティーを使用してリモートサーバーから SMB 共有をマウントします。
注記
SMB のコンテキストでは、SMB ダイアレクトである CIFS (Common Internet File System) プロトコルについて読むことがあります。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 セクションの サーバー最小プロトコル オプションを NT1 に設定します。これは Samba サーバーのデフォルトです。
  2. mount コマンドに -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 -t cifs -o username=user_name //server_name/share_name /mnt/
Password for user_name@//server_name/share_name:  ********
-o options パラメーターでは、共有のマウントに使用されるオプションを指定できます。詳細は、man ページの mount.cifs(8)「よく使用されるマウントオプション」 セクションおよび 『OPTIONS』 セクションを参照してください。

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

\\ server \ example \ share を DOMAIN \ Administrator ユーザーとして暗号化された SMB 3.0 接続経由で /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 番目のフィールドで、認証情報ファイルへのパスなどのマウントオプションを指定します。詳細は、man ページの mount.cifs(8)「よく使用されるマウントオプション」 セクションおよび 『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
credentials= file_name マウントオプションを マウント ユーティリティーに渡すか、/etc/fstab ファイルで使用して、ユーザー名とパスワードの入力を求められずに共有をマウントできるようになりました。

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

共有をマウントするために指定した認証情報により、デフォルトでマウントポイントのアクセス権が決まります。たとえば、共有をマウントするときに DOMAIN\example ユーザーを使用すると、どのローカルユーザーが操作を実行したかに関係なく、共有に対するすべての操作がこのユーザーとして実行されます。
ただし特定の状況では、システムの起動時に管理者が自動的に共有をマウントしたい場合でも、ユーザーは自分の認証情報を使用して共有のコンテンツに対して操作を実行する必要があります。このとき、multiuser マウントオプションを使用すると、このシナリオを設定できます。
重要
multiuser を使用するには、sec=security_type マウントオプションを、認証情報ファイルの krb5 オプションや ntlmssp オプションなど、非対話式の方法で認証情報の提供に対応するセキュリティータイプに追加で設定する必要があります。「ユーザーとして共有へのアクセス」 を参照してください。
root ユーザーは、マルチユーザー オプションと共有のコンテンツへの最小限のアクセス権を持つアカウントを使用して共有をマウントします。通常のユーザーは、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/
システムの起動時に共有を自動的にマウントしたくない場合は、mount コマンドに -o multiuser,sec= security_type を渡して手動でマウントします。SMB 共有の手動マウントの詳細は、「SMB 共有の手動マウント」 を参照してください。

SMB 共有が multiuser オプションを使用してマウントされているかどうかの確認

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

第10章 FS-Cache

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

図10.1 FS-Cache の概要

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

10.1. パフォーマンスに関する保証

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

10.2. キャッシュの設定

現在、Red Hat Enterprise Linux 7 は キャッシュファイルの キャッシュバックエンドのみを提供します。cachefilesd デーモンは、cachefile を 開始して管理します。/etc/cachefilesd.conf ファイルは、キャッシュファイルが キャッシュサービスを提供する方法を制御します。
キャッシュバックエンドで最初に行うのはキャッシュとして使用するディレクトリーの設定です。これは、次のパラメーターを使用して設定します。
$ 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 を ホストするファイルシステムにキャッシュを保存します。ラップトップでは、ルートファイルシステム (/) をホストファイルシステムとして使用することを推奨しますが、デスクトップマシンの場合は、キャッシュ専用のディスクパーティションをマウントする方が賢明です。
FS-Cache のキャッシュバックエンドで必要とされる機能に対応するファイルシステムには、以下のファイルシステムの Red Hat Enterprise Linux 7 実装が含まれます。
  • ext3 (拡張属性が有効)
  • ext4
  • Btrfs
  • XFS
ホストファイルシステムはユーザー定義の拡張属性に対応する必要があります。FS-Cache はこの属性を使用して、整合性のメンテナーンス情報を保存します。ext3 ファイルシステム (つまり device) のユーザー定義の拡張属性を有効にするには、次を使用します。
# 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 マウントを設定するには、マウント コマンドに -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 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
ただし、この場合、home0:/disk0/fredhome0:/disk0/jim のレベル 2 キーを区別するものが何もないため、スーパーブロックの 1 つだけがキャッシュの使用を許可されます。これに対処するには、少なくとも 1 つのマウントに 一意の識別子 (つまり、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% (ブロックのパーセンテージ), fcull N% (ファイルのパーセンテージ)
キャッシュの空き領域と利用可能なファイルの数がこれらの制限のいずれかを下回ると、カリング動作が開始します。
bstop N% (ブロックのパーセンテージ), fstop N% (ファイルのパーセンテージ)
キャッシュ内の使用可能な領域または使用可能なファイルの数がこの制限のいずれかを下回ると、カリングによってこれらの制限を超える状態になるまで、ディスク領域またはファイルのそれ以上の割り当ては許可されません。
各設定の N のデフォルト値は次のとおりです。
  • ブラン/フルン - 10%
  • bcull/fcull - 7%
  • bstop/fstop - 3%
この設定を行う場合は、以下の条件を満たす必要があります。
  • 0 ≤ bstop < bcull < brun < 100
  • 0 ≤ fstop < fcull < frun < 100
これらは使用可能なスペースと使用可能なファイルのパーセンテージであり、df プログラムによって表示されるパーセンテージを 100 から引いたものとして表示されるわけではありません。
重要
カリングは、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 の参考資料

achefilesd とその設定方法の詳細については、man queuefilesd および man queuefilesd.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 の設計上の制約、利用可能な統計、機能の詳細など、FS-Cache に関する一般情報については、次のカーネルドキュメントを参照してください: /usr/share/doc/kernel-doc- version/Documentation/filesystems/caching/fscache.txt

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

ストレージ管理のセクションは、Red Hat Enterprise Linux 7 におけるストレージに関する考慮事項から始まります。次に、パーティション、論理ボリューム管理、およびスワップパーティションに関する手順を説明します。続いて、ディスククォータと RAID システム、そして mount コマンド、volume_key、および acls の機能について説明します。その後は、SSD の調整、書き込みバリア、I/O 制限、およびディスクレスシステムが続きます。この後に、オンラインストレージに関する大きな章があり、最後にデバイスマッパーのマルチパスと仮想ストレージについて説明します。

第11章 ストレージをインストールする際の注意点

ストレージデバイスやファイルシステムの設定の多くはインストール時にしか実行することができません。ファイルシステムタイプなどの他の設定については、再フォーマットせずに変更できるのは特定の時点までになります。このようにストレージの設定については Red Hat Enterprise Linux 7 をインストールする前に慎重に計画する必要があります。
本章ではシステムのストレージ設定を計画する際の注意点について説明しています。インストール手順 (インストール時のストレージ設定を含む) は、Red Hat が提供する Installation Guide を参照してください。
サイズとストレージの制限に関して 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)、および ワールドワイドポート名 (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 および man dmraid を参照してください。18章RAID (Redundant Array of Independent Disks)

iSCSI の検出および設定

iSCSI ドライブのプラグアンドプレイ検出の場合には、iBFT 起動が可能な ネットワークインターフェイスカード (NIC) のファームウェアで設定を行ってください。インストール時の iSCSI ターゲットの CHAP 認証がサポートされています。ただし、インストール時の iSNS 検出はサポートされていません。

FCoE の検出および設定

Fibre Channel over Ethernet (FCoE) ドライブのプラグアンドプレイ検出は、EDD で起動可能な NIC のファームウェアで設定を行ってください。

DASD

ダイレクトアクセスストレージデバイス (DASD) は、インストール時に追加または設定できません。このデバイスは CMS 設定ファイル内で指定してください。

DIF/DIX を有効にしているブロックデバイス

DIF/DIX は、特定の SCSI ホストバスアダプターおよびブロックデバイスで提供されているハードウェアチェックサムの機能です。DIF/DIX が有効になっていると、ブロックデバイスが汎用ブロックデバイスとして使用されている場合にエラーが発生します。DIF/DIX チェックサムの計算後はバッファーされたデータが上書きされないようにするためのインターロックがバッファー書き込みパス内にないため、バッファーされた入出力または mmap(2) ベースの入出力が正常に動作しなくなります。
これにより、I/O が後でチェックサムエラーで失敗します。この問題は、すべてのブロックデバイス (またはファイルシステムベース) のバッファーリングされた I/O または mmap (2) I/O に共通しているため、上書きによって発生するこれらのエラーを回避することはできません。
したがって、DIF/DIX が有効になっているブロックデバイスは、O_DIRECT を使用するアプリケーションでのみ使用する必要があります。こうしたアプリケーションはローブロックデバイスを使用するはずです。あるいは、ファイルシステムを通じて O_DIRECT I/O のみが発行される限り、DIF/DIX 対応ブロックデバイス上で XFS ファイルシステムを安全に使用することもできます。特定の割り当て動作を行う際にバッファーされた入出力にフォールバックを行わないファイルシステムは XFS のみです。
DIF/DIX チェックサムの計算後に入出力データが変更しないようにするのは常にアプリケーションの役目となるため、DIF/DIX を使用できるアプリケーションを O_DIRECT 入出力および DIF/DIX ハードウェアでの使用を目的として設計されたアプリケーションに限ってください。

第12章 ファイルシステム検査

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

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

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

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

12.2.1. ext2、ext3、および ext4

これらのファイルシステムはすべて、e2fsck バイナリーを使用して、ファイルシステムの検査と修復を実行します。ファイル名 fsck.ext2fsck.ext3、および fsck.ext4 は、この同じバイナリーへのハードリンクです。これらのバイナリーは、システムの起動時に自動的に実行し、その動作は確認されるファイルシステムと、そのファイルシステムの状態によって異なります。
完全なファイルシステムの検査および修復は、メタデータジャーナリングファイルシステムではない ext2 や、ジャーナルのない ext4 ファイルシステムに対して呼び出されます。
メタデータジャーナリング機能のある ext3 ファイルシステムおよび ext4 ファイルシステムの場合、ジャーナルはユーザー空間で再生され、バイナリーは終了します。ジャーナル再生により、クラッシュ後に一貫したファイルシステムが確保されるため、これがデフォルトのアクションになります。
このファイルシステムで、マウント中にメタデータの不整合が生じると、その事実がファイルシステムのスーパーブロックに記録されます。e2fsck が、このようなエラーでファイルシステムがマークされていることを検出すると、e2fsck はジャーナル (がある場合) の再生後にフルチェックを実行します。
-p オプションが指定されていない場合、e2fsck は 実行中にユーザー入力を求めることがあります。-p オプションは、安全に実行できるすべての修復を自動的に実行するように e2fsck に指示します。ユーザーの介入が必要な場合、e2fsck は 出力で未解決の問題を示し、このステータスを終了コードに反映します。
一般的に使用される e2fsck 実行時オプションは次のとおりです。
-n
非変更モード。チェックのみの操作。
-b スーパーブロック
プライマリーシステムが破損している場合は、別のスーパーブロックのブロック番号を指定します。
-f
スーパーブロックに記録されたエラーがなくても、フルチェックを強制実行します。
-j journal-dev
外部のジャーナルデバイス (ある場合) を指定します。
-p
ユーザー入力のないファイルシステムを自動的に修復または preen (修復) する
-y
すべての質問に yes の回答を想定する
e2fsck のすべてのオプションは、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 を探す initscript を満たすためだけに存在します。 起動時の ファイルシステム バイナリー。fsck.xfs は 終了コード 0 で直ちに終了します。
古い xfsprogs パッケージには、xfs_check ツールが同梱されています。このツールは非常にスピードが遅く、大きなファイルシステムに対して十分な拡張性がありません。そのため、xfs_repair -n が推奨され、非推奨になりました。
xfs_repair が動作するには、ファイルシステム上のクリーンなログが必要です。ファイルシステムが完全にアンマウントされていない場合は、xfs_repair を 使用する前にファイルシステムをマウントし、アンマウントする必要があります。ログが破損していて再生できない場合は、-L オプションを使用してログをゼロにすることができます。
重要
-L オプションは、ログを再生できない場合にのみ使用する必要があります。このオプションを使用すると、ログ内のすべてのメタデータの更新が破棄され、結果としてさらに不整合が発生します。
-n オプションを使用して、Dry Run で、チェックのみモードの xfs_repair を実行することができます。このオプションを指定した場合は、ファイルシステムに変更が加えられません。
xfs_repair にはほとんどオプションがありません。共通に使用されるオプションには以下が含まれます。
-n
非変更モードです。チェックのみの操作。
-L
ゼロメタデータログ。マウントによってログを再生できない場合にのみ使用します。
-m maxmem
最大 MB の実行時に使用されるメモリーを制限します。必要な最小メモリーの概算を出すために 0 を指定できます。
-l ログ開発
外部ログデバイス (ある場合) を指定します。
xfs_repair のすべてのオプションは、xfs_repair (8) マニュアルページで指定されています。
次の 8 つの基本フェーズは、実行中に xfs_repair によって実行されます。
  1. Inode および inode ブロックマップ (アドレス指定) のチェック。
  2. Inode 割り当てマップのチェック。
  3. Inode サイズのチェック。
  4. ディレクトリーのチェック。
  5. パス名のチェック。
  6. リンク数のチェック。
  7. フリーマップのチェック。
  8. スーパーブロックチェック。
詳細については、xfs_repair (8) マニュアルページを参照してください。
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 を、設定するドライブのデバイス名に置き換えます。

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

デバイスを使用しない場合は、そのデバイスのパーティションはどれもマウントできず、そのデバイスのスワップ領域も有効にできません。
パーティションの削除またはサイズ変更を行う場合は、パーティションが存在するデバイスが使用中でない必要があります。
使用中のデバイスに新しいパーティションを作成することもできますが、推奨されません。

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

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

表13.1 分割された コマンド

コマンド 説明
help 利用可能なコマンドの一覧を表示します。
mklabel ラベル パーティションテーブル用のディスクラベルを作成します。
mkpart part-type [fs-type] start-mb end-mb 新しいファイルシステムを作成せずに、パーティションを作成します。
name minor-num name Mac と PC98 のディスクラベル用のみのパーティションに名前を付けます。
print パーティションテーブルを表示します。
quit 別れをやめる
rescue start-mb end-mb start-mb から end-mb へ、消失したパーティションを復旧します。
rm minor-num パーティションを削除します。
デバイス を選択 設定する別のデバイスを選択します。
マイナー番号フラグの状態 を設定する パーティションにフラグを設定します。state はオンまたはオフのいずれかになります。
番号フラグ を切り替えます パーティション NUMBER 上の FLAG の状態を切り替えます。
単位 単位 デフォルトのユニットを UNIT に設定します。

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

パーティションテーブルを表示するには、以下を実行します。
  1. パートを 開始します。
  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): ディスクの種類、製造元、モデル番号、およびインターフェイスについて説明しています。
  • Disk /dev/sda: 160GB: ブロックデバイスへのファイルパスと、ストレージキャパシティーを表示しています。
  • Partition Table: msdos: ディスクラベルのタイプを表示しています。
  • パーティションテーブルの Number はパーティション番号です。たとえば、マイナー番号 1 のパーティションは /dev/sda1 に対応します。開始 値と 終了 値はメガバイト単位です。有効な タイプ はメタデータ、フリー、プライマリー、拡張、または論理です。ファイルシステムは ファイルシステムのタイプです。フラグ 列には、パーティションに設定されているフラグがリストされます。利用可能なフラグは、boot、root、swap、hidden、raid、lvm、または lba です。
パーティションテーブルの ファイルシステムは 次のいずれかになります。
  • ext2
  • ext3
  • fat16
  • fat32
  • hfs
  • jfs
  • linux-swap
  • ntfs
  • reiserfs
  • hp-ufs
  • sun-ufs
  • xfs
デバイスの ファイルシステムに 値が表示されない場合は、そのファイルシステムタイプが不明であることを意味します。
注記
parted を再起動せずに別のデバイスを選択するには、次のコマンドを使用して、/dev/sda を選択するデバイスに置き換えます。
(parted) select /dev/sda
デバイスのパーティションテーブルを表示または設定できます。

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

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

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

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

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

パーティションをフォーマットしてラベルを付けるには、以下の手順を使用します。

手順13.2 パーティションのフォーマットとラベル付け

  1. パーティションにファイルシステムがない。ext4 ファイルシステムを作成するには、次を使用します。
    # mkfs.ext4 /dev/sda6
    Warning
    パーティションをフォーマットすると、そのパーティションに現存するすべてのデータが永久に抹消されます。
  2. パーティションにファイルシステムのラベルを付けます。たとえば、新しいパーティションのファイルシステムが /dev/sda6 で、それに Work という ラベルを付ける場合は、次を使用します。
    # e2label /dev/sda6 "Work"
    デフォルトでは、インストールプログラムはパーティションのマウントポイントをラベルとして使用して、ラベルが固有なものとなるようにします。ユーザーは使用するラベルを選択できます。
  3. root としてマウントポイント (例: /work) を作成します。

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

  1. root として、/etc/fstab ファイルを編集して、パーティションの UUID を使用して新しいパーティションを含めます。
    パーティションの UUID の完全なリストを表示するにはコマンド blkid -o list を使用し、個々のデバイスの詳細については blkid device を 使用します。
    /etc/fstab 内:
    • 最初の列には UUID= が 含まれ、その後にファイルシステムの UUID が続きます。
    • 2 番目の列には、新しいパーティションのマウントポイントが含まれている必要があります。
    • 3 番目の列はファイルシステムのタイプ (例: ext4 または swap) である必要があります。
    • 4 番目の列は、ファイルシステムのマウントオプションの一覧になります。ここでの デフォルトという 言葉は、パーティションが起動時にデフォルトのオプションでマウントされることを意味します。
    • 5 番目と 6 番目のフィールドは、バックアップとチェックのオプションを指定します。非ルートパーティションの値の例は 0 2 です。
  2. システムが新しい設定を登録するように、マウントユニットを再生成します。
    # systemctl daemon-reload
  3. ファイルシステムをマウントして、設定が機能することを確認します。
    # mount /work

追加情報

  • /etc/fstab の形式について詳しくは、fstab(5)マニュアルページ。

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

警告
パーティションが設定されているデバイスが使用中の場合は、削除しないでください。

手順13.3 パーティションの削除

  1. パーティションを削除する前に、以下のいずれかを行います。
    • レスキューモードで起動します。
    • デバイスのパーティションをアンマウントし、デバイスのスワップスペースをオフにします。
  2. parted ユーティリティーを起動します。
    # parted device
    device を、パーティションを削除するデバイスに置き換えます (/dev/sda など)。
  3. 現在のパーティションテーブルを表示して、削除するパーティションのマイナー番号を確認します。
    (parted) print
  4. コマンド rm を使用してパーティションを削除します。例えば、マイナー番号 3 のパーティションを削除するのは以下のコマンドです。
    (parted) rm 3
    Enter を押すとすぐに変更が開始されるため、コマンドをコミットする前にコマンドを確認してください。
  5. パーティションを削除した後、print コマンドを使用して、そのパーティションがパーティションテーブルから削除されたことを確認します。
    (parted) print
  6. 分割された シェルを終了します。
    (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 ユーティリティーは、パーティションタイプをフラグにマップしようとすることで、パーティションタイプをある程度制御できますが、これはエンドユーザーにとっては不便です。parted ユーティリティーは、LVM や RAID などの特定のパーティションタイプのみを処理できます。たとえば、parted を使用して最初のパーティションから lvm フラグを削除するには、次を使用します。
# parted /dev/sdc 'set 1 lvm off'
一般的に使用されるパーティションタイプとそれらを表すために使用される 16 進数のリストについては、『Red Hat Enterprise Linux 7 Installation Guide』 の付録 Partitions: Turning One Drive Into Many のパーティションタイプの表を参照してください。

13.5. fdisk でのパーティションのサイズ変更

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

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

以下の手順は、参照用にのみ提供されています。 fdisk を使用してパーティションのサイズを変更するには:
  1. デバイスをアンマウントします。
    # umount /dev/vda
  2. fdisk ディスク名 を実行します。以下に例を示します。
    # 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 は パーティションの末尾を物理セクターに合わせて配置するため、すべての空き領域を使用したくない場合は、Red Hat が人間が判読できるサイズ仕様を使用することを推奨します。正確な数値 (セクター単位) を指定してサイズを指定すると、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. エラーが発生すると、選択したパーティションが不安定になる可能性があるため、変更が正しいことが確実な場合は、w オプションを使用して変更を書き込みます。
  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 ユーザーのみが snapper コマンドを実行できます。
警告
シンプロビジョニングを使用している場合は、シンプールの空き領域を監視します。シンプールが完全に消費されると、データが失われる可能性があります。詳細は、『Red Hat Enterprise Linux 7 Logical Volume Manager Administration Guide』のThinly-Provisioned Logical Volumes (Thin Volumes)を参照してください。
Btrfs ツールおよびファイルシステムはテクノロジープレビューとして提供されるため、実稼働システムには適さないことに注意してください。
root 以外のユーザーまたはグループに特定の Snapper コマンドの使用を許可することは可能ですが、Red Hat では、権限のないユーザーまたはグループに対しては、権限を 昇格させない ことを推奨しています。このような設定は 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 Snapper 設定ファイルの作成

  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 スナップショットの作成

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

14.2.1. プレスナップショットとポストスナップショットのペアの作成

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

プレスナップショットの作成には、以下のコマンドを実行します。
# snapper -c config_name create -t pre
-c config_name オプションは、指定された設定ファイルの仕様に従ってスナップショットを作成します。設定ファイルが存在しない場合は、「Snapper の初期設定の作成」 を参照してください。
create -t オプションは、作成するスナップショットのタイプを指定します。受け入れられるエントリーは、prepost、または single です。
たとえば、次のように lvm_config 設定ファイルを使用して事前スナップショットを作成するには、「Snapper の初期設定の作成」、使用:
# snapper -c SnapperExample create -t pre -p
1
-p オプションは、作成されたスナップショットの番号を出力しますが、使用するかどうかは任意です。

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

ポストスナップショットはスナップショットのエンドポイントであり、「Snapper を使用したプレスナップショットの作成」 の手順に従って、親のプレスナップショットの後に作成する必要があります。

手順14.2 ポストスナップショットの作成

  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 post 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. 1 つのスナップショットの作成

単一の snapper スナップショットの作成は、プレスナップショットまたはポストスナップショットの作成に似ていますが、create -t オプションのみが単一を指定します。1 つのスナップショットを使用すれば、他のスナップショットとは無関係に、1 つのスナップショットを作成できます。ただし、比較を自動的に生成したり、追加情報を一覧表示したりせずに、LVM2 シンボリュームのスナップショットを簡単に作成したい場合は、「スナップショット」 で説明しているように、Red Hat では、この目的で Snapper の代わりに System Storage Manager を使用することをお勧めしています。
1 つのスナップショットを作成するには、以下を実行します。
# snapper -c config_name create -t single
たとえば、次のコマンドは、lvm_config 設定ファイルを使用して単一のスナップショットを作成します。
# snapper -c lvm_config create -t single
単一のスナップショットは変更を追跡するように特別に設計されていませんが、snapper diffxadiff、および status コマンドを使用して、任意の 2 つのスナップショットを比較できます。これらのコマンドの詳細は、「スナップショット間での変更の追跡」 を参照してください。

14.2.3. 自動スナップショットを作成するための Snapper の設定

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

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

statusdiff、および xadiff コマンドを使用して、スナップショット間でサブボリュームに加えられた変更を追跡します。
status
status コマンドは、2 つのスナップショット間で作成、変更、または削除されたファイルとディレクトリーのリスト、つまり 2 つのスナップショット間の変更の包括的なリストを表示します。このコマンドを使用すると、詳細を必要以上に表示することなく、変更の概要を取得できます。
詳細は、status コマンドによる変更の比較」 を参照してください。
diff
diff コマンドは、少なくとも 1 つの変更が検出された場合に、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
この出力は、ファイルに単語を追加するために file4 が変更されたことを示しています。

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 は 2 番目のスナップショットです。
snapper -c config_name undochange 1..2
重要
undochange コマンドを使用しても、Snapper ボリュームは元の状態に戻されず、データの一貫性は提供されません。たとえば、スナップショット 2 の後で、指定された範囲外で発生したファイルの変更は、たとえばスナップショット 1 の状態に戻った後も変更されないままとなります。たとえば、undochange を実行してユーザーの作成を取り消しても、そのユーザーが所有するファイルはそのまま残ります。
また、スナップショットの作成時にファイルの整合性を保証するメカニズムがないため、undochange コマンドを使用すると、すでに存在する不整合がスナップショットに戻される可能性があります。
ルートファイルシステムでは Snapper undochange コマンドを使用しないでください。失敗する可能性があります。
次の図は、undochange コマンドがどのように機能するかを示しています。

図14.1 時間の経過に伴う Snapper のステータス

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

mount および unmount コマンドを使用して変更を元に戻す

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

14.5. Snapper スナップショットの削除

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

第15章 swap 領域

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

15.1. スワップ領域の追加

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

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

Red Hat Enterprise Linux 7 は、デフォルトで、使用可能なすべての領域をインストール時に使用します。この設定を選択している場合は、まず swap 領域として使用するボリュームグループに新しい物理ボリュームを追加しなければなりません。
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. スワップファイルの作成

swap ファイルを追加します。

手順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. スワップ領域の削除

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

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

LVM2 スワップ論理ボリュームを削減するには (/dev/VolGroup00/LogVol01 が 削減するボリュームであると仮定します):

手順15.3 LVM2 の swap 論理ボリュームの削減

  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/LogVol02 が 削除するスワップボリュームであると仮定します):

手順15.4 swap ボリュームグループの削除

  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. 削除されたスワップストレージへのすべての参照を /etc/default/grub ファイルから削除します。
    # vi /etc/default/grub
  6. grub 設定を再構築します。
    1. BIOS ベースのマシンでは、次を実行します。
      # grub2-mkconfig -o /boot/grub2/grub.cfg
    2. UEFI ベースのマシンでは、次を実行します。
      # grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
  7. 論理ボリュームの削除に成功したかどうかをテストするには、アクティブなスワップ容量を調べます。
    $ cat /proc/swaps
    $ free -h

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

swap ファイルを削除します。

手順15.5 swap ファイルの削除

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

15.3. Swap 領域の移動

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

第16章 System Storage Manager (SSM)

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

16.1. SSM のバックエンド

SSM は、基盤となるテクノロジーの詳細を無視して、デバイス、プール、ボリュームの抽象化に準拠する ssmlib/main.py のコア抽象化レイヤーを使用します。バックエンドを ssmlib/main.py に登録して、createsnapshot などの特定のストレージテクノロジーメソッドを処理したり、ボリュームやプール を削除したり することができます。
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. 暗号化バックエンド

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

16.1.3.1. 暗号化ボリューム

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

16.1.3.2. 暗号化スナップショット

暗号化バックエンドはスナップショットに対応していませんが、暗号化したボリュームが 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 コマンドを使用します。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
---------------------------------------------------------------------------------
この表示は、引数を使用してさらに絞り込んで、表示するものを指定できます。使用可能なオプションのリストは、ssm list --help コマンドで確認できます。
注記
指定した引数によっては、SSM がすべてを表示しない場合があります。
  • devices または dev 引数を実行すると、一部のデバイスが省略されます。たとえば、CDRoms デバイスや DM/MD デバイスは、ボリュームとして記載されているときに意図的に非表示になります。
  • バックエンドの中にはスナップショットに対応していないものや、通常のボリュームとスナップショットを区別できないものがあります。これらのバックエンドのいずれかで スナップショット 引数を実行すると、SSM はスナップショットを識別するためにボリューム名を認識しようとします。SSM の正規表現がスナップショットパターンと一致しない場合、スナップショットは認識されません。
  • メインの Btrfs ボリューム (ファイルシステム自体) を除き、マウントされていない Btrfs ボリュームは表示されません。

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

このセクションでは、デバイス /dev/vdb および /dev/vdc、1G の論理ボリューム、および XFS ファイルシステムを持つ新しいプールがデフォルト名で作成されます。
このシナリオを作成するコマンド は ssm create --fs xfs -s 1G/dev/vdb/dev/vdc です。以下のオプションが使用されます。
  • --fs オプションは、必要なファイルシステムタイプを指定します。現在対応しているファイルシステムの種類は次のとおりです。
    • ext3
    • ext4
    • xfs
    • btrfs
  • -s は 論理ボリュームのサイズを指定します。単位を定義するために、次の接尾辞がサポートされています。
    • K または k (キロバイト)
    • M または m (メガバイト)
    • G または g (ギガバイト)
    • T または t (テラバイト)
    • P または p (ペタバイト)
    • E または e (エクサバイト)
  • リストされている 2 つのデバイス、/dev/vdb および /dev/vdc は、作成する 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
ssm コマンド には他にも便利なオプションが 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 つの物理ボリューム、プール、および論理ボリュームを作成しました。

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

ssm check コマンドは、ボリューム上でファイルシステムの整合性をチェックします。複数のボリュームを指定して確認することもできます。ボリュームにファイルシステムがない場合は、ボリュームがスキップされます。
ボリュームlvol001 内のすべてのデバイスをチェックするには、ssm check /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. ボリュームのサイズを大きくする

ssm Resize コマンドは、指定されたボリュームとファイルシステムのサイズを変更します。ファイルシステムがない場合は、ボリューム自体のサイズのみが変更されます。
この例では、現在 /dev/vdb 上に lvol001 という 900MB の論理ボリュームが 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. スナップショット

既存のボリュームのスナップショットを取得するには、ssm snapshot コマンドを使用します。
注記
ボリュームが属するバックエンドがスナップショットをサポートしていない場合、この操作は失敗します。
lvol001 のスナップショットを作成するには、次のコマンドを使用します。
# ssm snapshot /dev/lvm_pool/lvol001
  Logical volume "snap20150519T130900" created
これを確認するには、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                          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. 項目の削除

ssm delete は、デバイス、プール、またはボリュームのいずれかの項目を削除するために使用されます。
注記
削除したデバイスがプールで使用されている場合は、失敗します。これは、-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 /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 パーティションが作成されたことを前提としています。ルート (/) パーティションは、/etc/fstab ファイルでクォータポリシーを設定するために使用できます。

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

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

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

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

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

  1. 次のコマンドを使用して、ファイルシステムにクォータファイルを作成します。
    # quotacheck -cug /file system
  2. 次のコマンドを使用して、ファイルシステムごとの現在のディスク使用量の表を生成します。
    # quotacheck -avug
クォータファイルの作成に使用するオプションを以下に示します。
c
クォータファイルを、クォータを有効にしたファイルシステムごとに作成するように指定します。
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 ユーザーへのクォータの割り当て

たとえば、クォータが /etc/fstab/home パーティション (次の例では /dev/VolGroup00/LogVol02) に対して有効になっており、コマンド 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 によって使用されます。エディターを変更するには、EDITOR ~/.bash_profile ファイル内の環境変数を、選択したエディターのフルパスに変更します。
最初の列は、クォータが有効になっているファイルシステムの名前です。2 列目には、ユーザーが現在使用しているブロック数が示されます。その次の 2 列は、ファイルシステム上のユーザーのソフトブロック制限およびハードブロック制限を設定するのに使用されます。i ノード 列には、ユーザーが現在使用している i ノードの数が表示されます。最後の 2 列は、ファイルシステムのユーザーに対するソフトおよびハードの inode 制限を設定するのに使用されます。
ハードブロック制限は、ユーザーまたはグループが使用できる最大ディスク容量 (絶対値) です。この制限に達すると、それ以上のディスク領域は使用できなくなります。
ソフトブロック制限は、使用可能な最大ディスク容量を定義します。ただし、ハード制限とは異なり、ソフト制限は一定時間超過する可能性があります。この時間は 猶予期間 として知られています。猶予期間の単位は、秒、分、時間、日、週、または月で表されます。
いずれかの値が 0 に設定されていると、その制限は設定されません。テキストエディターで必要な制限に変更します。

例17.4 必要な制限の変更

以下に例を示します。
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. ソフト制限の猶予期間の設定

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

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

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

17.2.1. 有効化と無効化

クォータはゼロに設定することなく、無効にすることができます。すべてのユーザーとグループのクォータをオフにするには、以下のコマンドを使用します。
# quotaoff -vaug
-u オプションまたは -g オプションのいずれも指定しない場合は、ユーザークォータのみが無効になります。-g のみを指定すると、グループクォータのみが無効になります。-v スイッチを使用すると、コマンドの実行時に詳細なステータス情報が表示されます。
ユーザーおよびグループのクォータを再度有効にするには、次のコマンドを使用します。
# quotaon
すべてのファイルシステムでユーザーおよびグループのクォータを有効にするには、次のコマンドを使用します。
# quotaon -vaug
-u オプションまたは -g オプションのいずれも指定しない場合は、ユーザークォータのみが有効になります。-g のみが指定されている場合は、グループのクォータのみが有効になります。
/home などの特定のファイルシステムのクォータを有効にするには、次のコマンドを使用します。
# quotaon -vug /home
注記
quoteon コマンドはマウント時に自動的に実行されるため、XFS では必ずしも必要というわけではありません。詳細については、マニュアルページの quoteon (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
レポートは読みやすいですが、いくつか説明しておくべき点があります。各ユーザーの後に表示される -- は、 ブロックまたは i ノードの制限を超えているかどうかを簡単に判断する方法です。いずれかのソフト制限を超えた場合、対応する - の代わりに + が表示されます。最初の - はブロック制限を表し、2 番目は i ノード制限を表します。
通常、猶予 欄は空白です。ソフト制限が超過した場合、その列には猶予期間に残り時間量に相当する時間指定が含まれます。猶予期間が経過した場合、その代わりに 何も 表示されません。

17.2.3. クォータの精度維持

システムクラッシュなどの理由で、ファイルシステムのマウントを正しく解除できない場合は、次のコマンドを実行する必要があります。
# quotacheck
ただし、システムがクラッシュしていないとしても、quotacheck は定期的に実行できます。quotacheck を定期的に実行する安全な方法には、以下が含まれます。
次回の再起動時に quotacheck を確実に実行する
ほとんどのシステムに最適な方法
この方法は、定期的に再起動する (ビジーな) 複数ユーザーシステムに最も適しています。
シェルスクリプトを /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 を実行することができます。quotacheck -vug file_system コマンドを実行します。このコマンドは、quotacheck が指定された file_system を読み取り専用に再マウントできない場合に失敗します。チェックの後には、ファイルシステムは読み込み/書き込みとして再マウントされることに注意してください。
警告
読み込み/書き込みでマウントされているライブのファイルシステム上での quotacheck の実行は、quota ファイルが破損する可能性があるため、推奨されません。
cron の設定の詳細については、man cron を参照してください。

17.3. ディスククオータのリファレンス

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

第18章 RAID (Redundant Array of Independent Disks)

RAID の登場した背景には、容量が小さく手頃なディスクドライブを複数集めてアレイに結合させ、容量が大きく高価なドライブに負けないパフォーマンスと冗長性を実現しようとする動きがありました。この複数のデバイスからなるアレイは、コンピューター上では単一の論理ストレージユニットまたはドライブとして表されます。
RAID では複数のディスクに情報を拡散させることができます。ディスクのストライピング (RAID レベル 0)、ディスクのミラーリング (RAID レベル 1)、パリティーによるディスクのストライピング (RAID レベル 5) などの技術を使用して冗長性を得ながら待ち時間を抑え、帯域幅を増幅させることでハードディスクがクラッシュした場合の復元力を最大限に引き出します。
データは、一貫して同じサイズの大きさのチャンク (通常は 256K または 512K、 ただし他の値も可) に分割され、アレイ内の各ドライブに分散されます。各チャンクは、使用している RAID レベルに応じて、RAID アレイのハードドライブに書き込まれます。データが読み込まれるとこのプロセスが逆をたどります。その動作はアレイ内の複数のドライブがまるで一台の大容量ドライブであるかのように見えます。
システム管理者や大容量のデータを管理しているユーザーは、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 サブシステムをホストとは別に管理します。ホストに対して、1 RAID アレイごとに 1 つのディスクを表します。
ハードウェア RAID デバイスはシステムの内部にあっても外部にあってもかまいません。内部デバイスは一般的には特殊なコントローラーカードで設定され、RAID のタスクはオペレーティングシステムに対して透過的に処理されます。外部デバイスは一般的には SCSI、ファイバーチャネル、iSCSI、InfiniBand、または他の高速ネットワークなどの相互接続でシステムに接続され、システムには論理ボリュームとして表されます。
RAID コントローラーカードは、オペレーティングシステムへの SCSI コントローラーのように動作し、実際のドライブ通信をすべて処理します。ドライブはユーザーによって RAID コントローラーに接続されてから (通常の SCSI コントローラー同様に)、RAID コントローラーの設定に追加されます。オペレーティングシステムはこの違いを認識できません。

ソフトウェア RAID

ソフトウェア RAID では、カーネルディスク (ブロックデバイス) コード内に各種の RAID レベルを実装しています。高価ディスクコントローラーカードやホットスワップシャーシなど、最優先的な解決策を提供します。 [2] 必須ではありません。ソフトウェア RAID は、SCSI ディスクだけでなく安価な IDE ディスクでも機能します。最近の高速な CPU でもソフトウェア RAID は一般的にハードウェア RAID より優れたパフォーマンスを見せます。
Linux カーネルには マルチディスク (MD) ドライバーが含まれ、これにより RAID ソリューションは完全にハードウェアに依存しなくてもよくなります。ソフトウェアベースのアレイのパフォーマンスは、サーバーの 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 セットを作成するためのユーティリティーを提供します。ただし、これらのユーティリティーでは、(ディスク全体ではなく) パーティションのみが新しいセットのメンバーになることができます。セットにディスク全体を使用するには、ディスク全体にまたがる 1 つのパーティションを作成し、そのパーティションを RAID セットのメンバーとして使用します。
ルートファイルシステムが RAID セットを使用する場合、Anaconda は 特別なカーネルコマンドラインオプションをブートローダー設定に追加し、ルートファイルシステムを検索する前にどの RAID セットをアクティブにするかを initrd に指示します。
インストール時の RAID の設定方法は、Red Hat Enterprise Linux 7 Installation Guide を参照してください。

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

Red Hat Enterprise Linux 7 のインストール後に、RAID 以外の root ディスクを RAID1 ミラーに変換する必要がある場合は、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 
注記
grub2-install/dev/sda コマンドを PowerPC マシン上で実行すると機能せず、エラーが返されますが、システムは期待どおりに起動します。

18.6. RAID セットの設定

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

mdadm

mdadm コマンドラインツールは、Linux でソフトウェア RAID を管理するために使用されます (つまり mdraid)。さまざまな mdadm モードとオプションの詳細については、man mdadm を参照してください。マニュアル ページには、ソフトウェア RAID アレイの作成、監視、組み立てなどの一般的な操作に役立つ例も含まれています。

dmraid

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

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

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

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

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


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

第19章 mount コマンドの使用

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

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

現在接続されているファイルシステムをすべて表示するには、次のコマンドに引数を付けずに使用します。
$ mount
上記のコマンドで既知のマウントポイントの一覧が表示されます。行ごとにデバイス名、ファイルシステムのタイプ、マウントしているディレクトリー、およびマウントオプションなどの情報が以下のような形で表示されます。
device on directory type type (options)
ユーザーがマウントされたファイルシステムをツリー状の形式でリスト表示できる 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): 例: UUID=34795a28-ca6d-4fd8-a347-73671d0c19cb
  • ボリュームラベル: 例: LABEL=home
ファイルシステムがマウントされると、directory の元のコンテンツにアクセスできなくなります。
重要: ディレクトリーが使用されていないことを確認してください。
Linux では、すでにファイルシステムが接続されているディレクトリーに対してファイルシステムをマウントする動作が阻止されることはありません。特定のディレクトリーがマウントポイントとして機能するかどうかを判断するには、引数としてディレクトリーを指定して findmnt ユーティリティーを実行し、終了コードを確認します。
findmnt directory; echo $?
ファイルシステムがディレクトリーに接続されていない場合、指定されたコマンドは 1 を返します。
必要な情報をすべて入力せずに、つまりデバイス名、ターゲットディレクトリー、ファイルシステムタイプを入力せずに mount コマンドを実行すると、mount/etc/fstab ファイルの内容を読み取り、指定したファイルシステムがリストにあるかどうかをチェックします。/etc/fstab ファイルには、デバイス名と、選択したファイルシステムがマウントされるように設定されているディレクトリーのリスト、およびファイルシステムのタイプとマウントオプションが含まれています。したがって、/etc/fstab で指定されたファイルシステムをマウントする場合は、次のオプションのいずれかを選択できます。
mount [option] directory
mount [option] device
コマンドを root として実行しない限り、ファイルシステムをマウントするには権限が必要であることに注意してください (「マウントオプションの指定」)。
注記: 特定デバイスの UUID とラベルの確認
UUID と、特定のデバイスのラベル (デバイスがそれを使用している場合) を確認するには、次の形式で blkid コマンドを使用します。
blkid device
たとえば、/dev/sda3 に関する情報を表示するには、次のようにします。
# blkid /dev/sda3
/dev/sda3: LABEL="home" UUID="34795a28-ca6d-4fd8-a347-73671d0c19cb" TYPE="ext3"

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

ほとんどの場合、マウントは ファイルシステムを自動的に検出します。ただし、NFS (Network File System) や CIFS (Common Internet File System) などの特定のファイルシステムは認識されず、手動で指定する必要があります。ファイルシステムのタイプを指定するには、次の形式で mount コマンドを使用します。
$ mount -t type device directory
表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
複数のオプションを指定する場合、コンマの後にスペースを挿入しないでください。そうしないと、マウントは スペースに続く値を追加パラメーターとして誤って解釈します。
表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
ISO9660 は設計上、読み取り専用のファイルシステムになっていることに注意してください。

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 共有マウントポイントの作成

他のファイルシステムが通常マウントされる場所は 2 つあります。リムーバブルメディア用の /media/ ディレクトリーと、一時的にマウントされたファイルシステム用の /mnt/ ディレクトリーです。共有マウントを使用すると、この 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 ファイルのルートエントリー (/) で デフォルト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. ルートを 即座に再マウントする

システム起動時にルート (/) が読み取り専用権限でマウントされていた場合は、書き込み権限で再マウントできます。
# 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