It is 2am and /var is at 100 percent. Logs stopped writing, the database is refusing connections, and there is a brand new 200 gigabyte disk sitting in the server doing nothing. On a machine with plain fixed partitions, fixing this means backing up, repartitioning, and restoring, with real downtime and real risk. On a machine that uses LVM, it is three commands and the filesystem grows while it stays mounted and in use. Nobody even has to log off.

That difference is the whole reason to learn LVM. It puts a flexible layer between your physical disks and your filesystems, so storage stops being a decision you make once at install time and can never comfortably change.

LVM stacks three ideas. A physical volume is a disk or partition handed to LVM. A volume group is a pool made of one or more physical volumes. A logical volume is a slice of that pool which you format and mount like a normal partition, except you can grow it, and often shrink it, while it is running. Add a disk to the pool and extend a volume onto it with no downtime. The one thing people forget is that growing the volume does not grow the filesystem inside it; that is a second step.

Creating LVM storage follows the three layers from the bottom up. Initialize a disk as a physical volume, gather one or more of those into a volume group, carve a logical volume out of the group, then format and mount it just like the partition from the disks part. After this, the mount behaves like any other, but its size is no longer fixed.

Notice the device name. You can use the friendly /dev/vgdata/lv_web path, and df reports the underlying /dev/mapper/vgdata-lv_web; both point at the same volume. Add the volume to /etc/fstab by its path or UUID so it mounts at boot, exactly as you did for a plain partition.

This is the payoff, and the reason LVM earns its place on servers. When a volume fills, you add capacity to the pool and extend the volume onto it, all while it stays mounted. Back to the 2am scenario: a new disk is in the machine, and /web is full.

The volume was 50G and is now 148G, and /web never unmounted. You can combine the last two steps with lvextend -r, where the -r tells LVM to resize the filesystem for you in the same command. Use -l +100%FREE instead of a fixed size to consume all the space the pool has left.

The single most common LVM mistake: you run lvextend, see it succeed, and think you are done, but df still shows the old full size. The volume grew; the filesystem inside it did not. A logical volume is a container, and the filesystem has no idea the container got bigger until you tell it.

Finish the job with the right resize tool. For ext4, run resize2fs on the volume. For XFS, run xfs_growfs on the mount point, not the device. Easiest of all, let lvextend -r do both at once. And know the asymmetry: XFS can only grow, never shrink, while ext4 can shrink but only while unmounted. Plan sizes with that in mind.

LVM has a second trick that pairs with the backup part. A snapshot captures a logical volume as it stands right now, so you can back up a consistent picture even while applications keep writing. It works by recording only the blocks that change after the snapshot is taken, which makes it cheap and fast to create.

Back up from the snapshot mount, then remove it when the backup finishes. Give the snapshot enough space to hold the changes that happen during the backup window, and never leave one lying around, because a full snapshot that runs out of change space becomes invalid.

A short warning that saves later pain: do not hand your whole volume group to logical volumes on day one. When you create volumes, leave a good share of the pool unallocated, so that later you can grow whichever volume actually fills without attaching anything new. Claiming every block up front with -l 100%FREE on the first volume removes the very flexibility LVM exists to give you, and it is a common regret.

Separate the things that grow from the things that must not fill. Put /var, where logs and databases pile up, on its own volume and keep it off the root filesystem, so a runaway log fills its own space and not the system trying to manage it. The same logic puts /home on a shared box on its own volume. When one volume fills, only its own users feel it, and you extend just that one from the shared pool while everything else keeps running.

Name volumes for what they hold, not the disk they sit on, because a volume can move across disks over its life. lv_web and lv_db stay meaningful; a name like lv_sdb1 becomes a lie the first time you extend onto a second disk. A little naming discipline now keeps the layout readable years later.

Some guides call LVM an extra layer of complexity you can skip. On a server, I disagree, and the 2am scenario is why. The first time a volume fills and you extend it live in three commands instead of scheduling downtime for a repartition, the small upfront effort has paid for itself many times over. Installers from the RHEL family default to LVM for exactly this reason. Set it up at install time, even if you carve only one volume to start, and you keep the option to grow open forever.

The honest caveat is the cloud, where the disk itself is virtual and you often resize the block device in the provider console, then grow the partition and filesystem. Even there LVM helps once you attach a second disk or want snapshots, but it is less essential than on hardware you cannot re-provision with a click. Match the tool to the platform, and on real servers that answer is LVM by default.

In a VM, add two small virtual disks, then build and grow a volume so the whole loop is muscle memory. Nothing here touches your host.

sudo pvcreate /dev/sdb /dev/sdc
sudo vgcreate vgtest /dev/sdb
sudo lvcreate -L 1G -n lvtest vgtest
sudo mkfs.ext4 /dev/vgtest/lvtest
sudo vgextend vgtest /dev/sdc
sudo lvextend -r -l +100%FREE /dev/vgtest/lvtest   # grow LV and FS together

Run df -h and lvs before and after the extend to watch both the volume and the filesystem grow.

A data volume is at 100 percent and you have a spare disk. How do you add space with no downtime?

If it is on LVM: pvcreate the new disk, vgextend the volume group onto it, lvextend the logical volume, then grow the filesystem with resize2fs or xfs_growfs, all while it stays mounted. The detail that separates real experience from theory is naming that last filesystem resize step, because forgetting it is the classic mistake where df still shows full after a successful lvextend. Mentioning lvextend -r to do both at once is a bonus.

Do I lose data when I set up LVM? Running pvcreate on a disk that holds data destroys it, so only initialize empty disks or ones you have backed up. Building volumes and extending them later is safe for the data already on other volumes; it is the initial format of a disk that wipes.

Can I really extend while the filesystem is mounted? Yes, that is the point. Both ext4 and XFS grow online, so lvextend followed by the filesystem resize happens with the volume in active use. Shrinking is the operation that needs care and, for ext4, an unmount.

What is the difference between /dev/vgdata/lv_web and /dev/mapper/vgdata-lv_web? They are two names for the same device. LVM creates the friendly vggroup/lvname path, and the device mapper underneath exposes the vg-lv form. Use either in commands and fstab.

Is LVM a replacement for RAID? No. RAID protects against a disk dying; LVM manages how space is pooled and sliced. They are often layered together, LVM on top of a RAID array, each doing its own job.

Should each mount get its own volume or one big one? Separate volumes for the parts that grow independently, like /var and /home, so one filling does not sink the whole box, and keep the root filesystem small and stable. One giant volume is simpler but gives you a single point where anything filling up takes everything down.

What is thin provisioning? LVM can also make thin volumes that consume real space only as data is written, which lets a pool present more capacity than it physically has. It is a genuine tool for dense setups, but it needs monitoring so the pool never actually runs dry underneath the volumes. Leave it until standard volumes feel routine.

How do I see the whole picture quickly? Run pvs, vgs, and lvs for a one line summary of each layer, or the longer pvdisplay, vgdisplay, and lvdisplay for full detail. Start with the short ones.

Storage is no longer a decision frozen at install time; you can grow a full volume onto a new disk while the server keeps running. The last technical part turns inward to the tool you have used in every one of these lessons, the shell itself, and how to shape its environment so it works the way you do. Work the series in order from the Complete Guide.

LVM manual page, man7.org
lvextend manual page, man7.org
Configuring and managing logical volumes, Red Hat