ファイルシステムの管理
ファイルシステムの作成、変更、管理
概要
第1章 利用可能なファイルシステムの概要 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションに適したファイルシステムを選択することは、利用可能な選択肢が非常に多く、考慮すべき事項も多いため、重要な決定となります。
次のセクションでは、Red Hat Enterprise Linux 10 にデフォルトで含まれるファイルシステムと、アプリケーションに最適なファイルシステムに関する推奨事項を説明します。
1.1. ファイルシステムの種類 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux 10 は、さまざまなファイルシステム (FS) に対応します。さまざまな種類のファイルシステムがさまざまな問題を解決し、その使用はアプリケーションによって異なります。
最も一般的なレベルでは、利用可能なファイルシステムを以下の主要なタイプにまとめることができます。
| タイプ | ファイルシステム | 属性とユースケース |
|---|---|---|
| ディスクまたはローカルのファイルシステム | XFS | XFS は、RHEL におけるデフォルトファイルシステムです。特別な理由がない限り、ローカルファイルシステムとして XFS を導入してください。たとえば、互換性やパフォーマンスに関する特殊なケースなど。 |
| ext4 | 従来の ext2 および ext3 ファイルシステムから進化した ext4 には、Linux で馴染みやすいという利点があります。多くの場合、パフォーマンスでは XFS に匹敵します。ext4 ファイルシステムのサポート制限とファイルサイズは、XFS よりも低くなっています。 | |
| ネットワーク、またはクライアント/サーバーのファイルシステム | Network File System (NFS) | NFS は、同じネットワークにある複数のシステムでのファイル共有に使用します。 |
| サーバーメッセージブロック (SMB) | SMB は、Microsoft Windows システムとのファイル共有に使用します。 | |
| ボリューム管理ファイルシステム | Stratis | Stratis は、XFS と論理ボリュームマネージャー (LVM) を組み合わせたボリュームマネージャーです。Stratis の目的は、Btrfs や ZFS などのボリューム管理ファイルシステムにより提供される機能をエミュレートすることです。このスタックを手動で構築することは可能ですが、Stratis は設定の複雑さを軽減し、ベストプラクティスを実装し、エラー情報を統合します。 |
1.2. ローカルファイルシステム リンクのコピーリンクがクリップボードにコピーされました!
ローカルファイルシステムは、直接接続されたストレージを備えた 1 台のサーバー上で動作します。これらは、内蔵の Serial Advanced Technology Attachment (SATA) または Serial Attached SCSI(SAS) ディスク、ハードウェア RAID、および非共有 SAN デバイスに使用されます。
すべてのローカルファイルシステムは、ポータブルオペレーティングシステムインターフェイス (POSIX) 規格に準拠しており、明確に定義された一連のシステムコールをサポートしています。例としては、read()、write()、seek() などがあります。
- 利用可能なローカルファイルシステム
- XFS
- ext4
1.3. XFS ファイルシステム リンクのコピーリンクがクリップボードにコピーされました!
XFS は、拡張性、パフォーマンス、堅牢性、成熟度に優れた 64 ビットジャーナリングファイルシステムです。単一ホスト上で非常に大きなファイルやファイルシステムをサポートします。Red Hat Enterprise Linux 10 では、これがデフォルトのファイルシステムです。XFS は、元々 1990 年代の前半に SGI により開発され、極めて大規模なサーバーおよびストレージアレイで実行されてきた長い歴史があります。
XFS の機能は次のとおりです。
- 信頼性
- メタデータジャーナリングは、システムクラッシュ後もファイルシステムの整合性を確保します。ファイルシステムの操作記録を保持します。これらの記録は、システムが再起動され、ファイルシステムが再マウントされたときに再生できます。
- 広範囲に及ぶランタイムメタデータの整合性チェック
- 拡張性が高く、高速な修復ユーティリティー
- クォータジャーナリングクラッシュ後に行なわれる、時間がかかるクォータの整合性チェックが不要になります。
- スケーラビリティーおよびパフォーマンス
- 対応するファイルシステムのサイズが最大 1024 TiB
- 多数の同時操作に対応する機能
- 空き領域管理のスケーラビリティーに関する B-Tree インデックス
- 高度なメタデータ read-ahead アルゴリズム
- ストリーミングビデオのワークロードの最適化
- 割り当てスキーム
- エクステント (領域) ベースの割り当て
- ストライプを認識できる割り当てポリシー
- 遅延割り当て
- 領域の事前割り当て
- 動的に割り当てられる inode
- その他の機能
- Reflink ベースのファイルのコピー
- 密接に統合されたバックアップおよび復元のユーティリティー
- オンラインのデフラグ
- オンラインのファイルシステム拡張
- 包括的な診断機能
-
拡張属性 (
xattr)。これにより、システムはファイルごとに複数の追加の名前/値ペアを関連付けることができる。 - ディレクトリーツリー全体に対するクォータ制限のための、プロジェクトまたはディレクトリーのクォータ。
- サブセカンド (一秒未満) のタイムスタンプ
- パフォーマンスの特徴
XFS は、エンタープライズワークロードを実行する大規模システムにおいて高いパフォーマンスを発揮します。大規模なシステムとは、相対的に CPU 数が多く、さらには複数の HBA、および外部ディスクアレイへの接続を備えたシステムです。XFS は、マルチスレッドの並列 I/O ワークロードを備えた小規模のシステムでも適切に実行します。
XFS は小規模なシステムでも同様のパフォーマンスを発揮しますが、スケーラビリティーや大規模なデータセットに重点を置いています。
1.4. ext4 ファイルシステム リンクのコピーリンクがクリップボードにコピーされました!
ext4 ファイルシステムは、ext ファイルシステムファミリーの第 4 世代です。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エラーを返します。XFS は設定可能なエラー処理もサポートします。 - Quotas
ext4 では、既存のファイルシステムにファイルシステムを作成する場合にクォータを有効にできます。その後、マウントオプションを使用してクォータの適用を設定できます。
XFS クォータは再マウントできるオプションではありません。初期マウントでクォータをアクティブにする必要があります。
XFS ファイルシステムで
quotacheckコマンドを実行すると影響しません。クォータアカウンティングを初めてオンにすると、XFS はクォータを自動的にチェックします。- ファイルシステムのサイズ変更
- XFS には、ファイルシステムのサイズを縮小するユーティリティーがありません。XFS ファイルシステムのサイズのみを増やすことができます。ext4 は、ファイルシステムの拡張と縮小の両方をサポートします。しかし、縮小処理はオフラインでのみ実行可能です。
- Inode 番号
ext4 ファイルシステムは、232 個を超える inode をサポートしません。
XFS は動的な inode 割り当てをサポートしています。XFS ファイルシステム上で inode が消費できる領域の量は、ファイルシステムの合計領域のパーセンテージとして計算されます。システムが inode 不足に陥るのを防ぐため、管理者はファイルシステム作成後にこの割合を調整することができます。システムが 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. ローカルファイルシステムの選択 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションの要件を満たすファイルシステムを選択するには、ファイルシステムをデプロイする対象システムを理解する必要があります。一般的には、ext4 を特定の用途で使用する場合を除き、XFS を使用してください。
- XFS
- 大規模なデプロイメントの場合、特に大きなファイル (数百メガバイト) や大量の I/O 並行処理を扱う場合は、XFS を使用します。XFS は、高帯域幅 (200MB/秒以上) かつ 1 秒あたり 1000 回以上の入出力操作 (IOPS) が可能な環境で最適なパフォーマンスを発揮します。ただし、ext4 と比較してメタデータ操作に多くの CPU リソースを消費します。また、ファイルシステムの縮小をサポートしていません。
- ext4
- 小規模なシステムや I/O 帯域幅が制限されている環境では、ext4 のほうが適している可能性があります。シングルスレッド、少量の I/O ワークロード、およびスループット要件が低い環境の場合は、パフォーマンスが向上します。また、ext4 はオフラインの縮小をサポートしています。これはファイルシステムのサイズ変更が必要な場合に役立ちます。
ターゲットサーバーとストレージシステムでアプリケーションのパフォーマンスをベンチマークし、選択したファイルシステムがパフォーマンスとスケーラビリティーの要件を満たしていることを確認してください。
| シナリオ | 推奨されるファイルシステム |
|---|---|
| 特別なユースケースなし | XFS |
| 大規模サーバー | XFS |
| 大規模なストレージデバイス | XFS |
| 大規模なファイル | XFS |
| マルチスレッド I/O | XFS |
| シングルスレッド I/O | XFS, ext4 |
| 制限された I/O 機能 (1000 IOPS 未満) | XFS, ext4 |
| 制限された帯域幅 (200MB/s 未満) | XFS, ext4 |
| CPU にバインドされているワークロード | XFS, ext4 |
| オフラインの縮小への対応 | XFS, ext4 |
1.7. ネットワークファイルシステム リンクのコピーリンクがクリップボードにコピーされました!
ネットワークファイルシステム (クライアント/サーバーファイルシステムとも呼ばれる) は、クライアントシステムが共有サーバーに保存されているファイルにアクセスできるようにするものです。これにより、複数のシステムの、複数のユーザーが、ファイルやストレージリソースを共有できます。
このようなファイルシステムは、ファイルシステムのセットを 1 つ以上のクライアントにエクスポートする、1 つ以上のサーバーから構築されます。クライアントノードは、基盤となるブロックストレージにアクセスできません。その代わりに、より高度なアクセス制御を可能にするプロトコルを使用してストレージとやり取りします。
- 利用可能なネットワークファイルシステム
- RHEL お客様にとって最も一般的なクライアント/サーバーファイルシステムは、ネットワークファイルシステム (NFS) です。RHEL は、ネットワーク経由でローカルファイルシステムをエクスポートする NFS サーバーコンポーネントと、このようなファイルシステムをインポートする NFS クライアントの両方を提供します。
- RHEL には、共通インターネットファイルシステム (CIFS) クライアントも含まれています。これは、Windows との相互運用性を実現する、広く普及している Microsoft Server Message Block (SMB) ファイルサーバーをサポートします。ユーザー空間 Samba サーバーは、RHEL サーバーから Microsoft SMB サービスを使用する Windows クライアントを提供します。
1.10. ボリューム管理ファイルシステム リンクのコピーリンクがクリップボードにコピーされました!
ボリューム管理ファイルシステムは、ストレージ層内の簡素化と改善を目的として、ストレージスタック全体を統合します。
- 利用可能なボリューム管理ファイルシステム
Red Hat Enterprise Linux 10 は Stratis ボリュームマネージャーを提供します。Stratis はファイルシステム層に XFS を使用し、論理ボリュームマネージャー (LVM)、デバイスマッパー、その他のコンポーネントと統合しています。
Stratis は、Red Hat Enterprise Linux 8.0 で初めてリリースされました。Red Hat が Btrfs を非推奨にした時に生じたギップを埋めると考えられています。Stratis 1.0 は、直感的でコマンドラインベースのボリュームマネージャーです。ユーザーから複雑さを隠蔽しながら、重要なストレージ管理操作を実行できます。
- ボリュームの管理
- プールの作成
- シンストレージプール
- スナップショット
- 自動化読み取りキャッシュ
Stratis は強力な機能を提供しますが、現時点では Btrfs や ZFS といったその他の製品と比較される可能性がある機能をいつくか欠いています。特に、エラーを自動的に修正できるチェックサムをサポートしていない点が問題です。
第2章 RHEL システムロールを使用したローカルストレージの管理 リンクのコピーリンクがクリップボードにコピーされました!
storage ロールを使用すると、Ansible を使用して論理ボリュームマネージャー (LVM) およびローカルファイルシステム (FS) を管理できます。
ストレージ ロールを使用することで、複数のマシン上のディスクや論理ボリュームのファイルシステムの管理を自動化できます。
2.1. storage RHEL システムロールを使用してブロックデバイスに XFS ファイルシステムを作成する リンクのコピーリンクがクリップボードにコピーされました!
storage RHEL システムロールを使用して、ブロックデバイス上の XFS ファイルシステムの作成を自動化できます。
storage ロールは、パーティションが分割されていないディスク全体または論理ボリューム (LV) でのみファイルシステムを作成できます。パーティションにファイルシステムを作成することはできません。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。--- - name: Manage local storage hosts: managed-node-01.example.com tasks: - name: Create an XFS file system on a block device ansible.builtin.include_role: name: redhat.rhel_system_roles.storage vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfsサンプル Playbook で指定されている設定は次のとおりです。
name: barefs-
現在、ボリューム名 (この例では
barefs) は任意です。storageロールは、disks属性にリストされているディスクデバイスによってボリュームを識別します。 fs_type: <file_system>-
デフォルトのファイルシステム XFS を使用する場合は、
fs_typeパラメーターを省略できます。 disks: <list_of_disks_and_volumes>- ディスク名と LV 名の YAML リスト。
Playbook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.storage/README.mdファイルを参照してください。Playbook の構文を検証します。
$ ansible-playbook --syntax-check ~/playbook.ymlこのコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
$ ansible-playbook ~/playbook.yml
2.2. storage RHEL システムロールを使用してファイルシステムを永続的にマウントする リンクのコピーリンクがクリップボードにコピーされました!
storage RHEL システムロールを使用すると、ファイルシステムを永続的にマウントして、システムの再起動後もファイルシステムが使用可能であり、起動時に自動的にマウントされるようにすることができます。Playbook で指定したデバイス上にファイルシステムが存在しない場合は、ロールによってファイルシステムが作成されます。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。--- - name: Manage local storage hosts: managed-node-01.example.com tasks: - name: Persistently mount a file system ansible.builtin.include_role: name: redhat.rhel_system_roles.storage vars: storage_safe_mode: false storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs mount_point: /mnt/data mount_user: somebody mount_group: somegroup mount_mode: "0755"Playbook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.storage/README.mdファイルを参照してください。Playbook の構文を検証します。
$ ansible-playbook --syntax-check ~/playbook.ymlこのコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
$ ansible-playbook ~/playbook.yml
2.3. storage RHEL システムロールを使用して論理ボリュームを作成またはサイズ変更する リンクのコピーリンクがクリップボードにコピーされました!
storage RHEL システムロールを使用して、論理ボリュームマネージャー (LVM) 論理ボリュームを作成およびサイズ変更できます。ボリュームグループが存在しない場合は、ロールによって自動的に作成されます。
storage ロールを使用して、次のタスクを実行します。
- 多数のディスクで構成されるボリュームグループに LVM 論理ボリュームを作成する
- LVM 上の既存のファイルシステムのサイズを変更する
- LVM ボリュームのサイズをプールの合計サイズのパーセンテージで表す
ボリュームグループが存在しない場合、このロールによって作成されます。ボリュームグループ内に論理ボリュームが存在する場合に、そのサイズが Playbook で指定されたサイズと一致しないと、サイズが変更されます。
論理ボリュームを縮小する場合、データの損失を防ぐために、その論理ボリューム上のファイルシステムによって、縮小する論理ボリューム内の領域が使用されていないことを確認する必要があります。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。--- - name: Manage local storage hosts: managed-node-01.example.com tasks: - name: Create logical volume ansible.builtin.include_role: name: redhat.rhel_system_roles.storage vars: storage_safe_mode: false storage_pools: - name: myvg disks: - sda - sdb - sdc volumes: - name: mylv size: 2G fs_type: ext4 mount_point: /mnt/dataサンプル Playbook で指定されている設定は次のとおりです。
size: <size>- 単位 (GiB など) またはパーセンテージ (60% など) を使用してサイズを指定する必要があります。
Playbook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.storage/README.mdファイルを参照してください。Playbook の構文を検証します。
$ ansible-playbook --syntax-check ~/playbook.ymlこのコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
$ ansible-playbook ~/playbook.yml
検証
指定したボリュームが作成されたこと、または要求したサイズに変更されたことを確認します。
# ansible managed-node-01.example.com -m command -a 'lvs myvg'
2.4. storage RHEL システムロールを使用してオンラインブロック破棄を有効にする リンクのコピーリンクがクリップボードにコピーされました!
オンラインブロック破棄オプションを使用すると、XFS ファイルシステムをマウントし、未使用のブロックを自動的に破棄できます。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。--- - name: Manage local storage hosts: managed-node-01.example.com tasks: - name: Enable online block discard ansible.builtin.include_role: name: redhat.rhel_system_roles.storage vars: storage_volumes: - name: barefs type: disk disks: - /dev/sdb fs_type: xfs mount_point: /mnt/data mount_options: discardPlaybook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.storage/README.mdファイルを参照してください。Playbook の構文を検証します。
$ ansible-playbook --syntax-check ~/playbook.ymlこのコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
$ ansible-playbook ~/playbook.yml
検証
オンラインブロック破棄オプションが有効になっていることを確認します。
# ansible managed-node-01.example.com -m command -a 'findmnt /mnt/data'
2.5. storage RHEL システムロールを使用してファイルシステムを作成およびマウントする リンクのコピーリンクがクリップボードにコピーされました!
storage RHEL システムロールを使用して、再起動後も保持されるファイルシステムを作成およびマウントできます。このロールは、永続的なマウントを確保するために、/etc/fstab にエントリーを自動的に追加します。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。--- - name: Manage local storage hosts: managed-node-01.example.com tasks: -name: Create and mount a file system ansible.builtin.include_role: name: redhat.rhel_system_roles.storage vars: storage_safe_mode: false storage_volumes: - name: barefs type: disk disks: - sdb fs_type: ext4 fs_label: label-name mount_point: /mnt/dataサンプル Playbook で指定されている設定は次のとおりです。
disks: <list_of_devices>- ロールがボリュームを作成するときに使用するデバイス名の YAML リスト。
fs_type: <file_system>-
ロールがボリュームに設定するファイルシステムを指定します。
xfs、ext3、ext4、swap、またはunformattedを選択できます。 label-name: <file_system_label>- オプション: ファイルシステムのラベルを設定します。
mount_point: <directory>-
オプション: ボリュームを自動マウントする場合は、
mount_point変数をボリュームがマウントされるディレクトリーに設定します。
Playbook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.storage/README.mdファイルを参照してください。Playbook の構文を検証します。
$ ansible-playbook --syntax-check ~/playbook.ymlこのコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
$ ansible-playbook ~/playbook.yml
2.6. storage RHEL システムロールを使用した RAID ボリュームの設定 リンクのコピーリンクがクリップボードにコピーされました!
storage システムロールを使用すると、Red Hat Ansible Automation Platform と Ansible-Core を使用して RHEL に RAID ボリュームを設定できます。要件に合わせて RAID ボリュームを設定するためのパラメーターを使用して、Ansible Playbook を作成します。
特定の状況でデバイス名が変更する場合があります。たとえば、新しいディスクをシステムに追加するときなどです。したがって、データの損失を防ぐために、Playbook では永続的な命名属性を使用してください。永続的な命名属性の詳細は、永続的な命名属性 を参照してください。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。--- - name: Manage local storage hosts: managed-node-01.example.com tasks: - name: Create a RAID on sdd, sde, sdf, and sdg ansible.builtin.include_role: name: redhat.rhel_system_roles.storage 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: presentPlaybook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.storage/README.mdファイルを参照してください。Playbook の構文を検証します。
$ ansible-playbook --syntax-check ~/playbook.ymlこのコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
$ ansible-playbook ~/playbook.yml
検証
アレイが正しく作成されたことを確認します。
# ansible managed-node-01.example.com -m command -a 'mdadm --detail /dev/md/data'
2.7. storage RHEL システムロールを使用して RAID 上の LVM ボリュームグループを設定する リンクのコピーリンクがクリップボードにコピーされました!
storage RHEL システムロールを使用して、RAID アレイ上の LVM ボリュームグループを設定できます。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。--- - name: Manage local storage hosts: managed-node-01.example.com tasks: - name: Configure LVM pool with RAID ansible.builtin.include_role: name: redhat.rhel_system_roles.storage vars: storage_safe_mode: false storage_pools: - name: my_pool type: lvm disks: [sdh, sdi] raid_level: raid1 volumes: - name: my_volume size: "1 GiB" mount_point: "/mnt/app/shared" fs_type: xfs state: presentPlaybook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.storage/README.mdファイルを参照してください。注記storage_poolレベルでraid_levelを設定すると、最初に MD RAID アレイが作成され、その上に LVM ボリュームグループがビルドされます。Playbook の構文を検証します。
$ ansible-playbook --syntax-check ~/playbook.ymlこのコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
$ ansible-playbook ~/playbook.yml
検証
プールが RAID 上にあることを確認します。
# ansible managed-node-01.example.com -m command -a 'lsblk'
2.8. storage RHEL システムロールを使用して RAID LVM ボリュームのストライプサイズを設定する リンクのコピーリンクがクリップボードにコピーされました!
storage RHEL システムロールを使用して、RAID LVM ボリュームのストライプサイズを設定できます。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。--- - name: Manage local storage hosts: managed-node-01.example.com tasks: - name: Configure stripe size for RAID LVM volumes ansible.builtin.include_role: name: redhat.rhel_system_roles.storage vars: storage_safe_mode: false storage_pools: - name: my_pool type: lvm disks: [sdh, sdi] volumes: - name: my_volume size: "1 GiB" mount_point: "/mnt/app/shared" fs_type: xfs raid_level: raid0 raid_stripe_size: "256 KiB" state: presentPlaybook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.storage/README.mdファイルを参照してください。注記volumesレベルでraid_levelを設定すると、LVM RAID 論理ボリュームが作成されます。Playbook の構文を検証します。
$ ansible-playbook --syntax-check ~/playbook.ymlこのコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
$ ansible-playbook ~/playbook.yml
検証
ストライプサイズが必要なサイズに設定されていることを確認します。
# ansible managed-node-01.example.com -m command -a 'lvs -o+stripesize /dev/my_pool/my_volume'
2.9. storage RHEL システムロールを使用して LVM-VDO ボリュームを設定する リンクのコピーリンクがクリップボードにコピーされました!
storage RHEL システムロールを使用して、圧縮と重複排除を有効にした LVM 上の VDO ボリューム (LVM-VDO) を作成できます。
storage システムロールが LVM-VDO を使用するため、プールごとに作成できるボリュームは 1 つだけです。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。--- - name: Manage local storage hosts: managed-node-01.example.com tasks: - name: Create LVM-VDO volume under volume group 'myvg' ansible.builtin.include_role: name: redhat.rhel_system_roles.storage vars: storage_pools: - name: myvg disks: - /dev/sdb volumes: - name: mylv1 compression: true deduplication: true vdo_pool_size: 10 GiB size: 30 GiB mount_point: /mnt/app/sharedサンプル Playbook で指定されている設定は次のとおりです。
vdo_pool_size: <size>- デバイス上でボリュームが占める実際のサイズ。サイズは、10 GiB など、人間が判読できる形式で指定できます。単位を指定しない場合、デフォルトでバイト単位に設定されます。
size: <size>- VDO ボリュームの仮想サイズ。
Playbook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.storage/README.mdファイルを参照してください。Playbook の構文を検証します。
$ ansible-playbook --syntax-check ~/playbook.ymlこのコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
$ ansible-playbook ~/playbook.yml
検証
圧縮と重複排除の現在のステータスを表示します。
$ ansible managed-node-01.example.com -m command -a 'lvs -o+vdo_compression,vdo_compression_state,vdo_deduplication,vdo_index_state'LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert VDOCompression VDOCompressionState VDODeduplication VDOIndexState mylv1 myvg vwi-a-v--- 3.00t vpool0 enabled online enabled online
2.10. storage RHEL システムロールを使用して LUKS2 暗号化ボリュームを作成する リンクのコピーリンクがクリップボードにコピーされました!
storage ロールを使用し、Ansible Playbook を実行して、LUKS で暗号化されたボリュームを作成および設定できます。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。
手順
機密性の高い変数を暗号化されたファイルに保存します。
vault を作成します。
$ ansible-vault create ~/vault.ymlNew Vault password: <vault_password> Confirm New Vault password: <vault_password>ansible-vault createコマンドでエディターが開いたら、機密データを<key>: <value>形式で入力します。luks_password: <password>- 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。--- - name: Manage local storage hosts: managed-node-01.example.com vars_files: - ~/vault.yml tasks: - name: Create and configure a volume encrypted with LUKS ansible.builtin.include_role: name: redhat.rhel_system_roles.storage vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs fs_label: <label> mount_point: /mnt/data encryption: true encryption_password: "{{ luks_password }}" encryption_cipher: <cipher> encryption_key_size: <key_size> encryption_luks_version: luks2サンプル Playbook で指定されている設定は次のとおりです。
encryption_cipher: <cipher>-
LUKS 暗号を指定します。可能な値は、
twofish-xts-plain64、serpent-xts-plain64、およびaes-xts-plain64(デフォルト) です。 encryption_key_size: <key_size>-
LUKS キーのサイズを指定します。デフォルトは
512ビットです。 encryption_luks_version: luks2-
LUKS バージョンを指定します。デフォルトは
luks2です。
Playbook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.storage/README.mdファイルを参照してください。Playbook の構文を検証します。
$ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.ymlこのコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
$ ansible-playbook --ask-vault-pass ~/playbook.yml
検証
作成された LUKS 暗号化ボリュームを確認します。
# ansible managed-node-01.example.com -m command -a 'cryptsetup luksDump /dev/sdb'LUKS header information Version: 2 Epoch: 3 Metadata area: 16384 [bytes] Keyslots area: 16744448 [bytes] UUID: bdf6463f-6b3f-4e55-a0a6-1a66f0152a46 Label: (no label) Subsystem: (no subsystem) Flags: (no flags) Data segments: 0: crypt offset: 16777216 [bytes] length: (whole device) cipher: aes-cbc-essiv:sha256 sector: 512 [bytes] Keyslots: 0: luks2 Key: 256 bits Priority: normal Cipher: aes-cbc-essiv:sha256 Cipher key: 256 bits
2.12. storage RHEL システムロールを使用して物理ボリュームのサイズを変更する リンクのコピーリンクがクリップボードにコピーされました!
storage システムロールを使用して、ホストの外部から基盤となるストレージまたはディスクのサイズを変更した後、論理ボリュームマネージャー (LVM) 物理ボリュームのサイズを変更できます。たとえば、仮想ディスクのサイズを増やした後、既存の LVM でさらに多くの領域を使用できます。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。 - 基盤となるブロックストレージのサイズを変更した。
手順
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。--- - name: Manage local storage hosts: managed-node-01.example.com tasks: - name: Resize LVM PV size ansible.builtin.include_role: name: redhat.rhel_system_roles.storage vars: storage_pools: - name: myvg disks: ["sdf"] type: lvm grow_to_fill: trueサンプル Playbook で指定されている設定は次のとおりです。
grow_to_filltrue: ディスク上の新しい容量を使用するために、ストレージボリュームを自動的に拡張します。false: 基盤となるディスクが拡張された場合でも、ストレージボリュームを現在のサイズのままにします。
Playbook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.storage/README.mdファイルを参照してください。Playbook の構文を検証します。
$ ansible-playbook --syntax-check ~/playbook.ymlこのコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
$ ansible-playbook ~/playbook.yml
検証
grow_to_fill設定が期待どおりに機能することを確認します。テスト用の PV と VG を準備します。# pvcreate /dev/sdf# vgcreate myvg /dev/sdf初期の物理ボリュームサイズを確認して記録します。
# pvs-
Playbook を編集して
grow_to_fill: falseを設定し、Playbook を実行します。 - ボリュームサイズをチェックし、変更されていないことを確認します。
-
Playbook を編集して
grow_to_fill: trueを設定し、Playbook を再実行します。 - ボリュームサイズを確認し、拡張されていることを確認します。
第3章 Web コンソールを使用したパーティションの管理 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、フォーマット済みのパーティションの表示、新しいパーティションの作成、既存のパーティションの削除を行うことで、ディスクパーティションを管理できます。
3.1. ファイルシステムでフォーマットされたパーティションを Web コンソールに表示 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールの ストレージ セクションには、ファイルシステム テーブルで使用可能なファイルシステムがすべて表示されます。ファイルシステムでフォーマットされたパーティションのリストに加えて、新しいストレージを作成するためのページも使用できます。
前提条件
-
cockpit-storagedパッケージがシステムにインストールされている。 RHEL 10 Web コンソールがインストールされている。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
手順
- RHEL 10 Web コンソールにログインします。
Storage タブをクリックします。
ストレージ テーブルでは、ファイルシステムでフォーマットされたすべての利用可能なパーティション、その ID、種類、場所、サイズ、および各パーティションで使用可能な容量を確認できます。
右上隅のドロップダウンメニューを使用して、新しいローカルストレージまたはネットワークストレージを作成することもできます。
3.2. Web コンソールでパーティションの作成 リンクのコピーリンクがクリップボードにコピーされました!
新しいパーティションを作成するには、以下を行います。
- 既存のパーティションテーブルを使用する
- パーティションを作成する
前提条件
-
cockpit-storagedパッケージがシステムにインストールされている。 RHEL 10 Web コンソールがインストールされている。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
- システムに接続されたフォーマットされていないボリュームは、Storage タブの Storage テーブルに表示されます。
手順
- RHEL 10 Web コンソールにログインします。
- Storage タブをクリックします。
- Storage テーブルで、パーティションを分割するデバイスをクリックして、そのデバイスのページとオプションを開きます。
- デバイスページで、メニューボタン をクリックし、Create partition table を選択します。
Initialize disk ダイアログボックスで、以下を選択します。
パーティション設定:
- すべてのシステムおよびデバイスと互換性あり (MBR)
- 最新のシステムおよび 2TB (GPT) 以上のハードディスクと互換性あり
- パーティションなし
オーバーライト:
RHEL Web コンソールでディスク全体をゼロで書き換える場合は、Overwrite existing data with zeros チェックボックスをオンにします。このプログラムはディスク全体を調べるため、このオプションを使用すると遅くなりますが、よりセキュアになります。ディスクにデータが含まれていて、上書きする必要がある場合は、このオプションを使用します。
Overwrite existing data with zeros チェックボックスを選択しない場合、RHEL Web コンソールはディスクヘッダーのみを書き換えます。これにより、フォーマットの速度が向上します。
- をクリックします。
- 作成したパーティションテーブルの横にあるメニューボタン をクリックします。デフォルトでは Free space という名前が付けられます。
- をクリックします。
- Create partition ダイアログボックスで、ファイルシステムの Name を入力します。
- Mount point を追加します。
Type ドロップダウンメニューで、ファイルシステムを選択します。
- XFS ファイルシステムは大規模な論理ボリュームをサポートし、オンラインの物理ドライブを停止せずに、既存のファイルシステムの拡大および縮小を行うことができます。別のストレージの使用を希望しない場合は、このファイルシステムを選択したままにしてください。
ext4 ファイルシステムは以下に対応します。
- 論理ボリューム
- オンラインの物理ドライブを停止せずに切り替え
- ファイルシステムの拡張
- ファイルシステムの縮小
追加のオプションとして、LUKS(Linux Unified Key Setup) によるパーティションの暗号化を有効にすることができます。パスフレーズを使用してボリュームを暗号化できます。
- 作成するボリュームの Size を入力します。
RHEL Web コンソールでディスク全体をゼロで書き換える場合は、Overwrite existing data with zeros チェックボックスをオンにします。このプログラムはディスク全体を調べるため、このオプションを使用すると遅くなりますが、よりセキュアになります。ディスクにデータが含まれていて、上書きする必要がある場合は、このオプションを使用します。
Overwrite existing data with zeros チェックボックスを選択しない場合、RHEL Web コンソールはディスクヘッダーのみを書き換えます。これにより、フォーマットの速度が向上します。
ボリュームを暗号化する場合は、Encryption ドロップダウンメニューで暗号化の種類を選択します。
ボリュームを暗号化しない場合は、No encryption を選択します。
- At boot ドロップダウンメニューで、ボリュームをマウントするタイミングを選択します。
Mount options セクションで以下を実行します。
- ボリュームを読み取り専用論理ボリュームとしてマウントする場合は、Mount read only チェックボックスを選択にします。
- デフォルトのマウントオプションを変更する場合は、Custom mount options チェックボックスをオンにしてマウントオプションを追加します。
パーティションを作成します。
- パーティションを作成してマウントする場合は、 ボタンをクリックします。
パーティションのみを作成する場合は、 ボタンをクリックします。
ボリュームのサイズや、選択するオプションによって、フォーマットに数分かかることがあります。
検証
- パーティションが正常に追加されたことを確認するには、Storage タブに切り替えて Storage テーブルを確認し、新しいパーティションがリストされているかどうかを確認します。
3.3. Web コンソールでパーティションの削除 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールインターフェイスでパーティションを削除できます。
前提条件
-
cockpit-storagedパッケージがシステムにインストールされている。 RHEL 10 Web コンソールがインストールされている。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
手順
- RHEL 10 Web コンソールにログインします。
- Storage タブをクリックします。
- パーティションを削除するデバイスをクリックします。
- デバイスページの GPT partitions セクションで、削除するパーティションの横にあるメニューボタン をクリックします。
ドロップダウンメニューから を選択します。
RHEL Web コンソールは、パーティションを削除する前に、現在パーティションを使用しているすべてのプロセスを終了し、パーティションをアンマウントします。
検証
- パーティションが正常に削除されたことを確認するには、ストレージ タブに切り替えて、コンテンツ テーブルを確認します。
第6章 永続的な命名属性の概要 リンクのコピーリンクがクリップボードにコピーされました!
システム管理者として、複数のシステム起動後も信頼性の高いストレージ設定を構築するには、永続的な命名属性を使用してストレージボリュームを参照する必要があります。
6.1. 非永続的な命名属性のデメリット リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux では、ストレージデバイスを識別する方法が複数あります。各デバイスを識別するには、適切なオプションを使用することが重要です。これは、誤って間違ったデバイスにアクセスしてしまうことを防ぐのに役立ちます。
これは、ドライブへのインストールやフォーマットを行う際に特に重要です。
従来、/dev/sd(major number)(minor number) の形式の非永続的な名前は、ストレージデバイスを参照するために Linux 上で使用されます。メジャー番号とマイナー番号の範囲、および関連する sd 名は、検出されると各デバイスに割り当てられます。これは、メジャー番号とマイナー番号の範囲と、それに関連付けられた sd 名との関連性が変化する可能性があることを意味します。これは、デバイス検出の順序が変更された場合に発生する可能性があります。
このような順序の変更は、以下の状況で発生する可能性があります。
- システム起動プロセスの並列化により、システム起動ごとに異なる順序でストレージデバイスが検出された場合。
-
ディスクの電源が入らない、または SCSI(Small Computer System Interface) コントローラーに応答しない。この場合は、通常のデバイスプローブにより検出されません。システムがディスクにアクセスできません。その結果、以降のデバイスでは、メジャー番号とマイナー番号の範囲が下方修正されることになります。これは、関連する
SD カード名にも影響します。たとえば、通常sdbと呼ばれるディスクが検出されない場合があります。その場合、通常はsdcと呼ばれるディスクは、代わりにsdbとして表示されます。 -
SCSI コントローラー (ホストバスアダプターまたは HBA) が初期化に失敗し、その HBA に接続されているすべてのディスクが検出されなかった場合。後続のプローブされた HBA に接続しているディスクは、別のメジャー番号およびマイナー番号の範囲、および関連する別の
sd名が割り当てられます。 - システムに異なるタイプの HBA が存在する場合は、ドライバー初期化の順序が変更する可能性があります。これにより、HBA に接続されているディスクが異なる順序で検出される可能性があります。また、HBA がシステムの他の PCI スロットに移動した場合でも発生する可能性があります。
-
ファイバーチャネル、iSCSI(Internet Small Computer System Interface)、または FCoE(Fibre チャネル over Ethernet) アダプターを介して接続されたディスクは、プローブ時にアクセスできない場合があります。たとえば、ストレージアレイや途中のスイッチの電源が切れた場合などに、このような事態が発生する可能性があります。これは、停電後にシステムが再起動した際に、ストレージアレイがシステムよりも起動に時間がかかる場合に発生する可能性があります。一部のファイバーチャネルドライバーは、永続的な SCSI ターゲット ID とワールドワイドポート名 (WWPN) のマッピングを指定するメカニズムをサポートしています。ただし、これはメジャー番号範囲とマイナー番号範囲、または関連する
sd名を留保するものではありません。これは、一貫した SCSI ターゲット ID 番号のみを提供します。
これらの理由から、デバイスを参照する際に、メジャー番号とマイナー番号の範囲、または関連する SD カード 名を使用することは望ましくありません。これは特に /etc/fstab のようなファイルで顕著です。誤ったデバイスがマウントされ、データが破損する可能性があります。
別のメカニズムが使用されている場合でも、時折、sd 名を参照する必要が生じる場合があります。これは、デバイスからエラーが報告された場合に発生する可能性があります。Linux カーネルは、デバイスに関するカーネルメッセージの中で sd 名を使用します。また、SCSI ホスト、チャネル、ターゲット、および論理ユニット番号 (LUN) のタプルも使用します。
6.2. ファイルシステムおよびデバイスの識別子 リンクのコピーリンクがクリップボードにコピーされました!
ファイルシステムの識別子は、ファイルシステム自体に関連付けられます。一方、デバイスの識別子は、物理ブロックデバイスに紐付けられます。適切なストレージ管理を行うには、その違いを理解することが重要です。
ファイルシステムの識別子
ファイルシステムの識別子は、ブロックデバイス上に作成された特定のファイルシステムに関連付けられます。識別子はファイルシステムの一部としても格納されます。ファイルシステムを別のデバイスにコピーしても、ファイルシステム識別子は同じです。
ただし、mkfs ユーティリティーでフォーマットするなどしてデバイスを書き換えると、デバイスはその属性を失います。
ファイルシステムの識別子に含まれるものは、次のとおりです。
- 一意識別子 (UUID)
- ラベル
デバイスの識別子
デバイス識別子は、ブロックデバイス (ディスクやパーティションなど) に関連付けられます。mkfs ユーティリティーを使用してデバイスをフォーマットするなどしてデバイスを書き換えた場合でも、デバイスはその属性を保持します。これは、ファイルシステムに保存されていないためです。
デバイスの識別子に含まれるものは、次のとおりです。
- World Wide Identifier (WWID)
- パーティション UUID
- シリアル番号
推奨事項
- 論理ボリュームなどの一部のファイルシステムは、複数のデバイスにまたがっています。これらのファイルシステムにアクセスするには、デバイス識別子ではなくファイルシステム識別子を使用します。
6.3. /dev/disk/ にある udev メカニズムにより管理されるデバイス名 リンクのコピーリンクがクリップボードにコピーされました!
udev メカニズムは、Linux のすべてのタイプのデバイスに使用され、ストレージデバイスだけに限定されません。/dev/disk/ ディレクトリーにさまざまな種類の永続的な命名属性を提供します。ストレージデバイスの場合、Red Hat Enterprise Linux には /dev/disk/ ディレクトリーにシンボリックリンクを作成する udev ルールが含まれています。
ストレージデバイスは以下のように参照できます。
- ストレージデバイスのコンテンツ
- 一意識別子
- シリアル番号
udev の命名属性は永続的なものですが、システムを再起動しても自動的には変更されないため、設定可能なものもあります。
6.3.1. ファイルシステムの識別子 リンクのコピーリンクがクリップボードにコピーされました!
/dev/disk/by-uuid/ の UUID 属性
このディレクトリーのエントリーは、デバイスに格納されているコンテンツ (つまりデータ) 内の 一意識別子 (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
ファイルシステムを作成するときにラベル属性を設定できます。また、後で変更することもできます。
6.3.2. デバイスの識別子 リンクのコピーリンクがクリップボードにコピーされました!
/dev/disk/by-id/ の WWID 属性
World Wide Identifier (WWID) は、すべてのデバイスに対してスモールコンピューターシステムインターフェイス (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/ を使用できます。
NVMe デバイスを使用している場合、デバイスのシリアル番号の先頭に空白があると、一部のベンダーのディスク ID による名前変更が発生する可能性があります。
WWID マッピングの例:
| WWID シンボリックリンク | 非永続的なデバイス | 備考 |
|---|---|---|
|
|
|
ページ |
|
|
|
ページ |
|
|
| ディスクパーティション |
システムにより提供される永続的な名前のほかに、udev ルールを使用して独自の永続的な名前を実装し、ストレージの WWID にマップすることもできます。
/dev/disk/by-partuuid のパーティション UUID 属性
パーティション UUID(PARTUUID) 属性は、GUID パーティションテーブル (GPT) パーティションテーブルで定義されたパーティションを識別します。
パーティション UUID マッピングの例:
| PARTUUID シンボリックリンク | 非永続的なデバイス |
|---|---|
|
|
|
|
|
|
|
|
|
/dev/disk/by-path/ のパス属性
この属性は、デバイスへのアクセスに使用される ハードウェアパス がストレージデバイスを参照するシンボル名を提供します。
ハードウェアパス (PCI ID、ターゲットポート、LUN 番号など) の一部が変更されると、パス属性に失敗します。このため、パス属性は信頼性に欠けます。ただし、パス属性は以下のいずれかのシナリオで役に立ちます。
- 後で置き換える予定のディスクを特定する必要があります。
- 特定の場所にあるディスクにストレージサービスをインストールする予定です。
6.4. DM Multipath を使用した World Wide Identifier リンクのコピーリンクがクリップボードにコピーされました!
Device Mapper (DM) 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数値
例6.1 マルチパス設定での 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 を使用する場合は、クラスター内で一貫した名前を取得するために追加の手順が必要です。
6.5. udev デバイス命名規則の制約 リンクのコピーリンクがクリップボードにコピーされました!
udev デバイスの命名規則には、いくつかの課題と制約があります。これらには、イベントのタイミング、デバイスへのアクセス性、レイテンシー、命名の安定性、および動的なストレージ環境における外部プロセスとの潜在的な競合などが含まれます。
udev 命名規則の制約の一部は次のとおりです。
-
照会実行時に、デバイスにアクセスできない可能性があります。これは、
udevイベントのudevルールを処理する際に、udevメカニズムがストレージデバイスへの問い合わせに依存する可能性があるためです。これは、ファイバーチャネル、iSCSI(Internet Small Computer System Interface)、または FCoE(Fibre チャネル over Ethernet) ストレージデバイスでより起こりやすい。これは、デバイスがサーバーシャーシ内に設置されていない場合に発生します。 -
カーネルはいつでも
udevイベントを送信する可能性があり、それによってルールが処理される。デバイスにアクセスできない場合、/dev/disk/by-*/のリンクが削除される可能性があります。 -
udevイベントが生成されてから処理されるまでに遅延が生じる可能性があります。これは、多数のデバイスが検出され、ユーザー空間のudevdサービスがそれぞれのデバイスに対するルールを処理するのに時間がかかる場合に発生します。これにより、カーネルがデバイスを検出してから、/dev/disk/by-*/の名前が利用できるようになるまでに遅延が生じる可能性があります。 - ルールによって呼び出される blkid などの外部プログラムは、一時的にデバイスを開く可能性があります。これにより、デバイスは一時的に他の用途に使用できなくなります。
-
/dev/disk/にあるudevメカニズムによって管理されるデバイス名は、メジャーリリース間で変更される可能性があるため、リンクを更新する必要があります。
6.6. 永続的な命名属性のリスト表示 リンクのコピーリンクがクリップボードにコピーされました!
非永続ストレージデバイスの永続的な命名属性を確認できます。
手順
UUID(汎用一意識別子) とラベル属性をリスト表示するには、
lsblkユーティリティーを使用します。$ lsblk --fs storage-deviceたとえば、ファイルシステムの UUID ラベルを表示します。
$ lsblk --fs /dev/sda1NAME FSTYPE LABEL UUID MOUNTPOINT sda1 xfs Boot afa5d5e3-9050-48c3-acc1-bb30095f3dc4 /bootPARTUUID 属性をリスト表示するには、
--output +PARTUUIDオプションを指定してlsblkユーティリティーを使用します。$ lsblk --output +PARTUUIDたとえば、パーティションの PARTUUID 属性を表示します。
$ lsblk --output +PARTUUID /dev/sda1NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT PARTUUID sda1 8:1 0 512M 0 part /boot 4cd1448a-01World Wide Identifier (WWID) 属性をリスト表示するには、
/dev/disk/by-id/ディレクトリー内のシンボリックリンクのターゲットを調べます。たとえば、システム上にあるすべてのストレージデバイスの 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
6.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 settleext4 ファイルシステム、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
第7章 parted でのパーティション操作 リンクのコピーリンクがクリップボードにコピーされました!
parted は、ディスクパーティションを操作するプログラムです。MS-DOS や GPT など、複数のパーティションテーブル形式をサポートしています。これは、新しいオペレーティングシステム用のスペースの作成、ディスクの使用方法の再編成、および新しいハードディスクへのデータのコピーに役立ちます。
7.1. parted でパーティションテーブルの表示 リンクのコピーリンクがクリップボードにコピーされました!
ブロックデバイスのパーティションテーブルを表示して、パーティションレイアウトと個々のパーティションの詳細を確認します。parted ユーティリティーを使用して、ブロックデバイスのパーティションテーブルを表示できます。詳細は、システム上の parted(8) man ページを参照してください。
手順
partedユーティリティーを起動します。たとえば、次の出力は、デバイス/dev/sdaをリストします。# parted /dev/sdaパーティションテーブルを表示します。
(parted) printModel: 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オプション: 次に調べるデバイスに切り替えます。
(parted) select block-deviceprint コマンドの出力の詳細は、以下を参照してください。
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です。フラグの完全なリストは、システムのparted(8)man ページを参照してください。
7.2. parted でディスクにパーティションテーブルを作成 リンクのコピーリンクがクリップボードにコピーされました!
ディスク上にパーティションテーブルを作成し、ストレージ領域を個別の管理可能なセクションに整理するためのレイアウトを定義します。この手順を使用すると、異なる用途やオペレーティングシステム用に複数のパーティションを作成できます。
パーティションテーブルを使用してブロックデバイスをフォーマットすると、そのデバイスに保存されているすべてのデータが削除されます。
手順
インタラクティブな
partedシェルを起動します。# parted block-deviceデバイスにパーティションテーブルがあるかどうかを確認します。
(parted) printデバイスにすでにパーティションが存在する場合、それらは以下の手順で削除されます。
新しいパーティションテーブルを作成します。
(parted) mklabel table-typetable-type を、使用するパーティションテーブルのタイプに置き換えます。
-
マスターブートレコード (MBR) 用の
msdos GUID パーティションテーブル (GPT) の
gptたとえば、ディスクに GPT テーブルを作成するには、次のコマンドを使用します。
(parted) mklabel gptこのコマンドを入力すると、変更の適用が開始されます。
-
マスターブートレコード (MBR) 用の
パーティションテーブルを表示して、作成されたことを確認します。
(parted) printpartedシェルを終了します。(parted) quit
7.3. parted を使用したパーティションの作成 リンクのコピーリンクがクリップボードにコピーされました!
新しいディスクパーティションを作成して、ストレージスペースを効率的に整理し、異なる種類のデータを分離します。システムファイル、ユーザーデータ、スワップ領域用に専用の領域を設定できます。
前提条件
- ディスクのパーティションテーブルがある。
- 2 TiB を超えるパーティションを作成する場合は、GUID Partition Table (GPT) でディスクをフォーマットしている。
必要なパーティションは、swap、/boot/、および / (root) です。
手順
partedユーティリティーを起動します。# parted block-device現在のパーティションテーブルを表示し、十分な空き領域があるかどうかを確認します。
(parted) print- 十分な空き容量がない場合は、パーティションのサイズを変更してください。
パーティションテーブルから、以下を確認します。
- 新しいパーティションの開始点と終了点
- MBR で、どのパーティションタイプにすべきか
新しいパーティションを作成します。
MS-DOS の場合:
(parted) mkpart part-type fs-type start endGPT の場合:
(parted) mkpart part-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などのサイズ接尾辞を使用できます。デフォルトサイズの単位はメガバイトです。たとえば、MBR テーブルに 1024 MiB から 2048 MiB までのプライマリーパーティションを作成するには、次のコマンドを使用します。
(parted) mkpart primary 1024MiB 2048MiBコマンドを入力すると、変更の適用が開始されます。
-
part-type を
パーティションテーブルを表示して、作成されたパーティションのパーティションタイプ、ファイルシステムタイプ、サイズが、パーティションテーブルに正しく表示されていることを確認します。
(parted) printpartedシェルを終了します。(parted) quitカーネルが新しいパーティションを認識していることを確認します。
# cat /proc/partitions
7.4. parted でパーティションの削除 リンクのコピーリンクがクリップボードにコピーされました!
不要なディスクパーティションを削除して、ストレージ領域を他の目的に再利用します。この操作により、ディスクレイアウトの再編成、未使用パーティションの削除、システム上のストレージ利用率の最適化を行うことができます。
手順
インタラクティブな
partedシェルを起動します。# parted block-device-
block-device を、パーティションを削除するデバイスへのパス (例:
/dev/sda) に置き換えます。
-
block-device を、パーティションを削除するデバイスへのパス (例:
現在のパーティションテーブルを表示して、削除するパーティションのマイナー番号を確認します。
(parted) printパーティションを削除します。
(parted) rm partition-number- partition-number は、削除するパーティション番号に置き換えます。
このコマンドを実行すると、すぐに変更の適用が開始されます。
パーティションテーブルからパーティションが削除されたことを確認します。
(parted) printpartedシェルを終了します。(parted) quitパーティションが削除されたことをカーネルが登録していることを確認します。
# cat /proc/partitions-
パーティションが存在する場合は、
/etc/fstabファイルからパーティションを削除します。削除したパーティションを宣言している行を見つけ、ファイルから削除します。 システムが新しい
/etc/fstab設定を登録するように、マウントユニットを再生成します。# systemctl daemon-reload重要/proc/cmdlineに記載されているパーティション、または論理ボリュームマネージャー (LVM) の一部であるパーティションを削除するには、論理ボリュームの設定と管理 および、お使いのシステムのdracut(8)とgrubby(8) のman ページを参照してください。
7.5. parted でパーティションのサイズ変更 リンクのコピーリンクがクリップボードにコピーされました!
parted ユーティリティーを使用して、パーティションを拡張して未使用のディスク領域を利用したり、パーティションを縮小してその容量をさまざまな目的に使用したりできます。詳細は、システム上の parted(8) man ページを参照してください。
前提条件
- パーティションを縮小する前にデータをバックアップする。
- 2 TiB を超えるパーティションを作成する場合は、GUID Partition Table (GPT) でディスクをフォーマットしている。
- パーティションを縮小する場合は、サイズを変更したパーティションより大きくならないように、最初にファイルシステムを縮小しておく。
XFS は縮小に対応していません。
手順
partedユーティリティーを起動します。# parted block-device現在のパーティションテーブルを表示します。
(parted) printパーティションテーブルから、以下を確認します。
- パーティションのマイナー番号。
既存のパーティションの位置とサイズ変更後の新しい終了点。
重要パーティションのサイズを変更する場合は、サイズ変更するパーティションの末尾と次のパーティションの先頭 (最後のパーティションの場合はディスクの末尾) との間に、十分な未割り当て領域があることを確認してください。十分な領域がない場合、
partedはエラーを返します。ただし、パーティションの重複を避けるために、サイズを変更する前に使用可能な領域を確認することが推奨されます。
パーティションのサイズを変更します。
(parted) resizepart 1 2GiB- 1 を、サイズを変更するパーティションのマイナー番号に置き換えます。
-
2 を、サイズを変更するパーティションの新しい終了点を決定するサイズに置き換えます (ディスクの開始からカウントします)。
512MiB、20GiB、1.5TiBなどのサイズ接尾辞を使用できます。デフォルトサイズの単位はメガバイトです。
パーティションテーブルを表示して、サイズ変更したパーティションのサイズが、パーティションテーブルで正しく表示されていることを確認します。
(parted) printpartedシェルを終了します。(parted) quitカーネルが新しいパーティションを登録していることを確認します。
# cat /proc/partitions- オプション: パーティションを拡張した場合は、そこにあるファイルシステムも拡張します。
第8章 ディスクを再設定するストラテジー リンクのコピーリンクがクリップボードにコピーされました!
ほとんどの RHEL システムは、LVM を使用してストレージスペースを管理します。ディスクのパーティション分割には、parted、fdisk、またはその他のグラフィカルツールを使用することもできます。パーティションの再分割では、未分割の空き領域、未使用のパーティション、またはアクティブなパーティションから解放された空き領域が使用される場合があります。
次の例は、パーティション設定手法の一般的な概要を示しています。わかりやすいように簡略化されており、一般的な Red Hat Enterprise Linux インストール時の正確なパーティションレイアウトを反映しているわけではありません。
8.1. パーティションが分割されていない空き領域の使用 リンクのコピーリンクがクリップボードにコピーされました!
すでに定義されているパーティションはハードディスク全体にまたがらないため、定義されたパーティションには含まれない未割り当ての領域が残されます。
未使用のハードディスクもこのカテゴリーに分類されます。唯一の違いは、すべて の領域が定義されたパーティションの一部ではないことです。
新しいディスクでは、未使用の領域から必要なパーティションを作成できます。ほとんどのオペレーティングシステムは、ディスクドライブ上の利用可能な領域をすべて取得するように設定されています。
8.2. 未使用パーティションの領域の使用 リンクのコピーリンクがクリップボードにコピーされました!
未使用のパーティションに割り当てられた領域を使用するには、パーティションを削除してから、代わりに適切な Linux パーティションを作成します。または、インストールプロセス時に未使用のパーティションを削除し、新しいパーティションを手動で作成します。
8.3. アクティブなパーティションの空き領域の使用 リンクのコピーリンクがクリップボードにコピーされました!
必要な空き領域がすでに使用されているアクティブパーティション上にある場合、このプロセスの管理は困難になる可能性があります。ソフトウェアがプリインストールされたほとんどのコンピューターには、オペレーティングシステムとユーザーデータの両方を保持する 1 つの大きなパーティションがあります。
オペレーティングシステム (OS) を含むアクティブなパーティションのサイズ変更や変更を試みると、データが失われたり、OS が起動不能になったりする危険性があります。その結果、場合によっては OS を再インストールする必要があるかもしれません。続行する前に、システムにリカバリーメディアまたはインストールメディアが含まれているかどうかを確認してください。
使用可能な空き領域の使用を最適化するには、破壊的または非破壊的なパーティション再設定の方法を使用できます。
8.3.1. 破壊的な再設定 リンクのコピーリンクがクリップボードにコピーされました!
破壊的なパーティション再設定を行うと、ハードドライブ上のパーティションが破壊され、その場所に新しいパーティションが作成されます。この方法はコンテンツ全体を削除するため、元のパーティションから必要なデータをバックアップします。
既存のオペレーティングシステムから新しいパーティションを作成した後、次の操作を実行できます。
- ソフトウェアの再インストール。
- データの復元。
このメソッドは、元のパーティションに保存されたデータをすべて削除します。
8.3.2. 非破壊的な再パーティション リンクのコピーリンクがクリップボードにコピーされました!
非破壊的なパーティション再設定では、データの損失なしにパーティションのサイズを変更します。この方法は信頼性が高いものの、大容量のドライブでは処理時間が長くなります。
以下に、非破壊的なパーティション再設定を開始するのに役立つ方法をいくつかを示します。
- 既存データの再編成
一部のデータの保存場所は変更できないため、パーティションを必要なサイズに変更できない可能性があり、最終的には破壊的なパーティション再設定プロセスが必要になります。既存のパーティション内のデータを再編成すると、必要に応じてパーティションのサイズを変更し、パーティションを追加するための領域を追加したり、使用可能な空き領域を最大化したりすることができます。
データ損失の可能性を回避するには、データ移行プロセスを続行する前にバックアップを作成します。
- 既存パーティションのサイズ変更
既存のパーティションのサイズを変更すると、未使用の領域を解放できます。結果は、サイズ変更ソフトウェアにより異なります。多くの場合、元のパーティションと同じタイプのフォーマットされていない新しいパーティションを作成できます。
サイズ変更後の手順は、使用するソフトウェアにより異なります。以下の例では、新しい DOS (Disk Operating System) パーティションを削除し、代わりに Linux パーティションを作成することを推奨します。サイズ変更プロセスを開始する前に、何がディスクに最適か確認してください。
パーティションのサイズ変更と作成は、parted や GParted などの使用ツールにより異なる場合があります。具体的な手順は、ツールのドキュメントを参照してください。
- オプション: 新規パーティションの作成
Linux ベースのシステム向けに、サイズ変更ソフトウェアがいくつか利用可能です。この場合、サイズ変更後に新たに作成されたパーティションを削除する必要はありません。新しいパーティションの作成方法は、使用するソフトウェアによって異なります。
第9章 XFS の使用 リンクのコピーリンクがクリップボードにコピーされました!
これは、XFS ファイルシステムを作成および維持する方法の概要です。
9.1. XFS ファイルシステム リンクのコピーリンクがクリップボードにコピーされました!
XFS は、拡張性、パフォーマンス、堅牢性、成熟度に優れた 64 ビットジャーナリングファイルシステムです。単一ホスト上で非常に大きなファイルやファイルシステムをサポートします。Red Hat Enterprise Linux 10 では、これがデフォルトのファイルシステムです。XFS は、元々 1990 年代の前半に SGI により開発され、極めて大規模なサーバーおよびストレージアレイで実行されてきた長い歴史があります。
XFS の機能は次のとおりです。
- 信頼性
- メタデータジャーナリングは、システムクラッシュ後もファイルシステムの整合性を確保します。ファイルシステムの操作記録を保持します。これらの記録は、システムが再起動され、ファイルシステムが再マウントされたときに再生できます。
- 広範囲に及ぶランタイムメタデータの整合性チェック
- 拡張性が高く、高速な修復ユーティリティー
- クォータジャーナリングクラッシュ後に行なわれる、時間がかかるクォータの整合性チェックが不要になります。
- スケーラビリティーおよびパフォーマンス
- 対応するファイルシステムのサイズが最大 1024 TiB
- 多数の同時操作に対応する機能
- 空き領域管理のスケーラビリティーに関する B-Tree インデックス
- 高度なメタデータ read-ahead アルゴリズム
- ストリーミングビデオのワークロードの最適化
- 割り当てスキーム
- エクステント (領域) ベースの割り当て
- ストライプを認識できる割り当てポリシー
- 遅延割り当て
- 領域の事前割り当て
- 動的に割り当てられる inode
- その他の機能
- Reflink ベースのファイルのコピー
- 密接に統合されたバックアップおよび復元のユーティリティー
- オンラインのデフラグ
- オンラインのファイルシステム拡張
- 包括的な診断機能
-
拡張属性 (
xattr)。これにより、システムはファイルごとに複数の追加の名前/値ペアを関連付けることができる。 - ディレクトリーツリー全体に対するクォータ制限のための、プロジェクトまたはディレクトリーのクォータ。
- サブセカンド (一秒未満) のタイムスタンプ
- パフォーマンスの特徴
XFS は、エンタープライズワークロードを実行する大規模システムにおいて高いパフォーマンスを発揮します。大規模なシステムとは、相対的に CPU 数が多く、さらには複数の HBA、および外部ディスクアレイへの接続を備えたシステムです。XFS は、マルチスレッドの並列 I/O ワークロードを備えた小規模のシステムでも適切に実行します。
XFS は小規模なシステムでも同様のパフォーマンスを発揮しますが、スケーラビリティーや大規模なデータセットに重点を置いています。
9.2. ext4 および XFS で使用されるツールの比較 リンクのコピーリンクがクリップボードにコピーされました!
さまざまなツールとコマンドを使用して、作成、チェック、サイズ変更、バックアップ操作など、ext4 および XFS 上の一般的なファイルシステムタスクを実行します。
このセクションでは、ext4 ファイルシステムおよび XFS ファイルシステムで一般的なタスクを行うのに使用するツールを比較します。
| タスク | ext4 | XFS |
|---|---|---|
| ファイルシステムを作成する |
|
|
| ファイルシステム検査 |
|
|
| ファイルシステムのサイズを変更する |
|
|
| ファイルシステムのイメージを保存する |
|
|
| ファイルシステムのラベル付けまたはチューニングを行う |
|
|
| ファイルシステムのバックアップを作成する |
|
|
| クォータ管理 |
|
|
| ファイルマッピング |
|
|
ネットワークを使用してバックアップするための完全なクライアント/サーバーソリューションが必要な場合は、RHEL 9 で利用可能な bacula バックアップユーティリティーを使用できます。Bacula の詳細は、Bacula backup solution を参照してください。
第10章 XFS ファイルシステムの作成 リンクのコピーリンクがクリップボードにコピーされました!
システム管理者は、ブロックデバイスに XFS ファイルシステムを作成して、ファイルやディレクトリーを格納できます。
10.1. mkfs.xfs で XFS ファイルシステムの作成 リンクのコピーリンクがクリップボードにコピーされました!
大規模ストレージ環境向けの高パフォーマンス、スケーラビリティー、高度な機能を活用するために、XFS ファイルシステムを作成します。XFS は、大きなファイルと高いスループットを必要とするアプリケーションに特に効果的です。
手順
ファイルシステムを作成する場合は、以下の手順を実行します。
デバイスが通常のパーティション、LVM ボリューム、MD ボリューム、ディスク、または類似デバイスである場合は、次のコマンドを使用します。
# mkfs.xfs block-device注記XFS ファイルシステムの最小サイズは 300MB です。
mkfs.xfsは、パフォーマンスや冗長性の問題を回避するため、より小さなファイルシステムの作成をサポートしていません。-
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詳細は、システム上の
mkfs.xfs(8)man ページを参照してください。
第11章 XFS ファイルシステムのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
システム管理者は、xfsdump を使用して XFS ファイルシステムをファイルまたはテープにバックアップできます。これは、増分バックアップをサポートし、ファイルシステムのアンマウントを必要としないコマンドラインバックアップメカニズムを提供します。
11.1. XFS バックアップの機能 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、xfsdump ユーティリティーを使用して XFS ファイルシステムをバックアップする場合の主な概念と機能を説明します。
xfsdump ユーティリティーを使用すると次のことができます。
通常のファイルイメージへのバックアップ
通常のファイルに書き込むことができるバックアップは 1 つだけです。
テープドライブへのバックアップ
xfsdumpユーティリティーを使用すれば、同じテープに複数のバックアップを書き込むこともできます。バックアップは、複数のテープを分割して書き込むことができます。複数のファイルシステムを単一のテープデバイスにバックアップするには、すでに XFS バックアップが格納されているテープにバックアップを書き込みます。これにより、古いバックアップに、新しいバックアップが追加されます。
xfsdumpは、デフォルトでは既存のバックアップを上書しません。増分バックアップの作成
xfsdumpユーティリティーはダンプレベルを使用して、その他のバックアップの相対的なベースバックアップを決定します。0 から 9 までの数字は、ダンプレベルの増加を表します。増分バックアップは、下位レベルの最後のダンプ以降に変更したファイルのみが対象となります。- フルバックアップを実行する場合は、ファイルシステムでレベル 0 のダンプを実行します。
- レベル 1 のダンプは、フルバックアップ後の最初の増分バックアップです。次の増分バックアップはレベル 2 になります。これは、前回のレベル 1 のダンプ以降に変更したファイルのみが対象となります。レベル 9 まで同様です。
- サイズ、サブツリー、または inode フラグを使用してファイルをフィルタリングすることで、バックアップから除外できます。
詳細は、システム上の xfsdump(8) man ページを参照してください。
11.2. xfsdump で XFS ファイルシステムのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
xfsdump ユーティリティーを使用して、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/です。ファイルシステムをマウントする必要があります。 複数のファイルシステムをバックアップして単一のテープデバイスに保存する場合、
-L labelを使用して各バックアップにセッションラベルを追加します。これにより、復元時にバックアップを簡単に識別できるようになります。label を、バックアップの名前 (例:backup_data) に置き換えます。たとえば、
/boot/および/data/ディレクトリーにマウントされている XFS ファイルシステムの内容を/backup-files/内のファイルとしてバックアップするには、次のようにします。# xfsdump -l 0 -f /backup-files/boot.xfsdump /boot# xfsdump -l 0 -f /backup-files/data.xfsdump /data
-
level を、バックアップのダンプレベルに置き換えます。フルバックアップを実行する場合は
単一のテープデバイスに複数のファイルシステムをバックアップするには、
-L labelオプションを使用してセッションラベルを追加します。# xfsdump -l 0 -L "backup_boot" -f /dev/st0 /boot# xfsdump -l 0 -L "backup_data" -f /dev/st0 /data詳細は、システム上の
xfsdump(8)man ページを参照してください。
第12章 バックアップからの XFS ファイルシステムの復元 リンクのコピーリンクがクリップボードにコピーされました!
システム管理者は、xfsrestore ユーティリティーを使用して、xfsdump ユーティリティーで作成され、ファイルまたはテープに保存されている XFS バックアップを復元できます。
12.1. バックアップから XFS を復元する機能 リンクのコピーリンクがクリップボードにコピーされました!
xfsrestore を使用すると、バックアップから XFS ファイルシステムを復元できます。利用可能な復元モード、セッション識別、およびファイルを選択的に回復する方法を確認し、データの整合性と柔軟な回復ソリューションを確保します。
xfsrestore ユーティリティーは、xfsdump により作成されたバックアップからファイルシステムを復元します。xfsrestore ユーティリティーには 2 つのモードがあります。
- シンプル モードを使用すると、レベル 0 のダンプからファイルシステム全体を復元できます。これがデフォルトのモードです。
- 累積 モードでは、増分バックアップ (レベル 1 からレベル 9 まで) からファイルシステムを復元できます。
各バックアップは、session ID または session label で一意に識別されます。複数のバックアップを含むテープからバックアップを復元するには、対応するセッション ID またはラベルが必要です。
バックアップから特定のファイルを抽出、追加、または削除するには、xfsrestore インタラクティブモードを起動します。インタラクティブモードでは、バックアップファイルを操作する一連のコマンドが提供されます。
詳細は、システム上の xfsrestore(8) man ページを参照してください。
12.2. xfsrestore を使用してバックアップから XFS ファイルシステムを復元 リンクのコピーリンクがクリップボードにコピーされました!
xfsrestore を使用すると、ファイルまたはテープのバックアップから 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コマンドを使用します。以下は複数の 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/
-
backup-location を、バックアップの場所に置き換えます。これは、通常のファイル、テープドライブ、またはリモートテープデバイスになります。たとえば、ファイルの場合は
12.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)
[...]
情報メッセージは、一致するバックアップが見つかるまで継続して表示されます。
第13章 XFS ファイルシステムのサイズの拡大 リンクのコピーリンクがクリップボードにコピーされました!
システム管理者は、XFS ファイルシステムのサイズを増やして、より大きなストレージ容量を最大限に活用できます。ただし、現時点では XFS ファイルシステムのサイズは縮小できません。
ファイルシステムを非常に小さいサイズから大幅に大きいサイズに増やすと、多数の割り当てグループが作成され、パフォーマンスの問題が発生する可能性があります。ベストプラクティスとして、サイズの増加を元のサイズの最大 10 倍に制限します。
13.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オプションを指定しないと、基となるデバイスがサポートする最大サイズまでファイルシステムを拡張します。詳細は、システム上の
xfs_growfs(8)man ページを参照してください。
第14章 XFS エラー動作の設定 リンクのコピーリンクがクリップボードにコピーされました!
異なる I/O エラーが発生すると、XFS ファイルシステムの動作を設定できます。エラー処理をカスタマイズすることで、システムが失敗した操作を再試行するか、エラーが発生しても処理を継続するか、またはシャットダウンするかを制御できます。これにより、データの破損を防ぎ、ワークロードの要件やストレージの信頼性に合わせて動作を調整できるようになります。
14.1. XFS で設定可能なエラー処理 リンクのコピーリンクがクリップボードにコピーされました!
I/O エラーの再試行制限とタイムアウトを設定することで、XFS ファイルシステムのエラー処理を設定できます。XFS がデバイスエラー、空き領域不足状態、およびデバイスの損失にどのように応答するかを制御し、操作中およびアンマウント時の信頼性と柔軟性を向上させます。
XFS ファイルシステムは、I/O 操作中にエラーが発生すると、以下のいずれかの方法で応答します。
XFS は、操作が成功するまで、または XFS が設定制限に到達するまで I/O 操作を繰り返し再試行します。
この制限は、再試行の最大数または再試行の最大時間を基にしています。
- XFS は、エラーを永続的に考慮し、ファイルシステムで操作を停止します。
XFS が以下のエラー条件に反応する方法を設定できます。
EIO- 読み取りまたは書き込み時のエラー
ENOSPC- デバイスに空き容量がない
ENODEV- デバイスが見つからない
最大再試行回数と、XFS がエラーを永続的と見なすまでの最大時間を秒単位で設定できます。XFS は、いずれかの制限に達すると操作の再試行を停止します。
また、ファイルシステムのマウントを解除するときに、他の設定に関係なく XFS が再試行を即座にキャンセルするように XFS を設定することもできます。この設定により、永続的なエラーを出しても、マウント解除操作は成功します。
デフォルトの動作
各 XFS エラー条件のデフォルトの動作は、エラーコンテキストによって異なります。ENODEV などの XFS エラーは、リトライ回数に関係なく致命的で回復不能とみなされます。デフォルトの再試行制限は 0 です。
14.2. 特定の、未定義の XFS エラー条件の設定ファイル リンクのコピーリンクがクリップボードにコピーされました!
特定のエラー条件に対する再試行制限とタイムアウト、および未定義のエラーに対するデフォルトを設定するファイルを通じて 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 が操作の再試行を停止するまでの時間制限を秒単位で指定します。
14.3. 特定の条件に対する XFS 動作の設定 リンクのコピーリンクがクリップボードにコピーされました!
sysfs パラメーターを使用して、特定のエラー条件に対する最大再試行回数とタイムアウト制限を設定することで、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です。
14.4. 未定義の条件に対する XFS 動作の設定 リンクのコピーリンクがクリップボードにコピーされました!
未定義のエラー条件に対する再試行回数とタイムアウト制限を設定することで、デフォルトの XFS メタデータエラー処理を設定します。これは sysfs パラメーターを使用することで可能です。
手順
再試行の最大数、再試行時間制限、またはその両方を設定します。
再試行の最大数を設定するには、必要な数を
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です。
14.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です。
第15章 PCP を使用した XFS のパフォーマンス分析 リンクのコピーリンクがクリップボードにコピーされました!
XFS PMDA は、pcp パッケージの一部として提供され、インストール時にデフォルトで有効になります。これは、Performance Co-Pilot (PCP) で XFS ファイルシステムのパフォーマンスメトリクスデータを収集するために使用されます。PCP を使用すると、XFS ファイルシステムのパフォーマンスを分析できます。
15.1. XFS PMDA の手動インストール リンクのコピーリンクがクリップボードにコピーされました!
XFS パフォーマンスメトリクスドメインエージェント (PMDA) を手動でインストールします。エージェントが pcp 設定出力に表示されていない場合は、インストールスクリプトを実行することでこれを行うことができます。
前提条件
- Performance Co-Pilot (PCP) がインストールされています。詳細は PCP のインストールおよび有効化 を参照してください。
手順
xfs ディレクトリーに移動します。
# cd /var/lib/pcp/pmdas/xfs/XFS PMDA を手動でインストールします。
xfs]# ./Install Updating the Performance Metrics Name Space (PMNS) ... Terminate PMDA if already installed ... Updating the PMCD control file, and notifying PMCD ... Check xfs metrics have appeared ... 387 metrics and 387 values
検証
pmcdプロセスがホストで実行しており、設定リストに XFS PMDA が有効として記載されていることを確認します。# pcpPerformance Co-Pilot configuration on workstation: platform: Linux workstation 4.18.0-80.el8.x86_64 #1 SMP Wed Mar 13 12:02:46 UTC 2019 x86_64 hardware: 12 cpus, 2 disks, 1 node, 36023MB RAM timezone: CEST-2 services: pmcd pmcd: Version 4.3.0-1, 8 agents pmda: root pmcd proc xfs linux mmv kvm jbd2詳細は、システム上の
pmcd(1)man ページを参照してください。
15.2. pminfo を使用した XFS パフォーマンスメトリクスの検証 リンクのコピーリンクがクリップボードにコピーされました!
PCP は、XFS PMDA を介して、マウントされた XFS ファイルシステムごとに特定の XFS メトリクスのレポート作成をサポートしています。これにより、特定のマウントされたファイルシステムの問題を特定して、パフォーマンスを評価することが容易になります。pminfo コマンドは、マウントされた各 XFS ファイルシステムの各デバイスに対する XFS メトリクスを提供します。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
手順
XFS PMDA が提供する利用可能なメトリクスのリストを表示します。
# pminfo xfs個別のメトリクスの情報を表示します。以下の例では、
pminfoツールを使用して、特定の XFS の読み取りおよび書き込みメトリクスを調べます。xfs.write_bytesメトリクスの簡単な説明を表示します。# pminfo --oneline xfs.write_bytesxfs.write_bytes [number of bytes written in XFS file system write operations]xfs.read_bytesメトリクスの長い説明を表示します。# pminfo --helptext xfs.read_bytesxfs.read_bytes Help: This is the number of bytes read from read(2) system calls to files in XFS file systems. It can be used in conjunction with the read_calls count to calculate the average size of the read operations to file in XFS file systems.xfs.read_bytesメトリクスの現在のパフォーマンス値を取得します。# pminfo --fetch xfs.read_bytesxfs.read_bytes value 4891346238pminfoで、デバイスごとの XFS メトリクスを取得します。# pminfo --fetch --oneline xfs.perdev.read xfs.perdev.writexfs.perdev.read [number of XFS file system read operations] inst [0 or "loop1"] value 0 inst [0 or "loop2"] value 0 xfs.perdev.write [number of XFS file system write operations] inst [0 or "loop1"] value 86 inst [0 or "loop2"] value 0詳細は、システム上の
pminfo(1)man ページを参照してください。
15.3. pmstore を使用した XFS パフォーマンスメトリクスのリセット リンクのコピーリンクがクリップボードにコピーされました!
PCP を使用すると、特に特定のメトリクスが、xfs.control.reset メトリクスなどの制御変数として動作する場合は、そのメトリクスの値を変更できます。メトリクスの値を変更するには、pmstore ツールを使用します。
前提条件
- PCP がインストールされている。詳細は PCP のインストールおよび有効化 を参照してください。
手順
メトリクスの値を表示します。
$ pminfo -f xfs.writexfs.write value 325262すべての XFS メトリクスをリセットします。
# pmstore xfs.control.reset 1xfs.control.reset old value=0 new value=1
検証
メトリクスをリセットした後に情報を表示します。
$ pminfo --fetch xfs.writexfs.write value 0詳細は、システム上の
pmstore(1)およびpminfo(1)man ページを参照してください。
15.4. XFS の PCP メトリクスグループ リンクのコピーリンクがクリップボードにコピーされました!
Performance Co-Pilot は、割り当て、トランザクション、バッファーアクティビティーなど、すべてのデバイスにわたる XFS ファイルシステム操作を監視するための包括的なメトリクスグループを提供します。
以下の表は、XFS で利用可能な PCP メトリクスグループを説明しています。
| メトリクスグループ | 提供されたメトリクス |
|
| 読み書き操作の数、読み書きバイト数を含む一般的な XFS メトリクス。inode がフラッシュされた回数、クラッシュした回数、クラスター化に失敗した数に関するカウンターを併用。 |
|
| ファイルシステムのオブジェクトの割り当てに関するメトリクスの範囲。これには、エクステントおよびブロックの作成/解放の数が含まれます。割り当てツリーの検索と、拡張レコードの作成と btree からの削除との比較。 |
|
| メトリクスには、ブロックマップの読み取り/書き込みとブロックの削除の数、挿入、削除、および検索のためのエクステントリスト操作が含まれます。また、ブロックマップからの比較、検索、挿入、および削除に関する操作カウンター。 |
|
| 作成、エントリー削除、"getdent” の操作の数に対する XFS ファイルシステムのディレクトリー操作のカウンター。 |
|
| メタデータトランザクションの数のカウンター。これには、空のトランザクションの数と、同期および非同期のトランザクションの数のカウントが含まれます。 |
|
| オペレーティングシステムが、複数の結果で inode キャッシュの XFS inode を検索する回数のカウンター。このカウントキャッシュのヒット数、キャッシュミスなど。 |
|
| XFS ファイルシステムにおけるログバッファー書き込み回数のカウンターには、ディスクに書き込まれたブロック数が含まれます。また、ログフラッシュおよびピニングの数のメトリクスです。 |
|
| XFS フラッシュデーモンによってフラッシュされたファイルデータのバイト数をカウントし、ディスク上の連続領域と非連続領域にフラッシュされたバッファーの数をカウントします。 |
|
| すべての XFS ファイルシステムでの属性の取得、設定、削除、およびリスト表示の操作数のカウント。 |
|
| XFS ファイルシステムでのクォータ操作のメトリクス。これには、クォータ回収、クォータキャッシュミス、キャッシュヒット、およびクォータデータの回収の数に関するカウンターが含まれます。 |
|
| XFS バッファーオブジェクトに関するメトリクスの範囲。カウンターには、ページ検索時に要求されたバッファーコールの数、成功したバッファーロック、待機バッファーロック、失敗したときのロック、失敗したときの再試行、バッファーヒットが含まれます。 |
|
| XFS btree の操作に関するメトリクス。 |
|
| XFS 統計のメトリクスカウンターをリセットするのに使用される設定メトリクス。コントロールメトリクスは、pmstore ツールを使用して切り替えられます。 |
15.5. XFS のデバイスごとの PCP メトリクスグループ リンクのコピーリンクがクリップボードにコピーされました!
Performance Co-Pilot は、割り当てからトランザクション管理までの操作を網羅し、個々の XFS デバイスを監視するためのメトリクスグループを提供します。
以下の表は、XFS で利用可能なデバイスごとの PCP メトリクスグループを説明しています。
| メトリクスグループ | 提供されたメトリクス |
|
| 読み書き操作の数、読み書きバイト数を含む一般的な XFS メトリクス。inode がフラッシュされた回数、クラッシュした回数、クラスター化に失敗した数に関するカウンターを併用。 |
|
| ファイルシステムのオブジェクトの割り当てに関するメトリクスの範囲。これには、エクステントおよびブロックの作成/解放の数が含まれます。割り当てツリーの検索と、拡張レコードの作成と btree からの削除との比較。 |
|
| メトリクスには、ブロックマップの読み取り/書き込みとブロックの削除の数、挿入、削除、および検索のためのエクステントリスト操作が含まれます。また、ブロックマップからの比較、検索、挿入、および削除に関する操作カウンター。 |
|
| 作成、エントリー削除、"getdent” の操作の数に対する XFS ファイルシステムのディレクトリー操作のカウンター。 |
|
| メタデータトランザクションの数のカウンター。これには、空のトランザクションの数と、同期および非同期のトランザクションの数のカウントが含まれます。 |
|
| オペレーティングシステムが、複数の結果で inode キャッシュの XFS inode を検索する回数のカウンター。このカウントキャッシュのヒット数、キャッシュミスなど。 |
|
| XFS ファイルシステムにおけるログバッファー書き込み回数のカウンターには、ディスクに書き込まれたブロック数が含まれます。また、ログフラッシュおよびピニングの数のメトリクスです。 |
|
| XFS フラッシュデーモンによってフラッシュされたファイルデータのバイト数をカウントし、ディスク上の連続領域と非連続領域にフラッシュされたバッファーの数をカウントします。 |
|
| すべての XFS ファイルシステムでの属性の取得、設定、削除、およびリスト表示の操作数のカウント。 |
|
| XFS ファイルシステムでのクォータ操作のメトリクス。これには、クォータ回収、クォータキャッシュミス、キャッシュヒット、およびクォータデータの回収の数に関するカウンターが含まれます。 |
|
| XFS バッファーオブジェクトに関するメトリクスの範囲。カウンターには、ページ検索時に要求されたバッファーコールの数、成功したバッファーロック、待機バッファーロック、失敗したときのロック、失敗したときの再試行、バッファーヒットが含まれます。 |
|
| XFS btree の操作に関するメトリクス。 |
第16章 ファイルシステムの検査と修復 リンクのコピーリンクがクリップボードにコピーされました!
RHEL は、ファイルシステムをチェックおよび修復するための fsck (ファイルシステムチェック) と呼ばれるファイルシステム管理ツールを提供します。問題が検出されると、システム管理ツールは起動時に自動的に実行される可能性がありますが、必要に応じて手動で実行することもできます。
ファイルシステムチェッカーは、ファイルシステム全体のメタデータの整合性のみを保証します。チェッカーは、ファイルシステムに含まれる実際のデータを認識しないため、データのリカバリーツールではありません。
16.1. ファイルシステムの検査が必要なシナリオ リンクのコピーリンクがクリップボードにコピーされました!
破損、ブート失敗、システムエラーなど、ファイルシステムチェックが必要な状況を特定します。ファイルシステムの問題を診断および修復するために、適切な対策と考慮事項を講じることができます。標準的なチェックユーティリティーを使用すれば、これを実現できます。
以下のいずれかが発生した場合は、関連する fsck ツールを使用してシステムを検査できます。
- システムが起動しない
- 特定ディスクのファイルが破損する
- 不整合によりファイルシステムがシャットダウンするか、読み取り専用に変更する
- ファイルシステムのファイルにアクセスできない
ファイルシステムの不整合は、ハードウェアエラー、ストレージ管理エラー、ソフトウェアバグなどのさまざまな理由で発生する可能性があります。
ファイルシステムの検査ツールは、ハードウェアの問題を修復できません。修復を正常に動作させるには、ファイルシステムが完全に読み取り可能かつ書き込み可能である必要があります。ハードウェアエラーが原因でファイルシステムが破損した場合は、まず dd(8) ユーティリティーなどを使用して、ファイルシステムを適切なディスクに移動する必要があります。
ジャーナリングファイルシステムの場合、システムの起動時に通常必要なのは、必要に応じてジャーナルを再生することだけで、これは通常非常に短い操作になります。
ただし、ジャーナリングファイルシステムであっても、ファイルシステムの不整合や破損が発生した場合は、ファイルシステムチェッカーを使用してファイルシステムを修復する必要があります。
/etc/fstab の 6 番目のフィールドを 0 に設定すると、システムの起動時にファイルシステムの検査を無効にできます。ただし、起動時に fsck で問題が発生している場合 (たとえば、非常に大きなファイルシステムやリモートファイルシステムを使用している場合など) を除き、この操作は行わないでください。
詳細は、システム上の fstab(5)、fsck(8)、および dd(8) man ページを参照してください。
16.2. fsck の実行による潜在的な悪影響 リンクのコピーリンクがクリップボードにコピーされました!
通常、ファイルシステムの検査および修復のツールを実行すると、検出された不整合の少なくとも一部が自動的に修復されることが期待できます。場合によっては、以下の問題が発生する場合があります。
- inode やディレクトリーが大幅に損傷し、修復できない場合は、破棄される場合があります。
- ファイルシステムが大きく変更する場合があります。
予期しない変更や、望ましくない変更が永続的に行われないようにするには、この手順にまとめられている予防手順を行ってください。
16.3. XFS のエラー処理メカニズム リンクのコピーリンクがクリップボードにコピーされました!
このセクションでは、XFS がファイルシステム内のさまざまな種類のエラーを処理する方法を説明します。
不完全なアンマウント
ジャーナリングは、ファイルシステムで発生したメタデータの変更のトランザクション記録を保持します。
システムクラッシュ、電源障害、またはその他の不完全なアンマウントが発生した場合、XFS はジャーナル (ログとも呼ばれる) を使用してファイルシステムを復旧します。カーネルは XFS ファイルシステムをマウントするときにジャーナルの復旧を実行します。
破損
この文脈での 破損 は、次のような原因によるファイルシステムのエラーを意味します。
- ハードウェア障害
- ストレージファームウェア、デバイスドライバー、ソフトウェアスタック、またはファイルシステム自体のバグ
- ファイルシステムの一部が、ファイルシステム外の何かにより上書きされる問題
XFS は、ファイルシステムまたはファイルシステムメタデータの破損を検出すると、ファイルシステムをシャットダウンして、システムログにインシデントを報告することがあります。なお、/var ディレクトリーが存在するファイルシステムで破損が発生した場合、再起動後にはこれらのログは利用できなくなりますのでご注意ください。
以下は、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 ユーティリティーを使用する必要があります。詳細は、システム上の xfs_repair(8) man ページを参照してください。
16.4. xfs_repair による XFS ファイルシステムの検査 リンクのコピーリンクがクリップボードにコピーされました!
xfs_repair ユーティリティーを使用して、XFS ファイルシステムの読み取り専用チェックを実行します。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詳細は、システム上の
xfs_repair(8)およびxfs_metadump(8)man ページを参照してください。
16.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詳細は、システム上の
xfs_repair(8)man ページを参照してください。
16.6. ext2、ext3、および ext4 でエラー処理メカニズム リンクのコピーリンクがクリップボードにコピーされました!
ext2、ext3、および ext4 ファイルシステムでは、チェックと修復に e2fsck が使用されます。fsck.ext2、fsck.ext3、および fsck.ext4 バイナリーは e2fsck へのハードリンクであり、起動時に自動的に実行されます。それらの動作は、ファイルシステムの種類とその状態によって異なります。
完全なファイルシステムの検査および修復は、メタデータジャーナリングファイルシステムではない ext2 や、ジャーナルのない ext4 ファイルシステムに対して呼び出されます。
メタデータジャーナリング機能のある ext3 ファイルシステムおよび ext4 ファイルシステムの場合、ジャーナルはユーザー空間で再生され、ユーティリティーは終了します。これは、ジャーナルの再生によりクラッシュ後のファイルシステムの整合性が確保されるためのデフォルト動作になります。
このファイルシステムで、マウント中にメタデータの不整合が生じると、その事実がファイルシステムのスーパーブロックに記録されます。e2fsck が、このようなエラーでファイルシステムがマークされていることを検出すると、e2fsck はジャーナル (がある場合) の再生後にフルチェックを実行します。
詳細は、システム上の fsck(8) および e2fsck(8) man ページを参照してください。
16.7. e2fsck で ext2、ext3、または ext4 ファイルシステムの検査 リンクのコピーリンクがクリップボードにコピーされました!
ext2、ext3、または ext4 ファイルシステムをチェックするには、e2fsck -n を使用して、変更を加えずにエラーを報告するドライランを実行します。
手順
ファイルシステムを再マウントしてログを再生します。
# mount file-system# umount file-systemドライランを実行して、ファイルシステムを検査します。
# e2fsck -n block-device注記エラーが表示され、ファイルシステムを変更せずに実行できるアクションが示されます。整合性チェック後のフェーズでは、修復モードで実行していた場合に前のフェーズで修正されていた不整合が検出される可能性があるため、追加のエラーが出力される場合があります。
詳細は、システム上の
e2image(8)およびe2fsck(8)man ページを参照してください。
16.8. e2fsck で ext2、ext3、または ext4 ファイルシステムの修復 リンクのコピーリンクがクリップボードにコピーされました!
e2fsck -p を使用して、破損した ext2、ext3、または ext4 ファイルシステムを自動修復します。診断用のメタデータイメージをオプションで作成することで、これを実現できます。
手順
サポート調査のためにファイルシステムイメージを保存します。修復前のファイルシステムメタデータイメージは、破損がソフトウェアのバグによるものであるかどうかのサポート調査に役立ちます。修復前のイメージに含まれる破損のパターンは、根本的な分析に役に立つ場合があります。
注記ファイルシステムが大幅に損傷している場合は、メタデータイメージの作成に関連して問題が発生する可能性があります。
テスト目的でイメージを作成する場合は、
-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
第17章 ファイルシステムのマウント リンクのコピーリンクがクリップボードにコピーされました!
システム管理者は、システムにファイルシステムをマウントすると、ファイルシステムのデータにアクセスできます。
17.1. Linux のマウントメカニズム リンクのコピーリンクがクリップボードにコピーされました!
Linux、UNIX、および同様のオペレーティングシステムでは、ファイルシステムは異なるパーティションやリムーバブルデバイス上に存在できます。例としては、CD、DVD、USB フラッシュドライブなどが挙げられる。これらのファイルシステムは、ディレクトリーツリー内の特定の場所 (マウントポイントと呼ばれる) に接続することができます。それらは再び取り外すこともできます。ファイルシステムがディレクトリーにマウントされている間は、そのディレクトリーの元の内容にアクセスすることはできません。
Linux では、すでにファイルシステムが接続されているディレクトリーに、別のファイルシステムをマウントすることを妨げません。
マウント時には、次の方法でデバイスを識別できます。
-
汎用一意識別子 (UUID):
UUID=34795a28-ca6d-4fd8-a347-73671d0c19cbなど -
ボリュームラベル -
LABEL=homeなど -
非永続的なブロックデバイスへのフルパス -
/dev/sda3など
必要な情報をすべて指定せずに mount コマンドを使用してファイルシステムをマウントする場合、コマンドはデフォルト値を使用します。これには、デバイス名、ターゲットディレクトリー、またはファイルシステムの種類が指定されていない場合も含まれます。このような場合、マウント ユーティリティーは /etc/fstab ファイルの内容を読み取ります。指定されたファイルシステムがそこにリストされているかどうかを確認します。
/etc/fstab ファイルには、デバイス名とディレクトリーのリストが含まれています。これらのディレクトリーは、選択されたファイルシステムがマウントされている場所を示しています。ファイルには、ファイルシステムの種類とマウントオプションも指定されています。したがって、/etc/fstab に記載されているファイルシステムをマウントする場合は、以下のコマンド構文で十分です。
マウントポイントによるマウント:
# mount directoryブロックデバイスによるマウント:
# mount device
17.2. 現在マウントされているファイルシステムのリスト表示 リンクのコピーリンクがクリップボードにコピーされました!
findmnt ユーティリティーを使用して、現在マウントされているすべてのファイルシステムを、コマンドラインでリスト表示します。
手順
マウントされているファイルシステムのリストを表示するには、
findmntユーティリティーを使用します。$ findmntリスト表示されているファイルシステムを、特定のファイルシステムタイプに制限するには、
--typesオプションを追加します。$ findmnt --types fs-typeたとえば、以下は XFS ファイルシステムのみをリスト表示する例です。
$ findmnt --types xfsTARGET 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
17.3. mount でファイルシステムのマウント リンクのコピーリンクがクリップボードにコピーされました!
mount ユーティリティーを使用してファイルシステムをマウントします。
前提条件
選択したマウントポイントにファイルシステムがまだマウントされていないことを確認する。
$ findmnt mount-point
手順
特定のファイルシステムを添付する場合は、
mountユーティリティーを使用します。# mount device mount-pointたとえば、UUID により識別されるローカル XFS ファイルシステムをマウントするには、次のコマンドを実行します。
# mount UUID=ea74bbec-536d-490c-b8d9-5b40bbd7545b /mnt/datamount コマンドがファイルシステムの種類を自動的に認識できない場合は、--typesオプションを使用して指定してください。# mount --types type device mount-pointたとえば、リモートの NFS ファイルシステムをマウントするには、次のコマンドを実行します。
# mount --types nfs4 host:/remote-export /mnt/nfs
17.4. マウントポイントの移動 リンクのコピーリンクがクリップボードにコピーされました!
mount ユーティリティーを使用して、マウントされたファイルシステムのマウントポイントを別のディレクトリーに変更します。
手順
ファイルシステムがマウントされているディレクトリーを変更するには、以下のコマンドを実行します。
# mount --move old-directory new-directoryたとえば、
/mnt/userdirs/ディレクトリーにマウントされたファイルシステムを/home/マウントポイントに移動するには、以下のコマンドを実行します。# mount --move /mnt/userdirs /homeファイルシステムが想定どおりに移動したことを確認します。
$ findmnt$ ls old-directory$ ls new-directory
17.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その後、ファイルシステムを使用してプロセスを停止し、再度アンマウントを試みてください。
17.6. Web コンソールでのファイルシステムのマウントとマウント解除 リンクのコピーリンクがクリップボードにコピーされました!
RHEL システムでパーティションを使用できるようにするには、パーティションにファイルシステムをデバイスとしてマウントする必要があります。
ファイルシステムのマウントを解除することもできます。アンマウントすると RHEL システムはその使用を停止します。ファイルシステムをアンマウントすることで、デバイスの削除、除去、または再フォーマットを行うことができます。
前提条件
-
cockpit-storagedパッケージがシステムにインストールされている。 RHEL 10 Web コンソールがインストールされている。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
- ファイルシステムのマウントを解除する場合は、システムがパーティションに保存されているファイル、サービス、またはアプリケーションを使用しないようにする。
手順
- RHEL 10 Web コンソールにログインします。
- Storage タブをクリックします。
- Storage テーブルで、パーティションを削除するボリュームを選択します。
- GPT partitions セクションで、ファイルシステムをマウントまたはマウント解除するパーティションの横にあるメニューボタン をクリックします。
- または をクリックします。
17.7. 一般的なマウントオプション リンクのコピーリンクがクリップボードにコピーされました!
マウントユーティリティーは、さまざまなファイルシステムタイプにわたってファイルシステムの動作、アクセス権限、マウント設定を制御するためのさまざまなオプションをサポートしています。
次の表に、mount ユーティリティーの最も一般的なオプションを示します。以下の構文を使用することで、これらのマウントオプションを適用できます。
# mount --options option1,option2,option3 device mount-point
| オプション | 説明 |
|---|---|
|
| ファイルシステムで非同期の入出力を可能にします。 |
|
|
|
|
|
|
|
| バイナリーファイルがファイルシステム上で実行可能であることを指定します。 |
|
| イメージをループデバイスとしてマウントします。 |
|
|
デフォルトの動作では |
|
| 特定のファイルシステムでのバイナリーファイルの実行は許可しません。 |
|
| 普通のユーザー (つまり root 以外のユーザー) によるファイルシステムのマウントおよびアンマウントは許可しません。 |
|
| ファイルシステムがすでにマウントされている場合は再度マウントを行います。 |
|
| 読み取り専用でファイルシステムをマウントします。 |
|
| ファイルシステムを読み取りと書き込み両方でマウントします。 |
|
| 非 root ユーザーがファイルシステムをマウントおよびアンマウントできることを指定します。 |
第18章 複数のマウントポイントでのマウント共有 リンクのコピーリンクがクリップボードにコピーされました!
システム管理者は、マウントポイントを複製して、複数のディレクトリーからファイルシステムにアクセスするようにできます。
18.2. プライベートマウントポイントの複製の作成 リンクのコピーリンクがクリップボードにコピーされました!
マウントポイントをプライベートマウントとして複製します。複製後に、複製または元のマウントポイントにマウントするファイルシステムは、他方のマウントポイントには反映されません。
手順
元のマウントポイントから仮想ファイルシステム (VFS) ノードを作成します。
# mount --bind original-dir original-dir元のマウントポイントをプライベートとしてマークします。
# mount --make-private original-dirあるいは、選択したマウントポイントと、その下のすべてのマウントポイントのマウントタイプを変更するには、
--make-privateではなく、--make-rprivateオプションを使用します。複製を作成します。
# mount --bind original-dir duplicate-dir
例18.1 プライベートマウントポイントとして /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/cdromEFI GPL isolinux LiveOS# ls /mnt/cdrom #また、
/mntディレクトリーにマウントされているファイルシステムが/mediaに反映されていないことを確認することもできます。たとえば、/dev/sdc1デバイスを使用する、空でない USB フラッシュドライブをプラグインしており、/mnt/flashdisk/ディレクトリーが存在する場合は、次のコマンドを実行します。# mount /dev/sdc1 /mnt/flashdisk# ls /media/flashdisk# ls /mnt/flashdisken-US publican.cfg
18.4. スレーブマウントポイントの複製の作成 リンクのコピーリンクがクリップボードにコピーされました!
マウントポイントを slave マウントタイプとして複製します。複製後に、元のマウントポイントにマウントしたファイルシステムは複製に反映されますが、その逆は反映されません。
手順
元のマウントポイントから仮想ファイルシステム (VFS) ノードを作成します。
# mount --bind original-dir original-dir元のマウントポイントを共有としてマークします。
# mount --make-shared original-dirあるいは、選択したマウントポイントとその下のすべてのマウントポイントのマウントタイプを変更する場合は、
--make-sharedではなく、--make-rsharedオプションを使用します。複製を作成し、これを
slaveタイプとしてマークします。# mount --bind original-dir duplicate-dir# mount --make-slave duplicate-dir
例18.3 スレーブマウントポイントとして /mnt に /media を複製
この例は、/media ディレクトリーのコンテンツが /mnt にも表示されるけれども、/mnt ディレクトリーのマウントが /media に反映されないようにする方法を示しています。
/mediaディレクトリーから VFS ノードを作成します。# mount --bind /media /media/mediaディレクトリーを共有としてマークします。# mount --make-shared /mediaその複製を
/mntに作成し、slaveとしてマークします。# mount --bind /media /mnt# mount --make-slave /mnt/media内のマウントが/mntにも表示されていることを確認します。たとえば、CD-ROM ドライブに空でないメディアがあり、/media/cdrom/ディレクトリーが存在する場合は、以下のコマンドを実行します。# mount /dev/cdrom /media/cdrom# ls /media/cdromEFI GPL isolinux LiveOS# ls /mnt/cdromEFI GPL isolinux LiveOSまた、
/mntディレクトリーにマウントされているファイルシステムが/mediaに反映されていないことを確認します。たとえば、/dev/sdc1デバイスを使用する、空でない USB フラッシュドライブをプラグインしており、/mnt/flashdisk/ディレクトリーが存在する場合は、次のコマンドを実行します。# mount /dev/sdc1 /mnt/flashdisk# ls /media/flashdisk# ls /mnt/flashdisken-US publican.cfg
18.5. マウントポイントが複製されないようにする リンクのコピーリンクがクリップボードにコピーされました!
マウントポイントをバインド不可としてマークし、別のマウントポイントに複製できないようにします。
手順
マウントポイントのタイプをバインド不可なマウントに変更するには、以下のコマンドを使用します。
# mount --bind mount-point mount-point# mount --make-unbindable mount-pointあるいは、選択したマウントポイントとその下のすべてのマウントポイントのマウントタイプを変更する場合は、
--make-unbindableの代わりに、--make-runbindableオプションを使用します。これ以降、このマウントの複製を作成しようとすると、以下のエラーが出て失敗します。
# mount --bind mount-point duplicate-dirmount: 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
例18.4 /media が複製されないようにする
/mediaディレクトリーが共有されないようにするには、以下のコマンドを実行します。# mount --bind /media /media# mount --make-unbindable /media
第19章 ファイルシステムの永続的なマウント リンクのコピーリンクがクリップボードにコピーされました!
システム管理者は、ファイルシステムを永続的にマウントして、非リムーバブルストレージを設定できます。
19.1. /etc/fstab ファイル リンクのコピーリンクがクリップボードにコピーされました!
/etc/fstab 設定ファイルを使用して、ファイルシステムの永続的なマウントポイントを制御します。/etc/fstab ファイルの各行は、ファイルシステムのマウントポイントを定義します。
空白で区切られた次のフィールドが含まれます。
-
/devディレクトリーの永続的な属性またはパスで識別されるブロックデバイス。 - デバイスがマウントされるディレクトリー。
- デバイス上のファイルシステム。
-
ファイルシステムのマウントオプション。これには、ブート時にデフォルトオプションでパーティションをマウントする
defaultsオプションが含まれます。マウントオプションフィールドは、x-systemd.option形式のsystemdマウントユニットオプションも認識します。 -
dumpユーティリティーのオプションのバックアップを作成します。 -
fsckユーティリティーの順序を確認します。
systemd-fstab-generator は、エントリーを /etc/fstab ファイルから systemd-mount ユニットに動的に変換します。systemd-mount ユニットがマスクされていない限り、systemd は手動アクティベーション中に /etc/fstab から LVM ボリュームを自動マウントします。
例19.1 /etc/fstab の /boot ファイルシステム
| ブロックデバイス | マウントポイント | ファイルシステム | オプション | バックアップ | チェック |
|---|---|---|---|---|---|
|
|
|
|
|
|
|
systemd サービスは、/etc/fstab のエントリーからマウントユニットを自動的に生成します。
詳細は、システム上の fstab(5) および systemd.mount(5) man ページを参照してください。
19.2. /etc/fstab へのファイルシステムの追加 リンクのコピーリンクがクリップボードにコピーされました!
/etc/fstab 設定ファイルでファイルシステムの永続的なマウントポイントを設定します。
手順
ファイルシステムの汎用一意識別子 (UUID) 属性を調べます。
$ lsblk --fs storage-deviceたとえば、パーティションの UUID を表示します。
$ lsblk --fs /dev/sda1NAME FSTYPE LABEL UUID MOUNTPOINT sda1 xfs Boot ea74bbec-536d-490c-b8d9-5b40bbd7545b /bootこのマウントポイントのディレクトリーがない場合は、作成します。
# mkdir --parents mount-pointroot で
/etc/fstabファイルを編集し、ファイルシステムに行を追加します (UUID で識別されます)。たとえば、以下は
/etc/fstabにおける/bootマウントポイントを示しています。UUID=ea74bbec-536d-490c-b8d9-5b40bbd7545b /boot xfs defaults 0 0システムが新しい設定を登録するように、マウントユニットを再生成します。
# systemctl daemon-reloadファイルシステムをマウントして、設定が機能することを確認します。
# mount mount-point
第20章 オンデマンドでのファイルシステムのマウント リンクのコピーリンクがクリップボードにコピーされました!
システム管理者は、NFS などのファイルシステムをオンデマンドで自動的にマウントするように設定できます。
20.1. autofs サービス リンクのコピーリンクがクリップボードにコピーされました!
autofs サービスは、ファイルシステムの自動マウントおよび自動アンマウントが可能なため (オンデマンド)、システムのリソースを節約できます。ネットワークファイルシステム (NFS)、アンドリューファイルシステム (AFS)、サーバーメッセージブロックファイルシステム (SMBFS)、CIFS などのファイルシステムをマウントします。
/etc/fstab を使用して永続的にマウントする場合の欠点の 1 つは、マウントされたファイルシステムを維持するためにシステムがリソースを割り当てる必要があることです。これは、ユーザーがそのサービスにアクセスする頻度に関係なく発生します。これは、システムが一度に多数のシステムへの NFS マウントを維持している場合などに、システムのパフォーマンスに影響を与える可能性があります。
/etc/fstab に代わるのは、カーネルベースの autofs サービスの使用です。構成は次のとおりです。
- ファイルシステムを実装するカーネルモジュール
- 他のすべての機能を実行するユーザー空間サービス
詳細は、システム上の autofs(8) man ページを参照してください。
20.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
- 指定した場合に、エントリーにオプションが指定されていなければ、指定されたマップ内のすべてのエントリーに適用されます。
例20.1 /etc/auto.master ファイル
以下は /etc/auto.master ファイルのサンプル行です。
/mnt/data /etc/auto.data
マップファイル
マップファイルは、個々のオンデマンドマウントポイントのプロパティーを設定します。
ディレクトリーが存在しない場合、自動マウント機能はディレクトリーを作成します。ディレクトリーがオートマウンターの起動前に存在していた場合、オートマウンターは終了時にそれらを削除しません。タイムアウトを指定した場合は、タイムアウト期間中ディレクトリーにアクセスしないと、ディレクトリーが自動的にアンマウントされます。
マップの一般的な形式は、マスターマップに似ています。ただし、マスターマップでは、オプションフィールドはエントリーの末尾ではなく、マウントポイントと場所の間に表示されます。
mount-point options location
この形式で使用されている変数を以下に示します。
- mount-point
-
これは、
autofsのマウントポイントを参照しています。これは 1 つのインダイレクトマウント用の 1 つのディレクトリー名にすることも、複数のダイレクトマウント用のマウントポイントの完全パスにすることもできます。ダイレクトマップとインダイレクトマップの各エントリーキー (mount-point) の後に空白で区切られたオフセットディレクトリー (/で始まるサブディレクトリー名) が記載されます。これがマルチマウントエントリーと呼ばれるものです。 - options
-
このオプションを指定すると、マスターマップエントリーのオプション (存在する場合) に追加されます。設定エントリーの
append_optionsがnoに設定されている場合は、マスターマップのオプションの代わりにこのオプションが使用されます。 - location
-
ローカルファイルシステムのパス (Sun マップ形式のエスケープ文字
:が先頭に付き、マップ名が/で始まります)、NFS ファイルシステム、他の有効なファイルシステムの場所などのファイルシステムの場所を参照します。
例20.2 マップファイル
以下は、マップファイルのサンプルです (例: /etc/auto.misc)。このマップファイルを /misc 配下のマウントに使用するには、マスターマップファイル /etc/auto.master に以下を追加します。
/misc /etc/auto.misc
/etc/auto.misc ファイルには次の内容が含まれます。
payroll -fstype=nfs4 personnel:/exports/payroll
sales -fstype=xfs :/dev/hda4
マップファイルの最初の列は、autofs マウントポイント (personnel サーバーからの sales と payroll) を示しています。2 列目は、autofs マウントのオプションを示しています。3 列目はマウントのソースを示しています。
指定された設定に従って、autofs マウントポイントは /home/payroll と /home/sales に なります。-fstype= オプションは多くの場合省略されており、ファイルシステムが NFS の場合は必要ありません。これには、システムのデフォルトが NFS マウント用の NFSv4 である場合の NFSv4 のマウントも含まれます。
指定された設定を使用すると、プロセスが /home/payroll/2006/July.sxc のような autofs でマウントされていないディレクトリーへのアクセスを必要とする場合、autofs サービスは自動的にそのディレクトリーをマウントします。
amd マップ形式
autofs サービスは、amd 形式のマップ設定も認識します。これは Red Hat Enterprise Linux から削除された、am-utils サービス用に書き込まれた既存の自動マウント機能の設定を再利用する場合に便利です。
ただし、前のセクションで説明したよりシンプルな autofs 形式を使用してください。
詳細は、以下を参照してください。* システム上の autofs(5)、autofs.conf(5)、および auto.master(5) man ページ * /usr/share/doc/autofs/README.amd-maps ファイル
20.3. autofs マウントポイントの設定 リンクのコピーリンクがクリップボードにコピーされました!
autofs サービスを使用してオンデマンドマウントポイントを設定します。
前提条件
autofsパッケージをインストールしている。# dnf install autofsautofsサービスを起動して有効にしている。# systemctl enable --now autofs
手順
-
/etc/auto.identifierにあるオンデマンドマウントポイント用のマップファイルを作成します。identifier を、マウントポイントを識別する名前に置き換えます。 - マップファイルで、autofs 設定ファイル セクションの説明に従って、マウントポイント、オプション、および場所の各フィールドを入力します。
- autofs 設定ファイル セクションの説明に従って、マップファイルをマスターマップファイルに登録します。
設定の再読み込みを許可し、新しく設定した
autofsマウントを管理できるようにします。# systemctl reload autofs.serviceオンデマンドディレクトリーのコンテンツへのアクセスを試みます。
# ls automounted-directory
20.4. 自動マウントマップの保存と取得に LDAP を使用するように autofs を設定する リンクのコピーリンクがクリップボードにコピーされました!
LDAP ディレクトリーに保存されている自動マウントマップを取得するように autofs サービスを設定できます。
前提条件
-
autofsおよびopenldapパッケージがインストールされている。 - セキュアな認証のために Kerberos 対応サービスが実行中である。
手順
-
LDAP アクセスを設定するには、
/etc/openldap/ldap.confファイルを変更します。自動マウントエントリーを見つけるための適切なサーバーおよびベースを反映するために、BASEおよびURIオプションが設定されていることを確認します。 /etc/autofs.confファイルで、自動マウントマップの LDAP スキーマを設定します。デフォルトでは、autofsは頻繁に使用されるスキーマを設定ファイルに指定された順序でチェックします。# # Define the LDAP schema to used for lookups # # If no schema is set autofs checks each of the schemas # below in the order given to try and locate an appropriate # basdn for lookups. If you want to minimize the number of # queries to the server set the values here. # #map_object_class = nisMap #entry_object_class = nisObject #map_attribute = nisMapName #entry_attribute = cn #value_attribute = nisMapEntry # # Other common LDAP naming # #map_object_class = automountMap #entry_object_class = automount #map_attribute = ou #entry_attribute = cn #value_attribute = automountInformation # #map_object_class = automountMap #entry_object_class = automount #map_attribute = automountMapName #entry_attribute = automountKey #value_attribute = automountInformation注記これらの値を明示的に設定して、LDAP クエリーをわずかに減らすこともできます。
/etc/autofs.confファイルに小文字と大文字の両方で属性を書き込むことができます。自動マウント機能マップを LDAP に格納するためにデフォルトされた最新のスキーマが、
rfc2307bisドラフトに記載されています。このスキーマを使用するには、/etc/autofs.confファイルでコメントを解除し、ldap_schemaオプションに適切な値を設定してスキーマを設定します。たとえば、標準以外のスキーマを使用している場合や、デフォルトの動作をオーバーライドする必要がある場合は、/etc/autofs.confファイルで関連するスキーマ属性を指定できます。次の値は、rfc2307bisドラフトなどの一般的に使用されるスキーマ設定に対応しています。default_map_object_class = automountMap default_entry_object_class = automount default_map_attribute = automountMapName default_entry_attribute = automountKey default_value_atrribute = automountInformationautofs は、標準スキーマを自動的に検出します。通常、カスタムまたは混合スキーマ環境の場合にのみこれらの設定を指定する必要があります。使用する場合、スキーマ定義の完全なセットを 1 つだけアクティブにする必要があります。
設定でカスタムスキーマを指定する場合は、スキーマ関連のエントリーの完全なセットが 1 つだけアクティブになっていることを確認してください。競合を避けるため、その他はコメントアウトします。
rfc2307bisスキーマでは、automountKey属性が、古いrfc2307スキーマで使用されていたcn属性に置き換わります。以下は、対応する LDAP データ交換フォーマット (LDIF) 設定の例です。# auto.master, example.comdn: automountMapName=auto.master,dc=example,dc=com objectClass: top objectClass: automountMap automountMapName: auto.master# /home, auto.master, example.comdn: automountMapName=auto.master,dc=example,dc=com objectClass: automount automountKey: /home automountInformation: auto.home# auto.home, example.comdn: automountMapName=auto.home,dc=example,dc=com objectClass: automountMap automountMapName: auto.home# foo, auto.home, example.comdn: automountKey=foo,automountMapName=auto.home,dc=example,dc=com objectClass: automount automountKey: foo automountInformation: filer.example.com:/export/foo# /, auto.home, example.comdn: automountKey=/,automountMapName=auto.home,dc=example,dc=com objectClass: automount automountKey: / automountInformation: filer.example.com:/export/&LDAP サーバーからの認証を許可するには、
/etc/autofs_ldap_auth.confファイルを編集します。-
authrequiredを yes に変更します。 プリンシパルを LDAP サーバー (
host/FQDN@REALM) の Kerberos ホストプリンシパルに設定します。プリンシパル名は、GSS クライアント認証の一部としてディレクトリーへの接続に使用されます。<autofs_ldap_sasl_conf usetls="no" tlsrequired="no" authrequired="yes" authtype="GSSAPI" clientprinc="host/server.example.com@EXAMPLE.COM"/> secret="<ldap password>"/>ホストプリンシパルの詳細は、IdM での正規化された DNS ホスト名の使用 を参照してください。正確なホストプリンシパル情報を取得するために、
klist -kを実行することもできます。
-
20.5. autofs サービスを使用した NFS サーバーユーザーのホームディレクトリーの自動マウント リンクのコピーリンクがクリップボードにコピーされました!
ユーザーのホームディレクトリーを自動的にマウントするように autofs サービスを設定します。
前提条件
- autofs パッケージがインストールされている。
- autofs サービスが有効で、実行している。
手順
ユーザーのホームディレクトリーをマウントするサーバーの
/etc/auto.masterファイルを編集して、マウントポイントとローカル自動マウントマップを定義し、以下を追加します。/home /etc/auto.homeユーザーのホームディレクトリーをマウントする必要があるサーバー上にローカル自動マウントマップファイル
/etc/auto.homeを作成し、以下を追加します。* -fstype=nfs,rw,sync host.example.com:/home/&fstypeパラメーターはデフォルトでnfsであるため、このパラメーターは飛ばして次に進むことができます。詳細は、システム上のautofs(5)man ページを参照してください。autofsサービスをリロードします。# systemctl reload autofs
20.6. autofs サイトの設定ファイルのオーバーライドまたは拡張 リンクのコピーリンクがクリップボードにコピーされました!
クライアントシステムの特定のマウントポイントで、サイトのデフォルトをオーバーライドすることが役に立つ場合があります。
初期条件:
たとえば、次の条件を検討します。
-
nsswitchは、マップをチェックするサービスを autofs に指示します。 -
拡張または追加するマップの名前は
auto.homeです。 auto.homeマップはldapに保存され、/etc/nsswitch.confには次のディレクティブがあります。automount: files ldap/etc/auto.masterマップファイルには次の内容が含まれています。/home /etc/auto.homeマップ /etc/auto.home` ファイルには次の内容が含まれています。
* fileserver.example.com:/export/home/&
plus map inclusion の使用:
nsswitch を介して一元管理された auto.home マップを読み取るには、ローカルの /etc/auto.home ファイルからワイルドカードマップエントリー * fileserver.example.com:/export/home/& を削除し、+auto.home に置き換えます。
plus map inclusion はローカルマップ内でのみ使用できます。autofs が plus map inclusion を通じて files ソースに遭遇すると、インクルードされたマップ名が現在読み取り中のマップと同一である場合はそれをスキップします。この場合、両方とも auto.home であるため、autofs は nsswitch.conf で定義されている次のソース、つまり ldap に進みます。マップ内にワイルドカードマップエントリーが存在する場合、ブラウズモードが有効になっている場合でも、ディレクトリーリストには影響しません。これは、検索の実行時にワイルドカードが何に一致するかを autofs が認識できないためです。そのため、マウントポイントディレクトリーを事前に作成できません。
エントリーのオーバーライドまたは追加
特定のエントリーをローカルでオーバーライドまたは追加するには、それらを /etc/auto.home の +auto.home 行の前に配置します。たとえば、/etc/auto.home ファイルは次のようになります。
mydir someserver:/export/mydir
+auto.home
/home をリスト表示するときに mydir などのローカルエントリーを表示するには、/etc/autofs.conf で browse_mode = yes を設定してブラウズモードを有効にします。ワイルドカードエントリー (* など) は、アクセスされない限りディレクトリーリストに表示されません。
20.7. systemd.automount と /etc/fstab を使用してファイルシステムを必要に応じてマウントする リンクのコピーリンクがクリップボードにコピーされました!
マウントポイントが /etc/fstab で定義されている場合、automount systemd ユニットを使用して、必要に応じてファイルシステムをマウントします。マウントごとに自動マウントユニットを追加して有効にする必要があります。
手順
ファイルシステムの永続的なマウント の説明に従って、目的の fstab エントリーを追加します。以下に例を示します。
/dev/disk/by-id/da875760-edb9-4b82-99dc-5f4b1ff2e5f4 /mount/point xfs defaults 0 0-
前の手順で作成したエントリーの options フィールドに
x-systemd.automountを追加します。 システムが新しい設定を登録するように、新しく作成されたユニットをロードします。
# systemctl daemon-reload自動マウントユニットを起動します。
# systemctl start mount-point.automount
検証
mount-point.automountが実行されていることを確認します。# systemctl status mount-point.automount自動マウントされたディレクトリーに目的のコンテンツが含まれていることを確認します。
# ls /mount/point
20.8. systemd.automount とマウントユニットを使用してファイルシステムを必要に応じてマウントする リンクのコピーリンクがクリップボードにコピーされました!
マウントポイントがマウントユニットによって定義されている場合、systemd の automount ユニットを使用して、必要に応じてファイルシステムをマウントします。マウントごとに自動マウントユニットを追加して有効にする必要があります。
手順
マウントユニットを作成します。以下に例を示します。
mount-point.mount [Mount] What=/dev/disk/by-uuid/f5755511-a714-44c1-a123-cfde0e4ac688 Where=/mount/point Type=xfs-
マウントユニットと同じ名前で、拡張子が
.automountのユニットファイルを作成します。 ファイルを開き、
[Automount]セクションを作成します。Where=オプションをマウントパスに設定します。[Automount] Where=/mount/point [Install] WantedBy=multi-user.targetシステムが新しい設定を登録するように、新しく作成されたユニットをロードします。
# systemctl daemon-reload代わりに、自動マウントユニットを有効にして起動します。
# systemctl enable --now mount-point.automount
検証
mount-point.automountが実行されていることを確認します。# systemctl status mount-point.automount自動マウントされたディレクトリーに目的のコンテンツが含まれていることを確認します。
# ls /mount/point
第21章 IdM からの SSSD コンポーネントを使用した autofs マップのキャッシュ リンクのコピーリンクがクリップボードにコピーされました!
システムセキュリティーサービスデーモン (System Security Services Daemon: SSSD) は、リモートサービスディレクトリーと認証メカニズムにアクセスするシステムサービスです。データキャッシュは、ネットワーク接続が遅い場合に役立ちます。SSSD サービスを設定して、autofs マップをキャッシュすることができます。
21.1. autofs マップをキャッシュする SSSD の設定 リンクのコピーリンクがクリップボードにコピーされました!
System Security Services Daemon (SSSD) サービスは、Identity Management (IdM) サーバーに保存されている autofs マップをキャッシュできます。これにより、IdM サーバーを直接使用するために autofs を設定する必要がなくなります。
前提条件
-
sssdパッケージがインストールされている。
手順
SSSD 設定ファイルを開きます。
# vim /etc/sssd/sssd.confSSSD が処理するサービスリストに
autofsサービスを追加します。[sssd] domains = ldap services = nss,pam,autofs[autofs]セクションを新規作成します。autofsサービスのデフォルト設定はほとんどのインフラストラクチャーに対応するため、これを空白のままにすることができます。[nss] [pam] [sudo] [autofs] [ssh] [pac]詳細は、システム上の
sssd.confman ページを参照してください。オプション:
autofsエントリーの検索ベースを設定します。デフォルトでは、これは軽量ディレクトリーアクセスプロトコル (LDAP) の検索ベースです。サブツリーは、ldap_autofs_search_baseパラメーターで指定できます。[domain/EXAMPLE] ldap_search_base = "dc=example,dc=com" ldap_autofs_search_base = "ou=automount,dc=example,dc=com"SSSD サービスを再起動します。
# systemctl restart sssd.serviceSSSD が自動マウント設定のソースとしてリスト表示されるように、
/etc/nsswitch.confファイルを確認します。automount: sss filesautofsサービスを再起動します。# systemctl restart autofs.service/homeのマスターマップエントリーがあると想定し、ユーザーの/homeディレクトリーをリスト表示して設定をテストします。# ls /home/userNameリモートファイルシステムをマウントしない場合は、
/var/log/messagesファイルでエラーを確認します。必要に応じて、loggingパラメーターをdebugに設定して、/etc/sysconfig/autofsファイルのデバッグレベルを増やします。
第22章 root ファイルシステムに対する読み取り専用パーミッションの設定 リンクのコピーリンクがクリップボードにコピーされました!
場合によっては、読み取り専用権限で root ファイルシステム (/) をマウントする必要があります。たとえば、システムの予期せぬ電源切断後にセキュリティーの向上またはデータ整合性の保持を行う場合などです。
22.1. 書き込みパーミッションを保持するファイルおよびディレクトリー リンクのコピーリンクがクリップボードにコピーされました!
システムが正しく機能するためには、一部のファイルやディレクトリーで書き込みパーミッションが必要とされます。ルートファイルシステムが読み取り専用モードでマウントされている場合、これらのファイルは tmpfs 一時ファイルシステムを使用して RAM にマウントされます。
このようなファイルおよびディレクトリーのデフォルトセットは、/etc/rwtab ファイルから読み込まれます。このファイルをシステムに存在させるには、readonly-root パッケージが必要であることに注意してください。
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 /tmpdirsディレクトリーツリーが空の状態で
tmpfsにコピーされます。以下に例を示します。dirs /var/runfilesファイルやディレクトリーツリーはそのまま
tmpfsにコピーされます。以下に例を示します。files /etc/resolv.conf
/etc/rwtab.d/ にカスタムパスを追加する場合も、同じ形式が適用されます。
22.2. ブート時に読み取り専用パーミッションでマウントするように root ファイルシステムの設定 リンクのコピーリンクがクリップボードにコピーされました!
カーネルオプション、fstab、および読み取り専用ルート設定を変更して、ルートファイルシステムを起動時に読み取り専用としてマウントするように設定します。
手順
/etc/sysconfig/readonly-rootファイルで、READONLYオプションをyesに設定して、ファイルシステムを読み取り専用としてマウントします。READONLY=yes/etc/fstabファイルの root エントリー (/) にroオプションを追加します。/dev/mapper/luks-c376919e... / xfs x-systemd.device-timeout=0,ro 1 1rokernel オプションを有効にします。# grubby --update-kernel=ALL --args="ro"rwカーネルオプションが無効になっていることを確認します。# grubby --update-kernel=ALL --remove-args="rw"tmpfsファイルシステムに書き込みパーミッションでマウントするファイルとディレクトリーを追加する必要がある場合は、/etc/rwtab.d/ディレクトリーにテキストファイルを作成し、そこに設定を置きます。たとえば、
/etc/example/fileファイルを書き込みパーミッションでマウントするには、この行を/etc/rwtab.d/exampleファイルに追加します。files /etc/example/file重要tmpfsのファイルおよびディレクトリーの変更内容は、再起動後は持続しません。- システムを再起動して変更を適用します。
トラブルシューティング
誤ってルートファイルシステムを読み取り専用権限でマウントしてしまった場合は、以下のコマンドを使用して読み書き権限で再度マウントすることができます。
# mount -o remount,rw /
第23章 クォータを使用した XFS でのストレージ領域の使用の制限 リンクのコピーリンクがクリップボードにコピーされました!
ディスククォータを実装して、ユーザーまたはグループのストレージ容量を制限し、警告レベルを設定します。XFS クォータは、ユーザー、グループ、ディレクトリー、またはプロジェクトレベルでディスク容量 (ブロック) と i ノードを管理します。プロジェクトごとのクォータにより、ディレクトリー階層のディスク使用量を制御できます。
23.1. ディスククォータ リンクのコピーリンクがクリップボードにコピーされました!
ディスククォータとは、ユーザーやグループがファイルシステム上で使用できるディスク容量を制限する機能です。これらは、単一のユーザーが利用可能なすべてのストレージ領域を使用することを防ぎ、複数のユーザー間で公平なリソース割り当てを実現します。
ほとんどのコンピューティング環境では、ディスク領域は無限ではありません。クォータサブシステムは、ディスク領域の使用量を制御するメカニズムを提供します。
ディスククォータは、ローカルファイルシステムの個々のユーザーおよびユーザーグループに設定できます。これにより、メールなどのユーザー固有のファイル用のスペースを、プロジェクト用のスペースとは別に管理することが可能になります。クォータサブシステムは、ユーザーが割り当てられた制限を超えた場合に警告を発しますが、現在の作業のために余分なスペースを確保します (ハードリミット/ソフトリミット)。
クォータが実装されている場合は、クォータを超過しているかどうかを確認して、クォータが正しいことを確認する必要があります。ユーザーが繰り返しクォータの上限を超えたり、ソフトリミットに継続的に達したりする場合、システム管理者はディスク容量の使用量を削減する手助けをすることができます。または、管理者はユーザーのディスククォータを増やすこともできます。
クォータは、以下を制御するように設定できます。
- 消費されるディスクブロックの数。
- UNIX ファイルシステムのファイルに関する情報を含むデータ構造である inode の数。inode はファイル関連の情報を保存するため、作成可能なファイルの数を制御できます。
23.2. xfs_quota ツール リンクのコピーリンクがクリップボードにコピーされました!
xfs_quota ツールを使用して、XFS ファイルシステム上のクォータを管理できます。さらに、有効なディスク使用量のアカウンティングシステムとして、制限の強制適用をオフにして XFS ファイルシステムを使用できます。
XFS クォータシステムは、他のファイルシステムとはさまざまな点で異なります。最も重要な点として、XFS はクォータ情報をファイルシステムのメタデータとみなし、ジャーナリングを使用して一貫性のより高いレベルの保証を提供します。
詳細は、システム上の xfs_quota(8) man ページを参照してください。
23.3. XFS でのファイルシステムクォータ管理 リンクのコピーリンクがクリップボードにコピーされました!
XFS クォータサブシステムは、ディスク領域 (ブロック) およびファイル (inode) の使用量の制限を管理します。XFS クォータは、ユーザー、グループ、ディレクトリーレベル、またはプロジェクトレベルでこれらの項目の使用を制御または報告します。グループおよびプロジェクトのクォータは、古いデフォルト以外の XFS ディスクフォーマットでのみ相互に排他的です。
ディレクトリーまたはプロジェクトごとに管理する場合、XFS は特定のプロジェクトに関連付けられたディレクトリー階層のディスク使用量を管理します。
23.4. XFS のディスククォータの有効化 リンクのコピーリンクがクリップボードにコピーされました!
XFS ファイルシステムのユーザー、グループ、およびプロジェクトのディスククォータを有効にします。クォータを有効にすると、xfs_quota ツールを使用して制限を設定し、ディスク使用量を報告できます。
手順
ユーザーのクォータを有効にします。
# mount -o uquota /dev/xvdb1 /xfsuquotaをuqnoenforceに置き換えて、制限を強制適用せずに使用状況の報告を可能にします。グループのクォータを有効にします。
# mount -o gquota /dev/xvdb1 /xfsgquotaをgqnoenforceに置き換えて、制限を強制適用せずに使用状況の報告を可能にします。プロジェクトのクォータを有効にします。
# mount -o pquota /dev/xvdb1 /xfspquotaを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詳細は、システム上の
xfs(5)およびxfs_quota(8)man ページを参照してください。
23.5. XFS 使用量の報告 リンクのコピーリンクがクリップボードにコピーされました!
xfs_quota ツールを使用して制限を設定し、ディスク使用量を報告します。xfs_quota は、デフォルトでは対話形式で基本モードで実行されます。基本モードのサブコマンドは使用状況を報告し、すべてのユーザーが利用できます。
前提条件
- XFS ファイルシステムに対してクォータが有効になっている。XFS のディスククォータの有効化 を参照してください。
手順
xfs_quotaシェルを起動します。# xfs_quota指定したユーザーの使用状況および制限を表示します。
xfs_quota> quota usernameブロックおよび inode の空きおよび使用済みの数を表示します。
xfs_quota> dfhelp コマンドを実行して、
xfs_quotaで利用可能な基本的なコマンドを表示します。xfs_quota> helpqを指定してxfs_quotaを終了します。xfs_quota> q詳細は、システム上の
xfs_quota(8)man ページを参照してください。
23.6. XFS クォータ制限の変更 リンクのコピーリンクがクリップボードにコピーされました!
xfs_quota ツールを -x オプション付きで起動してエキスパートモードを有効にし、管理者コマンドを実行してクォータシステムを変更します。このモードのサブコマンドは、制限を実際に設定することができるため、昇格した特権を持つユーザーのみが利用できます。
前提条件
- XFS ファイルシステムに対してクォータが有効になっている。XFS のディスククォータの有効化 を参照してください。
手順
エキスパートモードを有効にするには、
-xオプションを指定してxfs_quotaシェルを起動します。# xfs_quota -x /path特定のファイルシステムのクォータ情報を表示します。
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たとえば、ホームディレクトリーが
/home/johnのユーザーjohnに対して、inode 数のソフト制限およびハード制限をそれぞれ 500 と 700 に設定するには、次のコマンドを使用します。# xfs_quota -x -c 'limit isoft=500 ihard=700 john' /home/この場合は、マウントされた xfs ファイルシステムである
mount_pointを渡します。xfs_quota -xで利用可能なエキスパートコマンドを表示します。xfs_quota> help
検証
クォータ制限が変更されたことを確認します。
xfs_quota> report -i -uUser quota on /home (/dev/loop0) Inodes User ID Used Soft Hard Warn/ Grace ---------- -------------------------------------------------- root 3 0 0 00 [------] testuser 2 500 700 00 [------]詳細は、システム上の xfs_quota(8) man ページを参照してください。
23.7. XFS のプロジェクト制限の設定 リンクのコピーリンクがクリップボードにコピーされました!
プロジェクトが制御するディレクトリーの制限を設定します。
手順
プロジェクトが制御するディレクトリーを
/etc/projectsに追加します。たとえば、以下は一意の ID が 11 の/var/logパスを/etc/projectsに追加します。プロジェクト ID には、プロジェクトにマッピングされる任意の数値を指定できます。# echo 11:/var/log >> /etc/projects/etc/projidにプロジェクト名を追加して、プロジェクト ID をプロジェクト名にマップします。たとえば、以下は、前のステップで定義されたようにlogfilesというプロジェクトをプロジェクト ID 11 に関連付けます。# echo logfiles:11 >> /etc/projidプロジェクトのディレクトリーを初期化します。たとえば、以下はプロジェクトディレクトリー
/varを初期化します。# xfs_quota -x -c 'project -s logfiles' /var初期化したディレクトリーでプロジェクトのクォータを設定します。
# xfs_quota -x -c 'limit -p bhard=1g logfiles' /var詳細は、システム上の
xfs_quota(8)、projid(5)、およびprojects(5)man ページを参照してください。
第24章 クォータを使用した ext4 でのストレージ領域の使用の制限 リンクのコピーリンクがクリップボードにコピーされました!
ディスククォータを割り当てる前に、システムでディスククォータを有効にする必要があります。ユーザーごと、グループごと、またはプロジェクトごとにディスククォータを割り当てることができます。ただし、ソフト制限が設定されている場合は、猶予期間として知られる設定可能な期間として、これらのクォータを超過できます。
24.1. クォータツールのインストール リンクのコピーリンクがクリップボードにコピーされました!
ディスククォータを実装するには、RPM パッケージ quota をインストールする必要があります。
手順
quotaパッケージをインストールします。# dnf install quota
24.2. ファイルシステム作成時のクォータ機能の有効化 リンクのコピーリンクがクリップボードにコピーされました!
ファイルシステムの作成時にクォータを有効にします。
手順
ファイルシステムの作成時にクォータを有効にします。
# mkfs.ext4 -O quota /dev/sda注記デフォルトでは、ユーザーとグループのクォータのみが有効になり、初期化されます。
ファイルシステムの作成時にデフォルトを変更します。
# mkfs.ext4 -O quota -E quotatype=usrquota:grpquota:prjquota /dev/sdaファイルシステムをマウントします。
# mount /dev/sda
24.3. 既存のファイルシステムでのクォータ機能の有効化 リンクのコピーリンクがクリップボードにコピーされました!
tune2fs コマンドを使用して、既存のファイルシステムでクォータ機能を有効にします。
手順
ファイルシステムをアンマウントします。
# umount /dev/sda既存のファイルシステムでクォータを有効にします。
# tune2fs -O quota /dev/sda注記デフォルトでは、ユーザーとグループのクォータのみが初期化されます。
デフォルトを変更します。
# tune2fs -Q usrquota,grpquota,prjquota /dev/sdaファイルシステムをマウントします。
# mount /dev/sda
24.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
24.5. ユーザーごとにクォータの割り当て リンクのコピーリンクがクリップボードにコピーされました!
ディスククォータは、edquota コマンドでユーザーに割り当てられます。
EDITOR 環境変数により定義されたテキストエディターは、edquota により使用されます。エディターを変更するには、~/.bash_profile ファイル内の EDITOR 環境変数に、必要なエディターのフルパスを設定してください。
前提条件
- ユーザーは、ユーザークォータを設定する前に存在する必要があります。
手順
ユーザーにクォータを割り当てます。
# edquota usernameusername を、クォータを割り当てるユーザーに置き換えます。
たとえば、
/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 testuserDisk quotas for user testuser: Filesystem blocks quota limit grace files quota limit grace /dev/sda 1000* 1000 1000 0 0 0
24.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
24.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)、projid(5)、およびprojects(5)man ページを参照してください。
24.8. ソフト制限の猶予期間の設定 リンクのコピーリンクがクリップボードにコピーされました!
特定のクォータにソフトリミットが設定されている場合、猶予期間を編集できます。猶予期間とは、ソフトリミットを超過しても許容される時間のことです。
ユーザー、グループ、またはプロジェクトの猶予期間を設定できます。
手順
猶予期間を編集します。
# edquota -t重要その他の
ed クォータコマンドは、特定のユーザー、グループ、またはプロジェクトの割り当て量に対して動作します。ただし、-tオプションは、クォータが有効になっているすべてのファイルシステムで動作します。
24.9. ファイルシステムのクォータをオフにする リンクのコピーリンクがクリップボードにコピーされました!
quotaoff を使用して、指定されたファイルシステムでディスククォータの強制適用をオフにします。このコマンドを実行した後も、クォータアカウンティングは有効なままです。
手順
すべてのユーザーとグループのクォータをオフにするには、次のコマンドを実行します。
# quotaoff -vaugP-
-uオプション、-gオプション、または-Pオプションがいずれも指定されていないと、ユーザーのクォータのみが無効になります。 -
-gオプションのみを指定すると、グループクォータのみが無効になります。 -
-Pオプションのみを指定すると、プロジェクトのクォータのみが無効になります。 -vスイッチにより、コマンドの実行時に詳細なステータス情報が表示されます。詳細は、システム上の
quotaoff(8)man ページを参照してください。
-
24.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列は空白です。ソフト制限が超過した場合、その列には猶予期間に残り時間量に相当する時間指定が含まれます。猶予期間が過ぎると、その代わりにnoneと表示されます。詳細は、
repquota(8)man ページを参照してください。
第25章 未使用ブロックの破棄 リンクのコピーリンクがクリップボードにコピーされました!
破棄操作は、どのブロックが使用されなくなったかをストレージデバイスに通知することで、ストレージのパフォーマンスと寿命を向上させます。これは、SSD がウェアレベリングを最適化し、シンプロビジョニングされたストレージが領域を再利用できるようにします。
前提条件
ファイルシステムの基礎となるブロックデバイスは、物理的な破棄操作に対応している必要があります。
/sys/block/<device>/queue/discard_max_bytesファイルの値がゼロではない場合は、物理的な破棄操作はサポートされます。
25.1. ブロック破棄操作のタイプ リンクのコピーリンクがクリップボードにコピーされました!
ブロック破棄操作は、バッチ、オンライン、または定期的な方法を使用して実行できます。それぞれに特定のユースケースとパフォーマンス推奨事項があります。
次のリストは、さまざまな破棄操作について説明しています。
- バッチ破棄
-
fstrimコマンドに、このタイプの破棄が含まれています。ファイルシステム内にある未使用のブロックで、管理者が指定した基準に一致するものをすべて破棄します。Red Hat Enterprise Linux 10 は、XFS および ext4 でフォーマットされおり、物理的な破棄操作に対応するデバイスでのバッチ破棄をサポートします。 - オンライン破棄
このタイプの破棄操作は、discard オプションを指定してマウント時に設定します。この操作は、ユーザーの介入なしにリアルタイムで実行されます。ただし、未使用から空き状態に移行しているブロックのみを破棄します。Red Hat Enterprise Linux 10 では XFS および ext4 フォーマットのデバイスでオンライン破棄をサポートしています。
パフォーマンスを維持するためにオンライン破棄が必要な場合、またはシステムのワークロードに対してバッチ破棄が実行不可能な場合を除き、バッチ破棄を使用します。
- 定期的な破棄
-
systemdサービスが定期的に実行するバッチ操作です。
すべてのタイプは、XFS ファイルシステムおよび ext4 ファイルシステムでサポートされます。
推奨事項
バッチまたは定期的な破棄を使用します。
以下の場合にのみ、オンライン破棄を使用してください。
- システムのワークロードでバッチ破棄が実行できない場合
- パフォーマンス維持にオンライン破棄操作が必要な場合
25.2. バッチブロック破棄の実行 リンクのコピーリンクがクリップボードにコピーされました!
バッチブロック破棄操作を実行して、マウントされたファイルシステムの未使用ブロックを破棄することができます。
前提条件
- ファイルシステムがマウントされている。
- ファイルシステムの基礎となるブロックデバイスが物理的な破棄操作に対応している。
手順
fstrimユーティリティーを使用します。選択したファイルシステムでのみ破棄を実行するには、次のコマンドを使用します。
# fstrim mount-pointマウントされているすべてのファイルシステムで破棄を実行するには、次のコマンドを使用します。
# fstrim --all
fstrimコマンドを実行する場合:- 破棄操作をサポートしていないデバイス、または
複数のデバイスで構成された論理デバイス (LVM または MD) で、いずれかのデバイスが破棄操作をサポートしていない場合、次のメッセージが表示されます。
# fstrim /mnt/non_discardfstrim: /mnt/non_discard: the discard operation is not supported
25.3. オンラインブロック破棄の有効化 リンクのコピーリンクがクリップボードにコピーされました!
オンラインブロック破棄操作を実行して、サポートしているすべてのファイルシステムで未使用のブロックを自動的に破棄できます。詳細は、システム上の mount(8) および fstab(5) man ページを参照してください。
手順
マウント時のオンライン破棄を有効にします。
ファイルシステムを手動でマウントするには、
-o discardマウントオプションを追加します。# mount -o discard device mount-point-
ファイルシステムを永続的にマウントするには、
/etc/fstabファイルのマウントエントリーにdiscardオプションを追加します。
25.4. 定期的なブロック破棄の有効化 リンクのコピーリンクがクリップボードにコピーされました!
systemd タイマーを有効にして、サポートしているすべてのファイルシステムで未使用ブロックを定期的に破棄できます。
手順
systemdタイマーを有効にして起動します。# systemctl enable --now fstrim.timerCreated symlink /etc/systemd/system/timers.target.wants/fstrim.timer → /usr/lib/systemd/system/fstrim.timer.
検証
タイマーのステータスを確認します。
# systemctl status fstrim.timerfstrim.timer - Discard unused blocks once a week Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled) Active: active (waiting) since Wed 2023-05-17 13:24:41 CEST; 3min 15s ago Trigger: Mon 2023-05-22 01:20:46 CEST; 4 days left Docs: man:fstrim May 17 13:24:41 localhost.localdomain systemd[1]: Started Discard unused blocks once a week.
第26章 I/O およびファイルシステムパフォーマンスに影響を与える要因 リンクのコピーリンクがクリップボードにコピーされました!
ストレージおよびファイルシステムパフォーマンスに適した設定は、ストレージの目的より大きく左右されます。I/O およびファイルシステムのパフォーマンスは、さまざまな要因によって影響を受ける可能性があります。
以下は、I/O およびファイルシステムのパフォーマンスに影響を与える可能性のある要因のリストです。
- データの書き込みまたは読み取りパターン
- 順次または無作為
- バッファーまたはダイレクト IO
- 基礎となるジオメトリーとのデータ調整
- ブロックサイズ
- ファイルシステムのサイズ
- ジャーナルサイズおよび場所
- アクセス時間の記録
- データの信頼性確保
- 事前にフェッチするデータ
- ディスク領域の事前割り当て
- ファイルの断片化
- リソースの競合
26.1. I/O およびファイルシステムの問題を監視および診断するツール リンクのコピーリンクがクリップボードにコピーされました!
パフォーマンスメトリクスを追跡し、デバイスの負荷、レイテンシーを分析し、操作をトレースするツールを使用して、I/O およびファイルシステムの問題を効率的に監視および診断します。これらのツールは、Red Hat Enterprise Linux 10 環境におけるボトルネックを特定し、システムパフォーマンスを最適化するのに役立ちます。
Red Hat Enterprise Linux 10 には、システムのパフォーマンスを監視し、I/O およびファイルシステムに関連するパフォーマンスの問題を診断するための以下のツールが用意されています。
-
vmstatツールは、システム全体のプロセス、メモリー、ページング、ブロック I/O、割り込み、および CPU アクティビティーに関する報告を行います。管理者はこのツールを使用することで、パフォーマンスの問題が I/O サブシステムによるものかを判断しやすくなります。vmstat分析の結果、I/O サブシステムがパフォーマンス低下の原因であることが判明した場合、管理者はiostat を使用して原因となっている I/O デバイスを特定できます。 -
iostatは、システムでの I/O デバイスの負荷を報告します。このツールはsysstatパッケージで提供されます。 -
blktraceは、I/O サブシステムでの時間の使用に関する詳細にわたる情報を提供します。付属ユーティリティーであるblkparse は、blktraceからの生の出力を読み取り、記録された入出力操作の人間が読みやすい要約を生成します。 btt はblktrace の出力を分析し、データが I/O スタックの各領域で費やした時間を表示します。これにより、I/O サブシステムにおけるボトルネックを容易に特定できるようになります。このユーティリティーは、blktraceパッケージの一部として提供されます。blktraceメカニズムで追跡され、bttが分析する重要なイベントには、以下のようなものがあります。-
I/O イベント (
Q) のキュー -
ドライバーイベント (
D) への I/O のディスパッチ -
I/O イベントの完了 (
C)
-
I/O イベント (
-
iowatcherはblktrace出力を使用して、I/O を経時的にグラフ化できます。これは、ディスク I/O の論理ブロックアドレス (LBA)、スループット、1 秒あたりのシーク回数、および 1 秒あたりの I/O 操作に焦点を当てています。これを使用することで、デバイスの演算回数の上限に到達するタイミングを判断しやすくなります。 BPF コンパイラーコレクション (BCC) は、
eBPF(extended Berkeley Packet Filter) プログラムの作成を容易にするライブラリーです。eBPFプログラムは、ディスク I/O、TCP 接続、プロセス作成などのイベントでトリガーされます。BCC ツールは、
/usr/share/bcc/tools/ディレクトリーにインストールされます。以下のbcc-toolsは、パフォーマンスの分析に役立ちます。-
biolatencyは、ブロックデバイス I/O(ディスク I/O) のレイテンシーをヒストグラムにまとめています。これにより、デバイスのキャッシュヒット、キャッシュミス、レイテンシーアウトライナーの 2 つのモードなど、分散を調査できます。 -
biosnoop は、各 I/O イベントを、発行元のプロセス ID と I/O レイテンシーとともに表示する基本的なブロック I/O トレースツールです。このツールを使用して、ディスク I/O パフォーマンスの問題を調査できます。 -
biotopは、カーネルのブロック I/O 操作に使用します。 -
filelifeツールは、stat()システムコールを追跡します。 -
fileslowerは、読み取りと書き込みが遅い同期ファイルを追跡します。 -
filetopは、プロセスによるファイルの読み取りと書き込みを表示します。 -
ext4slower、nfsslowerおよびxfsslowerは、特定のしきい値よりも操作速度の遅いファイルを表示するツールです (デフォルト値10ms)。
-
-
bpftaceは、パフォーマンスの問題の分析に使用されるeBPFのトレース言語です。また、システムの監査用に BCC のような追跡ユーティリティーが含まれており、I/O のパフォーマンスの問題を調査するのに役立ちます。 以下の
SystemTapスクリプトは、ストレージまたはファイルシステムのパフォーマンスの問題の診断に役立ちます。-
disktop.stp: 5 秒ごとにディスクの読み取りまたは書き込みのステータスを確認し、その期間の上位 10 エントリーを出力します。 -
iotime.stp: 読み取り、書き込み操作に使用した時間、読み取りおよび書き込みバイト数を出力します。 -
traceio.stp: 確認された累積 I/O トラフィックに基づいて上位 10 の実行可能ファイルを秒単位で出力します。 -
traceio2.stp: 指定したデバイスに読み取りおよび書き込みが行われると、実行可能ファイル名とプロセス識別子を出力します。 -
Inodewatch.stp: 指定されたデバイス上の指定された inode に対して読み取りまたは書き込みが発生するたびに、実行可能ファイル名とプロセス識別子を出力します。 -
inodewatch2.stp: 指定された inode の属性が変更されるたびに、実行可能ファイル名、プロセス識別子、および属性を出力します。
-
詳細は以下を参照してください。
-
システム上の
vmstat(8)、iostat(1)、blktrace(8)、blkparse(1)、btt(1)、bpftrace、およびiowatcher(1)man ページ
26.2. ファイルシステムのフォーマットに利用可能なチューニングオプション リンクのコピーリンクがクリップボードにコピーされました!
一部のファイルシステム設定は一旦決定すると、デバイスのフォーマット後に変更できません。これらには、サイズ、ブロックサイズ、ジオメトリー、外部ジャーナルが含まれます。
ストレージデバイスをフォーマットする前に使用できるオプションの詳細は次のとおりです。
Size- ワークロードに適したサイズのファイルシステムを作成します。ファイルシステムが小さいと、ファイルシステムのチェックにかかる時間とメモリーが少なくて済みます。ただし、ファイルシステムが小さすぎると、断片化が多くなり、パフォーマンスが低下します。
Block sizeブロックは、ファイルシステムの作業単位です。ブロックサイズは、1 つのブロックに格納できるデータ量を決定します。したがって、これは一度に書き込まれたり読み取られたりする最小データ量を設定します。
デフォルトのブロックサイズは、ほとんどのユースケースに適しています。ただし、ブロックサイズが一般的な読み書き量と一致すると、ファイルシステムのパフォーマンスが向上します。最適なパフォーマンスは、ブロックサイズが通常一度にアクセスするデータ量と等しいか、わずかに上回る場合に得られます。
ファイルが小さい場合は、引き続きブロック全体を使用します。ファイルは複数のブロックに分散できますが、ランタイム時のオーバーヘッドが増える可能性があります。
さらに、一部のファイルシステムはブロック数に制限があり、ファイルシステムの最大サイズが制限されます。
mkfsコマンドでデバイスをフォーマットする時に、ファイルシステムのオプションの一部としてブロックサイズを指定します。ブロックサイズを指定するパラメーターは、ファイルシステムによって異なります。Geometryファイルシステムジオメトリーは、ファイルシステム全体でのデータの分散に関係があります。システムが RAID などのストライプストレージを使用している場合は、フォーマット時にデータとメタデータを基盤となるストレージのジオメトリに合わせてください。これによりパフォーマンスが向上します。
多くのデバイスは推奨のジオメトリーをエクスポートし、デバイスが特定のファイルシステムでフォーマットされるとそのジオメトリーが自動的に設定されます。お使いのデバイスがこれらの推奨事項をエクスポートしない場合、またはそれらを変更したい場合は、
mkfsを使用してフォーマットするときにジオメトリを手動で指定してください。ファイルシステムのジオメトリーを指定するパラメーターは、ファイルシステムによって異なります。
External journals- ジャーナリングファイルシステムは、書き込み操作を実行する前に、ジャーナルファイルに変更内容を記録します。これにより、システムクラッシュや停電時にデバイスが破損する可能性が低減されます。また、回復を早める効果もある。
外部ジャーナルオプションは使用しない方が望ましい。
メタデータ集約型のワークロードでは、ジャーナルへの更新頻度が非常に多くなります。ジャーナルが大きいと、より多くのメモリーを使用しますが、書き込み操作の頻度は低減します。さらに、メタデータを多用するワークロードを持つデバイスのジャーナルを専用ストレージに配置することで、シーク時間を改善できます。プライマリーストレージと同等、またはそれ以上の速度でストレージを使用する。
外部ジャーナルが信頼できることを確認します。外部ジャーナルデバイスが損失すると、ファイルシステムが破損します。外部ジャーナルは、フォーマット時に作成し、マウント時にジャーナルデバイスを指定する必要があります。
26.3. ファイルシステムのマウントに利用可能なチューニングオプション リンクのコピーリンクがクリップボードにコピーされました!
atime、noatime、read-ahead 設定など、ファイルシステムのマウントに関する主要なチューニングオプションを調べて、さまざまなワークロードのパフォーマンスと機能のバランスをとるマウントオプションを選択できます。
以下は、ほとんどのファイルシステムで利用可能なオプションで、デバイスのマウント時に指定できます。
Access Timeファイルが読み込まれるたびに、ファイルのメタデータはアクセス時点で更新されます (
atime)。この際、追加の書き込み I/O が行われます。ほとんどのファイルシステムのatimeのデフォルト設定はrelatimeです。ただし、このメタデータの更新に時間がかかる場合で正確なアクセス時間データが必要ない場合には、
noatimeマウントオプションを指定してファイルシステムをマウントしてください。この設定で、ファイルの読み取り時にメタデータへの更新が無効になります。また、nodiratime動作も有効にし、ディレクトリーの読み取り時にメタデータへの更新を無効にします。
noatime mount オプションを使用して atime の更新を無効にすると、バックアッププログラムなどに依存するアプリケーションが破損する可能性があります。
read-aheadread-ahead動作では、すぐに必要となる可能性の高いデータを事前にフェッチし、ページキャッシュ (ディスク上にある場合よりも早くデータを取得可能) に読み込むことでファイルのアクセス時間を短縮します。read-ahead 値が大きいほど、さらに事前にシステムのデータがフェッチされます。Red Hat Enterprise Linux は、ファイルシステムについて検出した内容に基づいて、適切な read-ahead 値の設定を試みます。ただし、正確な検出が常に可能であるとは限りません。たとえば、ストレージアレイが単一の LUN としてシステムに表示した場合に、システムはその単一の LUN を検出するので、アレイに適した read-ahead 値は設定されません。
連続 I/O を大量にストリーミングするワークロードは、read-ahead 値を高くすると効果がある場合が多いです。Red Hat Enterprise Linux で提供されるストレージ関連の tuned プロファイルは、LVM ストライプ化と同様に read-ahead 値を増やしますが、このような調整は、ワークロードすべてで常に十分であるというわけではありません。
26.4. 使用されていないブロックの破棄 リンクのコピーリンクがクリップボードにコピーされました!
ファイルシステムで使用されていないブロックを定期的に破棄することは、ソリッドステートディスクとシンプロビジョニングストレージの両方にとって良い習慣です。
26.5. ソリッドステートディスクの調整に関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
ソリッドステートディスク (SSD) は、回転磁気プラッターではなく、NAND フラッシュチップを使用して永続データを保存します。SSD は、論理ブロックアドレス範囲全体にわたって、データへのアクセス時間を一定に保ちます。回転式のものとは異なり、測定可能なシークコストは発生しない。
それらは 1 ギガバイトあたりのストレージ容量が高価で、ストレージ密度も低い。しかし、ハードディスクドライブ (HDD) よりもレイテンシーが低く、スループットも高い。
SSD の使用済みのブロックが、ディスク容量を占有してくると、通常パフォーマンスは低下します。パフォーマンスの低下レベルはベンダーによって異なりますが、このような状況では、すべてのデバイスでパフォーマンスが低下します。破棄動作を有効にすると、この低下を軽減できます。
デフォルトの I/O スケジューラーと仮想メモリーのオプションは SSD 使用に適しています。設定時には、SSD のパフォーマンスに影響を与える可能性がある以下の要素を考慮してください。
I/O SchedulerI/O スケジューラーはどれでも、ほとんどの SSD で適切に動作することが想定されます。ただし、他のストレージタイプと同様に、ベンチマークテストを実施して、特定のワークロードに最適な設定を決定する必要があります。SSD を使用する場合は、特定のワークロードのベンチマークを行う場合にのみ、I/O スケジューラーを変更してください。
I/O スケジューラー間の切り替え方法は、
/usr/share/doc/kernel-version/Documentation/block/switching-sched.txtファイルを参照してください。シングルキューのホストバスアダプター (HBA) の場合、デフォルトの I/O スケジューラーは
deadlineです。複数のキュー HBA の場合は、デフォルトの I/O スケジューラーはnoneです。Virtual Memory-
I/O スケジューラーと同様に、仮想メモリー (VM) サブシステムには特別なチューニングは必要ありません。SSD の I/O は高速であるため、
vm_dirty_background_ratioとvm_dirty_ratio の設定値を下げてみてください。書き込み活動の増加は、通常、ディスク上の他の操作の遅延に悪影響を与えることはありません。しかし、この調整を行うと全体的な I/O が増加する可能性があるため、ワークロード固有のテストを行わない限り、一般的には推奨されません。 Swap- SSD はスワップデバイスとしても使用でき、ページアウトおよびページインのパフォーマンスが向上する可能性が高くなります。
26.6. 汎用ブロックデバイスのチューニングパラメーター リンクのコピーリンクがクリップボードにコピーされました!
ここにリストされている一般的なチューニングパラメーターは、/sys/block/sdX/queue/ ディレクトリーにあります。
以下のチューニングパラメーターは、I/O スケジューラーチューニングとは別のパラメーターで、全 I/O スケジューラーに適用されます。
add_random-
一部の I/O イベントは、
/dev/randomのエントロピープールに貢献します。これらの貢献のオーバーヘッドが測定できるレベルになった場合には、このパラメーターを0に設定してください。 iostatsデフォルトでは、
iostatsは有効で、デフォルト値は1です。iostats を0に設定すると、デバイスの I/O 統計情報の収集が無効になります。これにより、I/O パスにおけるわずかなオーバーヘッドが削減されます。iostats を0に設定すると、特定の不揮発性メモリーエクスプレス (NVMe) ストレージデバイスなどの高性能デバイスのパフォーマンスが向上する可能性があります。ベンダーが特定のストレージモデルに対して別途指定しない限り、iostats を有効にしておくことが望ましいです。iostatsを無効にすると、デバイスの I/O 統計が/proc/diskstatsファイルからなくなります。I/O 情報は、/sys/diskstatsファイルの内容をソースとしており、sarやiostatsなどの I/O ツールの監視に使用します。したがって、デバイスのiostatsパラメーターを無効にすると、I/O 監視ツールの出力には表示されなくなります。max_sectors_kbI/O 要求の最大サイズを KB 単位で指定します。デフォルト値は
512KB です。このパラメーターの最小値は、ストレージデバイスの論理ブロックサイズで決まります。このパラメーターの最大値は、max_hw_sectors_kbの値で決まります。max_sectors_kb は、常に最適な I/O サイズと内部消去ブロックサイズの倍数でなければなりません。0 が指定されているか、ストレージデバイスによる指定がない場合には、どちらかのパラメーターのlogical_block_sizeの値を使用します。nomerges-
要求をマージは、ほとんどのワークロードで有用です。ただし、デバッグの目的では、マージを無効にすると便利です。デフォルトでは、
nomergesパラメーターは0に設定されており、マージが有効です。単純なワンヒットマージを無効にするには、nomerges を1に設定します。すべてのタイプのマージを無効にするには、nomerges を2に設定します。 nr_requests-
キューに配置可能な最大 I/O 数です。現在の I/O スケジューラーが
noneの場合は、この数値を減らすことができますが、それ以外の場合は数字の増減が可能です。 optimal_io_size- このパラメーターで最適な I/O サイズを報告するストレージデバイスもあります。この値が報告された場合、アプリケーションは可能な限り、最適な I/O サイズに合わせて、かつその倍数となるように I/O を発行します。
read_ahead_kb連続読み込み操作中にオペレーティングシステムが読み取ることができる最大キロバイト数を定義します。その結果、次のシーケンシャル読み取りに必要な情報は、すでにカーネルページキャッシュ内に存在している。これにより、読み取り I/O パフォーマンスが向上します。
read_ahead_kbの値を大きくすると、デバイスマッパーは効果を得られます。マッピングするデバイスごとに128KBという容量は、良い出発点となるでしょう。大きなファイルを順次読み込む場合、read_ahead_kb の値をリクエストキューのディスクのmax_sectors_kbまで増やすとパフォーマンスが向上する可能性があります。rotational-
一部のソリッドステートディスクは、ソリッドステートのステータスを正しく公開せず、従来の回転ディスクとしてマウントされます。スケジューラーで不要なシーク時間短縮ロジックを無効にするには、
rotationalの値を0に手動で設定します。 rq_affinity-
rq_affinityのデフォルト値は1です。これは、発行した CPU コアと同じ CPU グループにある CPU コア 1 つで I/O 操作を完了します。I/O 要求を発行したプロセッサーでのみ I/O 操作を完了するには、rq_affinityを2に設定します。上記の 2 つの機能を無効にするには、0に設定します。 scheduler-
ストレージデバイスのスケジューラーまたはスケジューラーの優先順位を設定するには、
/sys/block/devname/queue/schedulerを編集します。devname を、設定したいデバイス名に置き換えてください。
第27章 Stratis ファイルシステムの設定 リンクのコピーリンクがクリップボードにコピーされました!
Stratis は、Red Hat Enterprise Linux 用のローカルストレージ管理ソリューションです。これは、シンプルさと使いやすさを重視し、高度なストレージ機能にアクセスできます。
Stratis は、物理ストレージデバイスのプールを管理するためにサービスとして実行され、複雑なストレージ設定のセットアップと管理を支援しながら、ローカルストレージ管理を使いやすく簡素化します。
Stratis は、以下のために使用できます。
- ストレージの初期設定
- その後の変更
- 高度なストレージ機能の使用
Stratis の中心的な概念はストレージプールです。このプールは 1 つ以上のローカルディスクまたはパーティションから作成され、ファイルシステムはプールから作成されます。プールでは次のような機能が有効になります。
- ファイルシステムのスナップショット
- シンプロビジョニング
- キャッシュ
- 暗号化
27.1. Stratis ファイルシステムのコンポーネント リンクのコピーリンクがクリップボードにコピーされました!
Stratis は、ブロックデバイス、ストレージプール、ファイルシステムという、連携して高度なストレージ管理を提供する 3 つの主要コンポーネントで構成されています。これらのコンポーネントは、シンプロビジョニング、スナップショット、および自動スペース管理機能を提供します。
外部的には、Stratis はコマンドラインと API を通じて次のファイルシステムコンポーネントを提供します。
blockdev- ディスクやディスクパーティションなどのブロックデバイス。
pool1 つ以上のブロックデバイスで構成されます。
プールの合計サイズは固定で、ブロックデバイスのサイズと同じです。
このプールには
、dm-cacheターゲットを使用した不揮発性データキャッシュなど、ほとんどの Stratis レイヤーが含まれています。Stratis は、各プールの
/dev/stratis/my-pool/ディレクトリーを作成します。このディレクトリーには、プール内の Stratis ファイルシステムを表すデバイスへのリンクが含まれています。filesystem各プールには 0 個以上のファイルシステムを含めることができます。ファイルシステムを含むプールには、任意の数のファイルを保存できます。
ファイルシステムはシンプロビジョニングされており、合計サイズは固定されていません。ファイルシステムの実際のサイズは、そこに格納されているデータとともに大きくなります。データサイズが仮想ファイルシステムのサイズに近づくと、Stratis は自動的にシンボリュームとファイルシステムを拡張します。
ファイルシステムは XFS ファイルシステムでフォーマットされます。Stratis はストレージに XFS ファイルシステムを使用し、Stratis ボリュームをプロビジョニングします。
以降のドキュメントでは、コマンドラインインターフェイスとの整合性を保つため、Stratis ボリュームを Stratis ファイルシステムと呼ぶことにします。
Stratis は、自身が作成したファイルシステムに関する情報を追跡します。XFS はこの情報を認識していません。XFS を使用して行われた変更は、Stratis を自動的に更新しません。
Stratis は、/dev/stratis/my-pool/my-fs パスにファイルシステムへのリンクを作成します。
Stratis は、dmsetup リストと /proc/partitions ファイルに表示される多くの Device Mapper デバイスを使用します。同様に、lsblk コマンドの出力は、Stratis の内部の仕組みとレイヤーを反映します。
27.2. Stratis と互換性のあるブロックデバイス リンクのコピーリンクがクリップボードにコピーされました!
Stratis は、物理ドライブ、論理ボリューム、ネットワークストレージなど、さまざまなブロックデバイスをサポートしています。シンプロビジョニングやスナップショットなどの高度な機能を維持しながら、さまざまなストレージタイプから Stratis プールを構築できます。
Stratis で使用可能なストレージデバイス。
対応デバイス
Stratis プールは、次の種類のブロックデバイスで動作するかどうかをテスト済みです。
- Linux Unified Key Setup (LUKS)
- 論理ボリュームマネージャー (LVM) の論理ボリューム
- マルチデバイス (MD) 冗長アレイ (RAID)
- デバイスマッパー (DM) マルチパス
- Internet Small Computer System Interface (iSCSI)
- ハードディスクドライブ (HDD) とソリッドステートドライブ (SSD)
- 不揮発性メモリーエクスプレス (NVMe) デバイス
27.3. Stratis のインストール リンクのコピーリンクがクリップボードにコピーされました!
Stratis ストレージ管理システムをインストールすると、RHEL システムでシンプロビジョニング、ファイルシステムスナップショット、柔軟なプールベースのストレージ管理などの高度なストレージ機能が有効になります。
手順
Stratis サービスとコマンドラインユーティリティーを提供するパッケージをインストールします。
# dnf install stratisd stratis-clistratisdサービスを開始し、ブート時に起動できるようにするには、以下を実行します。# systemctl enable --now stratisd
検証
stratisdサービスが有効になっていて実行されていることを確認します。# systemctl status stratisdstratisd.service - Stratis daemon Loaded: loaded (/usr/lib/systemd/system/stratisd.service; enabled; preset:> Active: active (running) since Tue 2025-03-25 14:04:42 CET; 30min ago Docs: man:stratisd(8) Main PID: 24141 (stratisd) Tasks: 22 (limit: 99365) Memory: 10.4M CPU: 1.436s CGroup: /system.slice/stratisd.service └─24141 /usr/libexec/stratisd --log-level debug
27.4. 暗号化されていない Stratis プールの作成 リンクのコピーリンクがクリップボードにコピーされました!
1 つ以上のブロックデバイスから暗号化されていない Stratis プールを作成できます。
前提条件
-
Stratis がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - Stratis プールを作成するブロックデバイスは、使用もマウントもされておらず、1 GB 以上の領域がある。
IBM Z アーキテクチャーで、
/dev/dasd*ブロックデバイスがパーティション設定されている。Stratis プールの作成には、パーティションデバイスを使用します。DASD デバイスのパーティション設定の詳細は、64-bit IBM Z での Linux インスタンスの設定 を参照してください。
Stratis プールは作成時にのみ暗号化でき、後から暗号化することはできません。
手順
Stratis プールで使用する各ブロックデバイスに存在するファイルシステム、パーティションテーブル、または RAID 署名をすべて削除します。
# wipefs --all block-deviceblock-deviceの値は、ブロックデバイスへのパスです (例:/dev/sdb)。選択したブロックデバイスに新しい暗号化されていない Stratis プールを作成します。
# stratis pool create my-pool block-deviceblock-deviceの値は、空または消去されたブロックデバイスへのパスです。次のコマンドを使用して、1 行に複数のブロックデバイスを指定することもできます。
# stratis pool create my-pool block-device-1 block-device-2
検証
新しい Stratis プールが作成されていることを確認します。
# stratis pool list
27.5. Web コンソールを使用した暗号化されていない Stratis プールの作成 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、1 つ以上のブロックデバイスから暗号化されていない Stratis プールを作成できます。
前提条件
RHEL 10 Web コンソールがインストールされている。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
-
Stratis がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - Stratis プールを作成するブロックデバイスは、使用もマウントもされておらず、1 GB 以上の領域がある。
暗号化されていない Stratis プールの作成後に、当該 Stratis プールを暗号化することはできません。
手順
- RHEL 10 Web コンソールにログインします。
- をクリックします。
- Storage テーブルで、メニューボタンをクリックし、Create Stratis pool を選択します。
- Name フィールドに、Stratis プールの名前を入力します。
- Stratis プールの作成元となる Block devices を選択します。
- オプション: プールに作成する各ファイルシステムの最大サイズを指定する場合は、Manage filesystem sizes を選択します。
- をクリックします。
検証
- Storage セクションに移動し、Devices テーブルに新しい Stratis プールが表示されていることを確認します。
27.6. カーネルキーリング内のキーを使用して暗号化された Stratis プールを作成する リンクのコピーリンクがクリップボードにコピーされました!
データを保護するために、カーネルキーリングを使用して、1 つ以上のブロックデバイスから暗号化された Stratis プールを作成できます。
この方法で暗号化された Stratis プールを作成すると、カーネルキーリングはプライマリー暗号化メカニズムとして使用されます。その後のシステムを再起動すると、このカーネルキーリングは、暗号化された Stratis プールのロックを解除します。
1 つ以上のブロックデバイスから暗号化された Stratis プールを作成する場合は、次の点に注意してください。
-
各ブロックデバイスは
cryptsetupライブラリーを使用して暗号化され、LUKS2フォーマットを実装しています。 - 各 Stratis プールは、一意の鍵を持つか、他のプールと同じ鍵を共有できます。これらのキーはカーネルキーリングに保存されます。
- Stratis プールを構成するブロックデバイスは、すべて暗号化または暗号化されていないデバイスである必要があります。同じ Stratis プールに、暗号化したブロックデバイスと暗号化されていないブロックデバイスの両方を含めることはできません。
- 暗号化 Stratis プールのデータキャッシュに追加されるブロックデバイスは、自動的に暗号化されます。
前提条件
-
Stratis v2.1.0 以降がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - Stratis プールを作成するブロックデバイスは、使用もマウントもされておらず、1 GB 以上の領域がある。
IBM Z アーキテクチャーで、
/dev/dasd*ブロックデバイスがパーティション設定されている。Stratis プールでパーティションを使用します。DASD デバイスのパーティション設定の詳細は、64-bit IBM Z での Linux インスタンスの設定 を参照してください。
手順
Stratis プールで使用する各ブロックデバイスに存在するファイルシステム、パーティションテーブル、または RAID 署名をすべて削除します。
# wipefs --all block-deviceblock-deviceの値は、ブロックデバイスへのパスです (例:/dev/sdb)。キーをまだ設定していない場合には、以下のコマンドを実行してプロンプトに従って、暗号化に使用するキーセットを作成します。
# stratis key set --capture-key key-descriptionkey-descriptionは、カーネルキーリングで作成されるキーへの参照になります。コマンドラインで、キー値の入力を求められます。キー値をファイルに配置し、--capture-keyオプションの代わりに--keyfile-pathオプションを使用することもできます。暗号化した Stratis プールを作成し、暗号化に使用すキーの説明を指定します。
# stratis pool create --key-desc key-description my-pool block-devicekey-description- 直前の手順で作成したカーネルキーリングに存在するキーを参照します。
my-pool- 新しい Stratis プールの名前を指定します。
block-device空のブロックデバイスまたは消去したブロックデバイスへのパスを指定します。
次のコマンドを使用して、1 行に複数のブロックデバイスを指定することもできます。
# stratis pool create --key-desc key-description my-pool block-device-1 block-device-2
検証
新しい Stratis プールが作成されていることを確認します。
# stratis pool list
27.7. Clevis を使用して暗号化された Stratis プールを作成する リンクのコピーリンクがクリップボードにコピーされました!
Stratis 2.4.0 以降では、コマンドラインで Clevis オプションを指定することで、Clevis メカニズムを使用して暗号化されたプールを作成できます。
前提条件
-
Stratis v2.3.0 以降がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - 暗号化された Stratis プールが作成されている。詳細は、カーネルキーリング内のキーを使用して暗号化された Stratis プールを作成するを 参照してください。
- お使いのシステムは Trusted Platform Module (TPM)2.0 をサポートしています。
手順
Stratis プールで使用する各ブロックデバイスに存在するファイルシステム、パーティションテーブル、または RAID 署名をすべて削除します。
# wipefs --all block-deviceblock-deviceの値は、ブロックデバイスへのパスです (例:/dev/sdb)。暗号化された Stratis プールを作成し、暗号化に使用する Clevis メカニズムを指定します。
# stratis pool create --clevis tpm2 my-pool block-devicetpm2- 使用する Clevis 機構を指定します。
my-pool- 新しい Stratis プールの名前を指定します。
block-device空のブロックデバイスまたは消去したブロックデバイスへのパスを指定します。
または、次のコマンドを使用して Clevis tang サーバーメカニズムを使用します。
# stratis pool create --clevis tang --tang-url my-url --thumbprint thumbprint my-pool block-devicetang- 使用する Clevis 機構を指定します。
my-url- tang サーバーの URL を指定します。
thumbprinttang サーバーの thumbprint を参照します。
次のコマンドを使用して、1 行に複数のブロックデバイスを指定することもできます。
# stratis pool create --clevis tpm2 my-pool block-device-1 block-device-2
検証
新しい Stratis プールが作成されていることを確認します。
# stratis pool list注記プール作成時に Clevis とキーリングの両方のオプションを同時に指定することで、Clevis とキーリングの両方のメカニズムを使用して暗号化プールを作成することもできます。
27.8. storage RHEL システムロールを使用して暗号化された Stratis プールを作成する リンクのコピーリンクがクリップボードにコピーされました!
データを保護するために、storage RHEL システムロールを使用して暗号化された Stratis プールを作成できます。パスフレーズに加えて、暗号化方法として Clevis と Tang または TPM 保護を使用できます。
Stratis 暗号化はプール全体でのみ設定できます。
前提条件
- コントロールノードと管理対象ノードの準備が完了している。
- 管理対象ノードで Playbook を実行できるユーザーとしてコントロールノードにログインしている。
-
管理対象ノードへの接続に使用するアカウントに、そのノードに対する
sudo権限がある。 - Tang サーバーに接続できる。詳細は、SELinux を Enforcing モードで有効にした Tang サーバーのデプロイメント を参照してください。
手順
機密性の高い変数を暗号化されたファイルに保存します。
vault を作成します。
$ ansible-vault create ~/vault.ymlNew Vault password: <vault_password> Confirm New Vault password: <vault_password>ansible-vault createコマンドでエディターが開いたら、機密データを<key>: <value>形式で入力します。luks_password: <password>- 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。
次の内容を含む Playbook ファイル (例:
~/playbook.yml) を作成します。--- - name: Manage local storage hosts: managed-node-01.example.com vars_files: - ~/vault.yml tasks: - name: Create a new encrypted Stratis pool with Clevis and Tang ansible.builtin.include_role: name: redhat.rhel_system_roles.storage vars: storage_pools: - name: mypool disks: - sdd - sde type: stratis encryption: true encryption_password: "{{ luks_password }}" encryption_clevis_pin: tang encryption_tang_url: tang-server.example.com:7500サンプル Playbook で指定されている設定は次のとおりです。
encryption_password- LUKS ボリュームのロックを解除するために使用するパスワードまたはパスフレーズ。
encryption_clevis_pin-
作成されたプールを暗号化するために使用できる Clevis の方式。
tangとtpm2を使用できます。 encryption_tang_url- Tang サーバーの URL。
Playbook で使用されるすべての変数の詳細は、コントロールノードの
/usr/share/ansible/roles/rhel-system-roles.storage/README.mdファイルを参照してください。Playbook の構文を検証します。
$ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.ymlこのコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。
Playbook を実行します。
$ ansible-playbook --ask-vault-pass ~/playbook.yml
検証
Clevis と Tang が設定された状態でプールが作成されたことを確認します。
$ ansible managed-node-01.example.com -m command -a 'sudo stratis report'... "clevis_config": { "thp": "j-G4ddvdbVfxpnUbgxlpbe3KutSKmcHttILAtAkMTNA", "url": "tang-server.example.com:7500" }, "clevis_pin": "tang", "in_use": true, "key_description": "blivet-mypool",
27.9. Web コンソールを使用した暗号化された Stratis プールの作成 リンクのコピーリンクがクリップボードにコピーされました!
データを保護するために、Web コンソールを使用して、1 つ以上のブロックデバイスから暗号化された Stratis プールを作成できます。
1 つ以上のブロックデバイスから暗号化された Stratis プールを作成する場合は、次の点に注意してください。
- 各ブロックデバイスは cryptsetup ライブラリーを使用して暗号化され、Linux Unified Key Setup バージョン 2(LUKS2) フォーマットを実装しています。
- 各 Stratis プールは、一意の鍵を持つか、他のプールと同じ鍵を共有できます。これらのキーはカーネルキーリングに保存されます。
- Stratis プールを構成するブロックデバイスは、すべて暗号化または暗号化されていないデバイスである必要があります。同じ Stratis プールに、暗号化したブロックデバイスと暗号化されていないブロックデバイスの両方を含めることはできません。
- 暗号化 Stratis プールのデータ層に追加されるブロックデバイスは、自動的に暗号化されます。
前提条件
RHEL 10 Web コンソールがインストールされている。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
-
Stratis v2.1.0 以降がインストールされ、
stratisdサービスが実行されている。 - Stratis プールを作成するブロックデバイスは、使用もマウントもされておらず、1 GB 以上の領域がある。
手順
- RHEL 10 Web コンソールにログインします。
- をクリックします。
- Storage テーブルで、メニューボタンをクリックし、Create Stratis pool を選択します。
- Name フィールドに、Stratis プールの名前を入力します。
- Stratis プールの作成元となる Block devices を選択します。
暗号化のタイプを選択します。パスフレーズ、Tang キーサーバー、またはその両方を使用できます。
パスフレーズ:
- パスフレーズを入力します。
- パスフレーズを確定します。
Tang キーサーバー:
- キーサーバーのアドレスを入力します。詳細は、SELinux を Enforcing モードで有効にした Tang サーバーのデプロイメント を参照してください。
- オプション: プールに作成する各ファイルシステムの最大サイズを指定する場合は、Manage filesystem sizes を選択します。
- をクリックします。
検証
- Storage セクションに移動し、Devices テーブルに新しい Stratis プールが表示されていることを確認します。
27.10. Web コンソールを使用した Stratis プールの名前変更 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、既存の Stratis プールの名前を変更できます。
前提条件
RHEL 10 Web コンソールがインストールされている。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
Stratis がインストールされ、
stratisdサービスが実行されている。Web コンソールがデフォルトで Stratis を検出してインストールしている。ただし、Stratis を手動でインストールする場合は、Stratis のインストール を参照してください。
- Stratis プールが作成されている。
手順
- RHEL 10 Web コンソールにログインします。
- をクリックします。
- Storage テーブルで、名前を変更する Stratis プールをクリックします。
- Stratis pool ページで、Name フィールドの横にある をクリックします。
- Rename Stratis pool ダイアログボックスで、新しい名前を入力します。
- をクリックします。
27.11. Stratis ファイルシステムでのオーバープロビジョニングモードの設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、すべての Stratis プールはオーバープロビジョニングされており、論理ファイルシステムのサイズが物理的に割り当てられた領域を超える可能性があります。Stratis はファイルシステムの使用状況を監視し、必要に応じて使用可能な領域を使用して割り当てを自動的に増やします。ただし、すでに使用可能な領域がすべて割り当てられており、プールがいっぱいの場合は、ファイルシステムに追加領域を割り当てることはできません。
ファイルシステムの容量が不足すると、ユーザーはデータを失う可能性があります。データ損失のリスクがオーバープロビジョニングの利点を上回るアプリケーションの場合、この機能を無効にできます。
Stratis はプールの使用状況を継続的に監視し、D-Bus API を使用してその値を報告します。ストレージ管理者はこれらの値を監視し、容量に達しないように必要に応じてデバイスをプールに追加する必要があります。
前提条件
- Stratis がインストールされている。詳細は、Stratis のインストール を参照してください。
手順
プールを正しく設定するには、次の 2 つの方法があります。
1 つ以上のブロックデバイスからプールを作成して、作成時にプールが完全にプロビジョニングされるようにします。
# stratis pool create --no-overprovision pool-name /dev/sdb--no-overprovisionオプションを使用すると、プールは実際に利用可能な物理領域よりも多くの論理領域を割り当てることができません。既存のプールにオーバープロビジョニングモードを設定します。
# stratis pool overprovision pool-name <yes|no>"yes" に設定すると、プールへのオーバープロビジョニングが有効になります。これは、プールによってサポートされる Stratis ファイルシステムの論理サイズの合計が、利用可能なデータ領域の量を超える可能性があることを意味します。プールがオーバープロビジョニングされ、すべてのファイルシステムの論理サイズの合計がプールで使用可能な領域を超える場合、システムはオーバープロビジョニングをオフにできず、エラーを返します。
検証
Stratis プールの完全なリストを表示します。
# stratis pool listName Total Physical Properties UUID Alerts pool-name 1.42 TiB / 23.96 MiB / 1.42 TiB ~Ca,~Cr,~Op cb7cb4d8-9322-4ac4-a6fd-eb7ae9e1e540-
stratis pool listの出力に、プールのオーバープロビジョニングモードフラグが表示されているかどうかを確認します。" ~ " は "NOT" を表す数学記号であるため、~Opはオーバープロビジョニングなしという意味です。 オプション: 特定のプールのオーバープロビジョニングを確認します。
# stratis pool overprovision pool-name yes# stratis pool listName Total Physical Properties UUID Alerts pool-name 1.42 TiB / 23.96 MiB / 1.42 TiB ~Ca,~Cr,~Op cb7cb4d8-9322-4ac4-a6fd-eb7ae9e1e540
27.12. Stratis プールの NBDE へのバインド リンクのコピーリンクがクリップボードにコピーされました!
暗号化された Stratis プールを Network Bound Disk Encryption (NBDE) にバインドするには、Tang サーバーが必要です。Stratis プールを含むシステムが再起動すると、Tang サーバーに接続して、カーネルキーリングの説明を指定しなくても、暗号化したプールのロックを自動的に解除します。
Stratis プールを補助 Clevis 暗号化メカニズムにバインドすると、プライマリーカーネルキーリング暗号化は削除されません。
前提条件
-
Stratis v2.3.0 以降がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - 暗号化した Stratis プールを作成し、暗号化に使用したキーの説明がある。詳細は、カーネルキーリング内のキーを使用して暗号化された Stratis プールを作成するを 参照してください。
- Tang サーバーに接続できる。詳細は、SELinux を Enforcing モードで有効にした Tang サーバーのデプロイメント を参照してください。
手順
暗号化された Stratis プールを NBDE にバインドする。
# stratis pool bind nbde --trust-url my-pool tang-servermy-pool- 暗号化された Stratis プールの名前を指定します。
tang-server- Tang サーバーの IP アドレスまたは URL を指定します。
27.13. Stratis プールの TPM へのバインド リンクのコピーリンクがクリップボードにコピーされました!
暗号化された Stratis プールを Trusted Platform Module (TPM) 2.0 にバインドすると、プールを含むシステムが再起動され、カーネルキーリングの説明を指定しなくても、プールは自動的にロック解除されます。
前提条件
-
Stratis v2.3.0 以降がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - 暗号化した Stratis プールを作成し、暗号化に使用したキーの説明がある。詳細は、カーネルキーリング内のキーを使用して暗号化された Stratis プールを作成するを 参照してください。
- 使用しているシステムは TPM 2.0 をサポートしている。
手順
暗号化された Stratis プールを TPM にバインドします。
# stratis pool bind tpm my-poolmy-pool- 暗号化された Stratis プールの名前を指定します。
key-description- 暗号化された Stratis プールの作成時に生成されたカーネルキーリングに存在するキーを参照します。
27.14. カーネルキーリングを使用した暗号化 Stratis プールのロック解除 リンクのコピーリンクがクリップボードにコピーされました!
システムの再起動後、暗号化した Stratis プール、またはこれを構成するブロックデバイスが表示されない場合があります。プールを暗号化するために使用されたカーネルキーリングを使用することで、プールのロックを解除できます。
前提条件
-
Stratis v2.1.0 がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - 暗号化された Stratis プールが作成されている。詳細は、カーネルキーリング内のキーを使用して暗号化された Stratis プールを作成するを 参照してください。
手順
以前使用したのと同じキー記述を使用して、キーセットを再作成します。
# stratis key set --capture-key key-descriptionkey-descriptionは、暗号化された Stratis プールの作成時に生成されたカーネルキーリングに存在するキーを参照します。Stratis プールが表示されることを確認します。
# stratis pool list
27.15. 補助暗号化からの Stratis プールのバインド解除 リンクのコピーリンクがクリップボードにコピーされました!
暗号化した Stratis プールを、サポート対象の補助暗号化メカニズムからバインドを解除すると、プライマリーカーネルキーリングの暗号化はそのまま残ります。これは、最初から Clevis 暗号化を使用して作成されたプールには当てはまりません。
前提条件
- Stratis v2.3.0 以降がシステムにインストールされている。詳細は、Stratis のインストール を参照してください。
- 暗号化された Stratis プールが作成されている。詳細は、カーネルキーリング内のキーを使用して暗号化された Stratis プールを作成するを 参照してください。
- 暗号化した Stratis プールは、サポート対象の補助暗号化メカニズムにバインドされます。
手順
補助暗号化メカニズムから暗号化された Stratis プールのバインドを解除します。
# stratis pool unbind clevis my-poolmy-poolは、バインドを解除する Stratis プールの名前を指定します。
27.16. Stratis プールの開始および停止 リンクのコピーリンクがクリップボードにコピーされました!
Stratis プールを開始および停止できます。この操作により、ファイルシステム、キャッシュデバイス、シンプール、暗号化されたデバイスなど、プールの構築に使用されたすべてのオブジェクトを解体または停止できます。プールがデバイスまたはファイルシステムをアクティブに使用している場合は、警告が表示され、停止できない可能性があることに注意してください。
停止状態は、プールのメタデータに記録されます。これらのプールは、プールが開始コマンドを受信するまで、次のブートでは開始されません。
前提条件
-
Stratis がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - 暗号化されていない、または暗号化された Stratis プールを作成した。詳細は、暗号化されていない Stratis プールを作成する または カーネルキーリング内のキーを使用して暗号化された Stratis プールを作成する を参照してください。
手順
次のコマンドを使用して、Stratis プールを停止します。これにより、ストレージスタックが切断されますが、メタデータはすべて保持されます。
# stratis pool stop --name pool-name以下のコマンドを使用して Stratis プールを起動します。
--unlock-methodオプションは、プールが暗号化されている場合にプールのロックを解除する方法を指定します。# stratis pool start --unlock-method <keyring|clevis> --name pool-name注記プール名またはプール UUID のいずれかを使用してプールを開始できます。
検証
次のコマンドを使用して、システム上のすべてのアクティブなプールをリスト表示します。
# stratis pool list次のコマンドを使用して、停止されたプールをすべてリスト表示します。
# stratis pool list --stopped次のコマンドを使用して、停止したプールの詳細情報を表示します。UUID を指定すると、このコマンドは UUID に対応するプールに関する詳細情報を出力します。
# stratis pool list --stopped --uuid UUID
27.17. Stratis ファイルシステムの作成 リンクのコピーリンクがクリップボードにコピーされました!
Stratis ファイルシステムを作成して、シンプロビジョニング、自動ファイルシステム拡張、ストレージプール内の統合スナップショットサポートなどの高度なストレージ機能を活用します。
前提条件
-
Stratis がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - Stratis プールが作成されている。詳細は、暗号化されていない Stratis プールの作成 または カーネルキーリング内のキーの使用 を参照してください。
手順
プールに Stratis ファイルシステムを作成します。
# stratis filesystem create --size number-and-unit my-pool my-fsnumber-and-unit- ファイルシステムのサイズを指定します。仕様形式は、入力の標準サイズ指定形式 (B、KiB、MiB、GiB、TiB、または PiB) に準拠する必要があります。
my-pool- Stratis プールの名前を指定します。
my-fsファイルシステムの任意名を指定します。
たとえば、Stratis ファイルシステムを作成します。
# stratis filesystem create --size 10GiB pool1 filesystem1
ファイルシステムのサイズ制限を設定します。
# stratis filesystem create --size number-and-unit --size-limit number-and-unit my-pool my-fs注記このオプションは、Stratis 3.6.0 以降で利用できます。
必要に応じて、後でサイズ制限を削除することもできます。
# stratis filesystem unset-size-limit my-pool my-fs
検証
プール内のファイルシステムをリスト表示して、Stratis ファイルシステムが作成されているかどうかを確認します。
# stratis fs list my-pool
27.18. Stratis ファイルシステムのマウント リンクのコピーリンクがクリップボードにコピーされました!
既存の Stratis ファイルシステムをマウントして、コンテンツにアクセスします。
前提条件
-
Stratis がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - Stratis ファイルシステムが作成されます。詳細は、Stratis ファイルシステムの作成 を参照してください。
手順
ファイルシステムをマウントするには、
/dev/stratis/ディレクトリーに Stratis が維持するエントリーを使用します。# mount /dev/stratis/my-pool/my-fs mount-pointこれでファイルシステムは mount-point ディレクトリーにマウントされ、使用できるようになりました。
注記プールを停止する前に、プールに属するすべてのファイルシステムをアンマウントします。ファイルシステムがマウントされたままの状態でも、プールは停止しません。
27.19. ブート時に Stratis ファイルシステムをマウントする設定 リンクのコピーリンクがクリップボードにコピーされました!
ファイルシステムのプールを正しく起動するメカニズムを設定することで、Stratis ファイルシステムをブート時にマウントするように設定できます。これを行わないと、マウント操作が失敗します。Stratis はこのプロセスをサポートするために 2 つの systemd サービスを提供します。
Stratis は現在、ルートファイルシステムの管理をサポートしていません。次の手順は、ルート以外のファイルシステムにのみ適用されます。
前提条件
- Stratis ファイルシステム (例: <my-fs>) が、Stratis プール (例: <my-pool>) 上に作成されている。詳細は、Stratis ファイルシステムの作成 を参照してください。
- マウントポイントディレクトリー (例: <mount-point>) が作成されている。
- ファイルシステムのプールの UUID が特定されている (例: <pool-uuid>)。
手順
root として、
/etc/fstabファイルを編集します。ファイルシステムの
/etc/fstabエントリーのマウントオプションにx-systemd.requires=stratis-fstab-setup@<pool-uuid>.serviceを追加します。/dev/stratis/<my-pool>/<my-fs> <mount-point> xfs defaults,x-systemd.requires=stratis-fstab-setup@<pool-uuid>.serviceClevis で NBDE(Network Bound Disk Encryption) を使用してプールが暗号化されている場合は
、x-systemd.requires=stratis-fstab-setup-with-network@ <pool-uuid> .serviceおよび_netdevを追加してください。/dev/stratis/<my-pool>/<my-fs> <mount-point> xfs defaults,x-systemd.requires=stratis-fstab-setup-with-network@<pool-uuid>.service,_netdev以下のように置き換えます。
- <my-pool> は、ファイルシステムが含まれる Stratis プールの名前です。
- <my-fs> は、プール内に作成した Stratis ファイルシステムの名前です。
- <mount-point> は、ファイルシステムをマウントするディレクトリーの名前です。
<pool-uuid> は、ファイルシステムのプールの UUID です。
重要暗号化された Stratis プールから Stratis ファイルシステムをブート時にマウントすると、パスワードが入力されるまでブートプロセスが停止する可能性があります。プールが NBDE や TPM2 などの無人メカニズムを使用して暗号化されている場合、Stratis プールは自動的にロック解除されます。そうでない場合は、ユーザーがコンソールにパスワードを入力して、ファイルシステムのプールのロックを解除する必要がある可能性があります。
27.20. Web コンソールを使用して Stratis ファイルシステムを作成および設定する リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、既存の Stratis プール上にファイルシステムを作成できます。
前提条件
RHEL 10 Web コンソールがインストールされている。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
-
stratisdサービスを実行している。 - Stratis プールが作成されている。
手順
- RHEL 10 Web コンソールにログインします。
- をクリックします。
- ファイルシステムを作成する Stratis プールをクリックします。
- Stratis pool ページで、Stratis filesystems セクションまでスクロールし、 をクリックします。
- ファイルシステムの名前を入力します。
- ファイルシステムのマウントポイントを入力します。
- マウントオプションを選択します。
- At boot ドロップダウンメニューで、ファイルシステムをマウントするタイミングを選択します。
ファイルシステムを作成します。
- ファイルシステムを作成してマウントする場合は、 をクリックします。
- ファイルシステムの作成のみを行う場合は、 をクリックします。
検証
- 新しいファイルシステムは、Stratis pool ページの Stratis filesystems タブに表示されます。
第28章 追加のブロックデバイスで Stratis プールを拡張する リンクのコピーリンクがクリップボードにコピーされました!
Stratis ファイルシステムのストレージ容量を増やすために、追加のブロックデバイスを Stratis プールに追加できます。手動で行うことも、Web コンソールを使用して行うこともできます。
28.1. Stratis プールへのブロックデバイスの追加 リンクのコピーリンクがクリップボードにコピーされました!
Stratis プールに 1 つ以上のブロックデバイスを追加できます。
前提条件
-
Stratis がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - Stratis プールを作成するブロックデバイスは、使用もマウントもされておらず、1 GB 以上の領域がある。
手順
1 つ以上のブロックデバイスをプールに追加するには、以下を使用します。
# stratis pool add-data my-pool device-1 device-2 device-n
28.2. Web コンソールを使用した Stratis プールへのブロックデバイスの追加 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、既存の Stratis プールにブロックデバイスを追加できます。キャッシュをブロックデバイスとして追加することもできます。
前提条件
RHEL 10 Web コンソールがインストールされている。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
-
stratisdサービスを実行している。 - Stratis プールが作成されている。
- Stratis プールを作成するブロックデバイスは、使用もマウントもされておらず、1 GB 以上の領域がある。
手順
- RHEL 10 Web コンソールにログインします。
- をクリックします。
- Storage テーブルで、ブロックデバイスを追加する Stratis プールをクリックします。
- Stratis pool ページで、 をクリックし、ブロックデバイスをデータまたはキャッシュとして追加する Tier を選択します。
- パスフレーズで暗号化された Stratis プールにブロックデバイスを追加する場合は、パスフレーズを入力します。
- Block devices で、プールに追加するデバイスを選択します。
- をクリックします。
第29章 Stratis ファイルシステムの監視 リンクのコピーリンクがクリップボードにコピーされました!
Stratis ユーザーは、システムにある Stratis ファイルシステムに関する情報を表示して、その状態と空き容量を監視できます。
29.1. Stratis ファイルシステムに関する情報の表示 リンクのコピーリンクがクリップボードにコピーされました!
stratis ユーティリティーを使用すると、Stratis ファイルシステムの合計サイズ、使用サイズ、空きサイズ、プールに属するファイルシステムとブロックデバイスなどに関する統計情報をリスト表示できます。
XFS ファイルシステムのサイズは、管理できるユーザーデータの合計量です。シンプロビジョニングされた Stratis プールでは、Stratis ファイルシステムのサイズが、割り当てられた領域よりも大きいように見える場合があります。XFS ファイルシステムのサイズは、この見かけのサイズに合わせて設定されます。つまり、通常は割り当てられた領域よりも大きくなります。df などの標準 Linux ユーティリティーは、XFS ファイルシステムのサイズを報告します。この値は通常、XFS ファイルシステムに必要な領域、つまり Stratis によって割り当てられた領域を過大評価します。
オーバープロビジョニングされた Stratis プールの使用状況を定期的に監視してください。ファイルシステムの使用量が割り当てられた容量に近づくと、Stratis はプール内の利用可能な容量を使用して割り当てを自動的に増やします。ただし、すでに使用可能な領域がすべて割り当てられていて、プールがいっぱいの場合は、追加の領域を割り当てることができず、ファイルシステムの領域が不足することになります。これは、Stratis ファイルシステムを使用することで、アプリケーションにおけるデータ損失のリスクにつながる可能性があります。
前提条件
-
Stratis がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。
手順
システムで Stratis に使用されているすべての ブロックデバイス に関する情報を表示する場合は、次のコマンドを実行します。
# stratis blockdevPool Name Device Node Physical Size Tier UUID my-pool /dev/sdb 9.10 TiB Data ec9fb718-f83c-11ef-861e-7446a09dccfbシステムにあるすべての Stratis プール に関する情報を表示するには、次のコマンドを実行します。
# stratis poolName Total/Used/Free Properties UUID Alerts my-pool 8.00 GiB / 800.99 MiB / 7.22 GiB -Ca,-Cr,Op e22772c2-afe9-446c-9be5-2f78f682284e WS001システムにあるすべての Stratis ファイルシステム に関する情報を表示するには、次のコマンドを実行します。
# stratis filesystemPool Filesystem Total/Used/Free/Limit Device UUID Spool1 sfs1 1 TiB / 546 MiB / 1023.47 GiB / None /dev/stratis/spool1/sfs1 223265f5-8f17-4cc2-bf12-c3e9e71ff7bfファイルシステム名または UUID を指定して、システム上の Stratis ファイルシステムに関する詳細情報を表示することもできます。
# stratis filesystem list my-pool --name my-fsUUID: 47255008-9bc7-4bd2-8294-e9d25cd9e7ba Name: my-fs Pool: my-pool Device: /dev/stratis/my-pool/my-fs Created: Nov 08 2018 08:03 Snapshot origin: None Sizes: Logical size of thin device: 1 TiB Total used (including XFS metadata): 546 MiB Free: 1023.47 GiB Size Limit: None
29.2. Web コンソールを使用した Stratis プールの表示 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、既存の Stratis プールとそれに含まれるファイルシステムを表示できます。
前提条件
RHEL 10 Web コンソールがインストールされている。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
-
stratisdサービスを実行している。 - 既存の Stratis プールがある。
手順
- RHEL 10 Web コンソールにログインします。
- をクリックします。
Storage テーブルで、表示する Stratis プールをクリックします。
Stratis プールページには、プールおよびプール内に作成したファイルシステムに関するすべての情報が表示されます。
第30章 Stratis ファイルシステムでのスナップショットの使用 リンクのコピーリンクがクリップボードにコピーされました!
Stratis ファイルシステムのスナップショットを使用して、ファイルシステムの状態を任意の時点でキャプチャーし、後でそれを復元できます。
30.1. Stratis スナップショットの特徴 リンクのコピーリンクがクリップボードにコピーされました!
Stratis スナップショットは、他の Stratis ファイルシステムの特定時点のコピーとして作成される通常のファイルシステムです。これらはソースファイルシステムとは独立して動作し、バックアップ、テスト、またはデータ回復の目的で使用できます。
Stratis の現在のスナップショット実装は、次のような特徴があります。
- ファイルシステムのスナップショットは別のファイルシステムです。
- スナップショットと元のファイルシステムのリンクは、有効期間中は行われません。スナップショットされたファイルシステムは、元のファイルシステムよりも長く存続します。
- スナップショットを作成するためにファイルシステムをマウントする必要はありません。
- 各スナップショットは、XFS ログに必要となる実際のバッキングストレージの約半分のギガバイトを使用します。
30.2. Stratis スナップショットの作成 リンクのコピーリンクがクリップボードにコピーされました!
既存の Stratis ファイルシステムのスナップショットとして Stratis ファイルシステムを作成できます。
前提条件
-
Stratis がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - Stratis ファイルシステムを作成している。詳細は、Stratis ファイルシステムの作成 を参照してください。
手順
Stratis スナップショットを作成します。
# stratis fs snapshot my-pool my-fs my-fs-snapshotスナップショットは、中心的な Stratis ファイルシステムです。Stratis スナップショットは複数作成できます。単一のオリジンファイルシステム、または別のスナップショットファイルシステムのスナップショットがあります。ファイルシステムがスナップショットである場合、詳細なファイルシステムリストにおいて、その 元 フィールドには元のファイルシステムの UUID が表示されます。
30.3. Stratis スナップショットのコンテンツへのアクセス リンクのコピーリンクがクリップボードにコピーされました!
Stratis ファイルシステムのスナップショットを、読み取りおよび書き込み操作でアクセスできるようにマウントすることができます。
前提条件
-
Stratis がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - Stratis スナップショットを作成している。詳細は、Stratis スナップショットの作成 を参照してください。
手順
スナップショットにアクセスするには、
/dev/stratis/my-pool/ディレクトリーから通常のファイルシステムとしてマウントします。# mount /dev/stratis/my-pool/my-fs-snapshot mount-point
30.4. Stratis ファイルシステムを以前のスナップショットに戻す リンクのコピーリンクがクリップボードにコピーされました!
Stratis ファイルシステムの内容を、Stratis スナップショットでキャプチャーされた状態に戻すことができます。
前提条件
-
Stratis がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - Stratis スナップショットを作成している。詳細は、Stratis スナップショットの作成 を参照してください。
手順
オプション: 後でアクセスできるように、ファイルシステムの現在の状態をバックアップします。
# stratis filesystem snapshot my-pool my-fs my-fs-backupファイルシステムを以前に取得したスナップショットに戻すスケジュールを設定します。
# stratis filesystem schedule-revert my-pool my-fs-snapshotオプション: 次のコマンドを実行して、元に戻す操作が正常にスケジュールされているかどうかを確認します。
# stratis filesystem list my-pool --name my-fs-snapshotUUID: b14987eb-b735-4c68-8962-f53f6b644cbc Name: my-fs-snapshot Pool: my-pool Device: /dev/stratis/p1/my-fs-snapshot Created: Mar 18 2025 12:29 Snapshot origin: f5a881b1-299d-4147-8ead-b4a56c623692 Revert scheduled: Yes Sizes: Logical size of thin device: 1 TiB Total used (including XFS metadata): 5.42 GiB Free: 1018.58 GiB注記同じ元のファイルシステムに対して、元に戻す操作を複数スケジュールすることはできません。また、元のファイルシステムまたは復元がスケジュールされているスナップショットのいずれかを破棄しようとすると、破棄操作は失敗します。
プールを再起動する前に、いつでも元に戻す操作をキャンセルできます。
# stratis filesystem cancel-revert my-pool my-fs-snapshot次のコマンドを実行して、キャンセルが正常にスケジュールされているかどうかを確認できます。
# stratis filesystem list my-pool --name my-fs-snapshotUUID: b14987eb-b735-4c68-8962-f53f6b644cbc Name: my-fs-snapshot Pool: my-pool Device: /dev/stratis/p1/my-fs-snapshot Created: Mar 18 2025 12:29 Snapshot origin: f5a881b1-299d-4147-8ead-b4a56c623692 Revert scheduled: No Sizes: Logical size of thin device: 1 TiB Total used (including XFS metadata): 5.42 GiB Free: 1018.58 GiB Size Limit: Noneキャンセルされていない場合は、プールの再起動時にスケジュールされた元に戻す操作が続行されます。
# stratis pool stop --name my-pool# stratis pool start --name my-pool
検証
プールに属するファイルシステムをリスト表示します。
# stratis filesystem list my-pool
my-fs-snapshot は、以前にコピーされた my-fs-snapshot 状態に戻されたため、プール内のファイルシステムのリストに表示されなくなりました。my-fs という名前のファイルシステムの内容は、スナップショット my-fs-snapshot と同じになりました。
30.5. Stratis スナップショットの削除 リンクのコピーリンクがクリップボードにコピーされました!
プールから Stratis スナップショットを削除できます。スナップショットのデータは失われます。
前提条件
-
Stratis がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - Stratis スナップショットを作成している。詳細は、Stratis スナップショットの作成 を参照してください。
手順
スナップショットをアンマウントします。
# umount /dev/stratis/my-pool/my-fs-snapshotスナップショットを破棄します。
# stratis filesystem destroy my-pool my-fs-snapshot
第31章 Stratis ファイルシステムの削除 リンクのコピーリンクがクリップボードにコピーされました!
既存の Stratis ファイルシステムまたはプールを削除できます。削除した Stratis ファイルシステムやプールは復元できません。
31.1. Stratis ファイルシステムの削除 リンクのコピーリンクがクリップボードにコピーされました!
既存の Stratis ファイルシステムを削除できます。そこに保存されているデータは失われます。
前提条件
-
Stratis がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 - Stratis ファイルシステムを作成している。詳細は、Stratis ファイルシステムの作成 を参照してください。
手順
ファイルシステムをアンマウントします。
# umount /dev/stratis/my-pool/my-fsファイルシステムを破棄します。
# stratis filesystem destroy my-pool my-fs
検証
ファイルシステムがもう存在しないことを確認します。
# stratis filesystem list my-pool
31.2. Web コンソールを使用した Stratis プールからのファイルシステムの削除 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、既存の Stratis プールからファイルシステムを削除できます。
Stratis プールのファイルシステムを削除すると、そこに含まれるすべてのデータが消去されます。
前提条件
RHEL 10 Web コンソールがインストールされている。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
Stratis がインストールされ、
stratisdサービスが実行されている。Web コンソールがデフォルトで Stratis を検出してインストールしている。ただし、Stratis を手動でインストールする場合は、Stratis のインストール を参照してください。
- 既存の Stratis プールがあり、その Stratis プール上にファイルシステムが作成されている。
手順
- RHEL 10 Web コンソールにログインします。
- をクリックします。
- Storage テーブルで、ファイルシステムを削除する Stratis プールをクリックします。
- Stratis pool ページで、Stratis filesystems セクションまでスクロールし、削除するファイルシステムのメニューボタン をクリックします。
- ドロップダウンメニューから を選択します。
- Confirm deletion ダイアログボックスで、 をクリックします。
31.3. Stratis プールの削除 リンクのコピーリンクがクリップボードにコピーされました!
既存の Stratis プールを削除できます。そこに保存されているデータは失われます。
前提条件
-
Stratis がインストールされ、
stratisdサービスが実行されている。詳細は、Stratis のインストール を参照してください。 Stratis プールを作成している。
- 暗号化されていないプールを作成するには、暗号化されていない Stratis プールの作成 を参照してください。
- 暗号化されたプールを作成するには、カーネルキーリング内のキーを使用して暗号化された Stratis プールを作成するを 参照してください。
手順
プールにあるファイルシステムのリストを表示します。
# stratis filesystem list my-poolプール上のすべてのファイルシステムをアンマウントします。
# umount /dev/stratis/my-pool/my-fs-1 \ /dev/stratis/my-pool/my-fs-2 \ /dev/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
31.4. Web コンソールを使用した Stratis プールの削除 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、既存の Stratis プールを削除できます。
Stratis プールを削除すると、そこに含まれるすべてのデータが消去されます。
前提条件
RHEL 10 Web コンソールがインストールされている。
手順は、Web コンソールのインストールおよび有効化 を参照してください。
-
stratisdサービスを実行している。 - 既存の Stratis プールがある。
手順
- RHEL 10 Web コンソールにログインします。
- をクリックします。
- Storage テーブルで、削除する Stratis プールのメニューボタン をクリックします。
- ドロップダウンメニューから を選択します。
- Permanently delete pool ダイアログボックスで、 をクリックします。
第32章 ext4 ファイルシステムの使用 リンクのコピーリンクがクリップボードにコピーされました!
システム管理者は、ext4 ファイルシステムを作成、マウント、サイズ変更、バックアップ、および復元できます。ext4 ファイルシステムは、ext3 のスケーラブルな拡張機能です。Red Hat Enterprise Linux 10 では、最大 16 TB の個々のファイルと最大 50 TB のファイルシステムをサポートします。
32.1. ext4 ファイルシステムの機能 リンクのコピーリンクがクリップボードにコピーされました!
効率的な大規模ファイル処理のためのエクステント、改善されたファイルシステムチェック時間、高度な割り当て手法、メタデータの整合性、拡張属性、クォータジャーナリング、1 秒未満のタイムスタンプなど、主要な ext4 ファイルシステム機能について説明します。
ext4 ファイルシステムの機能の詳細は次のとおりです。
- エクステントの使用 - ext4 ファイルシステムはエクステントを使用します。これにより、サイズが大きいファイルを使用する場合のパフォーマンスが向上し、サイズが大きいファイルのメタデータのオーバーヘッドが削減されます。
- Ext4 は、割り当てられていないブロックグループと inode テーブルセクションにラベルを付けることで、ファイルシステムのチェック時にそれらをスキップできるようにします。ファイルシステムの検査が簡単に行われ、ファイルシステムがサイズが大きくなるとより有益になります。
- メタデータチェックサム - Red Hat Enterprise Linux 10 では、この機能はデフォルトで有効になっています。
以下は、ext4 ファイルシステムの割り当て機能です。
- 永続的な事前割り当て
- 遅延割り当て
- マルチブロック割り当て
- ストライプ認識割り当て
-
拡張属性 (
xattr) - これにより、システムは、ファイルごとに、名前と値の組み合わせを追加で関連付けられるようになります。 クォータジャーナリング - クラッシュ後に行なわれる時間がかかるクォータの整合性チェックが不要になります。
注記ext4 で対応しているジャーナリングモードは
data=ordered(デフォルト) のみです。- サブセカンド (一秒未満) のタイムスタンプ - サブセカンドのタイムスタンプを指定します。
詳細は、システム上の ext4 man ページを参照してください。
32.2. ext4 ファイルシステムの作成 リンクのコピーリンクがクリップボードにコピーされました!
システム管理者であれば、mkfs.ext4 コマンドを使用してブロックデバイス上に ext4 ファイルシステムを作成できます。
前提条件
- ディスクにパーティションがある。Master Boot Record (MBR) または GUID Partition Table (GPT) パーティションの作成方法については、parted を使用してディスク上にパーティションテーブルを作成する を参照してください。
- または、論理ボリュームマネージャー (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_deviceUUID を、設定する UUID (例:
7cd65de3-e0be-41d9-b66d-96d749c02da7) に置き換えます。/dev/block_device を、ext4 ファイルシステムへのパス (例:
/dev/sda8) に置き換え、UUID を追加します。ファイルシステムの作成時にラベルを指定するには、以下のコマンドを実行します。
# mkfs.ext4 -L label-name /dev/block_device
作成した ext4 ファイルシステムを表示するには、以下のコマンドを実行します。
# blkid
32.3. ext4 ファイルシステムのマウント リンクのコピーリンクがクリップボードにコピーされました!
システム管理者であれば、マウント ユーティリティーを使用して ext4 ファイルシステムをマウントできます。
前提条件
- ext4 ファイルシステム。ext4 ファイルシステムの作成は、ext4 ファイルシステムの作成 を参照してください。
手順
ファイルシステムをマウントするためのマウントポイントを作成するには、以下のコマンドを実行します。
# mkdir /mount/point/mount/point を、パーティションのマウントポイントを作成するディレクトリー名に置き換えます。
ext4 ファイルシステムをマウントするには、以下を行います。
ext4 ファイルシステムを追加のオプションなしでマウントするには、次のコマンドを実行します。
# mount /dev/block_device /mount/point- ファイルシステムを永続的にマウントするには、ファイルシステムの永続的なマウント を参照してください。
マウントされたファイルシステムを表示するには、次のコマンドを実行します。
# df -h
32.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) に置き換えます。s、K、M、G、T の接尾辞を使用して、size を必要なサイズ変更値に置き換えてください。resize2fsコマンドを使用すると、マウントされた状態で ext4 ファイルシステムを拡張できます。# resize2fs /mount/device size注記拡張時のサイズパラメーターは任意です (多くの場合は必要ありません)。
resize2fsは、コンテナーの使用可能な領域 (通常は論理ボリュームまたはパーティション) を埋めるように、自動的に拡張します。
サイズを変更したファイルシステムを表示するには、次のコマンドを実行します。
# df -h
32.5. ext4 および XFS で使用されるツールの比較 リンクのコピーリンクがクリップボードにコピーされました!
さまざまなツールとコマンドを使用して、作成、チェック、サイズ変更、バックアップ操作など、ext4 および XFS 上の一般的なファイルシステムタスクを実行します。
このセクションでは、ext4 ファイルシステムおよび XFS ファイルシステムで一般的なタスクを行うのに使用するツールを比較します。
| タスク | ext4 | XFS |
|---|---|---|
| ファイルシステムを作成する |
|
|
| ファイルシステム検査 |
|
|
| ファイルシステムのサイズを変更する |
|
|
| ファイルシステムのイメージを保存する |
|
|
| ファイルシステムのラベル付けまたはチューニングを行う |
|
|
| ファイルシステムのバックアップを作成する |
|
|
| クォータ管理 |
|
|
| ファイルマッピング |
|
|
ネットワークを使用してバックアップするための完全なクライアント/サーバーソリューションが必要な場合は、RHEL 9 で利用可能な bacula バックアップユーティリティーを使用できます。Bacula の詳細は、Bacula backup solution を参照してください。
