Raw vs Usable Capacity Explained: Where Your TB Went

Defining Raw, Usable, and Effective Capacity

In storage procurement, three terms are frequently conflated: raw capacity, usable capacity, and effective capacity. Raw capacity represents the total unformatted physical space of all drives installed in a system. In a distributed platform like Ceph, raw capacity is the aggregate disk space across all OSDs. Raw capacity ignores parity schemes, formatting constraints, and file system layouts.

Usable capacity is the volume that remains for applications to write data after subtracting protection overheads, binary conversions, and operational safety buffers. Usable capacity reflects that most storage systems should not be driven to 100% full, because performance and recovery behavior degrade as free space disappears.

Effective capacity is a vendor-marketed metric that attempts to forecast the amount of logical data an array can store after applying inline data reduction technologies like deduplication and compression. Because effective capacity relies on data-reduction multipliers and workload assumptions, it is a variable estimate rather than an engineering certainty. Base hardware procurement must always be validated against actual usable limits.

The TB vs TiB Conundrum: Binary vs Decimal Discrepancies

The most immediate capacity reduction occurs at the measurement level. Disk manufacturers sell media measured under the International System of Units (SI) decimal standard, where 1 terabyte (TB) equals exactly 1,000,000,000,000 bytes (10^12 bytes). Operating systems, hypervisors, and storage controllers, however, traditionally measure capacity using binary prefixes, where 1 tebibyte (TiB) equals 1,099,511,627,776 bytes (2^40 bytes).

Because a binary TiB is 99,511,627,776 bytes larger than a decimal TB, the binary unit is approximately 9.95% larger. When you plug a drive sold as 1 TB into many operating systems that report capacity using binary division while labelling it as 'TB', the drive will appear to lose nearly 10% of its advertised scale.

For small drives, the discrepancy seems negligible. Across an enterprise SAN, NAS, or distributed cluster containing dozens or hundreds of drives, this binary-decimal conversion accounts for terabytes of missing provisioning space. Procurement teams should convert between TB and TiB before finalising hardware sizing to ensure physical chassis can host the required binary datasets.

Parity and Redundancy: RAID and Erasure Coding Overheads

Physical drives fail, requiring redundancy mechanisms that consume raw capacity to safeguard data availability. Traditional RAID arrays and modern distributed erasure-coding architectures balance protection against storage efficiency in distinct ways.

Under RAID layouts, capacity loss depends directly on the chosen parity structure. RAID 0 provides 100% of raw disk space for usable data because it stripes blocks across drives with zero parity, offering performance at the cost of zero fault tolerance. RAID 1 mirrors data completely across disks, yielding exactly 50% usable capacity across identical drives. RAID 5 introduces single-disk distributed parity, providing a usable pool calculated as (N - 1) times drive capacity, where N is the total drive count. RAID 6 introduces dual distributed parity, consuming two drives' worth of capacity (N - 2) to survive two concurrent disk dropouts. RAID 10 combines mirroring and striping across an even number of drives, retaining 50% usable space while delivering high IOPS.

Distributed storage platforms often replace RAID with erasure coding (EC). An erasure-coded scheme splits data into k data chunks and computes m coding (parity) chunks. The mathematical overhead factor for an erasure-coded pool is calculated as (k + m) / k. For example, under a 2+1 erasure coding profile, the system generates one parity chunk for every two data chunks, yielding an overhead multiplier of 1.5x raw capacity. Storing 10 TB of usable data in a 2+1 scheme requires 15 TB of raw disk space before accounting for OS formatting or file system structures.

System Overheads: Metadata, Full Ratios, and File Systems

Even after redundancy calculations, applications cannot write across the entirety of the allocated volume. Lower-level storage engines and operating systems reserve fixed spaces for indexing, journaling, and transaction tracking. In Ceph storage using the BlueStore backend, BlueStore metadata overhead typically consumes between 1% and 2% of total OSD capacity when the metadata database is hosted on the primary data device rather than an offloaded NVMe device.

File systems introduce allocation overheads through block reservation, root buffers, and inode tables. On traditional server deployments, journal structures ensure data consistency during unexpected power cuts, silently claiming capacity before data ingress begins. Modern SSD over-provisioning also reserves flash blocks at the hardware controller level to handle garbage collection, wear levelling, and bad block retirement, reducing access beyond raw NAND packaging.

Operational safety ceilings are another critical operational bottleneck. Distributed storage clusters will stall or lock read-only if raw media reaches complete capacity. For instance, Ceph implements an internal full ratio (`mon_osd_full_ratio`), typically set at 0.95 (95% full). However, production cluster design rules state that storage planning should assume approximately 0.80 (80%) usable maximum capacity. This 20% margin provides essential operational headroom to allow automatic data rebalancing, backfilling, and recovery when individual nodes or drives fail.

The Effective Capacity Gamble: Compression and Deduplication

To offset parity and unit conversion losses, vendors often pitch 'effective capacity'. This calculation applies a hypothetical data reduction ratio—often claimed to be 2:1, 3:1, or 5:1—against usable space. These ratios assume inline deduplication eliminates duplicate blocks and compression algorithms condense text, database entries, or system logs.

While data reduction is valuable, treating vendor effective ratios as guaranteed capacity during hardware planning introduces serious operational risk. Pre-compressed media, encrypted databases, audio/video files, and scientific binary datasets achieve minimal to zero reduction. If an IT team sizes a storage platform assuming a 3:1 reduction ratio and their incoming data is already encrypted or compressed, the array will reach physical exhaustion far ahead of schedule.

Planning must always establish baseline capacity using true usable capacity after unit conversion, parity schemes, metadata loss, and safety full ratios. Data reduction benefits should be treated as a lifespan-extending efficiency bonus rather than a substitute for physical drives.

Worked Waterfall: Tracing a 100TB Raw Procurement Quote

To illustrate how raw capacity degrades into actual application space, consider an enterprise quote for 100 TB of raw disk capacity intended for a distributed cluster using 2+1 erasure coding and standard operational thresholds.

Step 1 is the baseline hardware allocation: 100 TB decimal raw space. Converted to binary units (dividing by ~1.0995), the system has approximately 90.95 TiB of raw binary space available across the controllers.

Step 2 applies the protection scheme. Using a 2+1 erasure coding layout with an overhead factor of 1.5x ((k+m)/k), dividing the 90.95 TiB pool by 1.5 reduces available protected space to approximately 60.63 TiB.

Step 3 accounts for local metadata overhead. Deducting a standard 2% BlueStore metadata footprint removes 1.21 TiB, leaving 59.42 TiB.

Step 4 applies cluster operational headroom. Applying the standard 0.80 planning usable maximum threshold leaves an administrator with approximately 47.54 TiB of safe, provisionable application storage. From an original headline figure of 100 TB raw, actual day-to-day write space is under half the unformatted marketing figure.

UK Procurement Considerations: Power, TCO, and Cloud Alternatives

For UK infrastructure teams, usable capacity calculations directly dictate power budgets, rack density, and operational expenditure. Unusable raw storage still spins disks, draws electricity, and requires cooling. According to Ofgem, the standard-variable electricity price cap for Direct Debit customers from 1 July to 30 September 2026 is 26.11 pence per kWh (with a 57.19 pence daily standing charge), rising slightly to 26.32 pence per kWh from 1 October to 31 December 2026 (with a 54.83 pence daily standing charge). The UK government's quarterly energy prices release recorded average domestic electricity at 24.14 pence per kWh in June 2026, which can be used as a general benchmark when modelling storage power costs. In a datacentre environment, a typical 2U enterprise storage shelf drawing an illustrative 400W continuously consumes approximately 3,504 kWh annually per shelf before accounting for facility power usage effectiveness (PUE).

When servers host physical drives dedicated to parity, metadata, and headroom buffers, that 'dead' capacity incurs continuous electricity charges. Applying this to our 100 TB waterfall example—where roughly 52% of raw capacity (~52 TB across a ten-drive 10 TB pool) is absorbed by protection, metadata, and safety thresholds—reveals substantial hidden operational expenditure. If ten enterprise SATA/SAS drives draw an average of 8W each under a datacentre PUE multiplier of 1.4, the array draws 112W continuously. The ~52% unusable overhead accounts for approximately 58.2W, consuming roughly 510 kWh annually. At Ofgem's Q3 2026 price cap rate of 26.11p per kWh, powering this unusable capacity costs approximately £133 per year in electricity alone—exceeding £665 across a standard five-year hardware lifecycle for just 100 TB of raw disk.

Procurement teams evaluating on-premises expansion against outsourced repositories should also map these costs directly against usable requirements. Mid‑2026 UK market guidance puts cold/archive cloud backup storage at around 1p per GB per month (about £10 per TB per month), and hot backup tiers in the region of 12p to 15p per GB per month (roughly £120 to £154 per TB per month), though provider pricing varies. Applying these rates to the 47.54 TiB (~52.27 TB or ~52,270 GB) usable output from our worked example establishes an exact baseline: hosting this usable dataset in UK cloud archive storage costs roughly £523 per month (£6,276 annually), whereas hot cloud storage demands £6,272 to £7,840 per month. Crucially, pricing this against the headline 100 TB raw quote rather than true usable capacity would have falsely doubled projected cloud costs to £1,000/month cold or £12,000–£15,400/month hot, distorting the build-versus-buy business case.

Checklist: What to Ask Your Storage Vendor

Before approving a commercial storage proposal, insist on clear technical specifications rather than high-level sales brochures. Request answers to these practical sizing questions:

Are quoted capacities stated in decimal TB (10^12 bytes) or binary TiB (2^40 bytes)? Ensure all sizing documentation matches the reporting units of your hypervisors and operating systems.

What contractual remediation applies if usable capacity falls short? Demand an explicit performance guarantee stipulating that if the provisioned system delivers less usable binary space than modeled due to system overheads, the vendor must supply additional media and drive bays at zero cost.

What are the internal metadata, indexing, and OS reservations? Request explicit sizing for journaling, file system tables, and object metadata footprints.

Are unit-labelling disclosures legally defined across all documentation? Require vendors to submit formal tender specifications that explicitly separate decimal hardware capacity from usable binary figures, ensuring contractual commitments match operating system reporting.

Does the quote guarantee usable capacity without assuming data reduction? Sizing should meet business requirements entirely on usable capacity before factoring in speculative deduplication or compression multiples.

Sources

Every figure in this article traces to the sources below.

• •NIST — SI Units and Binary Prefixes Information
• •Ofgem — Energy Price Cap 1 July to 30 September 2026
• •Ofgem — Energy Price Cap 1 October to 31 December 2026
• •OneUptime — Ceph Storage Planning: Raw vs Usable Capacity
• •GOV.UK — Quarterly Energy Prices Statistical Release June 2026
• •BBC News — Energy Price Cap and Typical Household Electricity Benchmark
• •Servnet — UK Backup Repository Cost Per TB Tracker 2026