3.6 vSAN Space Efficiency: Compression, Deduplication, TRIM/UNMAP & Reclamation
Key Takeaways
- vSAN ESA applies compression per object at the top of the stack before replication, so a block is compressed once and every replica plus the network transfer benefits; ESA does not offer deduplication.
- vSAN OSA offers cluster-wide deduplication and compression together, or compression only; the OSA deduplication domain is the disk group, so identical blocks in different disk groups are not deduplicated.
- Enabling or disabling deduplication and compression on vSAN OSA triggers a rolling disk-group reformat across the cluster, which is why it is a planned change rather than a toggle.
- Erasure coding is itself a space-efficiency feature: RAID-5 4+1 on ESA costs 1.25 times raw capacity against 2.0 times for RAID-1 FTT=1.
- TRIM/UNMAP lets the guest operating system tell vSAN which blocks it has freed, without which deleted guest data continues to occupy capacity on thin-provisioned objects.
3.6 vSAN Space Efficiency: Compression, Deduplication, TRIM/UNMAP & Reclamation
Exam Focus: The blueprint lists "describe the purpose of vSAN Space Efficiency" as its own objective. The examinable distinction is which efficiency features exist in which architecture, because ESA and OSA differ fundamentally here and answer options exploit that.
Why Space Efficiency Is an Architecture Question
vSAN protects data by writing it more than once. A RAID-1 FTT=1 object consumes twice its logical size before a single byte of overhead is counted. Space efficiency features exist to claw that back, and where in the write path they operate determines how much they save.
ESA: Compression at the Top of the Stack
In the Express Storage Architecture, compression is not an opt-in cluster service. It is always available and applied per object, controlled through storage policy, and it happens at the top of the stack — before the data is replicated.
That placement is the whole point:
- A block is compressed once, then the compressed form is what gets mirrored or erasure-coded. Every replica inherits the saving.
- Because compression precedes replication, the compressed form is also what crosses the network, so ESA compression reduces east-west traffic between hosts as well as capacity consumed.
- Compression is per object, so a policy can enable it for general workloads and disable it for objects holding already-compressed data such as media archives or encrypted blobs, where compression spends CPU for no return.
ESA does not implement deduplication. If an answer option offers ESA deduplication, it is wrong.
OSA: Cluster-Wide Deduplication and Compression
The Original Storage Architecture takes the opposite approach. Efficiency is a cluster-wide setting, requires an all-flash configuration, and offers two modes:
| Mode | Scope | Notes |
|---|---|---|
| Deduplication and compression | Entire cluster | Deduplication domain is the disk group |
| Compression only | Entire cluster | Lower CPU and lower failure blast radius than full dedup |
Two consequences are heavily tested:
- The deduplication domain is the disk group, not the cluster. Two identical blocks living in different disk groups are stored twice. This is why OSA dedup ratios are lower than array-based dedup on comparable data.
- Turning the feature on or off reformats every disk group in a rolling operation across the cluster. It is a maintenance activity requiring capacity headroom and time, not a checkbox to flip during business hours.
A further OSA consideration is blast radius: with deduplication enabled, a single capacity device failure affects the entire disk group, because the deduplication metadata spans it.
Erasure Coding as a Space-Efficiency Feature
It is easy to file RAID-5 and RAID-6 under resilience only, but they are also the largest single capacity lever available.
| Policy | Capacity overhead | Saving vs RAID-1 FTT=1 |
|---|---|---|
| RAID-1, FTT=1 | 2.0× | baseline |
| RAID-5, ESA 2+1 | 1.5× | 25% |
| RAID-5, ESA 4+1 | 1.25× | 37.5% |
| RAID-5, OSA 3+1 | 1.33× | 33.5% |
| RAID-6, 4+2 | 1.5× | 25%, at FTT=2 |
In OSA this saving carried a genuine write penalty, so administrators often chose mirroring for demanding workloads. In ESA the log-structured design removes most of that penalty, which is why erasure coding is the sensible default in ESA and space efficiency and performance stop being a trade-off.
Thin Provisioning and Guest Reclamation with TRIM/UNMAP
vSAN objects are thin provisioned by default: capacity is consumed as data is written rather than reserved at creation. That efficiency degrades over time for one reason — the storage layer cannot see guest file system deletions.
When a guest deletes a 40 GB file, the guest file system marks those blocks free, but vSAN still holds them as written data. TRIM/UNMAP closes that gap: the guest issues an unmap command, vSAN releases the blocks, and consumed capacity falls to match reality.
Requirements worth remembering:
- The capability must be enabled at the vSAN cluster level.
- The guest operating system must support and issue TRIM/UNMAP commands.
- The virtual disk controller and VM hardware version must support it.
Without reclamation, a long-lived VM's consumed capacity ratchets upward and never falls, which is a classic "capacity keeps growing but nobody is adding data" scenario.
Reading Capacity Correctly
The vSAN capacity view separates several quantities that candidates conflate:
- Raw capacity — the physical total of all claimed devices.
- Usable capacity — what remains after protection overhead for the applied policies.
- Used capacity — what is actually written, after compression and deduplication.
- Slack / operations reserve — capacity vSAN holds back for resynchronisation, rebuilds, and policy changes. Consuming it removes vSAN's ability to self-heal, which is why capacity alerts fire well before the datastore is literally full.
Exam Watch: Key Scenarios and Candidate Traps
[!WARNING] Do not offer deduplication on ESA. ESA provides per-object compression only. Deduplication is an OSA feature, is cluster-wide, requires all-flash, and deduplicates within a disk group.
[!IMPORTANT] Enabling OSA dedup is disruptive to plan around. The rolling disk-group reformat is the reason this is a change-window activity. A scenario that asks for an immediate, non-disruptive capacity saving on an OSA cluster is pointing at policy change to erasure coding, not at enabling deduplication.
[!TIP] Match the symptom to the mechanism. "Consumed capacity never decreases even though users delete data" is a TRIM/UNMAP question. "We need 30 percent more usable capacity from the same hardware" is an erasure-coding question.
An architect is documenting space-efficiency options for a new vSAN Express Storage Architecture cluster. Which statement accurately describes what ESA provides?
A vSAN Original Storage Architecture cluster is running low on capacity. Management asks for the fastest non-disruptive way to increase usable capacity from the existing hardware. Which action best meets the requirement?
Application owners report that a virtual machine's consumed vSAN capacity has grown steadily for a year and never decreases, even though users routinely delete large files inside the guest. What is the most likely cause?
In a vSAN OSA cluster with deduplication and compression enabled, an administrator is surprised that two identical virtual machines on the same cluster show a lower deduplication ratio than expected. What explains this?