RAID levels<\/a> 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.<\/p>\nA 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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
LVM separates physical capacity from logical allocation<\/h2>\n
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.<\/p>\n
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.<\/p>\n
Use pvs<\/code>, vgs<\/code>, and lvs<\/code> before expansion. Confirm free extents in the volume group and the correct logical volume path. Tools such as lvextend<\/code> can allocate additional space; filesystem-specific tools then grow the filesystem.<\/p>\nLVM 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.<\/p>\n
ext4 and XFS require different resizing and repair habits<\/h2>\n
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.<\/p>\n
For ext4, resize2fs<\/code> is commonly used for resizing, and e2fsck<\/code> performs consistency checking and repair. For XFS, xfs_growfs<\/code> grows a mounted filesystem, while xfs_repair<\/code> is used for repair. fsck.xfs<\/code> does not perform the same kind of repair as e2fsck<\/code>.<\/p>\nBefore 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.<\/p>\n
Always verify the filesystem type with lsblk -f<\/code>, blkid<\/code>, or findmnt<\/code> before selecting a repair tool. \u201cLinux filesystem\u201d is not specific enough for a safe command.<\/p>\nExpansion is a sequence from lower layers to upper layers<\/h2>\n
Suppose a logical volume holding \/var<\/code> 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.<\/p>\nCloud 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.<\/p>\n
This \u201cbottom up\u201d expansion model prevents confusion: device capacity \u2192 partition or RAID \u2192 LVM physical volume \u2192 volume group \u2192 logical volume \u2192 filesystem \u2192 mounted usable space.<\/p>\n
After each step, verify what changed. lsblk<\/code>, pvs<\/code>, vgs<\/code>, lvs<\/code>, and df -hT<\/code> show different layers. df<\/code> reports filesystem space, not raw device capacity. A larger disk with an unchanged filesystem will not show more available space in df<\/code>.<\/p>\nMount failures require source, filesystem, and option checks<\/h2>\n
A filesystem can be healthy but unavailable because it failed to mount. findmnt<\/code>, mount<\/code>, lsblk -f<\/code>, and the journal help identify the source, target, filesystem type, and error. Common causes include a wrong UUID in \/etc\/fstab<\/code>, an unavailable network filesystem, an unsupported option, a missing mount-point directory, filesystem damage, or dependency timing during boot.<\/p>\nEdit \/etc\/fstab<\/code> 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<\/code> or an equivalent controlled validation rather than waiting for the next reboot to discover a mistake.<\/p>\nsystemd generates mount units from fstab<\/code>, 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.<\/p>\nWhen 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.<\/p>\n
Full filesystems and full inodes are different failures<\/h2>\n
A filesystem can report \u201cno space left on device\u201d because data blocks are full or because available inodes are exhausted. df -h<\/code> shows block usage, while df -i<\/code> shows inode usage. A workload that creates millions of small files can exhaust inodes while substantial byte capacity remains.<\/p>\nUse du<\/code> 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<\/code> can reveal deleted-but-open files. Log rotation failures, runaway application output, caches, container layers, and temporary files are common causes of unexpected growth.<\/p>\nAlso compare du<\/code> and df<\/code> results. Large discrepancies can point toward open deleted files, mount boundaries, reserved blocks, snapshots, or other allocation behavior.<\/p>\nThe 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.<\/p>\n
Repair decisions should protect data before convenience<\/h2>\n
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.<\/p>\n
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<\/code> entry requires configuration correction rather than storage repair.<\/p>\nIf 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.<\/p>\n
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.<\/p>\n
Troubleshoot the storage stack from symptom to layer<\/h2>\n
A disciplined Linux storage workflow starts with the symptom\u2014full filesystem, failed mount, degraded RAID, missing logical volume, I\/O error\u2014and maps it onto the layered design. Discover devices with lsblk<\/code>; inspect RAID with mdadm<\/code>; inspect LVM with pvs<\/code>, vgs<\/code>, and lvs<\/code>; identify filesystems with blkid<\/code> or lsblk -f<\/code>; inspect mounts with findmnt<\/code>; compare capacity with df<\/code>; and use the journal for kernel and mount errors.<\/p>\nOnly 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.<\/p>\n
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.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[29,49,36,108],"tags":[],"class_list":["post-3085","post","type-post","status-publish","format-standard","hentry","category-certifications","category-comptia-certifications","category-systems-infrastructure","category-exam-xk0-006"],"_links":{"self":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3085","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=3085"}],"version-history":[{"count":1,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3085\/revisions"}],"predecessor-version":[{"id":3586,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/posts\/3085\/revisions\/3586"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/media?parent=3085"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/categories?post=3085"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.biz\/blog\/wp-json\/wp\/v2\/tags?post=3085"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}