Updated for 2026: this guide was originally published in February 2017. It has been rewritten for clustered ONTAP. The 7-mode commands in the original are gone; everything below uses current ONTAP volume options.
Provisioning is the decision of when storage capacity gets reserved: up front, when you create the volume, or later, as data is actually written. Thick provisioning reserves it all on day one. Thin provisioning reserves almost nothing and hands out space on demand. The difference matters because it decides whether you can promise more capacity than you physically own — and what happens if everyone calls in that promise at once.
Thin provisioning
A thinly provisioned FlexVol volume starts with no space reserved. As data is written, the volume requests blocks from its aggregate. That lets you overcommit: with 1 TB of physical storage you can present, say, 1.5 TB of volumes to your hosts, because most volumes never fill up. You only consume what is actually written.
In ONTAP you create a thin volume by setting its space guarantee to none:
volume create -vserver vs1 -volume vol1 -aggregate aggr1 -space-guarantee none
For a fully thin SAN setup, also disable space reservation on the LUN itself:
lun modify -vserver vs1 -volume vol1 -lun lun1 -space-reserve disabled
That combination — guarantee none, fractional reserve 0, LUN reservation disabled — is the smallest upfront footprint ONTAP offers, and it is the default shape on AFF systems, where the space-guarantee default is already none. On AFF, inline deduplication, inline compression, and data compaction are also on by default, so thin volumes there get efficiency savings on top.
Thick provisioning
A thick-provisioned volume reserves its full size in the aggregate at creation, including 100% of the space needed for overwrites. Nothing is shared or borrowed: any block in the volume can be written at any time, because the space is already set aside.
volume create -vserver vs1 -volume vol1 -aggregate aggr1 -space-slo thick
Thick costs more upfront capacity, but it removes an entire failure mode: the volume can never run out of space because a neighbour volume grew. That is why it still belongs on latency-critical or business-critical workloads where a write failure is not an option. Note that thick does not mean inefficient: deduplication and compression still apply and offset the upfront reservation, especially on AFF.
Semi-thick: the middle option
ONTAP also offers semi-thick (-space-slo semi-thick): the volume itself is fully preallocated, but no space is reserved for overwrites, and snapshot autodelete is switched on. It suits workloads where you want the volume’s footprint guaranteed but can tolerate snapshots being deleted automatically under pressure.
When not to thin-provision
- Consumption is unpredictable or highly volatile — you cannot forecast when the aggregate will fill.
- The application is mission-critical and even a brief write outage is unacceptable.
- Monitoring is weak. Thin provisioning without free-space alerting is how aggregates fill up unnoticed.
- New storage cannot be procured quickly. If buying disks takes months, an overcommitted aggregate can run dry before relief arrives.
Remember the blast radius: an overcommitted aggregate does not fail one volume, it fails every volume on that aggregate when free space runs out.
Running thin provisioning safely
- Monitor both volume and aggregate free space, with alerts well before full — not at full.
- Enable volume autogrow, with its maximum set to the aggregate size. Then you only need to watch the aggregate; the volume grows on its own until the aggregate is the limit.
- Keep snapshot reserve and autodelete policies deliberate: snapshots pin blocks, so space you expected to reclaim stays held until the snapshot goes.
- Reclaim freed space: deleted blocks return to the pool only when host and array cooperate (SCSI UNMAP / TRIM). Without it, a volume that shrank logically stays fat physically.
- Keep SAN LUNs and NAS shares on separate FlexVol volumes. NetApp recommends against mixing them in one volume, and it keeps provisioning, snapshots, and replication simpler.
Thin vs thick at a glance
- Upfront reservation: thin — none; thick — full volume plus overwrite reserve.
- Overcommit: thin — yes, by design; thick — no.
- Failure mode: thin — writes fail if the aggregate fills; thick — no capacity failure mode, at the cost of stranded space.
- Best for: thin — VDI, dev/test, file services, anything with low or uneven fill; thick — databases and critical workloads where a failed write is unacceptable.
For most general-purpose volumes, thin is the right default — it is certainly the default on AFF — and thick is the deliberate exception for workloads that justify it. The deciding question is not which is newer, but whether you have the monitoring to run thin safely.
Further reading: NetApp’s volume provisioning options and SAN volume provisioning documentation.