During routine VM storage expansions on Oracle Linux 7.5 systems, I encountered a puzzling behavior with XFS filesystem extensions that previously worked flawlessly. The standard LVM extension procedure:

# Traditional workflow that normally succeeds
fdisk /dev/sdb << EOF
n
p
1
t
8e
w
EOF

partprobe -s
pvcreate /dev/sdb1
vgextend ol /dev/sdb1
lvextend -L+10G /dev/mapper/ol-root /dev/sdb1
xfs_growfs /dev/mapper/ol-root

The key insight came from examining mount points versus device paths. While df -Th shows the filesystem mounted at /, the error suggests the kernel doesn't associate the device path with the mount.

# Correct diagnostic approach:
mount | grep xfs
# Expected output: /dev/mapper/ol-root on / type xfs (rw,relatime,attr2,inode64,noquota)

lsblk -o NAME,FSTYPE,MOUNTPOINT
# Verify the complete device path hierarchy

For XFS filesystems, xfs_growfs requires the mount point path, not the device path:

# Correct syntax:
xfs_growfs /

# Alternative if needing to specify device:
xfs_growfs -d /dev/mapper/ol-root /

This behavior differs from ext4's resize2fs which operates directly on block devices.

Here's the verified procedure that resolved the issue:

# 1. Create physical volume
pvcreate /dev/sdb1

# 2. Extend volume group
vgextend ol /dev/sdb1

# 3. Extend logical volume (using 100% free space)
lvextend -l +100%FREE /dev/mapper/ol-root

# 4. Grow filesystem (critical difference)
xfs_growfs /

Several factors could explain why previously working commands now fail:

• Kernel updates changing XFS behavior (check with uname -r)
• Different LVM2 tool versions (lvm version)
• Filesystem metadata corruption (verify with xfs_repair -n)

For complex LVM configurations, additional verification helps:

# Check volume group free space
vgs ol

# Verify physical volume allocation
pvs

# Confirm XFS filesystem details
xfs_info /

When working with Oracle Linux 7.5 VMs, I frequently encounter storage expansion scenarios. The standard procedure for extending XFS filesystems on LVM typically works flawlessly:

# Standard expansion workflow
fdisk /dev/sdb
n → p → 1 → [defaults] → w
partprobe -s
pvcreate /dev/sdb1
vgextend ol /dev/sdb1
lvextend -L +10G /dev/mapper/ol-root
xfs_growfs /dev/mapper/ol-root

Recently, I've encountered systems where xfs_growfs fails with:

xfs_growfs: /dev/mapper/ol-root is not a mounted XFS filesystem

This occurs despite:

• The filesystem being visible in lsblk and df
• Successful LVM extension commands
• Previous successful expansions on the same systems

First, verify the actual mount point:

# Check mounted filesystems
findmnt -n -o TARGET /dev/mapper/ol-root

In my case, this revealed that while /dev/mapper/ol-root was mounted at /, the command expected the mount point rather than the device path.

The correct syntax differs between device paths and mount points:

# This will fail
xfs_growfs /dev/mapper/ol-root

# This works
xfs_growfs /

Here's the complete verified workflow:

# Add new disk
echo -e "n\np\n1\n\n\nw" | fdisk /dev/sdb
partprobe -s

# Extend LVM
pvcreate /dev/sdb1
vgextend ol /dev/sdb1
lvextend -L +10G /dev/mapper/ol-root

# Grow filesystem (NOTE: using mount point)
xfs_growfs /

For scripting purposes, you can programmatically determine the mount point:

MOUNTPOINT=$(findmnt -n -o TARGET /dev/mapper/ol-root)
xfs_growfs $MOUNTPOINT

The behavior difference appears related to:

• XFS utilities version changes
• Subtle differences in VM templates
• Kernel updates affecting device recognition

Always check your XFS tools version:

xfs_growfs -V