Skip to main content
Modern enterprise Linux storage stacks are designed for non-disruptive, online capacity expansion, even while filesystems are mounted and under active I/O. This document explains why each layer—SAN/FC, LVM2, and XFS—fully supports online growth and how to perform it safely.
Storage Path: ME4 LUN → dm-multipath → LVM2 (PV/VG/LV) → XFS/ext4

​
Why Online Growth is Safe

Each component in the modern Linux storage stack is explicitly designed to support online expansion:

SAN / FC

Nondisruptive LUN expansion by design

LVM2

Metadata-only updates, safe under I/O

Filesystems

XFS/ext4 designed for mounted growth

​
1. SAN / Fibre Channel — Nondisruptive LUN Expansion

Modern enterprise SAN systems (such as Dell EMC ME4) support live, nondisruptive LUN expansion:
1

Designed for Online Operation

  • Nondisruptive expansion with brief I/O stalls
  • No unmount or downtime required
2

Simple Host Rescan

  • Host rescans the SCSI bus
  • Multipath handles updated path geometry automatically

​
Dell ME4 Official Statement

“Resize tasks can be done online without disrupting the applications.”Source: Dell PowerVault ME4 and Linux Best Practices Guide

​
Rescan Commands

After expanding the LUN on the SAN: 
# Rescan SCSI bus for new size
rescan-scsi-bus.sh --resize

# Update multipath device
multipathd -k
# Inside multipathd shell:
multipathd> resize map mpathX
Conclusion: SAN LUN expansion is explicitly engineered to occur online, with no interruption to servers or I/O.

​
2. LVM2 — Online PV and LV Expansion

Do not proceed unless all paths and the multipath device report the new size.

​
Verify All Paths Are Resized

multipath -ll mpathX
blockdev --getsize64 /dev/sdX
blockdev --getsize64 /dev/mapper/mpathX

​
2.1 PV Resize (pvresize) — Safe While Mounted

According to Red Hat’s LVM developers:
“pvresize simply updates the metadata to make LVM aware of the new size.”“The data area does not change; only the PV extent map is updated.”— Jonathan Brassow, Red Hat LVM developerSource: Red Hat LVM Mailing List
Because it modifies only metadata, pvresize:
  • Does not touch data blocks
  • Does not affect the filesystem
  • Is safe under ongoing I/O (provided all block device paths are resized)
  • Is routinely run on root filesystems, which cannot be unmounted

​
Cloud Vendor Confirmation

All three major cloud providers document pvresize as part of their “expand disk without downtime” workflow:

AWS

Expand EBS volumes online

Google Cloud

Resize persistent disks without downtime

Azure

Expand disks without downtime
These platforms are extremely conservative; documenting pvresize online means it is fully safe and supported.

​
2.2 LV Resize (lvextend) — Online and Atomic

lvextend updates:
  • LVM metadata
  • device-mapper mappings
These operations are:
  • Atomic — metadata is committed atomically via device-mapper table swap
  • Safe during active I/O
  • Non-disruptive to mounted filesystems
Cloud vendors (AWS, GCP, Azure) all document lvextend as online, immediately after pvresize.
Conclusion: LVM2 PV and LV can be grown online, even during live writes, with no unmount required.

​
3. Online Filesystem Growth

After expanding the block device (SAN → PV → LV), the filesystem must grow to use the new space.

​
Filesystem Support Matrix

FilesystemOnline GrowNotes
XFS v4+✅Designed for online growth; cannot shrink
ext4✅resize2fs supports online grow

​
3.1 XFS — Designed for Online Expansion

Red Hat’s official XFS documentation states:
“The filesystem must be mounted to be grown.”Source: Red Hat Storage Administration Guide
This is one of the clearest vendor statements that XFS online growth is not just supported, but required while mounted.

​
Why XFS Online Growth is Safe

Journaled Metadata

All operations are journaled for consistency

Allocation Groups

Expand in place without reorganization

Mount Required

Must be mounted to grow (designed behavior)

Enterprise Ready

Designed for SAN arrays, RAID, HPC

​
XFS Growth Command

# Grow XFS filesystem to use all available space
xfs_growfs /mount/point

​
ext4 Growth Command

# Grow ext4 filesystem online
resize2fs /dev/mapper/vg-lv
Conclusion: XFS is one of the safest and most robust filesystems for online, mounted, high-throughput growth.

​
4. Network Share Clients Automatically See Grown Filesystems

When an XFS or ext4 filesystem exported over NFSv4 is grown on the server, clients will automatically reflect the new size without requiring remounts.
NFSv4 is stateful and revalidates filesystem attributes, so the updated capacity becomes visible to clients transparently.
Verify on client: 
df -h /mnt/nfs_share

​
Complete Online Resize Procedure

1

Expand LUN on SAN

Use SAN management interface to grow the LUN
2

Rescan SCSI Bus

rescan-scsi-bus.sh --resize
3

Verify All Paths

multipath -ll mpathX
blockdev --getsize64 /dev/mapper/mpathX
All paths must show new size
4

Resize Multipath Device

multipathd -k
multipathd> resize map mpathX
5

Resize Physical Volume

pvresize /dev/mapper/mpathX
pvs  # Verify new size
6

Extend Logical Volume

lvextend -l +100%FREE /dev/vg/lv
lvs  # Verify new size
7

Grow Filesystem

For XFS:
xfs_growfs /mount/point
For ext4:
resize2fs /dev/vg/lv
8

Verify New Size

df -h /mount/point

​
Why Older Admins Avoid Online Resize

Before kernel 2.6.31 and early LVM2/LVM1:
Historical limitations (pre-2010):
  • pvresize sometimes failed to detect new sizes
  • Multipath resizing was unreliable
  • PV resizing sometimes required pvcreate --restorefile
  • ext2/ext3 could corrupt if device size changed underneath
  • SAN rescan tools were buggy
  • UNIX systems generally required unmounting for geometry changes
  • LVM1 had no reliable online extension
This produced the legacy rule:
“Never resize storage while mounted.”

​
Modern RHEL9 (2021+) Systems

Online PV Expansion

Safe and fully supported

Online LV Expansion

Safe and fully supported

Online XFS Growth

Officially supported and required

SAN Growth

Nondisruptive by design
The entire modern storage stack is designed for online operation.

​
Summary Table

LayerOperationSafe While Mounted / Under I/O?Why
SAN / FCExpand LUN✅ YesEngineered for nondisruptive growth
LVM2 PVpvresize✅ YesOnly metadata updated; no data block changes
LVM2 LVlvextend✅ YesAtomic metadata update; safe under I/O
XFSxfs_growfs✅ YesMust be mounted; designed for online growth
ext4resize2fs✅ YesSupports online grow (not shrink)

​
Best Practices

Verify Before Proceeding

Always verify all paths show new size before running pvresize

Test in Non-Production

Practice the procedure in a test environment first

Backup Before Changes

Take snapshots or backups before major storage operations

Monitor During Growth

Watch iostat and system logs during the resize process

Schedule Maintenance Windows

Perform during low I/O periods when possible

Document Procedures

Keep runbooks updated with your specific environment details
For production systems, consider taking LVM snapshots before resizing, providing a quick rollback path if needed.

​
Troubleshooting

Verify all paths are updated:
multipath -ll
blockdev --getsize64 /dev/mapper/mpathX
pvs
Force rescan if needed:
echo 1 > /sys/class/block/sdX/device/rescan
Verify the underlying LV was extended:
lvs
df -h
For XFS, ensure you specify the mount point (not device):
xfs_growfs /mount/point  # Correct
xfs_growfs /dev/vg/lv    # Wrong
Reload multipath configuration:
multipathd reconfigure
multipathd -k
multipathd> resize map mpathX

​
References

  • Dell EMC ME4 Linux Best Practices
  • Red Hat LVM Developer Archives
  • AWS EBS Volume Expansion Documentation
  • Google Cloud Persistent Disk Resize Guide
  • Microsoft Azure Disk Expansion Documentation
  • Red Hat Enterprise Linux Storage Administration Guide
This guide reflects best practices for RHEL 9 / CentOS Stream 9 and similar modern distributions. Always consult your specific vendor documentation.

Build docs developers (and LLMs) love

Get started for freeTalk to us