A Thin Volume Can Be Larger Than Its Backing: Compare Logical Size and Pool Space

Follow the allocation beneath the volume size

An offer for an 8 TiB thin volume leaves a crucial question unanswered: how much backing is committed to that volume when it needs more space?

Red Hat Enterprise Linux 10 LVM provides a concrete example. Its documentation describes physical extents assigned to a thin pool and thin logical volumes given virtual sizes that can exceed that pool's capacity. Physical allocation follows usage rather than reserving the entire virtual size upfront. The Linux kernel's dm-thin reference describes multiple virtual devices on one data volume, with metadata held separately.

The mechanism separates the range of volume addresses from the pool space allocated beneath them. Mapping records connect a volume's backed regions to the pool's data blocks. Naming a larger address range does not create more blocks in that pool. A capacity reservation therefore needs its own stated policy and scope; it cannot be inferred from the volume's size.

The related Raw, Protected and Client-Usable Storage guide explains the earlier deductions from drive totals. Start this comparison after those deductions have been resolved. The question here is whether the resulting pool can support the allocations sharing it.

References: [R1][K1]

Work three 8 TiB volumes through one 12 TiB pool

Consider an invented offer with exactly 12 TiB available for data backing after protection, reserves and capacity set aside for metadata have already been accounted for. That 12 TiB is the total data pool, including both its currently allocated and unallocated portions. It backs three thin volumes, A, B and C, each with a virtual size of 8 TiB.

All quantities are exact TiB; 1 TiB equals 2^40 bytes. Stipulate disjoint allocations with no compression, deduplication, snapshot sharing or other pool consumers. Metadata is a separate finite resource whose adequacy is outside this arithmetic. These assumptions isolate the shared data-capacity question.

The volumes expose 8 + 8 + 8 = 24 TiB of addressable space. Their current allocations are 2 TiB for A, 3 TiB for B and 4 TiB for C. Together they occupy 2 + 3 + 4 = 9 TiB of the pool, leaving 12 - 9 = 3 TiB of unallocated data backing.

Against their individual virtual limits, A has 6 TiB unallocated, B has 5 TiB and C has 4 TiB. Adding those differences gives 15 TiB. That is unused virtual address space across the three volumes; the pool still has only 3 TiB of unallocated backing. Treating those 15 TiB as physically available would count capacity the offer has not supplied.

These are stipulated pool allocations, not filesystem file sizes. A real comparison needs the platform's corresponding allocation figures and the population sharing the same backing.

References: [U1]

Test the combined growth before accepting each volume separately

The buyer now declares additional unique allocations of 1 TiB on A, 1 TiB on B and 2 TiB on C, all to remain present together. The resulting per-volume allocations would be 3 TiB, 4 TiB and 6 TiB. Each fits within its own 8 TiB virtual size.

The pool calculation reaches a different result. The additions require 1 + 1 + 2 = 4 TiB of new data backing, while only 3 TiB remains. Equivalently, the resulting total would be 3 + 4 + 6 = 13 TiB against a 12 TiB pool: a 1 TiB shortfall under the stated assumptions.

This is why checking only that each volume stays below 8 TiB misses the buyer's requirement. A supplier could answer all three volume-limit questions correctly while leaving the combined growth unsupported. The shared pool is the resource that the three proposals compete for.

Increasing the stated virtual maximum of C would not close this particular gap. C's proposed 6 TiB already fits within 8 TiB. To substantiate the same simultaneous allocations, the offer must account for the missing backing; a revised logical size is not that accounting.

The 1 TiB deficit is an allocation screen for this idealized offer. It does not predict which actual request would encounter a limit, how many writes would complete or how an application would respond.

Read data backing and metadata capacity separately

RHEL 10 defines data_percent as the share of allocated pool data space in use, and metadata_percent as usage of the space holding mapping metadata. They have different denominators. A low data percentage cannot establish spare metadata capacity.

The checked dm-thin reference reports used/total data blocks and used/total metadata blocks separately. For data-space exhaustion, it describes configurable queueing or erroring of I/O. It separately states that metadata-space exhaustion causes I/O errors. This rolling kernel reference is not evidence of an installed kernel version, and its behavior must not be assigned to every array or cloud service.

For a real offer, ask the storage owner to interpret both resources for the supported product and configuration. An alert or a stated future expansion does not supply missing backing today. Any growth undertaking needs to identify which resource it covers and when that capacity becomes available.

References: [R1][K1]

Compare the backing commitment behind the same logical size

Two suppliers can both offer an 8 TiB thin volume while describing different commitments. One might provide a virtual maximum backed by an unreserved shared pool. Another might explicitly commit backing for a defined allocation and growth period. The matching 8 TiB labels alone do not make those offers equivalent.

Ask what, if anything, is reserved for this buyer; how that reservation relates to other allocations; and whether the declared growth must fit using current backing or depends on a later addition. The supplier should connect its answer to current pool use and all other consumers of that pool. A current free-space observation and a commitment to keep capacity available answer different questions.

The kernel permits shared volume data. For a proposal involving snapshots or other sharing, request pool allocation accounting instead of assuming disjoint contents. Credit planned reclamation only when the storage owner substantiates the backing available for the promised growth.

In the fictional case, a claim covering only A's extra 1 TiB is narrower than a promise covering all three additions together. Make that distinction explicit before comparing price or treating the proposal as sufficient for the buyer's requirement.

References: [K1]

Keep SSD reserved flash at its own layer

The word overprovisioning can refer to a different capacity relationship inside an SSD. Samsung's discussion of SSD data placement describes device overprovisioning as NAND capacity beyond the capacity exposed to the host.

That reserved flash is not the unused virtual address space of the thin volumes in this example. An SSD's internal reserve does not substantiate a reservation for A, B or C in the shared pool. If a supplier uses the same word for both, ask it to name the layer and quantities involved. Keep any drive-level capacity treatment in the earlier reconciliation instead of adding reserved flash to the stipulated 12 TiB.

References: [S1]

Carry the equipment decision into the physical installation scope

If resolving the capacity offer also introduces storage hardware into the deployment, the related GPU Storage Network Handoff guide helps identify its physical endpoints and connections.

Leviathan's rack-and-stack service covers agreed physical mounting, IT cabling, labeling and handoff records for customer-furnished equipment, subject to the actual site and scope. Use the service page or its project inquiry to share a nonconfidential equipment summary, rack positions, approved connection requirements and required physical records. Identify the appointed storage owner for allocation, reservations and software work so the physical installation request has a clear boundary.

References: [L1]