Traditional disk partitioning ties storage to a fixed size and a fixed physical location on one specific disk. LVM, the Logical Volume Manager, adds a flexible layer between raw disks and the filesystems that use them, letting you resize storage, pool multiple disks together, and take space-efficient snapshots, none of which traditional partitioning handles gracefully.

The three layers

LVM introduces three concepts that build on each other:

Physical volumes (PVs) are physical disks or partitions initialized for LVM use, the raw storage contributed to the system.

Volume groups (VGs) pool one or more physical volumes into a single unit of available storage. A volume group can span multiple physical disks, effectively combining their capacity into one pool.

Logical volumes (LVs) are chunks of space carved out of a volume group, formatted with a filesystem (ext4, XFS, or others) and mounted like a normal partition. This is the layer applications and users actually interact with.

Physical disks (/dev/sda, /dev/sdb)
  -> Physical Volumes (PVs)
    -> Volume Group (VG)
      -> Logical Volumes (LVs)
        -> Filesystems (mounted like normal partitions)

Creating physical volumes

sudo pvcreate /dev/sdb /dev/sdc

This initializes both disks for LVM use. pvcreate can also target a specific partition (/dev/sdb1) rather than a whole disk, if you want LVM to coexist with traditional partitions on the same device.

pvs               # compact summary of all physical volumes
pvdisplay          # detailed information per physical volume

Creating a volume group

sudo vgcreate data_vg /dev/sdb /dev/sdc

This combines both physical volumes into a single volume group named data_vg, pooling their capacity together.

vgs                # compact summary of all volume groups
vgdisplay           # detailed information per volume group

vgs output includes total size and free (unallocated) space, useful for quickly checking how much room is left for new or expanded logical volumes.

Creating logical volumes

sudo lvcreate -L 100G -n webdata data_vg

This carves a 100GB logical volume named webdata out of the data_vg volume group. To use all remaining free space in the group instead of a fixed size:

sudo lvcreate -l 100%FREE -n webdata data_vg

The new logical volume appears as a device at /dev/data_vg/webdata, ready to be formatted and mounted like any other block device:

sudo mkfs.ext4 /dev/data_vg/webdata
sudo mkdir -p /mnt/webdata
sudo mount /dev/data_vg/webdata /mnt/webdata

As with any mount, add an entry to /etc/fstab to make it persist across reboots.

Growing a logical volume

This is where LVM’s main advantage shows up directly: growing storage without unmounting or moving data.

sudo lvextend -L +50G /dev/data_vg/webdata

This adds 50GB to the logical volume, assuming the volume group has that much free space available. After extending the logical volume itself, the filesystem inside it also needs to be told to grow into the new space:

sudo resize2fs /dev/data_vg/webdata      # for ext4
sudo xfs_growfs /mnt/webdata              # for XFS (note: operates on the mount point, not the device)

Both of these can typically run while the filesystem is mounted and in active use, which is a meaningful advantage over resizing a traditional partition, an operation that often requires unmounting or booting from external media.

Shrinking a logical volume

Shrinking is more involved and riskier than growing, and the order of operations matters:

sudo umount /mnt/webdata
sudo e2fsck -f /dev/data_vg/webdata          # check filesystem first
sudo resize2fs /dev/data_vg/webdata 50G       # shrink the filesystem first
sudo lvreduce -L 50G /dev/data_vg/webdata     # then shrink the logical volume
sudo mount /dev/data_vg/webdata /mnt/webdata

The filesystem must be shrunk before the logical volume, doing it in the opposite order risks truncating the filesystem’s data and causing corruption. XFS specifically does not support shrinking at all; an XFS filesystem that needs to be smaller must be backed up, recreated at the smaller size, and restored, rather than shrunk in place.

Snapshots

A snapshot captures a logical volume’s state at a point in time, initially consuming very little space since it only tracks changes made after the snapshot was taken:

sudo lvcreate -L 5G -s -n webdata_snap /dev/data_vg/webdata

-s creates a snapshot rather than an independent logical volume, and -L 5G allocates space for tracking changes, not a full copy of the original volume’s size. Snapshots are commonly used to get a backup of a consistent, unchanging view of a filesystem that is actively being written to, or as a rollback point before a risky change like a major upgrade.

sudo lvconvert --merge /dev/data_vg/webdata_snap   # roll back to the snapshot's state

Snapshots are not a substitute for real backups stored on separate physical media, since a snapshot still depends on the same underlying disks as the original volume, and does not protect against disk failure.

Checking overall status

pvs      # physical volumes: size, volume group membership
vgs      # volume groups: total size, free space
lvs      # logical volumes: size, associated volume group

These three commands, in that order, are the fastest way to get a complete picture of an LVM setup: what raw storage is available, how it is pooled, and what has been allocated from it.

Should you use LVM?

LVM adds real flexibility, particularly for systems where storage needs are expected to grow, or where pooling multiple physical disks into flexible logical volumes is useful, such as file servers and virtualization hosts. It also adds a layer of complexity that is not necessary for every setup. A single-disk desktop installation with no plans to resize partitions later is a reasonable case for skipping LVM in favor of traditional partitioning, while servers and any system where storage will likely need to grow over time are the more common candidates for using it from the start.

Frequently Asked Questions

What problem does LVM actually solve?

Traditional disk partitions are fixed in size and location on a specific physical disk, which makes resizing awkward and combining space across multiple disks into one usable pool essentially impossible without LVM or a similar abstraction layer. LVM adds a flexible layer between raw disks and filesystems: physical disks or partitions become physical volumes, which are pooled into volume groups, from which you carve out logical volumes of whatever size you need, resizable later without needing to move data around on the underlying physical layout the way resizing a traditional partition often requires.

What is the difference between a physical volume, volume group, and logical volume?

A physical volume (PV) is a physical disk or partition that has been initialized for use with LVM, the raw storage being contributed to the system. A volume group (VG) is a pool formed by combining one or more physical volumes into a single unit of available storage, potentially spanning multiple physical disks. A logical volume (LV) is a chunk of space carved out of a volume group, formatted with a filesystem and mounted like any other partition would be. The relationship flows in that order: physical volumes are combined into a volume group, and logical volumes are then allocated from that group’s available space.

Can I resize an LVM logical volume without losing data?

Yes, this is one of LVM’s main advantages over traditional partitioning. Growing a logical volume (lvextend) can typically be done live, while the filesystem is mounted and in use, followed by resizing the filesystem itself to fill the new space (resize2fs for ext4, or xfs_growfs for XFS, which specifically only supports growing, never shrinking). Shrinking is more involved and riskier: the filesystem generally must be shrunk first (and some filesystems, including XFS, do not support shrinking at all), before the logical volume itself is reduced with lvreduce, and doing these steps out of order risks data loss.

Do I need LVM for a simple desktop installation?

Not necessarily. LVM adds real flexibility, easy resizing, snapshots, and pooling multiple disks, but also adds a layer of complexity that is not needed by everyone, particularly for a single-disk desktop installation where the partition layout is unlikely to change. Many distribution installers offer LVM as an option during installation specifically because it is genuinely useful for anyone who expects to resize partitions later, add storage, or use snapshots, while a simple traditional partition layout remains a perfectly reasonable choice for a straightforward desktop setup that is not expected to change.

What is an LVM snapshot and what is it used for?

A snapshot is a point-in-time copy of a logical volume that initially takes up very little space, since it only stores changes made after the snapshot was taken (a copy-on-write mechanism), rather than duplicating the entire volume immediately. Snapshots are commonly used to get a consistent backup of a filesystem that is actively being written to, since you can back up the frozen snapshot instead of the live, changing volume, and to create a safe rollback point before a risky operation like a major system upgrade, letting you revert if something goes wrong. Snapshots are not a substitute for real backups stored elsewhere, since they still depend on the same underlying physical disk as the original volume.

How do I check how much space is used and available in LVM?

pvs (physical volume summary), vgs (volume group summary), and lvs (logical volume summary) each give a compact one-line-per-item overview of their respective LVM layer, including size and, for volume groups, free space available for new logical volumes. For more detail on a specific item, the long-form equivalents pvdisplay, vgdisplay, and lvdisplay show full details for physical volumes, volume groups, and logical volumes respectively. vgs is usually the fastest way to answer “how much unallocated space do I have left to create a new logical volume or extend an existing one.”