Storage Efficiency • WAFL Internals
Dedupe, Compress, Compact: How WAFL Squeezes Every Byte Out of Capacity Flash
Flash is no longer the exotic performance tier — it’s becoming the default. Which makes the question of how efficiently you use every terabyte of it more important than ever.
Every gigabyte of flash you buy today costs more than the equivalent gigabyte of spinning disk, and that gap doesn’t look like it’s closing anytime soon. So the industry’s response has been predictable: build flash platforms that are cheaper per raw terabyte — QLC-based, high-density, "capacity" flash — and then lean hard on software to make every one of those terabytes count. That second half is where things get interesting, and where I think WAFL quietly does some of its best work without anyone talking about it much.
NetApp’s AFF C-Series and ASA C-Series are built exactly for this moment — QLC capacity flash that competes on cost with hybrid arrays while still being all-flash. But the hardware is only half the story. The other half is a set of storage efficiency mechanisms baked directly into WAFL (Write Anywhere File Layout) that have been maturing since ONTAP 8.3, and that I think deserve a closer look than the usual "we do dedupe and compression" bullet point.
A Three-Stage Pipeline, Not Three Separate Features
The thing people often miss is that dedup, compression, and compaction on ONTAP aren’t three independent knobs you flip and hope they add up. They run as an ordered, inline pipeline, each stage cleaning up what the previous one left behind, before a single block ever touches the drive. On an AFF or ASA system the sequence is:
Notice the order: dedup first, then compression, then compaction. That sequencing matters. Deduplication works on whole 4KB blocks, so it needs to run before anything gets shrunk or repacked — otherwise you’d be comparing hashes of compressed fragments instead of the original data, and you’d miss matches. Compaction runs last precisely because its job is to clean up after the other two: it looks at whatever is left over — compressed remnants, small files, oddly-sized I/O — and tries to fit several of those into a single physical block instead of wasting the rest of it.
The 4KB Problem Compaction Was Built to Solve
WAFL has always written in 4KB blocks. That's a deliberate, sensible design choice — it lines up with how flash and modern drives organize physical space. But it creates an obvious inefficiency: if compression shrinks an 8KB write down to 3KB, or if you're writing a pile of small files that are each only 1–2KB, you still end up consuming a full 4KB block for each of them. The leftover space in that block is simply wasted — padding that customers are paying full flash prices for.
Inline data compaction, introduced with ONTAP 9, exists specifically to close that gap. It takes multiple sub-4KB chunks — whether they're small uncompressed files or the leftovers of compression — and packs several of them into a single physical 4KB block before it's ever written to disk. Three separate 1KB writes that would have consumed three full blocks can now share one. It's a genuinely elegant fix for a problem that's specific to fixed-block architectures like WAFL, and it's additive to whatever dedup and compression already saved you.
“Compaction doesn’t compete with dedup or compression — it cleans up after them, turning the space they couldn’t reclaim into usable capacity.”
Efficiency That Runs When the CPU Isn’t Busy
Here's the part I find most underrated: not all of this efficiency work happens inline in the write path. ONTAP also runs storage efficiency as a background process that opportunistically uses spare CPU cycles — the cycles that would otherwise sit idle between bursts of host I/O. This is where Temperature-Sensitive Storage Efficiency (TSSE) comes in, introduced in ONTAP 9.8 and enabled by default on thinly provisioned AFF volumes, and enabled by default across the board on the C-Series.
TSSE works on a simple but clever idea: not all data deserves the same compression effort. Hot, frequently overwritten blocks get compressed in small 8KB groups — fast to process, low latency impact, decent savings. But data that cools off — typically after about two weeks of inactivity — gets picked up by a background scan and recompressed into larger 32KB groups using a stronger algorithm. Bigger groups compress better because there's more redundancy to exploit across a larger window of data, but decompressing them is heavier, which is exactly why you don't want to do it inline on every write. Applying that heavier compression only to cold data, and only when the system has cycles to spare, is a genuinely well-thought-out trade-off between performance and density.
It's worth noting ONTAP's newest AFF platforms (A70, A90, A1K) take a different path — they use a dedicated hardware offload processor to run 32K compression continuously rather than relying on temperature and idle CPU cycles. But for the C-Series capacity flash line specifically, TSSE running on spare CPU is the default mechanism, and it's a big part of why these QLC-based systems can compete on effective cost per terabyte against far less sophisticated capacity architectures.
Why This Is the Whole Point of Capacity Flash
QLC flash is cheaper per raw gigabyte than TLC, but it's also where the "flash is expensive" argument actually gets settled or lost. If a QLC-based array only stored data at its raw density, it wouldn't be competitive against high-capacity hybrid or spinning-disk systems on cost — you'd be paying a flash premium without reaping a flash-level density advantage. The entire economic case for AFF C-Series and ASA C-Series rests on software making the effective capacity meaningfully larger than the raw capacity, consistently, without the customer having to think about it.
That's what this three-stage pipeline plus TSSE is really doing under the hood: dedup removes redundant data, compression shrinks what's left, compaction eliminates the wasted space around fixed 4KB blocks, and TSSE keeps squeezing cold data further over time using capacity the system would otherwise leave idle. None of it requires the customer to run manual jobs, tune schedules, or trade away performance to get it — it's inline and default-on for the platforms built around it.
From a practitioner's seat, this is the detail I try to get customers to look past the headline $/GB number for. Two flash arrays can have identical raw capacity and wildly different effective capacity, and the difference isn't marketing — it's whether the filesystem underneath was actually designed for this problem from the ground up, or bolted efficiency features on afterward.
Curious how this plays out in your own environment? If you're running AFF or ASA today, volume show-footprint is worth a look — it'll show you exactly how much of your footprint reduction is coming from compaction versus compression versus TSSE. I'd genuinely like to hear what ratios people are seeing in the field — drop a comment or find me on LinkedIn.
Disclaimer: This article reflects my personal views and technical understanding as an individual in the storage industry. It does not represent an official position of NetApp or any employer, and it isn't sponsored or reviewed content. Technical details are drawn from publicly available NetApp documentation and community resources; please verify against official docs for your specific ONTAP version before making architecture or purchasing decisions.
References: NetApp ONTAP documentation — Storage efficiency overview, Temperature-sensitive storage efficiency, Deduplication/compression/compaction concepts; NetApp Community — "A Look Inside NetApp Inline Data Compaction."
Comments