When you standardise LVM provisioning across a fleet of Linux servers, how do you decide how much of each volume group to allocate to logical volumes up front rather than leaving extents unallocated?

## The asymmetry that drives everything Every other consideration is downstream of one fact: in LVM, growth and reclamation are not mirror images. - **Growing** is online, fast and boring. Add extents with `lvextend`, grow the filesystem with `resize2fs` or `xfs_growfs` (or let `-r` do both), and no service notices. - **Reclaiming** is an outage on ext4 — `resize2fs` shrinks only while unmounted — and does not exist at all on XFS, the default on RHEL-family systems. Getting space back from an XFS volume means creating a new smaller volume, copying, swapping and deleting. That makes an allocation decision effectively one-way. Unallocated extents, by contrast, keep every option open. When one direction is cheap and the other is expensive or impossible, the sound default is to stay on the cheap side and move only when you have evidence. ## What the reserve buys beyond growth Free extents are not just future capacity for the volume that runs out. They are working room for LVM itself. Evacuating a failing physical volume with `pvmove` requires free extents on the *remaining* devices to receive the data; a group with everything allocated cannot perform that migration at all without first adding a disk, which is not always something you can do at three in the morning. A group that runs at, say, eighty per cent allocated has an escape route that a fully allocated group does not. ## What the reserve costs Be honest about the other side, because a principal-level answer that only lists benefits is not a judgement, it is a preference. - **Idle capacity.** Storage you provisioned, paid for and are not using. On managed cloud volumes billed by provisioned size, that cost is direct and continuous. - **Operational dependence on noticing.** A lean policy trades pre-allocated slack for a promise that someone will act before a volume fills. If filesystem-utilisation alerting is weak or the growth procedure is a manual ticket with a slow queue, the lean policy converts an over-provisioning cost into an outage risk. That is a bad trade, and the right response is to fix the alerting and automate the growth, not to abandon leanness. - **Change volume.** Growth-on-demand means more changes to production, each small but each a change. That argues for automation with guardrails rather than repeated manual intervention. ## How the choice varies by workload One policy across a fleet is convenient, but the sizing inside it should not be uniform: - **Predictable, slow-growing data** — application logs and artefacts with retention policies — can be sized close to forecast, because the growth rate is knowable and the alert lead time is long. - **Bursty or unbounded growth** — a database that can double after a schema change, a cache with no eviction — deserves more slack, because the time between "eighty per cent" and "full" can be minutes rather than weeks. - **Anything where filling the volume is an outage rather than an inconvenience** — a database's data directory, a broker's journal — argues for both slack and an automated growth path, since the alert-to-action window is what actually protects the service. ## Where thin provisioning fits LVM offers over-provisioning as an alternative shape of the same bet: volumes present more capacity than physically exists and consume it as written. That optimises for utilisation and moves the risk from "a volume fills up" to "the shared pool fills up", which is a correlated failure affecting every volume at once. It is a legitimate choice for environments with strong pool-level monitoring and a fast path to add capacity, and a poor one where a single pool backs unrelated critical services. Whichever shape you pick, the underlying question is unchanged: who is watching the number, and how fast can capacity arrive after they do? ## The filesystem choice is part of the policy Because XFS cannot shrink, standardising on it makes the lean policy more important, not less — an over-allocation there is not recoverable without data movement. Standardising on ext4 buys an offline escape hatch at the cost of a maintenance window. Either is defensible; what is not defensible is choosing the filesystem and the allocation policy independently, then discovering the interaction during an incident. ## A defensible default Size to a near-term forecast plus headroom, hold a deliberate unallocated reserve in every group, alert on filesystem utilisation with enough lead time for the growth to complete, automate the grow step so it is a routine action rather than an improvisation, and document the reserve as reserved — not as spare capacity to be quietly consumed the first time someone needs a volume in a hurry.