Why a 60GB ZFS Snapshot Used 5TB: The Thin Provisioning Trap

The moment everything stops making sense

You think you understand snapshots. Everyone does: freeze the disk, track the changes, move on. It's worked that way for years across platforms, so when something explodes from 60GB to multiple terabytes, your first instinct is panic, and curiosity comes much later.

That's where this story starts. A simple expectation collides with an ugly surprise: creating a snapshot suddenly doubles disk usage. This is no small overhead or rounding error; it has full-on duplication vibes. "Why is a 60GB snapshot eating 5TB?" reads less like a question and more like disbelief.

The worst part is that at first glance, nothing looks wrong. The UI says one thing, ZFS says another, and somewhere in between, your storage pool keeps filling up.

The misleading mental model: "snapshots only store changes"

Almost everyone brings the same assumption into this: snapshots are lightweight, they store differences, and they're efficient by design. That belief is incomplete more than it is wrong.

One voice tried to steer things back to basics, pointing out that ZFS snapshots "only consume the amount of disk space in the 'refer' column." That's the textbook answer, and it's clean, logical, and comforting.

That explanation crashes into reality when your disk usage doubles anyway, and confusion turns into frustration. Now it feels like the system is lying to you, or worse, doing something wildly inefficient behind the scenes. Spoiler: it's doing exactly what you told it to do.

The hidden culprit: thick provisioning bites back

The turning point comes from a deceptively simple detail: thin provisioning wasn't enabled, and that one checkbox changes everything.

Without thin provisioning, every snapshot effectively reserves the full size of the disk on top of tracking changes. When that disk is 6TB, the math gets ugly fast, and what looks like a "small" snapshot behaves like a full clone in terms of space allocation.

One comment put it in plain terms: if you don't enable thin provisioning, "every snapshot will take up its full size rather than the differences." That's the missing piece. It's neither a bug nor a Proxmox quirk, just a configuration mismatch between expectation and reality.

The second trap: "fixing it" isn't instant

Things get even more frustrating from here. You find the solution, flip the setting, and expect everything to correct itself, and it doesn't.

Enabling thin provisioning doesn't retroactively fix existing disks. One user explained it clearly: it "won't do anything on its own for existing disks." That realization hits hard, because the misconfiguration is now baked into your current storage layout.

Now you're dealing with terms like refreservation, manual conversions, and commands that feel far more invasive than a simple toggle. What started as a snapshot question has turned into a storage migration problem.

The realization phase: "oh… it was me"

Every debugging process has a moment where the confusion snaps into clarity. In this case, it's almost audible: "I get it now."

That shift matters, because the system behaved exactly as designed and the misunderstanding was about how its pieces interact. Thick provisioning plus large disks plus snapshots equals massive space consumption. It's predictable once you see it and invisible until you do.

That's what makes this kind of issue so frustrating. In hindsight it's simple, but it's buried behind assumptions that feel universal and turn out not to be.

The bigger divide: ZFS purists vs. UI-first users

The situation also exposes a deeper divide in how people approach systems like Proxmox.

On one side are the ZFS-native thinkers. They live in zfs list, understand refer vs. used, and treat the Proxmox UI as a convenience layer. For them, this issue is almost obvious: of course provisioning settings affect snapshot behavior.

On the other side are users who trust the abstraction. They expect snapshots to behave the way they do everywhere else, and they rely on the UI to reflect reality without reinterpreting it. When it doesn't, it feels like something is broken, even when nothing is.

Neither side is wrong. They're just speaking slightly different languages.

What this actually teaches you

If there's one takeaway, it's that storage systems don't forgive assumptions, and ZFS forgives them least of all.

Thin vs. thick provisioning sounds like a minor detail until it doubles your disk usage. Snapshots sound lightweight until they inherit the full weight of your configuration. And toggles that look harmless can decide how terabytes get allocated behind the scenes.

Enabling a setting is only half the fix; the other half is understanding the model underneath it. Once you do, the behavior stops feeling random and starts feeling inevitable, which may be the most frustrating part of all.