LVM

Before you read. A database partition is at 96% and filling. You have a spare disk in the machine.

With plain partitions, the options are: shrink the neighbouring partition and grow this one, which means unmounting and hoping; or mount the new disk somewhere else and change the application to use two paths; or take an outage, move everything, and repartition.

None of those is good, and all of them exist for one reason: a partition’s start and end are decided when it is created, and everything after it on the disk is in the way.

So the question: what would have to change for “make this filesystem bigger” to be a thing you could do on a Tuesday afternoon, with the database running?

The answer is a layer of indirection. LVM sits between the disks and the filesystems and stops them being adjacent, so growing one no longer means moving another.

This is a deep-dive topic, and it is on the exam because the RHEL family installs onto LVM by default. There is a reasonable chance the machine in front of you is already using it.

Some words you will need

physical volume (PV)

A disk or partition handed over to LVM. It stops being used directly.

volume group (VG)

A pool made of one or more physical volumes. Capacity goes in here.

logical volume (LV)

A slice taken out of the pool. Behaves exactly like a partition, and this is what you put a filesystem on.

extent

The unit LVM allocates in, 4 MiB by default. Sizes are always a whole number of these.

What breaks without this

Growing storage becomes an outage. Every capacity increase means a maintenance window, a backup, and a repartition, instead of two commands.

You cannot read the machine in front of you. On a RHEL-family default install, /dev/sda2 is a physical volume and the root filesystem is on /dev/mapper/rhel-root. Somebody who only knows partitions cannot follow that, and df output that names /dev/mapper/ anything is telling you LVM is in play.

You do the resize half way. Growing the volume and not the filesystem is the single most common LVM mistake, and it produces no error at all.

The three layers

The whole trick is in the middle box. Once capacity is a pool, a logical volume is not sitting between two neighbours. Growing it means taking more extents from the pool, and the extents do not have to be next to the ones it already has, or even on the same disk.

Building it

Three commands, bottom up. The two devices below are raw disks that have never been partitioned.

# AlmaLinux 10.2, aarch64
$ pvcreate $DEVS; echo; pvs
  Physical volume "/dev/loop0" successfully created.
  Physical volume "/dev/loop1" successfully created.
  Creating devices file /etc/lvm/devices/system.devices

  PV         VG Fmt  Attr PSize   PFree  
  /dev/loop0    lvm2 ---  512.00m 512.00m
  /dev/loop1    lvm2 ---  512.00m 512.00m

pvcreate writes an LVM header onto each device. Two 512 MiB disks, both entirely free, and the VG column is empty because neither belongs to a group yet.

Note there are no partitions here. LVM is happy to take a whole disk, and on a data disk that is the tidier choice, one fewer layer, and no partition table to keep in step.

Then the group, and a volume out of it:

# AlmaLinux 10.2, aarch64
$ pvcreate -q $DEVS 2>/dev/null; vgcreate data $DEVS; echo; vgs; echo; lvcreate -n web -L 300M data; echo; lvs; echo; lsblk $DEVS
  Physical volume "/dev/loop0" successfully created.
  Physical volume "/dev/loop1" successfully created.
  Creating devices file /etc/lvm/devices/system.devices
  Volume group "data" successfully created

  VG   #PV #LV #SN Attr   VSize    VFree   
  data   2   0   0 wz--n- 1016.00m 1016.00m

  Logical volume "web" created.

  LV   VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  web  data -wi-a----- 300.00m                                                    

NAME       MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop0        7:0    0  512M  0 loop 
`-data-web 252:0    0  300M  0 lvm  
loop1        7:1    0  512M  0 loop 

Three things to read out of that.

VSize 1016.00m from two 512 MiB disks. Not 1024. Each PV gives up a little to LVM’s own metadata, so the pool is always slightly smaller than the sum of the parts. Expect it and do not go looking for the missing megabytes.

The lsblk tree. data-web is nested under loop0, and loop1 has nothing under it. The volume fitted entirely on the first disk, because 300 MiB fits in 512 MiB. LVM allocates linearly by default and only spills onto the second disk when it has to.

The volume is at /dev/data/web, and also at /dev/mapper/data-web. Both work. /dev/mapper/<vg>-<lv> is the one that shows up in df output, which is why a df line naming /dev/mapper/ anything means you are looking at LVM.

The three reporting commands go together and are worth learning as a set:

There are two families and both are named in the objectives. The short set prints a line per object and is what you reach for when you want to see everything at once. The display set prints a paragraph per object and is what you reach for when the short form leaves out the field you need.

VFree in vgs is the number to look at before any resize. It is the answer to “can I grow this right now”.

Two more commands are worth having before the next section. lvresize does the job of lvextend and lvreduce together, with the sign on the argument deciding: -L +500M grows, -L -500M shrinks, and a bare -L 500M sets the size outright. The separate commands still exist because shrinking a mounted filesystem by accident is expensive, and having to type lvreduce is a small speed bump in front of it.

The option worth remembering on any of the three is -r, which resizes the filesystem in the same breath as the volume. It is the answer to the pitfall the whole next section is about, and the reason to know the long way round first is that -r only knows how to grow the filesystems it supports.

And lvchange is the one you need when a volume exists and is not there. lvchange -ay data/web activates a volume, which is what an imported volume group needs before anything appears under /dev/mapper. A volume that lvs lists and ls /dev/mapper does not is almost always inactive rather than broken.

From here it is an ordinary block device: mkfs.ext4 /dev/data/web, mount it, put it in /etc/fstab. The filesystem neither knows nor cares that LVM is underneath.

The resize, and the step everybody forgets

The volume is mounted and in use. Here is the whole operation:

# AlmaLinux 10.2, aarch64
$ df -h /mnt/web | tail -1; echo "--- grow the logical volume ---"; lvextend -L +500M /dev/data/web; df -h /mnt/web | tail -1; echo "--- now grow the filesystem inside it ---"; resize2fs /dev/data/web; df -h /mnt/web | tail -1
/dev/mapper/data-web  272M   14K  253M   1% /mnt/web
--- grow the logical volume ---
  Size of logical volume data/web changed from 300.00 MiB (75 extents) to 800.00 MiB (200 extents).
  Logical volume data/web successfully resized.
/dev/mapper/data-web  272M   14K  253M   1% /mnt/web
--- now grow the filesystem inside it ---
resize2fs 1.47.1 (20-May-2024)
Filesystem at /dev/data/web is mounted on /mnt/web; on-line resizing required
old_desc_blocks = 3, new_desc_blocks = 7
The filesystem on /dev/data/web is now 819200 (1k) blocks long.

/dev/mapper/data-web  740M   14K  702M   1% /mnt/web

So the operation is always two steps, and the second one depends on the filesystem:

Note the XFS asymmetry. resize2fs takes a device; xfs_growfs takes a mount point. Getting them the wrong way round is a small, annoying, extremely common error, and the reason is that XFS can only be grown while mounted so it works in terms of the mount.

Or skip the second step entirely by asking lvextend to do it:

lvextend -L +500M --resizefs /dev/data/web

-r is the short form. It calls the right resize tool for the filesystem it finds. Use it. The only reason to do the two steps separately is to understand what -r is doing, which is what the capture above is for.

And -l +100%FREE is the other flag worth memorising. It takes everything left in the group rather than a number you had to work out:

lvextend -l +100%FREE -r /dev/data/web

Across distributions

The two defaults compound. A RHEL-family machine is LVM plus XFS, so growing root means lvextend then xfs_growfs <mount point> and shrinking is impossible. A Debian machine is usually a plain partition plus ext4, so growing root means repartitioning first. Same task, entirely different procedure, and assuming the one you know is how people get stuck.

Prove it

Before a resize:

# Is there room in the pool
sudo vgs

# What is the volume now, and what is the filesystem
sudo lvs
df -h /mnt/web

After:

# The volume grew
sudo lvs

# And so did the filesystem. This is the one that matters.
df -h /mnt/web

df is the acceptance test, not lvs. lvs confirms the volume changed, which is the step that never fails. df confirms the thing the application will actually experience.

What trips people up

1. lvextend worked and df did not change

The whole subject of the prediction above. The volume grew; the filesystem did not. resize2fs /dev/vg/lv for ext4, xfs_growfs /mount/point for XFS.

Use lvextend -r and it cannot happen.

2. “Insufficient free space”

lvextend refuses because the volume group has nothing left. vgs shows VFree 0.

LVM does not create capacity; it manages it. You need a new disk: pvcreate /dev/sdc, then vgextend data /dev/sdc, and the pool grows. Then extend.

That three-command sequence (pvcreate, vgextend, lvextend -r) is the whole answer to “we need more space”, and it is worth being able to type from memory.

3. Mixing up the device and the mount point

resize2fs takes the device. xfs_growfs takes the mount point. lvextend takes the device. df takes either.

There is no logic to remember here, only the fact. -r avoids it.

4. Forgetting LVM is there at all

df reports /dev/mapper/rhel-root and somebody goes looking for a partition of that name. There is not one.

lsblk shows the whole stack at once (disk, partition, PV, LV) and is the fastest way to orient on an unfamiliar machine.

5. Treating LVM as a backup or a redundancy layer

It is neither. A volume group spanning two disks loses everything when either disk fails, because extents are spread across both and nothing is duplicated. That is strictly worse than two separate disks.

Redundancy is the next lesson. LVM is about flexibility, and combining the two is the normal arrangement rather than a choice between them.

Work it through

A monitoring alert says /var/lib/mysql is at 97%. The server is live and the database cannot be stopped.

$ df -h /var/lib/mysql
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/vg_data-mysql   200G  194G  6.1G  97% /var/lib/mysql

Reason it through before reading on.

Is this even LVM? Yes: /dev/mapper/vg_data-mysql names a volume group and a logical volume. That single detail decides whether this is a two-command fix or a maintenance window.

Second, is there room in the pool? sudo vgs. Two possibilities:

• VFree shows 300G. Somebody provisioned generously and left headroom. You are three minutes from done.
• VFree shows 0. The pool is fully allocated, and you need a disk before you can do anything. That is a different conversation and it involves other people.

Which filesystem? findmnt /var/lib/mysql or lsblk -f. XFS on a RHEL-family box, most likely, which decides the second command and rules out ever giving the space back.

With free space in the group, the whole operation is one line:

sudo lvextend -L +100G -r /dev/vg_data/mysql

Volume grown, filesystem grown, database never stopped, no unmount. df confirms it.

With no free space, add a disk and extend the pool first:

sudo pvcreate /dev/sdd
sudo vgextend vg_data /dev/sdd
sudo lvextend -l +100%FREE -r /dev/vg_data/mysql

Still online, still no outage.

Now the question worth sitting with: why can this be done live at all, when the same job on a plain partition would need an outage?

Because of what is not next to the volume. On a partitioned disk, growing /dev/sda3 means the space immediately after it must be free, and it is occupied by /dev/sda4. The only ways out involve moving /dev/sda4, which means unmounting it.

Under LVM, the volume is a set of extents scattered wherever there was room. There is no “next to”. Adding extents does not disturb anything, so nothing has to be unmounted, so nothing has to stop.

The habit worth taking: on a new machine, look at lsblk before you need it. Knowing whether you are on LVM, and how much VFree there is, converts a 2am capacity alert from an investigation into a command. And when you build something, do not allocate the whole volume group, leaving 20% unallocated is what makes that command available later.

Try it

Optional, on a virtual machine with two spare disks. Do not do this on anything you care about.

1. sudo pvcreate /dev/sdb /dev/sdc, then sudo pvs. Note the free space.
2. sudo vgcreate testvg /dev/sdb /dev/sdc, then sudo vgs. Compare VSize to the sum of the two disks and explain the difference.
3. sudo lvcreate -n vol1 -L 1G testvg, then lsblk. Say which physical disk it landed on and why.
4. sudo mkfs.ext4 /dev/testvg/vol1, mount it, df -h.
5. sudo lvextend -L +1G /dev/testvg/vol1 and run df -h again before doing anything else. Confirm nothing changed.
6. sudo resize2fs /dev/testvg/vol1, then df -h once more.
7. Do it again with lvextend -L +1G -r and note that step 5 disappears.

Verification step. You have it when you can grow a mounted filesystem in one command and explain, without looking, why df would not have moved if you had left the -r off.

Check yourself

sudo pvcreate /dev/sdd
sudo vgextend vg_data /dev/sdd
sudo lvextend -l +100%FREE -r /dev/vg_data/mysql

References

• lvm(8) - Linux man-pages project. Accessed 2026-08-07.
• lvcreate(8) - Linux man-pages project. Accessed 2026-08-07.
• lvresize(8) - Linux man-pages project, for the sign convention and the -r option. Accessed 2026-08-21.
• lvchange(8) - Linux man-pages project, for activation. Accessed 2026-08-21.
• lvextend(8) - Linux man-pages project. Accessed 2026-08-07.
• vgcreate(8) - Linux man-pages project. Accessed 2026-08-07.
• resize2fs(8) - Linux man-pages project. Accessed 2026-08-07.
• xfs_growfs(8) - Linux man-pages project. Accessed 2026-08-07.
• lvmthin(7) - Linux man-pages project. Accessed 2026-08-07.

Every block above with a distribution and architecture header was captured by running the command on an AlmaLinux 10.2 container. Blocks without one are illustrative.