{"id":3460,"date":"2026-10-08T12:11:45","date_gmt":"2026-10-08T12:11:45","guid":{"rendered":"https:\/\/www.examtopics.biz\/blog\/lpi-101-500-linux-disks-filesystems\/"},"modified":"2026-10-11T17:40:49","modified_gmt":"2026-10-11T17:40:49","slug":"lpi-101-500-linux-disks-filesystems","status":"publish","type":"post","link":"https:\/\/www.examtopics.biz\/blog\/lpi-101-500-linux-disks-filesystems\/","title":{"rendered":"LPI 101-500: Linux Disks and Filesystems"},"content":{"rendered":"

Linux storage administration is easiest to understand as a chain of layers. A disk or virtual block device provides sectors. A partition table divides that device into regions. Logical Volume Manager can add another abstraction layer for flexible allocation. A filesystem organizes files and metadata inside a block device. A mount attaches that filesystem to the directory tree. Finally, \/etc\/fstab<\/code> describes filesystems that should be mounted automatically and the options used to mount them.<\/p>\n

The current LPIC-1 101-500<\/a> objectives still include devices, Linux filesystems, and the Filesystem Hierarchy Standard. That makes storage a core skill in the LPI certification<\/a> path rather than a distribution-specific specialty. The practical goal is to diagnose which layer is wrong before using a command that changes on-disk state.<\/p>\n

Identify the device before changing the layout<\/h2>\n

Modern Linux hosts can expose local SATA or NVMe disks, virtual disks, SAN LUNs, cloud block volumes, multipath devices, encrypted containers, software RAID, and logical volumes. Device names therefore should not be treated as permanent identities. The same physical or virtual storage may appear through different paths depending on hardware discovery order and platform configuration.<\/p>\n

Before partitioning, collect evidence: device size, model or virtual source, existing partition table, filesystem signatures, mount state, and whether the device participates in LVM, RAID, encryption, or multipath. A destructive partitioning command used against the wrong device can erase metadata that higher layers depend on. Good administrators verify the whole stack before writing a new partition table.<\/p>\n

Partition tables describe where partitions begin and end. GPT is common on modern systems and supports large disks and many partitions; MBR remains relevant for older systems and compatibility scenarios. A partition itself does not automatically become a filesystem. It can hold a filesystem, an LVM physical volume, swap space, RAID metadata, or other structures.<\/p>\n

LVM separates physical capacity from logical allocation<\/h2>\n

Logical Volume Manager adds flexibility by grouping physical storage into volume groups and allocating logical volumes from those pools. The key objects are physical volumes, volume groups, and logical volumes. A physical volume contributes capacity; a volume group aggregates that capacity; a logical volume consumes a chosen amount and presents a block device that can host a filesystem or other workload.<\/p>\n

The advantage is operational flexibility. A volume can often be extended without redesigning the original partition layout, and capacity can be managed from a pool instead of one fixed partition at a time. But LVM does not remove lower-level dependencies. If the physical device fails, every logical volume that depends on it can be affected unless redundancy exists elsewhere in the design.<\/p>\n

It is also important not to confuse LVM with RAID. LVM is primarily about allocation and logical block-device management, while RAID is about a data-placement and redundancy strategy across devices. RAID levels<\/a> provide useful background, but an administrator should verify whether redundancy is provided by hardware RAID, software RAID, a storage array, the cloud platform, or not at all before assuming an LVM layout is protected.<\/p>\n

Creating a filesystem establishes a new metadata structure<\/h2>\n

Commands such as mkfs<\/code> initialize a block device with a filesystem format. That is a destructive operation when run on a device that already contains useful data. The filesystem type determines features, limits, repair tools, metadata behavior, and supported mount options. Common Linux systems use filesystems such as ext4 and XFS, while other filesystems may be selected for specialized workloads.<\/p>\n

Formatting is only the beginning. The administrator should know how to inspect a filesystem, check free space and inode use, identify filesystem type, and determine whether a repair tool is appropriate. A filesystem that is nearly full can fail writes even when the underlying disk is healthy. A filesystem with exhausted inodes can report no space for new files despite having free data blocks. These are different problems and need different evidence.<\/p>\n

Filesystem repair must respect filesystem state. Running a repair utility against a mounted writable filesystem can be unsafe unless the tool explicitly supports that operation. Recovery procedures should therefore determine whether the filesystem can be unmounted, whether the system needs rescue mode, and whether a current backup exists before invasive repair begins.<\/p>\n

Mounts connect storage to the single Linux directory tree<\/h2>\n

Linux does not present filesystems as separate drive letters. A filesystem becomes accessible when mounted at a directory called a mount point. The same storage can be mounted at different directory paths, and a mount can temporarily hide files that were already present under the mount point. That can confuse troubleshooting if an administrator assumes those underlying files were deleted.<\/p>\n

Mount options influence behavior. Read-only versus read-write mode, permission-related options, device or execution restrictions, and filesystem-specific settings can materially affect applications. When an application reports permission or write errors, confirm the mount options as well as ordinary Unix file permissions.<\/p>\n

Temporary mounts entered interactively disappear across reboot unless persistent configuration exists. For persistent local filesystems, \/etc\/fstab<\/code> commonly defines the source, mount point, filesystem type, options, dump setting, and filesystem-check order. An incorrect fstab<\/code> entry can delay or disrupt boot, so changes should be validated before the next restart.<\/p>\n

UUIDs are more stable than discovery-order device names<\/h2>\n

Device paths such as \/dev\/sdb1<\/code> can change when hardware order changes, storage is added, or virtual devices are enumerated differently. Filesystem UUIDs and other persistent identifiers help decouple mount configuration from that discovery order. Administrators should know how to query filesystem identity and compare it with the identifier configured in \/etc\/fstab<\/code>.<\/p>\n

This is a common recovery scenario: the filesystem is healthy, but the boot process cannot mount it because the configured UUID is wrong after cloning, recreating, or reformatting a filesystem. Another system may contain duplicate UUIDs after block-level cloning, causing ambiguous device selection. The correct repair depends on understanding identity, not simply replacing UUID-based configuration with a fragile device path.<\/p>\n

Labels can also provide readable identifiers, but they still need governance to remain unique where uniqueness matters. Persistent naming is a design choice that should survive ordinary device enumeration changes while remaining understandable during recovery.<\/p>\n

Troubleshoot storage by walking down and up the stack<\/h2>\n

When a filesystem will not mount, start with whether the block device exists. Then verify the intended partition or logical volume, inspect filesystem signatures, confirm the mount point, and compare the requested filesystem type and options with reality. If the filesystem mounted but an application cannot write, check free space, inode availability, mount mode, ownership, permissions, security controls, and application-specific constraints.<\/p>\n

When the system fails to boot after a storage change, inspect the failed mount unit or boot message before editing fstab<\/code> blindly. A missing removable device, invalid UUID, unsupported option, failed LVM activation, or damaged filesystem can all create similar symptoms at a superficial level. Rescue environments are useful because they let an administrator inspect storage without relying on the normal boot target.<\/p>\n

Capacity problems require the same layered thinking. Adding a new virtual disk does not automatically enlarge a partition, physical volume, volume group, logical volume, and filesystem. Each layer may need an explicit change. Likewise, extending a logical volume without extending its filesystem can leave the application-visible capacity unchanged.<\/p>\n

Build storage skills by practicing reversible observations first<\/h2>\n

LPIC-1 storage preparation should emphasize inspection before modification. Practice listing block devices, identifying filesystem signatures, showing UUIDs, examining mount tables, reading fstab<\/code>, viewing LVM objects, and checking free space before practicing creation and resizing in disposable virtual machines. That sequence develops the habit of proving state before changing it.<\/p>\n

Then build controlled scenarios: add a virtual disk, create a GPT partition, initialize LVM, create a filesystem, mount it temporarily, add a UUID-based persistent entry, reboot, and verify the result. Introduce one error at a time\u2014a wrong UUID, missing mount point, exhausted filesystem, or inactive volume group\u2014and diagnose it from evidence. Storage administration becomes much safer when every command is connected to a specific layer and expected state transition.<\/p>\n

Swap and the filesystem hierarchy belong in the same storage mental model<\/h2>\n

Not every disk region is mounted as a normal filesystem. Swap provides backing space for virtual-memory management and can exist in a dedicated partition, logical volume, or file. Its presence does not increase physical RAM, and heavy swapping can signal memory pressure that harms application performance. Administrators should know how to identify active swap, distinguish it from ordinary mounted storage, and verify whether persistent swap configuration still points to a valid device after storage changes.<\/p>\n

The Filesystem Hierarchy Standard adds another layer of meaning to storage design. Mounting a separate filesystem at \/var<\/code>, \/home<\/code>, or another path changes the failure and capacity boundary for data under that directory. A full \/var<\/code> can stop logs, databases, or package operations even when the root filesystem has free space. Likewise, a separate \/home<\/code> can remain intact during some operating-system rebuild workflows. Capacity monitoring therefore needs to consider each mounted filesystem individually rather than reporting only total disk capacity.<\/p>\n

When planning persistent mounts, consider what should happen if a noncritical filesystem is unavailable at boot. Some mounts are essential to system operation; others can be configured so a missing remote or removable device does not block startup indefinitely. That policy belongs in the design before the failure, not as an emergency edit after the host drops into recovery mode.<\/p>\n","protected":false},"excerpt":{"rendered":"

Linux storage administration is easiest to understand as a chain of layers. A disk or virtual block device provides sectors. A partition table divides that […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[29,77,36],"tags":[],"class_list":["post-3460","post","type-post","status-publish","format-standard","hentry","category-certifications","category-lpi-certifications","category-systems-infrastructure"],"_links":{"self":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3460","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/comments?post=3460"}],"version-history":[{"count":1,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3460\/revisions"}],"predecessor-version":[{"id":3961,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3460\/revisions\/3961"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/media?parent=3460"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/categories?post=3460"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/tags?post=3460"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}