WIUNIX ACADEMY

Grow an LVM logical volume and XFS/ext4 filesystem online

Page 3 of 3. Review the earlier steps and prerequisites before continuing.

YOUR SYSTEM. YOUR STEPS.

Where are you working?

Choose your OS and version. The prerequisites, commands and troubleshooting follow your environment.

Rocky Linux 10Reviewed against official documentation · 2026-11-05

USE YOUR OWN VALUES

Configure this tutorial

Set the example values for your environment; related explanations and copy panels update together. Never enter passwords, private keys or tokens. Values stay in this tab and are not sent to the server or share links. Check actual DNS, certificates and network policy before running commands.

Different IP addresses, domains or ports? Open the settings below, change the values and select “Apply to tutorial”, then copy the updated commands.

Set values for my environment3 editable values

LET’S BUILD

Verify capacity and the application, not just exit status

Repeat the identity and capacity reports. LVM/device size and filesystem size are different measurements; filesystem metadata, reserved space and reporting units mean the numbers need not be identical. Compare before/after values at each layer rather than requiring df to equal the raw device bytes.

Run the application owner’s existing read/write or health check within its agreed scope. Confirm data accessibility, errors and latency; do not create a synthetic write workload just to fill new space. Capacity growth does not fix a quota, leaking files, inode pressure or a lower-layer I/O fault by itself.

Same Bash shell on the approved storage host

findmnt --mountpoint '/srv/data' -o TARGET,SOURCE,FSTYPE,FSROOT,OPTIONS
sudo lvs --segments -o lv_path,lv_attr,segtype,lv_size,vg_name,lv_health_status,devices '/dev/vg_data/lv_data'
sudo vgs -o vg_name,vg_attr,vg_size,vg_free,vg_extent_size,vg_free_count
lsblk -o NAME,TYPE,FSTYPE,SIZE,MOUNTPOINTS
df -hT -- '/srv/data'
df -i -- '/srv/data'
sudo journalctl -k --since '-15 min' --no-pager -n 80

How do I know it worked?

The filesystem gained usable capacity, the mapping is unchanged and the application’s own check passes; unresolved errors remain recorded.

Locate the unfinished layer before retrying

The diagnostic panels below read the current state. They do not recreate storage or repair a filesystem. Keep results private and preserve the first error, the before-record and the approved final target.

The guard rejects the mount or LV

A containing directory is not necessarily a mountpoint. Check the exact mounted source, FSROOT and device tree; a bind mount, LUKS layer, wrong namespace or another filesystem is outside this recipe. Correct the form only after the owner confirms the actual mapping; never bypass the guard.

findmnt --mountpoint '/srv/data' -o TARGET,SOURCE,FSTYPE,FSROOT,OPTIONS
sudo lvs --segments -o lv_path,lv_attr,segtype,lv_size,vg_name,lv_health_status,devices '/dev/vg_data/lv_data'
sudo vgs -o vg_name,vg_attr,vg_size,vg_free,vg_extent_size,vg_free_count
lsblk -o NAME,TYPE,FSTYPE,SIZE,MOUNTPOINTS
df -hT -- '/srv/data'
df -i -- '/srv/data'

There are not enough free extents

Read the selected LV and VG allocation. A partial/missing PV or another allocation may explain the failure. Do not switch to +100%FREE or add a PV blindly. Return to the storage owner for a separately scoped lower-layer change or a smaller still-growing approved target.

sudo lvs --segments -o lv_path,lv_size,vg_name,segtype,devices '/dev/vg_data/lv_data'
sudo vgs -o vg_name,vg_attr,vg_free,vg_extent_size,vg_free_count

LV grew but df still shows the old size

Check the exact mount, block-device size and filesystem type. Once the LV is at the intended target, retry only the matching filesystem branch after resolving its error. An absolute target makes another allocation unnecessary. A changed or larger-than-approved mapping needs a fresh plan.

findmnt --mountpoint '/srv/data' -o TARGET,SOURCE,FSTYPE,FSROOT,OPTIONS
sudo lvs --units b --nosuffix -o lv_path,lv_size '/dev/vg_data/lv_data'
sudo blockdev --getsize64 '/dev/vg_data/lv_data'
df -B1 -- '/srv/data'

Filesystem is read-only, reports I/O errors or denies growth

Correlate the kernel error with this device and attempt time. Stop growth and follow the application/storage incident procedure. Do not force a remount, clear errors, disable MAC enforcement, or run mounted repair/check commands. A successful LV extension does not certify filesystem health.

findmnt --mountpoint '/srv/data' -o TARGET,SOURCE,FSTYPE,OPTIONS
sudo journalctl -k --since '-30 min' --no-pager -n 100
sudo lvs -o lv_path,lv_attr,lv_health_status '/dev/vg_data/lv_data'

Recover forward or restore data to an approved destination

If the LV extension failed, inspect the actual size before retrying: do not assume that every failed multi-stage change left every layer untouched. Reuse the same approved absolute target only after the failure is understood. If the LV is larger but filesystem growth failed, retaining that larger LV while fixing the matching filesystem step is normally the forward path.

If corruption, device failure or an unsupported layout is involved, stop this recipe and invoke the existing application-consistent restore plan. Restore to a separately prepared, adequately sized healthy destination, verify data and application behavior, then use the application’s controlled cutover procedure. Preserve the original device and metadata evidence until the storage owner decides its disposition.

Do not shrink XFS here; ext4 offline shrink is a different procedure with ordering and downtime requirements, not this change’s rollback. Restoring an old VG map underneath a filesystem that has already grown can make live filesystem blocks inaccessible. No generic vgcfgrestore, lvreduce, mkfs, fsck/repair, deactivate or reboot command belongs to this recovery path.

Record what changed and keep headroom visible

Retain the approved rounded extent target, before/after LV and filesystem sizes, exact device identities, package/kernel builds, backup reference, native command results and the application check. Mark the change complete only when both layers and the application agree; otherwise name the unfinished boundary and its owner.

Use existing capacity monitoring to track filesystem blocks/inodes, quotas and remaining VG extents separately. Set workload-specific headroom rather than consuming the VG or claiming more capacity repairs the original growth cause. The environment paths here were checked against primary documentation; no hands-on distribution matrix or guarantee for custom values is claimed.

GO TO THE SOURCE

Official references

Each environment states how it was reviewed. A documentation review does not claim a hands-on test of every version.

KEEP LEARNING

Your next step

Explore all tutorials ↗