Expand an LVM logical volume and filesystem without downtime
Safely add capacity to an online thick LVM logical volume, with an optional new physical volume, a tested size plan, separate ext4 and XFS growth paths, and evidence that the application received usable space.
Increase an ext4 or XFS filesystem on a linear LVM logical volume while it remains mounted, without confusing volume-group free extents with filesystem capacity or turning an expansion request into an accidental disk initialization.
- Ubuntu Server 24.04 LTS
- LVM2 2.03.x
- Filesystems ext4, XFS
- Restorable application backup Complete and verify an application-consistent backup before changing block storage. LVM metadata backup cannot restore filesystem contents or transactions.
- Exact storage ownership Map the mount point through filesystem, logical volume, volume group, and physical volumes. When adding a disk, confirm its serial or WWN in the platform inventory.
findmnt {{mountPoint}} && lsblk --fs --output NAME,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS,SERIAL,WWN - Capacity and performance plan State how much usable filesystem space is required, why, and whether adding extents on another device changes latency, failure-domain, snapshot, or backup assumptions.
- Maintenance safety Even though ext4 and XFS can grow online, schedule observation, suppress automated storage changes, and keep application owners ready to stop writes if kernel or filesystem errors appear.
OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.
Full guide
What you will build
- A verified storage map from the application mount through its filesystem and device-mapper LV to the volume group and each physical volume, including device serial or WWN when new capacity is attached.
- A controlled two-phase online expansion: first allocate approved LVM extents to one thick linear LV, then grow ext4 or XFS with the correct native tool while the filesystem remains mounted.
- An evidence and recovery package containing LVM metadata backup, before/after allocation reports, mount identity, kernel health, application checks, and a realistic no-shrink rollback boundary.
- The LV size increases by exactly {{growthSize}}, the mounted filesystem exposes the requested usable capacity, and its source, UUID, filesystem type, and mount options remain unchanged.
- The volume group retains an understood amount of free space, every physical extent is attributable to an approved device, and no unexpected thin, snapshot, RAID, cache, or encrypted topology was modified.
- Application read/write health and the kernel journal remain clean throughout the observation window, with monitoring thresholds updated for the new capacity.
Architecture
How the parts fit together
A physical volume contributes fixed-size extents to one volume group. A thick linear logical volume maps logical extents onto one or more physical volumes, and device-mapper exposes the LV as a block device. ext4 or XFS owns structures inside that block device, while the VFS mounts the filesystem at the application path. Extending the VG, LV, and filesystem are distinct state transitions. Capacity is usable only after the filesystem grows, and adding a physical device can expand the failure domain even when no downtime is required.
- Resolve {{mountPoint}} to /dev/{{vgName}}/{{lvName}}, verify {{filesystemType}}, and capture current allocation and device identities.
- Back up LVM metadata and confirm the application-consistent data backup before any label or allocation write.
- Use existing VG free extents when sufficient; otherwise positively identify {{newDevice}}, create a PV, and extend only {{vgName}}.
- Test then apply a relative +{{growthSize}} LV extension, preserving a checkpoint between metadata allocation and filesystem growth.
- Run resize2fs for ext4 or xfs_growfs against the XFS mount, then verify filesystem capacity, application health, and kernel evidence.
Assumptions
- The target is a mounted, active, thick linear LVM LV. Thin pools, snapshots, cache volumes, LVM RAID, shared VGs, clustered filesystems, encryption resizing, and multipath require their own capacity and recovery procedures.
- The filesystem is ext4 or XFS and is healthy enough for supported online growth. This guide does not shrink filesystems or logical volumes.
- The requested value {{growthSize}} is a relative increase such as 20G, reviewed against current LV size, expected data growth, backup windows, and volume-group reserve policy.
- The optional {{newDevice}} is already partitioned when organizational policy requires a partition table. The example uses an empty partition and never creates or guesses a partition layout.
- Storage and application owners can observe the change. Online support removes planned unmount time, not the need for backup, monitoring, and a stop condition.
Key concepts
- Physical volume (PV)
- An LVM-labelled whole device or partition divided into physical extents and assigned to at most one ordinary volume group.
- Volume group (VG)
- The allocation domain pooling extents from one or more PVs. VFree is allocatable LVM space, not yet filesystem capacity.
- Logical volume (LV)
- A virtual block device whose logical extents map to physical extents. A filesystem cannot use new extents until its own metadata grows.
- Relative size
- An lvextend value prefixed with plus, such as +20G. Without plus, --size describes the desired final LV size.
- Online growth
- A supported expansion while the filesystem remains mounted. It does not mean the operation is reversible or harmless under failing hardware.
- LVM metadata backup
- A text representation of VG/LV allocation metadata. It can help restore LVM definitions but contains no application or filesystem data.
Before you copy
Values used in this guide
{{mountPoint}}Exact mounted application path whose filesystem needs capacity.
Example: /srv/app{{filesystemType}}Verified filesystem type. This guide accepts only ext4 or xfs.
Example: ext4{{vgName}}Volume group owning the target logical volume.
Example: vgdata{{lvName}}Logical volume mounted at the target path.
Example: app{{growthSize}}Approved relative increase with an LVM unit suffix; do not include a leading plus because the template supplies it.
Example: 20G{{newDevice}}Optional empty whole device or partition added only when current VFree is insufficient; identify by serial or WWN.
Example: /dev/vdb1{{changeId}}Filesystem-safe incident or change identifier used to name evidence files.
Example: CHG-2048Security and production boundaries
- pvcreate is intentionally classified danger because a plausible /dev/vdX name can refer to a production filesystem after device enumeration changes. Asset identity, signatures, mounts, and holders must all agree.
- Do not place LVM metadata backups only on {{mountPoint}}. The evidence and recovery metadata must survive loss of the filesystem being changed.
- Capacity does not solve uncontrolled data growth. Identify the writer, retention policy, alert threshold, backup-time impact, and potential denial-of-service path before expansion.
- LVM spanning increases availability dependency: loss of any required PV can make the linear LV incomplete. Use redundancy at the correct layer when a single-device failure is unacceptable.
Stop before continuing if
- Stop if findmnt, lvs, and lsblk do not resolve one unambiguous mount-to-LV-to-VG map.
- Stop if kernel logs show I/O errors, filesystem shutdown, device resets, or an LVM operation already in progress.
- Stop before pvcreate if {{newDevice}} has any signature, mount, holder, unexpected serial/WWN, or unapproved data-recovery value.
- Stop if the LV is thin, snapshot-backed, cached, RAID, shared, clustered, encrypted in an unplanned layer, or contains an unsupported filesystem.
- Stop after LV growth if native filesystem growth fails. Do not reduce the LV to match the old filesystem size.
verification
Map the mount to its complete LVM stack
Resolve the effective mount source and filesystem, then record logical-volume, volume-group, and physical-volume allocation with device identities.
Why this step matters
Storage changes must follow the effective kernel mount backward through every allocation layer. Matching names are not enough; source path, filesystem, LV path, segment type, device allocation, and hardware identity must form one coherent map.
What to understand
findmnt -T resolves the mount containing the path even when the supplied directory is below the actual mount point. Confirm that the returned target is the intended boundary.
The lvs segment type must be linear for this procedure. raid, thin, cache, snapshot, mirror, and shared attributes change capacity and rollback behavior.
Record physical devices and their serial/WWN because /dev/vda or /dev/sdb ordering can change after a reboot or attachment event.
System changes
- No persistent change; reads the mount table, LVM metadata, and block-device inventory.
Syntax explained
lvs --options ...segtype,devices- Shows both LV topology and the PV extents backing it.
vgs ...vg_free- Reports free extents available before another PV is considered.
lsblk ...SERIAL,WWN- Correlates Linux device paths with durable platform identities.
Values stay on this page and are never sent or saved.
findmnt --target {{mountPoint}} --output TARGET,SOURCE,FSTYPE,OPTIONS; sudo lvs --units g --options vg_name,lv_name,lv_path,lv_size,segtype,devices; sudo vgs --units g --options vg_name,vg_size,vg_free,pv_count; sudo pvs --units g --options pv_name,vg_name,pv_size,pv_free,dev_size; lsblk --output NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,SERIAL,WWNTARGET SOURCE FSTYPE OPTIONS /srv/app /dev/mapper/vgdata-app ext4 rw,relatime VG LV Path LSize Type Devices vgdata app /dev/vgdata/app 80.00g linear /dev/vda3(0) VG VSize VFree PV vgdata 100.00g 20.00g 1
Checkpoint: Approve one storage map
findmnt -T {{mountPoint}} && lvs -a -o +devices,segtypeContinue whenOne thick linear LV in {{vgName}} backs {{mountPoint}} with {{filesystemType}}.
Stop whenThe path crosses an unexpected mount or the LV topology is not thick linear.
Security notes
- Storage inventory can reveal tenant and infrastructure identifiers; retain it in the authorized change record.
Alternatives
- Use dmsetup ls --tree when device-mapper relationships remain ambiguous.
Stop conditions
- No allocation write occurs until the entire mount-to-hardware map is approved.
verification
Confirm filesystem type, usage, and healthy kernel state
Measure current filesystem capacity and inode use, inspect the recent kernel journal for device or filesystem errors, and confirm that no LVM operation or snapshot merge is already running.
Why this step matters
Growth should not begin on a filesystem or device already reporting damage. Usage and inode data also confirm whether capacity, inode exhaustion, deleted-open files, or retention—not raw block size—is the real problem.
What to understand
df type filtering fails safely if filesystemType is wrong, forcing the operator to reconcile the recorded type.
LV attributes expose snapshots, thin data/metadata pressure, activation, and operations that make the simple linear procedure inappropriate.
The recent kernel journal must be widened if monitoring or users reported earlier device resets; thirty minutes is only the immediate change window baseline.
System changes
- No persistent change; reads filesystem use, LV attributes, and kernel health.
Syntax explained
df --inodes- Separates inode exhaustion from block-capacity exhaustion.
lvs --all- Includes hidden pool, metadata, and snapshot LVs that affect topology.
journalctl --dmesg- Reads kernel messages from the journal.
Values stay on this page and are never sent or saved.
df --human-readable --type={{filesystemType}} {{mountPoint}}; df --inodes {{mountPoint}}; sudo lvs --all --options vg_name,lv_name,lv_attr,lv_size,data_percent,metadata_percent,copy_percent; sudo journalctl --dmesg --since '-30 minutes' --priority=warning --no-pagerFilesystem Size Used Avail Use% Mounted on /dev/mapper/vgdata-app 79G 71G 4.1G 95% /srv/app Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/vgdata-app 5.0M 410K 4.6M 9% /srv/app LV Attr LSize Data% Meta% Copy% app -wi-ao---- 80.00g
Checkpoint: Establish a healthy growth baseline
Continue whenFilesystem type and pressure are understood, LV topology is supported, and the kernel shows no storage warning.
Stop whenDamage, an active merge/conversion, or an unsupported topology appears.
Security notes
- Avoid copying application paths or device identifiers into public channels.
Alternatives
- Resolve deleted-open files, runaway logs, or inode exhaustion without block expansion when those are the actual cause.
Stop conditions
- Do not use capacity growth to mask active corruption or unknown writes.
command
Back up LVM metadata and the current mount contract
Save the volume-group metadata plus exact LVM and mount reports to an incident directory outside the filesystem being expanded, then verify that the metadata backup names the intended volume group.
Why this step matters
LVM normally creates automatic metadata archives, but an explicit change-specific copy plus reports make the pre-change allocation recoverable and auditable even if host defaults or archive retention differ.
What to understand
The directory mode restricts storage topology evidence to root. Place a copy in the approved backup system after verifying it.
vgcfgbackup contains VG and LV metadata, not filesystem data. The application backup remains the recovery mechanism for content.
The mount report records the source and options that must survive a migration or restore.
System changes
- Creates a root-only evidence directory and LVM metadata/report files outside {{mountPoint}}.
Syntax explained
vgcfgbackup --file- Writes an explicit metadata backup at the change-specific path.
lvs --segments +devices- Records extent topology before allocation.
install --directory --mode=0700- Creates a root-only evidence directory.
Values stay on this page and are never sent or saved.
sudo install --directory --mode=0700 /root/lvm-change-{{changeId}} && sudo vgcfgbackup --file /root/lvm-change-{{changeId}}/{{vgName}}.conf {{vgName}} && sudo lvs --all --segments --options +devices > /root/lvm-change-{{changeId}}/lvs.txt && findmnt --target {{mountPoint}} > /root/lvm-change-{{changeId}}/findmnt.txt && sudo grep --fixed-strings 'id = ' /root/lvm-change-{{changeId}}/{{vgName}}.conf | headVolume group "vgdata" successfully backed up. id = "V7tXhS-F5q9-..."
Checkpoint: Verify recoverable metadata evidence
test -s /root/lvm-change-{{changeId}}/{{vgName}}.conf && grep 'id = ' /root/lvm-change-{{changeId}}/{{vgName}}.confContinue whenA non-empty backup names the target VG metadata and evidence files are outside the target mount.
Stop whenThe backup is empty, stored only on {{mountPoint}}, or names another VG.
Security notes
- LVM reports disclose storage topology; protect them as operational metadata.
Alternatives
- Use the distribution's /etc/lvm/archive copy only after proving retention and exporting the exact pre-change revision.
Stop conditions
- No LV or PV metadata changes without both application data and LVM metadata recovery paths.
decision
Identify new capacity only when the volume group is short
If VFree already covers the approved growth, skip disk provisioning. Otherwise inspect the new whole device or partition for mounts, signatures, holders, serial, and WWN; the candidate must be positively identified and unused.
Why this step matters
The safest new disk is the one not needed at all. When existing VFree is insufficient, positive device identity and an empty signature/holder state are mandatory before pvcreate.
What to understand
wipefs --no-act lists recognized signatures without erasing them. Any output requires ownership investigation.
blkid can return nonzero for an empty device, so the guarded command preserves the rest of the evidence rather than pretending it succeeded.
holders identify device-mapper or other kernel consumers. An apparently unmounted partition can still back an active stack.
System changes
- No persistent change; inventories volume-group reserve and the candidate device.
Syntax explained
wipefs --no-act- Reports signatures without deleting them.
blkid ... || true- Shows known filesystem metadata while allowing an empty-device result.
/sys/class/block/.../holders- Shows active higher-layer consumers.
Values stay on this page and are never sent or saved.
sudo vgs {{vgName}} --units g --options vg_name,vg_free; lsblk --paths --output NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,SERIAL,WWN {{newDevice}}; sudo wipefs --no-act {{newDevice}}; sudo blkid {{newDevice}} || true; ls -l /sys/class/block/$(basename {{newDevice}})/holdersVG VFree vgdata 2.00g NAME SIZE TYPE FSTYPE MOUNTPOINTS SERIAL WWN /dev/vdb1 100G part vol-0ab12345 0x6000abc DEVICE OFFSET TYPE UUID LABEL holders: total 0
Checkpoint: Approve the new PV candidate
Continue whenSerial/WWN match inventory, the device has no signatures, mounts, or holders, and current VFree cannot satisfy the request.
Stop whenAny identity or ownership signal is missing or contradictory.
Security notes
- A tenant isolation failure can present another workload's disk; platform attachment labels are not sufficient without durable identity.
Alternatives
- Grow the existing underlying disk and use pvresize through a separate reviewed platform procedure.
Stop conditions
- Never wipe signatures as part of discovery.
warning
Initialize the approved empty device as an LVM physical volume
Run pvcreate only when the candidate's asset identity is approved, signature scan is empty, it is unmounted, and it has no holders. This writes LVM labels and makes prior content harder to recover.
Why this step matters
pvcreate establishes LVM ownership by writing labels and metadata areas. Because the same command can overwrite the discovery path to prior data, it is the strongest destructive boundary in this guide.
What to understand
--yes suppresses an interactive prompt only after the automated evidence gates have passed; it must not substitute for review.
The output PV UUID should be recorded with the device serial/WWN so later path changes remain traceable.
Do not use --force or --zero y to override detected signatures in this workflow.
System changes
- Writes LVM PV labels and metadata areas to {{newDevice}}.
Syntax explained
pvcreate- Initializes an empty block device for LVM physical-extents management.
--yes- Answers the ordinary confirmation after external approval gates; it does not override signatures safely.
Values stay on this page and are never sent or saved.
sudo pvcreate --yes {{newDevice}} && sudo pvs {{newDevice}} --units g --options pv_name,pv_uuid,pv_size,pv_free,vg_namePhysical volume "/dev/vdb1" successfully created. PV PSize PFree VG /dev/vdb1 100.00g 100.00g
Checkpoint: Confirm a new unassigned PV
pvs {{newDevice}} -o pv_name,pv_uuid,pv_size,pv_free,vg_nameContinue whenThe intended device has one PV UUID, all space free, and no VG yet.
Stop whenSize, identity, allocation, or VG membership differs from the approved candidate.
If this step fails
pvcreate reports an existing signature or refuses the device.
Likely causeThe device is not empty or is the wrong attachment.
wipefs --no-act {{newDevice}}lsblk -f {{newDevice}}udevadm info --query=property --name={{newDevice}}
ResolutionStop and reconcile ownership. Do not add force flags.
Security notes
- Require a second-person or automation policy check for production pvcreate targets.
Alternatives
- Use existing free VG extents or provision a new mounted filesystem instead of relabelling uncertain media.
Stop conditions
- Any signature, holder, mount, or identity mismatch blocks pvcreate.
command
Add the physical volume to the intended volume group
Extend exactly one named volume group with the newly initialized physical volume, then verify that its size and free extents increased by the expected amount.
Why this step matters
vgextend changes the allocation domain and future availability dependency of the VG. Immediate before/after size and membership evidence confirms that only the intended group gained only the intended PV.
What to understand
A linear LV allocated across this device may require it for the whole filesystem to activate, even if most extents remain on the original disk.
Keep some VFree after the change according to policy; do not assume the newly attached size is entirely usable or should be consumed.
Record physical extent size and allocation if exact byte reconciliation is required.
System changes
- Adds {{newDevice}} as a member of {{vgName}}, increasing its physical extent pool.
Syntax explained
vgextend VG PV- Assigns the named initialized PV to exactly one volume group.
pvs ...vg_name,pv_free- Verifies membership and remaining unallocated extents.
Values stay on this page and are never sent or saved.
sudo vgextend {{vgName}} {{newDevice}} && sudo vgs {{vgName}} --units g --options vg_name,vg_size,vg_free,pv_count && sudo pvs {{newDevice}} --units g --options pv_name,vg_name,pv_size,pv_freeVolume group "vgdata" successfully extended VG VSize VFree #PV vgdata 200.00g 102.00g 2 PV VG PSize PFree /dev/vdb1 vgdata 100.00g 100.00g
Checkpoint: Verify VG membership and reserve
Continue when{{vgName}} contains the new PV, its VSize/VFree increase is expected, and no LV allocation has happened yet.
Stop whenAnother VG changed or the new PV already shows unexpected allocation.
Security notes
- Update access and disposal controls for every device now capable of holding the filesystem's data.
Alternatives
- Keep a separate VG and filesystem when independent lifecycle or failure isolation is preferable.
Stop conditions
- Do not allocate LV extents until the new VG topology is recorded and accepted.
verification
Test the exact logical-volume expansion
Use LVM test mode with the approved relative growth amount. Confirm that the named thick linear LV has sufficient extents and that the request is an increase, not an absolute size smaller than the current LV.
Why this step matters
Test mode validates LVM metadata feasibility and the exact target without committing it. The explicit plus sign is a critical semantic check: +20G adds space, whereas 20G requests a final size.
What to understand
The test success message is simulated and the following lvs output must still show the original size.
Use a named LV path rather than ambiguous selection filters. Confirm segtype remains linear.
Test mode cannot prove the filesystem will grow or predict hardware failure; those remain separate gates.
System changes
- No intended persistent change; LVM simulates metadata processing and leaves the LV at its original size.
Syntax explained
--test- Runs LVM metadata logic without committing volume changes.
--size +{{growthSize}}- Requests a relative increase by the approved amount.
/dev/{{vgName}}/{{lvName}}- Names one exact target LV.
Values stay on this page and are never sent or saved.
sudo lvextend --test --size +{{growthSize}} /dev/{{vgName}}/{{lvName}} && sudo lvs /dev/{{vgName}}/{{lvName}} --units g --options vg_name,lv_name,lv_size,segtype,devicesTEST MODE: Metadata will NOT be updated and volumes will not be (de)activated. Logical volume vgdata/app successfully resized. VG LV LSize Type Devices vgdata app 80.00g linear /dev/vda3(0)
Checkpoint: Approve the simulated allocation
Continue whenTest succeeds, actual LV size is unchanged, VFree is sufficient, and target/amount match the change.
Stop whenThe request would consume reserve, changes another LV, or lacks free extents.
Security notes
- Treat an unexpectedly large growth amount as a change-control failure, not a harmless capacity bonus.
Alternatives
- Use extent counts only when organizational tooling calculates and records them accurately.
Stop conditions
- No real lvextend follows a failed or ambiguous test.
command
Extend the logical volume without resizing the filesystem yet
Apply the tested relative growth to the exact LV path. Keeping block and filesystem growth separate makes each checkpoint explicit and avoids trusting fsadm support for an unknown filesystem.
Why this step matters
This is the irreversible allocation checkpoint. Applying only the already tested relative increase limits scope and leaves the filesystem untouched until the new block size is proven.
What to understand
LVM automatically archives metadata on normal configurations, but retain the explicit pre-change backup.
The output must show old and new sizes whose difference equals {{growthSize}}. Reconcile rounding to physical extents.
Do not use lvresize for this expansion path because its broader resize semantics make accidental shrink requests easier.
System changes
- Allocates additional extents from {{vgName}} to /dev/{{vgName}}/{{lvName}}, increasing its block size.
Syntax explained
lvextend- Extends an LV and rejects a shrink operation.
--size +{{growthSize}}- Adds the reviewed amount rather than setting an ambiguous final size.
Values stay on this page and are never sent or saved.
sudo lvextend --size +{{growthSize}} /dev/{{vgName}}/{{lvName}} && sudo lvs /dev/{{vgName}}/{{lvName}} --units g --options vg_name,lv_name,lv_size,segtype,devices && sudo vgs {{vgName}} --units g --options vg_name,vg_freeSize of logical volume vgdata/app changed from 80.00 GiB (20480 extents) to 100.00 GiB (25600 extents). Logical volume vgdata/app successfully resized. VG LV LSize Type vgdata app 100.00g linear VG VFree vgdata 82.00g
Checkpoint: Confirm exact LV growth
Continue whenLV size increased by the reviewed extent-rounded amount and VG free space decreased accordingly.
Stop whenThe wrong LV, unexpected devices, or unexpected size appears.
If this step fails
lvextend succeeds but reports allocation on an unexpected PV.
Likely causeLVM allocation policy selected available extents different from the operator's assumption.
lvs -o lv_name,lv_size,seg_pe_ranges,devices /dev/{{vgName}}/{{lvName}}pvs -o pv_name,pv_used,pv_free
ResolutionStop before filesystem growth and review the supported migration plan; do not shrink the LV reflexively.
Security notes
- Capacity allocation can shift sensitive data to a newly attached device; apply the same encryption and disposal policy.
Alternatives
- Use explicit allocation constraints only when performance/failure placement is designed and tested.
Stop conditions
- If the actual extent map differs from the approved plan, pause before filesystem growth.
command
Grow ext4 or XFS with its native online tool
Run the branch that matches the verified filesystem type: resize2fs receives the LV device for ext4, while xfs_growfs receives the mounted directory for XFS. Unsupported filesystems stop rather than guessing.
Why this step matters
The filesystem, not LVM, exposes usable files and free space. ext4 and XFS accept different operands, so a strict type branch prevents a familiar-looking command from targeting the wrong layer.
What to understand
resize2fs reads the larger block device and expands mounted ext4 to its available size when no size is supplied.
xfs_growfs operates on the mounted XFS path and grows the data section to the underlying maximum by default.
The unsupported branch exits with code 64 and performs no fallback. btrfs, GFS2, and other filesystems require their own procedures.
System changes
- Expands filesystem allocation metadata online to use the larger LV.
Syntax explained
case '{{filesystemType}}'- Selects only the pre-verified ext4 or XFS procedure.
resize2fs LV- Grows ext4 on the named block device.
xfs_growfs MOUNT- Grows the mounted XFS filesystem.
exit 64- Stops unsupported types without guessing.
Values stay on this page and are never sent or saved.
case '{{filesystemType}}' in ext4) sudo resize2fs /dev/{{vgName}}/{{lvName}} ;; xfs) sudo xfs_growfs {{mountPoint}} ;; *) echo 'Unsupported filesystem: {{filesystemType}}' >&2; exit 64 ;; esacresize2fs 1.47.0 (5-Feb-2023) Filesystem at /dev/vgdata/app is mounted on /srv/app; on-line resizing required The filesystem on /dev/vgdata/app is now 26214400 (4k) blocks long.
Checkpoint: Prove native filesystem growth
df -hT {{mountPoint}} && findmnt -T {{mountPoint}}Continue whenFilesystem type is unchanged and total/available capacity increased.
Stop whenNative growth reports an error or kernel warnings appear.
If this step fails
resize2fs reports a bad magic number.
Likely causeThe filesystem type or LV path is wrong, or a lower storage layer was supplied.
findmnt -T {{mountPoint}} -o SOURCE,FSTYPElsblk -f /dev/{{vgName}}/{{lvName}}file -sL /dev/{{vgName}}/{{lvName}}
ResolutionStop and reconcile the mapping. Never create a new filesystem or force another checker.
Security notes
- Do not use shell input that can alter the case statement; variables must come from validated guide fields.
Alternatives
- Use lvextend --resizefs only in an environment where fsadm support and evidence meet local policy.
Stop conditions
- Never shrink the LV after filesystem growth begins or fails.
verification
Prove usable capacity and stable application I/O
Re-read the mapping and sizes, confirm the kernel observed no errors, and perform the application's own read/write health check rather than writing an arbitrary root-owned test file into production data.
Why this step matters
A larger df total is necessary but not sufficient. The final proof binds unchanged identity and options, expected LV allocation, usable headroom, clean kernel behavior, and application semantics.
What to understand
Compare available bytes against the capacity requirement, not merely the requested LV increase; filesystem overhead and reserved blocks affect usable space.
Use the application's native health/write path and backup verification. An arbitrary touch file may bypass the service identity and quota behavior.
Observe long enough to catch delayed device errors and update monitoring thresholds immediately.
System changes
- No persistent change from the verification commands; application-specific health probes follow their own documented behavior.
Syntax explained
df --human-readable- Shows filesystem-visible capacity after metadata growth.
lvs ...devices- Confirms final block size and allocation devices.
journalctl --dmesg --since- Checks the kernel change window for storage warnings.
Values stay on this page and are never sent or saved.
findmnt --target {{mountPoint}} --output TARGET,SOURCE,FSTYPE,OPTIONS; sudo lvs /dev/{{vgName}}/{{lvName}} --units g --options vg_name,lv_name,lv_size,devices; df --human-readable {{mountPoint}}; df --inodes {{mountPoint}}; sudo journalctl --dmesg --since '-10 minutes' --priority=warning --no-pagerTARGET SOURCE FSTYPE OPTIONS /srv/app /dev/mapper/vgdata-app ext4 rw,relatime VG LV LSize Devices vgdata app 100.00g /dev/vda3(0) Filesystem Size Used Avail Use% Mounted on /dev/mapper/vgdata-app 99G 71G 24G 76% /srv/app -- No entries --
Checkpoint: Accept the capacity change
Continue whenRequested headroom is usable, identity/options are unchanged, application I/O succeeds, and kernel evidence is clean.
Stop whenApplication errors, unexpected allocation, or device/filesystem warnings appear.
Security notes
- Avoid world-writable test artifacts; verify through the same identity and policy the application uses.
Alternatives
- Keep the service drained during an extended observation window for business-critical data.
Stop conditions
- Do not close the change until monitoring, backups, and inventory reflect the new storage.
Finish line
Verification checklist
sudo lvs /dev/{{vgName}}/{{lvName}} --units b --nosuffix --options lv_size && df --block-size=1 --output=size,used,avail,target {{mountPoint}}The filesystem total increased and does not exceed the logical volume; the requested usable headroom is visible.findmnt --target {{mountPoint}} --output TARGET,SOURCE,FSTYPE,OPTIONS,UUIDThe original mount point, LV source, filesystem type, UUID, and required options remain intact.sudo journalctl --dmesg --since '-30 minutes' --priority=warning --no-pagerNo new device reset, I/O, device-mapper, ext4, or XFS warning occurred during or after growth.Recovery guidance
Common problems and safe checks
lvextend test reports insufficient free space.
Likely causeThe VG lacks free extents, growthSize exceeds the approved device capacity, or free extents are constrained by allocation policy.
vgs {{vgName}} -o vg_size,vg_freepvs -o pv_name,pv_size,pv_free,vg_namelvs -a -o lv_name,lv_attr,lv_size,segtype,devices
ResolutionReduce the request through change approval, add a positively identified PV, or migrate data. Do not use another VG's device or overwrite signatures to satisfy the request.
pvcreate refuses because a filesystem or partition signature exists.
Likely causeThe wrong device was selected, provisioning reused storage, or stale metadata remains from a device whose ownership has not been proven.
wipefs --no-act {{newDevice}}blkid {{newDevice}}lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,SERIAL,WWN {{newDevice}}
ResolutionStop and reconcile the device with asset inventory and backups. Signature removal is a separate destructive change and is not automated by this guide.
The LV is larger but df still shows the original filesystem size.
Likely causeOnly the LVM layer grew, the wrong filesystem tool was selected, or native growth returned an error.
lvs /dev/{{vgName}}/{{lvName}} -o lv_sizefindmnt {{mountPoint}} -o SOURCE,FSTYPE,OPTIONSjournalctl -k --since '-15 minutes'
ResolutionKeep the larger LV, correct the filesystem-type branch, and run only its supported grow tool. Never shrink the LV back under a filesystem that may have begun expansion.
xfs_growfs reports that the path is not a mounted XFS filesystem.
Likely causeThe command received the LV device instead of the XFS mount point, the path resolves to another mount, or filesystemType was recorded incorrectly.
findmnt -T {{mountPoint}} -o TARGET,SOURCE,FSTYPExfs_info {{mountPoint}}lsblk -f /dev/{{vgName}}/{{lvName}}
ResolutionUse the verified mounted XFS directory. Do not format or remount merely to make the command accept a path.
Reference
Frequently asked questions
Why not use lvextend -r in one command?
It can be appropriate when fsadm support and behavior are fully understood, but separate LV and native-filesystem checkpoints make the irreversible boundary, evidence, and failure handling clearer across ext4 and XFS.
Can I allocate 100%FREE?
Technically yes, but an explicit reviewed size preserves VG reserve for operational needs and prevents an unexpected new PV size from being consumed automatically.
Is online growth zero risk?
No. It avoids an unmount but still writes LVM and filesystem metadata, can expose device failures, changes backup characteristics, and is not generally shrinkable.
Recovery
Rollback
Online filesystem growth is normally one-way: XFS cannot be shrunk, and ext4 shrink requires an offline, higher-risk operation. Treat restore or migration as rollback rather than trying to reverse the LV in place.
- If pvcreate targeted the wrong device, stop all storage writes immediately and engage data recovery; vgcfgrestore cannot reconstruct overwritten filesystem data.
- If vgextend succeeded but no LV extents were allocated from the new PV, use pvmove when needed and vgreduce only after pvs proves the PV has zero allocated extents.
- If the LV grew but the filesystem did not, leave the larger LV in place, diagnose the filesystem-specific error, and retry only the native grow operation after backup and health checks.
- If the application fails after successful growth, keep the non-destructive larger capacity and restore application configuration or data from its application-consistent backup.
- To return to a smaller storage footprint, build a new correctly sized filesystem, restore or replicate verified data, switch the mount during maintenance, and retain the old LV until acceptance checks pass.
Evidence