LVM is a storage abstraction layer that lets you manage physical storage devices as a pool of resources, from which you can carve out logical volumes. The most surprising thing about LVM is that you can resize a logical volume while it’s mounted and in use, and most of the time, it just works without a hitch.
Let’s see it in action. Imagine we have a physical disk partitioned into two Physical Volumes (PVs): /dev/sda1 and /dev/sdb1.
# See our Physical Volumes
sudo pvs
# Output might look like:
# PV VG Fmt Attr PSize PFree
# /dev/sda1 myvg lvm2 a-- <10.00g <10.00g
# /dev/sdb1 myvg lvm2 a-- <20.00g <20.00g
We have a Volume Group (VG) named myvg that spans both PVs. From this VG, we’ve created a Logical Volume (LV) called data_lv in the myvg group.
# See our Logical Volumes
sudo lvs
# Output might look like:
# LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%i
# data_lv myvg -wi-a----- 25.00g
This data_lv is mounted at /mnt/data.
# Check the mount point
mount | grep /mnt/data
# Output might look like:
# /dev/mapper/myvg-data_lv on /mnt/data type ext4 (rw,relatime)
Now, let’s say we need more space on /mnt/data. We can add another physical disk, partition it (e.g., /dev/sdc1), and add it to our Volume Group.
# Initialize the new partition as a Physical Volume
sudo pvcreate /dev/sdc1
# Add the new PV to the existing VG
sudo vgextend myvg /dev/sdc1
# Verify the VG has grown
sudo pvs
# PV VG Fmt Attr PSize PFree
# /dev/sda1 myvg lvm2 a-- <10.00g <10.00g
# /dev/sdb1 myvg lvm2 a-- <20.00g <20.00g
# /dev/sdc1 myvg lvm2 a-- <30.00g <30.00g
With the VG expanded, we can now extend our logical volume data_lv. We can extend it by a specific amount or to use all available free space in the VG. Let’s add 10GB.
# Extend the LV by 10GB
sudo lvextend -L +10G /dev/myvg/data_lv
# Or extend to use all free space:
# sudo lvextend -l +100%FREE /dev/myvg/data_lv
Crucially, since this data_lv is mounted and in use, we need to tell the filesystem on it to recognize the new space. For ext4, this is done with resize2fs.
# Resize the filesystem
sudo resize2fs /dev/myvg/data_lv
Now, if we check the disk space on /mnt/data, we’ll see the increased size.
# Check filesystem size
df -h /mnt/data
# Output will now show the larger size (e.g., 35GB instead of 25GB)
LVM works by abstracting physical storage. Physical Volumes (PVs) are the actual storage devices or partitions. These PVs are then grouped into Volume Groups (VGs). Logical Volumes (LVs) are then carved out of these VGs. When you extend an LV, you’re essentially telling LVM to allocate more blocks from the VG’s free space to that LV. The lvextend command updates LVM’s metadata to reflect this change. The resize2fs command then interacts with the filesystem driver to expand the filesystem’s internal structures to occupy these newly allocated blocks. This separation of concerns is why you can often resize LVs on the fly; the filesystem only needs to be told about the new space, and LVM handles the underlying block allocation.
A common pitfall is forgetting to resize the filesystem after extending the logical volume. If you only run lvextend, the OS sees a larger block device, but the filesystem on top of it still thinks it’s the old size, and you won’t be able to write data beyond the original partition boundary. The resize2fs command is filesystem-specific; for XFS, you’d use xfs_growfs.
The magic of LVM’s on-the-fly resizing relies on the filesystem driver being able to handle growing its structures while the filesystem is active. Not all filesystems support this, and some older versions of filesystems might have limitations. For example, while ext4 is generally robust, extremely large filesystems or specific configurations might introduce edge cases. The underlying LVM layer itself is designed to be dynamic, but the filesystem on top is the ultimate arbiter of whether a resize can occur without unmounting.
The next hurdle you’ll likely face is understanding LVM snapshots, which allow you to create point-in-time copies of your logical volumes.