ファイルシステムの管理
Red Hat Enterprise Linux 8 でのファイルシステムの作成、変更、管理
概要
オープンソースをより包摂的に
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージ を参照してください。
Red Hat ドキュメントへのフィードバック (英語のみ)
ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。改善点を報告する場合は、以下のように行います。
特定の文章に簡単なコメントを記入する場合は、以下の手順を行います。
- ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上端に Feedback ボタンがあることを確認してください。
- マウスカーソルで、コメントを追加する部分を強調表示します。
- そのテキストの下に表示される Add Feedback ポップアップをクリックします。
- 表示される手順に従ってください。
より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。
- Bugzilla の Web サイトにアクセスします。
- Component で Documentation を選択します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
- Submit Bug をクリックします。
第1章 利用可能なファイルシステムの概要
利用可能な選択肢と、関連するトレードオフが多数あるため、アプリケーションに適したファイルシステムを選択することが重要になります。本章では、Red Hat Enterprise Linux 8 に同梱されているファイルシステムの一部を説明し、アプリケーションに適したファイルシステムに関する過去の背景と推奨事項を示します。
1.1. ファイルシステムの種類
Red Hat Enterprise Linux 8 は、さまざまなファイルシステム (FS) に対応します。さまざまな種類のファイルシステムがさまざまな問題を解決し、その使用はアプリケーションによって異なります。最も一般的なレベルでは、利用可能なファイルシステムを以下の主要なタイプにまとめることができます。
表1.1 ファイルシステムの種類とそのユースケース
タイプ | ファイルシステム | 属性とユースケース |
---|---|---|
ディスクまたはローカルのファイルシステム | XFS | XFS は、RHEL におけるデフォルトファイルシステムです。ファイルをエクステントとして配置するため、ext4 と比べて断片化に対する影響はありません。Red Hat は、互換性や、パフォーマンスおいて稀に発生する難しい問題などの特別な理由がない限り、XFS をローカルファイルシステムとしてデプロイすることを推奨します。 |
ext4 | ext4 には、Linux の寿命が長いという利点があります。したがって、ほとんどすべての Linux アプリケーションでサポートされます。多くの場合は、パフォーマンスで XFS に匹敵します。ext4 は、一般的にホームディレクトリーに使用されます。 | |
ネットワーク、またはクライアント/サーバーのファイルシステム | NFS | NFS は、同じネットワークにある複数のシステムでのファイル共有に使用します。 |
SMB | SMB は、Microsoft Windows システムとのファイル共有に使用します。 | |
共有ストレージまたは共有ディスクのファイルシステム | GFS2 | GFS2 は、コンピュートクラスターのメンバーに共有書き込みアクセスを提供します。可能な限り、ローカルファイルシステムの機能的経験を備えた安定性と信頼性に重点が置かれています。SAS Grid、Tibco MQ、IBM Websphere MQ、および Red Hat Active MQ は、GFS2 に問題なくデプロイされています。 |
ボリューム管理ファイルシステム | Stratis (テクノロジープレビュー) | Stratis は、XFS と LVM を組み合わせて構築されたボリュームマネージャーです。Stratis の目的は、Btrfs や ZFS などのボリューム管理ファイルシステムにより提供される機能をエミュレートすることです。このスタックを手動で構築することは可能ですが、Stratis は設定の複雑さを軽減し、ベストプラクティスを実装し、エラー情報を統合します。 |
1.2. ローカルファイルシステム
ローカルファイルシステムは、1 台のローカルサーバーで実行し、ストレージに直接接続されているファイルシステムです。
たとえば、ローカルファイルシステムは、内部 SATA ディスクまたは SAS ディスクにおける唯一の選択肢であり、ローカルドライブを備えた内蔵ハードウェア RAID コントローラーがサーバーにある場合に使用されます。ローカルファイルシステムは、SAN にエクスポートされたデバイスが共有されていない場合に、SAN が接続したストレージに最もよく使用されているファイルシステムです。
ローカルファイルシステムはすべて POSIX に準拠しており、サポートされているすべての Red Hat Enterprise Linux リリースと完全に互換性があります。POSIX 準拠のファイルシステムは、read()
、write()
、seek()
など、明確に定義されたシステムコールのセットに対応します。
アプリケーションプログラマーの観点では、ローカルファイルシステム間の違いは比較的少なくなります。ユーザーの観点で最も重要な違いは、スケーラビリティーとパフォーマンスに関するものです。ファイルシステムの選択を検討する際に、ファイルシステムのサイズ、必要な固有の機能、実際のワークロードにおける実行方法を考慮してください。
利用可能なローカルファイルシステム
- XFS
- ext4
1.3. XFS ファイルシステム
XFSは、拡張性が高く、高性能で堅牢な、成熟した 64 ビットのジャーナリングファイルシステムで、1 台のホストで非常に大きなファイルおよびファイルシステムに対応します。これは、Red Hat Enterprise Linux 8 のデフォルトのファイルシステムです。XFS は、元々 1990 年代の前半に SGI により開発され、極めて大規模なサーバーおよびストレージアレイで実行されてきた長い歴史があります。
XFS の機能は次のとおりです。
- 信頼性
- メタデータジャーナリング - システムの再起動時、およびファイルシステムの再マウント時に再生できるファイルシステム操作の記録を保持することで、システムクラッシュ後のファイルシステムの整合性を確保します。
- 広範囲に及ぶランタイムメタデータの整合性チェック
- 拡張性が高く、高速な修復ユーティリティー
- クォータジャーナリングクラッシュ後に行なわれる、時間がかかるクォータの整合性チェックが不要になります。
- スケーラビリティーおよびパフォーマンス
- 対応するファイルシステムのサイズが最大 1024 TiB
- 多数の同時操作に対応する機能
- 空き領域管理のスケーラビリティーに関する B-Tree インデックス
- 高度なメタデータ先読みアルゴリズム
- ストリーミングビデオのワークロードの最適化
- 割り当てスキーム
- エクステント (領域) ベースの割り当て
- ストライプを認識できる割り当てポリシー
- 遅延割り当て
- 領域の事前割り当て
- 動的に割り当てられる inode
- その他の機能
- Reflink ベースのファイルのコピー (Red Hat Enterprise Linux 8 の新機能)
- 密接に統合されたバックアップおよび復元のユーティリティー
- オンラインのデフラグ
- オンラインのファイルシステム拡張
- 包括的な診断機能
-
拡張属性 (
xattr
)。これにより、システムが、ファイルごとに、名前と値の組み合わせを追加で関連付けられるようになります。 - プロジェクトまたはディレクトリーのクォータ。ディレクトリーツリー全体にクォータ制限を適用できます。
- サブセカンド (一秒未満) のタイムスタンプ
パフォーマンスの特徴
XFS は、エンタープライズレベルのワークロードがある大規模なシステムで優れたパフォーマンスを発揮します。大規模なシステムとは、相対的に CPU 数が多く、さらには複数の HBA、および外部ディスクアレイへの接続を備えたシステムです。XFS は、マルチスレッドの並列 I/O ワークロードを備えた小規模のシステムでも適切に実行します。
XFS は、シングルスレッドで、メタデータ集約型のワークロードのパフォーマンスが比較的低くなります。たとえば、シングルスレッドで小さなファイルを多数作成し、削除するワークロードがこれに当てはまります。
1.4. ext4 ファイルシステム
ext4 ファイルシステムは、ext ファイルシステムファミリーの第 4 世代です。これは、Red Hat Enterprise Linux 6 でデフォルトのファイルシステムです。
ext4 ドライバーは、ext2 および ext3 のファイルシステムの読み取りと書き込みが可能ですが、ext4 ファイルシステムのフォーマットは、ext2 ドライバーおよび ext3 ドライバーと互換性がありません。
ext4 には、以下のような新機能、および改善された機能が追加されました。
- 対応するファイルシステムのサイズが最大 50 TiB
- エクステントベースのメタデータ
- 遅延割り当て
- ジャーナルのチェックサム
- 大規模なストレージサポート
エクステントベースのメタデータと遅延割り当て機能は、ファイルシステムで使用されている領域を追跡する、よりコンパクトで効率的な方法を提供します。このような機能により、ファイルシステムのパフォーマンスが向上し、メタデータが使用する領域が低減します。遅延割り当てにより、ファイルシステムは、データがディスクにフラッシュされるまで、新しく書き込まれたユーザーデータの永続的な場所の選択を保留できます。これにより、より大きく、より連続した割り当てが可能になり、より優れた情報に基づいてファイルシステムが決定を下すことができるため、パフォーマンスが向上します。
ext4 で fsck
ユーティリティーを使用するファイルシステムの修復時間は、ext2 と ext3 よりも高速です。一部のファイルシステムの修復では、最大 6 倍のパフォーマンスの向上が実証されています。
1.5. XFS と ext4 の比較
XFS は、RHEL におけるデフォルトファイルシステムです。このセクションでは、XFS および ext4 の使用方法と機能を比較します。
- メタデータエラーの動作
-
ext4 では、ファイルシステムがメタデータのエラーに遭遇した場合の動作を設定できます。デフォルトの動作では、操作を継続します。XFS が復旧できないメタデータエラーに遭遇すると、ファイルシステムをシャットダウンし、
EFSCORRUPTED
エラーを返します。 - クォータ
ext4 では、既存のファイルシステムにファイルシステムを作成する場合にクォータを有効にできます。次に、マウントオプションを使用してクォータの適用を設定できます。
XFS クォータは再マウントできるオプションではありません。初期マウントでクォータをアクティブにする必要があります。
XFS ファイルシステムで
quotacheck
コマンドを実行すると影響しません。クォータアカウンティングを初めてオンにすると、XFS はクォータを自動的にチェックします。- ファイルシステムのサイズ変更
- XFS には、ファイルシステムのサイズを縮小するユーティリティーがありません。XFS ファイルシステムのサイズのみを増やすことができます。ext4 は、ファイルシステムの拡張と縮小の両方をサポートします。
- Inode 番号
ext4 ファイルシステムは、232 個を超える inode をサポートしません。
XFS は inode を動的に割り当てます。XFS ファイルシステムは、ファイルシステムに空き領域がある限り、inode からは実行できません。
特定のアプリケーションは、XFS ファイルシステムで 232 個を超える inode を適切に処理できません。このようなアプリケーションでは、戻り値
EOVERFLOW
で 32 ビットの統計呼び出しに失敗する可能性があります。Inode 番号は、以下の条件下で 232 個を超えます。- ファイルシステムが 256 バイトの inode を持つ 1 TiB を超える。
- ファイルシステムが 512 バイトの inode を持つ 2 TiB を超える。
inode 番号が大きくてアプリケーションが失敗した場合は、
-o inode32
オプションを使用して XFS ファイルシステムをマウントし、232 未満の inode 番号を実施します。inode32
を使用しても、すでに 64 ビットの数値が割り当てられている inode には影響しません。重要特定の環境に必要な場合を除き、
inode32
オプション は使用しないでください。inode32
オプションは割り当ての動作を変更します。これにより、下層のディスクブロックに inode を割り当てるための領域がない場合に、ENOSPC
エラーが発生する可能性があります。
1.6. ローカルファイルシステムの選択
アプリケーションの要件を満たすファイルシステムを選択するには、ファイルシステムをデプロイするターゲットシステムを理解する必要があります。以下の項目で、選択肢を確認できます。
- 大容量のサーバーがあるか
- ストレージの要件は大きいか、またはローカルで低速な SATA ドライブが存在するか
- アプリケーションで期待される I/O ワークロードの種類
- スループットとレイテンシーの要件
- サーバーおよびストレージハードウェアの安定性
- ファイルとデータセットの標準的なサイズ
- システムで障害が発生した場合のダウンタイムの長さ
サーバーとストレージデバイスの両方が大きい場合は、XFS が最適です。ストレージアレイが小さくても、XFS は、平均のファイルサイズが大きい場合 (たとえば、数百メガバイト) に、非常に優れたパフォーマンスを発揮します。
既存のワークロードが ext4 で良好に機能している場合は、ext4 を引き続き使用することで、ユーザーとアプリケーションに非常に馴染みのある環境を提供できます。
ext4 ファイルシステムは、I/O 機能が制限されているシステムでパフォーマンスが向上する傾向があります。限られた帯域幅 (200MB/s 未満) と、最大約 1000 の IOPS 機能でパフォーマンスが向上します。より高い機能を備えたものであれば、XFS はより高速になる傾向があります。
XFS は、ext4 と比較して、メタデータあたりの CPU の動作を約 2 倍消費します。そのため、同時に処理できることがほとんどない、CPU にバインドされたワークロードがあると、ext4 の方が高速になります。通常、アプリケーションが 1 つの読み取り/書き込みスレッドと小さなファイルを使用する場合は ext4 の方が優れていますが、アプリケーションが複数の読み取り/書き込みスレッドと大きなファイルを使用する場合は、XFS の方が優れています。
XFS ファイルシステムを縮小することはできません。ファイルシステムを縮小できるようにする必要がある場合は、オフライン縮小に対応する ext4 を使用することを検討してください。
通常、Red Hat は、ext4 に対する特別なユースケースがない限り、XFS を使用することを推奨します。また、ターゲットサーバーとストレージシステムで特定のアプリケーションのパフォーマンスを測定して、適切なタイプのファイルシステムを選択するようにしてください。
表1.2 ローカルファイルシステムに関する推奨事項の概要
シナリオ | 推奨されるファイルシステム |
---|---|
特別なユースケースなし | XFS |
大規模サーバー | XFS |
大規模なストレージデバイス | XFS |
大規模なファイル | XFS |
マルチスレッド I/O | XFS |
シングルスレッド I/O | ext4 |
制限された I/O 機能 (1000 IOPS 未満) | ext4 |
制限された帯域幅 (200MB/s 未満) | ext4 |
CPU にバインドされているワークロード | ext4 |
オフラインの縮小への対応 | ext4 |
1.7. ネットワークファイルシステム
クライアント/サーバーファイルシステムとも呼ばれるネットワークファイルシステムにより、クライアントシステムは、共有サーバーに保存されているファイルにアクセスできます。これにより、複数のシステムの、複数のユーザーが、ファイルやストレージリソースを共有できます。
このようなファイルシステムは、ファイルシステムのセットを 1 つ以上のクライアントにエクスポートする、1 つ以上のサーバーから構築されます。クライアントノードは、基盤となるブロックストレージにアクセスできませんが、より良いアクセス制御を可能にするプロトコルを使用してストレージと対話します。
利用可能なネットワークファイルシステム
- RHEL で最も一般的なクライアント/サーバーファイルシステムは、NFS ファイルシステムです。RHEL は、ネットワーク経由でローカルファイルシステムをエクスポートする NFS サーバーコンポーネントと、このようなファイルシステムをインポートする NFS クライアントの両方を提供します。
- RHEL には、Windows の相互運用性で一般的に使用されている Microsoft SMB ファイルサーバーに対応する CIFS クライアントも含まれています。ユーザー空間 Samba サーバーは、RHEL サーバーから Microsoft SMB サービスを使用する Windows クライアントを提供します。
1.10. ボリューム管理ファイルシステム
ボリューム管理ファイルシステムは、簡素化とスタック内の最適化の目的で、ストレージスタック全体を統合します。
利用可能なボリューム管理ファイルシステム
Red Hat Enterprise Linux 8 は、Stratis ボリュームマネージャーがテクノロジープレビューとして提供します。Stratis は、ファイルシステム層に XFS を使用し、LVM、Device Mapper、およびその他のコンポーネントと統合します。
Stratis は、Red Hat Enterprise Linux 8.0 で初めてリリースされました。Red Hat が Btrfs を非推奨にした時に生じたギップを埋めると考えられています。Stratis 1.0 は、ユーザーによる複雑さを隠しつつ、重要なストレージ管理操作を実行できる直感的なコマンドラインベースのボリュームマネージャーです。
- ボリュームの管理
- プールの作成
- シンストレージプール
- スナップショット
- 自動化読み取りキャッシュ
Stratis は強力な機能を提供しますが、現時点では Btrfs や ZFS といったその他の製品と比較される可能性がある機能をいつくか欠いています。たとえば、セルフ修復を含む CRC には対応していません。
第2章 RHEL システムロールを使用したローカルストレージの管理
Ansible を使用して LVM とローカルファイルシステム (FS) を管理するには、RHEL 8 で利用可能な RHEL システムロールの 1 つである storage
ロールを使用できます。
storage
ロールを使用すると、ディスク上のファイルシステム、複数のマシンにある論理ボリューム、および RHEL 7.7 以降の全バージョンでのファイルシステムの管理を自動化できます。
RHEL システムロールと、その適用方法の詳細は、「RHEL システムロールの概要」 を参照してください。
2.1. storage ロールの概要
storage
ロールは以下を管理できます。
- パーティションが分割されていないディスクのファイルシステム
- 論理ボリュームとファイルシステムを含む完全な LVM ボリュームグループ
storage
ロールを使用すると、次のタスクを実行できます。
- ファイルシステムを作成する
- ファイルシステムを削除する
- ファイルシステムをマウントする
- ファイルシステムをアンマウントする
- LVM ボリュームグループを作成する
- LVM ボリュームグループを削除する
- 論理ボリュームを作成する
- 論理ボリュームを削除する
- RAID ボリュームを作成する
- RAID ボリュームを削除する
- RAID を使用して LVM プールを作成する
- RAID を使用して LVM プールを削除する
2.2. storage システムロールでストレージデバイスを識別するパラメーター
storage
ロールの設定は、以下の変数に記載されているファイルシステム、ボリューム、およびプールにのみ影響します。
storage_volumes
管理対象のパーティションが分割されていない全ディスク上のファイルシステムの一覧
現在、パーティションはサポートされていません。
storage_pools
管理するプールの一覧
現在、サポートされている唯一のプールタイプは LVM です。LVM では、プールはボリュームグループ (VG) を表します。各プールの下には、ロールで管理されるボリュームの一覧があります。LVM では、各ボリュームは、ファイルシステムを持つ論理ボリューム (LV) に対応します。
2.3. ブロックデバイスに XFS ファイルシステムを作成する Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook では、storage
ロールを適用し、デフォルトパラメーターを使用してブロックデバイスに XFS ファイルシステムを作成します。
storage
ロールは、パーティションが分割されていないディスク全体または論理ボリューム (LV) でのみファイルシステムを作成できます。パーティションにファイルシステムを作成することはできません。
例2.1 /dev/sdb に XFS を作成する Playbook
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs roles: - rhel-system-roles.storage
-
現在、ボリューム名 (この例では
barefs
) は任意です。storage
ロールは、disks:
属性に一覧表示されているディスクデバイスでボリュームを特定します。 -
XFS は RHEL 8 のデフォルトファイルシステムであるため、
fs_type: xfs
行を省略することができます。 論理ボリュームにファイルシステムを作成するには、エンクロージングボリュームグループを含む
disks:
属性の下に LVM 設定を指定します。詳細は、「論理ボリュームを管理する Ansible Playbook の例」 を参照してください。LV デバイスへのパスを指定しないでください。
関連情報
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
2.4. ファイルシステムを永続的にマウントする Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage
ロールをすぐに適用して、XFS ファイルシステムを永続的にマウントします。
例2.2 /dev/sdb のファイルシステムを /mnt/data にマウントする Playbook
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs mount_point: /mnt/data roles: - rhel-system-roles.storage
-
この Playbook では、ファイルシステムが
/etc/fstab
ファイルに追加され、すぐにファイルシステムをマウントします。 -
/dev/sdb
デバイス上のファイルシステム、またはマウントポイントのディレクトリーが存在しない場合は、Playbook により作成されます。
関連情報
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
2.5. 論理ボリュームを管理する Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage
ロールを適用して、ボリュームグループに LVM 論理ボリュームを作成します。
例2.3 myvg ボリュームグループに mylv 論理ボリュームを作成する Playbook
- hosts: all vars: storage_pools: - name: myvg disks: - sda - sdb - sdc volumes: - name: mylv size: 2G fs_type: ext4 mount_point: /mnt roles: - rhel-system-roles.storage
myvg
ボリュームグループは、次のディスクで構成されます。-
/dev/sda
-
/dev/sdb
-
/dev/sdc
-
-
myvg
ボリュームグループがすでに存在する場合は、Playbook により論理ボリュームがボリュームグループに追加されます。 -
myvg
ボリュームグループが存在しない場合は、Playbook により作成されます。 -
Playbook は、
mylv
論理ボリューム上に Ext4 ファイルシステムを作成し、/mnt
ファイルシステムを永続的にマウントします。
関連情報
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
2.6. オンラインのブロック破棄を有効にする Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook では、storage
ロールを適用して、オンラインのブロック破棄を有効にして XFS ファイルシステムをマウントします。
例2.4 /mnt/data/ でのオンラインのブロック破棄を有効にする Playbook
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs mount_point: /mnt/data mount_options: discard roles: - rhel-system-roles.storage
関連情報
- この Playbook は、「ファイルシステムを永続的にマウントする Ansible Playbook の例」 に記載されている永続的なマウント例のすべての操作も実行します。
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
2.7. Ext4 ファイルシステムを作成してマウントする Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage
ロールを適用して、Ext4 ファイルシステムを作成してマウントします。
例2.5 /dev/sdb に Ext4 を作成し、/mnt/data にマウントする Playbook
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: ext4 fs_label: label-name mount_point: /mnt/data roles: - rhel-system-roles.storage
-
Playbook は、
/dev/sdb
ディスクにファイルシステムを作成します。 -
Playbook は、
/mnt/data
ディレクトリーにファイルシステムを永続的にマウントします。 -
ファイルシステムのラベルは
label-name
です。
関連情報
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
2.8. ext3 ファイルシステムを作成してマウントする Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage
ロールを適用して、Ext3 ファイルシステムを作成してマウントします。
例2.6 /dev/sdb に Ext3 を作成し、/mnt/data にマウントする Playbook
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: ext3 fs_label: label-name mount_point: /mnt/data roles: - rhel-system-roles.storage
-
Playbook は、
/dev/sdb
ディスクにファイルシステムを作成します。 -
Playbook は、
/mnt/data
ディレクトリーにファイルシステムを永続的にマウントします。 -
ファイルシステムのラベルは
label-name
です。
関連情報
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
2.9. storage システムロールを使用した RAID ボリュームの設定
storage
システムロールを使用すると、Red Hat Ansible Automation Platform を使用して RHEL に RAID ボリュームを設定できます。本セクションでは、要件に合わせて RAID ボリュームを設定するために、利用可能なパラメーターを使用して Ansible Playbook を設定する方法を説明します。
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記storage
ソリューションをデプロイするシステムに、Red Hat Ansible Automation Platform をインストールする必要はありません。-
Playbook を実行するシステムに
rhel-system-roles
パッケージがインストールされている。 -
storage
システムロールを使用して、RAID ボリュームをデプロイするシステムの詳細を記録したインベントリーファイルがある。
手順
以下の内容を含む新しい
playbook.yml
ファイルを作成します。- hosts: all vars: storage_safe_mode: false storage_volumes: - name: data type: raid disks: [sdd, sde, sdf, sdg] raid_level: raid0 raid_chunk_size: 32 KiB mount_point: /mnt/data state: present roles: - name: rhel-system-roles.storage
警告特定の状況でデバイス名が変更する場合があります。たとえば、新しいディスクをシステムに追加するときなどです。したがって、データの損失を防ぐために、Playbook で特定のディスク名を使用することは推奨していません。
オプション:Playbook の構文を確認します。
# ansible-playbook --syntax-check playbook.yml
インベントリーファイルで Playbook を実行します。
# ansible-playbook -i inventory.file /path/to/file/playbook.yml
関連情報
- RAID の詳細は、「RAID の管理」 を参照してください。
-
storage システムロールで使用されるパラメーターの詳細は、
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
2.10. storage システムロールを使用した LVM pool with RAID の設定
storage
システムロールを使用すると、Red Hat Ansible Automation Platform を使用して RHEL に LVM pool with RAID を設定できます。本セクションでは、利用可能なパラメーターを使用して Ansible Playbook を設定し、LVM pool with RAID を設定する方法を説明します。
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記storage
ソリューションをデプロイするシステムに、Red Hat Ansible Automation Platform をインストールする必要はありません。-
Playbook を実行するシステムに
rhel-system-roles
パッケージがインストールされている。 -
storage
システムロールを使用して、LVM pool with RAID を設定するシステムの詳細を記録したインベントリーファイルがある。
手順
以下の内容を含む新しい
playbook.yml
ファイルを作成します。- hosts: all vars: storage_safe_mode: false storage_pools: - name: my_pool type: lvm disks: [sdh, sdi] raid_level: raid1 volumes: - name: my_pool size: "1 GiB" mount_point: "/mnt/app/shared" fs_type: xfs state: present roles: - name: rhel-system-roles.storage
注記LVM pool with RAID を作成するには、
raid_level
パラメーターを使用して RAID タイプを指定する必要があります。オプション:Playbook の構文を確認します。
# ansible-playbook --syntax-check playbook.yml
インベントリーファイルで Playbook を実行します。
# ansible-playbook -i inventory.file /path/to/file/playbook.yml
関連情報
- RAID の詳細は、「RAID の管理」 を参照してください。
-
storage システムロールで使用されるパラメーターの詳細は、
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
2.11. storage ロールを使用した LUKS 暗号化ボリュームの作成
storage
ロールを使用し、Ansible Playbook を実行して、LUKS で暗号化されたボリュームを作成および設定できます。
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記ボリュームを作成するシステムに Red Hat Ansible Automation Platform をインストールする必要はありません。
-
Ansible コントローラーに
rhel-system-roles
パッケージがインストールされている。 - storage システムロールを使用して、LUKS 暗号化ボリュームをデプロイするシステムの詳細を記録したインベントリーファイルがある。
手順
以下の内容を含む新しい
playbook.yml
ファイルを作成します。- hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs fs_label: label-name mount_point: /mnt/data encryption: true encryption_password: your-password roles: - rhel-system-roles.storage
オプション:Playbook の構文を確認します。
# ansible-playbook --syntax-check playbook.yml
インベントリーファイルで Playbook を実行します。
# ansible-playbook -i inventory.file /path/to/file/playbook.yml
関連情報
- LUKS の詳細は、「LUKS を使用したブロックデバイスの暗号化」を参照してください。LUKS を使用したブロックデバイスの暗号化
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
関連情報
詳細は、
rhel-system-roles
パッケージをインストールして、以下のディレクトリーを参照してください。-
/usr/share/doc/rhel-system-roles/storage/
-
/usr/share/ansible/roles/rhel-system-roles.storage/
-
第5章 NFS のセキュア化
サーバーで NFS ファイルシステムをエクスポートする場合や、クライアントにマウントする際に、NFS セキュリティーリスクを最小限に抑え、サーバーのデータを保護するには、以下のセクションを検討してください。
5.1. AUTH_SYS とエクスポート制御による NFS 保護
NFS は、エクスポートしたファイルへのアクセスを制御するために、以下の従来のオプションを提供します。
- サーバーは、IP アドレスまたはホスト名を使用して、どのホストにどのファイルシステムのマウントを許可するかをサーバー側で制限します。
-
サーバーは、ローカルユーザーの場合と同じ方法で、NFS クライアントのユーザーに対してファイルシステムの権限を強制します。従来は、NFS は
AUTH_SYS
コールメッセージ (AUTH_UNIX
とも呼ばれます) を使用してこれを実行していました。このメッセージは、クライアントが、ユーザーの UID と GID を提示します。これは、悪意のあるクライアントや誤って設定されたクライアントが簡単にこの間違いを招き、ユーザーがアクセスすべきではないファイルにアクセスできる可能性があることを意味します。
潜在的なリスクを制限するため、多くの場合、管理者は、共通のユーザー ID およびグループ ID に対して、ユーザー権限を読み取り専用にするか、権限を下げてアクセスを制限します。ただし、このソリューションにより、NFS 共有が元々想定されている方法では使用されなくなります。
さらに、攻撃者が、NFS ファイルシステムをエクスポートするシステムが使用する DNS サーバーを制御できた場合は、特定のホスト名または完全修飾ドメイン名に関連付けられたシステムを、承認されていないマシンに指定できます。これで、認証されていないマシンは、NFS 共有のマウントを許可するシステムになります。これは、ユーザー名やパスワードの情報が交換されず、NFS マウントに追加のセキュリティーが提供されるためです。
NFS 経由でディレクトリーのエクスポートを行う際にワイルドカードを使用する場合は慎重に行ってください。ワイルドカードの対象が予定よりも広い範囲のシステムを対象とする可能性があります。
関連情報
-
NFS および
rpcbind
のセキュリティーを保護するには、nftables
、firewalld
などを使用します。これらのフレームワークの設定の詳細は、man ページのnft(8)
およびfirewalld-cmd(1)
を参照してください。
5.2. AUTH_GSS
を使用した NFS セキュリティー
NFS の全バージョンは、RPCSEC_GSS および Kerberos のメカニズムに対応します。
AUTH_SYS とは異なり、RPCSEC_GSS Kerberos メカニズムでは、サーバーは、どのユーザーがそのファイルにアクセスしているかを正確に表すことをクライアントに依存しません。代わりに、暗号を使用してサーバーにユーザーを認証し、悪意のあるクライアントがそのユーザーの Kerberos 認証情報を持たずにユーザーになりすますことがないようにします。RPCSEC_GSS Kerberos メカニズムを使用することが、マウントを保護する最も簡単な方法になります。Kerberos の設定後は、追加の設定が不要になるためです。
5.3. Kerberos を使用するために NFS サーバーおよびクライアントを設定
Kerberos はネットワーク認証システムであり、対称暗号化と、信頼できるサードパーティー (KDC) を使用してクライアントとサーバーが相互に認証できるようにします。Red Hat では、Kerberos の設定に Identity Management (IdM) を使用することを推奨します。
前提条件
-
Kerberos Key Distribution Centre (
KDC
) がインストールされ、設定されている。
手順
-
NFS サーバー側で、
nfs/hostname.domain@REALM
プリンシパルを作成します。 -
サーバーとクライアントに、
host/hostname.domain@REALM
を作成します。 - クライアントとサーバーのキータブに、対応する鍵を追加します。
-
NFS サーバー側で、
サーバーで、
sec=
オプションを使用して、希望するセキュリティーフレーバーを有効にします。すべてのセキュリティーフレーバーと非暗号化マウントを有効にするには、以下のコマンドを実行します。/export *(sec=sys:krb5:krb5i:krb5p)
sec=
オプションを使用するのに有効なセキュリティーフレーバーは、以下のようになります。-
sys
- 暗号化の保護なし (デフォルト) -
krb5
- 認証のみ -
krb5i
- インテグリティー保護 -
krb5p
- プライバシー保護
-
クライアントで、
sec=krb5
(もしくは設定に応じてsec=krb5i
またはsec=krb5p
) をマウントオプションに追加します。# mount -o sec=krb5 server:/export /mnt
関連情報
- Kerberos で保護された NFS 共有で root としてファイルを作成し、このファイルの root 所有権を維持する必要がある場合は、https://access.redhat.com/articles/4040141 を参照してください。この設定は推奨されません。
- NFS 設定の詳細は、man ページの exports(5) および nfs(5) を参照してください。
5.4. NFSv4 セキュリティーオプション
NFSv4 には、Microsoft Windows NT モデルの機能や幅広い導入の経緯があるため、POSIX モデルではなく、Microsoft Windows NT モデルをベースとした ACL サポートが含まれます。
NFSv4 のもう 1 つの重要なセキュリティー機能は、ファイルシステムのマウントに MOUNT
プロトコルを使用しなくなることです。MOUNT
プロトコルは、プロトコルがファイルを処理する方法により、セキュリティー上のリスクが発生します。
5.5. マウントされた NFS エクスポートに対するファイル権限
リモートホストにより NFS ファイルシステムを読み取りまたは読み書きとしてマウントした場合は、パーティションが、各共有ファイルに対する唯一の保護となります。同じユーザー ID の値を共有する 2 つのユーザーが、異なるクライアントシステムに同じ NFS ファイルシステムをマウントすると、そのユーザーは互いのファイルを修正できるようになります。また、クライアントシステムで root としてログインした場合は、su -
コマンドを使用して、NFS 共有が設定されたファイルにアクセスできます。
デフォルトでは、アクセス制御リスト (ACL) は、Red Hat Enterprise Linux では NFS が対応しています。Red Hat では、この機能を有効にしておくことを推奨します。
デフォルトでは、NFS がファイルシステムをエクスポートする際に、root squashing を使用します。これにより、NFS 共有にアクセスするユーザーのユーザー ID が、ローカルマシンの root ユーザーとして nobody
に設定されます。root squashing は、デフォルトのオプション root_squash
で制御されます。このオプションの詳細は、「NFS サーバーの設定」 を参照してください。
NFS 共有を読み取り専用としてエクスポートする場合は、all_squash
オプションの使用を検討してください。このオプションでは、エクスポートしたファイルシステムにアクセスするすべてのユーザーが、nobody
ユーザーのユーザー ID を取得します。
第6章 NFS での pNFS SCSI レイアウトの有効化
データのアクセスに pNFS SCSI レイアウトを使用するように、NFS サーバーおよびクライアントを設定できます。pNFS SCSI は、ファイルへの長期接続のシングルクライアントアクセスに伴うユースケースで利点があります。
前提条件
- クライアントとサーバーの両方で、SCSI コマンドを同じブロックデバイスに送信する必要があります。つまり、ブロックデバイスは共有 SCSI バス上になければなりません。
- ブロックデバイスに XFS ファイルシステムが含まれている必要があります。
- SCSI デバイスは、 SCSI-3 Primary Commands 仕様で説明されているように、SCSI Persistent Reservation に対応している必要があります。
6.1. pNFS テクノロジー
pNFS アーキテクチャーでは、NFS のスケーラビリティーが改善されます。サーバーに pNFS が実装されると、クライアントは複数のサーバーで同時にデータにアクセスできるようになります。これにより、パフォーマンスが向上します。
pNFS は、RHEL では以下のストレージプロトコルまたはレイアウトに対応しています。
- ファイル
- Flexfiles
- SCSI
6.2. pNFS SCSI レイアウト
SCSI レイアウトは、pNFS ブロックレイアウトの作業に基づいています。このレイアウトは、SCSI デバイス全体に定義されます。これには、SCSI 永続予約に対応する必要がある論理ユニット (lUS) として、固定サイズのブロックが連続的に含まれています。LU デバイスは、SCSI デバイスの識別子で識別されます。
pNFS SCSI は、ファイルへの長期接続のシングルクライアントアクセスのユースケースで適切に実行されます。例として、メールサーバーまたはクラスターを格納している仮想マシンなどが挙げられます。
クライアントとサーバーとの間の操作
NFS クライアントが、ファイルからの読み取り、またはファイルへの書き込みを行うと、クライアントは LAYOUTGET
操作を実行します。サーバーは、SCSI デバイスのファイルの場所に反応します。このクライアントは、使用する SCSI デバイスを判断するために、GETDEVICEINFO
の追加操作が必要になる場合があります。正しく動作するのであれば、クライアントは、READ
操作および WRITE
操作をサーバーに送信する代わりに、SCSI デバイスに直接 I/O 要求を発行することができます。
クライアント間のエラーまたは競合により、サーバーがレイアウトを再び呼び出したり、クライアントにレイアウトを発行しなくなることがあります。この場合、クライアントは、SCSI デバイスに I/O 要求を直接送信するのではなく、サーバーへの READ
操作および WRITE
操作を再び実行します。
操作を監視するには、「pNFS SCSI レイアウト機能の監視」 を参照してください。
デバイスの予約
pNFS SCSI は、予約の割り当てを通じてフェンシングを処理します。サーバーがレイアウトをクライアントに発行する前に、SCSI デバイスを予約して、登録したクライアントのみがデバイスにアクセスできるようにします。クライアントが、その SCSI デバイスに対してコマンドを実行できても、そのデバイスに登録されていない場合は、クライアントからの多くの操作が、そのデバイス上で失敗します。たとえば、サーバーが、そのデバイスのレイアウトをクライアントに送信していないと、クライアントの blkid
コマンドは、XFS ファイルシステムの UUID を表示できません。
サーバーは、独自の永続予約を削除しません。これにより、クライアントやサーバーの再起動時に、デバイスのファイルシステム内のデータが保護されます。SCSI デバイスを他の目的で使用するには、NFS サーバーで、手動で永続予約を削除する必要があります。
6.3. pNFS と互換性がある SCSI デバイスの確認
この手順では、SCSI デバイスが pNFS SCSI レイアウトに対応しているかどうかを確認します。
前提条件
以下のコマンドで、
sg3-utils
パッケージがインストールされている。# yum install sg3_utils
手順
サーバーおよびクライアントの両方で、適切な SCSI デバイスサポートを確認します。
# sg_persist --in --report-capabilities --verbose path-to-scsi-device
Persist Through Power Loss Active (
PTPL_A
) ビットが設定されるようにします。例6.1 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
関連情報
-
man ページの
sg_persist(8)
6.4. サーバーで pNFS SCSI の設定
この手順では、NFS サーバーが pNFS SCSI レイアウトをエクスポートするように設定します。
手順
- サーバーで、SCSI デバイスで作成した XFS ファイルシステムをマウントします。
NFS バージョン 4.1 以降をエクスポートするように NFS サーバーを設定します。
/etc/nfs.conf
ファイルの[nfsd]
セクションに、以下のオプションを設定します。[nfsd] vers4.1=y
pnfs
オプションを指定して、NFS で XFS ファイルシステムをエクスポートするように NFS サーバーを設定します。例6.2 pNFS SCSI をエクスポートする /etc/exports のエントリー
/etc/exports
設定ファイルの以下のエントリーにより、/exported/directory/
にマウントされているファイルシステムを、pNFS SCSI レイアウトとしてallowed.example.com
クライアントにエクスポートします。/exported/directory allowed.example.com(pnfs)
関連情報
- NFS サーバーの設定に関する詳細は、4章NFS 共有のエクスポート を参照してください。
6.5. クライアントで pNFS SCSI の設定
この手順では、pNFS SCSI レイアウトをマウントするように NFS クライアントを設定します。
前提条件
- NFS サーバーは、pNFS SCSI で XFS ファイルシステムをエクスポートするように設定されています。Bug 1891591 を参照してください。「サーバーで pNFS SCSI の設定」
手順
クライアントで、NFS バージョン 4.1 以降を使用して、エクスポートした XFS ファイルシステムをマウントします。
# mount -t nfs -o nfsvers=4.1 host:/remote/export /local/directory
NFS なしで XFS ファイルシステムを直接マウントしないでください。
関連情報
- NFS 共有のマウントの詳細は、3章NFS 共有のマウント を参照してください。
6.6. サーバーでの pNFS SCSI 予約の解放
この手順では、NFS サーバーが SCSI デバイスを維持している永続的な予約を解放します。これにより、pNFS SCSI をエクスポートする必要がなくなったら、SCSI デバイスを別の目的で使用できるようになります。
サーバーから予約を削除する必要があります。別の IT Nexus から削除することはできません。
前提条件
以下のコマンドで、
sg3-utils
パッケージがインストールされている。# yum install sg3_utils
手順
サーバーで、既存の予約をクエリーします。
# sg_persist --read-reservation path-to-scsi-device
例6.3 /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
サーバーにある既存の登録を削除します。
# sg_persist --out \ --release \ --param-rk=reservation-key \ --prout-type=6 \ path-to-scsi-device
例6.4 /dev/sda にある予約の削除
# sg_persist --out \ --release \ --param-rk=0x100000000000000 \ --prout-type=6 \ /dev/sda LIO-ORG block_1 4.0 Peripheral device type: disk
関連情報
-
man ページの
sg_persist(8)
6.7. pNFS SCSI レイアウト機能の監視
pNFS クライアントとサーバーで、pNFS SCSI 操作が適切に行われることを犠牲にしているかどうか、または通常の NFS 操作にフォールバックするかどうかを監視できます。
前提条件
- pNFS SCSI クライアントとサーバーが設定されている。
6.7.1. nfsstat でサーバーの pNFS SCSI 操作の確認
この手順では、nfsstat
ユーティティを使用して、サーバーから pNFS SCSI 操作を監視します。
手順
サーバーから操作サービスを監視します。
# 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%
クライアントとサーバーは、以下の場合に pNFS SCSI 操作を使用します。
-
layoutget
カウンター、layoutreturn
カウンター、およびlayoutcommit
カウンターがインクリメントします。これは、サーバーがレイアウトを提供することを意味します。 -
サーバーの
read
カウンターおよびwrite
カウンターはインクリメントしません。これは、クライアントが SCSI デバイスに直接 I/O 要求を実行していることを意味します。
-
6.7.2. mountstats でクライアントからの pNFS SCSI 操作の確認
この手順では、/proc/self/mountstats
ファイルを使用して、クライアントから pNFS SCSI 操作を監視します。
手順
マウントごとの操作カウンターを一覧表示します。
# 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
結果は以下のようになります。
-
LAYOUT
統計は、クライアントとサーバーが pNFS SCSI 操作を使用する要求を示します。 -
READ
およびWRITE
の統計は、クライアントとサーバーが NFS 操作にフォールバックする要求を示します。
-
第7章 FS-Cache の使用
FS-Cache は、ファイルシステムがネットワーク経由で取得したデータをローカルディスクにキャッシュするために使用できる永続的なローカルキャッシュです。これは、ネットワーク経由でマウントされたファイルシステムからデータにアクセスするユーザーのネットワークトラフィックを最小限に抑えます (例: NFS)。
7.1. FS-Cache の概要
以下の図は、FS-Cache の仕組みの概要を示しています。
図7.1 FS-Cache の概要
FS-Cache は、システムのユーザーおよび管理者が可能な限り透過的になるように設計されています。Solaris では cachefs
とは異なり、サーバー上のファイルシステムは、オーバーマウントしたファイルシステムを作成せずに、クライアントのローカルキャッシュと直接対話できます。NFS では、マウントオプションにより、FS-cache が有効になっている NFS 共有をマウントするようにクライアントに指示します。マウントポイントにより、fscache
と cachefiles
の 2 つのカーネルモジュールの自動アップロードが実行します。cachefilesd
デーモンは、カーネルモジュールと通信してキャッシュを実装します。
FS-Cache はネットワーク上で機能するファイルシステムの基本操作を変更せず、単にデータをキャッシュできる永続的な場所でファイルシステムを提供するだけです。たとえば、クライアントは FS-Cache が有効になっているかどうかに関わらず、NFS 共有をマウントできます。さらに、キャッシュされた NFS は、ファイルが部分的にキャッシュされ、事前完全に読み込む必要がないため、ファイル (個別または一括) に収まらないファイルを処理できます。また、FS-Cache は、クライアントファイルシステムドライバーからキャッシュで発生するすべての I/O エラーも非表示にします。
キャッシングサービスを提供するには、キャッシュバックエンド が必要です。キャッシュバックエンドは、cachefiles
であるキャッシングサービスを提供するように設定されたストレージドライバーです。この場合、FS-Cache では、キャッシュバックエンドとして bmap
および拡張属性 (ext3 など) に対応するブロックベースのファイルシステムをマウントする必要があります。
FS-Cache のキャッシュバックエンドで必要とされる機能に対応するファイルシステムには、以下のファイルシステムの Red Hat Enterprise Linux 8 実装が含まれます。
- ext3 (拡張属性が有効)
- ext4
- XFS
FS-Cache は、ネットワークを介するかどうかに関係なく、ファイルシステムを任意にキャッシュすることはできません。共有ファイルシステムのドライバーを変更して、FS-Cache、データストレージ/検索、メタデータのセットアップと検証を操作できるようにする必要があります。FS-Cache では、永続性に対応するためにキャッシュされたファイルシステムの インデックスキー と 一貫性データ が必要になります。インデックスキーはファイルシステムオブジェクトをキャッシュオブジェクトに一致させ、一貫性データを使用してキャッシュオブジェクトが有効のままかどうかを判断します。
Red Hat Enterprise Linux 8 では、cachefilesd パッケージはデフォルトでインストールされていないため、手動でインストールする必要があります。
7.2. パフォーマンスに関する保証
FS-Cache は、パフォーマンスの向上を 保証しません。キャッシュを使用するとパフォーマンスが低下します。たとえば、キャッシュされた NFS 共有では、ネットワーク間のルックアップにディスクアクセスが追加されます。FS-Cache は可能な限り非同期となりますが、これができない同期パス (読み込みなど) があります。
たとえば、FS-Cache を使用して、通常は負荷のない GigE ネットワークを介して 2 台のコンピューター間の NFS 共有をキャッシュしても、ファイルアクセスのパフォーマンスは向上しない可能性があります。代わりに、NFS 要求はローカルディスクからではなく、サーバーメモリーより早く満たされます。
したがって、FS-Cacheの使用は、さまざまな要因における 妥協 です。たとえば、NFS トラフィックのキャッシュに FS-Cache を使用すると、クライアントは多少遅くなりますが、ネットワークの帯域幅を消費せずにローカルに読み取り要求を満たすことでネットワークおよびサーバーの読み込み負荷が大幅に削減されます。
7.3. キャッシュの設定
現在、Red Hat Enterprise Linux 8 は cachefiles
キャッシュバックエンドのみを提供します。cachefilesd
デーモンは cachefiles
を開始し、管理します。/etc/cachefilesd.conf
ファイルは、cachefiles
によるキャッシュサービスの提供方法を制御します。
キャッシュバックエンドは、キャッシュをホストしているパーティション上の一定の空き領域を維持することで動作します。空き領域を使用する他の要素に応じてキャッシュを増大および縮小し、root ファイルシステム (ラップトップなど) で安全に使用できるようにします。FS-Cache ではこの動作でデフォルト値を設定し、キャッシュカリング制限 で設定できます。キャッシュカリング制限の設定に関する詳細は、「キャッシュカリング制限の設定」 を参照してください。
この手順では、キャッシュを設定する方法を説明します。
前提条件
cachefilesd パッケージがインストールされ、サービスが正常に起動しました。サービスが実行中であることを確認するには、次のコマンドを使用します。
# systemctl start cachefilesd # systemctl status cachefilesd
ステータスは active (running) である必要があります。
手順
キャッシュとして使用するディレクトリーをキャッシュバックエンドで設定するには、次のパラメーターを使用します。
$ dir /path/to/cache
一般的に、キャッシュバックエンドディレクトリーは、以下のように
/etc/cachefilesd.conf
内に/var/cache/fscache
として設定されます。$ dir /var/cache/fscache
キャッシュバックエンドのディレクトリーを変更する場合、selinux コンテキストは
/var/cache/fscache
と同じである必要があります。# semanage fcontext -a -e /var/cache/fscache /path/to/cache # restorecon -Rv /path/to/cache
- キャッシュを設定する際に、/path/to/cache をディレクトリー名に置き換えます。
selinux コンテキストを設定するコマンドが機能しない場合は、以下のコマンドを使用します。
# semanage permissive -a cachefilesd_t # semanage permissive -a cachefiles_kernel_t
FS-Cache は、
/path/to/cache
をホストするファイルシステムにキャッシュを保存します。ラップトップでは、root ファイルシステム (/
) をホストのファイルシステムとして使用することが推奨されますが、デスクトップマシンの場合は、キャッシュ専用のディスクパーティションをマウントするより慎重に行ってください。ホストファイルシステムはユーザー定義の拡張属性に対応する必要があります。FS-Cache はこの属性を使用して、整合性のメンテナンス情報を保存します。ext3 ファイルシステムのユーザー定義の拡張属性を有効にする(つまり)。
デバイス
、以下を使用します。# tune2fs -o user_xattr /dev/device
代わりに、マウント時にファイルシステムの拡張属性を有効にするには、次のコマンドを使用します。
# mount /dev/device /path/to/cache -o user_xattr
設定ファイルを置いたら、
cachefilesd
サービスを起動します。# systemctl start cachefilesd
起動時に
cachefilesd
が起動するように設定するには、root で次のコマンドを実行します。# systemctl enable cachefilesd
7.4. NFS でのキャッシュの使用
明示的に指示されない限り、NFS はキャッシュを使用しません。ここでは、FS-Cache を使用して NFS マウントを設定する方法を説明します。
前提条件
cachefilesd パッケージがインストールされ、実行している。これを実行していることを確認するには、次のコマンドを使用します。
# systemctl start cachefilesd # systemctl status cachefilesd
ステータスは active (running) である必要があります。
以下のオプションで NFS 共有をマウントします。
# mount nfs-share:/ /mount/point -o fsc
ファイルがダイレクト I/O や書き込みのために開いていない限り、
/mount/point
の下にあるファイルへのアクセスはすべてキャッシュを経由します。詳細は、「NFS でのキャッシュの制限」 を参照してください。NFS インデックスは NFS ファイルハンドルを使用してコンテンツをキャッシュします。ファイル名ではなく、ハードリンクされたファイルはキャッシュを正しく共有します。
NFS バージョン 3、4.0、4.1、および 4.2 はキャッシュに対応します。ただし、各バージョンはキャッシュに異なるブランチを使用します。
7.4.1. NFS キャッシュ共有の設定
NFS キャッシュの共有には潜在的な問題がいくつかあります。キャッシュは永続的であるため、キャッシュ内のデータブロックは 4 つのキーのシーケンスでインデックス化されます。
- レベル 1: サーバーの詳細
- レベル 2: 一部のマウントオプション、セキュリティータイプ、FSID、識別子
- レベル 3: ファイルハンドル
- レベル 4: ファイル内のページ番号
スーパーブロック間の整合性の管理に関する問題を回避するには、データのキャッシュを必要とする NFS のすべてのスーパーブロックに、固有のレベル 2 キーを設定します。通常、同じソースボリュームとオプションを持つ 2 つの NFS マウントはスーパーブロックを共有しているため、そのボリューム内に異なるディレクトリーをマウントする場合でもキャッシュを共有することになります。
以下は、異なるオプションでキャッシュ共有を設定する方法の例になります。
手順
次のコマンドで NFS 共有をマウントします。
mount home0:/disk0/fred /home/fred -o fsc mount home0:/disk0/jim /home/jim -o fsc
/home/fred
および/home/jim
には同じオプションがあるため、スーパーブロックを共有する可能性が高くなります。特に NFS サーバー上の同じボリュームやパーティションから作成されている場合は共有する可能性が高くなります (home0
)。スーパーブロックを共有しないようにするには、
mount
コマンドに以下のオプションを付けて実行します。mount home0:/disk0/fred /home/fred -o fsc,rsize=8192 mount home0:/disk0/jim /home/jim -o fsc,rsize=65536
この場合、
/home/fred
と/home/jim
は、レベル 2 キーの異なるネットワークアクセスパラメーターを持つため、スーパーブロックを共有しません。2 つのサブツリー (
/home/fred1
と/home/fred2
) のコンテンツを 2 回 キャッシュしてスーパーブロックを共有しないようにするには、次のコマンドを使用します。mount home0:/disk0/fred /home/fred1 -o fsc,rsize=8192 mount home0:/disk0/fred /home/fred2 -o fsc,rsize=65536
スーパーブロックの共有を回避するもう 1 つの方法は、
nosharecache
パラメーターで明示的に共有を回避することです。同じ例を使用します。mount home0:/disk0/fred /home/fred -o nosharecache,fsc mount home0:/disk0/jim /home/jim -o nosharecache,fsc
ただし、この場合は、レベル 2 キーの
home0:/disk0/fred
およびhome0:/disk0/jim
を区別することができないため、使用できるスーパーブロックは 1 つだけとなります。スーパーブロックにアドレスを指定するには、少なくとも 1 つのマウントに 一意の識別子 を追加します(つまり)。
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
が追加されます。
ユーザーは、異なる通信またはプロトコルパラメーターを持つスーパーブロック間でキャッシュを共有することはできません。たとえば、NFSv4.0 と NFSv3 の間、NFSv4.1 と NFSv4.2 間で共有することはできません。これは、強制されるスーパーブロックが異なるためです。また、読み込みサイズ (rsize) などのパラメーターを設定すると、キャッシュの共有が回避されます。これは、別のスーパーブロックを強制するためです。
7.4.2. NFS でのキャッシュの制限
NFS にはキャッシュの制限がいくつかあります。
- ダイレクト I/O で共有ファイルシステムからファイルを開くと、自動的にキャッシュが回避されます。これは、この種のアクセスがサーバーに直接行なわれる必要があるためです。
- ダイレクト I/O または書き込みのいずれかで共有ファイルシステムからファイルを開くと、キャッシュされたファイルのコピーがフラッシュされます。ダイレクト I/O や書き込みのためにファイルが開かれなくなるまで、FS-Cache はファイルを再キャッシュしません。
- さらに、FS-Cache の今回のリリースでは、通常の NFS ファイルのみをキャッシュします。FS-Cache はディレクトリー、シンボリックリンク、デバイスファイル、FIFO、ソケットを キャッシュしません。
7.5. キャッシュカリング制限の設定
cachefilesd
デーモンは、共有ファイルシステムからのリモートデータをキャッシュして、ディスクの空き領域を解放することで機能します。これにより、利用可能な空き領域がすべて消費される可能性があり、ディスクがルートパーティションも格納している場合は問題になる可能性があります。これを制御するために、cachefilesd
は古いオブジェクト (つまり最近のアクセスが少ないオブジェクト) をキャッシュから破棄して、一定量の空き領域を維持しようとします。この動作は キャッシュカリング と呼ばれます。
キャッシュカリングは、基盤となるファイルシステムで使用可能なブロックのパーセンテージとファイルのパーセンテージに基づいて行われます。/etc/cachefilesd.conf
には、6 つの制限を制御する設定が存在します。
- brun N% (ブロックのパーセンテージ)、frun N% (ファイルのパーセンテージ)
- キャッシュの空き領域と利用可能なファイルの数がこれらの制限を上回ると、カリングはオフになります。
- bcull N% (ブロックのパーセンテージ)、fcull N% (ファイルのパーセンテージ)
- キャッシュの空き領域と利用可能なファイルの数がこれらの制限のいずれかを下回ると、カリング動作が開始します。
- bstop N% (ブロックのパーセンテージ)、fstop N% (ファイルのパーセンテージ)
- キャッシュ内の使用可能な領域または使用可能なファイルの数がこの制限のいずれかを下回ると、カリングによってこれらの制限を超える状態になるまで、ディスク領域またはファイルのそれ以上の割り当ては許可されません。
各設定の N
のデフォルト値は以下の通りです。
-
brun
/frun
- 10% -
bcull
/fcull
- 7% -
bstop
/fstop
- 3%
この設定を行う場合は、以下の条件を満たす必要があります。
-
0 ≤
bstop
<bcull
<brun
< 100 -
0 ≤
fstop
<fcull
<frun
< 100
これは、空き領域と利用可能なファイルの割合であり、100 から、df
プログラムで表示される割合を引いたものではありません。
カリングは、bxxx と fxxx のペアを同時に依存します。ユーザーが個別に処理することはできません。
7.6. fscache カーネルモジュールからの統計情報の取得
FS-Cache は一般的な統計情報も追跡します。以下の手順では、この情報を取得する方法を説明します。
手順
FS-Cache の統計情報を表示するには、次のコマンドを使用します。
# cat /proc/fs/fscache/stats
FS-Cache の統計にはディシジョンポイントとオブジェクトカウンターに関する情報が含まれます。詳細は、以下のカーネルドキュメントを参照してください。
/usr/share/doc/kernel-doc-4.18.0/Documentation/filesystems/caching/fscache.txt
7.7. FS-Cache の参考資料
本セクションでは、FS-Cache の参考情報を詳細します。
cachefilesd
の詳細および設定方法は、man cachefilesd
およびman cachefilesd.conf
を設定してください。その他にも、以下のカーネルドキュメントを参照してください。-
/usr/share/doc/cachefilesd/README
-
/usr/share/man/man5/cachefilesd.conf.5.gz
-
/usr/share/man/man8/cachefilesd.8.gz
-
設計上の制約、利用可能な統計、機能など、FS-Cache に関する一般的な情報は、以下のカーネルドキュメントを参照してください。
/usr/share/doc/kernel-doc-4.18.0/Documentation/filesystems/caching/fscache.txt
第9章 永続的な命名属性の概要
システム管理者は、永続的な命名属性を使用してストレージボリュームを参照し、再起動を何度も行っても信頼できるストレージ設定を構築する必要があります。
9.1. 非永続的な命名属性のデメリット
Red Hat Enterprise Linux では、ストレージデバイスを識別する方法が複数あります。特にドライブへのインストール時やドライブの再フォーマット時に誤ったデバイスにアクセスしないようにするため、適切なオプションを使用して各デバイスを識別することが重要になります。
従来、/dev/sd(メジャー番号)(マイナー番号)
の形式の非永続的な名前は、ストレージデバイスを参照するために Linux 上で使用されます。メジャー番号とマイナー番号の範囲、および関連する sd
名は、検出されると各デバイスに割り当てられます。つまり、デバイスの検出順序が変わると、メジャー番号とマイナー番号の範囲、および関連する sd
名の関連付けが変わる可能性があります。
このような順序の変更は、以下の状況で発生する可能性があります。
- システム起動プロセスの並列化により、システム起動ごとに異なる順序でストレージデバイスが検出された場合。
-
ディスクが起動しなかったり、SCSI コントローラーに応答しなかった場合。この場合は、通常のデバイスプローブにより検出されません。ディスクはシステムにアクセスできなくなり、後続のデバイスは関連する次の
sd
名が含まれる、メジャー番号およびマイナー番号の範囲があります。たとえば、通常sdb
と呼ばれるディスクが検出されないと、sdc
と呼ばれるディスクがsdb
として代わりに表示されます。 -
SCSI コントローラー (ホストバスアダプターまたは HBA) が初期化に失敗し、その HBA に接続されているすべてのディスクが検出されなかった場合。後続のプローブされた HBA に接続しているディスクは、別のメジャー番号およびマイナー番号の範囲、および関連する別の
sd
名が割り当てられます。 - システムに異なるタイプの HBA が存在する場合は、ドライバー初期化の順序が変更する可能性があります。これにより、HBA に接続されているディスクが異なる順序で検出される可能性があります。また、HBA がシステムの他の PCI スロットに移動した場合でも発生する可能性があります。
-
ストレージアレイや干渉するスイッチの電源が切れた場合など、ストレージデバイスがプローブされたときに、ファイバーチャネル、iSCSI、または FCoE アダプターを持つシステムに接続されたディスクがアクセスできなくなる可能性があります。システムが起動するまでの時間よりもストレージアレイがオンラインになるまでの時間の方が長い場合に、電源の障害後にシステムが再起動すると、この問題が発生する可能性があります。一部のファイバーチャネルドライバーは WWPN マッピングへの永続 SCSI ターゲット ID を指定するメカニズムをサポートしますが、メジャー番号およびマイナー番号の範囲や関連する
sd
名は予約されず、一貫性のある SCSI ターゲット ID 番号のみが提供されます。
そのため、/etc/fstab
ファイルなどにあるデバイスを参照するときにメジャー番号およびマイナー番号の範囲や関連する sd
名を使用することは望ましくありません。誤ったデバイスがマウントされ、データが破損する可能性があります。
しかし、場合によっては他のメカニズムが使用される場合でも sd
名の参照が必要になる場合もあります (デバイスによりエラーが報告される場合など)。これは、Linux カーネルはデバイスに関するカーネルメッセージで sd
名 (および SCSI ホスト、チャネル、ターゲット、LUN タプル) を使用するためです。
9.2. ファイルシステムおよびデバイスの識別子
このセクションでは、ファイルシステムおよびブロックデバイスを識別する永続的な属性の相違点を説明します。
ファイルシステムの識別子
ファイルシステムの識別子は、ブロックデバイス上に作成された特定のファイルシステムに関連付けられます。識別子はファイルシステムの一部としても格納されます。ファイルシステムを別のデバイスにコピーしても、ファイルシステム識別子は同じです。一方、mkfs
ユーティリティーでフォーマットするなどしてデバイスを書き換えると、デバイスはその属性を失います。
ファイルシステムの識別子に含まれるものは、次のとおりです。
- 一意の ID (UUID)
- ラベル
デバイスの識別子
デバイス識別子は、ブロックデバイス (ディスクやパーティションなど) に関連付けられます。mkfs
ユーティリティーでフォーマットするなどしてデバイスを書き換えた場合、デバイスはファイルシステムに格納されていないため、属性を保持します。
デバイスの識別子に含まれるものは、次のとおりです。
- World Wide Identifier (WWID)
- パーティション UUID
- シリアル番号
推奨事項
- 論理ボリュームなどの一部のファイルシステムは、複数のデバイスにまたがっています。Red Hat は、デバイスの識別子ではなくファイルシステムの識別子を使用してこのファイルシステムにアクセスすることをお勧めします。
9.3. /dev/disk/ にある udev メカニズムにより管理されるデバイス名
このセクションでは、udev
サービスが /dev/disk/
ディレクトリーで提供する、さまざまな種類の永続的な命名属性を説明します。
udev
メカニズムは、ストレージデバイスだけでなく、Linux のすべてのタイプのデバイスに使用されます。ストレージデバイスの場合、Red Hat Enterprise Linux には /dev/disk/
ディレクトリーにシンボリックリンクを作成する udev
ルールが含まれています。これにより、次の方法でストレージデバイスを参照できます。
- ストレージデバイスのコンテンツ
- 一意の ID
- シリアル番号
udev
の命名属性は永続的なものですが、システムを再起動しても自動的には変更されないため、設定可能なものもあります。
9.3.1. ファイルシステムの識別子
/dev/disk/by-uuid/ の UUID 属性
このディレクトリーのエントリーは、デバイスに格納されているコンテンツ (つまりデータ) 内の 一意の ID (UUID) によりストレージデバイスを参照するシンボリック名を提供します。以下に例を示します。
/dev/disk/by-uuid/3e6be9de-8139-11d1-9106-a43f08d823a6
次の構文を使用することで、UUID を使用して /etc/fstab
ファイルのデバイスを参照できます。
UUID=3e6be9de-8139-11d1-9106-a43f08d823a6
ファイルシステムを作成する際に UUID 属性を設定できます。後で変更することもできます。
/dev/disk/by-label/ のラベル属性
このディレクトリーのエントリーは、デバイスに格納されているコンテンツ (つまりデータ) 内の ラベル により、ストレージデバイスを参照するシンボリック名を提供します。
以下に例を示します。
/dev/disk/by-label/Boot
次の構文を使用することで、ラベルを使用して /etc/fstab
ファイルのデバイスを参照できます。
LABEL=Boot
ファイルシステムを作成するときにラベル属性を設定できます。また、後で変更することもできます。
9.3.2. デバイスの識別子
/dev/disk/by-id/ の WWID 属性
World Wide Identifier (WWID) は永続的で、SCSI 規格によりすべての SCSI デバイスが必要とする システムに依存しない識別子 です。各ストレージデバイスの WWID 識別子は一意となることが保証され、デバイスのアクセスに使用されるパスに依存しません。この識別子はデバイスのプロパティですが、デバイスのコンテンツ (つまりデータ) には格納されません。
この識別子は、SCSI Inquiry を発行して Device Identification Vital Product Data (0x83
ページ) または Unit Serial Number (0x80
ページ) を取得することにより獲得できます。
Red Hat Enterprise Linux では、WWID ベースのデバイス名から、そのシステムの現在の /dev/sd
名への正しいマッピングを自動的に維持します。デバイスへのパスが変更したり、別のシステムからそのデバイスへのアクセスがあった場合にも、アプリケーションはディスク上のデータ参照に /dev/disk/by-id/
を使用できます。
例9.1 WWID マッピング
WWID シンボリックリンク | 非永続的なデバイス | 備考 |
---|---|---|
|
|
ページ |
|
|
ページ |
|
| ディスクパーティション |
システムにより提供される永続的な名前のほかに、udev
ルールを使用して独自の永続的な名前を実装し、ストレージの WWID にマップすることもできます。
/dev/disk/by-partuuid のパーティション UUID 属性
パーティション UUID (PARTUUID) 属性は、GPT パーティションテーブルにより定義されているパーティションを識別します。
例9.2 パーティション UUID のマッピング
PARTUUID シンボリックリンク | 非永続的なデバイス |
---|---|
|
|
|
|
|
|
/dev/disk/by-path/ のパス属性
この属性は、デバイスへのアクセスに使用される ハードウェアパス がストレージデバイスを参照するシンボル名を提供します。
ハードウェアパス (PCI ID、ターゲットポート、LUN 番号など) の一部が変更されると、パス属性に失敗します。このため、パス属性は信頼性に欠けます。ただし、パス属性は以下のいずれかのシナリオで役に立ちます。
- 後で置き換える予定のディスクを特定する必要があります。
- 特定の場所にあるディスクにストレージサービスをインストールする予定です。
9.4. DM Multipath を使用した World Wide Identifier
このセクションでは、Device Mapper Multipath 構成における World Wide Identifier (WWID) と非永続的なデバイス名のマッピングを説明します。
システムからデバイスへのパスが複数ある場合、DM Multipath はこれを検出するために WWID を使用します。その後、DM Multipath は /dev/mapper/wwid
ディレクトリー (例: /dev/mapper/3600508b400105df70000e00000ac0000
) に単一の「疑似デバイス」を表示します。
コマンド multipath -l
は、非永続的な識別子へのマッピングを示します。
-
Host:Channel:Target:LUN
-
/dev/sd
名 -
major:minor
数値
例9.3 マルチパス構成での WWID マッピング
multipath -l
コマンドの出力例
3600508b400105df70000e00000ac0000 dm-2 vendor,product [size=20G][features=1 queue_if_no_path][hwhandler=0][rw] \_ round-robin 0 [prio=0][active] \_ 5:0:1:1 sdc 8:32 [active][undef] \_ 6:0:1:1 sdg 8:96 [active][undef] \_ round-robin 0 [prio=0][enabled] \_ 5:0:0:1 sdb 8:16 [active][undef] \_ 6:0:0:1 sdf 8:80 [active][undef]
DM Multipath は、各 WWID ベースのデバイス名から、システムで対応する /dev/sd
名への適切なマッピングを自動的に維持します。これらの名前は、パスが変更しても持続し、他のシステムからデバイスにアクセスする際に一貫性を保持します。
DM Multipath の user_friendly_names
機能を使用すると、WWID は /dev/mapper/mpathN
形式の名前にマップされます。デフォルトでは、このマッピングは /etc/multipath/bindings
ファイルに保持されています。これらの mpathN
名は、そのファイルが維持されている限り永続的です。
user_friendly_names
を使用する場合は、クラスター内で一貫した名前を取得するために追加の手順が必要です。
9.5. udev デバイス命名規則の制約
udev
命名規則の制約の一部は次のとおりです。
-
udev
イベントに対してudev
ルールが処理されるときに、udev
メカニズムはストレージデバイスをクエリーする機能に依存する可能性があるため、クエリーの実行時にデバイスにアクセスできない可能性があります。これは、ファイバーチャネル、iSCSI、または FCoE ストレージデバイスといった、デバイスがサーバーシャーシにない場合に発生する可能性が高くなります。 -
カーネルは
udev
イベントをいつでも送信する可能性があるため、デバイスにアクセスできない場合に/dev/disk/by-*/
リンクが削除される可能性があります。 -
udev
イベントが生成されそのイベントが処理されるまでに遅延が生じる場合があります (大量のデバイスが検出され、ユーザー空間のudev
サービスによる各デバイスのルールを処理するのにある程度の時間がかかる場合など)。これにより、カーネルがデバイスを検出してから、/dev/disk/by-*/
の名前が利用できるようになるまでに遅延が生じる可能性があります。 -
ルールに呼び出される
blkid
などの外部プログラムによってデバイスが短期間開き、他の目的でデバイスにアクセスできなくなる可能性があります。 -
/dev/disk/ の
udev
メカニズムで管理されるデバイス名は、メジャーリリース間で変更される可能性があるため、リンクの更新が必要になる場合があります。
9.6. 永続的な命名属性の一覧表示
この手順では、非永続的なストレージデバイスの永続命名属性を確認する方法を説明します。
手順
UUID 属性とラベル属性を一覧表示するには、
lsblk
ユーティリティーを使用します。$ lsblk --fs storage-device
以下に例を示します。
例9.4 ファイルシステムの UUID とラベルの表示
$ lsblk --fs /dev/sda1 NAME FSTYPE LABEL UUID MOUNTPOINT sda1 xfs Boot afa5d5e3-9050-48c3-acc1-bb30095f3dc4 /boot
PARTUUID 属性を一覧表示するには、
--output +PARTUUID
オプションを指定してlsblk
ユーティリティーを使用します。$ lsblk --output +PARTUUID
以下に例を示します。
例9.5 パーティションの PARTUUID 属性の表示
$ lsblk --output +PARTUUID /dev/sda1 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT PARTUUID sda1 8:1 0 512M 0 part /boot 4cd1448a-01
WWID 属性を一覧表示するには、
/dev/disk/by-id/
ディレクトリーのシンボリックリンクのターゲットを調べます。以下に例を示します。例9.6 システムにある全ストレージデバイスの WWID の表示
$ file /dev/disk/by-id/* /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001 symbolic link to ../../sda /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 symbolic link to ../../sda1 /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2 symbolic link to ../../sda2 /dev/disk/by-id/dm-name-rhel_rhel8-root symbolic link to ../../dm-0 /dev/disk/by-id/dm-name-rhel_rhel8-swap symbolic link to ../../dm-1 /dev/disk/by-id/dm-uuid-LVM-QIWtEHtXGobe5bewlIUDivKOz5ofkgFhP0RMFsNyySVihqEl2cWWbR7MjXJolD6g symbolic link to ../../dm-1 /dev/disk/by-id/dm-uuid-LVM-QIWtEHtXGobe5bewlIUDivKOz5ofkgFhXqH2M45hD2H9nAf2qfWSrlRLhzfMyOKd symbolic link to ../../dm-0 /dev/disk/by-id/lvm-pv-uuid-atlr2Y-vuMo-ueoH-CpMG-4JuH-AhEF-wu4QQm symbolic link to ../../sda2
9.7. 永続的な命名属性の変更
この手順では、ファイルシステムの UUID またはラベルの永続的な命名属性を変更する方法を説明します。
udev
属性の変更はバックグラウンドで行われ、時間がかかる場合があります。udevadm settle
コマンドは変更が完全に登録されるまで待機します。これにより、次のコマンドが新しい属性を正しく利用できるようになります。
以下のコマンドでは、次を行います。
-
new-uuid を、設定する UUID (例:
1cdfbc07-1c90-4984-b5ec-f61943f5ea50
) に置き換えます。uuidgen
コマンドを使用して UUID を生成できます。 -
new-label を、ラベル (例:
backup_data
) に置き換えます。
前提条件
- XFS ファイルシステムをアンマウントしている (XFS ファイルシステムの属性を変更する場合)。
手順
XFS ファイルシステムの UUID またはラベル属性を変更するには、
xfs_admin
ユーティリティーを使用します。# xfs_admin -U new-uuid -L new-label storage-device # udevadm settle
ext4 ファイルシステム、ext3 ファイルシステム、ext2 ファイルシステムの UUID またはラベル属性を変更するには、
tune2fs
ユーティリティーを使用します。# tune2fs -U new-uuid -L new-label storage-device # udevadm settle
スワップボリュームの UUID またはラベル属性を変更するには、
swaplabel
ユーティリティーを使用します。# swaplabel --uuid new-uuid --label new-label swap-device # udevadm settle
第10章 パーティションの使用
システム管理者は、以下の手順に従ってさまざまな種類のディスクパーティションを作成、削除、および変更できます。
ブロックデバイスでパーティションを使用する長所と短所の概要は、ナレッジベースの記事 https://access.redhat.com/solutions/163853 を参照してください。
10.1. パーティションテーブルの表示
システム管理者は、ブロックデバイスのパーティションテーブルを表示して、パーティションレイアウトと個々のパーティションに関する詳細を確認できます。
10.1.1. parted でパーティションテーブルの表示
この手順では、parted
ユーティリティーを使用してブロックデバイスのパーティションテーブルを表示する方法を説明します。
手順
インタラクティブな
parted
シェルを起動します。# parted block-device
-
block-device を、調べるデバイスへのパス (例:
/dev/sda
) に置き換えます。
-
block-device を、調べるデバイスへのパス (例:
パーティションテーブルを表示します。
(parted) print
必要に応じて次のコマンドを使用して、次に調べるデバイスに切り替えることもできます。
(parted) select block-device
関連情報
-
man ページの
parted(8)
10.1.2. parted print
の出力例
このセクションでは、parted
シェルの print
コマンドの出力例を示し、出力内のフィールドを説明します。
例10.1 print
コマンドの出力
Model: ATA SAMSUNG MZNLN256 (scsi) Disk /dev/sda: 256GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 269MB 268MB primary xfs boot 2 269MB 34.6GB 34.4GB primary 3 34.6GB 45.4GB 10.7GB primary 4 45.4GB 256GB 211GB extended 5 45.4GB 256GB 211GB logical
以下は、フィールドの説明です。
Model: ATA SAMSUNG MZNLN256 (scsi)
- ディスクタイプ、製造元、モデル番号、およびインターフェース。
Disk /dev/sda: 256GB
- ブロックデバイスへのファイルパスとストレージ容量。
Partition Table: msdos
- ディスクラベルの種類。
Number
-
パーティション番号。たとえば、マイナー番号 1 のパーティションは、
/dev/sda1
に対応します。 Start
およびEnd
- デバイスにおけるパーティションの開始場所と終了場所。
Type
- 有効なタイプは、メタデータ、フリー、プライマリー、拡張、または論理です。
File system
-
ファイルシステムの種類。ファイルシステムの種類が不明な場合は、デバイスの
File system
フィールドに値が表示されません。parted
ユーティリティーは、暗号化されたデバイスのファイルシステムを認識できません。 Flags
-
パーティションのフラグ設定一覧。利用可能なフラグは、
boot
、root
、swap
、hidden
、raid
、lvm
、またはlba
です。
10.2. ディスクへのパーティションテーブルの作成
システム管理者は、ブロックデバイスでパーティションを使用できるように、さまざまな種類のパーティションテーブルを使用してそのブロックデバイスをフォーマットできます。
パーティションテーブルを使用してブロックデバイスをフォーマットすると、そのデバイスに保存されているすべてのデータが削除されます。
10.2.1. ディスクのパーティション変更前の留意事項
このセクションでは、パーティションの作成、削除、またはサイズ変更を行う前に考慮すべき重要な点を説明します。
このセクションでは、IBM Z アーキテクチャーに固有の DASD パーティションテーブルを説明しません。DASD の情報は、以下を参照してください。
- IBM Z への Linux インスタンスの設定
- IBM Knowledge Center の「What you should know about DASD」
パーティションの最大数
デバイスで使用できるパーティションの数は、パーティションテーブルの種類によって異なります。
マスターブートレコード (MBR) パーティションテーブルでフォーマットされたデバイスでは、次のいずれかの数だけパーティションを設定できます。
- 最大 4 つのプライマリーパーティション
- 最大 3 つのプライマリーパーティション、および 1 つの拡張パーティション、ならびにその拡張内に複数の論理パーティション
-
GUID パーティションテーブル (GPT) でフォーマットしたデバイスにおけるパーティションの最大数は 128 個です。GPT 仕様により、パーティションテーブル用に確保するエリアを拡大することで、さらに多くのパーティションを作成できますが、
parted
ユーティリティーで用いられる一般的な方法で得られるエリアは 128 個に制限されます。
Red Hat では、特に理由がない限り、少なくとも swap
、/boot/
、および /
(root) のパーティションを作成することが推奨されます。
パーティションの最大サイズ
デバイスのパーティションの最大サイズは、パーティションテーブルの種類により異なります。
- マスターブートレコード (MBR) パーティションテーブルでフォーマットしたデバイスの最大サイズは 2TiB になります。
- GUID パーティションテーブル (GPT) でフォーマットしたデバイスの最大サイズは 8ZiB になります。
2TiB を超えるパーティションを作成する場合は、ディスクを GPT でフォーマットする必要があります。
サイズ調整
parted
ユーティリティーを使用した場合は、パーティションサイズを指定する際の接尾辞を選択できます。
- MiB、GiB、または TiB
サイズは 2 のべき乗で表示されます。
- パーティションの開始点は、サイズが指定する正確なセクターに調整されます。
- 終了点は、指定されたサイズから 1 セクターを引いたサイズに調整されます。
- MB、GB、または TB
サイズは 10 のべき乗で表示されます。
開始点と終了点は、指定された単位の半分以内に置かれます。たとえば、接尾辞 MB を使用する場合は ±500 KB です。
10.2.2. パーティションテーブルの種類の比較
このセクションでは、ブロックデバイスに作成できるさまざまな種類のパーティションテーブルのプロパティーを比較します。
表10.1 パーティションテーブルの種類
パーティションテーブル | パーティションの最大数 | パーティションの最大サイズ |
---|---|---|
マスターブートレコード (MBR) | 4 つのプライマリー。または 3 つのプライマリーと、拡張パーティション内に 12 の論理 | 2TiB |
GUID パーティションテーブル (GPT) | 128 | 8ZiB |
10.2.3. MBR ディスクパーティション
本章の図では、パーティションテーブルが実際のディスクから分離されていることを示しています。ただし、これは完全に正確ではありません。実際には、パーティションテーブルは、ファイルシステムまたはユーザーデータの前のディスクの先頭に保管されますが、明確にするために以下の図で区切ります。
図10.1 MBR パーティションテーブルがあるディスク
上記の図で示したとおり、パーティションテーブルは 4 つのプライマリーパーティションの 4 つのセクションに分けられます。プライマリーパーティションは、論理ドライブ (またはセクション) を 1 つだけ含むことができるハードドライブのパーティションです。各セクションは、1 つのパーティションの定義に必要な情報を保持できます。つまり、パーティションテーブルでは 4 つのパーティションを定義できません。
各パーティションテーブルエントリーには、パーティションの重要な特徴がいくつか含まれています。
- パーティションが開始して終了するディスク上のポイント。
- パーティションが アクティブ であるかどうか。アクティブ としてフラグを付けることができるパーティションは 1 つだけです。
- パーティションのタイプ。
開始点と終了点は、パーティションのサイズとディスク上の場所を定義します。「active」フラグは、一部のオペレーティングシステムブートローダーで使用されます。つまり、「active」とマークされているパーティションのオペレーティングシステムが起動します。
タイプは、パーティションの想定される使用方法を特定する数字です。一部のオペレーティングシステムでは、パーティションの種類を使用して特定のファイルシステムの種類を示し、特定のオペレーティングシステムに関連付けられていることを示すフラグを付け、パーティションに起動可能なオペレーティングシステムが含まれていること、またはその 3 つの組み合わせを示します。
以下の図は、パーティションが 1 つあるドライブの例を示しています。
図10.2 1 つのパーティションを持つディスク
この例の 1 つのパーティションには、DOS
というラベルが付けられています。このラベルはパーティションタイプを表示し、DOS
は最も一般的なパーティションタイプです。
10.2.4. 拡張 MBR パーティション
4 つのパーティションがニーズに十分ではない場合は、拡張パーティションを使用して追加のパーティションを作成できます。これは、パーティションのタイプを「拡張」に設定することで実行できます。
拡張パーティションは、それ自体がディスクドライブのようなものです。拡張パーティション自体に完全に含まれる、1 つ以上のパーティション (4 つのプライマリパーティションではなく、現在は論理パーティションと呼ばれます) を指す独自のパーティションテーブルがあります。次の図は、1 つのプライマリパーティションと、2 つの論理パーティションを含む 1 つの拡張パーティション (およびいくつかの未パーティションの空き領域) を備えたディスクドライブを示しています。
図10.3 プライマリーパーティションと拡張 MBR パーティションの両方を備えたディスク
この図は示すように、プライマリーパーティションと論理パーティションには違いがあります。最大 4 つのプライマリーパーティションと拡張パーティションしか存在できませんが、存在できる論理パーティションの数には固定制限がありません。ただし、Linux でパーティションにアクセスする方法により、1 つのディスクドライブで 15 を超える論理パーティションを定義することはできません。
10.2.5. MBR パーティションタイプ
次の表は、一般的に使用される MBR パーティションタイプとそれらを表すために使用される 16 進数のリストです。
表10.2 MBR パーティションタイプ
MBR パーティションタイプ | 値 | MBR パーティションタイプ | 値 |
Empty | 00 | Novell Netware 386 | 65 |
DOS 12 ビット FAT | 01 | PIC/IX | 75 |
XENIX root | O2 | 旧 MINIX | 80 |
XENIX usr | O3 | Linux/MINUX | 81 |
DOS 16 ビット (32M 以下) | 04 | Linux swap | 82 |
Extended | 05 | Linux ネイティブ | 83 |
DOS 16 ビット (32 以上) | 06 | Linux 拡張 | 85 |
OS/2 HPFS | 07 | Amoeba | 93 |
AIX | 08 | Amoeba BBT | 94 |
AIX ブート可能 | 09 | BSD/386 | a5 |
OS/2 Boot Manager | 0a | OpenBSD | a6 |
Win95 FAT32 | 0b | NEXTSTEP | a7 |
Win95 FAT32 (LBA) | 0c | BSDI fs | b7 |
Win95 FAT16 (LBA) | 0e | BSDI swap | b8 |
Win95 Extended (LBA) | 0f | Syrinx | c7 |
Venix 80286 | 40 | CP/M | db |
Novell | 51 | DOS アクセス | e1 |
PRep Boot | 41 | DOS R/O | e3 |
GNU HURD | 63 | DOS セカンダリー | f2 |
Novell Netware 286 | 64 | BBT | ff |
10.2.6. GUID パーティションテーブル
GUID パーティションテーブル (GPT) は、Globally Unique Identifier (GUID) を使用したパーティション設定スキームです。GPT は、特にディスクのアドレス可能な最大ストレージ容量に制限されている MBR パーティションテーブルの制限に対応するために開発されました。MBR とは異なり、2 TiB (約 2.2 TB に相当) を超えるストレージに対応できません。GPT はこれよりも大きなハードディスクで使用されます。アドレス可能な最大ディスクサイズは 2.2 ZiB です。また、デフォルトでは GPT は、最大 128 のプライマリーパーティションの作成に対応します。この数は、パーティションテーブルにより多くの領域を割り当てることで拡張できます。
GPT には GUID に基づくパーティションタイプがあります。特定のパーティションには特定の GUID が必要なことに注意してください。たとえば、EFI ブートローダーのシステムパーティションには GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B
が必要です。
GPT ディスクは論理ブロックアドレス設定 (LBA) を使用し、パーティションレイアウトは以下のようになります。
- MBR ディスクとの後方互換性を維持するために、GPT の最初のセクター (LBA 0) は MBR データ用に予約され、「保護 MBR」と呼ばれます。
- プライマリー GPT ヘッダーは、デバイスの 2 番目の論理ブロック (LBA 1) から開始します。ヘッダーには、ディスク GUID、プライマリーパーティションテーブルの場所、セカンダリ GPT ヘッダーの場所、および CRC32 チェックサム、およびプライマリーパーティションテーブルが含まれます。また、テーブルにあるパーティションエントリーの数も指定します。
- プライマリー GPT には、デフォルトの 128 パーティションエントリーがあり、それぞれエントリーサイズは 128 バイトで、パーティションタイプ GUID と一意のパーティション GUID が含まれます。
- セカンダリー GPT はプライマリー GPT と同じです。これは、プライマリーパーティションテーブルが破損した場合に、リカバリーのバックアップテーブルとして主に使用されます。
- セカンダリー GPT ヘッダーは、ディスクの最後の論理セクターにあり、プライマリーヘッダーが破損した場合に GPT 情報を復元するために使用できます。これには、ディスク GUID、セカンダリーパーティションテーブルとプライマリー GPT ヘッダーの場所、それ自体とセカンダリーパーティションテーブルの CRC32 チェックサム、および可能なパーティションエントリーの数が含まれています。
図10.4 GUID パーティションテーブルを含むディスク
GPT (GUIDパーティションテーブル) を含むディスクにブートローダーを正常にインストールするには、BIOS ブートパーティションが必要です。これには、Anaconda によって初期化されるディスクが含まれます。ディスクに BIOS ブートパーティションがすでに含まれている場合は、再使用できます。
10.2.7. parted でディスクにパーティションテーブルを作成
この手順では、parted
ユーティリティーを使用するパーティションテーブルでブロックデバイスをフォーマットする方法を説明します。
手順
インタラクティブな
parted
シェルを起動します。# parted block-device
-
block-device を、パーティションテーブルを作成するデバイスへのパス (例:
/dev/sda
) に置き換えます。
-
block-device を、パーティションテーブルを作成するデバイスへのパス (例:
デバイスにパーティションテーブルがあるかどうかを確認します。
(parted) print
デバイスにパーティションが含まれている場合は、次の手順でパーティションを削除します。
新しいパーティションテーブルを作成します。
(parted) mklabel table-type
table-type を、使用するパーティションテーブルの種類に置き換えます。
-
msdo
(MBR の場合) -
gpt
(GPT の場合)
-
例10.2 GPT テーブルの作成
たとえば、ディスクに GPT テーブルを作成するには、次のコマンドを使用します。
(parted) mklabel gpt
このコマンドを実行するとすぐに変更が行われるため、実行する前によく確認してください。
パーティションテーブルを表示して、パーティションテーブルが存在することを確認します。
(parted) print
parted
シェルを終了します。(parted) quit
関連情報
-
man ページの
parted(8)
次のステップ
- デバイスにパーティションを作成します。詳細は、「パーティションの作成」 を参照してください。
10.3. パーティションの作成
システム管理者は、ディスクに新しいパーティションを作成できます。
10.3.1. ディスクのパーティション変更前の留意事項
このセクションでは、パーティションの作成、削除、またはサイズ変更を行う前に考慮すべき重要な点を説明します。
このセクションでは、IBM Z アーキテクチャーに固有の DASD パーティションテーブルを説明しません。DASD の情報は、以下を参照してください。
- IBM Z への Linux インスタンスの設定
- IBM Knowledge Center の「What you should know about DASD」
パーティションの最大数
デバイスで使用できるパーティションの数は、パーティションテーブルの種類によって異なります。
マスターブートレコード (MBR) パーティションテーブルでフォーマットされたデバイスでは、次のいずれかの数だけパーティションを設定できます。
- 最大 4 つのプライマリーパーティション
- 最大 3 つのプライマリーパーティション、および 1 つの拡張パーティション、ならびにその拡張内に複数の論理パーティション
-
GUID パーティションテーブル (GPT) でフォーマットしたデバイスにおけるパーティションの最大数は 128 個です。GPT 仕様により、パーティションテーブル用に確保するエリアを拡大することで、さらに多くのパーティションを作成できますが、
parted
ユーティリティーで用いられる一般的な方法で得られるエリアは 128 個に制限されます。
Red Hat では、特に理由がない限り、少なくとも swap
、/boot/
、および /
(root) のパーティションを作成することが推奨されます。
パーティションの最大サイズ
デバイスのパーティションの最大サイズは、パーティションテーブルの種類により異なります。
- マスターブートレコード (MBR) パーティションテーブルでフォーマットしたデバイスの最大サイズは 2TiB になります。
- GUID パーティションテーブル (GPT) でフォーマットしたデバイスの最大サイズは 8ZiB になります。
2TiB を超えるパーティションを作成する場合は、ディスクを GPT でフォーマットする必要があります。
サイズ調整
parted
ユーティリティーを使用した場合は、パーティションサイズを指定する際の接尾辞を選択できます。
- MiB、GiB、または TiB
サイズは 2 のべき乗で表示されます。
- パーティションの開始点は、サイズが指定する正確なセクターに調整されます。
- 終了点は、指定されたサイズから 1 セクターを引いたサイズに調整されます。
- MB、GB、または TB
サイズは 10 のべき乗で表示されます。
開始点と終了点は、指定された単位の半分以内に置かれます。たとえば、接尾辞 MB を使用する場合は ±500 KB です。
10.3.2. パーティションタイプ
このセクションでは、パーティションのタイプを指定するさまざまな属性を説明します。
パーティションタイプまたはフラグ
パーティションタイプ、またはフラグは、実行中のシステムではほとんど使用されません。ただし、パーティションタイプは、systemd-gpt-auto-generator
など、デバイスを自動的に識別してマウントするためにパーティションタイプを使用するオンザフライジェネレーターにとって重要です。
-
parted
ユーティリティーは、パーティションタイプを flags にマッピングすることでパーティションタイプを制御します。parted ユーティリティーが処理できるのは、特定のパーティションタイプ (LVM、swap、または RAID など) に限定されます。 -
fdisk
ユーティリティーは、16 進数コードを指定することで、あらゆる種類のパーティションタイプに対応します。
パーティションファイルシステムのタイプ
parted
ユーティリティーは、パーティションを作成するときにオプションでファイルシステムタイプ引数を受け付けます。値は以下の目的で使用されます。
- MBR にパーティションフラグを設定します。
-
GPT にパーティションの UUID タイプを設定します。たとえば、ファイルシステムタイプの
swap
、fat
、またはhfs
には、異なる GUID が設定されます。デフォルト値は Linux Data GUID です。
引数によりパーティション上のファイルシステムが変更することはありません。サポートされているフラグまたは GUID を変更するだけです。
次のファイルシステムのタイプがサポートされています。
-
xfs
-
ext2
-
ext3
-
ext4
-
fat16
-
fat32
-
hfs
-
hfs+
-
linux-swap
-
ntfs
-
reiserfs
10.3.3. パーティション命名スキーム
Red Hat Enterprise Linux は、/dev/xxyN
形式のファイル名を持つファイルベースの命名スキームを使用します。
デバイスおよびパーティション名は、以下の構造で構成されています。
/dev/
-
これは、すべてのデバイスファイルが配置されているディレクトリーの名前です。パーティションはハードディスク上に配置され、ハードディスクはデバイスであるため、パーティションを表すすべてのファイルは
/dev
に配置されます。 xx
-
パーティション名の最初の 2 文字は、パーティションが存在するデバイスのタイプ (通常は
sd
) を示します。 y
-
この文字は、パーティションが存在するデバイスを示します。たとえば、
/dev/sda
は最初のハードディスク、/dev/sdb
は 2 番目のハードディスク、などです。26 を超えるドライブが搭載されているシステムでは、より多くの文字を使用できます。たとえば、/dev/sdaa1
です。 N
-
最後の文字は、パーティションを表す数字を示します。最初の 4 つのパーティション (プライマリーまたは拡張) のパーティションには、
1
から4
までの番号が付けられます。論理パーティションは5
から始まります。たとえば、/dev/sda3
は 1 番目のハードディスクの 3 番目のプライマリーパーティションまたは拡張パーティションで、2 番目のハードディスク上の 2 番目の論理パーティション/dev/sdb6
です。ドライブのパーティション番号は、MBR パーティションテーブルにのみ適用されます。N は常にパーティションを意味するものではないことに注意してください。
Red Hat Enterprise Linux が すべて のタイプのディスクパーティションを識別して参照できる場合でも、ファイルシステムを読み取れないため、すべてのパーティションタイプに保存されているデータにアクセスできます。ただし、多くの場合、別のオペレーティングシステム専用のパーティション上にあるデータには問題なくアクセスすることができます。
10.3.4. マウントポイントとディスクパーティション
Red Hat Enterprise Linux では、各パーティションは、ファイルおよびディレクトリーの単一セットをサポートするのに必要なストレージの一部を形成するために使用されます。これは、パーティションとディレクトリーを関連付ける マウント として知られるプロセスを使用して実行されます。パーティションをマウントすると、指定したディレクトリー (マウントポイント と呼ばれる) からそのストレージを利用できるようになります。
たとえば、パーティション /dev/sda5
が /usr/
/ にマウントされている場合、/usr/
下にあるすべてのファイルとディレクトリーは、物理的に dev/sda5
に配置されていることになります。そのため、/usr/share/doc/FAQ/txt/Linux-FAQ
ファイルは /dev/sda5
に保存されますが、/etc/gdm/custom.conf
ファイルは保存されません。
また、この例では、/usr/
以下の 1 つ以上のディレクトリーが他のパーティションのマウントポイントになる可能性もあります。たとえば、パーティション /dev/sda7
は /usr/local
にマウントできます。つまり、/usr/local/man/whatis
は、/dev/sda5
ではなく /dev/sda7
上に存在することになります。
10.3.5. parted でパーティションの作成
この手順では、parted
ユーティリティーを使用してブロックデバイスに新しいパーティションを作成する方法を説明します。
前提条件
- ディスクにパーティションテーブルがある。ディスクのフォーマット方法の詳細は、「ディスクへのパーティションテーブルの作成」 を参照してください。
- 2TiB を超えるパーティションを作成する場合は、ディスクを GUID パーティションテーブル (GPT) でフォーマットしておく。
手順
インタラクティブな
parted
シェルを起動します。# parted block-device
-
block-device を、パーティションを作成するデバイスへのパス (例:
/dev/sda
) に置き換えます。
-
block-device を、パーティションを作成するデバイスへのパス (例:
現在のパーティションテーブルを表示し、十分な空き領域があるかどうかを確認します。
(parted) print
- 十分な空き容量がない場合は、既存のパーティションのサイズを変更できます。詳細は、「パーティションのサイズ変更」を参照してください。
パーティションテーブルから、以下を確認します。
- 新しいパーティションの開始点と終了点
- MBR で、どのパーティションタイプにすべきか
新しいパーティションを作成します。
(parted) mkpart part-type name fs-type start end
-
part-type を、パーティションテーブルに基づき
primary
、logical
、またはextended
に置き換えます。これは MBR パーティションテーブルにのみ適用されます。 - name を、任意のパーティション名に置き換えます。これは GPT パーティションテーブルに必要です。
-
fs-type を
xfs
、ext2
、ext3
、ext4
、fat16
、fat32
、hfs
、hfs+
、linux-swap
、ntfs
、またはreiserfs
のいずれかに置き換えます。fs-type パラメーターは任意です。parted
は、パーティション上にファイルシステムを作成しません。 -
start と end を、パーティションの開始点と終了点を決定するサイズに置き換えます (ディスクの開始からカウントします)。
512MiB
、20GiB
、1.5TiB
などのサイズサフィックスを使用できます。デフォルトサイズはメガバイトです。
例10.3 小さなプライマリーパーティションの作成
たとえば、MBR テーブルに 1024MiB から 2048MiB までのプライマリーパーティションを作成するには、次のコマンドを使用します。
(parted) mkpart primary 1024MiB 2048MiB
このコマンドを実行するとすぐに変更が行われるため、実行する前によく確認してください。
-
part-type を、パーティションテーブルに基づき
パーティションテーブルを表示して、作成されたパーティションのパーティションタイプ、ファイルシステムタイプ、サイズが、パーティションテーブルに正しく表示されていることを確認します。
(parted) print
parted
シェルを終了します。(parted) quit
次のコマンドを使用して、システムが新しいデバイスノードを登録するまで待機します。
# udevadm settle
カーネルが新しいパーティションを認識していることを確認します。
# cat /proc/partitions
関連情報
-
man ページの
parted(8)
10.3.6. fdisk でパーティションタイプの設定
この手順では、fdisk
ユーティリティーを使用してパーティションタイプまたはフラグを設定する方法を説明します。
前提条件
- ディスクにパーティションがある。
手順
インタラクティブな
fdisk
シェルを起動します。# fdisk block-device
-
block-device を、パーティションタイプを設定するデバイスへのパスに置き換えます。たとえば、
/dev/sda
に置き換えます。
-
block-device を、パーティションタイプを設定するデバイスへのパスに置き換えます。たとえば、
現在のパーティションテーブルを表示して、パーティションのマイナー番号を確認します。
Command (m for help): print
現在のパーティションタイプは
Type
列で、それに対応するタイプ ID はId
列で確認できます。パーティションタイプコマンドを入力し、マイナー番号を使用してパーティションを選択します。
Command (m for help): type Partition number (1,2,3 default 3): 2
必要に応じて、利用可能な 16 進数コードを一覧表示します。
Hex code (type L to list all codes): L
パーティションタイプを設定します。
Hex code (type L to list all codes): 8e
変更を書き込み、
fdisk
シェルを終了します。Command (m for help): write The partition table has been altered. Syncing disks.
変更を確認します。
# fdisk --list block-device
10.4. パーティションの削除
システム管理者は、ディスク領域を解放するのに使用されなくなったディスクパーティションを削除できます。
パーティションを削除すると、そのパーティションに保存されているすべてのデータが削除されます。
10.4.1. ディスクのパーティション変更前の留意事項
このセクションでは、パーティションの作成、削除、またはサイズ変更を行う前に考慮すべき重要な点を説明します。
このセクションでは、IBM Z アーキテクチャーに固有の DASD パーティションテーブルを説明しません。DASD の情報は、以下を参照してください。
- IBM Z への Linux インスタンスの設定
- IBM Knowledge Center の「What you should know about DASD」
パーティションの最大数
デバイスで使用できるパーティションの数は、パーティションテーブルの種類によって異なります。
マスターブートレコード (MBR) パーティションテーブルでフォーマットされたデバイスでは、次のいずれかの数だけパーティションを設定できます。
- 最大 4 つのプライマリーパーティション
- 最大 3 つのプライマリーパーティション、および 1 つの拡張パーティション、ならびにその拡張内に複数の論理パーティション
-
GUID パーティションテーブル (GPT) でフォーマットしたデバイスにおけるパーティションの最大数は 128 個です。GPT 仕様により、パーティションテーブル用に確保するエリアを拡大することで、さらに多くのパーティションを作成できますが、
parted
ユーティリティーで用いられる一般的な方法で得られるエリアは 128 個に制限されます。
Red Hat では、特に理由がない限り、少なくとも swap
、/boot/
、および /
(root) のパーティションを作成することが推奨されます。
パーティションの最大サイズ
デバイスのパーティションの最大サイズは、パーティションテーブルの種類により異なります。
- マスターブートレコード (MBR) パーティションテーブルでフォーマットしたデバイスの最大サイズは 2TiB になります。
- GUID パーティションテーブル (GPT) でフォーマットしたデバイスの最大サイズは 8ZiB になります。
2TiB を超えるパーティションを作成する場合は、ディスクを GPT でフォーマットする必要があります。
サイズ調整
parted
ユーティリティーを使用した場合は、パーティションサイズを指定する際の接尾辞を選択できます。
- MiB、GiB、または TiB
サイズは 2 のべき乗で表示されます。
- パーティションの開始点は、サイズが指定する正確なセクターに調整されます。
- 終了点は、指定されたサイズから 1 セクターを引いたサイズに調整されます。
- MB、GB、または TB
サイズは 10 のべき乗で表示されます。
開始点と終了点は、指定された単位の半分以内に置かれます。たとえば、接尾辞 MB を使用する場合は ±500 KB です。
10.4.2. parted でパーティションの削除
この手順では、parted
ユーティリティーを使用してディスクパーティションを削除する方法を説明します。
手順
インタラクティブな
parted
シェルを起動します。# parted block-device
-
block-device を、パーティションを削除するデバイスへのパス (例:
/dev/sda
) に置き換えます。
-
block-device を、パーティションを削除するデバイスへのパス (例:
現在のパーティションテーブルを表示して、削除するパーティションのマイナー番号を確認します。
(parted) print
パーティションを削除します。
(parted) rm minor-number
-
minor-number を、削除するパーティションのマイナー番号 (例:
3
) に置き換えます。
このコマンドを実行するとすぐに変更が行われるため、実行する前によく確認してください。
-
minor-number を、削除するパーティションのマイナー番号 (例:
パーティションテーブルからパーティションが削除されたことを確認します。
(parted) print
parted
シェルを終了します。(parted) quit
パーティションが削除されたことをカーネルが認識していることを確認します。
# cat /proc/partitions
-
パーティションが存在する場合は、
/etc/fstab
ファイルからパーティションを削除します。削除したパーティションを宣言している行を見つけ、ファイルから削除します。 システムが新しい
/etc/fstab
設定を登録するように、マウントユニットを再生成します。# systemctl daemon-reload
スワップパーティション、または LVM 部分を削除した場合は、
/etc/default/grub
ファイルのカーネルコマンドラインからパーティションへの参照をすべて削除して、GRUB 設定を再生成します。BIOS ベースのシステムの場合:
# grub2-mkconfig --output=/etc/grub2.cfg
UEFI ベースのシステムの場合:
# grub2-mkconfig --output=/etc/grub2-efi.cfg
アーリーブートシステムに変更を登録するには、
initramfs
ファイルシステムを再構築します。# dracut --force --verbose
関連情報
-
man ページの
parted(8)
10.5. パーティションのサイズ変更
システム管理者は、パーティションを拡張して未使用のディスク容量を利用したり、パーティションを縮小して、作成した容量をさまざまな目的に使用できます。
10.5.1. ディスクのパーティション変更前の留意事項
このセクションでは、パーティションの作成、削除、またはサイズ変更を行う前に考慮すべき重要な点を説明します。
このセクションでは、IBM Z アーキテクチャーに固有の DASD パーティションテーブルを説明しません。DASD の情報は、以下を参照してください。
- IBM Z への Linux インスタンスの設定
- IBM Knowledge Center の「What you should know about DASD」
パーティションの最大数
デバイスで使用できるパーティションの数は、パーティションテーブルの種類によって異なります。
マスターブートレコード (MBR) パーティションテーブルでフォーマットされたデバイスでは、次のいずれかの数だけパーティションを設定できます。
- 最大 4 つのプライマリーパーティション
- 最大 3 つのプライマリーパーティション、および 1 つの拡張パーティション、ならびにその拡張内に複数の論理パーティション
-
GUID パーティションテーブル (GPT) でフォーマットしたデバイスにおけるパーティションの最大数は 128 個です。GPT 仕様により、パーティションテーブル用に確保するエリアを拡大することで、さらに多くのパーティションを作成できますが、
parted
ユーティリティーで用いられる一般的な方法で得られるエリアは 128 個に制限されます。
Red Hat では、特に理由がない限り、少なくとも swap
、/boot/
、および /
(root) のパーティションを作成することが推奨されます。
パーティションの最大サイズ
デバイスのパーティションの最大サイズは、パーティションテーブルの種類により異なります。
- マスターブートレコード (MBR) パーティションテーブルでフォーマットしたデバイスの最大サイズは 2TiB になります。
- GUID パーティションテーブル (GPT) でフォーマットしたデバイスの最大サイズは 8ZiB になります。
2TiB を超えるパーティションを作成する場合は、ディスクを GPT でフォーマットする必要があります。
サイズ調整
parted
ユーティリティーを使用した場合は、パーティションサイズを指定する際の接尾辞を選択できます。
- MiB、GiB、または TiB
サイズは 2 のべき乗で表示されます。
- パーティションの開始点は、サイズが指定する正確なセクターに調整されます。
- 終了点は、指定されたサイズから 1 セクターを引いたサイズに調整されます。
- MB、GB、または TB
サイズは 10 のべき乗で表示されます。
開始点と終了点は、指定された単位の半分以内に置かれます。たとえば、接尾辞 MB を使用する場合は ±500 KB です。
10.5.2. parted でパーティションのサイズ変更
この手順では、parted
ユーティリティーを使用してディスクパーティションのサイズを変更する方法を説明します。
前提条件
パーティションを縮小する場合は、そこに格納されているデータのバックアップを作成する。
警告パーティションを縮小すると、パーティションのデータが失われる可能性があります。
- パーティションを 2TiB を超えるサイズに変更する場合は、ディスクを GUID パーティションテーブル (GPT) でフォーマットする必要があります。ディスクのフォーマット方法の詳細は、「ディスクへのパーティションテーブルの作成」 を参照してください。
手順
- パーティションを縮小する場合は、サイズを変更したパーティションより大きくならないように、最初にファイルシステムを縮小してください。XFS は、縮小をサポートしていないことに注意してください。
インタラクティブな
parted
シェルを起動します。# parted block-device
-
block-device を、パーティションのサイズ変更を行うデバイスへのパス (例:
/dev/sda
) に置き換えます。
-
block-device を、パーティションのサイズ変更を行うデバイスへのパス (例:
現在のパーティションテーブルを表示します。
(parted) print
パーティションテーブルから、以下を確認します。
- パーティションのマイナー番号
- 既存のパーティションの位置とサイズ変更後の新しい終了点
パーティションのサイズを変更します。
(parted) resizepart minor-number new-end
-
minor-number を、サイズを変更するパーティションのマイナー番号 (例:
3
) に置き換えます。 -
new-end を、サイズを変更するパーティションの新しい終了点を決定するサイズに置き換えます (ディスクの開始からカウントします)。
512MiB
、20GiB
、1.5TiB
などのサイズサフィックスを使用できます。デフォルトサイズはメガバイトです。
例10.4 パーティションの拡張
たとえば、ディスクの先頭にあるパーティションを 2GiB のサイズに拡張するには、次のコマンドを使用します。
(parted) resizepart 1 2GiB
このコマンドを実行するとすぐに変更が行われるため、実行する前によく確認してください。
-
minor-number を、サイズを変更するパーティションのマイナー番号 (例:
パーティションテーブルを表示して、サイズ変更したパーティションのサイズが、パーティションテーブルで正しく表示されていることを確認します。
(parted) print
parted
シェルを終了します。(parted) quit
カーネルが新しいパーティションを認識していることを確認します。
# cat /proc/partitions
- パーティションを拡張した場合は、そこにあるファイルシステムも拡張します。詳細は (参考) を参照してください。
関連情報
-
man ページの
parted(8)
10.6. ディスクを再構成するストラテジー
ディスクを再パーティションする方法は複数あります。本セクションでは、以下のアプローチについて説明します。
- パーティションが分割されていない空き領域が利用できる。
- 未使用のパーティションが利用可能である。
- アクティブに使用されているパーティションの空き領域が利用可能である。
本セクションでは、前述の概念について理論的にのみ説明し、ディスクのパーティションの再作成を段階的に実行する手順については説明しません。
以下の図は、分かりやすく、実際に Red Hat Enterprise Linux をインストールする際に発生する正確なパーティションレイアウトを反映しません。
10.6.1. パーティションが分割されていない空き領域の使用
このような場合、すでに定義されているパーティションはハードディスク全体にまたがらないため、定義されたパーティションには含まれない未割り当ての領域が残されます。次の図は、これがどのようになるかを示しています。
図10.5 パーティションが分割されていない空き領域があるディスク
上記の例では、最初の図は、1 つのプライマリーパーティションを持つディスクと、未割り当ての領域を持つ未定義のパーティションを表し、2 つ目の図は、領域が割り当てられた 2 つの定義されたパーティションを持つディスクを表します。
未使用のハードディスクもこのカテゴリーに分類されます。唯一の違いは、すべて の領域が定義されたパーティションの一部ではないことです。
いずれの場合も、未使用の領域から必要なパーティションを作成できます。このシナリオは、ほとんどの場合は新しいディスクに適しています。ほとんどのオペレーティングシステムは、ディスクドライブ上の利用可能な領域をすべて取得するように設定されています。
10.6.2. 未使用パーティションの領域の使用
この場合は、使用されなくなったパーティションを 1 つ以上設定できます。以下の図はこのような状況を示しています。
図10.6 未使用のパーティションがあるディスク
上記の例では、最初の図は未使用のパーティションを持つディスクを表し、2 番目の図は Linux 用の未使用パーティションの再割り当てを示しています。
このような場合は、未使用のパーティションに割り当てられる領域を使用できます。パーティションを削除してから、適切な Linux パーティションをその場所に作成する必要があります。未使用のパーティションを削除し、インストールプロセス時に新しいパーティションを手動で作成できます。
10.6.3. アクティブなパーティションの空き領域の使用
これは最も一般的な状況です。また、十分な空き領域がある場合でも、すでに使用中のパーティションに割り当てられるため、処理が困難になります。ソフトウェアがプリインストールされているコンピュータを購入した場合、ハードディスクには、オペレーティングシステムとデータを保持する1つの大きなパーティションがある可能性があります。
システムに新しいハードドライブを追加する以外に、破壊的な再構成と非破壊的な再構成を選択できます。
10.6.3.1. 破壊的な再構成
これにより、パーティションが削除され、小さいパーティションがいくつか作成されます。元のパーティションのデータは破棄されるため、完全バックアップを作成する必要があります。2 つのバックアップを作成し、検証 (バックアップソフトウェアで利用可能な場合) を使用し、パーティションを削除する 前 にバックアップからデータを読み込もうとします。
オペレーティングシステムがそのパーティションにインストールされていて、そのシステムも使用する場合は、再インストールする必要があります。オペレーティングシステムがプリインストールされた状態で販売されている一部のコンピューターには、元のオペレーティングシステムを再インストールするためのインストールメディアが含まれていない場合があります。元のパーティションとそのオペレーティングシステムのインストールを破棄する 前 に、これがシステムに適用されるかどうかを確認してください。
既存のオペレーティングシステムに小規模なパーティションを作成したら、ソフトウェアを再インストールし、データを復元し、Red Hat Enterprise Linux のインストールを開始できます。
図10.7 ディスク上での破壊的な再パーティション処理
元のパーティションに存在していたデータはすべて失われます。
10.6.3.2. 非破壊的な再パーティション
非破壊的なパーティション再分割では、大きなパーティションを小さくするプログラムを実行するため、そのパーティションに保存されているファイルを失うことはありません。通常、この方法は信頼性がありますが、大規模なドライブでは非常に時間がかかります。
非破壊的な再パーティション処理は分かりやすく、以下の 3 つの手順で構成されます。
- 既存データの圧縮およびバックアップ
- 既存パーティションのサイズ
- 新しいパーティションの作成
各ステップについて詳細に説明します。
10.6.3.2.1. 既存データの圧縮
最初の手順では、既存のパーティションのデータを圧縮します。これを行う理由は、パーティションの「末尾」で使用可能な空き領域を最大化するために、データを再配置します。
図10.8 ディスクの圧縮
上記の例では、最初の図は圧縮前のディスクを表し、圧縮後の 2 つ目の図です。
このステップは重要です。データの場所を使用しないと、パーティションを希望のエクステントのサイズを変更できなくなる可能性があります。一部のデータは移動できないことに注意してください。この場合、新しいパーティションのサイズが厳しく制限され、ディスクを破壊的に再パーティション化する必要が生じる可能性があります。
10.6.3.2.2. 既存パーティションのサイズ変更
次の図は、実際のサイズ変更プロセスを示しています。サイズ変更操作の実際の結果は使用するソフトウェアによって異なりますが、ほとんどの場合、新しく解放された領域を使用して、元のパーティションと同じタイプのフォーマットされていないパーティションが作成されます。
図10.9 ディスク上でのパーティションのサイズ変更
上記の例では、最初の図はサイズ変更前のパーティションを表し、サイズ変更後の 2 番目の図を示しています。
使用するサイズ変更ソフトウェアが新しく解放された領域をどのように処理するかを理解して、適切な手順を実行できるようにすることが重要です。ここで説明する場合は、新しい DOS パーティションを削除して、適切な Linux パーティションまたはパーティションを作成することが推奨されます。
10.6.3.2.3. 新しいパーティションの作成
例の「既存パーティションのサイズ変更」で説明したように、新しいパーティションを作成する必要がなくなることがあります。ただし、サイズ変更ソフトウェアが Linux をインストールしたシステムに対応していない限り、サイズ変更プロセスで作成されたパーティションを削除する必要があります。
図10.10 最終パーティション構成のディスク
上記の例では、最初の図は構成前のディスクを表し、2 番目の図は構成後のディスクを表しています。
第11章 XFS の使用
これは、XFS ファイルシステムを作成および維持する方法の概要です。
11.1. XFS ファイルシステム
XFSは、拡張性が高く、高性能で堅牢な、成熟した 64 ビットのジャーナリングファイルシステムで、1 台のホストで非常に大きなファイルおよびファイルシステムに対応します。これは、Red Hat Enterprise Linux 8 のデフォルトのファイルシステムです。XFS は、元々 1990 年代の前半に SGI により開発され、極めて大規模なサーバーおよびストレージアレイで実行されてきた長い歴史があります。
XFS の機能は次のとおりです。
- 信頼性
- メタデータジャーナリング - システムの再起動時、およびファイルシステムの再マウント時に再生できるファイルシステム操作の記録を保持することで、システムクラッシュ後のファイルシステムの整合性を確保します。
- 広範囲に及ぶランタイムメタデータの整合性チェック
- 拡張性が高く、高速な修復ユーティリティー
- クォータジャーナリングクラッシュ後に行なわれる、時間がかかるクォータの整合性チェックが不要になります。
- スケーラビリティーおよびパフォーマンス
- 対応するファイルシステムのサイズが最大 1024 TiB
- 多数の同時操作に対応する機能
- 空き領域管理のスケーラビリティーに関する B-Tree インデックス
- 高度なメタデータ先読みアルゴリズム
- ストリーミングビデオのワークロードの最適化
- 割り当てスキーム
- エクステント (領域) ベースの割り当て
- ストライプを認識できる割り当てポリシー
- 遅延割り当て
- 領域の事前割り当て
- 動的に割り当てられる inode
- その他の機能
- Reflink ベースのファイルのコピー (Red Hat Enterprise Linux 8 の新機能)
- 密接に統合されたバックアップおよび復元のユーティリティー
- オンラインのデフラグ
- オンラインのファイルシステム拡張
- 包括的な診断機能
-
拡張属性 (
xattr
)。これにより、システムが、ファイルごとに、名前と値の組み合わせを追加で関連付けられるようになります。 - プロジェクトまたはディレクトリーのクォータ。ディレクトリーツリー全体にクォータ制限を適用できます。
- サブセカンド (一秒未満) のタイムスタンプ
パフォーマンスの特徴
XFS は、エンタープライズレベルのワークロードがある大規模なシステムで優れたパフォーマンスを発揮します。大規模なシステムとは、相対的に CPU 数が多く、さらには複数の HBA、および外部ディスクアレイへの接続を備えたシステムです。XFS は、マルチスレッドの並列 I/O ワークロードを備えた小規模のシステムでも適切に実行します。
XFS は、シングルスレッドで、メタデータ集約型のワークロードのパフォーマンスが比較的低くなります。たとえば、シングルスレッドで小さなファイルを多数作成し、削除するワークロードがこれに当てはまります。
11.2. XFS ファイルシステムの作成
システム管理者は、ブロックデバイスに XFS ファイルシステムを作成して、ファイルやディレクトリーを格納できます。
11.2.1. mkfs.xfs で XFS ファイルシステムの作成
この手順では、ブロックデバイスに XFS ファイルシステムを作成する方法を説明します。
手順
ファイルシステムを作成する場合は、以下の手順を実行します。
デバイスが通常のパーティション、LVM ボリューム、MD ボリューム、ディスク、または類似デバイスである場合は、次のコマンドを使用します。
# 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
オプションを追加してください。
-
block-device を、ブロックデバイスへのパスに置き換えます。たとえば、
ハードウェア RAID デバイスにファイルシステムを作成する場合は、システムがデバイスのストライプジオメトリーを正しく検出しているかどうかを確認します。
ストライプジオメトリー情報が正しい場合は、追加のオプションが必要ありません。ファイルシステムを作成します。
# mkfs.xfs block-device
情報が正しくない場合は、
-d
オプションのsu
パラメーターおよびsw
パラメーターを使用して、ストライプジオメトリーを手動で指定します。su
パラメーターは RAID チャンクサイズを指定し、sw
パラメーターは RAID デバイス内のデータディスクの数を指定します。以下に例を示します。
# mkfs.xfs -d su=64k,sw=4 /dev/sda3
次のコマンドを使用して、システムが新しいデバイスノードを登録するまで待機します。
# udevadm settle
関連情報
-
man ページの
mkfs.xfs(8)
11.2.2. RHEL システムロールを使用してブロックデバイスに XFS ファイルシステムの作成
本セクションでは、storage
ロールを使用して、複数のターゲットマシンのブロックデバイスに XFS ファイルシステムを作成する方法を説明します。
前提条件
storage
ロールを使用する Ansible Playbook がある。このような Playbook を適用する方法は、「ロールの適用」 を参照してください。
11.2.2.1. ブロックデバイスに XFS ファイルシステムを作成する Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook では、storage
ロールを適用し、デフォルトパラメーターを使用してブロックデバイスに XFS ファイルシステムを作成します。
storage
ロールは、パーティションが分割されていないディスク全体または論理ボリューム (LV) でのみファイルシステムを作成できます。パーティションにファイルシステムを作成することはできません。
例11.1 /dev/sdb に XFS を作成する Playbook
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs roles: - rhel-system-roles.storage
-
現在、ボリューム名 (この例では
barefs
) は任意です。storage
ロールは、disks:
属性に一覧表示されているディスクデバイスでボリュームを特定します。 -
XFS は RHEL 8 のデフォルトファイルシステムであるため、
fs_type: xfs
行を省略することができます。 論理ボリュームにファイルシステムを作成するには、エンクロージングボリュームグループを含む
disks:
属性の下に LVM 設定を指定します。詳細は、「論理ボリュームを管理する Ansible Playbook の例」 を参照してください。LV デバイスへのパスを指定しないでください。
関連情報
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
11.2.2.2. 関連情報
-
storage
ロールの詳細は、「storage ロールの概要」 を参照してください。
11.3. XFS ファイルシステムのバックアップ
システム管理者は、xfsdump
を使用して XFS ファイルシステムをファイルまたはテープにバックアップできます。これは、簡単なバックアップメカニズムを提供します。
11.3.1. XFS バックアップの機能
本セクションでは、xfsdump
ユーティリティーを使用して XFS ファイルシステムをバックアップする場合の主な概念と機能を説明します。
xfsdump
ユーティリティーを使用すると次のことができます。
通常のファイルイメージへのバックアップ
通常のファイルに書き込むことができるバックアップは 1 つだけです。
テープドライブへのバックアップ
xfsdump
ユーティリティーを使用すると、同じテープに複数のバックアップを書き込むこともできます。バックアップは、複数のテープを分割して書き込むことができます。複数のファイルシステムのバックアップを 1 つのテープデバイスに作成するには、XFS バックアップがすでに含まれているテープにバックアップを書き込みます。これにより、古いバックアップに、新しいバックアップが追加されます。
xfsdump
は、デフォルトでは既存のバックアップを上書しません。増分バックアップの作成
xfsdump
ユーティリティーはダンプレベルを使用して、その他のバックアップの相対的なベースバックアップを決定します。0 から 9 までの数字は、ダンプレベルの増加を表します。増分バックアップは、下位レベルの最後のダンプ以降に変更したファイルのみが対象となります。- フルバックアップを実行する場合は、ファイルシステムでレベル 0 のダンプを実行します。
- レベル 1 のダンプは、フルバックアップ後の最初の増分バックアップです。次の増分バックアップはレベル 2 になります。これは、前回のレベル 1 のダンプ以降に変更したファイルのみが対象となります。レベル 9 まで同様です。
- ファイルを絞り込むサイズ、サブツリー、または inode のフラグを使用して、バックアップからファイルを除外
関連情報
-
man ページの
xfsdump(8)
11.3.2. xfsdump で XFS ファイルシステムのバックアップ
この手順では、XFS ファイルシステムのコンテンツのバックアップを、ファイルまたはテープに作成する方法を説明します。
前提条件
- バックアップが可能な 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
) に置き換えます。
-
level を、バックアップのダンプレベルに置き換えます。フルバックアップを実行する場合は
例11.2 複数の 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
関連情報
-
man ページの
xfsdump(8)
11.3.3. 関連情報
-
man ページの
xfsdump(8)
11.4. バックアップからの XFS ファイルシステムの復元
システム管理者は、xfsrestore
ユーティリティーを使用して、xfsdump
ユーティリティーで作成され、ファイルまたはテープに保存されている XFS バックアップを復元できます。
11.4.1. バックアップから XFS を復元する機能
本セクションでは、xfsrestore
ユーティリティーを使用してバックアップから XFS ファイルシステムを復元する際の主な概念と機能を説明します。
xfsrestore
ユーティリティーは、xfsdump
により作成されたバックアップからファイルシステムを復元します。xfsrestore
ユーティリティーには 2 つのモードがあります。
- simple モードでは、ユーザーはレベル 0 のダンプからファイルシステム全体を復元できます。これがデフォルトのモードです。
- cumulative モードでは、増分バックアップ (つまりレベル 1 からレベル 9) からファイルシステムを復元できます。
各バックアップは、session ID または session label で一意に識別されます。複数のバックアップを含むテープからバックアップを復元するには、対応するセッション ID またはラベルが必要です。
バックアップから特定のファイルを抽出、追加、または削除するには、xfsrestore
インタラクティブモードを起動します。インタラクティブモードでは、バックアップファイルを操作する一連のコマンドが提供されます。
関連情報
-
man ページの
xfsrestore(8)
11.4.2. xfsrestore を使用してバックアップから XFS ファイルシステムを復元
この手順では、XFS ファイルシステムの内容を、ファイルまたはテープのバックアップから復元する方法を説明します。
前提条件
- 「XFS ファイルシステムのバックアップ」 に記載されている XFS ファイルシステムのファイルまたはテープのバックアップ。
- バックアップを復元できるストレージデバイス。
手順
バックアップを復元するコマンドは、フルバックアップから復元するか、増分バックアップから復元するか、または 1 つのテープデバイスから複数のバックアップを復元するかによって異なります。
# xfsrestore [-r] [-S session-id] [-L session-label] [-i] -f backup-location restoration-path
-
backup-location を、バックアップの場所に置き換えます。これは、通常のファイル、テープドライブ、またはリモートテープデバイスになります。たとえば、ファイルの場合は
/backup-files/Data.xfsdump
、テープドライブの場合は/dev/st0
に置き換えます。 -
restoration-path を、ファイルシステムを復元するディレクトリーへのパスに置き換えます。たとえば、
/mnt/data/
に置き換えます。 -
ファイルシステムを増分 (レベル 1 からレベル 9) バックアップから復元するには、
-r
オプションを追加します。 複数のバックアップを含むテープデバイスからバックアップを復元するには、
-S
オプションまたは-L
オプションを使用してバックアップを指定します。-S
オプションではセッション ID でバックアップを選択でき、-L
オプションではセッションラベルで選択できます。セッション ID とセッションラベルを取得するには、xfsrestore -I
コマンドを使用します。session-id を、バックアップのセッション ID に置き換えます。たとえば、
b74a3586-e52e-4a4a-8775-c3334fa8ea2c
に置き換えます。session-label を、バックアップのセッションラベルに置き換えます。たとえば、my_backup_session_label
に置き換えます。xfsrestore
をインタラクティブに使用するには、-i
オプションを使用します。インタラクティブダイアログは、指定されたデバイスの、
xfsrestore
による読み取りが終了してから始まります。インタラクティブなxfsrestore
シェルの使用可能なコマンドには、cd
、ls
、add
、delete
、extract
があります。コマンドの全リストを見るには、help
コマンドを使用します。
-
backup-location を、バックアップの場所に置き換えます。これは、通常のファイル、テープドライブ、またはリモートテープデバイスになります。たとえば、ファイルの場合は
例11.3 複数の XFS ファイルシステムの復元
XFS バックアップファイルを復元し、その内容を
/mnt/
配下のディレクトリーに保存するには、次のコマンドを実行します。# xfsrestore -f /backup-files/boot.xfsdump /mnt/boot/ # xfsrestore -f /backup-files/data.xfsdump /mnt/data/
複数のバックアップを含むテープデバイスから復元するには、各バックアップをセッションラベルまたはセッション ID で指定します。
# xfsrestore -L "backup_boot" -f /dev/st0 /mnt/boot/ # xfsrestore -S "45e9af35-efd2-4244-87bc-4762e476cbab" \ -f /dev/st0 /mnt/data/
関連情報
-
man ページの
xfsrestore(8)
11.4.3. テープから XFS バックアップを復元するときの情報メッセージ
複数のファイルシステムのバックアップを使用してテープからバックアップを復元するとき、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) [...]
情報メッセージは、一致するバックアップが見つかるまで継続して表示されます。
11.4.4. 関連情報
-
man ページの
xfsrestore(8)
11.5. XFS ファイルシステムのサイズの拡大
システム管理者は、XFS ファイルシステムのサイズを大きくして、より大きなストレージ容量を利用できます。
現在、XFS ファイルシステムのサイズを縮小することはできません。
11.5.1. xfs_growfs で XFS ファイルシステムのサイズの拡大
この手順では、xfs_growfs
ユーティリティーを使用して XFS ファイルシステムを拡張する方法を説明します。
前提条件
- 基礎となるブロックデバイスのサイズが、後でファイルシステムのサイズを変更するのに十分な大きさである。該当するブロックデバイスのサイズを変更する場合は、ブロックデバイスに適した方法を選択してください。
- XFS ファイルシステムをマウントしている。
手順
XFS ファイルシステムのマウント時に、
xfs_growfs
ユーティリティーを使用してサイズを大きくします。# xfs_growfs file-system -D new-size
- file-system を、XFS ファイルシステムのマウントポイントに置き換えます。
-D
オプションを指定して、new-size を、ファイルシステムブロックの数で指定されているファイルシステムの新しいサイズに置き換えます。特定の XFS ファイルシステムのブロックサイズ (KB 単位) を調べるには、
xfs_info
ユーティリティーを使用します。# xfs_info block-device ... data = bsize=4096 ...
-
xfs_growfs
は、-D
オプションを指定しないと、基となるデバイスがサポートする最大サイズまでファイルシステムを拡張します。
関連情報
-
man ページの
xfs_growfs(8)
11.6. ext4 および XFS で使用されるツールの比較
本セクションでは、ext4 ファイルシステムおよび XFS ファイルシステムで一般的なタスクを行うのに使用するツールを比較します。
タスク | ext4 | XFS |
---|---|---|
ファイルシステムを作成する |
|
|
ファイルシステムを確認する |
|
|
ファイルシステムのサイズを変更する |
|
|
ファイルシステムのイメージを保存する |
|
|
ファイルシステムのラベル付けまたはチューニングを行う |
|
|
ファイルシステムのバックアップを作成する |
|
|
クォータ管理 |
|
|
ファイルマッピング |
|
|
第12章 XFS エラー動作の設定
異なる I/O エラーが発生すると、XFS ファイルシステムの動作を設定できます。
12.1. XFS で設定可能なエラー処理
XFS ファイルシステムは、I/O 操作中にエラーが発生すると、以下のいずれかの方法で応答します。
XFS は、操作が成功するまで、または XFS が設定制限に到達するまで I/O 操作を繰り返し再試行します。
この制限は、再試行の最大数または再試行の最大時間を基にしています。
- XFS は、エラーを永続的に考慮し、ファイルシステムで操作を停止します。
XFS が以下のエラー条件に反応する方法を設定できます。
EIO
- 読み取りまたは書き込み時のエラー
ENOSPC
- デバイスに空き容量がない
ENODEV
- デバイスが見つからない
最大再試行回数と、XFS がエラーを永続的と見なすまでの最大時間を秒単位で設定できます。XFS は、いずれかの制限に達すると操作の再試行を停止します。
また、ファイルシステムのマウントを解除するときに、他の設定に関係なく XFS が再試行を即座にキャンセルするように XFS を設定することもできます。この設定により、永続的なエラーを出しても、マウント解除操作は成功します。
デフォルトの動作
各 XFS エラー条件のデフォルトの動作は、エラーコンテキストによって異なります。ENODEV
などの XFS エラーは、リトライ回数に関係なく致命的で回復不能とみなされます。デフォルトの再試行制限は 0 です。
12.2. 特定の、未定義の XFS エラー条件の設定ファイル
以下のディレクトリーは、さまざまなエラー状態に対して XFS エラー動作を制御する設定ファイルを保存します。
/sys/fs/xfs/device/error/metadata/EIO/
-
EIO
エラー条件の場合 /sys/fs/xfs/device/error/metadata/ENODEV/
-
ENODEV
エラー条件の場合 /sys/fs/xfs/device/error/metadata/ENOSPC/
-
ENOSPC
エラー条件の場合 /sys/fs/xfs/device/error/default/
- その他のすべての未定義エラー条件の共通設定
各ディレクトリーには、再試行制限を設定するために以下の設定ファイルが含まれています。
max_retries
- XFS が操作を再試行する最大回数を制御します。
retry_timeout_seconds
- XFS が操作の再試行を停止するまでの時間制限を秒単位で指定します。
12.3. 特定の条件に対する XFS 動作の設定
この手順では、XFS が特定のエラー条件にどのように反応するかを設定します。
手順
再試行の最大数、再試行時間制限、またはその両方を設定します。
再試行の最大数を設定するには、必要な数を
max_retries
ファイルに書き込みます。# echo value > /sys/fs/xfs/device/error/metadata/condition/max_retries
時間制限を設定するには、希望する秒数を
retry_timeout_seconds
ファイルに書き込みます。# echo value > /sys/fs/xfs/device/error/metadata/condition/retry_timeout_second
value は、-1 から C 符号付き整数型の可能な最大値です。これは、64 ビットの Linux では 2147483647 です。
いずれの制限も、
-1
の値は継続的な再試行に使用され、0
は即座に停止するために使用されます。device は、
/dev/
ディレクトリーにあるデバイス名です。たとえば、sda
です。
12.4. 未定義の条件に対する XFS 動作の設定
この手順では、XFS が、共通の設定を共有するすべての未定義のエラー条件に反応する方法を設定します。
手順
再試行の最大数、再試行時間制限、またはその両方を設定します。
再試行の最大数を設定するには、必要な数を
max_retries
ファイルに書き込みます。# echo value > /sys/fs/xfs/device/error/metadata/default/max_retries
時間制限を設定するには、希望する秒数を
retry_timeout_seconds
ファイルに書き込みます。# echo value > /sys/fs/xfs/device/error/metadata/default/retry_timeout_seconds
value は、-1 から C 符号付き整数型の可能な最大値です。これは、64 ビットの Linux では 2147483647 です。
いずれの制限も、
-1
の値は継続的な再試行に使用され、0
は即座に停止するために使用されます。device は、
/dev/
ディレクトリーにあるデバイス名です。たとえば、sda
です。
12.5. XFS アンマウント動作の設定
この手順では、ファイルシステムのアンマウント時に XFS がエラー状態に対応するように設定します。
ファイルシステムに fail_at_unmount
オプションを設定すると、マウント解除時にその他すべてのエラー設定が上書きされ、I/O 操作を再試行せずにすぐにファイルシステムをマウント解除します。これにより、永続的なエラーが発生した場合でも、マウント解除操作を成功できます。
マウント解除プロセスの開始後に fail_at_unmount
の値を変更することはできません。アンマウントプロセスにより、設定ファイルが各ファイルシステムの sysfs
インターフェースから削除されます。ファイルシステムのマウント解除を開始する前に、マウント解除動作を設定する必要があります。
手順
fail_at_unmount
オプションを有効または無効にします。ファイルシステムのマウント解除時にすべての操作を再試行する場合は、オプションを有効にします。
# echo 1 > /sys/fs/xfs/device/error/fail_at_unmount
ファイルシステムのマウント解除時に、再試行制限の
max_retries
およびretry_timeout_seconds
を回避するには、オプションを無効にします。# echo 0 > /sys/fs/xfs/device/error/fail_at_unmount
device は、
/dev/
ディレクトリーにあるデバイス名です。たとえば、sda
です。
第13章 ファイルシステムの確認と修復
RHEL は、ファイルシステムの確認および修復が可能なファイルシステム管理ユーティリティーを提供します。このツールは、通常 fsck
ツールと呼ばれることが多く、fsck
は、ファイルシステムチェック を短くした名前になります。ほとんどの場合、このようなユーティリティーは、必要に応じてシステムの起動時に自動的に実行しますが、必要な場合は手動で呼び出すこともできます。
ファイルシステムチェッカーは、ファイルシステム全体のメタデータの整合性のみを保証します。チェッカーは、ファイルシステムに含まれる実際のデータを認識しないため、データのリカバリーツールではありません。
13.1. ファイルシステムの確認が必要なシナリオ
以下のいずれかが発生した場合は、関連する fsck
ツールを使用してシステムを確認できます。
- システムが起動しない
- 特定ディスクのファイルが破損する
- 不整合によりファイルシステムがシャットダウンするか、読み取り専用に変更する
- ファイルシステムのファイルにアクセスできない
ファイルシステムの不整合は、ハードウェアエラー、ストレージ管理エラー、ソフトウェアバグなどのさまざまな理由で発生する可能性があります。
ファイルシステムの確認ツールは、ハードウェアの問題を修復できません。修復を正常に動作させるには、ファイルシステムが完全に読み取り可能かつ書き込み可能である必要があります。ハードウェアエラーが原因でファイルシステムが破損した場合は、まず dd(8)
ユーティリティーなどを使用して、ファイルシステムを適切なディスクに移動する必要があります。
ジャーナリングファイルシステムの場合、システムの起動時に通常必要なのは、必要に応じてジャーナルを再生することだけで、これは通常非常に短い操作になります。
ただし、ジャーナリングファイルシステムであっても、ファイルシステムの不整合や破損が発生した場合は、ファイルシステムチェッカーを使用してファイルシステムを修復する必要があります。
/etc/fstab
の 6 番目のフィールドを 0
に設定すると、システムの起動時にファイルシステムの確認を無効にできます。ただし、Red Hat は、システムの起動時に fsck
に問題がある場合 (非常に大きなファイルシステムやリモートファイルシステムなど) を除いて、無効にすることを推奨しません。
関連情報
-
man ページの
fstab(5)
-
man ページの
fsck(8)
-
man ページの
dd(8)
13.2. fsck の実行による潜在的な悪影響
通常、ファイルシステムの確認および修復のツールを実行すると、検出された不整合の少なくとも一部が自動的に修復されることが期待できます。場合によっては、以下の問題が発生する場合があります。
- inode やディレクトリーが大幅に損傷し、修復できない場合は、破棄される場合があります。
- ファイルシステムが大きく変更する場合があります。
予期しない変更や、望ましくない変更が永続的に行われないようにするには、この手順にまとめられている予防手順を行ってください。
13.3. XFS のエラー処理メカニズム
本セクションでは、XFS がファイルシステム内のさまざまな種類のエラーを処理する方法を説明します。
不完全なアンマウント
ジャーナリングは、ファイルシステムで発生したメタデータの変更のトランザクション記録を保持します。
システムクラッシュ、電源障害、またはその他の不完全なアンマウントが発生した場合、XFS はジャーナル (ログとも呼ばれる) を使用してファイルシステムを復旧します。カーネルは XFS ファイルシステムをマウントするときにジャーナルの復旧を実行します。
破損
この文脈での 破損 は、次のような原因によるファイルシステムのエラーを意味します。
- ハードウェア障害
- ストレージファームウェア、デバイスドライバー、ソフトウェアスタック、またはファイルシステム自体のバグ
- ファイルシステムの一部が、ファイルシステム外の何かにより上書きされる問題
XFS は、ファイルシステムまたはファイルシステムメタデータの破損を検出すると、ファイルシステムをシャットダウンして、システムログにインシデントを報告することがあります。/var
ディレクトリーが置かれているファイルシステムで破損が発生すると、このログは再起動後に利用できなくなります。
例13.1 XFS の破損を報告するシステムログエントリー
# dmesg --notime | tail -15 XFS (loop0): Mounting V5 Filesystem XFS (loop0): Metadata CRC error detected at xfs_agi_read_verify+0xcb/0xf0 [xfs], xfs_agi block 0x2 XFS (loop0): Unmount and run xfs_repair XFS (loop0): First 128 bytes of corrupted metadata buffer: 00000000027b3b56: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000005f9abc7a: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000005b0aef35: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000da9d2ded: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000001e265b07: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000006a40df69: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000000b272907: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000000e484aac5: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ XFS (loop0): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x2 len 1 error 74 XFS (loop0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -117, agno 0 XFS (loop0): Failed to read root inode 0x80, error 11
ユーザー空間ユーティリティーは通常、破損した XFS ファイルシステムにアクセスしようとすると Input/output error メッセージを報告します。破損したログを使用して XFS ファイルシステムをマウントすると、マウントに失敗し、次のエラーメッセージが表示されます。
mount: /mount-point: mount(2) system call failed: Structure needs cleaning.
破損を修復するには、手動で xfs_repair
ユーティリティーを使用する必要があります。
関連情報
-
man ページの
xfs_repair(8)
に、XFS 破損チェックの詳細なリストがあります。
13.4. xfs_repair
で XFS ファイルシステムの確認
この手順では、xfs_repair
ユーティリティーを使用して XFS ファイルシステムの読み取り専用の確認を実行します。破損を修復するには、手動で xfs_repair
ユーティリティーを使用する必要があります。xfs_repair
は、その他のファイルシステム修復ユーティリティーとは異なり、XFS ファイルシステムが正しくアンマウントされていなくても起動時には動作しません。不完全なアンマウントが発生した場合、XFS は単にマウント時にログを再生して、一貫したファイルシステムを確保します。xfs_repair
は、最初にマウントし直さずに、ダーティーログがある XFS ファイルシステムを修復することはできません。
xfsprogs
パッケージには fsck.xfs
バイナリーがありますが、これはシステムの起動時に fsck.file
システムバイナリーを検索する initscripts
を満たすためにのみ存在します。fsck.xfs
は、終了コード 0 で即座に終了します。
手順
ファイルシステムをマウントおよびアンマウントしてログを再生します。
# mount file-system # umount file-system
注記マウントが structure needs cleaning (構造のクリーニングが必要) エラーで失敗した場合は、ログが破損しているため再生できません。ドライランは、結果として、より多くのディスク上の破損を検出して報告する必要があります。
xfs_repair
ユーティリティーを使用してドライランを実行し、ファイルシステムを確認します。エラーが表示され、ファイルシステムを変更せずに実行できるアクションが示されます。# xfs_repair -n block-device
ファイルシステムをマウントします。
# mount file-system
関連情報
-
man ページの
xfs_repair(8)
-
man ページの
xfs_metadump(8)
13.5. xfs_repair で XFS ファイルシステムの修復
この手順では、xfs_repair
ユーティリティーを使用して破損した XFS ファイルシステムを修復します。
手順
xfs_metadump
ユーティリティーを使用して、診断またはテストの目的で、修復する前にメタデータイメージを作成します。修復前のファイルシステムメタデータイメージは、破損がソフトウェアのバグによるものであるかどうかのサポート調査に役立ちます。修復前のイメージに含まれる破損のパターンは、根本的な分析に役に立つ場合があります。xfs_metadump
デバッグツールを使用して、XFS ファイルシステムからファイルにメタデータをコピーします。サポートに大きなメタダンプ
ファイルを送信する必要がある場合は、標準の圧縮ユーティリティーを使用して生成されたメタダンプ
ファイルを圧縮してファイルサイズを縮小できます。# xfs_metadump block-device metadump-file
ファイルシステムを再マウントしてログを再生します。
# mount file-system # umount file-system
アンマウントしたファイルシステムを修復するには、
xfs_repair
ユーティリティーを使用します。マウントが成功した場合、追加のオプションは必要ありません。
# xfs_repair block-device
マウントが Structure needs cleaning エラーで失敗した場合は、ログが破損しているため再生できません。ログを消去するには、
-L
オプション (force log zeroing) を使用します。警告このコマンドを実行すると、クラッシュ時に進行中だったすべてのメタデータの更新が失われます。これにより、ファイルシステムに重大な損傷やデータ損失が生じる可能性があります。これは、ログを再生できない場合に最後の手段としてのみ使用してください。
# xfs_repair -L block-device
ファイルシステムをマウントします。
# mount file-system
関連情報
-
man ページの
xfs_repair(8)
13.6. ext2、ext3、および ext4 でエラー処理メカニズム
ext2、ext3、および ext4 のファイルシステムは、e2fsck
ユーティリティーを使用して、ファイルシステムの確認と修復を実行します。ファイル名の fsck.ext2
、fsck.ext3
、および fsck.ext4
は、e2fsck
ユーティリティーへのハードリンクです。これらのバイナリーは、システムの起動時に自動的に実行し、その動作は確認されるファイルシステムと、そのファイルシステムの状態によって異なります。
完全なファイルシステムの確認および修復は、メタデータジャーナリングファイルシステムではない ext2 や、ジャーナルのない ext4 ファイルシステムに対して呼び出されます。
メタデータジャーナリング機能のある ext3 ファイルシステムおよび ext4 ファイルシステムの場合、ジャーナルはユーザー空間で再生され、ユーティリティーは終了します。これは、ジャーナルの再生によりクラッシュ後のファイルシステムの整合性が確保されるためのデフォルト動作になります。
このファイルシステムで、マウント中にメタデータの不整合が生じると、その事実がファイルシステムのスーパーブロックに記録されます。e2fsck
が、このようなエラーでファイルシステムがマークされていることを検出すると、e2fsck
はジャーナル (がある場合) の再生後にフルチェックを実行します。
関連情報
-
man ページの
fsck(8)
-
man ページの
e2fsck(8)
13.7. e2fsck で ext2、ext3、または ext4 ファイルシステムの確認
この手順では、e2fsck
ユーティリティーを使用して、ext2 ファイルシステム、ext3 ファイルシステム、または ext4 ファイルシステムを確認します。
手順
ファイルシステムを再マウントしてログを再生します。
# mount file-system # umount file-system
ドライランを実行して、ファイルシステムを確認します。
# e2fsck -n block-device
注記エラーが表示され、ファイルシステムを変更せずに実行できるアクションが示されます。整合性の確認後のフェーズでは、修復モードで実行していた場合に前のフェーズで修正されていた不整合が検出される可能性があるため、追加のエラーが出力される場合があります。
関連情報
-
man ページの
e2image(8)
-
man ページの
e2fsck(8)
13.8. e2fsck で ext2、ext3、または ext4 ファイルシステムの修復
この手順では、e2fsck
ユーティリティーを使用して、破損した ext2、ext3、または ext 4 のファイルシステムを修復します。
手順
サポート調査のためにファイルシステムイメージを保存します。修復前のファイルシステムメタデータイメージは、破損がソフトウェアのバグによるものであるかどうかのサポート調査に役立ちます。修復前のイメージに含まれる破損のパターンは、根本的な分析に役に立つ場合があります。
注記ファイルシステムが大幅に損傷している場合は、メタデータイメージの作成に関連して問題が発生する可能性があります。
テスト目的でイメージを作成する場合は、
-r
オプションを使用して、ファイルシステムと同じサイズのスパースファイルを作成します。e2fsck
は、作成されるファイルで直接操作できます。# e2image -r block-device image-file
診断用にアーカイブまたは提供するイメージを作成する場合は、
-Q
オプションを使用して、転送に適したよりコンパクトなファイル形式を作成します。# e2image -Q block-device image-file
ファイルシステムを再マウントしてログを再生します。
# mount file-system # umount file-system
ファイルシステムを自動的に修復します。ユーザーの介入が必要な場合は、
e2fsck
が出力の未修正の問題を示し、このステータスを終了コードに反映させます。# e2fsck -p block-device
関連情報
-
man ページの
e2image(8)
-
man ページの
e2fsck(8)
-
man ページの
第14章 ファイルシステムのマウント
システム管理者は、システムにファイルシステムをマウントすると、ファイルシステムのデータにアクセスできます。
14.1. Linux のマウントメカニズム
本セクションでは、Linux でのファイルシステムのマウントに関する基本概念を説明します。
Linux、UNIX、および類似のオペレーティングシステムでは、さまざまなパーティションおよびリムーバブルデバイス (CD、DVD、USB フラッシュドライブなど) にあるファイルシステムをディレクトリーツリーの特定のポイント (マウントポイント) に接続して、再度切り離すことができます。ファイルシステムがディレクトリーにマウントされている間は、そのディレクトリーの元の内容にアクセスすることはできません。
Linux では、ファイルシステムがすでに接続されているディレクトリーにファイルシステムをマウントできます。
マウント時には、次の方法でデバイスを識別できます。
-
UUID (Universally Unique Identifier) -
UUID=34795a28-ca6d-4fd8-a347-73671d0c19cb
など -
ボリュームラベル -
LABEL=home
など -
非永続的なブロックデバイスへのフルパス -
/dev/sda3
など
デバイス名、目的のディレクトリー、ファイルシステムタイプなど、必要な情報をすべて指定せずに mount
コマンドを使用してファイルシステムをマウントすると、mount
ユーティリティーは /etc/fstab
ファイルの内容を読み取り、指定のファイルシステムが記載されているかどうかを確認します。/etc/fstab
ファイルには、選択したファイルシステムがマウントされるデバイス名およびディレクトリーのリスト、ファイルシステムタイプ、およびマウントオプションが含まれます。そのため、/etc/fstab
で指定されたファイルシステムをマウントする場合は、以下のコマンド構文で十分です。
マウントポイントによるマウント:
# mount directory
ブロックデバイスによるマウント:
# mount device
関連情報
-
man ページの
mount(8)
- UUID などの永続的な命名属性を一覧表示する方法は、「永続的な命名属性の一覧表示」 を参照してください。
14.2. 現在マウントされているファイルシステムの一覧表示
この手順では、コマンドラインに、現在マウントされているファイルシステムの一覧を表示する方法を説明します。
手順
マウントされているファイルシステムの一覧を表示するには、
findmnt
ユーティリティーを使用します。$ findmnt
一覧表示されているファイルシステムを、特定のファイルシステムタイプに制限するには、
--types
オプションを追加します。$ findmnt --types fs-type
以下に例を示します。
例14.1 XFS ファイルシステムのみを表示
$ findmnt --types xfs TARGET SOURCE FSTYPE OPTIONS / /dev/mapper/luks-5564ed00-6aac-4406-bfb4-c59bf5de48b5 xfs rw,relatime ├─/boot /dev/sda1 xfs rw,relatime └─/home /dev/mapper/luks-9d185660-7537-414d-b727-d92ea036051e xfs rw,relatime
関連情報
-
man ページの
findmnt(8)
14.3. mount でファイルシステムのマウント
この手順では、mount
ユーティリティーを使用してファイルシステムをマウントする方法を説明します。
前提条件
選択したマウントポイントにファイルシステムがマウントされていない。
$ findmnt mount-point
手順
特定のファイルシステムを添付する場合は、
mount
ユーティリティーを使用します。# mount device mount-point
例14.2 XFS ファイルシステムのマウント
たとえば、UUID により識別されるローカル XFS ファイルシステムをマウントするには、次のコマンドを実行します。
# mount UUID=ea74bbec-536d-490c-b8d9-5b40bbd7545b /mnt/data
mount
がファイルシステムタイプを自動的に認識できない場合は、--types
オプションで指定します。# mount --types type device mount-point
例14.3 NFS ファイルシステムのマウント
たとえば、リモートの NFS ファイルシステムをマウントするには、次のコマンドを実行します。
# mount --types nfs4 host:/remote-export /mnt/nfs
関連情報
-
man ページの
mount(8)
14.4. マウントポイントの移動
この手順では、マウントされたファイルシステムのマウントポイントを、別のディレクトリーに変更する方法を説明します。
手順
ファイルシステムがマウントされているディレクトリーを変更するには、以下のコマンドを実行します。
# mount --move old-directory new-directory
例14.4 ホームファイルシステムの移動
たとえば、
/mnt/userdirs/
ディレクトリーにマウントされたファイルシステムを/home/
マウントポイントに移動するには、以下のコマンドを実行します。# mount --move /mnt/userdirs /home
ファイルシステムが想定どおりに移動したことを確認します。
$ findmnt $ ls old-directory $ ls new-directory
関連情報
-
man ページの
mount(8)
14.5. umount でファイルシステムのアンマウント
この手順では、umount
ユーティリティーを使用してファイルシステムをアンマウントする方法を説明します。
手順
次のいずれかのコマンドを使用してファイルシステムをアンマウントします。
マウントポイントで行う場合は、以下のコマンドを実行します。
# umount mount-point
デバイスで行う場合は、以下のコマンドを実行します。
# umount device
コマンドが次のようなエラーで失敗した場合は、プロセスがリソースを使用しているため、ファイルシステムが使用中であることを意味します。
umount: /run/media/user/FlashDrive: target is busy.
ファイルシステムが使用中の場合は、
fuser
ユーティリティーを使用して、ファイルシステムにアクセスしているプロセスを特定します。以下に例を示します。$ fuser --mount /run/media/user/FlashDrive /run/media/user/FlashDrive: 18351
その後、ファイルシステムを使用してプロセスを終了し、マウント解除を再度試みます。
14.6. 一般的なマウントオプション
本セクションでは、mount
ユーティリティーでよく使用されるオプションを示します。
オプションは、次の構文で使用できます。
# mount --options option1,option2,option3 device mount-point
表14.1 一般的なマウントオプション
オプション | 説明 |
---|---|
| ファイルシステムで非同期の入出力を可能にします。 |
|
|
|
オプション |
| 特定のファイルシステムでのバイナリーファイルの実行を許可します。 |
| イメージをループデバイスとしてマウントします。 |
|
デフォルトでは、 |
| 特定のファイルシステムでのバイナリーファイルの実行は許可しません。 |
| 普通のユーザー (つまり root 以外のユーザー) によるファイルシステムのマウントおよびアンマウントは許可しません。 |
| ファイルシステムがすでにマウントされている場合は再度マウントを行います。 |
| 読み取り専用でファイルシステムをマウントします。 |
| ファイルシステムを読み取りと書き込み両方でマウントします。 |
| 普通のユーザー (つまり root 以外のユーザー) によるファイルシステムのマウントおよびアンマウントを許可します。 |
14.7. 複数のマウントポイントでのマウント共有
システム管理者は、マウントポイントを複製して、複数のディレクトリーからファイルシステムにアクセスするようにできます。
14.7.2. プライベートマウントポイントの複製の作成
この手順では、マウントポイントをプライベートマウントとして複製します。複製後に、複製または元のマウントポイントにマウントするファイルシステムは、他方のマウントポイントには反映されません。
手順
元のマウントポイントから仮想ファイルシステム (VFS) ノードを作成します。
# mount --bind original-dir original-dir
元のマウントポイントをプライベートとしてマークします。
# mount --make-private original-dir
あるいは、選択したマウントポイントと、その下のすべてのマウントポイントのマウントタイプを変更するには、
--make-private
ではなく、--make-rprivate
オプションを使用します。複製を作成します。
# mount --bind original-dir duplicate-dir
例14.5 プライベートマウントポイントとして /mnt に /media を複製
/media
ディレクトリーから VFS ノードを作成します。# mount --bind /media /media
/media
ディレクトリーをプライベートとしてマークします。# mount --make-private /media
そのコピーを
/mnt
に作成します。# mount --bind /media /mnt
これで、
/media
と/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
関連情報
-
man ページの
mount(8)
14.7.4. スレーブマウントポイントの複製の作成
この手順では、マウントポイントをスレーブマウントとして複製します。複製後に、元のマウントポイントにマウントしたファイルシステムは複製に反映されますが、他のマウントポイントには反映されません。
手順
元のマウントポイントから仮想ファイルシステム (VFS) ノードを作成します。
# mount --bind original-dir original-dir
元のマウントポイントを共有としてマークします。
# mount --make-shared original-dir
あるいは、選択したマウントポイントとその下のすべてのマウントポイントのマウントタイプを変更する場合は、
--make-shared
ではなく、--make-rshared
オプションを使用します。複製を作成し、それをスレーブとしてマークします。
# mount --bind original-dir duplicate-dir # mount --make-slave duplicate-dir
例14.7 スレーブマウントポイントとして /mnt に /media を複製
この例は、/media
ディレクトリーのコンテンツが /mnt
にも表示され、/mnt
ディレクトリーのマウントが /media
に反映されないようにする方法を示しています。
/media
ディレクトリーから VFS ノードを作成します。# mount --bind /media /media
/media
ディレクトリーを共有としてマークします。# mount --make-shared /media
そのコピーを
/mnt
に作成し、スレーブとしてマークします。# 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
関連情報
-
man ページの
mount(8)
14.7.5. マウントポイントが複製されないようにする
この手順では、別のマウントポイントに複製されないように、マウントポイントをバインド不可としてマークします。
手順
マウントポイントのタイプをバインド不可なマウントに変更するには、以下のコマンドを使用します。
# mount --bind mount-point mount-point # mount --make-unbindable mount-point
あるいは、選択したマウントポイントとその下のすべてのマウントポイントのマウントタイプを変更する場合は、
--make-unbindable
の代わりに、--make-runbindable
オプションを使用します。これ以降、このマウントの複製を作成しようとすると、以下のエラーが出て失敗します。
# mount --bind mount-point duplicate-dir mount: wrong fs type, bad option, bad superblock on mount-point, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so
例14.8 /media が複製されないようにする
/media
ディレクトリーが共有されないようにするには、以下のコマンドを実行します。# mount --bind /media /media # mount --make-unbindable /media
関連情報
-
man ページの
mount(8)
14.8. ファイルシステムの永続的なマウント
システム管理者は、ファイルシステムを永続的にマウントして、非リムーバブルストレージを構成できます。
14.8.1. /etc/fstab ファイル
本セクションでは、ファイルシステムの永続的なマウントポイントを制御する /etc/fstab
設定ファイルを説明します。ファイルシステムを永続的にマウントするには、/etc/fstab
を使用することが推奨されます。
/etc/fstab
ファイルの各行は、ファイルシステムのマウントポイントを定義します。空白で区切られた 6 つのフィールドが含まれています。
-
/dev
ディレクトリーの永続的な属性またはパスで識別されるブロックデバイス。 - デバイスがマウントされるディレクトリー。
- デバイス上のファイルシステム。
-
ファイルシステムのマウントオプション。
defaults
オプションは、システムの起動時に、パーティションがデフォルトのオプションでマウントされることを意味します。本セクションでは、x-systemd.option
形式のsystemd
マウントユニットオプションも取り上げます。 -
dump
ユーティリティーのオプションのバックアップを作成します。 -
fsck
ユーティリティーの順序を確認します。
例14.9 /etc/fstab
の /boot
ファイルシステム
ブロックデバイス | マウントポイント | ファイルシステム | オプション | バックアップ | チェック |
---|---|---|---|---|---|
|
|
|
|
|
|
systemd
サービスは、/etc/fstab
のエントリーからマウントユニットを自動的に生成します。
関連情報
-
man ページの
fstab(5)
-
man ページの
systemd.mount(5)
の fstab セクション
14.8.2. /etc/fstab へのファイルシステムの追加
この手順では、/etc/fstab
設定ファイルでファイルシステムの永続マウントポイントを設定する方法を説明します。
手順
ファイルシステムの UUID 属性を調べます。
$ lsblk --fs storage-device
以下に例を示します。
例14.10 パーティションの UUID の表示
$ lsblk --fs /dev/sda1 NAME FSTYPE LABEL UUID MOUNTPOINT sda1 xfs Boot ea74bbec-536d-490c-b8d9-5b40bbd7545b /boot
このマウントポイントのディレクトリーがない場合は、作成します。
# mkdir --parents mount-point
root で
/etc/fstab
ファイルを編集し、ファイルシステムに行を追加します (UUID で識別されます)。以下に例を示します。
例14.11 /etc/fstab の /boot マウントポイント
UUID=ea74bbec-536d-490c-b8d9-5b40bbd7545b /boot xfs defaults 0 0
システムが新しい設定を登録するように、マウントユニットを再生成します。
# systemctl daemon-reload
ファイルシステムをマウントして、設定が機能することを確認します。
# mount mount-point
関連情報
- ファイルシステムを識別するために使用できるその他の永続的な属性: 「/dev/disk/ にある udev メカニズムにより管理されるデバイス名」
14.8.3. RHEL システムロールを使用したファイルシステムの永続的なマウント
本セクションでは、storage
ロールを使用して、ファイルシステムを永続的にマウントする方法を説明します。
前提条件
storage
ロールを使用する Ansible Playbook がある。このような Playbook を適用する方法は、「ロールの適用」 を参照してください。
14.8.3.1. ファイルシステムを永続的にマウントする Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage
ロールをすぐに適用して、XFS ファイルシステムを永続的にマウントします。
例14.12 /dev/sdb のファイルシステムを /mnt/data にマウントする Playbook
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs mount_point: /mnt/data roles: - rhel-system-roles.storage
-
この Playbook では、ファイルシステムが
/etc/fstab
ファイルに追加され、すぐにファイルシステムをマウントします。 -
/dev/sdb
デバイス上のファイルシステム、またはマウントポイントのディレクトリーが存在しない場合は、Playbook により作成されます。
関連情報
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
14.8.3.2. 関連情報
-
storage
ロールの詳細は、「storage ロールの概要」 を参照してください。
14.9. オンデマンドでのファイルシステムのマウント
システム管理者は、NFS などのファイルシステムをオンデマンドで自動的にマウントするように設定できます。
14.9.1. autofs サービス
本セクションでは、ファイルシステムをオンデマンドでマウントするのに使用する autofs
サービスの利点と基本概念を説明します。
/etc/fstab
設定を使用した永続的なマウントの欠点の 1 つは、マウントされたファイルシステムにユーザーがアクセスする頻度に関わらず、マウントされたファイルシステムを所定の場所で維持するために、システムがリソースを割り当てる必要があることです。これは、システムが一度に多数のシステムへの NFS マウントを維持している場合などに、システムのパフォーマンスに影響を与える可能性があります。
/etc/fstab
に代わるのは、カーネルベースの autofs
サービスの使用です。これは以下のコンポーネントで構成されています。
- ファイルシステムを実装するカーネルモジュール
- 他のすべての機能を実行するユーザー空間サービス
autofs
サービスは、ファイルシステムの自動マウントおよび自動アンマウントが可能なため (オンデマンド)、システムのリソースを節約できます。このサービスは、NFS、AFS、SMBFS、CIFS、およびローカルなどのファイルシステムをマウントする場合にも使用できます。
関連情報
-
man ページの
autofs(8)
14.9.2. autofs 設定ファイル
本セクションでは、autofs
サービスで使用される設定ファイルの使用方法と構文を説明します。
マスターマップファイル
autofs
サービスは、デフォルトの主要設定ファイルとして、/etc/auto.master
(マスターマップ) を使用します。これは、/etc/autofs.conf
設定ファイルの autofs
設定を Name Service Switch (NSS) メカニズムとともに使用することで、対応している別のネットワークソースと名前を使用するように変更できます。
すべてのオンデマンドマウントポイントはマスターマップで設定する必要があります。マウントポイント、ホスト名、エクスポートされたディレクトリー、オプションはすべて、ホストごとに手動で設定するのではなく、一連のファイル (またはサポートされているその他のネットワークソース) で指定できます。
マスターマップファイルには、autofs
により制御されるマウントポイントと、それに対応する設定ファイルまたは自動マウントマップと呼ばれるネットワークソースが一覧表示されます。マスターマップの形式は次のとおりです。
mount-point map-name options
この形式で使用されている変数を以下に示します。
- mount-point
-
autofs
マウントポイント (例:/mnt/data/
) です。 - map-file
- マウントポイントの一覧と、マウントポイントがマウントされるファイルシステムの場所が記載されているマップソースファイルです。
- options
- 指定した場合に、エントリーにオプションが指定されていなければ、指定されたマップ内のすべてのエントリーに適用されます。
例14.13 /etc/auto.master ファイル
以下は /etc/auto.master
ファイルのサンプル行です。
/mnt/data /etc/auto.data
マップファイル
マップファイルは、個々のオンデマンドマウントポイントのプロパティを設定します。
ディレクトリーが存在しない場合、自動マウント機能はディレクトリーを作成します。ディレクトリーが存在している状況で自動マウント機能が起動した場合は、自動マウント機能の終了時にディレクトリーが削除されることはありません。タイムアウトを指定した場合は、タイムアウト期間中ディレクトリーにアクセスしないと、ディレクトリーが自動的にアンマウントされます。
マップの一般的な形式は、マスターマップに似ています。ただし、マスターマップでは、オプションフィールドはエントリーの末尾ではなく、マウントポイントと場所の間に表示されます。
mount-point options location
この形式で使用されている変数を以下に示します。
- mount-point
-
これは、
autofs
のマウントポイントを参照しています。これは 1 つのインダイレクトマウント用の 1 つのディレクトリー名にすることも、複数のダイレクトマウント用のマウントポイントの完全パスにすることもできます。ダイレクトマップとインダイレクトマップの各エントリーキー (mount-point) の後に空白で区切られたオフセットディレクトリー (/
で始まるサブディレクトリー名) が記載されます。これがマルチマウントエントリーと呼ばれるものです。 - options
- オプションを指定すると、これはそのマップエントリー用のマウントオプションになります。エントリー自体にはオプション指定を行いません。このフィールドは任意です。
- location
-
ローカルファイルシステムのパス (Sun マップ形式のエスケープ文字
:
が先頭に付き、マップ名が/
で始まります)、NFS ファイルシステム、他の有効なファイルシステムの場所などのファイルシステムの場所を参照します。
例14.14 マップファイル
以下は、マップファイルのサンプルです (例: /etc/auto.misc
)。
payroll -fstype=nfs4 personnel:/dev/disk/by-uuid/52b94495-e106-4f29-b868-fe6f6c2789b1 sales -fstype=xfs :/dev/disk/by-uuid/5564ed00-6aac-4406-bfb4-c59bf5de48b5
マップファイルの最初の列は、autofs
マウントポイント (personnel
サーバーからの sales
と payroll
) を示しています。2 列目は、autofs
マウントのオプションを示しています。3 列目はマウントのソースを示しています。
任意の設定に基づき、autofs
マウントポイントは、/home/payroll
と /home/sales
になります。-fstype=
オプションは省略されることが多く、通常は正しい操作には必要ありません。
与えられた設定を使用して、プロセスが /home/payroll/2006/July.sxc
などのアンマウントされたディレクトリー autofs
へのアクセスを要求すると、autofs
サービスは自動的にディレクトリーをマウントします。
amd マップ形式
autofs
サービスは、amd
形式のマップ設定も認識します。これは Red Hat Enterprise Linux から削除された、am-utils
サービス用に書き込まれた既存の自動マウント機能の設定を再利用する場合に便利です。
ただし、Red Hat は、前述のセクションで説明した簡単な autofs
形式の使用を推奨しています。
関連情報
-
man ページの
autofs(5)
、autofs.conf(5)
、およびauto.master(5)
-
amd
マップ形式の詳細は、autofs
パッケージで提供されている/usr/share/doc/autofs/README.amd-maps
ファイルを参照してください。
14.9.3. autofs マウントポイントの設定
この手順では、autofs
サービスを使用してオンデマンドマウントポイントを設定する方法を説明します。
前提条件
autofs
パッケージをインストールしている。# yum install autofs
autofs
サービスを起動して有効にしている。# systemctl enable --now autofs
手順
-
/etc/auto.identifier
にあるオンデマンドマウントポイント用のマップファイルを作成します。identifier を、マウントポイントを識別する名前に置き換えます。 - マップファイルで、「autofs 設定ファイル」 の説明に従って、マウントポイント、オプション、および場所のフィールドを入力します。
- 「autofs 設定ファイル」 の説明に従って、マスターマップファイルにマップファイルを登録します。
オンデマンドディレクトリーのコンテンツへのアクセスを試みます。
$ ls automounted-directory
14.9.4. autofs サービスを使用した NFS サーバーユーザーのホームディレクトリーの自動マウント
この手順では、ユーザーのホームディレクトリーを自動的にマウントするように autofs サービスを設定する方法を説明します。
前提条件
- autofs パッケージがインストールされている。
- autofs サービスが有効で、実行している。
手順
ユーザーのホームディレクトリーをマウントする必要があるサーバーの
/etc/auto.master
ファイルを編集して、マップファイルのマウントポイントと場所を指定します。これを行うには、以下の行を/etc/auto.master
ファイルに追加します。/home /etc/auto.home
ユーザーのホームディレクトリーをマウントする必要があるサーバー上で、
/etc/auto.home
という名前のマップファイルを作成し、以下のパラメーターでファイルを編集します。* -fstype=nfs,rw,sync host.example.com:/home/&i
fstype
パラメーターはデフォルトでnfs
であるため、このパラメーターは飛ばして次に進むことができます。詳細は、autofs(5)
man ページを参照してください。autofs
サービスを再読み込みします。# systemctl reload autofs
14.9.5. autofs サイトの設定ファイルの上書き/拡張
クライアントシステムの特定のマウントポイントで、サイトのデフォルトを上書きすることが役に立つ場合があります。
例14.15 初期条件
たとえば、次の条件を検討します。
自動マウント機能のマップが 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
ファイルマップが存在しない。
例14.16 別のサーバーからのホームディレクトリーのマウント
上記の条件で、クライアントシステムが NIS マップの auto.home
を上書きして、別のサーバーからホームディレクトリーをマウントする必要があるとします。
この場合、クライアントは次の
/etc/auto.master
マップを使用する必要があります。/home /etc/auto.home +auto.master
/etc/auto.home
マップにエントリーが含まれています。* host.example.com:/export/home/&
自動マウント機能は最初に出現したマウントポイントのみを処理するため、/home
ディレクトリーには NIS auto.home
マップではなく、/etc/auto.home
の内容が含まれます。
例14.17 選択されたエントリーのみを使用した auto.home の拡張
別の方法として、サイト全体の auto.home
マップを少しのエントリーを使用して拡張するには、次の手順を行います。
/etc/auto.home
ファイルマップを作成し、そこに新しいエントリーを追加します。最後に、NIS のauto.home
マップを含めます。これにより、/etc/auto.home
ファイルマップは次のようになります。mydir someserver:/export/mydir +auto.home
この NIS の
auto.home
マップ条件で、/home
ディレクトリーの出力内容を一覧表示すると次のようになります。$ ls /home beth joe mydir
autofs
は、読み取り中のファイルマップと同じ名前のファイルマップの内容を組み込まないため、上記の例は期待どおりに動作します。このように、autofs
は、nsswitch
設定内の次のマップソースに移動します。
14.9.6. LDAP で自動マウント機能マップの格納
この手順では、autofs
マップファイルではなく、LDAP 設定で自動マウント機能マップを格納するように autofs
を設定します。
前提条件
-
LDAP から自動マウント機能マップを取得するように設定されているすべてのシステムに、LDAP クライアントライブラリーをインストールする必要があります。Red Hat Enterprise Linux では、
openldap
パッケージは、autofs
パッケージの依存関係として自動的にインストールされます。
手順
-
LDAP アクセスを設定するには、
/etc/openldap/ldap.conf
ファイルを変更します。BASE
、URI
、schema
の各オプションがサイトに適切に設定されていることを確認します。 自動マウント機能マップを LDAP に格納するために既定された最新のスキーマが、
rfc2307bis
ドラフトに記載されています。このスキーマを使用する場合は、スキーマの定義のコメント文字を取り除き、/etc/autofs.conf
設定ファイル内に設定する必要があります。以下に例を示します。例14.18 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) 設定の例です。例14.19 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/&
関連情報
-
rfc2307bis
ドラフト - https://tools.ietf.org/html/draft-howard-rfc2307bis
14.10. root ファイルシステムに対する読み取り専用パーミッションの設定
場合によっては、root ファイルシステム (/
) を読み取り専用パーミッションでマウントする必要があります。ユースケースの例には、システムの予期せぬ電源切断後に行うセキュリティーの向上またはデータ整合性の保持が含まれます。
14.10.1. 書き込みパーミッションを保持するファイルおよびディレクトリー
システムが正しく機能するためには、一部のファイルやディレクトリーで書き込みパーミッションが必要とされます。root ファイルシステムが読み取り専用モードでマウントされると、このようなファイルは、tmpfs
一時ファイルシステムを使用して RAM にマウントされます。
そのようなファイルとディレクトリーのデフォルトセットは、/etc/rwtab
ファイルから読み取り、以下のような内容になっています。
dirs /var/cache/man dirs /var/gdm <content truncated> empty /tmp empty /var/cache/foomatic <content truncated> files /etc/adjtime files /etc/ntp.conf <content truncated>
/etc/rwtab
ファイルのエントリーは、以下の形式に従います。
copy-method path
この構文で、以下のことを行います。
- copy-method を、ファイルまたはディレクトリーを tmpfs にコピーする方法を指定するキーワードの 1 つに置き換えます。
- path を、ファイルまたはディレクトリーへのパスに置き換えます。
/etc/rwtab
ファイルは、ファイルまたはディレクトリーを tmpfs
にコピーする方法として以下を認識します。
empty
空のパスが
tmpfs
にコピーされます。以下に例を示します。empty /tmp
dirs
ディレクトリーツリーが空の状態で
tmpfs
にコピーされます。以下に例を示します。dirs /var/run
files
ファイルやディレクトリーツリーはそのまま
tmpfs
にコピーされます。以下に例を示します。files /etc/resolv.conf
カスタムパスを /etc/rwtab.d/
に追加する場合も同じ形式が適用されます。
14.10.2. ブート時に読み取り専用パーミッションでマウントするように root ファイルシステムの設定
この手順を行うと、今後システムが起動するたびに、root ファイルシステムが読み取り専用としてマウントされます。
手順
/etc/sysconfig/readonly-root
ファイルで、READONLY
オプションをyes
に設定します。# Set to 'yes' to mount the file systems as read-only. READONLY=yes
/etc/fstab
ファイルの root エントリー (/
) にro
オプションを追加します。/dev/mapper/luks-c376919e... / xfs x-systemd.device-timeout=0,ro 1 1
ro
オプションを/etc/default/grub
ファイルのGRUB_CMDLINE_LINUX
ディレクティブに追加し、ディレクティブにrw
が含まれていないことを確認します。GRUB_CMDLINE_LINUX="rhgb quiet... ro"
GRUB2 設定ファイルを再作成します。
# grub2-mkconfig -o /boot/grub2/grub.cfg
tmpfs
ファイルシステムに書き込みパーミッションでマウントするファイルとディレクトリーを追加する必要がある場合は、/etc/rwtab.d/
ディレクトリーにテキストファイルを作成し、そこに設定を置きます。たとえば、
/etc/example/file
ファイルを書き込みパーミッションでマウントするには、この行を/etc/rwtab.d/example
ファイルに追加します。files /etc/example/file
重要tmpfs
のファイルおよびディレクトリーの変更内容は、再起動後は持続しません。- システムを再起動して変更を適用します。
トラブルシューティング
誤って読み取り専用パーミッションで root ファイルシステムをマウントした場合は、次のコマンドを使用して、読み書きパーミッションで再度マウントできます。
# mount -o remount,rw /
第15章 クォータによるストレージ領域の使用量の制限
ディスククォータを実装して、ユーザーまたはグループに利用可能なディスク領域のサイズを制限できます。ユーザーがディスク領域を過剰に消費したり、パーティションが満杯になる前に、システム管理者に通知を出す警告レベルを定義することもできます。
15.1. ディスククォータ
ほとんどのコンピューティング環境では、ディスク領域は無限ではありません。クォータサブシステムは、ディスク領域の使用量を制御するメカニズムを提供します。
ディスククォータは、ローカルファイルシステムの個々のユーザーおよびユーザーグループに設定できます。これにより、ユーザー固有のファイル (電子メールなど) に割り当てられる領域を、ユーザーが作業するプロジェクトに割り当てられた領域とは別に管理できます。クォータサブシステムは、割り当てられた制限を超えるとユーザーに警告しますが、現在の作業に追加領域を許可します (ハード制限/ソフト制限)。
クォータが実装されている場合は、クォータを超過しているかどうかを確認して、クォータが正しいことを確認する必要があります。ユーザーが繰り返しクォータを超過するか、常にソフト制限に達している場合、システム管理者は、ユーザーが使用するディスク領域を減らすか、ユーザーのディスククォータを増やす方法を決定するのを助けることができます。
クォータは、以下を制御するように設定できます。
- 消費されるディスクブロックの数。
- UNIX ファイルシステムのファイルに関する情報を含むデータ構造である inode の数。inode はファイル関連の情報を保存するため、作成可能なファイルの数を制御できます。
15.1.1. xfs_quota
ツール
xfs_quota
ツールを使用して、XFS ファイルシステム上のクォータを管理できます。さらに、有効なディスク使用量のアカウンティングシステムとして、制限の強制適用をオフにして XFS ファイルシステムを使用できます。
XFS クォータシステムは、他のファイルシステムとはさまざまな点で異なります。最も重要な点として、XFS はクォータ情報をファイルシステムのメタデータとみなし、ジャーナリングを使用して一貫性のより高いレベルの保証を提供します。
関連情報
-
xfs_quota(8)
man ページ
15.2. XFS ディスククォータの管理
xfs_quota
ツールを使用して XFS でクォータを管理し、プロジェクトで制御されるディレクトリーに制限を設定できます。
汎用クォータ設定ツール (quota
、repquota
、edquota
など) を使用して XFS クォータを操作することもできます。ただし、このツールは XFS プロジェクトクォータでは使用できません。
Red Hat は、他の利用可能なすべてのツールで xfs_quota
を使用することを推奨します。
15.2.1. XFS でのファイルシステムクォータ管理
XFS クォータサブシステムは、ディスク領域 (ブロック) およびファイル (inode) の使用量の制限を管理します。XFS クォータは、ユーザー、グループ、ディレクトリーレベル、またはプロジェクトレベルでこれらの項目の使用を制御または報告します。グループおよびプロジェクトのクォータは、古いデフォルト以外の XFS ディスクフォーマットでのみ相互に排他的です。
ディレクトリーまたはプロジェクトごとに管理する場合、XFS は特定のプロジェクトに関連付けられたディレクトリー階層のディスク使用量を管理します。
15.2.2. XFS のディスククォータの有効化
この手順では、XFS ファイルシステムのユーザー、グループ、およびプロジェクトのディスククォータを有効にします。クォータを有効にすると、xfs_quota
ツールを使用して制限を設定し、ディスク使用量を報告できます。
手順
ユーザーのクォータを有効にします。
# mount -o uquota /dev/xvdb1 /xfs
uquota
をuqnoenforce
に置き換えて、制限を強制適用せずに使用状況の報告を可能にします。グループのクォータを有効にします。
# mount -o gquota /dev/xvdb1 /xfs
gquota
をgqnoenforce
に置き換えて、制限を強制適用せずに使用状況の報告を可能にします。プロジェクトのクォータを有効にします。
# mount -o pquota /dev/xvdb1 /xfs
pquota
をpqnoenforce
に置き換え、制限を強制適用せずに使用状況の報告を可能にします。または、
/etc/fstab
ファイルにクォータマウントオプションを追加します。以下の例は、XFS ファイルシステムでユーザー、グループ、およびプロジェクトのクォータを有効にする/etc/fstab
ファイルのエントリーを示しています。以下の例では、読み取り/書き込みパーミッションでファイルシステムもマウントします。# vim /etc/fstab /dev/xvdb1 /xfs xfs rw,quota 0 0 /dev/xvdb1 /xfs xfs rw,gquota 0 0 /dev/xvdb1 /xfs xfs rw,prjquota 0 0
関連情報
-
man ページの
mount(8)
-
xfs_quota(8)
man ページ
-
man ページの
15.2.3. XFS 使用量の報告
xfs_quota
ツールを使用して制限を設定し、ディスク使用量を報告できます。xfs_quota
は、デフォルトでは対話形式で基本モードで実行されます。基本モードのサブコマンドは使用量を報告するだけで、すべてのユーザーが使用できます。
前提条件
- XFS ファイルシステムに対してクォータが有効になっている。「XFS のディスククォータの有効化」を参照してください。
手順
xfs_quota
シェルを起動します。# xfs_quota
指定したユーザーの使用状況および制限を表示します。
# xfs_quota> quota username
ブロックおよび inode の空きおよび使用済みの数を表示します。
# xfs_quota> df
help コマンドを実行して、
xfs_quota
で利用可能な基本的なコマンドを表示します。# xfs_quota> help
q
を指定してxfs_quota
を終了します。# xfs_quota> q
関連情報
-
xfs_quota(8)
man ページ
15.2.4. XFS クォータ制限の変更
-x
オプションを指定して xfs_quota
ツールを起動し、エキスパートモードを有効にして、クォータシステムを変更できる管理者コマンドを実行します。このモードのサブコマンドは、制限を実際に設定することができるため、昇格した特権を持つユーザーのみが利用できます。
前提条件
- XFS ファイルシステムに対してクォータが有効になっている。「XFS のディスククォータの有効化」を参照してください。
手順
エキスパートモードを有効にするには、
-x
オプションを指定してxfs_quota
シェルを起動します。# xfs_quota -x
特定のファイルシステムのクォータ情報を表示します。
# xfs_quota> report /path
たとえば、(
/dev/blockdevice
の)/home
のクォータレポートのサンプルを表示するには、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 [------]
クォータの制限を変更します。
# xfs_quota> limit isoft=500m ihard=700m user /path
たとえば、ホームディレクトリーが
/home/john
のユーザーjohn
に対して、inode 数のソフト制限およびハード制限をそれぞれ 500 と 700 に設定するには、次のコマンドを使用します。# xfs_quota -x -c 'limit isoft=500 ihard=700 john' /home/
この場合は、マウントされた xfs ファイルシステムである
mount_point
を渡します。help コマンドを実行して、
xfs_quota -x
で利用可能なエキスパートコマンドを表示します。# xfs_quota> help
関連情報
-
xfs_quota(8)
man ページ
-
15.2.5. XFS のプロジェクト制限の設定
以下の手順では、プロジェクトが制御するディレクトリーに制限を設定します。
手順
プロジェクトが制御するディレクトリーを
/etc/projects
に追加します。たとえば、以下は一意の ID が 11 の/var/log
パスを/etc/projects
に追加します。プロジェクト ID には、プロジェクトにマッピングされる任意の数値を指定できます。# echo 11:/var/log >> /etc/projects
/etc/projid
にプロジェクト名を追加して、プロジェクト ID をプロジェクト名にマップします。たとえば、以下は、前のステップで定義されたようにLogs
というプロジェクトをプロジェクト ID 11 に関連付けます。# echo Logs:11 >> /etc/projid
プロジェクトのディレクトリーを初期化します。たとえば、以下はプロジェクトディレクトリー
/var
を初期化します。# xfs_quota -x -c 'project -s logfiles' /var
初期化したディレクトリーでプロジェクトのクォータを設定します。
# xfs_quota -x -c 'limit -p bhard=lg logfiles' /var
関連情報
-
xfs_quota(8)
man ページ -
projid(5)
man ページ -
projects(5)
man ページ
-
15.3. ext3 および ext4 のディスククォータの管理
ディスククォータを割り当てる前に、システムでディスククォータを有効にする必要があります。ユーザーごと、グループごと、またはプロジェクトごとにディスククォータを割り当てることができます。ただし、ソフト制限が設定されている場合は、猶予期間として知られる設定可能な期間として、これらのクォータを超過できます。
15.3.1. クォータツールのインストール
ディスククォータを実装するには、RPM パッケージ quota
をインストールする必要があります。
手順
-
quota
パッケージをインストールします。
# yum install quota
15.3.2. ファイルシステム作成でクォータ機能の有効化
この手順では、ファイルシステムの作成時にクォータを有効にする方法を説明します。
手順
ファイルシステムの作成時にクォータを有効にします。
# mkfs.ext4 -O quota /dev/sda
注記デフォルトでは、ユーザーとグループのクォータのみが有効になり、初期化されます。
ファイルシステムの作成時にデフォルトを変更します。
# mkfs.ext4 -O quota -E quotatype=usrquota:grpquota:prjquota /dev/sda
ファイルシステムをマウントします。
# mount /dev/sda
関連情報
詳細は、ext4
の man
ページを参照してください。
15.3.3. 既存のファイルシステムでのクォータ機能の有効化
この手順では、tune2fs
コマンドを使用して、既存のファイルシステムでクォータ機能を有効にする方法を説明します。
手順
ファイルシステムをアンマウントします。
# umount /dev/sda
既存のファイルシステムでクォータを有効にします。
# tune2fs -O quota /dev/sda
注記デフォルトでは、ユーザーとグループのクォータのみが初期化されます。
デフォルトを変更します。
# tune2fs -Q usrquota,grpquota,prjquota /dev/sda
ファイルシステムをマウントします。
# mount /dev/sda
関連情報
詳細は、ext4
の man
ページを参照してください。
15.3.4. クォータ強制適用の有効化
クォータアカウンティングは、追加のオプションを使用せsずにファイルシステムをマウントした後にデフォルトで有効になりますが、クォータの強制適用は行いません。
前提条件
- クォータ機能が有効になり、デフォルトのクォータが初期化されます。
手順
ユーザークォータに対して、
quotaon
によるクォータの強制適用を有効にします。# mount /dev/sda /mnt
# quotaon /mnt
注記クォータの強制適用は、マウントオプション
usrquota
、grpquota
、またはprjquota
を使用して、マウント時に有効にできます。# mount -o usrquota,grpquota,prjquota /dev/sda /mnt
すべてのファイルシステムのユーザー、グループ、およびプロジェクトのクォータを有効にします。
# quotaon -vaugP
-
-u
オプション、-g
オプション、または-P
オプションがいずれも指定されていないと、ユーザーのクォータのみが有効になります。 -
-g
オプションのみを指定すると、グループのクォータのみが有効になります。 -
-P
オプションのみを指定すると、プロジェクトのクォータのみが有効になります。
-
/home
などの特定のファイルシステムのクォータを有効にします。# quotaon -vugP /home
関連情報
-
quotaon(8)
man ページを参照してください。
15.3.5. ユーザーごとにクォータの割り当て
ディスククォータは、edquota
コマンドでユーザーに割り当てられます。
EDITOR
環境変数により定義されたテキストエディターは、edquota
により使用されます。エディターを変更するには、~/.bash_profile
ファイルの EDITOR
環境変数を、使用するエディターのフルパスに設定します。
前提条件
- ユーザーは、ユーザークォータを設定する前に存在する必要があります。
手順
ユーザーにクォータを割り当てます。
# edquota username
username を、クォータを割り当てるユーザーに置き換えます。
たとえば、
/dev/sda
パーティションのクォータを有効にし、edquota testuser
コマンドを実行すると、システムに設定したデフォルトエディターに以下が表示されます。Disk quotas for user testuser (uid 501): Filesystem blocks soft hard inodes soft hard /dev/sda 44043 0 0 37418 0 0
必要な制限を変更します。
いずれかの値が 0 に設定されていると、制限は設定されません。テキストエディターでこれらを変更します。
たとえば、以下は、testuser のソフトブロック制限とハードブロック制限をそれぞれ 50000 と 55000 に設定していることを示しています。
Disk quotas for user testuser (uid 501): Filesystem blocks soft hard inodes soft hard /dev/sda 44043 50000 55000 37418 0 0
- 最初の列は、クォータが有効になっているファイルシステムの名前です。
- 2 列目には、ユーザーが現在使用しているブロック数が示されます。
- その次の 2 列は、ファイルシステム上のユーザーのソフトブロック制限およびハードブロック制限を設定するのに使用されます。
-
inodes
列には、ユーザーが現在使用している inode 数が表示されます。 最後の 2 列は、ファイルシステムのユーザーに対するソフトおよびハードの inode 制限を設定するのに使用されます。
- ハードブロック制限は、ユーザーまたはグループが使用できる最大ディスク容量 (絶対値) です。この制限に達すると、それ以上のディスク領域は使用できなくなります。
- ソフトブロック制限は、使用可能な最大ディスク容量を定義します。ただし、ハード制限とは異なり、ソフト制限は一定時間超過する可能性があります。この時間は 猶予期間 として知られています。猶予期間の単位は、秒、分、時間、日、週、または月で表されます。
検証手順
ユーザーのクォータが設定されていることを確認します。
# quota -v testuser Disk quotas for user testuser: Filesystem blocks quota limit grace files quota limit grace /dev/sda 1000* 1000 1000 0 0 0
15.3.6. グループごとにクォータの割り当て
グループごとにクォータを割り当てることができます。
前提条件
- グループは、グループクォータを設定する前に存在している必要があります。
手順
グループクォータを設定します。
# edquota -g groupname
たとえば、
devel
グループのグループクォータを設定するには、以下を実行します。# edquota -g devel
このコマンドにより、グループの既存クォータがテキストエディターに表示されます。
Disk quotas for group devel (gid 505): Filesystem blocks soft hard inodes soft hard /dev/sda 440400 0 0 37418 0 0
- 制限を変更し、ファイルを保存します。
検証手順
グループクォータが設定されていることを確認します。
# quota -vg groupname
15.3.7. プロジェクトごとにクォータの割り当て
以下の手順では、プロジェクトごとにクォータを割り当てます。
前提条件
- プロジェクトクォータがファイルシステムで有効になっている。
手順
プロジェクトが制御するディレクトリーを
/etc/projects
に追加します。たとえば、以下は一意の ID が 11 の/var/log
パスを/etc/projects
に追加します。プロジェクト ID には、プロジェクトにマッピングされる任意の数値を指定できます。# echo 11:/var/log >> /etc/projects
/etc/projid
にプロジェクト名を追加して、プロジェクト ID をプロジェクト名にマップします。たとえば、以下は、前のステップで定義されたようにLogs
というプロジェクトをプロジェクト ID 11 に関連付けます。# echo Logs:11 >> /etc/projid
必要な制限を設定します。
# edquota -P 11
注記プロジェクトは、プロジェクト ID (この場合は
11
)、または名前 (この場合はLogs
) で選択できます。quotaon
を使用して、クォータの強制適用を有効にします。「クォータ強制適用の有効化」を参照してください。
検証手順
プロジェクトのクォータが設定されていることを確認します。
# quota -vP 11
注記プロジェクト ID またはプロジェクト名のいずれかで検証できます。
関連情報
-
edquota(8)
man ページ -
projid(5)
man ページ -
projects(5)
man ページ
15.3.8. ソフト制限の猶予期間の設定
特定のクォータにソフト制限がある場合、猶予期間 (ソフト制限を超過できる期間) を編集できます。ユーザー、グループ、またはプロジェクトの猶予期間を設定できます。
手順
猶予期間を編集します。
# edquota -t
他の edquota
コマンドは特定のユーザー、グループ、またはプロジェクトのクォータで機能しますが、-t
オプションはクォータが有効になっているすべてのファイルシステムで機能します。
関連情報
-
edquota(8)
man ページ
15.3.9. ファイルシステムのクォータをオフにする
quotaoff
を使用して、指定されたファイルシステムでディスククォータの強制適用をオフにします。クォータアカウンティングは、このコマンド実行後も有効のままになります。
手順
すべてのユーザーとグループのクォータをオフにするには、次のコマンドを実行します。
# quotaoff -vaugP
-
-u
オプション、-g
オプション、または-P
オプションがいずれも指定されていないと、ユーザーのクォータのみが無効になります。 -
-g
オプションのみを指定すると、グループクォータのみが無効になります。 -
-P
オプションのみを指定すると、プロジェクトのクォータのみが無効になります。 -
-v
スイッチにより、コマンドの実行時に詳細なステータス情報が表示されます。
-
関連情報
-
quotaoff(8)
man ページを参照してください。
15.3.10. ディスククォータに関するレポート
repquota
ユーティリティーを使用してディスククォータレポートを作成できます。
手順
repquota
コマンドを実行します。# repquota
たとえば、
repquota /dev/sda
コマンドは次のような出力を生成します。*** Report for user quotas on device /dev/sda 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
クォータが有効化された全ファイルシステムのディスク使用状況レポートを表示します。
# repquota -augP
各ユーザーに続いて表示される --
記号で、ブロックまたは inode の制限を超えたかどうかを簡単に判断できます。ソフト制限のいずれかを超えると、対応する -
文字の代わりに +
文字が表示されます。最初の -
文字はブロック制限を表し、次の文字は inode 制限を表します。
通常、grace
列は空白です。ソフト制限が超過した場合、その列には猶予期間に残り時間量に相当する時間指定が含まれます。猶予期間の期間が過ぎると、その時間には 何も
表示されません。
関連情報
詳細は、repquota(8)
man ページを参照してください。
第16章 未使用ブロックの破棄
破棄操作に対応するブロックデバイスで破棄操作を実行するか、そのスケジュールを設定できます。
16.1. ブロックの破棄操作
ブロック破棄操作では、マウントされたファイルシステムで使用されていないブロックを破棄します。これは以下に役立ちます。
- ソリッドステートドライブ (SSD)
- シンプロビジョニングされたストレージ
要件
ファイルシステムの基礎となるブロックデバイスは、物理的な破棄操作に対応している必要があります。
/sys/block/device/queue/discard_max_bytes
ファイルの値がゼロではない場合は、物理的な破棄操作に対応しています。
16.2. ブロック破棄操作のタイプ
以下のような、さまざまな方法で破棄操作を実行できます。
- バッチ破棄
- ユーザーが明示的に実行します。選択したファイルシステムのすべての未使用ブロックを破棄します。
- オンライン破棄
- マウント時に指定されます。ユーザーによる介入なしでリアルタイムで実行されます。オンライン破棄操作は、使用中から空きに移行しているブロックのみを破棄します。
- 定期的な破棄
-
systemd
サービスが定期的に実行するバッチ操作です。
すべてのタイプは、XFS ファイルシステム、ext4 ファイルシステム、および VDO で対応されています。
推奨事項
Red Hat は、バッチ破棄または周期破棄を使用することを推奨します。
以下の場合にのみ、オンライン破棄を使用してください。
- システムのワークロードでバッチ破棄が実行できない場合
- パフォーマンス維持にオンライン破棄操作が必要な場合
16.3. バッチブロック破棄の実行
この手順では、バッチによるブロック破棄操作を実行し、マウントされたファイルシステムの未使用ブロックを破棄します。
前提条件
- ファイルシステムがマウントされている。
- ファイルシステムの基礎となるブロックデバイスが物理的な破棄操作に対応している。
手順
fstrim
ユーティリティーを使用します。選択したファイルシステムでのみ破棄を実行するには、次のコマンドを使用します。
# fstrim mount-point
マウントされているすべてのファイルシステムで破棄を実行するには、次のコマンドを使用します。
# fstrim --all
fstrim
コマンドを以下のいずれかで実行している場合は、
- 破棄操作に対応していないデバイス
- 複数のデバイスから構成され、そのデバイスの 1 つが破棄操作に対応していない論理デバイス (LVM または MD)
次のメッセージが表示されます。
# fstrim /mnt/non_discard fstrim: /mnt/non_discard: the discard operation is not supported
関連情報
-
man ページの
fstrim(8)
16.4. オンラインブロック破棄の有効化
この手順は、サポートされるすべてのファイルシステムで、未使用のブロックを自動的に破棄するオンラインブロック破棄操作を有効にします。
手順
マウント時のオンライン破棄を有効にします。
ファイルシステムを手動でマウントするには、
-o discard
マウントオプションを追加します。# mount -o discard device mount-point
-
ファイルシステムを永続的にマウントするには、
/etc/fstab
ファイルのマウントエントリーにdiscard
オプションを追加します。
関連情報
-
man ページの
mount(8)
-
man ページの
fstab(5)
16.5. RHEL システムロールを使用したオンラインのブロック破棄の有効化
本セクションでは、storage
ロールを使用してオンラインのブロック破棄を有効にする方法を説明します。
前提条件
-
storage
ロールを含む Ansible Playbook がある。
このような Playbook を適用する方法は、「ロールの適用」 を参照してください。
16.5.1. オンラインのブロック破棄を有効にする Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook では、storage
ロールを適用して、オンラインのブロック破棄を有効にして XFS ファイルシステムをマウントします。
例16.1 /mnt/data/ でのオンラインのブロック破棄を有効にする Playbook
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs mount_point: /mnt/data mount_options: discard roles: - rhel-system-roles.storage
関連情報
- この Playbook は、「ファイルシステムを永続的にマウントする Ansible Playbook の例」 に記載されている永続的なマウント例のすべての操作も実行します。
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
16.5.2. 関連情報
-
storage
ロールの詳細は、「storage ロールの概要」 を参照してください。
16.6. 定期的なブロック破棄の有効化
この手順では、対応するすべてのファイルシステムで、未使用のブロックを定期的に破棄する systemd
タイマーを有効にします。
手順
systemd
タイマーを有効にして起動します。# systemctl enable --now fstrim.timer
第17章 Stratis で階層化ローカルストレージの管理
Stratis の高レベルシステムに統合されている複雑なストレージ設定を簡単に設定および管理できます。
Straits がテクノロジープレビューとして利用可能にテクノロジープレビュー機能に対する Red Hat のサポート範囲の詳細は、「テクノロジプレビュー機能のサポート範囲」を参照してください。
Stratis をデプロイしているお客様は、Red Hat にフィードバックをお寄せください。
17.1. Stratis ファイルシステムの設定
システム管理者は、Stratis ボリューム管理ファイルシステムをシステム上で有効にしてセットアップし、階層化ストレージを簡単に管理できます。
17.1.1. Stratis の目的と機能
Stratis は、Linux 用のローカルストレージ管理ソリューションです。これは、シンプルさと使いやすさに力を入れており、高度なストレージ機能にアクセスできます。
Stratis を使用すると、以下の活動をより簡単に行うことができます。
- ストレージの初期設定
- その後の変更
- 高度なストレージ機能の使用
Stratis は、高度なストレージ機能に対応する、ユーザーとカーネルのハイブリッドローカルストレージ管理システムです。Stratis は、ストレージ プール の概念を中心としています。このプールは 1 つ以上のローカルディスクまたはパーティションから作成され、ボリュームはプールから作成されます。
プールにより、次のような多くの便利な機能を使用できます。
- ファイルシステムのスナップショット
- シンプロビジョニング
- 階層化
17.1.2. Stratis ボリュームの構成要素
外部的には、Stratis は、コマンドラインインターフェースおよび API に次のボリュームコンポーネントを表示します。
blockdev
- ディスクやディスクパーティションなどのブロックデバイス。
pool
1 つ以上のブロックデバイスで構成されています。
プールの合計サイズは固定で、ブロックデバイスのサイズと同じです。
プールには、
dm-cache
ターゲットを使用した不揮発性データキャッシュなど、ほとんどの Stratis レイヤーが含まれています。Stratis は、各プールの
/stratis/my-pool/
ディレクトリーを作成します。このディレクトリーには、プール内の Stratis ファイルシステムを表すデバイスへのリンクが含まれています。
filesystem
各プールには、ファイルを格納する 1 つ以上のファイルシステムを含めることができます。
ファイルシステムはシンプロビジョニングされており、合計サイズは固定されていません。ファイルシステムの実際のサイズは、そこに格納されているデータとともに大きくなります。データのサイズがファイルシステムの仮想サイズに近づくと、Stratis はシンボリュームとファイルシステムを自動的に拡張します。
ファイルシステムは XFS でフォーマットされています。
重要Stratis は、Stratis を使用して作成したファイルシステムに関する情報を追跡し、XFS はそれを認識しません。また、XFS を使用して変更を行っても、自動的に Stratisに更新を作成しません。ユーザーは、Stratis が管理する XFS ファイルシステムを再フォーマットまたは再構成しないでください。
Stratis は、パスが
/stratis/my-pool/my-fs
のファイルシステムへのリンクを作成します。
Stratis は、dmsetup
リストと /proc/partitions
ファイルに表示される多くの Device Mapper デバイスを使用します。同様に、lsblk
コマンドの出力は、Stratis の内部の仕組みとレイヤーを反映します。
17.1.3. Stratis で使用可能なブロックデバイス
本セクションでは、Stratis に使用できるストレージデバイスを一覧で紹介します。
対応デバイス
Stratis プールは、次の種類のブロックデバイスで動作するかどうかをテスト済みです。
- LUKS
- LVM 論理ボリューム
- MD RAID
- DM Multipath
- iSCSI
- HDD および SSD
- NVMe デバイス
Stratis は、現行バージョンでは、ハードドライブまたはその他のハードウェアの不具合に対応しません。複数のハードウェアデバイスに Stratis プールを作成すると、データにアクセスするために複数のデバイスが動作状態になっているため、データを損失するリスクが高まります。
対応していないデバイス
Stratis にはシンプロビジョニングレイヤーが含まれているため、Red Hat はすでにシンプロビジョニングされているブロックデバイスに Stratis プールを配置することを推奨しません。
関連情報
-
iSCSI や、ネットワークを必要とするその他のブロックデバイスの
_netdev
マウントオプションに関する情報は、man ページのsystemd.mount(5)
を参照してください。
17.1.4. Stratis のインストール
この手順では、Stratis の使用に必要なパッケージをすべてインストールします。
手順
Stratis サービスとコマンドラインユーティリティーを提供するパッケージをインストールします。
# yum install stratisd stratis-cli
stratisd
サービスが有効になっていることを確認してください。# systemctl enable --now stratisd
17.1.5. Stratis プールの作成
この手順では、1 つ以上のブロックデバイスから暗号化済みまたは暗号化されていない Stratis プールを作成する方法を説明します。
以下の注記は、暗号化された Stratis プールに適用されます。
-
各ブロックデバイスは
cryptsetup
ライブラリーを使用して暗号化され、LUKS2
形式を実装します。 - 各 Stratis プールは、一意の鍵を持つか、他のプールと同じ鍵を共有できます。これらのキーはカーネルキーリングに保存されます。
- Stratis プールを構成するすべてのブロックデバイスは、暗号化または暗号化されません。同じ Stratis プールに、暗号化したブロックデバイスと暗号化されていないブロックデバイスの両方を含めることはできません。
- 暗号化 Stratis プールのデータ層に追加されるブロックデバイスは、自動的に暗号化されます。
前提条件
- Stratis v2.2.1 がシステムにインストールされている。Bug 1891591 を参照してください。「Stratis のインストール」
-
stratisd
サービスが実行している。 - Stratis プールを作成するブロックデバイスは使用されておらず、マウントされていない。
- Stratis プールを作成するブロックデバイスが、それぞれ 1 GiB 以上である。
IBM Z アーキテクチャーでは、
/dev/dasd*
ブロックデバイスをパーティションに分割している。Stratis プールでパーティションを使用します。DASD デバイスのパーティション設定には、「IBM Z への Linux インスタンスの設定」を参照してください。
手順
選択したブロックデバイスにファイルシステム、パーティションテーブル、または RAID 署名が含まれている場合は、以下のコマンドで消去します。
# wipefs --all block-device
block-device
は、ブロックデバイスへのパスです (例:/dev/sdb
)。選択したブロックデバイスに新しい Stratis プールを作成します。
注記スペースで区切られた、1 行に複数のブロックデバイスを指定します。
# stratis pool create my-pool block-device-1 block-device-2
暗号化されていない Stratis プールを作成するには、以下のコマンドを使用して手順 3 に移動します。
# stratis pool create my-pool block-device
block-device
は、空のブロックデバイスまたは消去したブロックデバイスへのパスになります。注記暗号化されていない Stratis プールの作成後には、暗号化されていない Stratis プールを暗号化することはできません。
暗号化された Stratis プールを作成するには、以下の手順を実行します。
キーセットをまだ作成していない場合には、以下のコマンドを実行してプロンプトに従って、暗号化に使用するキーセットを作成します。
# stratis key set --capture-key key-description
ここでの
key-description
は、キーセットの説明または名前です。暗号化した Stratis プールを作成し、暗号化に使用する鍵の説明を指定します。代わりに
--keyfile-path
パラメーターを使用してキーパスを指定することもできます。# stratis pool create --key-desc key-description my-pool block-device
ここでは、
key-description
- 暗号化に使用するキーファイルの説明または名前を指定します。
my-pool
- 新しい Stratis プールの名前を指定します。
block-device
- 空のブロックデバイスまたは消去したブロックデバイスへのパスを指定します。
新しい Stratis プールが作成されていることを確認します。
# stratis pool list
トラブルシューティング
システムの再起動後に、暗号化した Stratis プール、または構成するブロックデバイスが表示されなくなることがあります。この問題が発生した場合は、Stratis プールのロックを解除して表示されるようにする必要があります。
Stratis プールのロックを解除するには、以下の手順を実行します。
以前使用したものと同じキー記述を使用して、キーセットを再作成します。
# stratis key set --capture-key key-description
Stratis プールとブロックデバイスをアンロックします。
# stratis pool unlock
Stratis プールが表示されることを確認します。
# stratis pool list
関連情報
-
stratis(8)
の man ページ
次のステップ
- プールに Stratis ファイルシステムを作成します。詳細は、「Stratis ファイルシステムの作成」を参照してください。
17.1.6. Stratis ファイルシステムの作成
この手順では、既存の Stratis プールに Stratis ファイルシステムを作成します。
前提条件
- Stratis がインストールされている。Bug 1891591 を参照してください。「Stratis のインストール」
-
stratisd
サービスが実行している。 - Stratis プールを作成している。Bug 1891591 を参照してください。「Stratis プールの作成」
手順
Stratis ファイルシステムをプールに作成するには、次のコマンドを実行します。
# stratis fs create my-pool my-fs
- my-pool を、既存の Stratis プールの名前に置き換えます。
- my-fs を、ファイルシステムの任意の名前に置き換えます。
確認のために、プールにあるファイルシステムの一覧を表示します。
# stratis fs list my-pool
関連情報
-
man ページの
stratis(8)
次のステップ
- Stratis ファイルシステムをマウントします。Bug 1891591 を参照してください。「Stratis ファイルシステムのマウント」
17.1.7. Stratis ファイルシステムのマウント
この手順では、コンテンツにアクセスするために既存の Stratis ファイルシステムをマウントします。
前提条件
- Stratis がインストールされている。Bug 1891591 を参照してください。「Stratis のインストール」
-
stratisd
サービスが実行している。 - Stratis ファイルシステムを作成している。Bug 1891591 を参照してください。「Stratis ファイルシステムの作成」
手順
ファイルシステムをマウントするには、
/stratis/
ディレクトリーで Stratis が維持するエントリーを使用します。# mount /stratis/my-pool/my-fs mount-point
これでファイルシステムは mount-point ディレクトリーにマウントされ、使用できるようになりました。
関連情報
-
man ページの
mount(8)
17.1.8. Stratis ファイルシステムを永続的に維持
この手順では、Stratis ファイルシステムを永続的にマウントして、システムが起動した後に自動的に利用できるようにします。
前提条件
- Stratis がインストールされている。Bug 1891591 を参照してください。「Stratis のインストール」
-
stratisd
サービスが実行している。 - Stratis ファイルシステムを作成している。Bug 1891591 を参照してください。「Stratis ファイルシステムの作成」
手順
ファイルシステムの UUID 属性を調べます。
$ lsblk --output=UUID /stratis/my-pool/my-fs
以下に例を示します。
例17.1 Stratis ファイルシステムの UUID の表示
$ lsblk --output=UUID /stratis/my-pool/fs1 UUID a1f0b64a-4ebb-4d4e-9543-b1d79f600283
このマウントポイントのディレクトリーがない場合は、作成します。
# mkdir --parents mount-point
root で
/etc/fstab
ファイルを編集し、ファイルシステムに行を追加します (UUID で識別されます)。xfs
をファイルシステムのタイプとして使用し、x-systemd.requires=stratisd.service
オプションを追加します。以下に例を示します。
例17.2 /etc/fstab の /fs1 マウントポイント
UUID=a1f0b64a-4ebb-4d4e-9543-b1d79f600283 /fs1 xfs defaults,x-systemd.requires=stratisd.service 0 0
システムが新しい設定を登録するように、マウントユニットを再生成します。
# systemctl daemon-reload
ファイルシステムをマウントして、設定が機能することを確認します。
# mount mount-point
関連情報
17.2. 追加のブロックデバイスで Stratis ボリュームの拡張
Stratis ファイルシステムのストレージ容量を増やすために、追加のブロックデバイスを Stratis プールに追加できます。
17.2.1. Stratis ボリュームの構成要素
外部的には、Stratis は、コマンドラインインターフェースおよび API に次のボリュームコンポーネントを表示します。
blockdev
- ディスクやディスクパーティションなどのブロックデバイス。
pool
1 つ以上のブロックデバイスで構成されています。
プールの合計サイズは固定で、ブロックデバイスのサイズと同じです。
プールには、
dm-cache
ターゲットを使用した不揮発性データキャッシュなど、ほとんどの Stratis レイヤーが含まれています。Stratis は、各プールの
/stratis/my-pool/
ディレクトリーを作成します。このディレクトリーには、プール内の Stratis ファイルシステムを表すデバイスへのリンクが含まれています。
filesystem
各プールには、ファイルを格納する 1 つ以上のファイルシステムを含めることができます。
ファイルシステムはシンプロビジョニングされており、合計サイズは固定されていません。ファイルシステムの実際のサイズは、そこに格納されているデータとともに大きくなります。データのサイズがファイルシステムの仮想サイズに近づくと、Stratis はシンボリュームとファイルシステムを自動的に拡張します。
ファイルシステムは XFS でフォーマットされています。
重要Stratis は、Stratis を使用して作成したファイルシステムに関する情報を追跡し、XFS はそれを認識しません。また、XFS を使用して変更を行っても、自動的に Stratisに更新を作成しません。ユーザーは、Stratis が管理する XFS ファイルシステムを再フォーマットまたは再構成しないでください。
Stratis は、パスが
/stratis/my-pool/my-fs
のファイルシステムへのリンクを作成します。
Stratis は、dmsetup
リストと /proc/partitions
ファイルに表示される多くの Device Mapper デバイスを使用します。同様に、lsblk
コマンドの出力は、Stratis の内部の仕組みとレイヤーを反映します。
17.2.2. Stratis プールへのブロックデバイスの追加
この手順では、Stratis ファイルシステムで使用できるように、1 つ以上のブロックデバイスを Stratis プールに追加します。
前提条件
- Stratis がインストールされている。Bug 1891591 を参照してください。「Stratis のインストール」
-
stratisd
サービスが実行している。 - Stratis プールに追加するブロックデバイスは使用されておらず、マウントされていない。
- Stratis プールに追加するブロックデバイスは使用されておらず、それぞれ 1 GiB 以上である。
手順
1 つ以上のブロックデバイスをプールに追加するには、以下を使用します。
# stratis pool add-data my-pool device-1 device-2 device-n
関連情報
-
man ページの
stratis(8)
17.3. Stratis ファイルシステムの監視
Stratis ユーザーは、システムにある Stratis ボリュームに関する情報を表示して、その状態と空き容量を監視できます。
17.3.1. さまざまなユーティリティーが報告する Stratis のサイズ
本セクションでは、df
などの標準的なユーティリティーと、stratis
ユーティリティーにより報告される Stratis サイズの相違点を説明します。
df
などの標準的な Linux ユーティリティーは、Stratis 上の 1TiB の XFS ファイルシステムレイヤーのサイズを報告します。これは 1 TiB です。Stratis の実際のストレージ使用量は、シンプロビジョニングにより少なくなっており、また XFS レイヤーが満杯に近くなると Stratis が自動的にファイルシステムを拡張するため、これは特に有用な情報ではありません。
Stratis ファイルシステムに書き込まれているデータ量を定期的に監視します。これは Total Physical Used の値として報告されます。これが Total Physical Size の値を超えていないことを確認してください。
関連情報
-
man ページの
stratis(8)
17.3.2. Stratis ボリュームの情報表示
この手順では、Stratis ボリュームに関する合計サイズ、使用済みサイズ、空きサイズ、ファイルシステム、プールに属するブロックデバイスなどの統計情報を一覧表示します。
前提条件
- Stratis がインストールされている。Bug 1891591 を参照してください。「Stratis のインストール」
-
stratisd
サービスが実行している。
手順
システムで Stratis に使用されているすべての ブロックデバイス に関する情報を表示する場合は、次のコマンドを実行します。
# stratis blockdev Pool Name Device Node Physical Size State Tier my-pool /dev/sdb 9.10 TiB In-use Data
システムにあるすべての Stratis プール に関する情報を表示するには、次のコマンドを実行します。
# stratis pool Name Total Physical Size Total Physical Used my-pool 9.10 TiB 598 MiB
システムにあるすべての Stratis ファイルシステム に関する情報を表示するには、次のコマンドを実行します。
# stratis filesystem Pool Name Name Used Created Device my-pool my-fs 546 MiB Nov 08 2018 08:03 /stratis/my-pool/my-fs
関連情報
-
man ページの
stratis(8)
17.4. Stratis ファイルシステムでのスナップショットの使用
Stratis ファイルシステムのスナップショットを使用して、ファイルシステムの状態を任意の時点でキャプチャーし、後でそれを復元できます。
17.4.1. Stratis スナップショットの特徴
本セクションでは、Stratis ファイルシステムのスナップショットのプロパティーと制限事項を説明します。
Stratis では、スナップショットは、別の Stratis ファイルシステムのコピーとして作成した通常の Stratis ファイルシステムです。スナップショットには、元のファイルシステムと同じファイルの内容が含まれていますが、スナップショットが変更するときにファイル内容が変更する可能性があります。スナップショットにどんな変更を加えても、元のファイルシステムには反映されません。
Stratis の現在のスナップショット実装は、次のような特徴があります。
- ファイルシステムのスナップショットは別のファイルシステムです。
- スナップショットと元のファイルシステムのリンクは、有効期間中は行われません。スナップショットされたファイルシステムは、元のファイルシステムよりも長く存続します。
- スナップショットを作成するためにファイルシステムをマウントする必要はありません。
- 各スナップショットは、XFS ログに必要となる実際のバッキングストレージの約半分のギガバイトを使用します。
17.4.2. Stratis スナップショットの作成
この手順では、既存の Stratis ファイルシステムのスナップショットとして Stratis ファイルシステムを作成します。
前提条件
- Stratis がインストールされている。Bug 1891591 を参照してください。「Stratis のインストール」
-
stratisd
サービスが実行している。 - Stratis ファイルシステムを作成している。Bug 1891591 を参照してください。「Stratis ファイルシステムの作成」
手順
Stratis スナップショットを作成するには、次のコマンドを実行します。
# stratis fs snapshot my-pool my-fs my-fs-snapshot
関連情報
-
man ページの
stratis(8)
17.4.3. Stratis スナップショットのコンテンツへのアクセス
この手順では、Stratis ファイルシステムのスナップショットをマウントして、読み書き操作にアクセスできるようにします。
前提条件
- Stratis がインストールされている。Bug 1891591 を参照してください。「Stratis のインストール」
-
stratisd
サービスが実行している。 - Stratis スナップショットを作成している。Bug 1891591 を参照してください。「Stratis スナップショットの作成」
手順
スナップショットにアクセスするには、
/stratis/my-pool/
ディレクトリーから通常のファイルシステムとしてマウントします。# mount /stratis/my-pool/my-fs-snapshot mount-point
関連情報
- 「Stratis ファイルシステムのマウント」
-
man ページの
mount(8)
17.4.4. Stratis ファイルシステムを以前のスナップショットに戻す
この手順では、Stratis ファイルシステムの内容を、Stratis スナップショットでキャプチャーされた状態に戻します。
前提条件
- Stratis がインストールされている。Bug 1891591 を参照してください。「Stratis のインストール」
-
stratisd
サービスが実行している。 - Stratis スナップショットを作成している。Bug 1891591 を参照してください。「Stratis スナップショットの作成」
手順
必要に応じて、後でそれにアクセスできるように、ファイルシステムの現在の状態のバックアップを作成します。
# stratis filesystem snapshot my-pool my-fs my-fs-backup
元のファイルシステムをアンマウントして削除します。
# umount /stratis/my-pool/my-fs # stratis filesystem destroy my-pool my-fs
元のファイルシステムの名前でスナップショットのコピーを作成します。
# stratis filesystem snapshot my-pool my-fs-snapshot my-fs
元のファイルシステムと同じ名前でアクセスできるようになったスナップショットをマウントします。
# mount /stratis/my-pool/my-fs mount-point
my-fs という名前のファイルシステムの内容は、スナップショット my-fs-snapshot と同じになりました。
関連情報
-
man ページの
stratis(8)
17.4.5. Stratis スナップショットの削除
この手順では、Stratis スナップショットをプールから削除します。スナップショットのデータは失われます。
前提条件
- Stratis がインストールされている。Bug 1891591 を参照してください。「Stratis のインストール」
-
stratisd
サービスが実行している。 - Stratis スナップショットを作成している。Bug 1891591 を参照してください。「Stratis スナップショットの作成」
手順
スナップショットをアンマウントします。
# umount /stratis/my-pool/my-fs-snapshot
スナップショットを破棄します。
# stratis filesystem destroy my-pool my-fs-snapshot
関連情報
-
man ページの
stratis(8)
17.5. Stratis ファイルシステムの削除
既存の Stratis ファイルシステム、または Stratis プールを削除して、そこに含まれるデータを破棄できます。
17.5.1. Stratis ボリュームの構成要素
外部的には、Stratis は、コマンドラインインターフェースおよび API に次のボリュームコンポーネントを表示します。
blockdev
- ディスクやディスクパーティションなどのブロックデバイス。
pool
1 つ以上のブロックデバイスで構成されています。
プールの合計サイズは固定で、ブロックデバイスのサイズと同じです。
プールには、
dm-cache
ターゲットを使用した不揮発性データキャッシュなど、ほとんどの Stratis レイヤーが含まれています。Stratis は、各プールの
/stratis/my-pool/
ディレクトリーを作成します。このディレクトリーには、プール内の Stratis ファイルシステムを表すデバイスへのリンクが含まれています。
filesystem
各プールには、ファイルを格納する 1 つ以上のファイルシステムを含めることができます。
ファイルシステムはシンプロビジョニングされており、合計サイズは固定されていません。ファイルシステムの実際のサイズは、そこに格納されているデータとともに大きくなります。データのサイズがファイルシステムの仮想サイズに近づくと、Stratis はシンボリュームとファイルシステムを自動的に拡張します。
ファイルシステムは XFS でフォーマットされています。
重要Stratis は、Stratis を使用して作成したファイルシステムに関する情報を追跡し、XFS はそれを認識しません。また、XFS を使用して変更を行っても、自動的に Stratisに更新を作成しません。ユーザーは、Stratis が管理する XFS ファイルシステムを再フォーマットまたは再構成しないでください。
Stratis は、パスが
/stratis/my-pool/my-fs
のファイルシステムへのリンクを作成します。
Stratis は、dmsetup
リストと /proc/partitions
ファイルに表示される多くの Device Mapper デバイスを使用します。同様に、lsblk
コマンドの出力は、Stratis の内部の仕組みとレイヤーを反映します。
17.5.2. Stratis ファイルシステムの削除
この手順では、既存の Stratis ファイルシステムを削除します。そこに保存されているデータは失われます。
前提条件
- Stratis がインストールされている。Bug 1891591 を参照してください。「Stratis のインストール」
-
stratisd
サービスが実行している。 - Stratis ファイルシステムを作成している。Bug 1891591 を参照してください。「Stratis ファイルシステムの作成」
手順
ファイルシステムをアンマウントします。
# umount /stratis/my-pool/my-fs
ファイルシステムを破棄します。
# stratis filesystem destroy my-pool my-fs
ファイルシステムがもう存在しないことを確認します。
# stratis filesystem list my-pool
関連情報
-
man ページの
stratis(8)
17.5.3. Stratis プールの削除
この手順では、既存の Stratis プールを削除します。そこに保存されているデータは失われます。
前提条件
- Stratis がインストールされている。Bug 1891591 を参照してください。「Stratis のインストール」
-
stratisd
サービスが実行している。 - Stratis プールを作成している。Bug 1891591 を参照してください。「Stratis プールの作成」
手順
プールにあるファイルシステムの一覧を表示します。
# stratis filesystem list my-pool
プール上のすべてのファイルシステムをアンマウントします。
# umount /stratis/my-pool/my-fs-1 \ /stratis/my-pool/my-fs-2 \ /stratis/my-pool/my-fs-n
ファイルシステムを破棄します。
# stratis filesystem destroy my-pool my-fs-1 my-fs-2
プールを破棄します。
# stratis pool destroy my-pool
プールがなくなったことを確認します。
# stratis pool list
関連情報
-
man ページの
stratis(8)
第18章 ext3 ファイルシステムの使用
システム管理者は、ext3 ファイルシステムの作成、マウント、サイズ変更、バックアップ、および復元が可能です。ext3 ファイルシステムは、基本的に、ext2 ファイルシステムが拡張されたバージョンです。
18.1. ext3 ファイルシステムの機能
ext3 ファイルシステムの機能は以下のとおりです。
可用性 - 予期しない電源障害やシステムクラッシュの後、ジャーナリングが提供されているため、ファイルシステムを確認する必要はありません。デフォルトのジャーナルサイズは、ハードウェアの速度に応じて、復旧するのに約 1 秒かかります
注記ext3 で対応しているジャーナリングモードは data=ordered (デフォルト) のみです。詳細は、「EXT ジャーナリングオプション "data=writeback" は RHEL でサポートされますか?」を参照してください。ナレッジベース記事。
- データの整合性 - ext3ファイルシステムは、予期しない電源障害やシステムクラッシュが発生したときに、データの整合性が失われないようにします。
- 速度 - 一部のデータを複数回書き込みますが、ext3 のジャーナリングにより、ハードドライブのヘッドモーションが最適化されるため、ほとんどの場合、ext3 のスループットは ext2 よりも高くなります。
- 簡単な移行 - ext2 から ext3 に簡単に移行でき、再フォーマットをせずに、堅牢なジャーナリングファイルシステムの恩恵を受けることができます。
関連情報
-
man ページの
ext3
18.2. ext3 ファイルシステムの作成
システム管理者は、mkfs.ext3
コマンドを使用して、ブロックデバイスに ext3 ファイルシステムを作成できます。
前提条件
ディスクにパーティションがある。MBR パーティションまたは GPT パーティションの作成方法は、「ディスクへのパーティションテーブルの作成」 を参照してください。
もしくは、LVM ボリュームまたは MD ボリュームを使用します。
手順
ext3 ファイルシステムを作成する場合は、以下の手順を実行します。
デバイスが通常のパーティションの場合、LVM ボリューム、MD ボリューム、または類似デバイスは次のコマンドを使用します。
# mkfs.ext3 /dev/block_device
/dev/block_device を、ブロックデバイスへのパスに置き換えます。
たとえば、
/dev/sdb1
、/dev/disk/by-uuid/05e99ec8-def1-4a5e-8a9d-5945339ceb2a
、または/dev/my-volgroup/my-lv
です。一般的な用途では、デフォルトのオプションが最適です。
注記ファイルシステムの作成時に UUID を指定する場合は、次のコマンドを実行します。
# mkfs.ext3 -U UUID /dev/block_device
UUID を、設定する UUID (例:
7cd65de3-e0be-41d9-b66d-96d749c02da7
) に置き換えます。/dev/block_device を、ext3 ファイルシステムへのパス (例:
/dev/sda8
) に置き換え、UUID を追加します。ファイルシステムの作成時にラベルを指定するには、以下のコマンドを実行します。
# mkfs.ext3 -L label-name /dev/block_device
作成した ext3 ファイルシステムを表示する場合は、以下のコマンドを実行します。
# blkid
関連情報
-
man ページの
ext3
-
man ページの
mkfs.ext3
18.3. Ext3 ファイルシステムのマウント
システム管理者は、mount
ユーティリティーを使用して、ext3 ファイルシステムをマウントできます。
前提条件
- ext3 ファイルシステム。ext3 ファイルシステムの作成方法は、「ext3 ファイルシステムの作成」 を参照してください。
手順
ファイルシステムをマウントするためのマウントポイントを作成するには、以下のコマンドを実行します。
# mkdir /mount/point
/mount/point を、パーティションのマウントポイントを作成するディレクトリー名に置き換えます。
ext3 ファイルシステムをマウントするには、以下の手順を実行します。
ext3 ファイルシステムを追加のオプションなしでマウントするには、以下のコマンドを実行します。
# mount /dev/block_device /mount/point
- ファイルシステムを永続的にマウントする場合は、「ファイルシステムの永続的なマウント」 を参照してください。
マウントされたファイルシステムを表示するには、次のコマンドを実行します。
# df -h
関連情報
-
man ページの
mount
-
man ページの
ext3
-
man ページの
fstab
- 14章ファイルシステムのマウント
18.4. ext3 ファイルシステムのサイズ変更
システム管理者は、resize2fs
ユーティリティーを使用して、ext3 ファイルシステムのサイズを変更できます。resize2fs
ユーティリティーは、特定の単位を示すサフィックスが使用されていない限り、ファイルシステムのブロックサイズの単位でサイズを読み取ります。以下のサフィックスは、特定の単位を示しています。
-
s (セクター) -
512
バイトのセクター -
K (キロバイト) -
1,024
バイト -
M (メガバイト) -
1,048,576
バイト -
G (ギガバイト) -
1,073,741,824
バイト -
T (テラバイト) -
1,099,511,627,776
バイト
前提条件
- ext3 ファイルシステム。ext3 ファイルシステムの作成方法は、「ext3 ファイルシステムの作成」 を参照してください。
- サイズ変更後にファイルシステムを保持するための、適切なサイズの基本ブロックデバイス
手順
ext3 ファイルシステムのサイズを変更する場合は、以下の手順に従ってください。
アンマウントされている ext3 ファイルシステムのサイズを縮小および拡張するには、以下のコマンドを実行します。
# umount /dev/block_device # e2fsck -f /dev/block_device # resize2fs /dev/block_device size
/dev/block_device を、ブロックデバイスへのパス (例:
/dev/sdb1
) に置き換えます。size を、
s
、K
、M
、G
、およびT
のサフィックスを使用して必要なサイズ変更値に置き換えます。ext3 ファイルシステムは、
resize2fs
コマンドを使用して、マウントしたままの状態でサイズを大きくすることができます。# resize2fs /mount/device size
注記拡張時のサイズパラメーターは任意です (多くの場合は必要ありません)。
resize2fs
は、コンテナーの使用可能な領域 (通常は論理ボリュームまたはパーティション) を埋めるように、自動的に拡張します。
サイズを変更したファイルシステムを表示するには、次のコマンドを実行します。
# df -h
関連情報
-
man ページの
resize2fs
-
man ページの
e2fsck
-
man ページの
ext3
18.5. RHEL システムロールを使用した ext3 ファイルシステムの作成およびマウント
本セクションでは、ディスクで指定したラベルが付いた ext3 ファイルシステムを作成し、storage
ロールを使用してファイルシステムを永続的にマウントする方法を説明します。
前提条件
-
storage
ロールを含む Ansible Playbook がある。
このような Playbook を適用する方法は、「ロールの適用」 を参照してください。
18.5.1. ext3 ファイルシステムを作成してマウントする Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage
ロールを適用して、Ext3 ファイルシステムを作成してマウントします。
例18.1 /dev/sdb に Ext3 を作成し、/mnt/data にマウントする Playbook
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: ext3 fs_label: label-name mount_point: /mnt/data roles: - rhel-system-roles.storage
-
Playbook は、
/dev/sdb
ディスクにファイルシステムを作成します。 -
Playbook は、
/mnt/data
ディレクトリーにファイルシステムを永続的にマウントします。 -
ファイルシステムのラベルは
label-name
です。
関連情報
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
18.5.2. 関連情報
-
storage
ロールの詳細は、「storage ロールの概要」 を参照してください。
第19章 ext4 ファイルシステムの使用
システム管理者は、ext4 ファイルシステムの作成、マウント、サイズ変更、バックアップ、および復元が可能です。ext4 ファイルシステムは、ext3 ファイルシステムの拡張性を高めたファイルシステムです。Red Hat Enterprise Linux 8 では、最大 16
テラバイトの個別のファイルサイズと、最大 50
テラバイトのファイルシステムに対応します。
19.1. ext4 ファイルシステムの機能
以下は、ext4 ファイルシステムの機能です。
- エクステントの使用 - ext4 ファイルシステムはエクステントを使用します。これにより、サイズが大きいファイルを使用する場合のパフォーマンスが向上し、サイズが大きいファイルのメタデータのオーバーヘッドが削減されます。
- ext4 は、未割り当てのブロックグループと、inode テーブルセクションに適宜ラベルを付けます。これにより、ファイルシステムのチェック時に、ブロックグループとテーブルセクションをスキップできます。ファイルシステムのチェックが簡単に行われ、ファイルシステムがサイズが大きくなるとより有益になります。
- メタデータチェックサム - この機能は、デフォルトでは Red Hat Enterprise Linux 8 で有効になっています。
以下は、ext4 ファイルシステムの割り当て機能です。
- 永続的な事前割り当て
- 遅延割り当て
- マルチブロック割り当て
- ストライプ認識割り当て
-
拡張属性 (
xattr
) - これにより、システムは、ファイルごとに、名前と値の組み合わせを追加で関連付けられるようになります。 クォータジャーナリング - クラッシュ後に行なわれる時間がかかるクォータの整合性チェックが不要になります。
注記ext4 で対応しているジャーナリングモードは data=ordered (デフォルト) のみです。詳細は、「EXT ジャーナリングオプション "data=writeback" は RHEL でサポートされますか?」を参照してください。ナレッジベース記事。
- サブセカンド (一秒未満) のタイムスタンプ - サブセカンドのタイムスタンプを指定します。
関連情報
-
man ページの
ext4
19.2. ext4 ファイルシステムの作成
システム管理者は、mkfs.ext4
コマンドを使用して、ブロックデバイスに ext4 ファイルシステムを作成できます。
前提条件
ディスクにパーティションがある。MBR パーティションまたは GPT パーティションの作成方法は、「ディスクへのパーティションテーブルの作成」 を参照してください。
もしくは、LVM ボリュームまたは MD ボリュームを使用します。
手順
ext4 ファイルシステムを作成する場合は、以下の手順を実行します。
デバイスが通常のパーティションの場合、LVM ボリューム、MD ボリューム、または類似デバイスは次のコマンドを使用します。
# mkfs.ext4 /dev/block_device
/dev/block_device を、ブロックデバイスへのパスに置き換えます。
たとえば、
/dev/sdb1
、/dev/disk/by-uuid/05e99ec8-def1-4a5e-8a9d-5945339ceb2a
、または/dev/my-volgroup/my-lv
です。一般的な用途では、デフォルトのオプションが最適です。ストライプ化されたブロックデバイス (RAID5 アレイなど) の場合は、ファイルシステムの作成時にストライプジオメトリーを指定できます。適切なストライプジオメトリーを使用することで、ext4 ファイルシステムのパフォーマンスが向上します。たとえば、4k ブロックのファイルシステムで、64k ストライド (16 x 4096) のファイルシステムを作成する場合は、次のコマンドを使用します。
# mkfs.ext4 -E stride=16,stripe-width=64 /dev/block_device
この例では、以下のようになります。
- stride=value - RAID チャンクサイズを指定します。
- stripe-width=value - 1 RAID デバイス内のデータディスク数、または 1 ストライプ内のストライプユニット数を指定します。
注記ファイルシステムの作成時に UUID を指定する場合は、次のコマンドを実行します。
# mkfs.ext4 -U UUID /dev/block_device
UUID を、設定する UUID (例:
7cd65de3-e0be-41d9-b66d-96d749c02da7
) に置き換えます。/dev/block_device を、ext4 ファイルシステムへのパス (例:
/dev/sda8
) に置き換え、UUID を追加します。ファイルシステムの作成時にラベルを指定するには、以下のコマンドを実行します。
# mkfs.ext4 -L label-name /dev/block_device
作成した ext4 ファイルシステムを表示するには、以下のコマンドを実行します。
# blkid
関連情報
-
man ページの
ext4
-
man ページの
mkfs.ext4
19.3. ext4 ファイルシステムのマウント
システム管理者は、mount
ユーティリティーを使用して、ext4 ファイルシステムをマウントできます。
前提条件
- ext4 ファイルシステム。ext4 ファイルシステムの作成方法は、「ext4 ファイルシステムの作成」 を参照してください。
手順
ファイルシステムをマウントするためのマウントポイントを作成するには、以下のコマンドを実行します。
# mkdir /mount/point
/mount/point を、パーティションのマウントポイントを作成するディレクトリー名に置き換えます。
ext4 ファイルシステムをマウントするには、以下を行います。
ext4 ファイルシステムを追加のオプションなしでマウントするには、次のコマンドを実行します。
# mount /dev/block_device /mount/point
- ファイルシステムを永続的にマウントする場合は、「ファイルシステムの永続的なマウント」 を参照してください。
マウントされたファイルシステムを表示するには、次のコマンドを実行します。
# df -h
関連情報
-
man ページの
mount
-
man ページの
ext4
-
man ページの
fstab
- 14章ファイルシステムのマウント
19.4. ext4 ファイルシステムのサイズ変更
システム管理者は、resize2fs
ユーティリティーを使用して、ext4 ファイルシステムのサイズを変更できます。resize2fs
ユーティリティーは、特定の単位を示すサフィックスが使用されていない限り、ファイルシステムのブロックサイズの単位でサイズを読み取ります。以下のサフィックスは、特定の単位を示しています。
-
s (セクター) -
512
バイトのセクター -
K (キロバイト) -
1,024
バイト -
M (メガバイト) -
1,048,576
バイト -
G (ギガバイト) -
1,073,741,824
バイト -
T (テラバイト) -
1,099,511,627,776
バイト
前提条件
- ext4 ファイルシステム。ext4 ファイルシステムの作成方法は、「ext4 ファイルシステムの作成」 を参照してください。
- サイズ変更後にファイルシステムを保持するための、適切なサイズの基本ブロックデバイス
手順
ext4 ファイルシステムのサイズを変更するには、以下の手順に従ってください。
アンマウントされている ext4 ファイルシステムのサイズを縮小および拡張するには、次のコマンドを実行します。
# umount /dev/block_device # e2fsck -f /dev/block_device # resize2fs /dev/block_device size
/dev/block_device を、ブロックデバイスへのパス (例:
/dev/sdb1
) に置き換えます。size を、
s
、K
、M
、G
、およびT
のサフィックスを使用して必要なサイズ変更値に置き換えます。ext4 ファイルシステムは、
resize2fs
を使用して、マウントしたままの状態でサイズを大きくすることができます。# resize2fs /mount/device size
注記拡張時のサイズパラメーターは任意です (多くの場合は必要ありません)。
resize2fs
は、コンテナーの使用可能な領域 (通常は論理ボリュームまたはパーティション) を埋めるように、自動的に拡張します。
サイズを変更したファイルシステムを表示するには、次のコマンドを実行します。
# df -h
関連情報
-
man ページの
resize2fs
-
man ページの
e2fsck
-
man ページの
ext4
19.5. RHEL システムロールを使用した ext4 ファイルシステムの作成およびマウント
本セクションでは、ディスクで指定したラベルが付いた ext4 ファイルシステムを作成し、storage
ロールを使用してファイルシステムを永続的にマウントする方法を説明します。
前提条件
-
storage
ロールを含む Ansible Playbook がある。
このような Playbook を適用する方法は、「ロールの適用」 を参照してください。
19.5.1. Ext4 ファイルシステムを作成してマウントする Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage
ロールを適用して、Ext4 ファイルシステムを作成してマウントします。
例19.1 /dev/sdb に Ext4 を作成し、/mnt/data にマウントする Playbook
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: ext4 fs_label: label-name mount_point: /mnt/data roles: - rhel-system-roles.storage
-
Playbook は、
/dev/sdb
ディスクにファイルシステムを作成します。 -
Playbook は、
/mnt/data
ディレクトリーにファイルシステムを永続的にマウントします。 -
ファイルシステムのラベルは
label-name
です。
関連情報
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
関連情報
-
storage
ロールの詳細は、「storage ロールの概要」 を参照してください。
19.6. ext4 および XFS で使用されるツールの比較
本セクションでは、ext4 ファイルシステムおよび XFS ファイルシステムで一般的なタスクを行うのに使用するツールを比較します。
タスク | ext4 | XFS |
---|---|---|
ファイルシステムを作成する |
|
|
ファイルシステムを確認する |
|
|
ファイルシステムのサイズを変更する |
|
|
ファイルシステムのイメージを保存する |
|
|
ファイルシステムのラベル付けまたはチューニングを行う |
|
|
ファイルシステムのバックアップを作成する |
|
|
クォータ管理 |
|
|
ファイルマッピング |
|
|
法律上の通知
このページには機械翻訳が使用されている場合があります (詳細はこちら)。