Table of Contents
Why Use LVM?
Logical Volume Manager (LVM) sits between your physical storage (disks/partitions) and the filesystems you create. Instead of rigidly mapping “this partition = this filesystem”, LVM lets you:
- Grow and shrink logical volumes (LVs) more flexibly
- Combine multiple disks into a single storage pool
- Take snapshots for backups or testing
- Move data between disks with minimal downtime
LVM is about abstraction and flexibility in storage management.
Core LVM Building Blocks
LVM has three main layers. Understanding these conceptually is the key:
- Physical Volumes (PVs)
- Volume Groups (VGs)
- Logical Volumes (LVs)
Think: PVs → VGs → LVs → Filesystems
Physical Volumes (PV)
A PV is a block device prepared for use by LVM.
Typical PV examples:
- A whole disk:
/dev/sdb - A partition:
/dev/sda2 - A software RAID device:
/dev/md0
Conceptually:
- LVM writes its own metadata and divides the PV into fixed-size chunks called physical extents (PEs).
- Every usable block of space in LVM is made from PEs.
Key idea: A PV is the raw storage supplied to LVM.
Volume Groups (VG)
A VG is a pool of storage created by combining one or more PVs.
Conceptually:
- You can think of a VG as a “virtual disk cabinet”.
- All free space in the VG is represented as a collection of free PEs.
- You allocate that space to logical volumes.
Example layout:
- PVs:
/dev/sda2,/dev/sdb1 - VG:
vg_data(holds the combined capacity of those PVs)
Add/remove PVs to grow/shrink the VG:
- Adding a new disk → create PV → add it to VG → VG gets more space.
- Removing a disk (with
pvmove/vgreduce) → shrink VG.
Key idea: A VG is a shared storage pool from which you carve out LVs.
Logical Volumes (LV)
An LV is what you use as if it were a partition.
You:
- Put filesystems on LVs (e.g.
ext4,xfs) - Mount LVs just like partitions (e.g. on
/home,/var, etc.) - Use swap on an LV
Conceptually:
- An LV is built from PEs allocated from one VG.
- The filesystem or application never sees the underlying disk layout; it only sees the LV block device (
/dev/vg_name/lv_name).
Key idea: An LV is a flexible “virtual partition”.
Extents: The Fundamental Unit
LVM manages space in fixed-size chunks called extents:
- On the PV side: Physical Extents (PEs)
- On the LV side: Logical Extents (LEs)
Conceptually:
- One LE maps to one PE (in simple linear allocations).
- Typical extent size: 4 MiB (but configurable).
If a VG has $N$ PEs and each PE is size $S$, then total VG size is:
$$\text{VG size} = N \times S$$
Extents allow:
- Easier resizing (add/remove extents, not arbitrary blocks)
- Easier allocation algorithms for LVM
- Uniform mapping across multiple disks
You usually don’t need to change extent size unless you work with very large volumes.
How LVM Maps Storage
Conceptual mappings:
- Physical disk/partition → PV
- LVM metadata + PEs carved from raw space.
- PVs (one or more) → VG
- All PEs from member PVs are combined into one pool.
- VG → LV
- LVs are defined as sequences of LEs
- LEs are mapped internally to PEs on specific PVs.
A simplified example:
- PVs:
/dev/sda2(100 GiB),/dev/sdb1(200 GiB) - VG:
vg_main(300 GiB total) - LVs:
lv_root= 40 GiBlv_home= 200 GiBlv_backup= 60 GiB
The LV data may be spread over both disks; the filesystem doesn’t care—LVM handles it.
Allocation Modes: Linear vs Striped
LVM can arrange PEs for an LV in different patterns.
Linear Volumes
Linear LV:
- The default and simplest.
- LEs are laid out one after another on available PEs, possibly across multiple PVs.
- Conceptually similar to a long concatenation of disks/partitions.
Pros:
- Simple
- Easy to extend
- Flexible for adding disks over time
Cons:
- Performance limited by single-disk throughput at any point of the layout
- If any PV fails, any LV using it is compromised
Use when you want capacity and flexibility more than performance.
Striped Volumes
Striped LV (similar idea to RAID 0):
- Data is striped across multiple PVs.
- Each “stripe” is a chunk of consecutive blocks; stripes are interleaved across PVs.
Conceptual effect:
- Reads/writes can be performed in parallel on multiple PVs.
- Aggregate throughput can be higher.
Pros:
- Better performance for sequential and some random workloads
Cons:
- Higher risk: if any PV fails, the entire LV fails (like RAID 0)
- Less flexible when resizing or changing PV layout
Use when you want performance and accept higher risk or when redundancy is handled elsewhere (e.g. on top of RAID).
Common Use Patterns with LVM
Flexible Layouts for System Partitions
Typical use:
- Create a VG from your main disk.
- Create separate LVs for:
/(root)/home/varswap
Advantages:
- Resize
/homeif it grows unexpectedly. - Add a new disk to expand
/varor/srv. - Take snapshots of
/for safe system upgrades (details in snapshot chapters).
Storage Pools for Data
For data servers (files, databases, VMs):
- Create one large VG from multiple disks.
- Carve out LVs for:
- Database storage
- VM images
- Shared user data
Benefits:
- Can grow a specific LV without having dedicated physical disks for it.
- Easier to reallocate storage between services as needs change.
Resizing with LVM: Conceptual View
Resizing involves:
- Resizing the LV itself
- LVM changes the number of LEs assigned to that LV (add/remove extents).
- Resizing the filesystem inside the LV
- Filesystem tools grow or shrink the filesystem to match new LV size.
Conceptually:
- Growing an LV:
- Must have free PEs in the VG.
- Filesystem grows into the new extents.
- Shrinking an LV:
- Filesystem must be shrunk first (and fully inside the new size).
- Then LVM can release the unused extents back to the VG.
Main idea: LVM handles the block layer; filesystem tools handle the data layer.
Snapshots: Point-in-Time Copies
An LVM snapshot is a logical volume that represents the state of another LV at a specific moment.
Conceptually:
- When you create a snapshot, LVM starts tracking which blocks change on the original LV.
- Only changed blocks are stored in the snapshot space (copy-on-write).
- Reading from the snapshot reconstructs the old state using:
- Original LV blocks that haven’t changed
- Snapshot blocks for data that has changed
Use cases:
- Consistent backups of live data
- Safe testing of changes
- Capturing system states before risky operations
Important concept: snapshots need space for changes; they are not free in capacity or performance.
Data Movement and Disk Replacement
One powerful LVM concept is online data relocation.
Moving Data Between PVs
With LVM, logical data is not tied permanently to specific sectors or disks:
- You can move PEs for an LV from one PV to another while the LV is in use.
- Conceptually, LVM updates its mapping so LEs now point to new PEs.
Use cases:
- Replacing an old disk:
- Add new disk as PV to VG.
- Move data off the old PV to the new PV.
- Remove the old PV from the VG.
- Rebalancing space among disks.
Main idea: LVM decouples logical layout from physical location.
LVM and RAID Concepts
LVM integrates with RAID-like concepts (LVM RAID types), but the key concept is:
- LVM can provide redundancy and striping at the logical volume level.
- Instead of using separate RAID layers, you can:
- Create mirrored LVs (RAID 1 style)
- Create striped LVs (RAID 0 style)
- Use more advanced RAID levels (depending on LVM version and tools)
Conceptual advantage:
- Unified management: all storage (capacity, performance, redundancy) handled through LVM’s abstractions.
- Flexible migration and resizing while keeping redundancy.
Details of RAID levels themselves belong in the RAID-focused chapter; here, you just need to know that LVM can embed RAID-like behavior into LVs.
LVM Architecture Summary
Concept recap:
- PVs: prepared disks/partitions that provide storage.
- VGs: storage pools made from PVs.
- LVs: virtual partitions carved from VGs, used like normal block devices.
- Extents (PE/LE): fixed-size chunks; basic units of allocation.
- Linear vs striped allocation: trade-off between simplicity and performance.
- Snapshots: copy-on-write point-in-time views of LVs.
- Data movement: logical data can be relocated among PVs with minimal downtime.
- Optional RAID-like capabilities: redundancy and striping at LVM level.
Mental model:
- Think of LVM as a storage abstraction layer that turns a bunch of physical disks into flexible, resizable, and movable logical volumes, which your filesystems and applications use just like they would use traditional partitions.