CompTIA XK0-006: Linux Storage and LVM in Practice

Linux storage administration is easier when the layers are kept distinct. A physical disk or virtual block device is not the same thing as a partition, an LVM physical volume, a volume group, a logical volume, a filesystem, or a mount point. Each layer solves a different problem. Logical Volume Manager adds a flexible allocation layer between raw devices and filesystems, which makes it possible to group capacity, create logical devices, and resize storage more easily than with fixed partitions alone.

For administrators following XK0-006, the important skill is not memorizing every LVM subcommand. It is understanding how storage state maps from hardware to mounted data. The Linux administration workflow should let an operator answer: which device backs this filesystem, how much free capacity exists at each layer, what can be expanded safely, which mount is persistent across reboot, and what evidence should be captured before a storage change.

Map the stack before changing anything

Start with discovery. `lsblk` shows block devices and their relationships; filesystem and mount tools show which devices are formatted and where they are mounted; `pvs`, `vgs`, and `lvs` summarize LVM objects. The names can look similar while representing very different layers. `/dev/sdb` may be a disk, `/dev/sdb1` a partition, that partition may be an LVM physical volume, the physical volume may belong to `vgdata`, and `vgdata/lvapp` may contain a filesystem mounted at `/srv/app`.

That map matters because the correct expansion depends on where free space exists. A filesystem can be full while the logical volume has no free extents, the volume group has abundant free extents, and the physical disk has unused unpartitioned space—or the opposite. Expanding the wrong layer does not automatically expand the layers above it. Administrators should know exactly which capacity pool is exhausted before issuing resize commands.

Record the current state before maintenance. Capture device sizes, PV/VG/LV summaries, filesystem usage, mount options, and relevant identifiers. A storage change is much easier to review or reverse when the operator has a “before” picture rather than relying on memory after several commands have modified metadata.

Understand PVs, VGs, and LVs as separate jobs

An LVM physical volume is a block device or partition initialized for LVM. Red Hat documentation describes the PV as the storage that contributes capacity into a volume group. A volume group combines one or more PVs into a shared pool of extents. Logical volumes allocate extents from that pool and present virtual block devices that can be formatted or used directly by applications.

This hierarchy creates flexibility. A volume group can aggregate multiple devices, and logical volumes can be created or extended from available extents without requiring the filesystem to know which physical device supplied them. The flexibility does not remove hardware failure domains, however. If a logical volume spans multiple physical devices without redundancy, the loss of one device can affect the whole logical volume.

Use naming that communicates purpose. Volume groups such as `vg_system` and `vg_data`, and logical volumes such as `lv_logs` or `lv_database`, are easier to operate than a collection of generic names. Names should remain stable even if the underlying physical devices change, which is one of LVM’s practical advantages.

Keep logical volume size and filesystem size separate

A logical volume is a block device; a filesystem is the structure that stores files on top of that device. Extending an LV creates more block space, but the filesystem may still need to be grown to use it. Some tools can perform both steps together, but administrators should understand that two operations are occurring. The exact filesystem command depends on the filesystem type, and not every filesystem supports the same resize behavior.

Before expanding, identify the filesystem, confirm that the volume group has enough free extents, and verify the supported growth procedure. Growing is generally easier than shrinking. Some filesystems cannot be reduced at all, and shrinking an LV before safely shrinking the filesystem can destroy data. Treat reduction as a separate high-risk procedure that requires filesystem-specific planning rather than as the reverse of an extension.

Capacity planning should include free space inside the filesystem and free extents in the volume group. Leaving all VG space allocated on day one removes one of LVM’s operational advantages. A modest reserve can be useful for controlled growth, snapshots, or urgent capacity needs, provided the team understands the tradeoff between reserve and available application space.

Treat snapshots as operational tools, not backups

LVM snapshots can preserve a point-in-time view of a logical volume by tracking changes after the snapshot is created. They can be useful during short maintenance operations, testing, or backup workflows, but they are not a substitute for an independent backup. The snapshot depends on the same storage stack and consumes space as blocks change. If its allocated space is exhausted, the snapshot may become unusable.

Snapshot behavior also affects performance and capacity. A busy database or write-heavy filesystem can generate changes quickly, so snapshot sizing should reflect the expected change rate and lifetime rather than a fixed percentage copied from another system. Monitor snapshot usage and remove temporary snapshots after their purpose is complete.

For recovery planning, keep the distinction between rollback convenience and durable protection. The article on storage and backup assumptions applies here as well: copies that share the same failure domain do not protect against every loss scenario. Backups should be recoverable even when the original host or storage stack is unavailable.

Mounts make storage usable to applications

A filesystem is not part of the normal path hierarchy until it is mounted. Temporary manual mounts are useful for testing, while persistent mounts require configuration such as `/etc/fstab` or an equivalent systemd mount definition. Use stable identifiers such as UUIDs or logical-volume paths where appropriate instead of relying on device names that can change between boots.

Mount options affect behavior and security. Read-only mounts, `noexec`, `nosuid`, and other options can reduce exposure in some use cases, but they should be applied with an understanding of the application’s needs. A service that legitimately executes files from a path will fail if `noexec` is added without testing. Storage security works best when mount policy, ownership, and service design agree.

Permissions remain a separate layer above the mount. If a filesystem is mounted correctly but a process cannot access a directory, investigate ownership, mode bits, ACLs, and security labels. The article on Linux permissions helps separate a filesystem problem from an access-control problem.

Monitor capacity before the filesystem reaches zero

Filesystems should be monitored with enough lead time to act safely. A warning at 99 percent utilization may arrive too late for a database or logging workload that grows quickly. Set thresholds based on growth rate, maintenance windows, and how expensive expansion is. Ten gigabytes of free space means something different on a log partition growing 5 GB per hour than on an archive growing 100 MB per week.

Inode exhaustion can also produce “no space left” symptoms even when blocks remain free, particularly when workloads create huge numbers of small files. Monitor both space and inode usage where the filesystem exposes them. LVM adds another capacity layer to watch: the volume group may be full even if some individual filesystems still have headroom, leaving no reserve for the one that needs emergency growth.

Routine checks are well suited to Bash automation. A script can collect filesystem use, inode use, VG free space, snapshot utilization, and mount state, then alert when defined thresholds are crossed. Keep the remediation decision separate unless the organization has a tested policy for automatic growth.

Plan storage changes around applications and recovery

Before extending, moving, or replacing storage, understand what the application expects. Databases may need quiescing for some backup methods, clustered services may have shared-storage rules, and container workloads may bind to host paths that disappear if a mount is changed. Coordinate the block-layer change with the service-layer change rather than assuming a successful LVM command means the application is safe.

Backups should be verified by restoration, not by job completion alone. A backup that captured files but not required ownership, ACLs, labels, database consistency, or boot configuration may not produce a usable service. Document the recovery path, including how the volume group and filesystems would be recreated if the underlying disk were lost.

The same discipline helps when decommissioning storage. Confirm that data has moved, mounts have been removed, no service still references the path, and LVM objects are no longer active before removing PVs or devices. Storage metadata is powerful; deliberate sequencing prevents an apparently “unused” device from turning out to be part of a larger volume group.

Troubleshoot from the mount downward

When an application reports a storage problem, begin with the symptom it actually sees: path missing, read-only filesystem, permission denied, input/output error, or no space. Check mount state and filesystem usage, then trace the mount to the LV, VG, PV, and physical or virtual device. Kernel logs can reveal device resets or filesystem errors that are invisible from a simple `df` output.

If storage is used by containers, remember that the container may see a bind mount or volume rather than the host path directly. The guide to container operations explains how namespace and ownership differences can make the same storage appear differently inside the workload. Verify both views before changing permissions or remounting.

LVM is most useful when it makes storage easier to reason about, not when it adds another layer of mystery. Administrators who can map device to PV to VG to LV to filesystem to mount can expand capacity deliberately, recognize failure domains, and recover with confidence. That layered understanding is more valuable than any single command sequence.