Offensive Security Researcher & Quantum Cryptography Analyst

Volume Management Concepts: From Physical Disks to Flexible Volumes

Abdul Wahab Junaid
Volume management concepts

Photo by Sergei Starostin on Pexels.com

Early in my career I resized a partition the hard way — backup, delete, recreate, restore — because the system I was working on had no volume manager at all. That experience is exactly why volume management exists, and why I still think it is one of the most underappreciated layers in the entire storage stack. This article walks through what volume management actually is, how it works internally, and how to use it well in real environments.

What Is Volume Management?

Volume management is the layer of software that sits between raw physical (or virtual) storage devices and the file systems or applications that consume them. Its job is to aggregate, partition, resize, and protect storage in a flexible way that does not require the rigid, disk-by-disk constraints of traditional partitioning.

Instead of a file system being tied to one physical disk or one fixed-size partition, a volume manager lets you combine multiple physical devices into pools, then carve out logical volumes from those pools that can grow, shrink, move, and be protected independently of the physical hardware underneath.

Core Building Blocks

Volume management terminology varies by platform, but the concepts map cleanly across Linux LVM, Windows Storage Spaces/Disk Management, and enterprise array-based volume managers.

ConceptLinux LVM TermWindows TermDescription
Physical storage unitPhysical Volume (PV)Physical DiskRaw disk or LUN contributing capacity
Aggregated poolVolume Group (VG)Storage PoolPool combining one or more physical volumes
Logical unit carved from poolLogical Volume (LV)Virtual DiskThe resizable, flexible volume presented to the OS/file system
Smallest allocation unitPhysical Extent (PE)Slab/Allocation UnitFixed-size chunk used for allocation bookkeeping

How Volume Management Works Internally

Step 1: Physical Volume Initialization

A raw disk or LUN is initialized with metadata that marks it as available for the volume manager to use. On Linux:

pvcreate /dev/sdb /dev/sdc

This writes a small metadata header identifying the disk as part of the LVM system, without touching the rest of the disk.

Step 2: Volume Group Creation

Multiple physical volumes are combined into a single pool of extents:

vgcreate vg_data /dev/sdb /dev/sdc

At this point, vg_data is a single logical pool of capacity, even though it physically spans two separate disks.

Step 3: Logical Volume Creation

A logical volume is carved out of the pool, and this is what actually gets formatted with a file system:

lvcreate -L 500G -n lv_app vg_data
mkfs.xfs /dev/vg_data/lv_app
mount /dev/vg_data/lv_app /app

Step 4: Online Resizing

This is where volume management really pays off. Growing a volume — assuming the underlying file system supports online growth (XFS and ext4 both do) — requires no downtime:

lvextend -L +100G /dev/vg_data/lv_app
xfs_growfs /app

Shrinking is more constrained (XFS cannot shrink at all; ext4 can but requires unmounting), which is a real operational limitation worth knowing before you design volumes too large.

Striping, Mirroring, and Concatenation Within Volume Management

Volume managers can implement RAID-like behavior in software, independent of any hardware RAID underneath:

# Create a striped logical volume across 3 physical volumes for performance
lvcreate -L 300G -i 3 -I 64 -n lv_striped vg_data

# Create a mirrored logical volume for redundancy
lvcreate -L 200G -m 1 -n lv_mirrored vg_data

Thin Provisioning at the Volume Manager Layer

Modern volume managers support thin logical volumes, where the logical size presented is larger than the physically allocated space, with real allocation happening on write:

lvcreate -L 1T --thinpool thin_pool vg_data
lvcreate -V 2T --thin -n lv_thin vg_data/thin_pool

Here, lv_thin appears as a 2TB volume to the OS, but physically only consumes space as data is actually written, up to the thin pool’s real capacity. Monitoring thin pool utilization becomes critical here — if the pool physically fills up while logical volumes still believe they have room, writes will fail or stall, which is a common and painful operational mistake.

Snapshots at the Volume Manager Layer

LVM (and most volume managers) support copy-on-write or redirect-on-write snapshots at the logical volume level, independent of any file-system-level or array-level snapshot capability:

lvcreate -L 50G -s -n lv_app_snap /dev/vg_data/lv_app

This creates a point-in-time, space-efficient snapshot of lv_app, commonly used before applying patches or upgrades so a rollback is possible without a full restore from backup.

Volume Management in Enterprise Storage Arrays

Beyond the host OS layer, enterprise arrays implement their own volume management concepts, generally with equivalent capabilities:

For example, on a Dell EMC PowerStore or Unity array, a storage pool aggregates physical drives, and individual thin LUNs are provisioned from that pool with independent size, performance policy, and protection settings — conceptually identical to LVM’s VG/LV relationship, just implemented in array firmware instead of host software.

Volume Management in Windows

Windows Storage Spaces implements the same underlying concepts:

# Create a storage pool from physical disks
New-StoragePool -FriendlyName "DataPool" -StorageSubsystemFriendlyName "Windows Storage*" -PhysicalDisks (Get-PhysicalDisk -CanPool $true)

# Create a virtual disk (volume) from the pool with mirroring
New-VirtualDisk -StoragePoolFriendlyName "DataPool" -FriendlyName "AppVDisk" -Size 500GB -ResiliencySettingName Mirror

# Format and assign a drive letter
Get-VirtualDisk -FriendlyName "AppVDisk" | Get-Disk | Initialize-Disk -PartitionStyle GPT -PassThru | New-Partition -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem NTFS

Capacity Calculation Example

Understanding how much usable capacity a volume group actually provides after mirroring or striping overhead is a common real-world calculation:

If you provision a 1.5TB striped volume across the remaining capacity and a 1TB thin volume with 2:1 expected over-subscription, your effective allocatable capacity planning looks like:

Total raw pool:        4.00 TB
Mirrored volume (usable):  1.00 TB (consumes 2.00 TB raw)
Remaining raw pool:     2.00 TB
Striped volume:         1.50 TB (consumes 1.50 TB raw, no redundancy)
Remaining raw pool:     0.50 TB
Thin volume (logical size): 1.00 TB (physical consumption grows over time, capped by remaining 0.50 TB pool)

This kind of table is exactly what you want to build before provisioning anything in production — it is the difference between a pool that lasts two years and one that unexpectedly fills up in two months.

Performance and Scalability Considerations

Common Mistakes

  1. Growing a volume without growing the underlying file system. lvextend alone does not resize XFS/ext4 — you must run xfs_growfs or resize2fs afterward.
  2. Over-subscribing thin pools without monitoring. Assuming average utilization will hold when a handful of thin volumes suddenly get written to heavily can fill a pool unexpectedly.
  3. Striping for performance without also planning redundancy. Striped volumes with no mirroring or underlying RAID have zero fault tolerance — a single disk failure loses the entire volume.
  4. Forgetting that some file systems cannot shrink. Planning volumes too large upfront on XFS-based systems means you are stuck; you would need to recreate the volume to shrink it.
  5. Not aligning volume manager stripe/extent sizes with underlying RAID stripe sizes, which can cause unnecessary read-modify-write penalties on the physical array.

Advantages of Proper Volume Management

Disadvantages / Trade-offs

Migrating Data Between Physical Volumes Without Downtime

One of the most practical everyday uses of a volume manager is migrating data off an aging or failing physical disk without taking the logical volume offline. On Linux LVM, this is a routine, well-supported operation:

# Add the new physical volume to the volume group
pvcreate /dev/sdd
vgextend vg_data /dev/sdd

# Migrate extents from the old physical volume to the new one, live
pvmove /dev/sdb /dev/sdd

# Once migration completes, remove the old physical volume from the group
vgreduce vg_data /dev/sdb
pvremove /dev/sdb

The logical volumes and the applications using them are never taken offline during this process — the volume manager transparently updates its extent mapping table as data moves, which circles back to the same indirection concept covered in the storage virtualization article. This is exactly the kind of operation that made the “backup, delete, recreate, restore” approach I mentioned at the start of this article completely unnecessary once volume management became standard practice.

Volume Manager Metadata Backup

Because the volume group’s metadata (which physical extents map to which logical volumes) is critical to data availability, it is worth backing it up separately from the data itself:

# LVM automatically maintains metadata backups, but you can also force one
vgcfgbackup vg_data

# In a disaster recovery scenario, metadata can be restored from backup
vgcfgrestore vg_data

Losing volume group metadata without a backup can make otherwise intact data on physical disks effectively inaccessible, since the mapping information describing how to reassemble logical volumes from physical extents would be gone — a good reminder that volume manager metadata deserves the same backup discipline as the data it describes.

FAQs

Q: Is LVM a replacement for RAID? Not fully — LVM can provide mirroring and striping similar to RAID 1 and RAID 0, but it lacks the parity-based redundancy of RAID 5/6 in most implementations. Many environments layer LVM on top of hardware or software RAID rather than replacing it.

Q: Can I resize a volume while it is mounted and in use? Growing is generally safe online with modern file systems (XFS, ext4, NTFS). Shrinking usually requires the volume to be unmounted, and some file systems (XFS) do not support shrinking at all.

Q: What happens if a thin provisioning pool runs out of physical space? Writes to thin volumes drawing from that pool will fail or stall, which can cause application errors or crashes. This is why thin pool capacity must be actively monitored with alerting well below 100%.

Summary

Volume management is the flexible middle layer that turns rigid physical disks into resizable, protectable, and movable logical volumes — whether you are working with Linux LVM, Windows Storage Spaces, or an enterprise array’s internal pool and LUN architecture. Understanding the physical-volume-to-volume-group-to-logical-volume relationship, along with striping, mirroring, and thin provisioning trade-offs, is fundamental to building a storage layout that can grow and adapt without painful downtime or data migrations.

References

Exit mobile version