LVM ボリュームのスタッキング

概要

ストレージ管理は複雑なタスクですが、LVM はボリュームをどのようにスタックするかという柔軟性を提供することで、この複雑さを助長しています。私たちは、LVM の間違った使い方を何度も目にしてきました。ユーザーは、特定のストレージスタックの可能性や代替案、システム全体の影響について認識していないことが多いと言えます。本書は、デバイスをどのように積み重ねるかのガイドラインと、システム全体における影響箇所のリストを提供します。この記事は、Red Hat 系列の GNU/Linux ディストリビューション (Red Hat Enterprise Linux、Fedora、CentOS) を念頭に置いて書かれていますが、他の GNU/Linux ディストリビューションにも同様に当てはめることができます。

下図は、ストレージスタックのレイアウトを示したものです。この記事では、各コンポーネントについて、ベストプラクティス、既知のバグや制限、潜在的な荒削りな部分 (上流、社内、サードパーティーのテストに焦点を当てる必要がある部分) をまとめています。 現在 LVM でサポートされていない dm-era、dm-stats、dm-verity は含まれません。

(local disk|SCSI|virtio|SAS|FC|iSCSI) [multipath] [partition table] [mdadm] LUKS, LVMや VDO (file system|database)

LVM スタック
LVM を単独で使用する場合、時には 再帰 (論理ボリュームを物理ボリュームとして使用すること) が必要になります。

LV_stack [再帰]

LVM と LUKS
LUKS を使用する場合、LVM より下の場合もあれば、上の場合もあり、中間の場合もありますが、LUKS ボリュームを別のボリュームの上には使用しないでください。

LVM、LUKS、VDO
VDO を使用する場合、LVM より下の場合もあれば、上の場合もあり、中間の場合もありますが、LUKS と使用する場合は、常に VDO より下になります。

目次

• システムに対する影響
• 論理ボリューム下のスタック
  • iSCSI、FC、FCoE、AoE、virtio...
  • マルチパス
    • ネットワークボンディング
  • パーティション
  • mdadm RAID
  • LUKS
  • 再帰: 別の論理ボリューム上の物理ボリューム
• VDO: 圧縮と重複排除
• 論理ボリュームスタック
  • マトリクス
  • X のプールメタデータ
  • X 上のプールデータ
  • タイプ X の外部オリジンを持つシン
  • タイプ X の論理ボリュームの古いスナップショット
  • X 上の Cache Pool メタデータ
  • X 上のキャッシュプールデータ
  • タイプ X のキャッシュ論理ボリューム
• その他部品
  • ファイルシステム
  • クラスター
  • /boot
  • root ファイルシステム (/)
  • インストール
• 謝意

システムに対する影響

スタッキングは、システムの起動とシャットダウン、スタックの起動/停止に影響します。もう一つの重要な要件は、デバイスの属性をスタックの上位レベルに伝搬させ、スタックの全レベルでブロックを適切に配置することです。

クラスター環境では、デバイスを排他的に開いているノードで常に操作できるようにロックする必要があります。これは、複数のトップレベルデバイス (シンプール) を持つ可能性があるスタックデバイスの場合、プールとすべてのシンボリュームが常に 1 つのノードのみで排他的に開かれることを保証するために重要です。

影響を受ける地域の詳細なリスト:

• 起動/停止
  • 特定のスタック上の root ファイルシステムでの起動/シャットダウン
  • 特定のスタックにマウントされた他のファイルシステムでのシャットダウン
  • サービスが正しい順序で開始/停止することを確認する
  • ボリュームが udev ルールによって適切にアクティベートされていることを確認する
• dracut
  • 新しい initramfs の生成とリブート
• anaconda
  • スタックが存在する状態での新しい論理ボリュームへのインストール
  • 既存のボリュームグループ内の新しい論理ボリュームへのインストール
  • 既存の論理ボリュームへのインストール
• kdump
• 属性伝搬
  • セグメントサイズとアライメント
  • discard
• pvmove
  • pvmove はスタックにミラーを挿入
• vgsplit
  • 論理ボリュームがボリュームグループ間で正しく分割される
• ミラーおよび RAID 固有の操作
  • ミラーおよび RAID 論理ボリュームのスプリットおよびマージレグ
  • ミラーと RAID の論理ボリュームのアップ/ダウンコンバート
• イベント処理
  • スナップショットおよびシンプールデータとメタデータの論理ボリュームの自動サイズ変更
  • ミラーおよび RAID 論理ボリュームの欠落した脚の自動修復
• cluster
  • 他のノードから排他的にアクティブ化されたデバイス (スタック内の任意の場所) に対する操作
• performance
  • 旧来のスナップショットを除き、大幅な性能低下なし

論理ボリューム下のスタック

一般的なルールは、以下のとおりです。

• ストライピング、ミラーリング、暗号化は一度だけ行います。つまり、mdadm や LVM ベースの RAIDn ボリュームをミラーリングしようとしないでください。
• 冗長性と暗号化を両立させる場合、ミラーリングデータの上に LUKS を使用する。同じデータを複数の鍵で暗号化すると、暗号解析の対象となる可能性が高くなり、また CPU サイクルの消費も多くなります。

iSCSI、FC、FCoE、AoE、virtio...{#physical}

サポート対象。これらは、その上で許可されていることとは無関係です。

マルチパス

サポート対象。上記で許可されていることとは無関係です。

マルチパスは、存在する場合、常にスタックの一番下にあります (物理レベル (FC、iSCSI、SAS) のすぐ上)。

ネットワークボンディング

サポート対象。iSCSI/FCoE では、ネットワークボンディングは dm-multipath の代替となります。dm-multipath が望ましいが、ボンディングもサポートされています。

パーティション

サポート対象。混合環境を除いて除外することをお勧めします。

以前は、ツールが LVM で使用されるディスクを識別できないことを補うために、8e (LVM) パーティションを使用することが推奨されていました。GNU/Linux の世界ではもう必要ないかもしれませんが、特に Windows マシンがブロックデバイスをフリーデバイスとして扱わないようにアクセスするような混在環境では、今でもこの方法が適用されます。

推奨事項:

• 論理ボリュームを分割しないでください。(VM が使用する論理ボリュームは、プロビジョニング時にパーティショニングされます。これらは通常、ホスト上では起動しません)。
  
• MD を分割しないでください。
  
• 1 つのボリュームグループで、1 つのデバイスに複数のパーティションを使用することは避けてください。特にミラーボリュームや RAID ボリュームを使用している場合、これらは独立したデバイスとして扱われるため、これは危険なことです。

その他の用途
その他、パーティションがまだ必要なユースケース (範囲外) があります。

• リムーバブル (USB) デバイス (LVM を認識しているマシンで使用される可能性が高いため)
• ブートパーティション
• デュアルブートノート PC

mdadm RAID

サポート対象。

LVM RAID にはまだない MD の機能があります。Mdadm は、そのままとなります。

LUKS

サポート対象。物理ボリューム全体の暗号化が推奨されます。論理ボリュームごとの暗号化は注意して使用してください。

オプションの dm-crypt デバイスが存在する場合は、物理ボリュームの下 (暗号化されたディスクまたはパーティション) または最上位の論理ボリューム (暗号化されたファイルシステム) の上にあります。データレイアウトに関する情報が公開されないため、物理ボリューム全体を暗号化する方が安全です。

注記: 冗長性が必要な場合は、ルールとして MD RAID ボリュームの上に LUKS を配置します。物理ボリュームは暗号化デバイスに置くことができます。

既知の問題:

• LUKS と破棄
  

再帰: 別の論理ボリューム上の物理ボリューム

サポート対象ですが、一般的なルールとしてはサポート対象外となります。他に解決策がない場合は再帰を使用します。

既知の制限事項 (バグとはみなされない)。

• 仮想マシンイメージのスナップショットのように、同じボリュームグループ名や LVM、ファイルシステムの UUID が使用されている場合、アクティベーションに問題があることが知られています。
• このようなスタッキングは、外側の論理ボリュームによって制限される内側の論理ボリュームを成長させる際に障壁となります。
• 非クラスターホスト上でネストされたクラスターボリュームグループをアクティブにする場合、クラスターロックはサポートされません。

このようなスタックで動作するように意図されたツールは、たとえば、ボリュームグループの名前を変更したり、ゲストでクラスターボリュームグループが非アクティブであることを確認する方法を提供するなどして、これらの問題を自分で処理する必要があります。

再帰を含むユースケースについて LVM 開発者と話し合い、必要な機能をサポートする他の方法があるかどうかを確認することをお勧めします。

既知のユースケース

• ホスト上の論理ボリュームに基づいた VM イメージのゲストファイルシステムのマウント。

  回避策: 別のゲストを使用してデータを操作してください。ホスト上の VM からファイルシステムをマウントすることは、セキュリティー上のリスクがあることに留意してください。

• VDO ボリュームの場合は、上下に LVM があることが最適となります。

  VDO の下の LVM は、RAID、キャッシュ、または複数の物理ボリュームからスペースを集約するために使用することができます。

  VDO の上の LVM は、同じ VDO デバイスを共有する複数のリニアボリュームに使用できます。シンデータは別の適切な候補です。3 番目のユーザーは、場合によっては圧縮を避けるために、VDO ボリュームをキャッシュすることができます。

  詳細は、サポート対象の LV スタックの VDO と マトリクス を参照してください。

VDO - 圧縮と重複排除

サポート対象。

VDO ボリュームはまだ LVM2 と統合されていません。したがって、VDO ボリュームは、VDO ボリュームの上と下にある LVM と使用することが望ましい場合があります。

既知の問題:

• VDO ボリュームはシンプール同様、仮想サイズが物理サイズより大きいオーバープロビジョニングによって、VDO の上の FS にはまだスペースがあるように見えても、物理スペースが枯渇している可能性があるという問題を抱えています。
• VDO はまだ LVM と統合されていないため、空き容量を監視し、物理サイズの拡張を手動で処理する必要があります。

VDO の下にスタック

1. 物理的な [multipth] [partition] [mdadm]
2. (1) の上の LUKS - フルディスク暗号化
3. 上にオプションのキャッシュがある RAID、ミラー、ストライプ、またはリニア LV。VDO の下の LV を使用すると、LVM の通常の利点があります。
   • VDO ボリュームの拡張
   • 複数のデバイスにまたがる VDO ボリューム
4. (3) の上の LUKS - 特に RAID を使用する場合

LV は、バッキングデバイスとして適していません。

• シンボリューム - 現時点では、アクティブな VDO ボリュームの一貫したスナップショットを取得することはできません (シンボリュームの上の LUKS ボリュームがある場合と同じです)。
• 古いスナップショット、またはスナップショット付きのボリューム - 上記と同じですが、この他に深刻なパフォーマンス上の打撃があります。

バッキングデバイスとしての VDO の使用

VDO を PV として使用する場合、VDO が完全に適合するデバイスはほとんどありません。

• tdata (シンプールのデータデバイス) の下:
  • これが最適な場合があります。これにより、複数のシンボリューム間で追加の冗長性が排除され、圧縮によってデータ量がさらに削減されます。
  • リスク: サイズを変更してください! dmeventd は VDO デバイス上の tdata のサイズ変更を処理できません。そのため、VG と VDO デバイスに十分な空き容量があることを確認してください。
• 複数のリニアボリュームの下:
  • VDO 自体は複数ボリュームを許可していないため、1 台の VDO を複数のデバイスで共有し、バッキングデバイスとして使用する場合は、このオプションを使用します。

LV がデータを共有している場合、VDO は複数のスナップショットなどにも適合します。

圧縮または重複排除がボトルネックになっている場合は、VDO の上で corig を使用してキャッシュを使用し、cdata に高速なドライブを使用することをお勧めします。

VDO の上での使用に適していないデバイス

• VDO の上で LUKS を 使用しない でください - 暗号化されたデータは圧縮も重複排除も行いません。
• キャッシュまたはシンメタデータの下で VDO を 使用しない でください。これらは疑似ランダムであり、適切に重複排除されません。
• RAID、ストライプ、またはミラーボリューム:
  • RAID1 とミラーはデータを複製するため、ミラー/RAID1 レッグとして VDO を使用すると、より多くの重複作業を意味します。
  • stripe と RAID0 は複数のディスクにデータを分散させるので、VDO は重複をより少なく発見することができます。
  • RAID{4,5,6} は、書き込まれるデータ量を増やし、複数のディスクにデータを分散します。

論理ボリュームスタック

古いバージョンの LVM では限られた数の可能性しか提供されませんでしたが、最近のバージョンでは、より多くの組み合わせを持つ新しいターゲットが導入されました。

古いバージョン:

(Linear | Stripe | RAID | Mirror) | [Snapshot]

最新バージョン

スナップショットおよびミラーを除く上記のいずれかにデータまたはメタデータをプールし、キャッシュします。
スナップショット以外の上記のいずれかのシンスナップショット。
最上位の論理ボリューム (サポート対象外のミラーとスナップショット、および計画されたシンボリュームとキャッシュボリュームを除く) をキャッシュするか、シンプールのデータをキャッシュします。

古いスタイルのスナップショット
古いスタイルのスナップショット - ターミナルストップ。これらの上では何もサポートされません。

短期間のスナップショット (バックアップ作成など) のみの限定的なサポート。長期間、特に大きな変更の場合は、シンスナップショットを使用します。

ミラー または RAID、あるいは両方?
ミラーは、既存のユースケースで引き続きサポートされます。

既存の問題により、ミラーの上にスタックされたデバイスのサポートは延長されません。

現在、ミラーには以下の不可欠な用途があります。

• クラスター内の共有アクティベーション。RAID をクラスター内の共有モードで有効にすることはできません。
• 内部でミラーを使用する pvmove。

両ターゲットへの対応の必要性については、今後、改めて検討する予定です。

ストライプ柄のミラー
ストライプのミラーを使用することもできますが (lvcreate -m N -i M)、これはストライプのミラーを作成し、ドライブが故障した場合にストライプ全体を失うと考えられるため、最適とは言えません。可能であれば RAID10 で代用してください。

シンスナップショットと旧スナップショットの比較
古いスナップショットを最小限に制限します。サポートされているのは、コピーおよび削除する短期間のスナップショットのみです。巨大または多数のスナップショットによるパフォーマンスの低下は、既知の制限です。大規模な長期または多数のスナップショットが必要な場合は、シンスナップショットを使用します。

完全なスナップショットやプールを拡張するための監視としきい値を有効にすることを忘れないでください。

外部オリジンを持つスナップショットとシンスナップショットの違いの 1 つは、スナップショットはオリジンをまったく変更しないのに対し、シンスナップショットを作成すると、オリジンが外部オリジンを持つシンボリュームに変換されることです。現状では、変換後に原点に書き込まれたデータを保持したまま、純粋な原点に戻る方法はありません。

スナップショットと外部オリジンを使用したシンスナップショットのもう 1 つの違いは、スナップショットがいっぱいになり、時間が延長されない場合、無効とマークされますが、オリジン論理ボリュームは完全に機能し続けることです。シンプールがいっぱいになると、エラーを返すか書き込みをキューに入れるように設定できますが、タイムアウトした操作の場合、データが破損する可能性があります。詳細については、lvmthin (7) man ページ を参照してください。

マトリクス

次の表は、特定のタイプ (Y) の論理ボリュームが別の論理ボリュームで特定のロール (X) を果たす、スタッカー (またはレイヤード) ボリュームのサポートされるケースをまとめたものです。これには、まだ LVM と統合されていない VDO ボリュームも含まれますが、マトリクスビューは、サポートされている組み合わせを表示するのに適しています。

X/Y	X/Linear	X/Stripe	X/Mirror	X/RAIDn	X/シンボリューム	X/旧スナップショット	X/キャッシュボリューム	X/VDO ボリューム
プールメタ/Y	OK	OK	-	Preferred	-	-	-	bad
プールデータ/Y	OK	OK	-	OK	-	-	OK !	OK
シンスナップショット/Y の外部オリジン	OK	OK	OK	OK	OK	-	-	OK
古いスナップショット/Y のオリジン	OK	OK	OK	OK	OK	-	-	OK
キャッシュデータ/Y	OK	OK	-	OK	-	-	-	avoid
キャッシュメタ/Y	OK	OK	-	OK	-	-	-	bad
キャッシュオリジン/Y	OK	OK	-	OK	MAYBE	-	TODO	OK
VDO/Y	OK	OK	OK	OK	-	-	OK	bad

凡例

X/Y: タイプ Y の論理ボリュームは、別の論理ボリュームでロール X を持っています。

• 動作する:
  • 動作し、Red Hat によってサポートされています (OK)
  • 動作し、サポートされまずが、推奨されません (avoid)
  • 動作し、サポートが計画されています (WIP)
  • 動作しますが、サポート対象外の機能 (bad)
• 動作しない:
  • 動作しないが、サポートが計画されている (TODO)
  • 動作しせず、未定 (MAYBE)
  • 動作せず、サポートの予定もない (-)
• 既知の問題点 (!)

X のプールメタデータ

プールメタデータは、データの安全性とスピードが重要です。最速のドライブには、リニアまたは RAID1 を使用します。

• メタデータボリュームが破損すると、一部のファイルだけでなく、すべてのデータが失われる可能性があります。
• 比較的小さなボリュームですが、アクセス頻度が高いです。

別の論理ボリュームの上にシンプールを作成し、管理する方法については lvmthin (7) man ページで説明しています。

Liner/Stripe 上のプールメタデータ

サポート対象。ディスクが 1 枚だけなら、これは普通のユースケースです。冗長性を持たせたボリュームを強く推奨します。

ミラー上のプールメタデータ

サポート対象外詳細については、バグ 919604 - ミラーボリュームにスタックされたシンプールがデバイス障害からの回復に失敗するを参照してください。

RAIDn 上のプールメタデータ

RAID1 推奨。

速度は安全性と同様に重要であるため、RAID1 とおそらく RAID10 は、使用する意味のある唯一の 2 つの RAID レベルです。RAID10 を使用する利点は測定されていません。

また、メタデータのサイズは 16GiB に制限されているため、パフォーマンスを犠牲にして RAID6 などを使用して数ギガバイトを節約することは適切な決定ではありません。

別の論理ボリュームの上にシンプールを作成し、管理する方法については lvmthin (7) man ページで説明しています。

シンボリューム上のプールメタデータ

サポート対象外

古いスナップショット上のプールメタデータ

サポート対象外

キャッシュ論理ボリューム上のプールメタデータ

サポート対象外

X 上のプールデータ

単なるデータです。データとして扱ってください。ただし、シンスナップショットには冗長性がないため、複数のスナップショット間で共有されているセクターを失うと、すべてのスナップショットで失われたセクターが保持していたデータが失われることに注意してください。

Linear/Stripe 上のプールデータ

サポート対象。これは通常/典型的なユースケースです。

ミラー上のプールデータ

サポート対象外詳細については、バグ 919604 - ミラーボリュームにスタックされたシンプールがデバイス障害からの回復に失敗するを参照してください。

RAIDn 上のプールデータ

サポート対象。

シンボリューム上のプールデータ

サポート対象外興味深いユースケースがあれば再考されるかもしれません。

ユースケース: シンプロビジョニング用の大きなチャンクを下部に配置し、スナップショット用の小さなチャンクを上部に配置したプールを使用します。これは、基本イメージ用の大きなチャンクを持つプールとして実装し、小さなチャンクを持つ 2 番目のプールにシンスナップショットを作成することができます。

古いスタイルのスナップショット上のプールデータ

サポート対象外

キャッシュ論理ボリューム上のプールデータ

サポート対象。 (v2.02.125)

既知の問題:

• キャッシュボリュームのサイズ変更は現在機能していません。プールがいっぱいになった場合、プールを拡張できませんでした。
• プールをバッキングするキャッシュボリュームを非キャッシュに戻すことはできません。メタデータの編集に頼る必要があります。

タイプ X の外部オリジンを持つシン

Linear/Stripe タイプの外部オリジンを持つシン

サポート対象。

Mirror/RAID タイプの外部オリジンを持つシン

サポート対象。シンデータ自体がミラーリングされていない場合は、冗長性を失わないように注意してください。シンデータを含む物理ボリュームに障害が発生すると、元の論理ボリュームへの書き込みが失われる可能性があります。

thin-volume タイプの外部オリジンを持つシン

サポート対象。(シンプール間で循環依存関係を作成する場合を除き、深さは無制限です。)

旧式のスナップショットタイプの外部オリジン持つシン

サポート対象外

キャッシュ論理ボリュームタイプの外部オリジンを持つシン

サポート対象外

タイプ X の論理ボリュームの古いスナップショット

短期間のスナップショット (バックアップ作成など) のみの限定的なサポート。長期間、特に大きな変更の場合は、シンスナップショットを使用します。

シンスナップショットに対する優位性

• より小さなチャンクサイズも許容されます。これには代償が伴い、スナップショットの書き込みパフォーマンスの低下は既知の問題です。
• サイズ制限の可能性シンスナップショットのサイズを制限できるのは、使用するシンプールにスナップショットが 1 つだけある場合のみです。
• オリジンは書き込み可能なままとなります。

Linear/Stripe の古いスナップショット

サポート対象。

ミラー論理ボリュームの古いスナップショット

サポート対象。

RAID 論理ボリュームの古いスナップショット

サポート対象 (データからバックアップを作成するときのスナップショット)。古いスナップショット (冗長性のないもの) を長期間使用することは考えにくいです。

古いスナップショット (snapshots) の古いスナップショット (snapshot)

サポート対象外

キャッシュ論理ボリュームの古いスナップショット

サポート対象外

Q: バックアップ用のプールデータとメタデータの古いスナップショットはありますか?{#s-pd}

post 7.0

X 上のキャッシュプールメタデータ

メタデータでは、データの安全性と速度が重要です。最速のドライブで RAID1 を使用します。

ライトバック を使用すると、データまたはメタデータボリュームが失われるため、キャッシュされた論理ボリュームのデータが破損する可能性があります。

これは比較的小さいボリュームですが、頻繁にアクセスされます。

別の論理ボリュームの上にキャッシュプールを作成および管理する方法については、lvmcache (7) man ページで説明されています。

Liner/Stripe のキャッシュプールメタデータ

サポート対象。ディスクが 1 枚だけなら、これは普通のユースケースです。特に ライトバック キャッシュには、冗長性のあるボリュームをお勧めします。

ミラー上のキャッシュプールメタデータ

サポート対象外

RAID1 上の Cache Pool メタデータ

推奨されます。

速度は安全性と同様に重要であるため、RAID1 とおそらく RAID10 は、使用する意味のある唯一の 2 つの RAID レベルです。RAID10 を使用する利点は測定されていません。

また、メタデータのサイズは 16GiB に制限されているため、パフォーマンスを犠牲にして RAID6 などを使用して数ギガバイトを節約することは適切な決定ではありません。

シンボリューム上のキャッシュプールメタデータ

サポート対象外

古いスナップショットのキャッシュプールメタデータ

サポート対象外

キャッシュ論理ボリューム上のキャッシュプールメタデータ

サポート対象外

X 上のキャッシュプールデータ

単なるデータです。データとして扱ってください。

別の論理ボリュームの上にキャッシュプールを作成および管理する方法については、lvmcache (7) man ページで説明されています。

Linear/Stripe のキャッシュプールデータ

サポート対象 - 通常/典型的なユースケース

ミラー上のキャッシュプールデータ

サポート対象外

RAIDn 上のキャッシュプールデータ

サポート対象。RAID1 または RAID10 を希望。他の RAID レベルでは、キャッシュが遅くなります。

シンボリューム上のキャッシュプールデータ

サポート対象外

古いスタイルのスナップショットのキャッシュプールデータ

サポート対象外

キャッシュ論理ボリューム上のキャッシュプールデータ

サポート対象外

タイプ X のキャッシュ論理ボリューム

既知の問題 (英語)

• キャッシュの論理ボリュームのサイズを変更することはできません。
  

Linear/Stripe タイプの論理ボリュームのキャッシング

サポート対象。

ミラータイプの論理ボリュームのキャッシング

サポート対象外

RAID タイプのキャッシュ論理ボリューム

サポート対象。速度よりもデータの整合性が優先される場合は、ライトバック を避けてください。メタデータが破損している場合は、データが破損する可能性が高くなります。データまたはメタデータドライブが破損した場合、自動キャッシュ解除は実装されていないため、可用性が重要な場合はミラーリングを使用してください。

シンボリュームタイプの論理ボリュームのキャッシング

サポート対象外

古い形式のスナップショットタイプの論理ボリュームのキャッシング

サポート対象外

タイプキャッシュ論理ボリュームのキャッシング論理ボリューム

サポート対象外将来的に計画されている多層キャッシュ。

その他の部品

ファイルシステム

サポート対象。LVM は通常のブロックデバイスを提供し、サポート対象のファイルシステムはすべて論理ボリューム上でサポートされます。

クラスター

完全にクラスター対応のターゲットが使用できない場合は、排他的なアクティブ化が許可されます。機能しないものはすべてバグと見なされます。

ボリュームの共有は、Linear/Stripe およびミラーターゲットに限定されます。

/boot

RHEL7 ではサポート対象外です。論理ボリュームでの起動はサポート対象外ですが、リニアおよびミラー化された論理ボリュームで動作することが知られています。

これは RAID1 でテストする必要があります。これらはまったくテストされていないため、機能する場合でも他のタイプは避けてください。

root ファイルシステム (/)

目標: サポート対象のすべてのスタックが root ファイルシステムで機能する必要があります。機能しないものはすべてバグと見なされます。

インストール

謝意

コメントやその他のアドバイスを寄せてくださったみなさま、特に、Jon Brassow、Tom Coughlan、Zdenek Kabelac、Alasdair G. Kergon (アルファベット順) に感謝申し上げます。