I85PREP
⌘ K
RHCSA study materials
RHCSA study resources

Growing an XFS Volume After a Hypervisor Disk Expansion

RHCSA · Put your knowledge to work in context.

All case studies

Growing an XFS Volume After a Hypervisor Disk Expansion

A RHEL 9 virtual machine hosts an application that writes to /var/log/app, a single XFS filesystem on logical volume /dev/vgdata/lvapp (4.0 GB). The volume group vgdata has exactly one physical volume: the whole disk /dev/vdb, 20 GB, with no partition table. The filesystem is mounted through an /etc/fstab entry that uses a UUID. Overnight the storage team expanded /dev/vdb to 50 GB in the hypervisor. df -h still reports 4.0G total, the filesystem is at 100% and the application has stopped logging. pvdisplay still shows 20.00 GiB for /dev/vdb and vgs reports 0 free. A junior admin proposes rebooting so the kernel notices the new size, but the application has a 15-minute maintenance window and no downtime is allowed.

1. Bring the new capacity into use and grow /var/log/app to 25 GB with no unmount and no reboot. Give the exact command sequence and justify each step.

Read the worked answer

There are three independent layers that each have to be told about the new size: the kernel's view of the block device, the LVM physical volume, and the filesystem.

# 1. make the kernel re-read the device size
echo 1 > /sys/class/block/vdb/device/rescan   # or: rescan-scsi-bus.sh
lsblk /dev/vdb                                # must now show 50G

# 2. grow the PV so vgdata actually owns the new extents
pvresize /dev/vdb
pvs; vgs                                      # VFree should be ~46G

# 3. grow the LV, then the filesystem
lvextend -L 25G /dev/vgdata/lvapp
xfs_growfs /var/log/app                       # online, mounted filesystem
df -h /var/log/app

Notes on judgement:

  • pvresize reads the current device size. If the rescan is skipped it silently does nothing and vgs still shows 0 free - that is exactly the state described.
  • If the PV had been /dev/vdb1 instead of the whole disk, growpart /dev/vdb 1 must come before pvresize.
  • lvextend -r (or --resizefs) would fuse steps 3 and the filesystem growth by calling the right tool automatically, which is the safer habit in production.

2. The junior admin runs `lvextend -L 48G /dev/vgdata/lvapp` and gets 'insufficient free space', even though the disk is 50 GB. Explain the failure and give the corrected command.

Read the worked answer

Two things are wrong, and they need separate explanations.

  1. The space is not in the VG yet. Until pvresize /dev/vdb runs, the PV is still 20 GiB, the LV already occupies 4 GiB, so VFree is 0 and any extension fails.
  2. -L is an absolute size, not an increment. Even after pvresize, the VG would hold roughly 46 GiB of free extents (50 GiB minus the existing 4 GiB LV minus a few MB of LVM metadata). Asking for an LV of 48G requires 44 GiB on top of nothing free, i.e. more than the VG can ever supply.

Correct approaches:

vgs                       # read VFree before choosing a number
lvextend -L 25G /dev/vgdata/lvapp      # absolute target, within VFree
df -h /var/log/app && xfs_growfs /var/log/app
# or take everything that is left:
lvextend -l +100%FREE -r /dev/vgdata/lvapp

The lesson: -L sets the final size and -l takes extents/percentages; check vgs first rather than guessing, and never size an LV to the theoretical disk capacity.

3. A colleague says to run `xfs_growfs /var/log/app` first and extend the LV afterwards. Explain what `xfs_growfs` actually does, why the order matters, and what would change if the filesystem were ext4.

Read the worked answer

xfs_growfs does not create space. It tells a mounted XFS filesystem to expand its structures to fill the block device underneath it (or to an explicit size given with -D, in filesystem blocks). It reads the current device size and grows to it.

So if it runs before lvextend, the block device is still 4 GB and the command either reports there is nothing to do or grows by zero - the filesystem then stays small while the LV is larger, and someone has to remember to run it again.

Order is therefore: device → PV → LV → filesystem.

Other facts that change the picture:

  • XFS can only grow, never shrink. If the requirement had been to reduce /var/log/app, XFS is the wrong answer and the data would have to be backed up, the LV recreated and the data restored.
  • On ext4 the filesystem tool is resize2fs /dev/vgdata/lvapp (online growth is supported, shrinking requires an unmounted filesystem and an fsck first).
  • lvextend -r avoids the whole question by detecting the filesystem type and invoking the correct tool.