Articles
LVM Interview Questions: Extent Allocation, Thin Pools, and Safe Capacity Changes
Prepare for LVM interview questions with extent ledgers, allocation constraints, thin-pool data and metadata limits, and verified filesystem resize ordering.
An LVM interview often starts with an apparently simple request: “The filesystem is nearly full. Give it more space.” A useful answer identifies the layer holding capacity and the layer consuming it. Free extents in a volume group do not automatically appear as free filesystem blocks, and a large thin volume does not guarantee physical pool headroom.
Keep a capacity ledger across devices, PVs, VGs, LVs and filesystems; verify each changed layer before calling a resize complete. This guide develops that approach through original extent, allocation and thin-pool exercises.
Add a second distinction to your explanation: filesystem usage and LVM allocation answer different questions.
Evidence boundary: Facts come from current LVM2 manual pages and Red Hat Enterprise Linux 9 documentation, checked October 6, 2026. Capacity ledgers are original examples verified with independent Python arithmetic. No physical device, logical volume or filesystem was changed. Candidate reports do not establish interview frequency; recovery recommendations are engineering reasoning under the stated assumptions.
Which layer has the free space?
Official architecture: Red Hat's LVM overview describes physical volumes supplying storage to volume groups, which supply logical volumes. Extents are allocation units. A filesystem placed on an LV has its own layout and usage accounting.
Our first asset is a deliberately simplified thick, linear-volume ledger. The VG has 200 GiB of usable extent space, with a chosen extent size of 4 MiB. We exclude other allocations and metadata overhead from this teaching model.
- Total extents:
200 × 1024 / 4 = 51,200. - An 80 GiB application LV uses 20,480 extents.
- A 90 GiB archive LV uses 23,040 extents.
- The remaining 7,680 extents represent 30 GiB of VG free space.
The application filesystem can still be almost full while that VG has 30 GiB available. Conversely, deleting application files generally changes filesystem usage without releasing the thick LV's allocated extents back to the VG.
Use a layer ledger instead of combining those numbers into one “disk free” value:
| Layer in our example | Capacity observation | What it establishes |
|---|---|---|
| VG | 200 GiB usable; 30 GiB unallocated | Extents potentially available for an eligible LV allocation |
| Application thick LV | 80 GiB allocated | Size of its logical block device |
| Application filesystem | Built within the 80 GiB LV | Its own usable blocks and usage must be inspected |
| Application data | Files occupy most filesystem capacity | Does not establish VG allocation or inode availability |
Useful Linux read-only inspection commands include:
pvs
vgs
lvs -a -o lv_name,vg_name,lv_size,segtype,data_percent,metadata_percent,devices
findmnt -T /srv/app
df -hT /srv/app
df -i /srv/app
These commands are examples for a Linux LVM host; they were not run against a real host here. Inspect the actual namespace and mount. A container path, bind mount or different device can make an otherwise correct capacity reading irrelevant to the failing application.
An inode shortage, application quota or deleted-but-open file also needs separate investigation. Our recommendation is to preserve the exact write error and compare it with the relevant capacity limit before resizing the LV. More block space is not a universal answer to every failed write.
Why can allocation fail despite sufficient aggregate VG space?
Our second asset adds allocation placement to the ledger. Two PVs together have 8,192 free 4 MiB extents, or 32 GiB. PV A has all 8,192; PV B has none.
A linear allocation of 32 GiB might fit our simplified capacity model. A proposed two-stripe extension that requires 4,096 extents on each of two eligible PVs does not. Aggregate free space meets the requested total, but the required placement cannot be satisfied.
Official allocation constraints: The lvextend manual describes LV extension and allocation policies. Our interview recommendation is to inspect segment type, stripe count, eligible devices and per-PV free extents before treating the VG total as sufficient evidence.
This is an allocation counterexample, not a claim that every striped extension has identical requirements. Existing segment geometry, selected devices and policy determine the actual request. RAID layouts also add constraints and overhead that our linear accounting deliberately omits.
Changing to a permissive allocation policy is a design change. Explain what property the current policy protects and what the proposed placement means for performance or failure domains. “Force the allocation” is not a complete capacity plan.
Distinguish two cases when a virtual disk has been enlarged. The operating system may see a larger underlying device while the PV still reflects its earlier size. Alternatively, the PV and VG may already have free extents while the target LV is unchanged. Our recommendation is to prove the size at each layer before choosing which one needs updating.
For adding a new device, identify its intended role and existing contents before discussing PV initialization. No command sequence should silently assume an unlabelled device is disposable. In an interview, make that precondition part of the proposed change rather than burying it behind a familiar command.
What order makes LV and filesystem growth reviewable?
Our application LV needs an additional 10 GiB. At 4 MiB per extent, the extension consumes 2,560 extents. The VG free count falls from 7,680 to 5,120: 30 GiB becomes 20 GiB.
The LV now spans 90 GiB. If the filesystem is unchanged, its geometry remains within the earlier 80 GiB capacity. An LV-size readback and a filesystem-size readback are therefore separate completion checks.
| Stage in our original exercise | Application LV | Filesystem geometry | VG free space |
|---|---|---|---|
| Before change | 80 GiB | Within 80 GiB | 30 GiB |
| After LV extension only | 90 GiB | Still within 80 GiB | 20 GiB |
| After supported filesystem growth | 90 GiB | Grown within 90 GiB | 20 GiB |
Official filesystem boundary: xfs_growfs describes growing a mounted XFS filesystem. resize2fs describes resizing supported ext-family filesystems, with operating-mode constraints. Choose the procedure for the actual filesystem, tooling and system rather than assuming one universal resize command.
An integrated resize option may coordinate more than one step; our recommendation still requires checking the resulting LV and filesystem independently. A successful wrapper command does not make the distinction irrelevant to troubleshooting.
Preserve the pre-change device mapping, filesystem type, LV layout and sizes. Confirm the available extents and the intended incremental versus absolute target. Then make the supported growth change and compare the result with the ledger.
Our acceptance test includes the intended mount remaining correct, increased usable filesystem capacity, and a small application-level operation under the actual service identity. The advertised device size does not prove the application can use it, or that capacity is visible in its namespace.
Our simplified table treats filesystem geometry as its bounding device size. Real df capacity differs because of filesystem metadata and other accounting. Do not expect a byte-for-byte equality between the LV size and df's user-available space; compare the intended increase and filesystem state instead.
Why can a thin pool run out while volumes look spacious?
Official thin-provisioning model: lvmthin distinguishes virtual thin-LV size from blocks allocated on writes. A pool has separate data and metadata components. Its Data% and Meta% describe different resources.
Our third original ledger has a 100 GiB data pool, 92 GiB of allocated data, and an independent metadata reading of 97%. Three thin LVs have virtual sizes of 80, 80 and 60 GiB. Their 220 GiB virtual total does not imply 220 GiB of physical backing.
A filesystem may report considerable free capacity inside one of those virtual devices while the shared pool is approaching a different limit. Reading only that filesystem's df cannot establish whether the next pool allocation will succeed.
If the VG has 24 GiB free, a chosen 20% data-pool extension adds 20 GiB in our simplified ledger. Data capacity becomes 120 GiB; unchanged 92 GiB use is approximately 76.67%. VG headroom falls to 4 GiB before any separate metadata allocation or other overhead.
That calculation does not resolve the 97% metadata observation. Metadata capacity and usage need their own readback and supported action. Treating lower Data% as proof that the pool is healthy would miss the other resource.
Official autoextension conditions: RHEL 9's thin-pool procedures describe monitoring and automatic extension settings. Our recommendation checks monitoring, policy, available VG extents and observed extension events together. A threshold setting alone cannot manufacture backing capacity.
In a control case with only 8 GiB of VG headroom, the selected 20 GiB increment does not fit our ledger. Alert early enough to make a supported change before exhaustion, accounting for allocation rate and response time. This is our capacity-planning recommendation, not a universal safe utilization threshold.
Official snapshot sharing: lvmthin describes thin snapshots sharing data blocks. Our inference is that reclaim estimates must account for references, not just apparent file deletion. A filesystem deletion, a discard reaching the pool, and the final release of an unreferenced block are distinct events.
Do not assume removing a snapshot frees all of its displayed logical size. In our abstract sharing control, deleting one of two references leaves the shared block allocated; it becomes reclaimable only after the final reference is released. Actual discard behavior and pool state require verification beyond this accounting model.
How should you reason about shrink, evacuation and recovery?
Growth and shrink have different safety conditions. Official LV reduction warning: lvreduce warns about data loss when reducing a volume that still contains data in the removed area. Used-byte count alone does not establish where a filesystem's required blocks or metadata lie.
Our shrink exercise starts with an 80 GiB LV and an 80 GiB filesystem geometry. Only 30 GiB of file data are used. Reducing the block device to 60 GiB first violates the geometry bound despite that low usage.
For a filesystem and workflow that support reduction, our ordering requirement is to establish a valid smaller filesystem before reducing its underlying device. The abstract companion rejects filesystem_size > LV_size; it does not implement filesystem relocation or certify that a shrink is safe.
Official RHEL 9 scope: The physical-volume management chapter states that its XFS workflow does not support shrinking. For that environment, our recommendation is to consider migration to an appropriately sized destination with validation and a cutover plan rather than assume an ext-family shrink procedure applies.
Preserve recoverable data and metadata before a risky capacity change. Official backup boundary: vgcfgbackup saves VG configuration metadata; it is not a backup of filesystem contents. A metadata file alone cannot restore overwritten application data.
For device evacuation, inspect which extents remain allocated on the source and whether eligible destinations can accept them. In our simple case, a source holds 16 GiB of allocated extents while destinations offer only 12 GiB free. The proposed move lacks capacity even though the source filesystem has unused blocks.
Official relocation behavior: pvmove moves allocated extents and documents checkpointed continuation for interrupted operations. Our recommendation is to inspect the current operation and extent locations before restarting or removing a device. A background command returning is not proof that relocation finished.
After a move, verify that the source's allocated extents are gone, the expected LVs remain accessible and a representative workload still behaves correctly. Only then does removal satisfy the intended dependency order. Recovery must account for the actual remaining placement, not just the original plan.
Finish the interview answer with an observed state: “The intended LV and filesystem grew; VG free extents match the allocation; pool data and metadata have verified headroom; the application operation succeeds.” State any layer not exercised by your test.
Sources and Further Reading
- RHEL 9: LVM Architecture
- RHEL 9: Basic Logical Volume Management
- RHEL 9: Physical Volumes and Filesystem Restrictions
- LVM2 lvmthin(7): Data, Metadata and Shared Blocks
- LVM2 lvextend(8): Extension and Allocation
- LVM2 lvreduce(8): Reduction Preconditions
- LVM2 pvmove(8): Extent Relocation and Interruption
- LVM2 vgcfgbackup(8): Configuration Metadata
- XFS xfs_growfs(8): Mounted Filesystem Growth
- resize2fs(8): ext-family Filesystem Resizing
Research checked October 6, 2026. Manual-page behavior and RHEL 9 workflows are scoped above. Original arithmetic checks do not resize, repair or recover a real filesystem.