The basic architecture of Linux LVM and prospects for data recovery

data organization, advantages and disadvantages and possibility of data recovery from linux logical volume manager

Logical Volume Manager is a disk management option which enables spanning partitions across multiple physical devices and allows for easy partition resizing. It has been included into the Linux kernel since 1999 and relying on its device mapper framework, is now supported by every modern distribution. Providing enhanced flexibility, this storage configuration method is widely utilized by system administrators for various server, NAS and SAN systems running Linux as the means of organizing storage space with maximum efficiency. Although this technology is particularly beneficial in a corporate setting, with the considerably increasing storage needs of home users, it is getting commonly employed on desktop PCs as well while more and more Linux installations enable this component by default.

Let’s go through the key concepts of Logical Volume Manager, its basic architecture, strengths and shortcomings.


LVM basics

Logical Volume Manager serves a layer of abstraction between the operating system and the physical disks it makes use of. However, in contrast to the traditional disk management model, in which each storage device is represented by a single or several partitions, logical volumes in LVM are not tied this way to particular digital media: one volume can spread over many drives and be resized or removed any time on the fly.

The fundamental storage structures it relies on include:

  • Physical volumes. Physical volumes are essentially conventional disk partitions or whole storage devices like internal or external hard disk drives, software- or hardware-based RAID systems, etc. One or several physical volumes comprise a volume group.
  • Volume groups. A volume group can be compared to a virtual partition and is composed of one or more physical volumes forming a single storage pool available for the system. At least one physical volume is required to create a volume group while other ones can be added later to increase capacity. When a volume group is created, it is automatically divided into storage chunks of the same fixed size which are referred to as physical extents.
  • Physical extents. A physical extent is the smallest chunk into which physical volumes are cleaved (the default size is 4 MiB). Physical extents can be described as tiny parts of physical storage which can be allocated to any logical volume on demand.
  • Logical volumes. A logical volume is a part of a volume group and consists of physical extents. Similar to a standard partition in a non-LVM managed system, it has a mount point and a file system, such as Ext4 or XFS, but in contrast to it, can be created, removed or resized utilizing free space in the volume group it belongs to. This is achieved by copying and reorganizing available physical extents whilst running.

How is data organized?

To organize and keep track of its internal structures LVM uses physical volume labels and metadata.

A physical volume label carries the UUID (universally unique identifier) of the corresponding physical volume, its size in bytes, the list of data area and metadata area locations. This label is usually written to the second 512-byte sector on the disk.

Metadata is stored in ASCII and holds all configuration details of each volume group. It is written to a special metadata area within every physical volume forming the corresponding volume group. New metadata is usually added to the end of the old metadata and after that the pointer to the metadata start gets updated.

Besides the information about how and when the volume group was created, its name, unique id, version, properties, the size of an extent, etc., metadata embraces:

  • a list of physical volumes it consists of together with their UUIDs, properties, number of extents and the offset to the start of the first extent in sectors;
  • a list of logical volumes, each item of which consists of a list of logical volume segments with mapping to the list of physical volume segments.

As Logical Volume Manager stores this information directly on disk sectors instead of separate files, the disks remain readable by it after Linux reinstall or in other cases when the root file system is wiped.

Advantages and disadvantages

LVM offers noteworthy benefits in terms of scalability and storage space management:

  • Dynamic resizing of volumes

    Instead of setting up partitions of a fixed size at the very beginning, the user can leave unpartitioned storage space and then add it to a certain mounted partition when it gets filled up. There is no need to back up all the data and reformat the storage.

  • Spreading one volume over multiple disks

    With Logical Volume Manager any valid number of physical disks can be assigned to the same logical volume which will be recognized by the system as a single partition.

  • Live capacity expansion

    Any valid number of physical storage devices of any size can be added to a volume group to expand its capacity without downtime. For example, new drives can be added to the server to increase its capabilities while the system will remain online.

  • Thin Provisioning

    LVM gives the possibility to apportion more storage capacity to logical volumes than in fact is available in a volume group. In contrast to a set of partitions with a fixed size, a special thin pool can be created within a volume group, which will provide room for all thin logical volumes bound to it. However, none of the thin volumes reserves a part or the whole present space for individual needs until some data is actually written to consume this space. Hence, each of the thin volumes is assigned a virtual size which may exceed the amount of free space on the physical storage.

  • Support of snapshots

    LVM supports snapshotting which allow creating a backup copy of the file system at a certain point of time.

Nevertheless, acting as an additional layer of abstraction between the OS and the disks it operates, it brings about extra complexity, particularity at the point of data loss:

  • Unsafe volume shrinking

    Attempts to reduce the size of a logical volume or reallocate storage space used by it to another volume commonly result in corruption and data loss, especially when the file system is full or shrinking is not supported by this file system type.

  • No dual-booting

    Other operating systems do not recognize this technology, therefore, its partitions cannot be accessed from Windows or macOS. For a dual boot environment a standard non-LVM partition is to be created.

  • Risk of overwriting

    By multi-booting other operating systems may fail to detect this volume manager and consider the disk empty which bears the possibility of overwriting.

  • No default fault-tolerance

    The loss or removal of a disk from LVM will leave the entire storage together with all the files inaccessible while the probability of such a failure increases by every added disk.

  • High likelihood of metadata corruption

    LVM provides the possibility to enlarge a logical volume and its file system when it is mounted and active. However, any possible interruption of this procedure caused by a power outage, software or hardware malfunction or simple user mistake can prevent the correct metadata to be written completely and render the entire storage unusable.

Possibility of data recovery

The Professional and RAID editions of UFS Explorer are able to read metadata on the LVM disks and automatically reconstruct such a volume in the virtual mode. The virtual storage will be added to the list of connected storages in the left panel of the main tab for further data recovery. At the same time, access will be provided to the volume components as well.

However, severe damage or total overwriting of LVM metadata may pose a big challenge for data recovery: more often than not data in LVM is stored on non-contiguous sectors, especially when there are multiple physical volumes in a volume group and volumes get resized many times.

In some cases, metadata can be recovered with the help of a backup copy which are stored in /etc/lvm/backup. The file name will match the name of the volume group.

If you need to recover data from an LVM volume, please rely on the instruction.

Last update: August 6, 2022

If you liked this article, you can share it on social media: