29

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?

1

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.

| improve this answer | |
  • 14
    Your answer seems to suggest that lvmetad provides a service to the filesystem running on top of it that allows it to do journaling properly. But other sources just say that it caches information about LVM layout for the set of command lvm command line tools. Would be nice to support your version with some sources. – Pavel Šimerda Feb 4 '15 at 17:33
  • 8
    I have to echo @PavelŠimerda 's skepticism. The lvmetad manual says nothing about journaling. Not to mention that it would be a layering violation if LVM were to start to become journal aware (as that means it needs to be aware of which file systems are journaling and which are not, and it needs to know which file system lives on top of it). I also don't see any reason why having a file system's journal spread across multiple physical volumes would be a problem. That happens all the time with other technologies like RAID 0. – Dan Moulding May 13 '15 at 18:15
30

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.