LVM

Most important commands to remember

• pvs — inspect physical volumes.
• vgs — inspect volume groups and their unallocated space.
• lvs — inspect logical volumes and allocation types.

Commands and flags

Command or option	Meaning
sudo	Run the read-only reports with device access privileges.
-o	Select the comma-separated report fields.
pv_name,vg_name,pv_size,pv_free	Physical device, owning group, size, and free allocation space.
vg_name,vg_size,vg_free	Group name, total size, and unallocated group space.
lv_name,vg_name,lv_size,segtype	Logical volume, group, logical capacity, and segment type.
pool_lv,data_percent,metadata_percent	Associated pool and relevant thin-pool usage percentages where applicable.

Displayed size suffixes indicate LVM’s units. A blank percentage field means it is not available or applicable for that row, not automatically zero usage.

The concepts that matter

1. LVM adds a mapping layer

The Logical Volume Manager sits between storage devices and consumers such as filesystems. A physical volume, or PV, is a block device prepared for LVM. A volume group, or VG, combines allocation capacity from one or more PVs.

A logical volume, or LV, exposes a usable block device carved from that group. This indirection lets the logical arrangement differ from individual disk boundaries. It does not erase the physical devices’ capacity or failure characteristics.

2. Free group space is not free filesystem space

LVM tracks allocation in chunks called extents. Free extents in a volume group can be assigned to logical volumes. Space already assigned to an LV may contain a filesystem with its own used and free blocks.

Growing the LV gives its consumer a larger block device; the filesystem may need a separate supported growth operation. Shrinking is especially sensitive because the filesystem must remain within the reduced device. An LVM report alone cannot tell you how much room a directory has for new files.

3. Thin provisioning separates advertised and allocated capacity

A thin LV can present a logical size larger than the physical data currently allocated to it. Writes consume capacity from a shared thin pool, and that pool also needs metadata to track mappings.

This makes utilization flexible but creates a shared exhaustion risk. Monitor both data and metadata usage, not just each LV’s advertised size. Multiple thin volumes can compete for the same remaining pool capacity.

4. Snapshots and redundancy solve different problems

An LVM snapshot preserves a point-in-time block view using snapshot-specific mechanisms. It can support a backup workflow, but depends on underlying storage and available capacity. Application consistency may require coordination before taking the snapshot.

A snapshot on the same storage is not an independent backup. Likewise, simply combining disks into a VG does not provide redundancy. Linear, striped, mirrored, and RAID layouts have different failure behavior; inspect the actual layout rather than inferring protection from the name LVM.

One small example

Optional: inspect an existing Linux LVM installation. These are reporting commands; they do not initialize disks, resize volumes, or create snapshots.

sudo pvs -o pv_name,vg_name,pv_size,pv_free
sudo vgs -o vg_name,vg_size,vg_free
sudo lvs -o lv_name,vg_name,lv_size,segtype,pool_lv,data_percent,metadata_percent

Match vg_name across the reports to follow PV → VG → LV. Compare group free space with logical volume sizes without treating either as filesystem free space. Inspect segtype for the allocation layout.

For thin pools, examine both usage percentages; a high metadata percentage can matter even when data usage is lower. Hosts without LVM may produce no rows. These reports establish the allocation structure, not filesystem health, application consistency, or a tested backup. No cleanup is required.

Keep this idea: LVM maps physical capacity into logical block devices; allocation, filesystem space, and data protection are separate layers.