LEARN. PRACTICE. GROW.Start with identity and the map
On a fictional reconciliation server, /srv/ledger should use XFS on a linear LV. Before changing capacity, map device, PV, VG, LV, filesystem, and mount point. The name /dev/sdb alone does not sufficiently identify the approved disk. Compare inventory, stable identity, sizes, types, and observed usage. Use lsblk with explicit columns and relate its output to lvs and findmnt. A similarly sized disk may belong to another service. This exercise starts with observation: metadata-creation commands must not be used to discover whether a device contains data. Record the expected mapping before selecting any mutation.
Calculate extents and reserve
In this teaching model, the VG has 3072 free extents, each measuring 4 MiB. That provides 12288 MiB, or 12 GiB. Growing a simple linear LV by 16 GiB requires 4096 extents: 1024 are missing. Free space inside another filesystem is not automatically available to the VG. Add the agreed operational reserve: with 24 GiB free and requests for 8 and 12 GiB, 4 GiB remains. If the minimum reserve is 6, the request physically fits but misses the local condition. These numbers assume linear allocation without RAID, thin provisioning, or additional rounding.
Read the requested size before execution
A 40 GiB LV must become 60 GiB. Argument -L +20G expresses the increase; -L 60G expresses final size. Exchanging these forms changes the request. Using +60G asks for another sixty, not sixty in total. The plan should record initial size, final size, and difference while confirming free extents. Argument +100%FREE consumes available reserve and does not express a fixed sixty-GiB target. If a step fails, measure again before repeating a relative increase. Copying the same command again can produce a second change that is valid but unwanted. Include the intended final state in review.
Validate volume and filesystem separately
The device can grow without the filesystem using the additional space. If lvs shows 60 GiB while mounted XFS is still about 40 GiB, first confirm that you are observing the correct source. XFS growth requires an active mount and sufficient device capacity. xfs_growfs uses the mount point; without -D it attempts to use maximum supported capacity. With -D, size is expressed in filesystem blocks. For bsize=4096, a teaching target of 60 GiB corresponds to 15728640 blocks, but this is not a promise about usable space, geometry, or metadata overhead.
Resume from partial state
--resizefs combines operations on different layers; an error is not proof of global rollback. Retain output, identify the failed step, and observe effective sizes. If the LV already grew, repeating +20G may consume more capacity without correcting the filesystem issue. Keep technical failure separate from batch effects: a database checkpoint may persist even when files are missing. Before processing resumes, reconcile results and use the supported application procedure. The storage team can restore capacity without having the authority or information to decide whether a transaction should be repeated. Record this handoff explicitly.
Define actual acceptance and reversibility
In the consulted RHEL 10 documentation, XFS does not support shrinking. Returning capacity cannot be solved with lvreduce based only on usage reported by df. Plan migration to another filesystem with consistency, metadata, capacity, and recovery verified. For growth, acceptance includes correct source, consistent sizes, access under the service identity, and a controlled functional result. Also record remaining reserve and the observation owner. The proposed lab should use a disposable VM with recovery available. The platform’s executable calculations check only the stated numbers; they do not replace a RHEL rehearsal with actual devices.
lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINTS
lvs -o lv_name,lv_size,vg_name,vg_free
findmnt -M /srv/ledger -o SOURCE,TARGET,FSTYPE,OPTIONS
df -hT /srv/ledgerLV=40 GiB; VG free=24 GiB; target=60 GiB. A 20 GiB increase leaves 4 GiB of reserve. If the filesystem remains at 40 GiB, identify the missing step before repeating any increase.
Common pitfalls
Repeating a relative increase, confusing GiB with blocks, counting filesystem free space as VG extents, or assuming an error rolled back every step.
Related topics: Persistent mounts · Batch reconciliation
Select the right identity, calculate capacity and reserve, observe every layer, and resume from demonstrated state.
Reference: RHEL 10 logical volume management · EX200 based on Red Hat Enterprise Linux 10