LVM, the Logical Volume Manager for Linux, is a storage layer that pools physical disks or partitions into volume groups and divides that pool into flexible logical volumes. On Linux systems, it decouples file systems from fixed partitions, so capacity can be resized, extended across disks, snapshotted and moved while the system keeps running.
The current implementation, often called LVM2, is built on the kernel’s device mapper framework. File systems such as ext4 or XFS sit on top of a logical volume exactly as they would on a partition, unaware of the mapping underneath.
How LVM maps storage
LVM maps storage through three layers of abstraction. Physical volumes are initialized disks or partitions, volume groups pool them, and logical volumes are the block devices that file systems use.
| Layer | What it is | Typical command | Example name |
|---|---|---|---|
| Physical volume (PV) | A disk, partition or RAID device with an LVM header | pvcreate | /dev/sdb |
| Volume group (VG) | A pool of space from one or more PVs | vgcreate, vgextend | vg_data |
| Logical volume (LV) | A block device carved from the VG | lvcreate, lvextend | /dev/vg_data/lv_db |
Space inside a volume group is divided into physical extents, by default 4 MiB each. A logical volume is simply a list of extents, which can come from any physical volume in the group and need not be contiguous. This mapping is what makes online resizing and data relocation possible.
Metadata describing the layout is stored in a small area on every physical volume, with automatic backups under /etc/lvm/backup and archives of earlier versions. These text files allow the layout to be restored with vgcfgrestore after an accidental change.
Logical volume types and features
LVM supports several logical volume types beyond a simple linear mapping. Each serves a different goal, from performance to space efficiency.
| Type | How it works | Main use |
|---|---|---|
| Linear | Extents allocated one after another across PVs | General storage, default choice |
| Striped | Data spread across PVs in chunks | Higher throughput, no redundancy |
| RAID 1, 5, 6, 10 | LVM RAID using the kernel md code | Redundancy without a separate md layer |
| Thin pool and thin volumes | Space allocated only when written | Overprovisioning and efficient snapshots |
| Snapshot | Copy-on-write view of a volume at a point in time | Consistent backups and safe upgrades |
| Cache volume | Fast SSD in front of a slower LV | Accelerating HDD-based volumes |
Classic snapshots reserve a fixed amount of space for changed blocks and slow down writes to the origin, because each first write triggers a copy. If the reserved space fills, the snapshot becomes invalid and unusable. Thin snapshots share the pool and scale better, but depend on careful monitoring of pool usage.
LVM compared with RAID and ZFS
LVM is a volume manager, not a file system, and it is often combined with neighboring technologies rather than replacing them. The comparison clarifies where each one fits.
| Aspect | LVM | Software RAID (md) | ZFS |
|---|---|---|---|
| Primary job | Flexible volume management | Redundancy across disks | Integrated file system and volume manager |
| Redundancy | Optional LVM RAID | Core feature | Mirrors and RAID-Z |
| Snapshots | Classic or thin | None | Native, very efficient |
| Data checksums | No | No | Yes, end to end |
| File system | Any, such as ext4 or XFS | Any | ZFS only |
A long-standing pattern on Linux servers is md RAID underneath LVM, with a conventional file system on top. ZFS covers all three roles in one stack and adds integrity checking, at the cost of higher memory use and a separate toolset.
Practical operations with LVM
Day-to-day value comes from resizing and moving storage without downtime. The most common operations follow a short, predictable sequence.
- Extending a volume: add a disk with pvcreate and vgextend, then run lvextend with the -r option to grow the file system at the same time.
- Shrinking a volume: possible for ext4 only while unmounted; XFS cannot be shrunk at all.
- Replacing a disk: pvmove migrates extents to another PV while the volume stays online, then vgreduce removes the old disk.
- Backing up consistently: create a snapshot, back up from it, then remove it promptly to avoid write overhead.
A good habit is to leave free extents in the volume group instead of assigning everything at installation. Unallocated space can be given to whichever volume grows first, which is the main reason LVM exists.
Risks and common mistakes
LVM adds flexibility but also new failure modes. Most serious incidents come from forgotten snapshots, thin pools or volumes spanning disks without redundancy.
- Spanning without redundancy: a linear volume across two disks is lost entirely if either disk fails.
- Thin pool exhaustion: when an overprovisioned pool fills, writes fail and file systems can be damaged; set autoextend thresholds and alerts.
- Old snapshots left in place: they slow writes and eventually overflow.
- Resizing in the wrong order: shrinking a logical volume before shrinking its file system destroys data.
In simple terms
LVM works like a shared storage room with movable walls. Several disks are combined into one large room. Inside it, walls divide the space into smaller rooms for different uses.
When one room gets full, the walls can be moved or a new disk can enlarge the whole room. This happens without emptying the rooms first, so the server keeps working.
A practical example
A company runs a PostgreSQL database on a Linux server with two 2 TB SSDs in an md RAID 1 mirror. The administrator placed LVM on top, creating a volume group with a 1 TB logical volume for the database and leaving the remaining space unallocated in the volume group.
When the database approached 900 GB, the administrator ran lvextend with the resize option to add 500 GB, and the XFS file system grew online in seconds without stopping the service. Before each major PostgreSQL upgrade, the team takes an LVM snapshot so the previous state can be restored quickly if the upgrade fails, and removes the snapshot as soon as the upgrade is confirmed.