Convert TiB to GB

A tebibyte is 1,024 gibibytes. The gap against the terabyte has grown with each step: 2.4% at kilo, 4.9% at mega, 7.4% at giga, 10% at tera.

A gigabyte is a billion bytes in the decimal sense used by drive manufacturers, phone plans and video sizes.

One TiB is 1,024 of the unit below it; one TB is 1,000. On this page that is the difference between 1099.5116 GB and 1000 GB — 10 % — and the gap grows at every step up the scale, which is why it is a rounding error on a photograph and a visible chunk of a hard disk.

This is the whole of the missing-storage mystery, and on this page it is worth 10 %. A drive sold in TB holds exactly what the label says; Windows divides by 1,024 instead of 1,000, keeps the decimal name, and reports 1000 GB where the box said 1099.5116. macOS has counted these in the decimal units since 10.6, which is why the same drive can look two sizes on two machines — nothing is missing and nobody is rounding, the same bytes have two names.

Arrays report tebibytes. A ZFS pool, a NAS summary page, a Linux filesystem asked for human-readable sizes — all of them count in powers of 1,024, and the figure that gets written down and carried into a planning document is a TiB one. Price lists, quota pages and provisioning dialogs are overwhelmingly in decimal GB, because that is the unit capacity is sold in and has been since long before anyone was selling it by the month.

Between the two is a multiplication by 1,099.511627776. A 12 TiB pool is 13,194 GB, not 12,000, and the 1,194 GB of difference is nearly 10 percent of the quote. Nothing about the round conversion looks wrong on a page — 12 TiB and 12,000 GB read as the same amount to almost everybody — which is why this error survives review and appears first on an invoice.

The conversion is only half the problem, because the field you are filling in may itself mean gibibytes. Block storage volumes are frequently provisioned in GiB while object storage is frequently billed per decimal GB, and the two can sit in the same console under similar labels. Reading the service documentation is the right first step and it does not always answer the question.

What always answers it is a measurement. Provision or store a quantity whose byte count you know, read what the service reports, and divide: the ratio will be exactly 1,000,000,000 or exactly 1,073,741,824, and there is nothing in between for it to be. One observation per service settles it permanently and is worth recording somewhere the next person will find it.

A usable capacity in TiB is several subtractions away from the drives that have to be bought. Convert the usable requirement to bytes; add the redundancy, which for single parity across a set of drives costs the capacity of one of them and for mirroring costs half of everything; add the headroom the filesystem needs to keep performing, which for a copy-on-write filesystem is not a small allowance; then convert to the decimal terabytes the drives are labelled in.

Doing those steps in mixed units is how a pool ends up one drive short. Each subtraction has to apply to a figure in a known system, and the temptation is to take 9 percent off here and a drive off there until the answer looks plausible. In bytes, every step is checkable and the final conversion happens exactly once, at the point where the number becomes a purchase order.

Storage priced per gigabyte per month multiplies whatever quantity it is given, so an error in the quantity is an error in every invoice for as long as the data exists. Quoting a 12 TiB migration as 12,000 GB rather than 13,194 understates by 1,194 GB a month, permanently, and the shortfall is not visible in any single number on the bill — it is visible only as a total that does not match the estimate.

The same applies to anything else charged by volume: transfer, snapshots, replicas in a second region. Each is a multiplier on a base quantity, and each inherits whatever unit error the base carries. Getting the base right once is worth more than checking every line afterwards, which is the general argument for quoting in bytes and letting each system present the figure in its own units.

A pool summary usually shows several numbers that look like capacity and are not the same thing: raw capacity across the drives, usable capacity after redundancy, allocated space, and free space, sometimes with compression and deduplication savings folded into one of them. Comparing the wrong pair produces a discrepancy that gets attributed to units when it is a definition problem.

The order to read them in is raw, then usable, then allocated. Raw should be close to the sum of the drive labels converted from decimal TB to TiB — about 91 percent of the number on the boxes. Usable should be raw minus the redundancy. Allocated should be less than usable by whatever is free. If any of those three relationships does not hold, the explanation is in the configuration rather than in the arithmetic.

Storage layers that compress or deduplicate report a logical size and a physical one, and the ratio between them is a property of the data rather than of the system. A pool holding highly compressible data can store more logical bytes than its physical capacity, which makes any forecast based on logical figures unreliable in both directions — favourable while the data stays compressible, and abruptly unfavourable when a large volume of already-compressed media arrives.

For a quote this means stating which figure is being priced. A migration quoted on logical size and billed on physical, or the reverse, produces a difference far larger than the 9.95 percent this page is about. The unit conversion is exact and can be settled once; the compression ratio is an estimate that has to be measured on a representative sample and stated as an assumption. Stating it also makes the quote revisable: when the real ratio turns out different, only one number in the document has to change.

The habit that removes this whole class of dispute is to carry the byte count in every document that will be read by more than one organisation. A quote that says 13,194 GB and gives 13,194,139,533,312 bytes beside it can be checked by anyone, converted into any convention, and compared with any price list without a conversation about whose gigabyte is meant.

It costs one column and it changes what a disagreement is about. With bytes on the page, a mismatch is a question of what is being counted — snapshots, replicas, overhead — which is a discussion both sides can have productively. Without them, the first hour goes on establishing whether anybody is talking about the same quantity, and that hour recurs at every stage of the project. The byte count is one number, it never needs translating, and it is the only figure in the document that both parties can be certain they are reading the same way.