私は、長年使用してきた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ツールがその情報を取得するためにボリュームをスキャンする必要がないように、udevルールと連携してLVMの状態をキャッシュに保持します。私の小さな配列はこの種の機能の恩恵を受けられないというだけですか？どのような状況で使用したい/必要なのでしょうか？
回答:
lvmetadは、LVM用のメタデータキャッシングデーモンです。デーモンは、udevルール（lvmetadの使用中にLVMが正しく動作するためにインストールする必要があります）から通知を受け取ります。これらの通知により、lvmetadはシステムで使用可能なボリュームグループの最新の一貫したイメージを取得します。デフォルトでは、lvmetadは実行中であってもLVMによって使用されません。lvm.conf（5）を参照してください。
これを少し詳しく見ると、別の定義に値します。 ウィキペディアの状態：
ジャーナリングファイルシステムは、メインファイルシステムにコミットする前に、ジャーナル（通常はファイルシステムの専用領域にある循環ログ）に加えられる変更を追跡するファイルシステムです。システムがクラッシュした場合や停電が発生した場合、そのようなファイルシステムはより速くオンラインに戻り、破損する可能性が低くなります。
OPはすでに利点を理解しているため、LVMの詳細な説明は行いません。そのため、ジャーナリングが追加された理由のみを説明します。古いバージョンのLVMにはジャーナリングデーモンがありませんでした。つまり、システムがクラッシュした場合、使用できるジャーナルは物理ボリューム（ハードディスク）のみでした。論理ボリュームが複数の物理ボリュームにまたがる論理ボリュームグループの複数のエクステントにまたがる場合、問題が発生します。
半分ジャーナルトランザクションは1つの物理ボリューム上に存在し、残りの半分は別の物理ボリューム上に存在する場合は、トランザクションのジャーナルは、両方の物理ボリュームへの変更をコミットすることはできません、物理ボリュームは、彼らは、ボリューム・グループの一部であることを理解していないため、トランザクション理由ログは物理ボリュームにのみ存在します。
そこで、新しいデーモンが登場します。各物理ボリュームのジャーナルログの代わりに、LVMはジャーナルログを作成し、ボリュームグループ内にそのセクションを作成できます。これはジャーナリング専用に確保されます。そのようにすると、トランザクションログ全体を見つけて、ボリュームグループレベルで再生できます。
このリンクから：
通常、各LVMコマンドはディスクスキャンを発行して、関連するすべての物理ボリュームを見つけ、ボリュームグループメタデータを読み取ります。ただし、メタデータデーモンが実行されて有効になっている場合、この高価なスキャンをスキップできます。これにより、特に多くのディスクを持つシステムで、I / Oを大幅に節約し、LVM操作の完了に必要な時間を短縮できます。
したがって、起動パフォーマンスと複雑さの増加を犠牲にして、LVM管理とステータス操作のパフォーマンスを向上させるために実行します。システム内のディスクが多いほど、パフォーマンスの向上レベルは大きくなります。