LVM Hands On Example

The last chapter built the PV → VG → LV model conceptually. This chapter turns each of those three layers into an actual command, then goes further — extending a volume with a second disk, which is the entire reason LVM was worth learning in the first place.

Creating A Physical Volume: `pvcreate`

Starting from a fresh, unused disk — /dev/sdc in this example, confirmed empty with lsblk first, per the habit from earlier in this section:

sudo pvcreate /dev/sdc

This initializes the entire disk as a physical volume, writing LVM metadata onto it that marks it as available for LVM to manage. Note this example uses the whole disk directly rather than a partition on it — a genuinely common approach with LVM, since LVM itself handles the subdivision that partitioning would otherwise be responsible for.

Verify it:

sudo pvs

PV         VG   Fmt  Attr PSize  PFree
/dev/sdc        lvm2 ---  20.00g 20.00g

No VG listed yet — this PV exists but isn’t part of any volume group.

Creating A Volume Group: `vgcreate`

sudo vgcreate data_vg /dev/sdc

This creates a new volume group named data_vg, drawing its space from the physical volume just created. The name is yours to choose — pick something descriptive, since you’ll reference it in every command from here on.

sudo vgs

VG      #PV #LV #SN Attr   VSize  VFree
data_vg   1   0   0 wz--n- 20.00g 20.00g

Creating A Logical Volume: `lvcreate`

sudo lvcreate -L 5G -n data_lv data_vg

-L 5G sets the size, -n data_lv names it, and data_vg specifies which volume group to carve it out of. Note this deliberately doesn’t use the entire 20G volume group — 15G remains unallocated, available either for a second logical volume or for extending this one later.

sudo lvs

LV      VG      Attr       LSize
data_lv data_vg -wi-a-----   5.00g

Formatting And Mounting The Logical Volume

From here, everything is identical to working with a plain partition — a logical volume gets a device path, formatted and mounted exactly like /dev/sdb1 was in the mkfs and Mounting files earlier in this section:

sudo mkfs.ext4 /dev/data_vg/data_lv
sudo mkdir -p /mnt/data
sudo mount /dev/data_vg/data_lv /mnt/data

That /dev/data_vg/data_lv path — volume group name, then logical volume name — is how LVM devices are addressed, distinct from the /dev/sdX pattern used for plain disks and partitions. Add it to /etc/fstab exactly the same way as the earlier example, using its UUID from blkid rather than this path directly, for the same stability reasons covered in the Mounting chapter.

Extending: Adding A Second Disk

This is the payoff from the last chapter’s database scenario. Say /mnt/data is running low on space, and a second disk, /dev/sdd, has just been attached to the system.

Step one: bring the new disk into LVM, exactly like the first one:

sudo pvcreate /dev/sdd

Step two: extend the volume group to include it:

sudo vgextend data_vg /dev/sdd
sudo vgs

VFree on data_vg now reflects the additional space from /dev/sdd — the volume group’s pool has grown, without touching the logical volume or its filesystem yet.

Step three: extend the logical volume to actually claim some of that new space:

sudo lvextend -L +10G /dev/data_vg/data_lv

+10G adds 10G to the volume’s current size, rather than setting an absolute size — the + matters here the same way it did with chmod’s symbolic mode back in the Permissions section, expressing a relative change instead of an absolute one.

The Step People Forget: Resizing The Filesystem Itself

Extending the logical volume makes more raw space available — but the filesystem sitting on top of it doesn’t automatically know that space exists yet. This is a genuinely common point of confusion: lvextend succeeds, lvs shows the larger size, and yet df (covered properly in the next chapter) still shows the old, smaller amount of usable space, because the filesystem itself hasn’t been told to grow into the newly available room.

For ext4:

sudo resize2fs /dev/data_vg/data_lv

For xfs, the equivalent tool operates on the mount point, not the device path directly:

sudo xfs_growfs /mnt/data

Note

Recall from the Filesystems chapter: xfs can be grown but never shrunk. xfs_growfs reflects that directly — there’s no equivalent “shrink” command for xfs at all, on any device, LVM or not. If shrinking might ever be a requirement, that’s a real argument for ext4 over xfs on that specific volume.

Both resize2fs and xfs_growfs here are running against an already-mounted, in-use filesystem — both support this kind of online resize for growing, which is exactly why this whole sequence can typically happen with no downtime at all.

Cleaning Up

Tear the example down in the reverse order it was built, unmounting first:

sudo umount /mnt/data
sudo lvremove /dev/data_vg/data_lv
sudo vgremove data_vg
sudo pvremove /dev/sdc /dev/sdd

Remember to also remove the /etc/fstab entry if you added one during this walkthrough, and the mount -a habit from the Mounting chapter applies here just as much — verify the edit rather than assuming it’s correct.

Quick Reference

Layer	Create	List
Physical Volume	`pvcreate`	`pvs`
Volume Group	`vgcreate`	`vgs`
Logical Volume	`lvcreate`	`lvs`

Extending: vgextend (add a PV to a VG), lvextend (grow an LV), then resize2fs/xfs_growfs (grow the filesystem itself) — always in that order, since each step depends on the one before it having already happened.

What’s Next

You can now create, mount, and grow storage using either plain partitions or LVM, and you know which situations call for the added flexibility. The next chapter is more measurement than management: df and du, for actually seeing how much space is used and where it’s going.

Last updated on August 21, 2026

Logical Volume Management (LVM)Inspecting Disk Usage (df, du)