Linux Disk Management and LVM: A Hands-on Tutorial

What and Why

Linux storage looks like a stack of layers: physical disks, partitions, optional LVM, filesystems, mount points. Each layer has its own tools, and once you can name the layers you can grow, shrink, snapshot, and recover with confidence.

LVM (Logical Volume Manager) is the part most engineers underuse. It lets you treat physical disks as a pool and carve logical volumes out of it - resizable, snapshottable, and movable between disks while mounted.

Mental Model

/dev/sda  /dev/sdb   (physical disks)
 |          |
 v          v
Partitions (optional)
 |          |
 +----+-----+
      v
 Physical Volumes (pvcreate)
      |
      v
 Volume Group (vgcreate)   <-- pool of extents
      |
      v
 Logical Volumes (lvcreate)  <-- "virtual disks"
      |
      v
 Filesystem (mkfs.ext4 / xfs)
      |
      v
 Mount point (/var/lib/data)

LVM’s magic is in the volume group. Add a new disk to the VG and every logical volume on top can grow into it without downtime.

Hands-on Example

Start with one fresh disk /dev/sdb. Build a VG and an ext4 logical volume:

# 1. Create a physical volume
sudo pvcreate /dev/sdb

# 2. Create a volume group
sudo vgcreate data_vg /dev/sdb

# 3. Create a logical volume (50G)
sudo lvcreate -n appdata -L 50G data_vg

# 4. Make a filesystem and mount
sudo mkfs.ext4 /dev/data_vg/appdata
sudo mkdir -p /var/lib/appdata
sudo mount /dev/data_vg/appdata /var/lib/appdata

Persist the mount in /etc/fstab:

/dev/data_vg/appdata  /var/lib/appdata  ext4  defaults,noatime  0  2

Now usage is climbing and you need more space. Add another disk and grow online:

sudo pvcreate /dev/sdc
sudo vgextend data_vg /dev/sdc
sudo lvextend -L +100G /dev/data_vg/appdata
sudo resize2fs /dev/data_vg/appdata        # ext4; for xfs use xfs_growfs /mount

No unmount required.

Take a snapshot before a risky upgrade:

sudo lvcreate -L 5G -s -n appdata_snap /dev/data_vg/appdata
# ...run the upgrade...
# If everything is fine:
sudo lvremove /dev/data_vg/appdata_snap
# If it broke and you need to roll back:
sudo umount /var/lib/appdata
sudo lvconvert --merge /dev/data_vg/appdata_snap
sudo mount /var/lib/appdata

Inspect what you have:

pvs        # physical volumes
vgs        # volume groups
lvs        # logical volumes
lsblk      # tree view of devices
df -h      # filesystem usage

Common Pitfalls

• Resizing the wrong layer. lvextend grows the LV. resize2fs (or xfs_growfs) grows the filesystem inside. Both are needed unless you use lvextend -r.
• Filling the VG. Snapshots consume extents as the origin changes. A snapshot smaller than the rate of change overflows and becomes unusable.
• Shrinking XFS. XFS cannot shrink. Plan accordingly. ext4 can but it is risky and requires unmount.
• Forgetting /etc/fstab. Mounts disappear at reboot. Always add an entry; for safety use nofail on optional volumes.
• No backups. LVM snapshots are not backups. They live on the same disks. Stream snapshots to off-host storage.

Production Tips

• Use thin provisioning (lvcreate -T) when you expect many snapshots or want over-commit. It saves space but be vigilant about pool fill.
• Pair LVM with mdadm RAID or hardware RAID for redundancy. LVM alone does not protect against disk failure.
• Label filesystems (tune2fs -L data /dev/data_vg/appdata) and mount by LABEL= or UUID= rather than /dev/... to survive reordering.
• Use xfs for very large filesystems and write-heavy databases; ext4 for general-purpose. Both grow online.
• Monitor with node_exporter’s LVM and filesystem collectors. Alert at 80 percent usage so you have time to extend.

Wrap-up

Once you can mentally trace from /dev/sd* up through PVs, VGs, LVs, filesystem, and mount point, Linux disk management stops being scary. LVM in particular pays for itself the first time you extend a database volume without downtime or roll back a bad upgrade with a snapshot merge. Build the habit on a test VM today and your future production self will glide through disk events.