Overview
LVM adds a flexible layer between raw disks and the filesystems on top of them: a physical volume is a disk or partition brought under LVM's management, a volume group pools one or more physical volumes into a single unit of capacity, and a logical volume is a virtual block device carved out of a volume group's available space, with the kernel's Device Mapper layer actually mapping an LV's blocks onto one or more of its VG's underlying disks. That indirection is what makes LVM genuinely useful, capacity can be added to a VG by adding another disk as a new PV, and an LV (and its filesystem) can grow into that space, without the fixed boundaries a plain partition table imposes. mount attaches a filesystem to the directory tree for the current session; /etc/fstab is what makes that attachment persist across a reboot instead of quietly vanishing.
Quick Reference
| LVM layer | What it is | Analogy |
|---|---|---|
| Physical Volume (PV) | A disk or partition under LVM | A single brick |
| Volume Group (VG) | A pool of one or more PVs | A pile of bricks pooled together |
| Logical Volume (LV) | A virtual block device carved from a VG | A wall built from the pile, resizable |
Syntax
pvcreate /dev/sdb1 # bring a partition under LVM as a PV
vgcreate data-vg /dev/sdb1 # create a volume group from that PV
lvcreate -L 50G -n app-lv data-vg # carve a 50GB logical volume from the VGExamples
# Grow an existing filesystem into newly added VG capacity -
# no unmounting, no data migration, no mount point change.
vgextend data-vg /dev/sdc1
lvextend -L +20G /dev/data-vg/app-lv
# ext2/ext3/ext4:
resize2fs /dev/data-vg/app-lv
# XFS instead (must be run on the mounted filesystem, not the device):
# xfs_growfs /mount/pointA manual mount doesn't survive a reboot
Running mount from the command line attaches a filesystem for the current session only. Without a matching entry in /etc/fstab, that mount is gone the next time the system boots, a common cause of "it worked yesterday" storage surprises.
Visual Diagram
Common Mistakes
- Creating a filesystem directly on a raw partition instead of through LVM, then hitting a hard capacity wall with no easy way to grow it later.
- Growing a logical volume with
lvextendbut forgetting to also grow the filesystem on top of it (resize2fs/xfs_growfs), leaving the extra space allocated but unusable. - Mounting a filesystem manually to fix an immediate need and never adding the corresponding
/etc/fstabentry, so it silently disappears on the next reboot. - Removing a physical volume from a volume group while a logical volume still has data striped or allocated onto it, causing data loss.
Performance
- LVM's block-mapping indirection (Device Mapper) adds negligible overhead in the common case; the practical performance factor is which underlying physical disks an LV's blocks actually land on, not LVM itself.
- Spreading a logical volume across multiple physical volumes can improve throughput if the underlying disks are genuinely independent, but doesn't help, and can hurt, if they share a single bottlenecked bus or controller.
Best Practices
- Provision storage through LVM by default rather than raw partitions, so future growth doesn't require an unmount-and-migrate operation.
- Always resize the filesystem after extending the logical volume underneath it; the LV growing doesn't automatically grow what's on top of it.
- Add every mount that should persist to
/etc/fstabimmediately, not as an afterthought once a reboot has already dropped it. - Confirm no data is allocated on a physical volume (
pvmoveit off first if needed) before removing it from a volume group.