LFCS Storage Management Practice Question
A file server has an XFS filesystem on /dev/vg_data/lv_share that is nearly full. The volume group has 50 GB of free space. The administrator runs lvextend -L +20G /dev/vg_data/lv_share, which succeeds. However, df -h still reports the original size. What should the administrator do next to make the additional space usable?
⚠ Common exam trap
The trap here is assuming that lvextend automatically grows the filesystem, when in fact it only resizes the logical volume and a separate filesystem-specific step is needed.
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
✓
Run xfs_growfs /mountpoint, where /mountpoint is the current mount point of the filesystem.
After extending an LV that hosts an XFS filesystem, the filesystem itself must be grown separately. The XFS-specific tool is xfs_growfs, which is invoked with the mount point and can be run while the filesystem is mounted. This expands the filesystem to use the additional space, after which df will show the new size.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Run partprobe /dev/vg_data/lv_share to make the kernel reread the partition table.
Why it's wrong here
partprobe is used to inform the kernel of partition table changes on a whole disk device; it is irrelevant for an LVM logical volume, which is not partitioned in that sense. Even if it ran, it would not grow the XFS filesystem. The real issue is that the filesystem layer has not been told to expand into the new space.
- ✗
Run resize2fs /dev/vg_data/lv_share to expand the filesystem to the new size.
Why it's wrong here
resize2fs is the tool for ext2/ext3/ext4 filesystems, not XFS. Running it against an XFS filesystem will fail with an error because the on-disk metadata is not ext-style. This option is plausible because resize2fs is commonly used after lvextend on ext4, but it does not apply to the XFS filesystem in this scenario.
- ✓
Run xfs_growfs /mountpoint, where /mountpoint is the current mount point of the filesystem.
Why this is correct
XFS requires an explicit grow operation after the underlying block device is enlarged. xfs_growfs is run against the mount point (not the device) and expands the filesystem to fill the available space on the logical volume. This is the correct next step because lvextend only resized the LV, leaving the XFS filesystem at its old size.
- ✗
Unmount the filesystem, run lvresize --resizefs /dev/vg_data/lv_share, then remount it.
Why it's wrong here
lvresize --resizefs can grow the filesystem simultaneously with the LV, but the LV has already been extended. Unmounting is unnecessary and disruptive for an XFS filesystem that supports online growth. While lvresize with --resizefs works for some filesystems, the immediate correct action after an already-completed lvextend is simply to grow XFS online.
Go deeper
Related to this question
About these practice questions
This LFCS question is part of Courseiva's 406-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Linux Foundation exam blueprint
This LFCS practice question is part of Courseiva's free Linux Foundation 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 LFCS exam.