Convert GiB to TB

A gibibyte is 1,073,741,824 bytes — about 7% more than a gigabyte. Windows measures in gibibytes and labels them GB, which is the whole of the missing-space mystery.

A terabyte is a trillion bytes. A drive sold as 1 TB is exactly that — the space that seems to go missing is a unit disagreement, not a defect.

The factor is 0.001074, and almost nobody carries that around. Rounded to 0.00107 it is off by 0.35 % — which stays invisible on small numbers and turns into a whole unit somewhere around 1,000 GiB.

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 GiB is 1,024 of the unit below it; one GB is 1,000. On this page that is the difference between 0.0011 TB and 0.001 TB — 7.4 % — 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 7.4 %. A drive sold in GB holds exactly what the label says; Windows divides by 1,024 instead of 1,000, keeps the decimal name, and reports 0.001 TB where the box said 0.0011. 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.

The number that starts this conversion almost always came from a machine. A volume manager reporting the size of an existing pool, a hypervisor summarising datastores, a monitoring dashboard trending consumption — all of them compute in powers of 1,024 and print GiB or a bare GB that means the same thing. The number that ends it goes on a purchase order, and every supplier quotes decimal terabytes.

That makes this a boundary conversion rather than an arithmetic exercise, and boundary conversions are where units get dropped. A requirement travels from an engineer to a procurement form as a bare figure, is read as decimal because the form is decimal, and the order is placed for seven per cent less capacity than was asked for. Nothing in the process is wrong except that the unit stopped travelling with the number.

Most unit conversions are symmetric in their consequences: being a little over or a little under costs about the same. This one is not. A capacity purchase that lands under the requirement cannot be corrected by configuration, by tuning or by a support ticket. It is corrected by buying more hardware, which means another approval, another lead time and another maintenance window.

So the rule is to round up to the next available capacity and then apply the design margins on top. 4,000 GiB is 4.295 TB and wants a larger drive than a 4 TB one. 8,000 GiB is 8.59 TB. 20,000 GiB is 21.47 TB. In each case the arithmetic lands a shade past a catalogue size, which is not a coincidence — the catalogue sizes are round decimal numbers and the requirements are round binary ones.

A short table covers most procurement. 500 GiB is 0.537 TB. 1,000 GiB is 1.074 TB. 1,024 GiB — one tebibyte — is 1.0995 TB. 2,000 GiB is 2.147. 5,000 GiB is 5.369. 10,000 GiB is 10.737. The multiplier is 0.001074 from GiB to TB, or more memorably, add 7.4 per cent and move the decimal point three places.

The 1,024 line is the one worth internalising, because it is where the intuition breaks. One tebibyte is not one terabyte, it is 1.0995 of them, so a requirement expressed as "a terabyte" by an engineer looking at a binary display needs a 1.1 TB purchase and there is no such product. That single mismatch is behind a great many volumes that are provisioned at exactly the size that turns out to be slightly too small.

The order of operations decides whether the number at the end means anything. Start with usable capacity in the unit the requirement was measured in — GiB — because that is the figure somebody actually needs. Convert it to TB. Then apply the redundancy layout, which is a multiplier on the purchase and not on the requirement: a mirror doubles it, single parity over eight members adds an eighth, double parity over eight adds a quarter.

Doing it the other way round produces numbers that cannot be checked. Applying the unit conversion after the parity arithmetic mixes a 7.37 per cent correction into a 25 per cent one and makes both invisible, so when the delivered array is smaller than expected nobody can say which step was wrong. Two separate lines with two separate justifications survive review; one blended figure does not.

Cloud consoles are the sharpest version of this problem because both units appear within a few clicks of each other. It is common for a block volume to be created with a size in gibibytes, for the usage graph to be drawn in gibibytes, and for the pricing page to quote a rate per gigabyte-month. Each is internally consistent and the combination is not intuitive.

The practical consequence is on the invoice rather than the capacity: a volume created at 1,000 GiB is 1,074 GB of billable storage, so the bill runs 7.4 per cent above a naive estimate made from the provisioning figure. It is a small percentage of a large recurring number, which is exactly the shape of a cost variance that gets noticed a quarter late.

It is tempting to treat the 7.4 per cent as slack — to buy at the converted figure and call the difference headroom. It is not headroom, it is the same quantity written down correctly, and spending it leaves the design with no margin at all. Growth, snapshots, filesystem reserves and the performance cliff that most storage hits before it is full are separate allowances and each needs its own number.

The useful habit is to write the plan as a chain that can be read back: usable requirement in GiB, the same figure in TB, the layout multiplier, the growth allowance for the purchase cycle, the catalogue size chosen. Five lines, each defensible on its own, and the conversion sitting in the open where anybody can check it rather than folded into a margin that nobody can.

The only reliable protection is to carry the unit with the figure everywhere it goes, and to include the byte count when the figure crosses an organisational boundary. A requirement written as "10,737,418,240,000 bytes, being 10,000 GiB or 10.74 TB" cannot be misread by procurement, by a supplier or by whoever inherits the system in two years.

That looks like overkill on one line and stops looking like it the first time a quotation comes back against the wrong number. Storage is the one domain on this site where a unit disagreement has a price attached, and where the person who discovers the error is usually not the person who made it.

A redundant array uses only as much of each member as its smallest one provides, so a set assembled from drives of nominally equal size can lose capacity to a few gigabytes of difference between manufacturers. That has been a real hazard for as long as drives have been sold by round decimal numbers, and it is why enterprise controllers frequently round every member down to a common figure before building the set.

It matters to this conversion because it means the purchase figure cannot be a bare total. A requirement of 40,000 GiB, converted to 42.95 TB and satisfied by eleven 4 TB drives, is a different order from one satisfied by six 8 TB drives, and the two have different rebuild times, different failure exposure and different usable totals after parity. Convert first, then choose the member size, then check that the arithmetic still clears the requirement with the layout applied.