Where Storage Space Disappears: Thin Provisioning to Snapshots
Storage that reports plenty of free space and then runs out is one of the more alarming ways a system fails, because it happens without warning and stops writes across everything using that storage. It is almost always one of a few causes.
Thin provisioning: allocated is not used
The most common cause on modern storage.
Thin provisioning lets you present more capacity to systems than physically exists, on the reasonable assumption that most of them will not fill what they were given. A ten terabyte volume presented to a server may consume only what has actually been written.
That is efficient and it creates a specific risk: you can allocate more than you own. If the systems using that storage grow into their allocations, the underlying pool runs out while every volume still reports free space.
The failure is abrupt. Writes stop, and they stop for everything sharing that pool rather than for the volume that grew.
Two things to watch. Pool usage rather than volume usage, because the pool is what actually runs out. And total allocated against physical capacity, so you know how overcommitted you are.
Snapshots consume space that nothing shows
The second common cause, and the least visible.
A snapshot preserves the state of data at a point in time. It costs little when taken, and it grows as the live data changes, because the original blocks must be retained.
Three consequences.
A busy volume grows its snapshots quickly. The more the data changes, the more must be retained.
Old snapshots nobody removed keep consuming indefinitely. A snapshot taken before a migration two years ago is still holding blocks.
The space does not appear in the volume's usage figure. The volume looks the same size; the pool behind it is filling.
The practical habit: review snapshot retention periodically, and set retention policies rather than taking snapshots manually and trusting someone to remove them.
Worth stating plainly: a snapshot is not a backup. It lives on the same storage as the data it protects, so it survives a mistake but not a failure of the storage itself — our backup guide covers the distinction.
Reserved and overhead capacity
Capacity that was never yours to use.
Parity consumes drives. A RAID group gives you less usable space than the sum of its drives, and double parity costs more than single — our RAID guide covers the arithmetic.
Hot spares are drives held idle against a failure, contributing nothing to capacity.
Systems reserve space for their own operation — metadata, journals, working room. Some file systems perform badly when very full, which is why that reserve exists.
Decimal and binary units differ. A drive sold as 4TB reports less in systems counting in binary units. This is a units difference rather than missing capacity — our capacity guide covers it, and the practical rule is to plan against the reported figure.
Together these mean the capacity you can actually use is meaningfully less than the capacity you bought, and that gap should be in your planning rather than a surprise.
Deduplication and compression cut both ways
Where a system reduces stored data, effective capacity depends on what you store.
The ratio achieved is data-dependent and not predictable in advance. Highly similar data reduces well; already-compressed data such as media files or encrypted archives reduces barely at all.
Two cautions. Do not plan capacity on an assumed ratio — if the ratio comes in lower than assumed, you have bought less capacity than you thought. And the ratio can fall over time as the mix of stored data changes, which means capacity that was adequate quietly becomes tight.
Watch the right number
Four things worth monitoring, and most estates watch only the first.
Pool usage rather than volume usage, since the pool is what runs out.
Total allocated against physical, so overcommitment is visible.
Snapshot consumption as a separate figure.
Rate of growth, not just the current level. A pool at 70 percent is fine; a pool at 70 percent that was at 50 percent last month is a problem with a date on it.
That fourth one is what converts a capacity emergency into a planned purchase. Our capacity planning guide covers projecting from growth rate, and our monitoring guide covers routing the alert somewhere a person reads — because a threshold nobody sees is not monitoring.
What to do when it happens
Fastest routes to breathing room, roughly in order.
Delete old snapshots, which frequently recovers a surprising amount immediately.
Find what grew. A log file that filled a volume, a runaway process, a backup written to the wrong place — these are common and quickly fixed once identified.
Move something off to different storage temporarily.
Add capacity, remembering that a new drive means a group extension or a new group, and that capacity is sized to the smallest member of a group.
And afterwards, fix the monitoring rather than only the symptom. A pool that filled once without warning will do it again.
Common questions
My volumes show free space but writes are failing. Why?
Almost certainly the underlying pool is full while the volumes still report their allocated size. With thin provisioning you can allocate more than you physically own, and when the pool exhausts, writes stop for everything sharing it rather than just the volume that grew.
Where has my space gone?
Check snapshots first. They cost little when taken and grow as data changes, old ones nobody removed keep consuming indefinitely, and the space does not appear in the volume’s usage figure — the volume looks the same while the pool behind it fills.
Why is my usable capacity so much less than I bought?
Parity consumes drives, hot spares sit idle, systems reserve working space for metadata and journals, and decimal drive capacities report smaller in binary units. Together the gap is meaningful and belongs in your planning rather than as a surprise.
Can I plan capacity around deduplication savings?
Not safely. The ratio is data-dependent and unpredictable — already-compressed media or encrypted archives reduce barely at all — and it can fall over time as your data mix changes, quietly turning adequate capacity into tight capacity.
What should I actually monitor?
Pool usage rather than volume usage, total allocated against physical, snapshot consumption separately, and rate of growth. That last one matters most — a pool at 70 percent is fine, but one that was at 50 percent last month is a problem with a date on it.
Tell us your growth rate and current pool usage, and we will help you size the addition rather than guess at it.
