Convert GB to TiB

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

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.

The factor is 0.000909, and almost nobody carries that around. Rounded to 0.00091 it is off by 0.06 % — which stays invisible on small numbers and turns into a whole unit somewhere around 10,000 GB.

That is the number worth knowing before you round: not the error itself, but where it stops being ignorable. Below that point the shorter factor is the sensible one; above it, use the field above, which never rounds until it prints.

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.

Storage is specified in the units of whoever wrote the document. Drive datasheets, volume requests, database sizing guides and quota tables are almost all in decimal gigabytes, because that is how the components were sold. The pool those volumes land in is reported by software, and software counts in powers of 1,024, so the total comes back in tebibytes.

The two do not add up in the obvious way. A plan for forty volumes of 250 GB is 10,000 GB, which sounds like ten of something and is 9.09 TiB. Anybody who reserved a 10 TiB pool has a comfortable margin they did not know about; anybody who reserved 9 TiB is short by exactly the amount the conversion hides, and will find out when the pool fills.

The divergence between the decimal and binary scales compounds at every prefix: 2.4 per cent at kilo, 4.86 at mega, 7.37 at giga, 9.95 at tera. Crossing from GB to TiB uses the tera-step ratio, so the correction is the largest anybody meets in practice. A tenth of a capacity plan is not a rounding difference; it is a drive, a shelf or a month of growth.

It is also the step at which the two conventions stop looking similar enough to substitute. Below a gigabyte, people get away with treating the units as interchangeable because the error hides inside the safety margin. At the tera step the error is bigger than most safety margins, and a plan that treats a thousand gigabytes as a tebibyte is wrong by more than it is careful.

Five figures cover most of this work. 1,000 GB is 0.909 TiB. 2,000 GB is 1.819. 5,000 GB is 4.547. 10,000 GB is 9.095. 50,000 GB is 45.47. Going the other way, one TiB absorbs 1,099.5 GB, so a pool reported as 20 TiB will take about 21,990 GB of decimal-quoted volumes.

The shortcut that survives being remembered wrongly is to multiply gigabytes by 0.0009095, or to divide by 1,100 and accept a tenth of a per cent of error. Dividing by 1,024 is the mistake to avoid: that ratio takes gibibytes to tebibytes, not gigabytes, and using it here reports 0.977 TiB for 1,000 GB — an over-count of 7.4 per cent, in the direction that makes a pool look larger than it is.

The failure is rarely a bad conversion. It is a column that contains both kinds of number. A sizing sheet picks up drive capacities from a vendor quotation in TB, current consumption from a monitoring export in TiB, per-database estimates from a DBA in GB, and a backup retention figure from a policy document that does not say. Every value is correct in isolation and the total is not.

The practical fix is to convert on entry rather than at the end, and to name the column after its unit rather than after its contents. A column headed "bytes" cannot silently accept a tebibyte figure; a column headed "size" can, and eventually will. This is the same discipline that stops currency columns from mixing, applied to a difference that is smaller and therefore harder to see.

On a thick-provisioned pool a unit mistake announces itself immediately: the allocations do not fit and something refuses to be created. Thin provisioning removes that check by design, letting the sum of volume sizes exceed the physical capacity on the assumption that not everything will be used at once. The unit error survives that assumption intact and waits.

What arrives later is a pool crossing its high-water mark earlier than the model predicted, by roughly the size of the conversion that was skipped. The symptom is a forecast that keeps being revised, not an error, which is why it is worth reconciling the model against the pool in bytes once at the start rather than trusting that two sets of plausible numbers describe the same thing.

The unit conversion is arithmetic and is not a loss. The subtractions that follow it are real. Parity or replication takes its share first — a mirrored pool halves, a double-parity set of twelve gives ten members of usable space. Filesystem structures and reserves take a few per cent more. Snapshots take whatever changes between them, which is a rate rather than a fixed figure and is the one most often left out of a plan.

Keeping those separate from the GB-to-TiB step is what makes a capacity model auditable. When the pool fills early, the first question is which of the four subtractions was underestimated, and that question is answerable only if each was recorded as its own line. A single blended "overhead" percentage hides exactly the mistake anybody would want to find.

Growth rates arrive in the same mixed units as everything else — a few hundred gigabytes a month from an application team, a percentage from a trend line, a tebibyte-per-quarter figure from a monitoring system. Applying a growth percentage to a figure in one unit and adding it to a baseline in another is the compound version of the same error, and it drifts further with every planning cycle.

Convert the baseline and the growth to bytes, run the model there, and convert the answer into whatever unit the purchase order will use. It is a dull step, it takes one column, and it is the difference between a plan that lands within a per cent and one that is a whole drive out by the second year.

A backup plan multiplies more mixed units together than any other capacity exercise. The protected data is quoted in GB by the application teams. The retention policy is a count of daily, weekly and monthly points. The change rate is a percentage. The deduplication and compression ratio is a factor supplied by a vendor. The repository that holds the result reports in TiB. Six inputs, four unit systems, and a product that is wrong by whatever the least careful step was.

The ordering that survives review is to reduce everything to bytes at the point of entry, apply the retention and change-rate arithmetic there, and convert once at the end. It is also worth recording the deduplication ratio as an assumption rather than a measurement until the repository has run for a full retention cycle, because it is the single term with the widest range and it is routinely quoted from a datasheet rather than observed.