mjhjmtu

I have a Gentoo server with LVM running on top of a RAID array that I have been using for a number of years. Recently I upgraded LVM to 2.02.109 (don't recall what version it was before) and received a message while upgrading:

* Make sure to enable lvmetad in /etc/lvm/lvm.conf if you want
* to enable lvm autoactivation and metadata caching.

I understand that I can enable it by setting use_lvmetad = 1 in /etc/lvm/lvm.conf.

But why would I need such a feature? My understanding is that it works with udev rules to keep LVM state in a cache so that LVM tools don't need to scan volumes for obtain that information. Is it just that my little array can't benefit from this kind of feature? Under what circumstances might I want/need to use it?

Description

From the lvmetad man page:

lvmetad is a metadata caching daemon for LVM. The daemon receives
notifications from udev rules (which must be installed for LVM to work
correctly when lvmetad is in use). Through these notifications,
lvmetad has an up-to-date and consistent image of the volume groups
available in the system. By default, lvmetad, even if running, is not
used by LVM. See lvm.conf(5).

Looking at this a little closer merits another definition. Wikipedia states:

A journaling file system is a file system that keeps track of the
changes that will be made in a journal (usually a circular log in a
dedicated area of the file system) before committing them to the main
file system. In the event of a system crash or power failure, such
file systems are quicker to bring back online and less likely to
become corrupted.

Reasoning

I won't go into a detailed explanation of LVM, as the OP already understands the benefits. As such, I'll only explain why journaling was added. Older versions of LVM had no journaling daemon, meaning that if the system crashed the only journal that could be used was on the physical volume (hard disk). That creates a problem when the logical volume spans multiple extents on Logical Volume Groups that span multiple physical volumes.

If half a journal transaction exists on one physical volume and the other half exists on another physical volume, the transactional journal cannot commit changes to both physical volumes, because the physical volumes do not understand that they are part of a volume group, because the transaction log only exists in the physical volume.

That's where the new daemon comes into play. Now instead of a journal log for each physical volume, LVM can create a journal log and create a section for it in the volume group, that is set aside for the journaling only. After doing so, the entire transaction log can be found and replayed at the Volume Group level.

From this link:

Normally, each LVM command issues a disk scan to find all relevant physical volumes and to read volume group metadata. However, if the metadata daemon is running and enabled, this expensive scan can be skipped ...
This can save a significant amount of I/O and reduce the time required to complete LVM operations, particularly on systems with many disks.

So you would run it for increased performance of LVM management and status operations, at the cost of startup performance and increased complexity. The level of performance increase is larger when there are more disks in the system.