Linux storage problems become much easier when you identify the layer that is actually failing. A disk can contain partitions; partitions or disks can become RAID members; block devices can become LVM physical volumes; volume groups can provide logical volumes; logical volumes can hold filesystems; and filesystems are mounted into the directory tree. A symptom at the top may originate several layers below.

The current XK0-006 Linux+ exam expects administrators to manage and troubleshoot these layers rather than memorize isolated commands. The safest workflow is to map the storage stack first and modify it only after you know where the data lives.

Build a block-device map before changing anything

Start by discovering what the system actually sees. lsblk provides a useful tree of disks, partitions, LVM logical volumes, and mount points. Add columns such as filesystem type, UUID, size, and device model when needed. blkid identifies filesystem and volume metadata, while findmnt shows mounted filesystems and their sources.

Do not assume /dev/sdb is always the same physical disk after hardware changes. Persistent identifiers such as UUIDs and /dev/disk/by-* paths are safer for configuration. Virtualized and cloud systems can also present devices differently after attachment or reboot.

If LVM is involved, use pvs, vgs, and lvs to see physical volumes, volume groups, logical volumes, and free space. If software RAID is involved, inspect /proc/mdstat and mdadm --detail for array state.

This first inventory is the storage equivalent of drawing a network topology before troubleshooting routing. Without it, commands that appear routine can modify the wrong layer.

RAID provides device-level redundancy or performance behavior

Linux software RAID commonly uses mdadm to combine block devices into arrays. Different RAID levels distribute data, mirrors, and parity differently, which affects capacity, failure tolerance, and performance. Linux administration adds the operational tasks of assembling, monitoring, replacing, and rebuilding members.

A degraded array can continue serving data while one member has failed, depending on the RAID level. That is not a healthy steady state. Administrators should identify the failed member, verify which device is safe to replace, add the replacement, and monitor rebuild progress.

Do not confuse RAID with backup. RAID can keep a service available after some device failures, but it does not protect against accidental deletion, corruption propagated to every member, ransomware, or loss of the entire host. Backups remain a separate control.

When troubleshooting, determine whether the problem is an individual device, the RAID array, or a filesystem above it. Running filesystem repair on a component device that belongs to an assembled RAID array can cause severe damage.

LVM separates physical capacity from logical allocation

Logical Volume Manager adds an abstraction layer between physical storage and filesystems. Physical volumes contribute space to volume groups. Logical volumes allocate space from those volume groups and appear as block devices that can hold filesystems, swap, or other data.

This design makes growth flexible. You can add a new disk as a physical volume, extend the volume group, grow a logical volume, and then grow the filesystem. But each step affects a different layer. Extending the logical volume does not automatically guarantee that the filesystem uses the new space unless the command or workflow also expands the filesystem.

Use pvs, vgs, and lvs before expansion. Confirm free extents in the volume group and the correct logical volume path. Tools such as lvextend can allocate additional space; filesystem-specific tools then grow the filesystem.

LVM snapshots can provide point-in-time block-level views for certain workflows, but they are not a substitute for independent backup. Snapshot capacity and copy-on-write behavior must be monitored because a filled snapshot can become unusable.

ext4 and XFS require different resizing and repair habits

Filesystem type determines which commands are safe. ext4 filesystems can generally be grown and can also be shrunk when unmounted using appropriate tools and planning. XFS can be grown online but is not normally shrunk in place. Treating all Linux filesystems as interchangeable is a common administrative mistake.

For ext4, resize2fs is commonly used for resizing, and e2fsck performs consistency checking and repair. For XFS, xfs_growfs grows a mounted filesystem, while xfs_repair is used for repair. fsck.xfs does not perform the same kind of repair as e2fsck.

Before any repair, confirm whether the filesystem must be unmounted and whether recent backups exist. Filesystem repair changes metadata and can discard damaged structures to restore consistency. Running it casually on a mounted production filesystem can make the situation worse.

Always verify the filesystem type with lsblk -f, blkid, or findmnt before selecting a repair tool. “Linux filesystem” is not specific enough for a safe command.

Expansion is a sequence from lower layers to upper layers

Suppose a logical volume holding /var is full and the volume group has free space. The correct process is to confirm the layout, extend the logical volume, grow the filesystem using the correct filesystem tool, and verify the resulting capacity. If the volume group lacks free space, a lower layer must be expanded first by adding or growing a physical volume.

Cloud environments often add another step because the virtual disk must be enlarged in the provider platform before the guest sees additional sectors. A partition may also need to be extended before LVM or the filesystem can consume the space.

This “bottom up” expansion model prevents confusion: device capacity → partition or RAID → LVM physical volume → volume group → logical volume → filesystem → mounted usable space.

After each step, verify what changed. lsblk, pvs, vgs, lvs, and df -hT show different layers. df reports filesystem space, not raw device capacity. A larger disk with an unchanged filesystem will not show more available space in df.

Mount failures require source, filesystem, and option checks

A filesystem can be healthy but unavailable because it failed to mount. findmnt, mount, lsblk -f, and the journal help identify the source, target, filesystem type, and error. Common causes include a wrong UUID in /etc/fstab, an unavailable network filesystem, an unsupported option, a missing mount-point directory, filesystem damage, or dependency timing during boot.

Edit /etc/fstab carefully. A syntax or device error can delay boot or send a system into emergency mode. Prefer persistent identifiers rather than volatile device names. After editing, test with mount -a or an equivalent controlled validation rather than waiting for the next reboot to discover a mistake.

systemd generates mount units from fstab, so the journal can provide useful boot-time error context. Network mounts may also need appropriate ordering or automount behavior to avoid failures when networking is not yet usable.

When a mount fails, do not jump directly to filesystem repair. First establish whether the block device exists, whether its identifiers match the configuration, and whether the filesystem is actually damaged.

Full filesystems and full inodes are different failures

A filesystem can report “no space left on device” because data blocks are full or because available inodes are exhausted. df -h shows block usage, while df -i shows inode usage. A workload that creates millions of small files can exhaust inodes while substantial byte capacity remains.

Use du carefully to find where space is consumed, remembering that deleted files can remain allocated while a process still has them open. Tools such as lsof can reveal deleted-but-open files. Log rotation failures, runaway application output, caches, container layers, and temporary files are common causes of unexpected growth.

Also compare du and df results. Large discrepancies can point toward open deleted files, mount boundaries, reserved blocks, snapshots, or other allocation behavior.

The correct remediation depends on the cause. Deleting random files can break applications. Expanding storage may postpone a runaway logging problem without fixing it. Treat capacity alarms as diagnostic evidence, not simply a request to add disk space.

Repair decisions should protect data before convenience

When storage is damaged, the order of actions matters. First identify the affected layer and stop writes if continued activity can worsen corruption. Preserve backups, snapshots, or images where appropriate. Then use the repair tool designed for that layer.

A failed disk in RAID calls for array recovery, not immediate filesystem repair on the failed member. A damaged LVM metadata configuration may require LVM recovery procedures. A filesystem inconsistency requires filesystem-specific checking. A wrong fstab entry requires configuration correction rather than storage repair.

If evidence suggests hardware failure, inspect SMART or platform health information and replace unreliable devices. Repeated filesystem corruption can be a symptom of failing storage, memory problems, power loss, or unsafe shutdown behavior rather than a filesystem bug.

Production recovery should prioritize data integrity and reversibility. Commands that destroy signatures, recreate filesystems, force array assembly, or overwrite metadata should be used only when you understand the expected effect and have a recovery path.

Troubleshoot the storage stack from symptom to layer

A disciplined Linux storage workflow starts with the symptom—full filesystem, failed mount, degraded RAID, missing logical volume, I/O error—and maps it onto the layered design. Discover devices with lsblk; inspect RAID with mdadm; inspect LVM with pvs, vgs, and lvs; identify filesystems with blkid or lsblk -f; inspect mounts with findmnt; compare capacity with df; and use the journal for kernel and mount errors.

Only after the layer is identified should you resize, repair, replace, or reconfigure. That approach prevents destructive category errors such as repairing a RAID member instead of the array or growing a logical volume without growing the filesystem.

Linux storage is powerful because each layer solves a different problem: RAID changes redundancy, LVM changes allocation flexibility, filesystems organize data, and mounts integrate that data into the namespace. The same separation that gives flexibility also creates troubleshooting complexity. Build the map first, then act on the layer that is actually failing.