LVM: storage that moves along

LVM (Logical Volume Manager) is not a file system. It is a layer between your physical disks and your file system that decouples disks and partitions from their fixed size. This article explains how that layer works, what you can do with it, and where the limits lie. For administrators who want to manage storage that grows with demand — not with the original partition layout.

Requirements

• A Linux system with LVM support. All mainstream distributions have this on board by default: RHEL 8 and 9, Debian 10-12, Ubuntu 20.04-24.04.
• `root` access or sudo rights.
• A free disk or partition to practice on. Working on a system where data already resides is not a good start.
• The package `lvm2` (for LVM itself) and a file system of your choice — `ext4` is the safest to start with.

The three layers

LVM has three levels, and it helps to keep that hierarchy in mind before you start typing commands.

Physical Volumes (PVs) are the raw building blocks: entire disks like `/dev/sdb`, or partitions like `/dev/sdb1`. You initialize them with `pvcreate`, which puts LVM metadata on them.

Volume Groups (VGs) collect one or more PVs into a single pool. A VG is not storage you can use directly — it is the pantry from which you later carve volumes. Two 1 TB disks together become a 2 TB VG, or a 1.5 TB VG if you reserve the rest.

Logical Volumes (LVs) are what you ultimately format and mount. An LV looks like a partition but is not tied to one physical disk. It can use space from multiple disks at once, and you can enlarge or shrink it while the system is running — provided the file system allows it.

This abstraction is the core. A classic partition is a fixed piece of one disk; an LV is a flexible piece from a shared pool.

Why LVM, and what it costs

LVM exists because static partitions solve a problem you only encounter when it is too late. You cannot easily enlarge a partition with space from another partition — the partitions lie next to each other on the same disk, and you would have to shift them all to make room in between.

LVM solves that by creating an intermediate layer. But that layer costs something: you add an abstraction layer between hardware and file system. That means extra metadata, an extra step at boot (LVM must activate its volumes), and an extra place where something can go wrong. On a system with one disk and a fixed workload, it is honestly unnecessary. On a server where storage needs change — databases that grow, log partitions that fill up, backups that temporarily demand a lot of space — the flexibility pays for itself.

The commands

The standard allocation unit within a VG is the extent, by default 4 MB in most implementations. Everything you do with LVM revolves around assigning extents to volumes. This is the practical core.

1. Create a Physical Volume

pvcreate /dev/sdb

This puts LVM metadata on `/dev/sdb`. The disk is now a PV. Check with `pvs` or `pvdisplay` that LVM recognizes it. Note: this does not wipe the disk, but it does prepare it for LVM management — do not put existing data on it that you still need.

2. Create a Volume Group

vgcreate vg_data /dev/sdb

This combines the PV into a VG named `vg_data`. You can later add more disks with `vgextend vg_data /dev/sdc`, which grows the pool. The advantage of this becomes clear in step 3.

3. Create a Logical Volume

lvcreate -L 100G -n lv_home vg_data

This creates an LV of 100 GB named `lv_home` from the pool `vg_data`. The volume appears as `/dev/vg_data/lv_home`. You can now put a file system on it and mount it, just like a regular partition.

The real power lies in what comes next. Suppose 100 GB turns out not to be enough.

4. Extend the volume

lvextend -L +50G /dev/vg_data/lv_home
resize2fs /dev/vg_data/lv_home

The first line enlarges the LV by 50 GB — the system does not need to reboot. The second line lets `ext4` know there is more space. With XFS, you use `xfs_growfs` instead of `resize2fs`. The volume remains mounted; this can happen live, while data is on it.

This is why LVM is so valued in production environments: a database that grows unexpectedly, a log partition that fills up — you resolve it without downtime, without switching to a larger disk.

5. Shrink a volume — with care

umount /dev/vg_data/lv_home
e2fsck -f /dev/vg_data/lv_home
resize2fs /dev/vg_data/lv_home 120G
lvreduce -L 120G /dev/vg_data/lv_home
mount /dev/vg_data/lv_home /home

Shrinking is the operation where LVM partly loses its reputation for flexibility. The volume must first be unmounted — shrinking a mounted volume is not possible. Then you must first shrink the file system itself (`resize2fs` to 120 GB), and only then the LV (`lvreduce` to 120 GB). In that order, and not the other way around: if you shrink the LV first, you will damage the file system.

More importantly: not every filesystem cooperates. `ext4` supports shrinking, XFS does not. For XFS, shrinking is simply not an option — you would have to copy the volume to a smaller new volume. This is not a bug, but a design choice of XFS, and it is the reason you need to know in advance which filesystem you need.

6. Add a disk to the pool

vgextend vg_data /dev/sdc
lvextend -l +100%FREE /dev/vg_data/lv_home
resize2fs /dev/vg_data/lv_home

Adding a new physical disk is the core of LVM's scalability. You extend the VG with a new PV, then enlarge the LV with all free space (`-l +100%FREE` uses all remaining extents). The LV can now be spread across two physical disks — something that is impossible with classic partitions.

Verification

Check whether everything works correctly:

pvs
vgs
lvs
df -h /home

`pvs` shows you physical volumes, `vgs` the volume groups with their total and free space, `lvs` the logical volumes. `df -h` confirms that the filesystem sees the new size. If the numbers from `lvs` and `df -h` do not match, the filesystem has not been adjusted yet — then run `resize2fs` again.

Common problems

I do not see my LV after a reboot. LVM normally activates volumes automatically during boot. If that does not happen, activate them manually:

vgchange -ay

`resize2fs` complains that the filesystem is not clean. First run `e2fsck -f /dev/vg_data/lv_home` before shrinking or enlarging the filesystem. This checks and repairs the metadata — skipping it is asking for trouble.

I want to shrink XFS, but it does not work. That is correct — XFS does not support shrinking. Create a new smaller LV, copy the data to it with `rsync` or `xfsdump`/`xfsrestore`, and remove the old volume. This is cumbersome, and it is the reason many administrators use ext4 for variable volumes.

The limit of LVM

LVM is not a replacement for backups. Spreading an LV across multiple disks spreads your data, but offers no redundancy — if one disk fails, the entire LV becomes unusable. If you want to prevent that, you need mirroring (`lvcreate --mirrors 1`) or a RAID solution at another level. LVM can do that, but it costs disk space, and it is not the default configuration.

What LVM does do: it makes storage manageable in a way classic partitions cannot. Volumes grow and shrink without a reboot, disks come and go without repartitioning, and data is no longer tied to the physical boundaries of a single disk. The price is an extra layer you must understand — and that will make itself felt one day when you need it.

On systems where storage needs are stable, LVM is an unnecessary abstraction. On systems where they are not, it is the difference between an operation that requires a maintenance window and a command you run while the service simply keeps running. The art is knowing which side you are on — and installing LVM before you find out you were on the wrong side.