LFCS 82 🐧 LVM — Concepts
Logical Volume Management inserts a layer between the physical disk and the filesystem. The disk is no longer the unit of allocation; the filesystem is created on a logical volume that can span multiple disks, be resized while mounted, and be moved between physical devices without unmounting. The LFCS storage domain treats LVM as the default choice for any filesystem that might need to grow, because traditional partitions cannot be resized without unmounting and repartitioning, and LVM can.
This chapter covers the conceptual model of LVM: the three layers—Physical Volume, Volume Group, and Logical Volume—and the Physical Extent that connects them. It explains why the abstraction exists, how the layers relate to each other, and the specific capabilities that the abstraction enables. The chapter does not cover the commands for creating or resizing LVM; those belong to the next chapter. It establishes the mental model that makes the commands make sense.
Key point: LVM is a mapping layer. A Logical Volume is not a partition; it is a block device whose extents are mapped to Physical Extents on one or more Physical Volumes. The mapping is what allows the volume to be resized, moved, or spanned across disks.
Why LVM exists
The partition resize problem. A traditional partition has a fixed size and a fixed position on a disk. Growing it requires free space immediately adjacent to it, and shrinking it requires the filesystem to be unmounted. If the partition is in the middle of the disk and the free space is at the end, the partition cannot grow without moving data, which is a risky and slow operation. LVM removes this constraint by decoupling the logical block device from the physical location of the data .
The disk spanning problem. A single partition cannot span two disks. If an application needs 3 TB and the available disks are two 2 TB drives, a traditional partition can only use one of them. LVM pools the disks into a Volume Group and allocates the Logical Volume from the pool, so the 3 TB volume can use space from both disks without the application knowing .
The runtime resize capability. An LVM Logical Volume can be extended while it is mounted and the filesystem is active, provided the filesystem supports online growth (ext4 and XFS both do). The physical extents are added to the mapping, and the filesystem is grown to match. This is the operational advantage that makes LVM the default for root and data volumes on most distributions .
The snapshot and migration capabilities. LVM can create a snapshot of a Logical Volume, which is a point-in-time copy that shares the unchanged extents with the original. It can also move the extents of a Logical Volume from one Physical Volume to another while the volume is in use, which allows a disk to be evacuated without downtime. These capabilities are not required for the LFCS exam, but they are the reason the abstraction exists beyond simple resizing .
a. The three layers: PV, VG, and LV
The LVM model has three layers, and each layer has a specific role in the mapping. The Physical Volume (PV) is a block device that LVM has initialized. It can be an entire disk (/dev/sdb), a partition (/dev/sdb1), or a software RAID device. The initialization writes LVM metadata to the device, which records the device’s identity and its membership in a Volume Group .
The Volume Group (VG) is a pool of Physical Volumes. It aggregates the capacity of its member PVs into a single address space. The VG is the unit that the administrator manages: a new disk is added to the VG with vgextend, and the VG’s capacity grows by the size of the new PV. The VG does not have a fixed size; it is the sum of its PVs, and it can be extended or reduced .
The Logical Volume (LV) is a block device allocated from the VG. It is the equivalent of a partition in a non-LVM system, but it is not tied to a physical location. The LV has a name and a device path, and a filesystem can be created on it and mounted. The LV’s size is a number of extents, and those extents are mapped to Physical Extents on the VG’s PVs .
The mapping is the key. When the application writes to /dev/vg00/lv_data, the LVM layer translates the logical block address into a Physical Extent on a specific Physical Volume. The translation table is stored in the VG metadata, and it is what allows the LV to span disks and be resized.
b. Physical Extents and the allocation unit
The Physical Extent (PE) is the smallest allocatable unit in a Volume Group. When a PV is initialized, its space is divided into PEs of a fixed size, typically 4 MiB. The PE size is set when the VG is created and cannot be changed afterward .
The Logical Volume is divided into Logical Extents (LEs), and each LE maps to exactly one PE. The LE and PE sizes are equal, so the mapping is one-to-one. The LV’s size is the number of LEs multiplied by the PE size, and the VG’s free space is the number of unallocated PEs multiplied by the PE size .
The extent model has two consequences. First, an LV’s size is always a multiple of the PE size. A request for 100 MB with a 4 MiB PE size allocates 25 PEs, which is 100 MB. A request for 102 MB allocates 26 PEs, which is 104 MB. The lvcreate command rounds up to the extent boundary, and the difference is reported in the command’s output . Second, the mapping table is what makes resizing cheap. Extending an LV adds PEs to the mapping; it does not move data.
c. The capabilities the abstraction enables
The three layers and the extent mapping enable a specific set of operations that are not possible with traditional partitions.
Online growth is the primary capability. When the VG has free PEs, the LV can be extended with lvextend, and the filesystem can be grown with resize2fs (ext4) or xfs_growfs (XFS) while it is mounted. The application continues to run, and the new space is available immediately after the filesystem resize .
Shrinking is possible for ext4, but not for XFS. The LV must be unmounted, the filesystem must be shrunk with resize2fs, and the LV must be reduced with lvreduce. The order matters: shrinking the filesystem first prevents data loss. XFS does not support shrinking, so an XFS LV is grow-only .
Spanning allows an LV to use PEs from multiple PVs. This is the default behavior when the VG has multiple PVs and the LV is larger than any single PV. The LV is not mirrored or striped unless those features are explicitly configured; it is simply a linear mapping across the PVs .
Moving allows the PEs of an LV to be relocated from one PV to another with pvmove. The operation runs while the LV is in use, and it is the mechanism for evacuating a disk before removing it from the system .
Complete Example Session
# ============================================
# PART 1: THE PHYSICAL LAYER
# ============================================
# The raw disks or partitions are the starting point.
# They have no LVM identity until pvcreate runs.
lsblk
# sdb 8:16 0 10G 0 disk
# sdc 8:32 0 10G 0 disk
# ============================================
# PART 2: THE PHYSICAL VOLUME
# ============================================
# pvcreate writes LVM metadata to the device.
# The device becomes a member of the LVM pool.
pvcreate /dev/sdb /dev/sdc
pvs
# PV VG Fmt Attr PSize PFree
# /dev/sdb lvm2 --- 10.00g 10.00g
# /dev/sdc lvm2 --- 10.00g 10.00g
# ============================================
# PART 3: THE VOLUME GROUP
# ============================================
# vgcreate pools the PVs into a single address space.
# The VG is the unit the administrator manages.
vgcreate vg_data /dev/sdb /dev/sdc
vgs
# VG #PV #LV #SN Attr VSize VFree
# vg_data 2 0 0 wz--n- 19.99g 19.99g
# ============================================
# PART 4: THE LOGICAL VOLUME
# ============================================
# lvcreate allocates extents from the VG.
# The LV is a block device, not a partition.
lvcreate -n lv_app -L 5G vg_data
lvs
# LV VG Attr LSize Pool Origin Data%
# lv_app vg_data -wi-a----- 5.00g
# ============================================
# PART 5: THE MAPPING
# ============================================
# The LV maps to PEs on the PVs.
# The mapping is stored in the VG metadata.
lvs -o +seg_pe_ranges vg_data
# The output shows which PEs on which PVs
# back the logical extents of the LV.
# ============================================
# PART 6: THE FILESYSTEM
# ============================================
# A filesystem is created on the LV.
# The LV is used exactly like a partition.
mkfs.ext4 /dev/vg_data/lv_app
mkdir -p /mnt/app
mount /dev/vg_data/lv_app /mnt/app
df -hT /mnt/app
# ============================================
# PART 7: THE GROWTH CAPABILITY
# ============================================
# The VG has free space. The LV can grow.
# ext4 grows online; XFS grows online.
# Both are covered in the LVM commands chapter.
# lvextend -L +2G /dev/vg_data/lv_app
# resize2fs /dev/vg_data/lv_app
# ============================================
# PART 8: THE SPANNING CAPABILITY
# ============================================
# The LV can use extents from both PVs.
# The application does not see the disk boundary.
# lvcreate -n lv_big -L 15G vg_data
# The 15G LV spans sdb and sdc.
# ============================================
# PART 9: THE MOVE CAPABILITY
# ============================================
# pvmove relocates extents from one PV to another.
# The LV remains available during the move.
# pvmove /dev/sdb /dev/sdc
# Moves all extents from sdb to sdc.
# ============================================
# PART 10: THE FULL PICTURE
# ============================================
# PV is the device with LVM metadata.
# VG is the pool of PVs.
# LV is the block device allocated from the pool.
# PE is the unit of allocation.
echo "LVM concepts established."The ten parts walk through the layers from the raw device to the mounted filesystem, then name the capabilities that the abstraction enables. The pattern is consistent: each layer adds a capability that the layer below it does not have.
Quick Reference
LVM Layers
| Layer | Abbreviation | Definition | Command to Create |
|---|---|---|---|
| Physical Volume | PV | Block device with LVM metadata | pvcreate |
| Volume Group | VG | Pool of PVs | vgcreate |
| Logical Volume | LV | Block device allocated from VG | lvcreate |
| Physical Extent | PE | Smallest allocatable unit | Set at VG creation |
Layer Relationships
| Relationship | Meaning |
|---|---|
| PV → VG | A VG is composed of one or more PVs |
| VG → LV | An LV is allocated from a VG’s free PEs |
| LV → PE | Each LE maps to exactly one PE |
| PE → PV | Each PE resides on exactly one PV |
Capabilities
| Capability | Description | Filesystem Support |
|---|---|---|
| Online grow | Extend LV while mounted | ext4, XFS, Btrfs |
| Shrink | Reduce LV | ext4 (offline), not XFS |
| Span | LV uses multiple PVs | Any |
| Move | Relocate PEs between PVs | Any |
| Snapshot | Point-in-time copy | Any |
Device Paths
| Path | Meaning |
|---|---|
/dev/sdb | Raw block device |
/dev/vg_data/lv_app | LV device path |
/dev/mapper/vg_data-lv_app | Alternative LV path |
/dev/disk/by-id/... | Persistent device identifier |
Best Practices
✅ Do This:
# Use whole disks or partitions for PVs.
pvcreate /dev/sdb /dev/sdc // ✅
# Name VGs and LVs by purpose.
vgcreate vg_data /dev/sdb // ✅
lvcreate -n lv_app -L 5G vg_data // ✅
# Leave free PEs in the VG for future growth.
# A full VG cannot be extended without adding a PV. // ✅
# Use the LV device path for filesystem operations.
mkfs.ext4 /dev/vg_data/lv_app // ✅❌ Don’t Do This:
# Don't use a disk for LVM and a filesystem simultaneously.
# The LVM metadata occupies the start of the device. // ❌
# Don't expect XFS to shrink.
# lvreduce without shrinking the filesystem first destroys data. // ❌
# Don't create a VG without a plan for the PE size.
# The PE size cannot be changed after VG creation. // ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| LV size not a round number | PE size rounding | Check lvcreate output; the allocated size is the next multiple of the PE size |
| Cannot extend LV | VG has no free PEs | Add a PV with vgextend or free space with lvreduce |
| XFS shrink fails | XFS does not support shrinking | Use ext4 for volumes that may need to shrink |
| PV not recognized | LVM metadata not written | pvcreate the device |
| LV path not found | VG not active | vgchange -a y vg_name |
Real-World Examples
1. Create PV
pvcreate /dev/sdb2. Create VG
vgcreate vg_data /dev/sdb3. Create LV
lvcreate -n lv_app -L 5G vg_data4. Show PVs
pvs5. Show VGs
vgs6. Show LVs
lvs7. LV Device Path
/dev/vg_data/lv_app8. Alternative Path
/dev/mapper/vg_data-lv_app9. Spanning LV
lvcreate -n lv_big -L 15G vg_data10. Move Extents
pvmove /dev/sdb /dev/sdcVisual
The Three Layers
┌─────────────────────────────────────────────────────────┐
│ LOGICAL VOLUME (LV) │
│ /dev/vg_data/lv_app │
│ ┌───────────────────────────────────────────────────┐ │
│ │ LE 0 │ LE 1 │ LE 2 │ ... │ LE n │ │
│ └────┬───┴────┬───┴────┬───┴───────┴────┬───────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ VOLUME GROUP (VG) │ │
│ │ vg_data │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ PE 0 │ PE 1 │ PE 2 │ ... │ PE n │ │ │
│ │ └────┬───┴────┬───┴────┬───┴───────┴────┬─────┘ │ │
│ └───────│────────│────────│────────────────│────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ PHYSICAL VOLUMES (PV) │ │
│ │ /dev/sdb /dev/sdc │ │
│ │ ┌─────────────────┐ ┌─────────────────┐ │ │
│ │ │ PE 0 │ PE 1 │ │ PE 0 │ PE 1 │ │ │
│ │ └────────┴────────┘ └────────┴────────┘ │ │
│ └───────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘The Extent Mapping
┌─────────────────────────────────────────────────────────┐
│ LV: lv_app (5 GB, 4 MiB PE) │
│ LEs 0..1279 │
│ │
│ Mapping table: │
│ LE 0 → PV /dev/sdb, PE 0 │
│ LE 1 → PV /dev/sdb, PE 1 │
│ ... │
│ LE 639 → PV /dev/sdb, PE 639 │
│ LE 640 → PV /dev/sdc, PE 0 ← spans to second disk │
│ ... │
│ LE 1279 → PV /dev/sdc, PE 639 │
│ │
│ The application sees a single 5 GB block device. │
│ The mapping is transparent. │
└─────────────────────────────────────────────────────────┘The Resize Capability
┌─────────────────────────────────────────────────────────┐
│ BEFORE │
│ VG: 20 GB total, 5 GB allocated, 15 GB free │
│ LV: 5 GB │
│ │
│ lvextend -L +5G /dev/vg_data/lv_app │
│ │ │
│ ▼ │
│ AFTER │
│ VG: 20 GB total, 10 GB allocated, 10 GB free │
│ LV: 10 GB │
│ │
│ The filesystem resize follows. │
│ No unmount, no data movement. │
└─────────────────────────────────────────────────────────┘PV, VG, and LV Commands
┌─────────────────────────────────────────────────────────┐
│ LAYER CREATE DISPLAY EXTEND │
│ ───────────────────────────────────────────────────── │
│ PV pvcreate pvs (not extended) │
│ VG vgcreate vgs vgextend │
│ LV lvcreate lvs lvextend │
│ │
│ Each layer has a create command, a display command, │
│ and (for VG and LV) an extend command. │
└─────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| PV | Block device with LVM metadata |
| VG | Pool of PVs |
| LV | Block device allocated from a VG |
| PE | Smallest allocatable unit (default 4 MiB) |
| LE | Logical extent, maps 1:1 to a PE |
| Online grow | Supported by ext4, XFS, Btrfs |
| Shrink | ext4 only (offline), not XFS |
| Spanning | LV uses PEs from multiple PVs |
| Moving | pvmove relocates PEs |
| Device path | /dev/vg_name/lv_name |
Key takeaways:
- LVM is a mapping layer. The LV is not a partition; it is a block device whose extents map to PEs on one or more PVs. The mapping is what enables resizing and spanning .
- The three layers are PV, VG, and LV. The PV is the initialized device, the VG is the pool, and the LV is the allocated block device. The PE is the unit that connects them .
- The extent size is fixed at VG creation. A request for 102 MB with a 4 MiB PE size allocates 26 PEs (104 MB). The rounding is reported by
lvcreate. - Online growth is the primary capability. ext4 and XFS can be grown while mounted. XFS cannot be shrunk. The choice of filesystem determines whether the LV is grow-only or grow-and-shrink .
- Spanning is transparent to the filesystem. An LV that uses PEs from multiple PVs appears as a single block device. The application does not see the disk boundary .
Remember: LVM inserts an abstraction between the disk and the filesystem. The Physical Volume is the disk that LVM has claimed. The Volume Group is the pool of those disks. The Logical Volume is the block device that the filesystem sees. The Physical Extent is the unit of allocation that connects them. The abstraction is what allows a filesystem to grow without repartitioning, to span disks without RAID, and to move between devices without downtime. The commands create and manage the layers; the concept is the mapping.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!