長年使用してきたRAIDアレイの上でLVMを実行しているGentooサーバーがあります。最近、LVMを2.02.109にアップグレードし(以前のバージョンを思い出せない)、アップグレード中にメッセージを受け取りました。
* Make sure to enable lvmetad in /etc/lvm/lvm.conf if you want
* to enable lvm autoactivation and metadata caching.
use_lvmetad = 1
に/etc/lvm/lvm.conf
を設定することで有効にできることを理解しています。
しかし、なぜそのような機能が必要なのでしょうか?私の理解では、LVMツールがボリュームをスキャンしてその情報を取得する必要がないように、LVMの状態をキャッシュに保持するためにudevルールと連携しています。私の小さな配列がこの種の機能から利益を得ることができないだけですか?どのような状況で使用したい/必要がありますか?
lvmetad manページ から:
lvmetadはLVMのメタデータキャッシングデーモンです。デーモンはudevルールから通知を受け取ります(lvmetadが使用されているときにLVMが正しく機能するためには、このルールをインストールする必要があります)。これらの通知を通じて、lvmetadはシステムで利用可能なボリュームグループの最新かつ一貫したイメージを持っています。デフォルトでは、lvmetadは、実行中であっても、LVMによって使用されません。 lvm.conf(5)を参照してください。
これをもう少し詳しく見ると、別の定義に値します。 Wikipedia の状態:
ジャーナリングファイルシステムは、メインファイルシステムにコミットする前に、ジャーナル(通常はファイルシステムの専用領域にある循環ログ)で行われる変更を追跡するファイルシステムです。システムクラッシュや電源障害が発生した場合、そのようなファイルシステムはオンラインに戻るまでの時間が短く、破損する可能性が低くなります。
OPはすでにメリットを理解しているので、LVMの詳細な説明は省きます。そのため、ジャーナリングが追加された理由についてのみ説明します。古いバージョンのLVMにはジャーナリングデーモンがありませんでした。つまり、システムがクラッシュした場合、使用できるジャーナルは物理ボリューム(ハードディスク)だけでした。これにより、論理ボリュームが、複数の物理ボリュームにまたがる論理ボリュームグループの複数のエクステントにまたがる場合に問題が発生します。
ジャーナルトランザクションの半分が1つの物理ボリュームに存在し、残りの半分が別の物理ボリュームに存在する場合、トランザクションジャーナルは両方の物理ボリュームに変更をコミットできません。トランザクションログは物理ボリュームにのみ存在するため、ボリュームグループの一部。
そこで登場するのが、新しいデーモンです。これで、LVMは、各物理ボリュームのジャーナルログの代わりに、ジャーナルログを作成し、ボリュームグループ内にそのセクションを作成できます。これは、ジャーナリング専用に確保されています。その後、トランザクションログ全体を見つけて、ボリュームグループレベルで再生できます。
このリンク から:
通常、各LVMコマンドはディスクスキャンを発行して、関連するすべての物理ボリュームを見つけ、ボリュームグループのメタデータを読み取ります。ただし、メタデータデーモンが実行されて有効になっている場合は、この高価なスキャンをスキップできます。これにより、I/Oが大幅に節約され、特に多くのディスクを備えたシステムで、LVM操作の完了に必要な時間が短縮されます。
したがって、LVMの管理とステータス操作のパフォーマンスを向上させるためにそれを実行しますが、起動時のパフォーマンスと複雑さを犠牲にします。システム内のディスク数が多いほど、パフォーマンスの向上レベルは大きくなります。