GitHub user Ryan-AccuWeb-Cloud added a comment to the discussion: Clarification 
on Storage Overprovisioning Factor

Hi @vishnuvs369 ,

Yeah, this trips up a lot of people — happy to clear it up.

**So how does the factor actually work?**

The `storage.overprovisioning.factor` (default is 2) is a global setting. It 
applies to storage pools that support thin provisioning — mainly NFS, and thin 
iSCSI/FC on some hypervisors. You can't set it per-pool out of the box, which 
is a bit annoying (there's an old feature request for it: CLOUDSTACK-6092).

**Your numbers — you've got it right**

With a factor of 2 on a 17.60 TiB pool, CloudStack treats it as:

17.60 × 2 = **35.2 TiB allocatable**

So yep, that's where the 35.2 TiB comes from. It's basically CloudStack saying 
"I'll let you thin-provision up to double the physical size."

**What allocated vs. used actually means**

This is the part that confuses most folks:

- **Allocated (14.27 TiB / 81%)** — this is just the sum of all the volume 
sizes CloudStack has handed out. It's what *would* be used if everyone filled 
their disks completely.
- **Used (4.84 TiB / 27.5%)** — this is the real physical space actually 
sitting on disk right now (basically what `df` would show you).

So in your case, people have been given 14.27 TiB worth of volumes, but they're 
only actually using 4.84 TiB. That gap is exactly why overprovisioning exists — 
most VMs never fill their disks.

**What happens when allocated hits 100%?**

CloudStack stops letting you create new volumes on that pool (and typically 
blocks VM deploys that need a new volume). Simple as that.

One thing to watch out for: there have been bugs in some versions where resize 
or migration operations don't do the capacity check properly, and allocated 
sneaks past 100%. So don't rely on that 100% limit as a hard wall.

**The real risk with factor = 2**

Here's the thing — factor 2 assumes your average disk usage stays **under 
50%**. If people start actually filling their disks, you'll run out of 
*physical* space long before allocated ever hits 100%.

That's the trap. Allocated says "everything's fine, you're at 81%," but you 
could be near physical exhaustion and not realize it until writes start failing.

**What I'd recommend**

- Watch **Used**, not Allocated. Used is your real limit.
- Keep actual usage under ~80% of physical capacity to be safe.
- If your users tend to fill disks (or you're not sure), drop the factor to 1.5 
or even 1.
- Factor 2 is fine if you trust that utilization stays low. Factor 3+ is asking 
for trouble unless you've got data proving people barely use their disks.

**TL;DR** — Yes, 35.2 TiB is the allocatable number. CloudStack will block new 
volumes at 100% allocated, but the real danger is running out of *physical* 
space first. Keep an eye on Used and you'll be fine.


Regards,
Ryan | AccuWeb.Cloud
Cloud & Infrastructure Support

GitHub link: 
https://github.com/apache/cloudstack/discussions/13973#discussioncomment-18493686

----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]

Reply via email to