Home / Reference / Storage efficiency

ONTAP storage efficiency: dedupe, compression, and compaction

Storage efficiency is one of ONTAP's headline features — and one of the most misunderstood. WAFL's copy-on-write design makes post-process dedupe possible, but modern ONTAP (9.x on AFF) does most of its savings inline, before data ever hits disk: zero-block sharing, inline dedupe, adaptive compression, and compaction all fire in the write path. This guide covers what each technology actually does, where it runs (inline vs background), how to enable it per volume with real CLI, and how to read the efficiency numbers without fooling yourself.

The four core technologies

Technology	What it does	When it runs
Dedupe	Replaces duplicate 4 KB blocks with pointers to one shared block (persistent block sharing via the aggregate-level volume block sharing)	Inline (`-inline`) or background (scheduled)
Compression	Packs multiple blocks into compressed clusters; adaptive compression skips incompressible data instead of wasting CPU	Inline or background
Compaction	Packs multiple small I/O writes into a single 4 KB block on disk	Inline only (AFF by default)
Zero-block sharing	All-zero blocks are never written at all — they're shared for free	Always on, no configuration

Mental model: dedupe removes duplicate data, compression shrinks individual data, compaction fills partially used blocks. They attack different kinds of waste and stack multiplicatively — which is why a thin-provisioned VMware LUN on AFF routinely shows a 3–5× total ratio while a database volume shows far less.

Inline vs background: which to use

On AFF systems running recent ONTAP 9.x releases, inline efficiency is enabled by default on new volumes and is the recommended mode: every write is checked once, and you never pay a second read of the data later. Background (post-process) dedupe still matters in three cases:

Data that arrives duplicated over time — file shares, home directories, backup targets where copies land after the initial write.
Existing volumes built before inline settings were standard — enable background dedupe and schedule a scan.
CPU-constrained platforms (some FAS models) — shifting work to a scheduled window keeps latency predictable.

Compression deserves a caveat: inline adaptive compression is safe for nearly everything, but compressing already-compressed data (JPEG, video, .zip) burns CPU for ~0% gain. Adaptive mode largely handles this itself by detecting incompressible extents.

The command set (ONTAP 9.x)

# --- Enable per-volume efficiency (the common case) ---
volume efficiency on -vserver vs1 -vol vol_data
# Inline variants (AFF default):
volume efficiency modify -vserver vs1 -vol vol_data -inline-dedupe true
volume efficiency modify -vserver vs1 -vol vol_data -inline-compression true
volume efficiency modify -vserver vs1 -vol vol_data -policy auto   # adaptive compression policy

# --- Background dedupe schedules ---
efficiency policy create -vserver vs1 -policy nightly-dedupe -type scheduled \
  -schedule daily -duration 6 -dedupe-background true
volume efficiency modify -vserver vs1 -vol vol_archive -policy nightly-dedupe

# --- Kick off a scan manually ---
volume efficiency start -vserver vs1 -vol vol_archive
volume efficiency show -vserver vs1            # state, progress, last-op stats

# --- Measure savings ---
volume efficiency show -vserver vs1 -vol vol_data \
  -fields policy,dedupe-saved,compression-saved,total-saved,percent-total-saved
# Logical vs physical usage (the ratio everyone quotes):
vol show -vserver vs1 -vol vol_data \
  -fields size-used,size-logical-used,physical-used,logical-space-efficiency

# --- Aggregate-wide view (includes shared-block savings across volumes) ---
aggr show -fields physical-used,logical-used,capacity-tier-used
aggr efficiency show                            # where supported

# --- Cross-volume dedupe: share identical blocks between sibling volumes ---
volume efficiency start -vserver vs1 -vol vol_clone2 -scan-old-data
# Note: volume block sharing works within one aggregate; clones made with
# `volume clone create` share parent blocks automatically (flexclone).

# --- File-system level analytics: find dedupe candidates ---
volume file fingerprint start -vserver vs1 -vol vol_data
volume file fingerprint show -vserver vs1 -vol vol_data

# --- Disable (rare; e.g. benchmarking baseline) ---
volume efficiency off -vserver vs1 -vol vol_data

Gotcha: volume efficiency start on a large volume with -scan-old-data semantics can run for hours and compete with foreground I/O on HDD aggregates. Schedule it in a maintenance window; on AFF the impact is usually negligible.

Reading the numbers honestly

Every vendor quotes an efficiency ratio, but the denominators differ. On ONTAP, keep three numbers straight:

SIS saved space (volume efficiency show) — savings from dedupe/compression/compaction within the volume's own data.
Thin provisioning savings — space between the volume's logical size and what's actually allocated from the aggregate. Not counted unless you include it.
Shared-block savings — FlexClones, snapshot-shared blocks, and cross-volume block sharing live at the aggregate level; they never appear in a single volume's stats.

The number that pays your hardware bill is logical-used ÷ physical-used at the aggregate level. A realistic expectation set by workload:

Workload	Typical total ratio
VMware / virtual desktops (AFF, thin)	3:1 – 5:1
General file services (NFS/SMB shares)	1.5:1 – 2:1
Databases (Oracle/SQL, pre-provisioned)	1.2:1 – 2:1 (compression-dependent)
Backups / archive with snapshots	5:1 – 20:1 (snapshot + dedupe stacking)
Media / already-compressed data	~1:1 — do not expect savings

Efficiency and its neighbors

Snapshots: snapshot copies are free at creation because WAFL never overwrites blocks; dedupe then collapses duplicate blocks across snapshot versions. This stacking is why retention-heavy workloads see outsized ratios — see the copy-on-write & snapshots guide.
FabricPool: tiered (cold) data keeps its efficiency characteristics in the object store; FabricPool adds its own compression of cloud chunks. See the FabricPool deep-dive. One caution: heavy rehydration reads of deduped data can add latency — profile first.
FlexClones: a clone shares 100% of parent blocks until diverged — instant, zero-cost test/dev copies. Combined with dedupe, test environments cost almost nothing.
Cloud volumes (FSx/ANF): efficiency is managed for you on Azure NetApp Files; on FSx for ONTAP the same SIS commands apply through your SVM — see the FSx guide.

Troubleshooting quick hits

Symptom	Likely cause / fix
`volume efficiency show` says state `disabled`	Licensing (`system license show -package eficiency` on FAS) or manually disabled; run `volume efficiency on`
Ratio drops after migration	Efficiency metadata doesn't always survive non-ONTAP transfers; run a fresh `volume efficiency start -scan-old-data`
Dedupe job never finishes	Check `volume efficiency show -instance` progress and the schedule window (`-duration`); widen the window or split volumes across policies
High CPU during scans	Move to background scheduling off-peak, or verify inline mode so scans stay incremental
"Logical used" much larger than aggregate growth	That's thin provisioning + shared blocks working — compare against `physical-used`, not logical

Related guides

Aggregate capacity math — raw vs usable before efficiency
WAFL deep-dive — why copy-on-write enables all of this
FabricPool cloud tiering — efficiency meets object storage
Volume space troubleshooting — when savings don't materialize
SVM administration — where volumes and policies live