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