Raw, Protected and Client-Usable Storage: Compare Capacity in a GPU Offer

Start with the 60 TB allocation requirement

Consider a fictional buyer who requires an empty allocation for 60 TB of original data, with any growth or working-space requirement to be specified separately. Offer A lists 120 TB raw with three total copies. Offer B lists the same 120 TB raw with stipulated 4+2 coding and advertises 80 TB after protection. The buyer needs to follow both offers through to the space provided to the workload.

Raw device capacity is the sum of the stated capacities of the included devices. Identify whether that population includes boot drives, cache, spares or devices assigned elsewhere. A total across those roles does not establish one data allocation. The related DGX B200 storage guide explains boot, cache and external storage roles; this comparison starts with the relevant data-device population identified.

For this comparison, protection-only logical capacity means the amount of original data supported after accounting only for copies or coding chunks. Client-usable capacity means the capacity made available at the workload's actual storage boundary, such as its filesystem, volume or tenant allocation. The allocation limit and its remaining free space are separate figures.

First isolate protection. Stipulate that all 120 TB in each offer can participate in its stated scheme, with existing data and every other deduction excluded. All TB quantities in the case are exact decimal amounts. These are invented arithmetic inputs, not product specifications, installed-system observations or successful write results.

Offer A: three total copies reduce 120 TB to 40 TB

With three total copies, each unit of original data occupies three units of raw storage in this simplified accounting. Three copies means three instances in total, rather than an original plus three additional copies. Ceph Squid's erasure-code documentation contrasts this replication factor of 3 with coding factors.

Offer A therefore supports an ideal protection-only logical amount of 120 TB / 3 = 40 TB. Storing that 40 TB once accounts for 40 TB; its two additional copies account for 80 TB. Together they consume the stipulated 120 TB.

The buyer requires 60 TB. A's 40 TB result already falls short, even with every other deduction excluded. Repeating the 120 TB drive total cannot substantiate the requested allocation: that same total also has to hold the copies.

References: [C1]

Offer B: four data chunks plus two coding chunks allow 80 TB

Offer B uses a different mechanism. Ceph Squid's profile documentation explains splitting data into equal-sized data chunks and computing coding chunks of the same size. In the stipulated 4+2 case, four data chunks collectively represent the original data, with two additional coding chunks carrying protection information. The six chunks are not six complete copies.

The storage factor is therefore (4+2)/4 = 1.5 units of underlying storage per unit of original data. The denominator is the four data chunks. Dividing 120 TB by six would wrongly treat every chunk as an entire copy; treating 1.5 as a claim that half the raw space remains free would also use the wrong denominator.

Offer B's ideal protection-only logical amount is 120 TB / 1.5 = 80 TB, equivalently 120 TB × 4/6. Its data chunks account for 80 TB and coding chunks for 40 TB in the simplified total. Ceph Squid documents the same 4+2 factor of 1.5; its documented default profile is 2+2, a separate case.

The 80 TB result exceeds the buyer's 60 TB requirement at this protection-only screen. The next question is how much of the offered service reaches the buyer's allocation.

References: [C1][C2]

The later 48 TB client quota changes the buying answer

Offer B's supplier now clarifies that the client quota is 48 TB. That is the decisive allocation figure in this fictional return. An allowance of 48 TB falls 12 TB short of the requested 60 TB, even when the allocation is empty.

The 80 TB result answered how much original data the raw total could support after the stipulated coding alone. The 48 TB quota answers how much this client is allowed to hold. The coding calculation did not allocate its result to the buyer, and the two figures alone do not explain every intervening deduction.

CephFS provides a named example of this boundary: a directory quota can restrict bytes or file count, and a mounted root's reported available space can be based on quota minus usage. A quota states a limit rather than establishing a physical reservation. Ceph also documents cooperative, imprecise enforcement, so a quota statement is not evidence of an exact write-stop point.

Both offers therefore leave the buyer's stated requirement unmet: A at the protection calculation, B at the later client allowance. Raising B's quota would still require evidence of the capacity supporting the revised allocation; changing the limit alone would not supply that evidence.

References: [C4]

Check whether a smaller number is a unit conversion

Before treating a supplier's smaller displayed number as another capacity deduction, reconcile its units. Here 1 TB = 1,000,000,000,000 bytes, while 1 TiB = 1,099,511,627,776 bytes. NIST distinguishes decimal tera from binary tebi.

For example, the same 80 TB is approximately 72.76 TiB. Expressing those bytes in TiB changes the number without consuming storage. Retain the units attached to each supplier figure, convert consistently and request byte counts when a TB label is ambiguous. The case's 48 TB quota and 60 TB requirement already use the same unit, so conversion cannot close their gap.

Apple's February 26, 2025 capacity guidance separately explains decimal labeling and space consumed by formatting. Formatting is an actual use of space, unlike changing units. Its guidance supplies no formatting allowance for the GPU storage offer.

References: [U1][A1]

Request one reconciliation at the buyer's allocation boundary

The supplier return needs to connect the identified raw device population to capacity after protection, net service capacity, the buyer's allocation limit and the space available in that empty allocation. Have each supplier define what its protected or usable label includes. A protected figure may already include adjustments beyond the protection-only calculation used here.

Account once for the actual configuration's formatting, metadata and allocation overhead, required reserves, unequal device capacities, placement restrictions and operating limits. Identify how snapshots, existing data and other allocations affect the service being offered. With unequal devices, the sum alone cannot establish how much of each device the layout can use. Request the applicable treatment rather than subtracting an invented standard percentage.

A pool report can help explain this reconciliation when its scope is understood. Ceph Squid distinguishes raw usage from stored data and defines pool MAX AVAIL as an estimate of additional notional data that can be written to that pool. Its value depends on protection, device mapping, device utilization and the configured fullness threshold. A cluster-wide free total or pool estimate is therefore insufficient to establish the capacity available to one client allocation.

For A, request an offer that accounts for the 60 TB allocation rather than returning the same 120 TB raw headline. For B, request an explicit answer to the 48 TB allowance and the supporting capacity reconciliation. Retain the product/version, configuration basis and evidence date. A planned allocation and a current observed free-space figure answer different questions.

If effective capacity depends on data reduction, ask for the stated assumptions and the quantity available without that assumed saving. Compare prices after identifying the same delivered capacity and included service. Performance, durability, availability and workload suitability need their own evidence; these capacity calculations select no architecture or performance winner.

References: [A1][C3]

Carry the resolved offer into the physical installation scope

Once the storage owner has resolved the capacity offer, its equipment and approved connections can become inputs to the physical installation package. The related storage-network handoff guide explains the endpoint records needed for that transfer. Rack placement or a completed cable path cannot establish the workload's allocation.

Leviathan's rack-and-stack service covers agreed physical mounting, IT cabling, labeling and handoff records for customer-furnished equipment, subject to the actual site and authorized scope. Identify the equipment supplier and storage-service owner separately. Storage architecture, capacity allocation, data migration and software commissioning need their own appointed scope.

Use the related service page or its project inquiry to share a nonconfidential equipment summary, rack positions, approved connection schedule, site constraints and required physical output. Carry unresolved capacity or connection inputs with their responsible owners so the scope discussion starts with the remaining work.

References: [L1]