Capacity Math — The 7-Stage Waterfall
S2DCartographer computes a 7-stage theoretical capacity waterfall showing how raw storage is accounted for from physical disks to final usable capacity.
The 7 Stages
flowchart LR
S1["**Stage 1**\nRaw Capacity\n(capacity disks)"]
S2["**Stage 2**\nVendor (TB)\n(informational)"]
S3["**Stage 3**\nPool Overhead\n(~1%)"]
S4["**Stage 4**\nReserve\n(min(N,4)×drive)"]
S5["**Stage 5**\nInfra Volume\n(pool footprint)"]
S6["**Stage 6**\nAvailable\n(for volumes)"]
S7["**Stage 7**\nUsable Capacity\n(÷ resiliency factor)"]
S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7Stage 1 — Raw Capacity
Sum of all capacity-tier disk sizes across all nodes. Cache-tier disks are excluded — they don't contribute to pool capacity.
NOTE
3-node, all-NVMe cluster
4 nodes × 4× Samsung PM9A3 3.84 TB NVMe = 16 drives × 3.49 TiB = 55.88 TiBStage 2 — After Vendor Labeling Adjustment
Shows the discrepancy between drive labels (TB) and what Windows reports (TiB). This is the unit-conversion gap described in TiB vs TB. No actual bytes are lost — this stage makes the difference visible.
NOTE
No bytes change at Stage 2 Stage 2 is informational. The Size value does not change from Stage 1. The stage description shows the vendor-labeled TB value so you can compare it to your drive specification sheets.
Stage 3 — After Storage Pool Overhead
The pool consumes a small amount of space for metadata. Approximately 0.5–1% of raw capacity. The actual value comes directly from StoragePool.TotalSize via CIM.
Stage 4 — After Reserve Space
Microsoft recommends keeping min(NodeCount, 4) capacity drive equivalents unallocated in the pool. This reserve allows the pool to rebuild after a drive failure without exhausting available space.
Reserve = min(NodeCount, 4) × LargestCapacityDriveSizeNOTE
Reserve calculation
4-node cluster, 3.84 TB drives (3.49 TiB each):
Reserve = min(4, 4) × 3.49 TiB = 13.97 TiBS2DCartographer reports the recommended reserve, the actual unallocated space, and one of three statuses:
| Status | Condition |
|---|---|
Adequate | Free space ≥ recommended reserve |
Warning | Free space is 50–100% of recommended |
Critical | Free space < 50% of recommended |
CAUTION
Critical reserve A Critical reserve means the cluster cannot sustain a drive failure and complete a full rebuild. Free pool space immediately.
Stage 5 — After Infrastructure Volume
Azure Local automatically creates an infrastructure volume for cluster metadata, storage bus logs, and CSV metadata. This typically consumes 250–500 GiB depending on cluster size.
S2DCartographer detects the infrastructure volume by name pattern and size heuristic, and breaks it out separately so it does not inflate the workload capacity figure.
NOTE
Detection patterns Volumes are classified as infrastructure if they match Infrastructure_<guid>, ClusterPerformanceHistory, UserStorage_N, HCI_UserStorage_N, SBEAgent, or contain infra in the name.
Stage 6 — Available for Workload Volumes
What remains after reserve and infrastructure volume. This is the budget from which all user-created volumes draw their pool footprint.
Stage 7 — Usable Capacity
Stage 6 (Available for Volumes) divided by the resiliency factor. This is the amount of logical data you can actually store.
| Resiliency type | Factor | Efficiency |
|---|---|---|
| Three-way mirror | ÷ 3 | 33.3% |
| Two-way mirror | ÷ 2 | 50.0% |
| Nested two-way mirror (2-node) | ÷ 4 | 25.0% |
| Single parity (4-node) | varies | ~66.7% |
| Dual parity / LRC (6-node) | varies | ~66.7%+ |
BlendedEfficiencyPercent on the waterfall object reports the theoretical efficiency for the cluster's configured resiliency type.
NOTE
This is theoretical The waterfall shows what you can store given perfect resiliency alignment. It is not a live count of what is provisioned. Actual provisioning state is in the Volume Map and Health Checks sections of the report.
Example Waterfall
4-node cluster, 16× 3.84 TB NVMe (all capacity, all-NVMe):
| Stage | Name | Deducted | Remaining |
|---|---|---|---|
| 1 | Raw Capacity | — | 61.44 TB |
| 2 | Vendor (TB) | — | 61.44 TB (55.88 TiB) |
| 3 | Pool Overhead | −0.61 TB | 60.83 TB |
| 4 | Reserve | −15.36 TB | 45.47 TB |
| 5 | Infrastructure Volume | −0.08 TB | 45.39 TB |
| 6 | Available for Volumes | — | 45.39 TB |
| 7 | Usable Capacity | −30.26 TB | 15.13 TB |
Thin Overcommit Detection
Thin-provisioned volumes have a logical size greater than the current pool footprint. S2DCartographer flags clusters where the total logical size of all thin volumes exceeds the remaining available capacity — a dangerous condition that can cause unexpected out-of-space failures.
The OvercommitRatio from Get-S2DStoragePoolInfo and the ThinOvercommit health check in Get-S2DHealthStatus both surface this condition.
See Get-S2DCapacityWaterfall for the full waterfall API reference.
Cross-tool contract with Surveyor
S2D Cartographer (scan) and Surveyor (plan) must produce the same numbers for the same cluster. tests/maproom/unit/SurveyorContract.Tests.ps1 pins that contract using fixtures from tests/maproom/Fixtures/surveyor-contract-cases.json (example values only).
| Stage | Both tools |
|---|---|
| Raw | drive bytes x drives per node x nodes (no per-drive efficiency haircut) |
| Pool | raw x 0.99 (about 1 percent pool metadata), or the live pool size when it can be read |
| Reserve | min(nodes, 4) x largest capacity drive (Learn: plan-volumes, Reserve capacity) |
| Infrastructure volume | footprint (Cartographer reads it live; Surveyor models size / efficiency) |
| Available for volumes | pool - reserve - infrastructure footprint |
| Usable | available x efficiency, i.e. available / data copies |
What the 0.92 factor was. An early Surveyor build multiplied every drive by 0.92. That value is close to the decimal-to-binary ratio 10^12 / 2^40 = 0.9095, so it stood in for the TB to TiB display conversion, not for a real format overhead. Applying it to bytes double counted the unit change. Neither tool applies it any more; units are converted once, at display. The test asserts that stage 3 is raw x 0.99.
Documented differences. Cartographer takes a copies divisor, Surveyor an efficiency multiplier (they are reciprocals). Surveyor's expansion headroom treats dual parity as two copies; the waterfall uses the real efficiency from the node-count table. Neither difference changes the waterfall numbers.
Rack aware, nested and mixed media
- Rack aware clusters use Rack Level Nested Mirror: two-way mirror for 1+1 (two machines), four-way mirror for 2+2 and larger (four machines or more). Three-way mirror, parity and plain nested mirror are not available.
Get-S2DCapacityWaterfall -RackAwareandInvoke-S2DWaterfallCalculation -RackAwareapply this. Source: Learn, Azure Local rack aware cluster requirements, Supported node configurations. - Nested two-way mirror on two machines writes four copies (25 percent efficiency).
- Clusters with NVMe, SSD and HDD together: reserve one SSD plus one HDD per server, up to four of each (Learn plan-volumes, Reserve capacity). The waterfall detects this from the physical disk inventory.