EX200 Create and configure file systems Practice Question
Exhibit
Refer to the exhibit. # df -hT /mnt/data Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/vg00-lvol0 xfs 50G 30G 20G 60% /mnt/data
The administrator wants to reduce the file system size to 40GB. Which command sequence should be used?
⚠ Common exam trap
Red Hat often tests the misconception that any file system can be shrunk using logical volume management tools like lvreduce, but XFS is a notable exception that requires full data migration to reduce its size.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
It is not possible to shrink an XFS file system
XFS is a high-performance 64-bit journaling file system that does not support online or offline shrinking. Once an XFS file system is created, its size cannot be reduced; the only way to reclaim space is to back up the data, destroy the file system, recreate it at the desired size, and restore the data. Therefore, any attempt to shrink an XFS file system using lvreduce or similar tools will corrupt the file system.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
It is not possible to shrink an XFS file system
Why this is correct
XFS file systems are designed to be grow-only. The on-disk structures, especially the B+tree metadata and dynamic inode allocation, do not support in-place shrinkage, and there is neither an xfs_shrink command nor an option in xfs_growfs to reduce the size. To reduce the size, you must back up the data with tools such as xfsdump, destroy or remove the logical volume, recreate it at the desired size, create a new XFS file system, and restore the data. Attempting to shrink a live XFS file system with any tool is unsupported and will lead to corruption.
- ✗
xfs_repair; lvreduce
Why it's wrong here
xfs_repair is a file system checking and repair utility, not a resize tool; it scans and fixes structural inconsistencies but cannot alter the geometry or shrink the file system. Running xfs_repair before lvreduce would simply return the file system to a consistent state at its existing size, and then lvreduce -L would shrink the underlying logical volume while the XFS metadata still describes the original, larger block range. That leaves the file system with a shorter device, causing metadata misreads and almost certain data loss when the file system later tries to access blocks past the new end of the LV. In short, repairing does not enable shrinking, and a subsequent lvreduce without a corresponding file system shrink is inherently destructive.
- ✗
umount /mnt/data; lvreduce -L 40G; mount; xfs_growfs
Why it's wrong here
Unmounting the file system is a necessary preliminary for any safe resize, but it does not make XFS shrinkable. Even with /mnt/data unmounted, lvreduce -L 40G truncates the logical volume while the XFS on-disk metadata still claims a larger size; when the volume is remounted, the file system will either fail to mount with superblock inconsistencies or immediately encounter corruption because its assumed block range exceeds the device. xfs_growfs can only increase the size of an XFS file system to fill a larger device; it has no capability to reduce the size. Because both operations are insufficient — lvreduce shrinks only the block device and xfs_growfs only grows — this sequence cannot achieve the desired 40G file system and will damage the data.
- ✗
lvreduce -L 40G /dev/vg00/lvol0; xfs_growfs
Why it's wrong here
lvreduce -L 40G /dev/vg00/lvol0 performed while the XFS file system is still mounted is dangerous because it cuts off logical blocks that the file system considers part of its valid space; the XFS superblock and allocation groups still reference those blocks, so any subsequent access to them will go beyond the device and cause I/O errors. Then xfs_growfs is typically used to expand the file system after an lvextend, but here the device is smaller than the file system expects, and xfs_growfs will attempt to grow to fill the new volume size — which is still smaller than the original, so it cannot help and may even worsen the inconsistency. The correct order for a non-shrinkable FS is never to lvreduce without a file system that can shrink; for XFS you must recreate the file system and restore data. Thus this command pair both risks immediate corruption and fails to reduce the logical file system properly.
Go deeper
Related to this question
About these practice questions
Courseiva writes every EX200 question from scratch — 127 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This EX200 practice question is part of Courseiva's free Red Hat certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the EX200 exam.