11.10. ファイルシステムおよびストレージ
LVM writecache の制限
writecache LVM キャッシュメソッドには以下の制限がありますが、cache メソッドには存在しません。
-
pvmoveコマンドを使用すると、writecache論理ボリュームに名前を付けることはできません。 -
writecacheを指定した論理ボリュームは、シンプールまたは VDO と組み合わせて使用できません。
以下の制限は、cache メソッドにも適用されます。
-
cacheまたはwritecacheがアタッチされている間は、論理ボリュームのサイズを変更することはできません。
(JIRA:RHELPLAN-27987, BZ#1798631, BZ#1808012)
XFS クォータ警告が頻繁にトリガーされる
クォータタイマーを使用すると、クォータ警告が頻繁にトリガーされるため、ソフトクォータが必要以上に速く実行されます。この問題を回避するには、警告のトリガーを妨げるソフトクォータを使用しないでください。その結果、警告メッセージの量はソフトクォータ制限を強制せず、設定されたタイムアウトを尊重するようになります。
(BZ#2059262)
LUKS ボリュームを格納する LVM mirror デバイスが応答しなくなることがある
セグメントタイプが mirror のミラーリング LVM デバイスで LUKS ボリュームを格納すると、特定の条件下で応答しなくなる可能性があります。デバイスが応答しなくなると、すべての I/O 操作を拒否します。
耐障害性のソフトウェア定義ストレージに、LUKS ボリュームをスタックする必要がある場合に、この問題を回避するには、Red Hat はセグメントタイプが mirror ではなく raid1 の LVM RAID 1 デバイスを使用することを推奨します。
raid1 のセグメントタイプは、デフォルトの RAID 設定タイプで、mirror の代わりに、推奨のソリューションとしてこのタイプが使用されます。
mirror デバイスを raid1 に変換するには、ミラーリングされた LVM デバイスの RAID1 デバイスへの変換 を参照してください。
(BZ#1730502)
/boot ファイルシステムを LVM に配置することができない
/boot ファイルシステムを LVM 論理ボリュームに配置することはできません。この制限は、以下の理由により存在します。
-
EFI システムでは、EFI システムパーティション が従来の
/bootファイルシステムとして機能します。uEFI 標準では、特定の GPT パーティションタイプと、このパーティションの特定のファイルシステムタイプが必要です。 -
RHEL 8 は、システムブートエントリーに Boot Loader Specification (BLS) を使用します。この仕様では、プラットフォームのファームウェアが
/bootファイルシステムを読み込める必要があります。EFI システムでは、プラットフォームファームウェアは uEFI 標準で定義された/boot設定のみを読み取ることができます。 - GRUB 2 ブートローダーでの LVM 論理ボリュームに対するサポートは完全ではありません。Red Hat は、uEFI や BLS などの標準があるので、この機能のユースケース数が減少しているため、サポートを改善する予定はありません。
Red Hat では、LVM での /boot のサポートを提供する予定はありません。代わりに、Red Hat は、/boot ファイルシステムを LVM 論理ボリュームに配置する必要がないシステムスナップショットおよびロールバックを管理するツールを提供します。
(BZ#1496229)
LVM で、複数のブロックサイズを持つボリュームグループが作成できない
vgcreate または vgextend などの LVM ユーティリティーでは、物理ボリューム (PV) の論理ブロックサイズが異なるボリュームグループ (VG) を作成できなくなりました。別のブロックサイズの PV で基礎となる論理ボリューム (LV) を拡張するとファイルシステムがマウントに失敗するため、LVM はこの変更を採用しました。
ブロックサイズが混在する VG の作成を再度有効にするには、lvm.conf ファイルの allow_mixed_block_sizes=1 オプションを設定します。
blk-availability systemd サービスは、複雑なデバイススタックを非アクティブ化する
systemd では、デフォルトのブロック非アクティブ化コードは、仮想ブロックデバイスの複雑なスタックを常に正しく処理するとは限りません。一部の設定では、シャットダウン中に仮想デバイスが削除されない場合があり、エラーメッセージがログに記録されます。この問題を回避するには、次のコマンドを実行して、複雑なブロックデバイススタックを非アクティブ化します。
# systemctl enable --now blk-availability.service
その結果、複雑な仮想デバイススタックはシャットダウン中に正しく非アクティブ化され、エラーメッセージは生成されません。
(BZ#2011699)
VDO ドライバーのバグにより、ジャーナルブロックを介してデバイスがフリーズする可能性があります
デバイスマッパーの suspend 操作を追跡しているときに、VDO ドライバーのバグにより、システムが一部のジャーナルブロックをメタデータの更新待ちとしてマークします。suspend 呼び出し以降、更新はすでに適用されています。
ジャーナルが同じ物理ブロックに戻ると、ブロックは使用できなくなります。最終的に、ブロックが再び使用可能になるまで、すべての書き込みが停止します。VDO デバイスでの growPhysical、growLogical、および setWritePolicy 操作には、一時停止/再開サイクルが含まれているため、多数のジャーナル更新後にデバイスがフリーズする可能性があります。
VDO プールまたはその上の論理ボリュームのサイズを増やすか、LVM ツールで管理されている VDO デバイスで pvmove および lvchange 操作を使用すると、この問題が発生する可能性があります。
回避策として、一時停止/再開サイクルを含む方法で VDO デバイスの設定を変更し、VDO デバイスを完全にシャットダウンしてから、再度起動します。これにより、メモリー内の不適切な状態がクリアされ、ジャーナルブロックがリセットされます。その結果、デバイスはフリーズしなくなり、正常に動作します。
VDO ボリュームの起動中にソフトロックアップが原因でシステムがハングする
pv_mmu_ops 構造のカーネル ABI の破損 (修正中) により、カーネルバージョン 4.18.0-425.10.1.el8_7 (RHEL-8.7.0.2-BaseOS) を搭載した RHEL 8.7 システムで、Virtual Data Optimizer (VDO) ボリュームの起動時に、ソフトロックアップが原因でハングまたはカーネルパニックが発生します。この問題を回避するには、kernel-4.18.0-425.10.1.el8_7 で起動する前に有効な VDO ボリュームを無効にして、システムのハングを防ぐか、以前のバージョンのカーネル (4.18.0-425.3.1.el8) にダウングレードして、VDO 機能を保持します。
