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
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.